A Context diagram represents a high-level view of the overall business or system boundary of interest. A Context diagram defines the system’s domain that is under investigation within an organization’s environment. Within the domain, the diagram depicts the top process as a ‘black box’ together with its major incoming and outgoing data flows linked to participating external entities. It is a popular diagrammatic tool for process modelling and scoping systems.
A Context diagram is useful for establishing the boundary of the business or system domain (the sphere of analysis activity) under investigation. It identifies the external entities along with major data interfaces that interact with the target process – all of which the new system will need to consider. The diagram therefore can be a useful tool for helping identify the project scope and secure stakeholder agreement (sign-off) on the project scope.
A Context diagram is possibly one of the first tools that is applied early in the requirements elicitation process within the Analysis phase of a typical System Development Life Cycle. The requirements elicitation process helps with discovering and describing the business and project objectives, including with defining the project scope. A Context diagram's top process can be broken down to reveal more detailed processes and data flows if necessary, using techniques known as functional decomposition and levelled . Technically, a Context diagram is a top level DFD, sometimes referred to as 'level 0 DFD'.
The primary audience involved with a Context diagram are stakeholders such as project sponsors, managers, and subject matter experts who provide the information for developing a Context diagram and are the same people who should approve each Context diagram. Project managers and requirements teams are also involved to plan the project work.
A Context diagram can be assembled from the following three components:
Process: A process is a logical activity that can be regarded as a black box with major data flowing in and out of it. A rounded rectangle (or circle) represents a process under study. Each process is labelled inside its rectangle to describe its function or purpose. It is common to use a verb-noun phrase for naming a process, e.g. ‘Check stock’ and ‘Reserve product’. If the Context diagram is decomposed to levelled Data Flow Diagrams, add a numbering scheme inside the process rectangle to identify the start of the hierarchical sequence number (refer to the article for details). It is usual to place the sequence number identifier above the process name with a horizontal line separating them.
An external entity sits outside the domain of interest and supplies data to or receives data from the domain. An external entity is referred to as an external source or sink (destination) for data flowing in and out of the domain. A rectangle defines an external entity and is labelled with a noun phrase inside it to describe an organisation, process, machine or person (i.e. a thing) that is outside the domain under analysis. Examples of naming an external entity are ‘Payment company’, ‘Store locator’, 'Mainframe server' and ‘Customer’.
Data flow: A data flow represents the path of data moving through the domain under analysis. A data flow shows the movement of data between a process and an external entity. An arrow is the symbol used to connect a process with external entities. Each arrow should be labelled appropriately to describe the data being passed, e.g. ‘Customer details’, ‘Rejected order’ and 'Stock level lookup' are common. A data flow can move the same type of data in both directions in which case each end should show an arrow. Data flows are also useful for identifying interfaces which will need closer data analysis (e.g. ER data modelling).
There are two main styles of diagrammatic notations for Data Flow Diagrams; Gane & Sarson notation set (e.g. rounded square symbol for a process), and Yourdon's notation (e.g. circle symbol for a process).
While there are guiding principles and rules for using Context diagrams, in practice they are not necessarily always followed. Some practitioners add new symbols or adapt the rules to suit their needs which can sometimes be useful so long as they are applied consistently throughout the project. The following are some of the principles and rules for using Context diagrams:
Within a Context diagram, the external environment (i.e. external entities) sends data to the main process within the domain under investigation. The main process transforms the incoming data and sends it out to the external environment as output data.
A Context diagram is essentially the top level Data Flow Diagram (level 0 DFD) of a defined domain. It can be decomposed into lower levels of detailed Data Flow Diagrams if necessary (refer to the article for further details).
The main process must have incoming and outgoing data flows.
The main process can have one or more input data flows and one or more output data flows.
An external entity must send its outgoing data flow only to the main process.
An external entity must receive an input data flow only from the main process.
Only the main process is permitted to transform or change data.
The following steps present guidelines for developing Context diagrams:
Define the process: Start a Context diagram by identifying the main process under study and naming it appropriately. If the process needs to be broken down into sub-processes for further analysis, add a numbering scheme to the process to kick-off the numbering sequence for the related Data Flow Diagrams to follow. Also, label each Context diagram with a descriptive name for referencing purposes.
Identify external entities: Identify each external entity that interacts or impacts the main process and label each one with a descriptive name.
Connect data flows: Connect each external entity to the main process by an arrow to show its data flow direction. Name each data flow clearly and as close to it as possible so as to avoid confusing the name with other data flows close by.
Revise and update the Context diagram:
Update the Context diagram as soon as new information is discovered or the existing requirements are changed in order to keep your diagram accurate and complete. Finally, name each Context diagram consistently for referencing back to it throughout the project.
Keep in mind the following pointers when developing Context diagrams:
Decide which style of notation (Gane & Sarson or Yourdon) to use for the Context diagram components throughout the project.
If you wish to avoid data flow lines crossing over each other, try repositioning the components to see if this helps. If it does not, it is acceptable to duplicate components on the diagram for this purpose.
It is common to attach a Context diagram in a high-level business requirements document to define the project scope.
It is vital to engage stakeholders when developing Context diagrams. As well as eliciting the requirements and project scope from the stakeholders, it is essential that they review and agree (sign-off) on each Context diagram that will form part of the project documentation. This way, questions like "Why was this external entity included?" or "How come this interface was missed out?" can be put to rest with responses such as "The sponsors have agreed to include the external entity [exclude the interface] in question from the project scope."