Context Diagram In A Nutshell

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 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:

  1. 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.
  2. 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.
  3. 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 dispensercash 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.

Online community

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.
  • Accountantsfinancial 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 companymarketing services, orders in.
  • Government – tax rate, import/export registration in.
  • Credit agency – credit validation in, credit demand out.

Key takeaways:

  • 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

Cynefin Framework

The Cynefin Framework gives context to decision making and problem-solving by providing context and guiding an appropriate response. The five domains of the Cynefin Framework comprise obvious, complicated, complex, chaotic domains and disorder if a domain has not been determined at all.

SWOT Analysis

SWOT Analysis is a framework used for evaluating the business’s Strengths, Weaknesses, Opportunities, and Threats. It can aid in identifying the problematic areas of your business so that you can maximize your opportunities. It will also alert you to the challenges your organization might face in the future.

Pareto Analysis

The Pareto Analysis is a statistical analysis used in business decision making that identifies a certain number of input factors that have the greatest impact on income. It is based on the similarly named Pareto Principle, which states that 80% of the effect of something can be attributed to just 20% of the drivers.

Failure Mode And Effects Analysis

A failure mode and effects analysis (FMEA) is a structured approach to identifying design failures in a product or process. Developed in the 1950s, the failure mode and effects analysis is one the earliest methodologies of its kind. It enables organizations to anticipate a range of potential failures during the design stage.

Blindspot Analysis

A Blindspot Analysis is a means of unearthing incorrect or outdated assumptions that can harm decision making in an organization. The term “blindspot analysis” was first coined by American economist Michael Porter. Porter argued that in business, outdated ideas or strategies had the potential to stifle modern ideas and prevent them from succeeding. Furthermore, decisions a business thought were made with care caused projects to fail because major factors had not been duly considered.

Read Next: SWOT AnalysisPersonal SWOT AnalysisTOWS MatrixPESTEL AnalysisPorter’s Five ForcesTOWS MatrixSOAR Analysis.

Main Free Guides:

Scroll to Top