Business Analyst Articles: Business Analysis & Systems Analysis

» April 2014 (3)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Sunday, June 13, 2010
77507 Views 4 Comments 71 members voted Article Rating

In the course of every project that a business analyst encounters, unknown risks and requirements will inevitably arise. The question is when—will they arise during requirements discovery (ideal), or after the project has been deployed (resulting in managerial consternation and costly fixes)? Context diagrams are instrumental in unearthing unknown requirements during the discovery phase, both by forcing an analyst to think through the context (thus the moniker context diagram) of a project methodically and by enabling stakeholders to do so as well. As one site aptly notes, “Context diagrams can save a project from some very nasty surprises.” [1] Given the return that an analyst gets on her investment (helping to ensure a project’s proper direction), the creation of context diagrams is well worth her time.

What is a context diagram?

A context diagram is a graphic design that clarifies the interfaces and boundaries of the project or process at hand. It not only shows the process or project in its context, it also shows the project’s interactions with other systems and users. According to Wikipedia, a context diagram is “is the highest level view of a system . . . showing a . . . system as a whole and its inputs and outputs from/to external factors.”[2] Further, a context diagram “shows the interactions between a system and other actors with which the system is designed to interface. System context diagrams can be helpful in understanding the context which the system will be part of.”[3]

Here is an example of a context diagram:

Example of a context diagram

A context diagram will fall into one of two categories of rigor:

  • The first lacks any formal structure; an object is simply placed in its context, showing its interaction with external entities from a high level. This type of context diagram is normally produced by those who have not had formal training in producing context diagrams, but who, for a presentation or marketing purposes, want to show an object or system in its context. This may also be used in informal settings even by context diagram experts.

  • The second type is a bit more rigid, drawing from the same rules, syntax, and symbols established for data flow diagrams. In this instance, the context diagram is a subset of a data flow diagram with the context diagrams being the simplest form of data flow diagrams.

A project can have/use multiple context diagrams – for distinct processes - which can be revised as more information is discovered or requirements change. Context diagrams are normally included in requirements documents.

Why is a context diagram beneficial?

Context diagrams are instrumental in advancing the thinking process and triggering memory recall of subject matter expects who create and study them. (To that end, a project may have multiple revised context diagrams that are versioned and archived, or they may be for brainstorming only and never make it off the white board.) A context diagram will also reveal omissions and errors in a business plan or business requirements so that any necessary corrections can be brought to light and addressed before a project is deployed. Kossiakoff wrote, “The objective of a system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of system requirements and constraints.”[4] The goal is to get feedback from a project’s stakeholders and identify any missing pieces while the project is still in the discovery stage.

In addition, a context diagram may serve to unambiguously and quickly define a project’s scope. It facilitates the discovery and/or confirmation of high-level events that trigger the process, including external entities that interact with project or process, inputs to and outputs from the project or process, and initial sub-process requirements.


What are events?

When it is mentioned that a context diagram facilitates the discovery of high-level events, that simply means that a context diagram helps its creator and viewers discover all of the occurrences or happenings to which our system must respond. According to Yourdon, an event may be flow-oriented, meaning it is related to a data flow (i.e., customer credit data enters the system so the credit report is updated); temporal, meaning it occurs at a predictable point in time (i.e., time sheets process at 3:00 p.m. CST), or a control event, meaning it is an expected event that happens at a particular point in time, but the time is not planned or known ahead of time (i.e., deliveries arrive from overseas).[5]

What are the parts of a context diagram?

Context diagrams are made up of simple parts: boxes and lines. According to Wikipedia, “Context diagrams can be developed with the use of two types of building blocks: labeled boxes, one in the center representing the system and around it multiple boxes for each external actor, and relationship, labeled lines between the entities and system”.[6] The two most common ways of displaying these are the Gane-Sarson and Yourdon-De Marco symbol sets.[7] (A bit more information about those is available here.) Visio will accommodate either symbol set.

