Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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 ᅐxes)? 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.
A context diagram is a graphic design that clariᅐes 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]
The ᅐrst 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 ᅐow
diagrams. In this instance, the context diagram is a subset of a data ᅐow diagram with the context diagrams being
the simplest form of data ᅐow 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.
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
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 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.
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.
Data ᅐows, represented as arrows, are the connectors between the main process and the various external entities
and show data ᅐow among them. Again, an example is below.
Since a context diagram is somewhat high-level and focused Context Diagram pitfalls to avoid
on the context of the process at hand, it does not include any
information that is not directly related to that process’s Examine your context diagram to be sure
information that is not directly related to that process’s Examine your context diagram to be sure
straightforward system. This means that data sources, that none of the following were inadvertently
external communications, alternative scenarios, or anything included:
not part of the main function or system you are diagramming
does not need to be included. While these may be included in Internal actors who initiate data ᅐows or
a traditional ᅐowchart, they are extraneous to a context processes (as mentioned above, these
diagram. have no place in a context diagram)
Additionally, a context diagram will never show work ᅐows or “Black holes,” meaning many inputs into
actors who initiate data ᅐows (but it will show the direction of the process are depicted but no outputs.
the ᅐow). Context diagrams are not the same as use case
diagrams; they do not show the entire process with actors, etc. Or the converse, “miracles,” many outputs
They only show the process at hand in its context. come out of the process, but nothing
goes in
How do you create a context diagram?
“Isolated entities,” meaning external
You can create a context diagram by following eight entities are shown but not linked
straightforward steps. Because of the ᅐuid and transformative
nature of most context diagrams, a whiteboard may be the Entity-to-entity data ᅐows with no process
best tool to begin their creation. Once the diagram is more in between
concrete, it may become an artifact using Visio or some other
tool which supports context diagrams:
1: Using a white board or other ᅐexible 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 ᅐows. If they are suᅐciently complex, each of these sub-processes
may be decomposed into further sub-processes. This technique is topic for a later article on data ᅐow 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 identiᅐer
(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 ᅐrst source onto the diagram, and check it oᅐ your list.
(You will methodically add the other sources later.)
4: Next, capture the interactions between this ᅐrst 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.
5: Now document the additional sources you’ve already listed and their data ᅐows. Determine for each of the
remaining sources if it does something diᅐerent 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 ᅐow. Repeat until all sources are oᅐ your list.
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.
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 speciᅐcally 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 eᅐective, they must be created for their intended purpose, include
their own inherent characteristics, and not be confused with use cases, ᅐowcharts, or similar tools. When used as
intended, context diagrams are a potent tool for ensuring a project’s success.
Article: Putting Systems Analysis “Into Context” using the Context Diagram
Question: What is a Context Diagram and what are the beneᅐts of creating one?
Forum Post: Context Diagram: Bank ATM Example
Author: Morgan Masters is Business Analyst and Staᅐ Writer at ModernAnalyst.com, 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 http://www.ModernAnalyst.com
[1] http://www.pqsw.com/hjsasp/gn02.cfm?SI=43479230767&ID=921210469186
[2] http://en.wikipedia.org/wiki/System_context_diagram
[3] Ibid.
[4] Ibid.
[5] http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_18#The_Context_Diagram
[6] http://en.wikipedia.org/wiki/System_context_diagram
[7] http://www.pqsw.com/hjsasp/gn02.cfm?SI=43479230767&ID=921210469186
Posted in: Structured Systems Analysis (DFDs, ERDs, etc.), General Business Analysis
RELATED ARTICLES
When Good BAs do Bad Deᅐning Scope with Changeover strategy: Five reasons why you
Things Feature Levels and Better have one! need a business analyst
Events (Scope Part 2) as you move to the cloud
COMMENTS
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, diᅐerent side) because anything that's not
justiᅐed by a use case is not needed; no one will ever notice it's missing. This is essential analysis at
its ᅐnest.
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 deᅐning 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.
ajmarkos posted on Tuesday, June 15, 2010 2:59 PM
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
staᅐ. I also had a chance to review the requirements specs for a large number of software projects
for this company.
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 ᅐrst create some lower level data ᅐow diagrams and then summarize them
upwards into a context diagram.
Tony
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 ᅐows
deᅐning 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 deᅐned. By deᅐning the interfaces you have deᅐned the scope of the
requirements. Anything outside of the context diagram may be declared out-of-scope for the
project.
Les.
I can not ᅐnd 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 ᅐow diagram. So why not create one by ᅐrst creating lower
level diagrams vs lower level use cases? There is a huge diᅐerence between use cases and data ᅐow
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 ᅐow diagrams have a built-in lithmus
test of completedness.
Tony
ARTICLE/PAPER CATEGORIES
CoE/CoP for Business Analysts Data Analysis & Modeling Decision Management
Getting Started as a Business IIBA & BABOK Interviewing & Hiring Business
Systems Analyst Systems Analysts
Requirements Analysis (BABOK KA) Requirements Management and Salary Info for the Business
Communication (BABOK KA) Systems Analyst
SDLC, Process, and Methodologies Analytical and Problem Solving Security Analysis
Skills
Testing & Quality Assurance (QA) Tools Uniᅐed Modeling Language (UML)
Testing & Quality Assurance (QA) Tools Uniᅐed Modeling Language (UML)
Business Analysis Planning (BABOK Use Cases User Interface & Usability
KA)
Start Do
Start Do