Article Context Diagrams

ProjectConnections.
com Technique Brief
INTRODUCTION:
Technique Brief Context Diagrams

Contributed by Alan Zimmerman, www.zimvision.com
The technique brief content starts on the following page.
What This Is
Context diagrams graphically depict a system's boundaries, the information that flows in and out of the
system, and the other systems and people that will use it and benefit from it. Representing the system as
a single black box process interacting with its environment, context diagrams provide a picture of project
scope.
Context diagrams can be very simple sketches or detailed graphical interface specifications, depending
on what you need for a given communication or interaction.
Why Its Useful

Any system exists in order to respond and provide services to the world around it. The context model
describes how the system relates to its business environment. It depicts the boundary, scope, and
benefits of the system in a simple, intuitive format that non-technical stakeholders can easily understand.
Context diagrams provide several additional benefits:
Careful determination of system boundaries helps limit costs, decrease development time,
and improve system analysis and design.
Clear communication of the system and its benefits to other systems and people will help you
enlist appropriate stakeholders.
Approaching the system from the top-most level will ensure that your analysis makes sense at
a high level before you invest time developing the details.
In some circumstances, a simple picture is a better way to rapidly gain clarity than a written
specification. Context models are the simplest of all modeling diagrams and are easy to sketch.
How to Use It
Use an appropriate level of detail for the circumstances. In a quick conversation with a stakeholder, show
only those details relevant to your discussion. When creating a comprehensive specification to begin your
system analysis, be sure to include all the details you can think of and use a rigorous naming convention.
Draw a circle and label it with the system name.
Around the circle, draw one rectangle for each external entity (source or destination of
information or control). These can be either external systems or people.
Draw the data and control events that flow between the system and the external entities. Use
solid arrows for data and dashed arrows for control events. Label each arrow in terms relevant to the
business. Stay at a high level. Arrows should only go in one direction.
Show the diagram to potential users and other stakeholders. Check it against your other
models. Refine the diagram as you adjust project scope and system requirements.
Use additional notation sparingly. Stick figures representing external user roles or rectangles
that group related diagram objects may be useful, but adding too much stuff to the diagram or using
clipart shapes instead of rectangles confuses people.
The technique brief content starts on the following page.
Copyright 2009 Emprend Inc. Permission for ProjectConnections.com Members use on their projects.
See our Terms of Service for information on PMO/group use and corporate subscriptions.
Page 1
ProjectConnections.com Technique Brief


INTRODUCTION TO CONTEXT DIAGRAMS
Context diagrams resulted from work by Yourdon,
Constantinei, DeMarcoii and others in the late 1970s as part
of structured analysis and structured design methodology.
They were top-level data flow diagrams. Extended by Gane &
Sarsoniii and applied to real time systems by Ward & Melloriv,
they gained notation for depicting control flows, discrete-time
signals, and continuous-time signals. While venerable, they
retain their usefulness because of their simplicity.
Context diagrams show the proposed system in its
environment of external entities, exchanging data and control
information with those entities.
The system is shown as a simple, labeled circle (Yourdon
notation) or a rounded rectangle (Gane & Sarson notation).
No internal details are shown, not even major subsystems.
The focus is on the systems context, not the system itself.
External entities (sometimes called terminators) are sources
and sinks (destinations) of data and control information. They
are shown as simple rectangles. These can represent other
systems (Product Data Management System), external classes of users (Test Engineer), organizations
(Marketing), or hardware (Product Prototype). External entities typically are not operators of the
system nor are they implementation details like displays or keyboards. They should represent entities that
are important to the business, not implementation or architecture components.
Data flows represent information, objects, or physical items passing in and out of the system and are
drawn with solid arrows. Control flows represent signals or events that cause a change in system
behavior and are drawn with dashed arrows.
Ward & Mellor further extend the notation to use
double-headed arrows for continuous-time data (which,
like the level of chemical in a tank, is available all the
time) and single-headed arrows for discrete-time data
(which, like an order for more chemical, occurs only
when needed) but most drawing programs dont easily
support this notation. If its relevant to your system,
make the effort, but make sure your audience
understands and values the distinction.
RECOMMENDATIONS
Data and control flow names are important. Use names that are relevant and familiar to your business
stakeholders. In more formal diagrams used as part of your system analysis, the data and control flow
names are the first entries your data dictionary and should be traceable to objects in your data model or
signals in your hardware. But these internal names for data should not be used on the context diagram.
Use single-direction arrows only. Its easy to use the same arrow if similar data is flowing both to and
from the same entity. You just put an arrowhead at both ends. But this is misleading. A useful, non-trivial
system always transforms data in a meaningful way and never hands the same data back to the external
entity. If you find yourself with a bi-directional arrow, think more carefully about the data being exchanged
and come up with better, more evocative names for the two flows. For example, development engineers
both create change requests and respond to change requests. Rather than have one bidirectional arrow,
it is better to have two arrows. Each represents a unique system behavior and use case. What would you
call the two flows to differentiate them?
What you leave off is as important as what you include. If something is outside the scope of your
system, leave it off the diagram. For example, if your invoicing system generates billing information for the
Page 2