The main parts of a context diagram are:

  • The process, represented as a rounded rectangle, which shows a given process or activity at its highest level. A process must react in a preplanned way, and indicates where data is transformed, stored, or distributed. (The top portion of the rectangle is often reserved for the process number.) Examples of how this may look are below.

    Context Diagram: Process

  • The external entity may be an actor (person or thing) that either triggers the process or receives output from the process. An external entity may also be either a data source and/or destination. External entities are represented as rectangular boxes. A few examples are below.

    Context Diagram: External Entity

  • Data flows, represented as arrows, are the connectors between the main process and the various external entities and show data flow among them. Again, an example is below.

Context Diagram: Data Flow

An example of these parts displayed together as a context diagram is below:

Simple Sample Context Diagram

What does a context diagram not include?

Since a context diagram is somewhat high-level and focused on the context of the process at hand, it does not include any information that is not directly related to that process’s straightforward system. This means that data sources, external communications, alternative scenarios, or anything not part of the main function or system you are diagramming does not need to be included. While these may be included in a traditional flowchart, they are extraneous to a context diagram.

Additionally, a context diagram will never show work flows or actors who initiate data flows (but it will show the direction of the flow). Context diagrams are not the same as use case diagrams; they do not show the entire process with actors, etc. They only show the process at hand in its context.

How do you create a context diagram?

You can create a context diagram by following eight straightforward steps. Because of the fluid and transformative nature of most context diagrams, a whiteboard may be the best tool to begin their creation. Once the diagram is more concrete, it may become an artifact using Visio or some other tool which supports context diagrams:


Context Diagram pitfalls to avoid

Examine your context diagram to be sure that none of the following were inadvertently included:

  • Internal actors who initiate data flows or processes (as mentioned above, these have no place in a context diagram)

  • “Black holes,” meaning many inputs into the process are depicted but no outputs.

  • Or the converse, “miracles,” many outputs come out of the process, but nothing goes in

  • “Isolated entities,” meaning external entities are shown but not linked

  • Entity-to-entity data flows with no process in between

1: Using a white board or other flexible writing tool, draw a context diagram for the highest level process at hand (known as level 0). Once this is completed, that high-level process may be further decomposed into sub-processes. If the sub-processes are fairly independent of each other, they may each be made into a separate context diagrams (not on level 0) with their own external entities and data flows. If they are sufficiently complex, each of these sub-processes may be decomposed into further sub-processes. This technique is topic for a later article on data flow diagrams.

2: For each distinct high-level process (or system, functional area being studied) draw the process that acts upon the input. Place the process in the center of your white board. Label each process with a unique numeric identifier (example: 1.0, 2.0) that will enable easy reference and revision in your requirements. Use a verb-noun structure to label the process. An example would be “Take orders.” (Ignore the inner workings of the process for this and future steps.)

3: Next, you will identify and document all external entities that are sources of data to the process you just listed. List all the external entities you can think of on the margin of the document. Use nouns to indicate who these entities are. (Examples would be vendors and consumers.) Place the first source onto the diagram, and check it off your list. (You will methodically add the other sources later.)

Context diagram: identify and document all external entities

4: Next, capture the interactions between this first listed source and the process. Determine what input(s) the source provides into the process. Draw the arrow (relationship) and label it accordingly. Determine what output the process returns to the source (if any), and draw it accordingly.

Context Diagram: capture the interactions

5: Now document the additional sources you’ve already listed and their data flows. Determine for each of the remaining sources if it does something different from the source(s) already placed on your diagram. If a source initiates the same input into the process as a previous source, group them. Otherwise, place it into its own box and draw the data flow. Repeat until all sources are off your list.

Context diagram: document the additional sources you’ve already listed and their data flows.

6: Identify and document additional external entities and don’t forget about entities which need data from the process being studied. Use nouns to indicate who these entities are (Example: “Credit Bureau”). Draw their inputs and outputs. Don’t worry if you don’t know all of these. Capture whatever you can and move on to the next step.

Context diagram: Identify and document additional external entities

7: Identify and document high-level events. For each context diagram, brainstorm these by asking, “How could a source interact with this process?” Document these events on the margin of your context diagram. High-level events will be used as inputs.

8: Capture additional requirements. If you happen to discover a requirement during the creation of a context diagram, be sure to note it either in your requirements document (be sure to note its source as the context diagram) or in a separate requirements repository designed specifically for requirements unearthed from the creation of context diagrams.

