Context Diagram

Definition

Context Diagram

a top-level requirements diagram that documents the external environment of a blackbox system:

• Application:
  • Software only application
  • System-level application containing both hardware and software
• Business Enterprise
• Business Facility
• Center:
  • Contact Center
  • Data Center
  • Reuse Center
• Component:
  • Hardware Component
  • Software Component
• Database
• Framework

Semantic Net Context Diagram

a context diagram drawn as a kind of semantic net showing the general relationships between the system and its externals

Data Flow Context Diagram

a context diagram drawn as a kind of data flow diagram showing the more detailed dataflows and object flows between the system and its externals

Objectives

The typical objectives of a context diagram is to document:

• The system as a blackbox hiding its interal parts
• The externals that interact with the system
• Either the:
  • General relationships between them (if a semantic net)
  • Detailed dataflows and object flows between them (if a data flow diagram)

Benefits

The typical benefits of a context diagram are to:

• Provide the context in which to discuss the system with its stakeholders.
• Clarify the boundary of the system, and thereby help determine and achieve consensus on what is in and out of scope.
• Help identify the interfaces between the system and its externals.
• Simplify and drive the analysis of the functional requirements.
• Provide a way to organize the resulting use case model (sorted by external type and external).

Contents

The typical contents of a context diagram are:

• Blackbox Deliverable Icon:
  • Business Enterprise.
  • Contact Center.
  • Data Center.
  • Application (system or software).
  • Framework.
  • Hardware Component.
  • Software Component.
• External Icons:
  • Roles (a.k.a., actors).
  • Teams.
  • Organizations.
  • Application (system or software).
  • Databases.
• Relationship Icons:
  • Inheritance and referential relationships between externals.
  • Referential relationships between externals and the blackbox.

Stakeholders

The typical stakeholders of a context diagram are:

• Producers:
  • Requirements Team
• Evaluators:
  • Requirements Inspection Team
    (typically during the evaluation of the system requirements specification)
• Approvers:
  • Project Manager
  • Technical Leader
  • Customer Representative
• Maintainers:
  • Requirements Team
• Users:
  • Architecture Team, which uses it to drive the system architecture.
  • Project Team, which uses it to understand the context of the work product being developed.

Phases

• Business Strategy: Completed for the:
  • Business Enterprise.
  • Contact Center(s) if produced to supporting multiple applications.
  • Data Center(s) if produced to supporting multiple applications.
• Business Optimization: Not Applicable
• Initiation: Completed for the:
  • Application during system or software application development.
  • Framework during framework development.
  • Hardware Component during reusable hardware component development.
  • Software Component during reusable software component development.
  • Contact Center(s) if necessary and not previously produced.
  • Data Center(s) if necessary and not previously produced.
• Construction: Maintained
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

Context diagrams can typially be started if the following preconditions hold:

• The business strategy phase or initiation phase has started.
• The requirements team is adequately staffed and trained in requirements analysis and requirements specification.
• The business vision statement and/or application vision statement have been started.

Inputs

The typical inputs to a context diagram include:

• Work Products:
  • Contract
  • Statement Of Work
  • Business Vision Statement
  • Application Vision Statement
  • Glossary
• Stakeholders:
  • Customer Representative(s)
  • Customer Organization Domain Experts (e.g., marketing personnel)
  • Developer Organization Domain Experts
  • Selected Users

Guidelines

• First draw top-level semantic net context diagram(s) for use when initially talking with stakeholders. Then follow this with more detailed data flow context diagram(s) for obtaining information about data flows and object flows.
• Use the following steps to draw context diagrams:
  1. Draw the node representing the system under discussion in the center of the drawing and label it with the name of the system.
  2. Select an external that directly interfaces with the system but has not yet been added to the context diagram. Select an icon for the external that clearly signifies the type of external (e.g., system, role, database). For semantic net context diagrams, place the icon for the external on the diagram so that it is above the system if the external depends on the system, below the system if the system depends on the external, or beside the system if they are peers of each other (this enables the reader to clearly see the flow of control). For data flow diagrams, similarly place the icon for the external on the diagram so that the general flow of data is clear to the reader. Label the node with the name of the external. To ensure that the icon is large enough to contain the name when manually drawing the context diagram on a whiteboard, write the label first and then draw the icon around it. When using a tool that makes it easy to move icons, you can wait until step 6 to worry about positioning the icons for externals.
  3. Use an arc to connect the external with the system. Use arrowheads to signify the direction of dependency (if a semantic net) or flow (if a data flow diagram). Label the arc with a meaningful verb phrase (if a semantic net) or the name of the data flow or object flow (if a data flow diagram). Use an appropriate arc style to differentiate data flows from object flows.
  4. Repeat steps 2 and 3 until all direct externals are included in the diagram.
  5. Where appropriate, repeat steps 2, 3, and 4 for any indirect externals (i.e., important externals that interact with the system only via other externals). Only add indirect externals if they provide the “context” needed to understand the system.
  6. Where appropriate, rearrange the nodes and arcs to maximize the readability of the context diagram.
  7. Decompose the context diagram if overly cluttered or complex.
  8. Incorporate the diagram into the appropriate documents.
  9. Properly label the diagram.
• One or more context diagrams are usually contained in the application vision statement and system requirements specification.
• The semantic net context diagram is similar to the data flow context diagram of Structured Analysis (SA), but its relationships are primarily referential (and therefore a kind of control flow) and in the direction of dependency, whereas the data flow context diagram relationships were primarily data flows and object flows that may or may not be in the direction of control flows.
• Notice that on semantic net context diagrams, the referential relationship arcs are labeled with an active verb phrase so that the reader can read a natural language sentence of the form: subject (the starting node), verb phrase (the relationship), and direct object (the ending node).
• Avoid using functional decomposition when creating data flow context diagrams as in Structured Analysis. The context of logical subfunctions is far less useful than the context of systems and subsystems.

Conventions

Context diagrams are typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• Inspection Checklist

Examples

Heating and Cooling System Context Diagram(s)

The following are two system context diagrams for a home heating and cooling system. The semantic net context diagram is on the left, and the corresponding data flow context diagram is on the right. Note that the semantic net version is at a much higher level of abstraction than the data flow version. Note also that the semantic net version answers the question “Why?” whereas the data flow version better answers the question “How?”

Digital Thermostat Software Context Diagram

The following semantic net context diagram documents the direct and indirect externals of a blackbox digital thermostat software application. Notice that the indirect externals are critical for understanding the context of the software, whereas the single direct external (the integrated chip) is of little interest except for reminding the architect that the software should be portable.

Electronic Auction System Context Diagram

The following system context diagram documents the externals (e.g., human actors, computers, networks, and gateway system) of a blackbox electronic auction system application. It uses the OML notation, which is more understandable than UML for context diagrams.