Description

A context diagram is a top level (also known as Level 0) data flow

diagram. It only contains one process node (process 0) that
generalizes the function of the entire system in relationship to
external entities.
A Context diagram represents a high-level view of the overall
business or system boundary of interest. A Context diagram
defines the systems domain that is under investigation within an
organizations 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 modeling
and scoping systems.
Components
A Context diagram can be assembled from the following three components:

1) 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 labeled inside its rectangle to describe
its function or purpose. It is common to use a verb-noun phrase for naming a
process. If the Context diagram is decomposed to leveled Data Flow
Diagrams, add a numbering scheme inside the process rectangle to identify
the start of the hierarchical sequence number. It is usual to place the sequence
number identifier above the process name with a horizontal line separating
them.
2) External entity: 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 labeled with a
noun phrase inside it to describe an organization, process, machine or person
that is outside the domain under analysis.
3) 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 labeled appropriately to
describe the data being passed. 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.
Note:
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.

A sample of Context Diagram:

Principles:
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.
Rules:
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.
Development
The following steps present guidelines for developing Context
diagrams:

1) 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.
2) Identify external entities: Identify each external entity that
interacts or impacts the main process and label each one with a
descriptive name.
3) 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.
4) 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.
Tips:
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."