If you are not already including context diagrams as a routine part of your requirements discovery and analysis, you are missing a key tool in your arsenal for ensuring a project’s success. Context diagrams are powerful tools for eliciting facts about a process are system. However, to be effective, they must be created for their intended purpose, include their own inherent characteristics, and not be confused with use cases, flowcharts, or similar tools. When used as intended, context diagrams are a potent tool for ensuring a project’s success.

More on Context Diagrams:

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at



[3] Ibid.

[4] Ibid.




Rate this:


Posted on Tuesday, June 15, 2010 10:08 AM by
This is HIPO with a thin disguise.

No--it's not use cases. It's process-centric rather than goal-centric; it's looking out from inside instead of in from outside. Great for classical batch job processes.

It puts a presumptive design in context rather than putting the service in context. It doesn't know whether it's a component diagram, an object diagram, or a collaboration diagram.

It does all the things we've been trying lose for the last two decades.

We adopted use cases (or user stories--same bed, different side) because anything that's not justified by a use case is not needed; no one will ever notice it's missing. This is essential analysis at its finest.

Use cases can be presented at a high level, without all the details, to put a project goal in context. I did a job for Border Services where we started by defining the two business use cases: Enter Canada and Bring Goods into Canada. We "put in context" a major project on one page of pictures and text.

Posted on Tuesday, June 15, 2010 2:59 PM by
Great article. However, I have found that in the real world, Context Diagrams are scarce. I once worked at a very large corporation that taught Context Diagrams to everyone short of the janitorial staff. I also had a chance to review the requirements specs for a large number of software projects for this company.

So how many Context Diagrams did I uncover? Answer: Zero!

A big reason for a lack of Context Diagrams is that they are supposed to rely on a pure top-down approach to analysis. Problem: Nobody is, at the start of the project, knowledgeable enough to proceed in a top down fashion.

A workable solution is to first create some lower level data flow diagrams and then summarize them upwards into a context diagram.

Posted on Wednesday, June 16, 2010 12:23 PM by
I use context diagrams to define the scope of the project. By showing the system under consideration with its interfaces to external systems and actors.

As mentioned, it is unlikely that one will be able to identify a completed context diagram up front, what I do is build the context from use cases.

The use case is captured by the symbol representing the system, and actors are added as external entities communicating wit the system. The relationship with the actor is replaced by data flows defining the information that is passed between the actor and the system.

As the use cases are created, the context diagram may be updated until the complete scope of the project interfaces has been defined. By defining the interfaces you have defined the scope of the requirements. Anything outside of the context diagram may be declared out-of-scope for the project.

Useful for helping to prevent scope creep.

Posted on Wednesday, June 16, 2010 6:39 PM by

I can not find mention of the fact that it is unlikely that one will be able to identify a completed context diagram up front. Can you tell me where it is at in the article?

Anyways, you are right saying that a pure top-down approach is unlikely. (I would say almost never happens.) A rare comment from real down-in-the-trenches experience!!!

A context diagram is a top-level data flow diagram. So why not create one by first creating lower level diagrams vs lower level use cases? There is a huge difference between use cases and data flow diagrams. With use cases, the analyst never knows if he/she is done with analysis. This a BIG problem in ultimately creating a context diagram. Only data flow diagrams have a built-in lithmus test of completedness.


Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at, simply follow us on Twitter:

Featured Digital Library Resources 

Big Data Analytics for Dummies
Finally, a Big Data book written for business analysts, BI professionals, and data scientists!  Big Data Analytics for Dummies is a valuable resource that addresses the practical dilemmas surrounding Big Data...

A Buyer’s Guide to Customer Analytics
Discover the five crucial criteria of a customer analytics platform in A Buyer’s Guide to Customer Analytics now.

Free Analytics software: Alteryx Project Edition
Alteryx Project Edition provides you with a single solution that delivers the data blending, analytics, and sharing capabilities of Alteryx with just enough allowed runs of your workflow to solve one business problem or to complete one project.

The Business Analyst's Guide to Hadoop
Get started with Hadoop using this whitepaper, "The Business Analyst's Guide to Hadoop".

Copyright 2006-2013 by Modern Analyst Media LLC