A context diagram is a model illustrating the interaction between a product and external people, organizations, or systems. The context diagram is used by business analysts to understand the context and boundaries of the systems within a project. The structural elements of a context diagram comprise the product, external entities, and data flows.
- Understanding a context diagram
- The structural elements of a context diagram
- Benefits of context diagrams
- Context diagram example
- Key takeaways:
- Connected Business Frameworks
Understanding a context diagram
The context diagram identifies the flow of information between the system and external entities (actors) and helps the project team identify the interfaces that it needs to account for.
Businesses will find context diagrams to be useful when:
- Work has begun on a new product that is expected to interact or impact existing systems.
- An existing process is being automated, involving the building of a new system or the implementation of a commercial off-the-shelf (COTS) system.
- An existing system needs to be replaced – which interfaces will be impacted by the upgrade?
- Revisions need to be made to a system such that interfaces need to be added or removed.
The context diagram usually forms part of a requirements document and must be read and understood by all key project stakeholders. As a result, it should incorporate plain language wherever possible.
The structural elements of a context diagram
To illustrate key interactions, the diagram incorporates three symbols according to the elements they represent. These elements include:
- The product (circle) – or any system, process, or business entity responsible for processing and sending information to each entity. Importantly, the product in question must be within the control of the initiative to change. Systems, processes, people, or organizations that cannot be changed by the initiative should be represented as external entities.
- External entities (rectangles) – defined as the people, organizations, and systems that provide data to (or consume data from) the product. In a hotel reservation system (product), external entities include hotel guests, financial institutions, and external reservation systems.
- Data flow (directional arrows) – how does the product interact with external entities via data transfer? This encompasses user interfaces, file transfers, reporting, and APIs among other things. Each data flow is represented by an arrow annotated with text detailing the type of data that flows between the product and each entity. The label itself should be a noun giving a very general description of the data flow. For example, data flow between a bank and a hotel reservation system may include labels such as “payment validation request” and “payment validation”.
Benefits of context diagrams
Project teams that are unfamiliar with context diagrams should know that they can realize several benefits:
- Error identification. Context diagrams provide a means for noting omissions or errors in a business plan or project. This helps the business mitigate risks and reduce costs before project implementation.
- Scope definition. In some cases, the scope of a project may be hard to communicate to every stakeholder. The context diagram clearly illustrates the scope of a project in a way that is relatable and understandable.
- Customer clarification. The project team can use the diagram to provide clarity on the user group that it considers to be its customers. This gives the organization impetus and purpose and allows project sponsors to make targeted investment decisions.
Context diagram example
We will now outline some additional applications of context diagrams as well as expand on the hotel reservation system example touched on earlier.
In each case, we’ll list the product, external entities, data flow, and data flow description where relevant.
Automated teller machine
A context diagram can be used to depict ATM software and illustrate how it interacts with hardware.
The ATM system (product) interacts with the following external entities:
- Accounts database (external entity) – account information (data flow descriptor).
- Cash dispenser – cash details and warnings.
- Printout dispenser – printout information and warnings.
- Customer display – display information.
- Card reader – data and commands.
- Customer keypad – data and commands.
- Control system – data and commands.
Work context diagrams can also be used to clarify the factors and events that must be analyzed to ensure a product supports its environment.
In this example, consider the “give-and-take” interactions that occur between an online community (product) and its key stakeholders:
- Staff writers (external entity) – content out, compensation in (data flow descriptors).
- Community users – registration out, tools, and information in.
- Advertisers – payments out, advertising spots in.
- Accountants – financial reports out, financial data in.
Supply chain management
Business context diagrams are another iteration that defines task expectations that are either within or outside of a company’s scope.
These diagrams also serve as a systems requirements document since project stakeholders can rigorously assess the resources required for successful implementation.
Let’s now consider a context diagram that illustrates the data flow that occurs between a supply chain management system and the sales channels it serves.
Like any robust context diagram, this one identifies the tasks involved in each interaction and in the process, clearly defines the range and limitations of the system:
- Supply chain management system (product).
- Wholesale distributors (external entities) – inventory levels and orders out, delivery details in.
- Retail distributors – orders out, delivery information in.
- Suppliers – delivery information and shipment details out, purchase orders in.
Hotel reservation system
In this fourth example, let’s return to the example of the hotel reservation system:
- Book room (product).
- Hotel rooms (external entity) – room (data flow descriptor).
- Time/schedule – current time and date.
- Financial institution – payment validation request in, payment validation out.
- Guest – booking request out, booking confirmation in.
- External reservation system – booking request in, booking confirmation out.
- Bookings – booking.
- Guests – guest.
Order processing system
In the fifth and final example we have a context diagram for an order processing system:
- Order processing system (product).
- Inventory (external entity) – available inventory in, product availability request out (data flow descriptors).
- Production – production schedule in, confirmed order out.
- Customer – request payment, order status in, status response, invoice out.
- Delivery company – delivery service, goods in, product delivery information out.
- Procurement – requisition request out.
- Supplier company – marketing services, orders in.
- Government – tax rate, import/export registration in.
- Credit agency – credit validation in, credit demand out.
- A context diagram graphically represents the flow of information between a product and its people, systems, or organizations.
- A context diagram contains a product, process, system, or business entity at its center. The product is connected to external entities by directional arrows which describe the nature of data flow between the product and each entity.
- A context diagram must be created in such a way that all project stakeholders can understand the conceptual relationships between key elements. Primarily this is achieved by assigning very general, noun-based descriptions to the data flow.
Connected Business Frameworks
Main Free Guides: