Chapter 2.

Context Diagrams and Use Cases

Background
The System Engineering Process
Note that the reading and study from SE5341 Weeks 3 through 5 should be done before the material in this

applied.

System Lifecycles
After reviewing the systems engineering process, but before we dig into context diagrams and use cases, let’s

take a very brief look at a systems life cycle. Systems engineers represent life cycles in several ways. Organizations in

both government/military and industry frequently use customized views to represent the system life cycle in ways that

are particularly meaningful for their operating environment. For example, the U. S. Department of Defense has different

life cycle models for hardware intensive systems (programs), defense unique software intensive systems, incrementally

fielded software intensive programs, and yet, there is great commonality across system life cycle views. The INCOSE

view of a generic system life cycle can be found in the SEBoK Part 3, Introduction to Life Cycle Processes, Generic Life

Cycle Model linked here: https://www.sebokwiki.org/wiki/Generic_Life_Cycle_Model. The SEBoK also shows more

detailed life cycle views in Life Cycle Models section that start here: https://www.sebokwiki.org/wiki/Life_Cycle_Models

A key task for systems engineers, is to document a shared understanding of a systems scope. This is done during

the early phases of the SE process, after project organization and as part of the analysis work needed to document

system requirements. Because many systems engineering and analysis projects encompass existing systems and

processes, understanding the current state of a system of interest (SOI) is vital to troubleshooting problems and must be

accomplished as part of the analytical process for designing future state(s) for the SOI.

As part of documenting this shared understanding, system engineers must first identify all the external entities

including external databases, other external systems, humans, robots, and other devices that interact with the System of

Interest (SOI). System engineers also identify actors and services associated with the SOI. By properly helping create and

document this shared understanding of a project or systems scope, SE’s facilitate efficient and effective actions to

troubleshoot or upgrade existing systems and influence the design of new systems.
 Two of the commonly used frameworks to help the systems engineer define and subsequently communicate a

common view of a system are context diagrams and use case diagrams, which originated in software engineering. Over

time, these frameworks have evolved and been adapted for use across multiple disciplines, with many becoming core

concepts in the practitioner’s library including use in the Project Management Institute Project Management Body of

Knowledge (PMBOK®) Guide and the International Council on Systems Engineering (INCOSE) Systems Engineering Body

of Knowledge (SEBOK) and its associated Guide.

Context Diagrams

Webster defines context as “The interrelated conditions in which something exists or occurs” (merriam-

webster.com/dictionary/, 2021). The word stems from the Latin contexere which means to weave or join together.

Thus, a good context diagram will reveal, by weaving together, the SOI and its interrelated systems. A context diagram

is a specific type of data flow diagram (DFD) and sometimes you may see it referred to as a Context DFD, Context Level

DFD, or even a Level 0 DFD. They are all the same thing. For our purposes, the context diagram will be used to define a

system at its highest level (see Exercise 2.1) but as a specialized type of DFD, context diagramming can be done at lower

levels of a system.

Notation
To create a context diagram, start with a circle, square, or rectangle and label it to represent the SOI in the

center of your drawing. Traditionally, a circle has been used but a square or rectangle works equally well. Next, draw and

label each system the SOI interfaces, then connect the SOI with these interfacing systems with lines. The objective is to

show the systems operating environment and define its associated boundaries. The example in Figure 2.2 shows a

simple security control system in the center rectangle. There are four interfacing systems with two having flows both to

and from the control.

A context diagram can be built without showing data flows. In some cases, during the first iterations of a context

diagram, we may not know all the flow(s) with sufficient precision to accurately populate the diagram. In other cases,

power for example, it is not data or information that is represented by the flow, but simply some form of alternating or

direct current. What is important is building the relationships between the SOI and interfacing systems. Flows, if needed,

can be added as the drawing evolves into its final version.

 Figure 2.2. A good context diagram shows the system boundaries. (Source: Shawn Smith)

Constraints
It is tempting to add relationships to a context diagram because we want to provide additional details that more

completely inform those viewing the diagram. Figure 2.3 shows the addition of a dotted line (a relationship) between

the power source and the output siren. This seems to add an important element to the diagram, after all the siren won’t

work without power! Yet, this line, this additional information is beyond the scope of the context diagram and thus

should not be added to the diagram. The only relationship between the control and the output is a signal from the

control that turns the siren on or off.

 Figure 2.3. The relationship between the power source and siren is outside the scope of this diagram.

If we wanted to show the relationships the power system has with its interfacing systems using a context

diagram it would look like Figure 2.4.

Figure 2.4. The SOI is always at the center of the context diagram. (Source: Shawn Smith)

Relationship to Lower Level DFDs

It was noted earlier that the context diagram is the top level view of a system with a focus on interfacing

systems and boundaries. There are frequent requirements for lower-level diagrams that show increasing detail. One way

to approach this kind of a requirements is to create a DFD for each system that interfaces with the SOI, much like what

was done with the example in Figure 2.4, in a sense making the interfacing system the SOI. Doing this is straightforward

and may provide the additional details needed. In most cases, it also creates some amount of needless redundancy. An

alternative to creating a DFD for each system is to take a process-related approach and create the Context Diagram by

decomposing each relationship. For example, we may have many different types of sensors. All are designed to detect

something but for a lower-level diagram we would differentiate between a sensor that senses only motion (an infra-red

sensor) and one that senses motion and the distance to the movement. For the context level diagram one relationship is

