A Context Diagram (sometimes also referred to as a Level-0 Data Flow Diagram) is a common tool that Business Analysts use to understand the context of an entity being examined. Most descriptions of a Context Diagram limit this entity to a system that is being created or modified as part of a project, but the Context Diagram can also be applied to other entities.
There are at least three different specifications for creating Context Diagrams (that I can find at this time). They are: Gane-Sarson, Yourdon-DeMarco, and TOGAF. The main characteristics of each are described below.
Context Diagrams in the Gane-Sarson and Yourdon-DeMarco styles generally consist of just four (4) standard elements. These are:
The Process (or system, or business entity, etc) being investigated. There should only be one process per Context diagram and it is generally displayed in the center of the diagram. The Process contains the name of the process or entity being investigated.
Data Stores are databases that are either created by the Process under review and used by outside parties, or created by outside parties and used by the Process.
Note that data stores/databases may not show up on many context diagrams. If the database is part of an external system, you would show the overall system, not the database. Normally you only want to show a database when it is shared by your core process and another system. However, I like to use the database symbol for some external actors where most of what they provide is data (a 3rd-party data feed for example, or an external data processing system). I do this because I find stakeholders better understand the nature of that entity.
Actors (or Entities, or Terminators) are the parties that communicate either directly with the Process, or indirectly with the Process through an intermediary Data Store. According to Yourdon, in a Context Diagram the Actors should not be shown as communicating directly with each other.
Flows (or Relationships) represent data or events flowing between the three other components above. Flows are labelled and can be displayed as unidirectional or bi-directional.
In the TOGAF Enterprise Architecture system the Context Diagram can be used to model a specific project. This Project Context Diagram uses up to fifteen (15) different model elements, and includes different elements for: 
Because I am unsure of the copyrights on the symbols used and my copy of Visio does not support TOGAF modeling, I will just refer interested users to this link at the TOGAF-Modeling.org web site: Project Context Diagrams.
Remember, the main purpose of a Context Diagram in the business analysis space is to communicate with stakeholders, not to specify data flows to developers. Feel free to skip the formal styles above and use any other diagram elements that are available to you and that make sense. If you use Visio, your stakeholders might react better to person shapes for external parties, computer shape for systems, disk shapes for databases, and similar changes that make the diagram more intuitive for them to understand.
In general, a Context Diagram can be used to examine:
Some more specific uses include:
As indicated above, most Context Diagrams are focused on identifying the context of a system.
Creating a context diagram of a process or system is not just a great way to help determine the scope of an effort, it also helps identify the stakeholders who should be involved. This is also one of those times where strict adherence to the formal design standards for context diagrams should be skipped and you should show communication between actors or external entities as a way of identifying non-directly impacted stakeholders. You should add more detail to you diagram as the effort moves on and you learn more.
By skipping the level of detail in something like a Process diagram, the BA remains at a sufficient level of abstraction that the context diagram enables stakeholders to see the big picture while not getting bogged down or distracted by the details.
A great use for Context Diagram's comes up when BA's are first starting to work with a particular business unit or client. By starting with a Context Diagram that shows the standard interactions and relationships for that business unit, the BA can learn a great deal about the business and identify specific processes or use cases that merit further exploration.
The Context Diagram structure can also be used to analyze a problem.
Processat the center of the diagram.
Flowsin the diagram.
For example, maybe the problem you are investigating is
User dissatisfaction with our website.
User dissatisfaction with our websitebecomes the Problem label in the center of the diagram.
Browserversion flowing into the problem (external factors contributing to the problem) and with
lack of a content delivery network, and
server bandwidthbeing interactions flowing out from the problem )internal factors that drive the problem out to the user.
When doing problem analysis, it rarely helps to limit the diagram to just those factors directly interacting with the problem domain, so the diagram may have connections several
steps away from the problem.
A more complex version of this problem analysis structure exists as the Problem Frame Approach.
In the following steps I will demonstrate the creation of a Context Diagram for a simplified web-based order system using the Yourdon-DeMarco format, created with Enterprise Architect.
The first step is the Process (or business entity, or in this case a system) that you are focusing on to the diagram. There should only be one Process per context diagram and this should be your first action. Note however, that the subsequent steps below can be done in whatever order you like.
For the second step, I am going to add the Actors. To start off, I can think of four actors who would interact with the Order system. They are:
The updated diagram now looks like this:
For the third step, I am going to add a single external data store that represents the transaction processors system. Remember that with a context diagram you are modeling the factors external to your process, so any database that is internal to Order System is not modeled. I could have made this an external entity, but given that I am assuming the transaction processing is a fully automated process, I feel a data store makes more sense.
The updated diagram now looks like this:
Now that the actors and data stores have been defines, the next step is show the interactions between them. If I was working with stakeholders to determine the interactions of an Order system, I might find the following common interactions and data flows between the entities diagrammed in Step 3.
With all of those interactions captures, the updated diagram now looks like this:
The final result might look like the diagram above. Or a slightly different version based (mostly, the Credit Bureau should be a flat rectangle) on the Gane-Sarson format that I created with Visio is shown below:
From a Business Analysis perspective, the context diagram is mostly used to help determine the scope of the effort that is being undertaken. If for example you were beginning an initiative to improve the Order System itself or the order processing process in the business case above, you could work with your stakeholders to agree that only the items in the diagram are in scope.
For example, if the Warehouse later wanted to add a capability to auto-order certain products when inventory reached a certain point, you could point out that interactions with suppliers are not in the diagram above and thus not in scope.
The actors, systems, and flows captured in a context diagram also provide a starting point for Use Case Diagrams, process flow diagrams, class diagrams, and similar efforts to capture more detailed knowledge.
Flows can be used to: