HKSM

A context diagram is a high-level visual model that shows a system or product as a single entity and illustrates how it exchanges information with external actors. It clarifies the scope boundary and interfaces without showing internal processes or sequencing.

Key Points

• Shows the system as a single box with external entities around it.
• Uses labeled arrows to depict inputs and outputs crossing the system boundary.
• Clarifies what is inside scope versus external to the system.
• Does not show internal workflow, timing, or data transformations.
• Supports early stakeholder alignment and interface discovery.
• Provides a baseline for requirements, integration planning, and risk identification.

What the Diagram Shows

A context diagram presents a one-page view of the system-of-interest and how it interacts with the outside world.

• The system boundary, typically shown as a single box.
• External entities such as users, organizations, devices, or other systems.
• Information flows that cross the boundary, each with a clear name.
• Direction of exchanges, including bidirectional flows when needed.
• Optional notes on constraints or interface protocols at a high level.

How to Construct

• Confirm purpose and scope from the charter, vision, or problem statement.
• Define the system-of-interest and draw its boundary as a single box.
• Identify external actors using the stakeholder list, process maps, and interviews.
• Place external entities around the system and draw directional flows; label flows with concise nouns.
• Remove internal steps or data stores to keep the diagram at level 0 detail.
• Validate flows and boundaries with subject matter experts and key stakeholders.
• Version-control the diagram and reference it in requirements and risk discussions.

Inputs Needed

• Project charter, vision statement, and problem/opportunity summary.
• Stakeholder register and roles/responsibilities information.
• Existing process maps, current-state diagrams, and service blueprints.
• Interface catalogs, API/connection specifications, and contract requirements.
• Policies, regulations, and standards impacting interfaces and data.
• Elicitation outputs from workshops, interviews, and observations.

Outputs Produced

• Approved context diagram artifact (image or modeling file).
• List of external entities and interfaces to be managed.
• Defined scope boundary with included and excluded elements.
• Assumptions, open questions, and constraints about interfaces.
• Identified integration risks and initial mitigation ideas.
• Candidate interface and data exchange requirements.

Interpretation Tips

• Check that every arrow crossing the boundary is labeled with a clear noun (e.g., "Order data").
• Treat a two-headed arrow as two distinct flows; verify both are required.
• If internal subprocesses or sequences appear, it is no longer a context diagram.
• Use it as a conversation aid; details go into interface specs and data models.
• Keep the diagram simple; excessive entities may signal unclear scope.
• Update the diagram when scope, stakeholders, or interfaces change.

Example

For a Service Request System, the diagram shows the system at the center and these external entities:

• Customer: submits request data and receives confirmation/status updates.
• Support Agent: receives assigned requests and sends resolution notes.
• Notification Service: receives message content and returns delivery status.
• Payment Provider: receives payment authorization data and returns approval/decline.
• Reporting Platform: receives aggregated metrics for analytics.

Arrows are labeled with nouns such as "Request details," "Status update," "Authorization," and "Metrics," with directions showing who sends and who receives.

Pitfalls

• Including internal process steps or data stores that belong in detailed models.
• Overloading the diagram with minor entities instead of grouping them logically.
• Using vague or verb-only labels on arrows, creating ambiguity.
• Embedding technology specifics too early, limiting design options.
• Overlooking non-human actors like devices, services, or regulators.
• Failing to revise the diagram after scope or integration decisions change.

PMP Example Question

A project manager needs to align stakeholders on scope and external interfaces before defining detailed requirements. Which artifact should the team create?

1. Context diagram
2. User story map
3. RACI matrix
4. Schedule network diagram

Correct Answer: A — Context diagram

Explanation: A context diagram shows the system boundary and interactions with external entities, which is ideal for scoping and interface alignment before detailed requirements.