purchasing department instead of sending invoices directly to vendors, leave the vendors and invoices off
the diagram. Show the interaction with the purchasing department accurately. When your stakeholders
ask where the invoices actually are sent, then your discussion about system scope can begin.
Do not show data stores on context diagrams.
On data flow diagrams, data stores appear as two parallel lines and represent data at rest (in the sense
that flows are data in motion). Usually they only appear on lower-level data flow diagrams representing
internal processes. However, some authors advocate using them on context diagrams. We disagree. If
the database is part of the system, it is hidden inside the system boundary. If it is external to the system, it
is just another external entity. Because most data relevant at a system level is stored in databases with
their own API, administrators, and organizational stakeholders, they deserve the status of an external
system anyway.
Represent people as people.
Classes of users are common sources and sinks of data and control information. All systems have
customers. In all current notations these are represented as rectangles like any other external entity. But
consider using UML actor symbols instead. This has two advantages. 1) It makes it instantly obvious
where people are using and benefiting from the system; this has strategic political benefits to the savvy
project manager during stakeholder negotiations. 2) It allows you to correlate and cross-check your
context diagram to your top level use case diagram.
Sketch informal, partial context diagrams on the
spot, at every opportunity. This notation is so
simple; you can use it on whiteboards, spare copier
paper, or even on napkins as you discuss the
system with stakeholders. Drawing as you speak
engages your listener. Being able to quickly sketch
the system during a conversation greatly facilitates
understanding and demonstrates your command of
the subject matter.
Better yet, having your stakeholders draw the
diagram with you has several benefits:
It
helps you
requirements better.
understand
their
It increases their buy-in.
It is creates a shared work product early in the product cycle. Copy the resulting page or
photograph the whiteboard so that everybody has a take-away from the conversation.
Page 3

For example, if you are in a meeting with marketing &
manufacturing stakeholders, discussing how the use of a
Software Configuration Management system will benefit
both their departments, draw them a simple picture as you
describe how the system will guarantee that their feature
requests and bug reports will get implemented by the
engineering team. Theres no need to make them study the
complete and somewhat complex formal diagram in their
laps and certainly no need to use PowerPoint. Keep the
current version of the complete diagram handy if more
detail is required. (The full example diagram appears later
this brief.)
CREATING THE CONTEXT DIAGRAM

