Professional Documents
Culture Documents
INTRODUCTION:
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.
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.
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.
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
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 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.
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 3
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.
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.
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 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.
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 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?
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?
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?
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 7
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.
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 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:
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 9
Yourdon, E. and Constantine, L.L. (1979). Structured Design: Fundamentals of a Discipline of Computer
Program and Systems Design. Prentice Hall.
ii
iii
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