acceptable. Lower diagrams might show multiple relationships, one for each type of sensor used in the system. The

approach is similar for service systems, we would decompose based on service processes.

Summary

• Context diagrams show the relationships between a single system and other external systems as a single

process.

• They are useful to identify system boundaries and interfaces.

 • Should be easily understood ‘at a glance’. Non-technical audiences should be able to quickly grasp the scope and

boundaries of the SOI.

Use Cases
Once a context diagram has been developed, we should understand the system well enough to begin developing

use cases. Like context diagrams, use cases had their beginning in software analysis but have been leveraged across

technical and non-technical disciplines because they offer a method to organize and clearly depict how an end user

intends to use the system. The phrase “use case” has many meanings, making it a polyseme, and thus creates a situation

where ambiguity can creep into the analysis. However, with a good context diagram in hand, we have quite literally set

the context for the use cases and can confidently proceed with creating these views of how users intend to use the SOI.

Uses
In Figure 2.5 we add users to the context diagram for our security system and we can see there could be at least

two uses. One is programming the alarm control. The other is using the system e. g., arming and disarming the system.

Each of these would be depicted as a separate use case in a use case diagram. The user for these two uses could be one

and the same (a homeowner for example) OR there could be two different users. The user who programs the control on

behalf of the homeowner and the homeowner with controls how the system is used. What if the homeowner had a

tenant? The use case for the tenant could be the same as for the homeowner in the arm/disarm use case but may be

different, depending on how much control the Homeowner wants to delegate to the Tenant. So, while these additions

to the Context Diagram shows several relationships in Figure 2.5, there are at 8 use cases that might be developed, 9 if

the Power Source is counted. The revised system scope shown in Figure 2.5 is an example of a Level 1 DFD, which is one

level lower than the Level 0 Context Diagram. We will build use cases for the Homeowner and Programmer based on this
 revised diagram.

Figure 2.5. Several Specific Types of Users are Added.

Notation
Once use cases are identified we use Unified Modeling Language (UML) (Object Management Group, 2017) or

System Modeling Language (SysML) (Object Management Group, 2019) notation to build out the drawings. While UML is

heavily used in software engineering, SysML is designed for systems engineering with SysML adopting notation and

syntax based on a subset of UML 2.5. This is an important relationship because it enables systems engineers using SysML

and software engineers using UML 2.5. to share information and collaborate more easily.

Use cases start with nodes and paths which include specific shapes and icons that shows how a user interacts

with the SOI. Note that users are frequently other systems which is allowed per UML which defines an Actor as “…a role

played by a user or any other system that interacts with the subject” (Object Management Group, 2017). Examples of

the six most common SysML notations are shown in Table 1.1.
Table 1.1. Six Common UML Notations

Node Description
An oval with the use case name
Use Case
UseCase

A stick figure

Actor

A rectangle with the subject name

SubjectName
Subject

Path Description
A single line
Communications

A dotted line with the word include

inside double < >
Include
<<include>>

A dotted line with the word extend

inside double < >
Extend
<<extend>>
 In Figure 2.6. three top-level use cases are identified and documented.

Figure 2.6. Top-Level Use Cases for the Security Alarm System. (Source: Shawn Smith)

As we further decompose the use case, the way the Homeowner uses the system becomes clearer as shown in

Figure 2.6. The use case of Tenant Acknowledges New Code extends or supplements the behavior of the Change Tenant

Code use case. The three <<include>> use cases are all part of the usual process of the Homeowner operating the alarm

system. Other use cases for the Tenant, Programmer, Thief, Power System and so on can be defined in a similar manner

as what has been done for the Homeowner use case in Figures 2.6 and 2.7.
Figure 2.7. Lower-level use cases reveal additional details. (Source: Shawn Smith)

Constraints
The notations discussed here are those notations that are the most basic and most frequently used. Using

<<include>> and <<extend>> should be done carefully because, for example, the including use case must depend on

results from the included use case. In the alarm system use case shown in Figure 2.7, the acknowledgement of the new

code by the tenant is a result of changing the tenant code, a use case initiated by the Homeowner.

In some cases, sufficient detail may be provided by using only the communications type path. Frequently, the Extend

and Include relationships are dependent on how a systems engineer approaches documenting the use case. This is one

reason why defining use cases should done by individual systems engineers in only the simplest situations. For more

complex use cases, expect to iterate through the process several times while using a thorough peer review process that

includes input from actual users.

Summary
• Start with a top-level use case and derive additional, more detailed use cases from it.

• Included (<<include>>) use cases should always be part of the normal operation of the system.

• Extending (<<extend>>) use cases (see Tenant Acknowledges New Code in Figure 2.6) supplement, or expand,

the process of the extended use case.

• Sometimes, only the communications path is needed to show relationships between an Actor and a Use Case.

• Always include actual users (to the maximum extent practical for the project) in developing and documenting

use cases.
 References
Merriam-webster.com/dictionary. (2021, April 21). Retrieved from merriam-webster.com: https://www.merriam-

webster.com/dictionary/context

Object Management Group. (2017). OMG Unified Modeling Language (OMG UML) version 2.5.1. Object Management

Group. Retrieved from https://www.omg.org/spec/UML/2.5.1/PDF

Object Management Group. (2019, November 1). OMG Systems Modeling Language (OMG SysML) version 1.6.