This section is a step-by step tutorial showing how to create the context diagram, using an example
software configuration management system.
Step 1: Choose the correct level of formality and complexity
As discussed above, sometimes a simple sketch is appropriate. On the other hand, having a carefully
maintained and accurate formal context diagram helps your systems analysts stay on track. You should
have one authoritative, up-to-date, and complete context diagram of your system at all times. Then,
sketch or draw simpler versions as the situation requires.
Step 2: Choose the correct symbols
Lets face it: circles, arrows, and rectangles are not visually exciting. Further, there are lots of clipart,
stencils, and symbols around to choose from that could easily add to the visual variety of your context
diagram. However, resist the urge to experiment. The symbols you use on the page carry tacit cultural
and personal connotations that each of your audience members will interpret slightly differently. You dont
want people making up their own information and adding it to your diagram at random. Stick to the simple,
boring, but unambiguous basics.
As suggested above, you might consider using UML actor symbols for classes of people interacting with
the system. However, if you are also using use case diagrams, be sure that these external entities are
directly related to your use case actors in some way or another. Visual and label similarity implies that
they are the same. If they are not, represent the external people as rectangles or re-factor your diagrams
to make them coherent.
Finally, be careful with color. Different hues and shades have different cultural connotations to different
people that may be inappropriate. Maintaining the same color, or even the same shade of gray, is always
a problem due to vagaries of display and printing technologies. Keep it simple.
Step 3: Draw the system
This step is easy. Draw a big circle in the center of the page and name it
something that everybody will recognize. Name the system for what it does
and avoid acronyms or abbreviations.
Example: Our example system is a software configuration management
system for a product development group. Enough stakeholders have been
referring to the proposed system as a change control system that, even
though change control is traditionally part of configuration management, those
words need to be incorporated somehow. Finally, there are several SCM
systems in the company, so this group has to be explicit.
Step 4: Identify external sources and sinks of data and control
Start by just listing all the external entities you can think of. Dont limit yourself. Think about all the
potential systems and people your new system will influence or affect. The farther away from the
anticipated automated system you look, the more useful and innovative your product is likely to be. v In
many drawing programs, its easy to create rectangles and label them, one after another. Arrange them
around the system in some reasonable fashion. While you should avoid listing such mundane interfaces
as keyboards and displays, do list devices that have business relevance when specifying physical
systems such as factory automation.
Page 4

In most cultures, diagrams show things flowing from left to right or top to bottom. If you have important
sources, place them on the left. Important destinations or consumers of data tend to go on the right. But
few external entities are only sources or only sinks. Data flows back and forth, so dont worry if things
arent simple. Place related entities near each other. Finally, some positions tend to have implicit
connotations: things along the bottom tend to be foundational or in a supporting role; things along the top
tend to be in control. But these are just guidelines.
Example: Many departments will use our SCM system:
Marketing will record feature
requests and monitor progress.
Project management will monitor

progress.
Design engineering will take

change requests and produce release
candidate file sets of both code and
documentation.
Test engineering will test releases

and submit bug reports.
An automated test harness will

build and test releases, annotating them
with the results of testing.
Product prototypes will load

releases and execute them.
Manufacturing will take tested

releases via their PLM system, read
release notes and other metadata, and
submit bug reports.
Technical Support will read release notes and documentation and submit bug reports.
Marketing will publish documentation, patches, and other downloads on the customer-facing
website.
System administrators will keep the system running and apply updates and patches from the
SCM system software vendor.
Step 5: Estimate top-level system functions or use cases

You create the context diagram while you are capturing and refining system requirements and as you are
creating system use cases. One activity does not precede the others. Notice that our example
descriptions of externals also include what people will do with the system and what data they will supply
or expect. Estimating this information about data and behavior is useful in preparation for determining the
data and control flows. (Note that you dont need to be using use cases for context diagrams to be of
value.)
Step 6: Draw the data and control flows
For each external entity, draw arrows for all the information that moves between the entity and the
system. Focus on the events and information that are important to the business, not necessarily data that
is available in convenient formats. For example, a business event named Customer unhappy is better
than Bug report submit form. By staying in problem space and focusing on what is going on in the
business context, you avoid prematurely setting the system boundary and locking yourself into an
inappropriate implementation.
Some events happen periodically, as a specific point in time. Indicate this in the name.
Control flows are relatively rare in non-real time business modeling. They are events that carry no
information other than that the event occurredlike an interrupt. Most events have additional information.
If your system is monitoring all the doors in the building, for example, a door opening is an event. Your
system needs to know which door opened, so this is should be modeled as a data flow rather than a
control flow.
Page 5

The same data rarely flows in and then out of the system without undergoing some transformation. That
transformation is the reason your system exists. Reflect this transformation in the names of the data
flows. In our example SCM system, Bug reports and Feature requests flow into the system from
various sources, but Change requests flow out to development engineers. In fact, all of these will be
implemented with a single data object.
Finally, dont worry about all this in the early stages. At every point in the process, put down what you
know, and revise and re-factor as you go. By seeing whats on the page, you will better understand what
you need to find out.
Example: At an early stage in the process, our context diagram has all data and control flows we can
think of, but there are questions.
What are the SCM System Administrators doing? Theres some indication that they are
important to the system (or they wouldnt be on the diagram) but we dont know what they need or
what they produce. Are they really external to the system at all?
Why does the Technical Writer only have data flowing out? What information does this role
need to do their job? Are they expected to check in their work or submit bug reports?
The Test Harness Automation Scripts apparently are triggered by a check-in event. Is there
other information required with this event, or does the Harness just go off and run the same tests
each time?
Are the Bug reports the Manufacturing Engineer generates really the same as the Bug
reports the Development engineer generates? Is the difference important to the system?
The Project Manager requires Status and produces Prioritizationthis is far too vague.
We need more details about what information this role needs and how it will use the system.
Page 6

Are the Release notes produced by the Development Engineer the same as the Release
Notes produced by the Technical Writer? Are these identical to those required by other externals?
Why is the Manufacturing Product Lifecycle Management System connection a one-way
street?
The system apparently needs to interface with Development Tools in addition to the
Development Engineer. Is this simply an inappropriate implementation interfacing detail or is this a
legitimate separate connection that deserves special mention on the context diagram?
Step 7: Annotate and organize the diagram

It may be useful to organize and arrange the external entities on the diagram to improve understanding.
Typical groupings include:
Externals that report to the same area of the organization chart
Externals that will be implemented in the same phase
Externals that have the same priority
This is also the time to try using UML actor symbols.

Example: Heres the SCM context diagram that well be using as we discuss the system with
stakeholders. The organizational groupings imply some new information, or at least new questions:
The Manufacturing group doesnt seem to be very connected to the system. Are there more
things we can do to provide benefits to them?
The IT group is responsible for the system itself and its proper operation. Are they really an
external entity? If not, how do we represent their requirements?
Where is the customer on this diagram? Is our vision of the system too internally focused?
What affect will a Product Development SCM system have on our ability to delight the customer and
how can we represent this?
Where is senior management on this diagram? What benefits does the system provide them?
What inputs can they provide? Where is the business value flowing on this diagram?
Page 7

Step 8: Validate and revise

The context diagram is only one of the models you use to describe the system. It must be compatible and
coherent with the other models.
Compare it with your use case diagrams. Are all of your use case actors represented in some
way by external entities?
Compare it with your use cases. Each data and control flow should participate in a use case.
Are there use cases that require information that is missing from your diagram?
Compare it with your data model. Does every flow correspond to one or more data objects?
In all these cases, there may not be a simple, one-to-one correspondence between items in one model
with items in another.
Most importantly, revisit the diagram and keep it up to date with every project iteration.
USING CONTEXT DIAGRAMS
A context diagram is useful to the project manager in several ways.
Communicating. Like all models, your context diagram is primarily a communication tool.
Print your context diagram on the biggest sheet of paper you can, take it out and show it to all your
stakeholders, scribble all over it, and revise it. Put it up on the wall of your projects war room. Sketch
parts of it every time you discuss the system.
Setting the system boundary. A systems boundary is rarely determined by technical

factors alone. Social, organizational, financial, or interpersonal factors can influence what is in scope
and what isnt. Trying different groupings on your diagram, using the right names for external entities,
and enumerating the data flowing in and out of your system can aid in understanding these factors.
Page 8

Identifying your dependencies. Any data source you dont control makes you dependent on
external, uncontrolled factors. Perhaps these should be brought inside the system boundary as a riskmitigation tactic. Perhaps you can delay the requirement to use troublesome data sources, or
eliminate them entirely.
Determining your development partners. External sources and sinks that cannot be
controlled, cannot be eliminated, and cannot be brought inside must still be managed. External data
sources are your supply chain. External consumers of data are your customers. Visit the key
stakeholders that represent each external entity and make sure you understand their point of view.
Negotiating scope to control budget and schedule. Every arrow translates into effort and
time. Perhaps some can be eliminated. Perhaps an internal data transformation or behavior can be
moved out of scope if the data is already available from an external source in the appropriate form.
Showing progress. Use shading, grouping, or animation to indicate which externals and
which data flows will be available at which project phase.
Breaking down the system into subsystems. Multiple instances of similar data might
indicate the need for a subsystem to handle that sort of data.
Controlling integration costs. Context diagrams enumerate the external systems that must
be integrated. Integration is troublesome and expensive. Minimize the external entities your system
has to interact with. On the other hand, the adjacent systems are why your systems exists; dont
throw the baby out with the bathwater.
Splitting up one product into several to form a product line. The diagram is a
generalization across the product line; not every system in the product may connect with all systems
or types of users shown in the diagram.vi
SUMMARY
Context diagrams use simple notation to depict critical information: how your system interacts with its
environment and the business benefits it provides. They are simple to sketch and clear to non-technical
viewers, making them useful during discussions with stakeholders. While one of the older modeling
techniques, context diagrams remain an excellent tool for communicating about projects and controlling
project scope, schedule, and budget.
ABOUT THE AUTHOR
Alan Zimmerman's 35-year career has included hardware and software engineering, system analysis and
business planning, project and functional management, technical writing, and training development and
delivery. And, along the way, he's thrown in a little rock-and-roll disk jockey and improvisational comedy
here and there. His research interests include the on-going maturation of the software engineering
profession and the intersection of business and software development processes. As owner of Pragmatic
Design Studio, he is using agile methods and web technologies to solve problems in traditionally underserved markets.
REFERENCES
Sommerville, I. (2004). Software Engineering Seventh Edition, Addison-Wesley
Roam, D. (2008), The Back of the Napkin, Solving Problems and Selling Ideas with Pictures, Penguin
Group, 2008
Wiegers, K. (2003). Software Requirements, Second Edition, Microsoft Press
References cited in the text:
Page 9
Yourdon, E. and Constantine, L.L. (1979). Structured Design: Fundamentals of a Discipline of Computer
Program and Systems Design. Prentice Hall.
ii
DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press
iii
Gane, C. and Sarson, T. (1979). Structured Systems Analysis. Prentice Hall
iv
Ward, P. and Mellor, S. ( 1986). Structured Development for Real-Time Systems, Volume 2: Essential
Modeling Techniques, Englewood Cliffs, NJ: Prentice Hall,
v
Robertson, S. and Robertson, J. (2006). Mastering the Requirements Process, Second Edition, Addison
Wesley Professional
A Framework for Software Product Line Practice, Version 5.0 (retrieved 2008-12-04)
http://www.sei.cmu.edu/productlines/frame_report/productLS.htm
vi

Article Context Diagrams

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Article Context Diagrams

Uploaded by

Copyright:

Available Formats

ProjectConnections.

com Technique Brief

Technique Brief Context Diagrams

Technique Brief Context Diagrams

The technique brief content starts on the following page.

Why Its Useful

Draw a circle and label it with the system name.

The technique brief content starts on the following page.

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

Technique Brief Context Diagrams

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

It increases their buy-in.

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

CREATING THE CONTEXT DIAGRAM

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

Project management will monitor

Design engineering will take

Test engineering will test releases

An automated test harness will

Product prototypes will load

Manufacturing will take tested

Step 5: Estimate top-level system functions or use cases

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

Why is the Manufacturing Product Lifecycle Management System connection a one-way

Step 7: Annotate and organize the diagram

Externals that report to the same area of the organization chart

Externals that will be implemented in the same phase

Externals that have the same priority

This is also the time to try using UML actor symbols.

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

Step 8: Validate and revise

Setting the system boundary. A systems boundary is rarely determined by technical

ProjectConnections.com Technique Brief

Technique Brief Context Diagrams

DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press

Gane, C. and Sarson, T. (1979). Structured Systems Analysis. Prentice Hall

You might also like