A Context Diagram is the highest-level Data Flow Diagram for a system. It shows the entire system as a single process (labeled 0 or 0.0) surrounded by the external entities that interact with it, connected by labeled data flows. It is sometimes called a Level-0 DFD or Context-Level DFD and is always the first diagram produced in structured systems analysis.
A Context Diagram is a deliberately simplified, one-page picture that answers a single question: "What is inside the system we are building, and what is outside?" It defines the system boundary explicitly and enumerates every external party that supplies data to the system or consumes data from it.
Unlike deeper DFD levels, a Context Diagram contains:
It deliberately excludes:
Context Diagrams emerged alongside DFDs from the structured analysis movement of the late 1970s:
Both notations are still in widespread use; selection is a matter of team or tooling preference.
Level 0 (Context Diagram) ─────── The entire system as ONE process.
│ External entities only. No data stores.
▼
Level 1 (System-Level DFD) ────── 5-7 major sub-processes that make up the
│ system. Data stores appear here for the first time.
▼
Level 2 (Sub-process DFDs) ─────── Each Level-1 process decomposed into its
│ constituent steps. Balance with parent required.
▼
Level 3+ (Further decomposition) ─ Rare; reserved for algorithmically complex
processes that need additional elaboration.
The Context Diagram is produced first, before any other structured-analysis artifact. It anchors every later decision about scope, requirements, and architecture.
Context Diagrams are intentionally stakeholder-friendly. A single page with a few labeled boxes and arrows is readable by:
A Context Diagram uses only three of the four standard DFD symbols. Data stores are deliberately omitted.
0 or 0.0 to mark it as the root of the decomposition hierarchyCustomer, Payment Gateway, RegulatorOrder Request, Payment Authorization, Shipment Status| Element | Why Excluded |
|---|---|
| Data stores (D1, D2, ...) | Stores are an internal implementation concern; they appear only when the single process is decomposed at Level 1. |
| Internal processes (1.1, 1.2, ...) | The whole point of Level 0 is to abstract away internal structure. |
| Control flow / decisions | DFDs in general model data, not control. A Context Diagram is purely about what crosses the boundary. |
| Sequencing or timing | Use a sequence diagram, activity diagram, or BPMN for temporal behavior. |
| Implementation details | Protocols, databases, languages, and hosting are deliberately invisible at this level. |
The two dominant notations differ only in the shape used for the process. Every other symbol is identical.
YOURDON / DeMARCO NOTATION | GANE-SARSON NOTATION
==================================|=================================
1. SYSTEM PROCESS (Process 0) | 1. SYSTEM PROCESS (Process 0)
___________ | ╭─────────────╮
/ \ | │ 0 │
/ 0 \ | │ Order Mgmt │
| Order Mgmt | | │ System │
\ System / | ╰─────────────╯
\___________/ |
| (Rounded Rectangle)
(Large Circle) |
|
2. EXTERNAL ENTITY | 2. EXTERNAL ENTITY
┌─────────────┐ | ┌─────────────┐
│ Customer │ | │ Customer │
└─────────────┘ | └─────────────┘
|
(Rectangle, same in both) | (Rectangle, same in both)
|
3. DATA FLOW | 3. DATA FLOW
───── Order Request ─────▶ | ───── Order Request ─────▶
|
(Labeled arrow, same) | (Labeled arrow, same)
|
4. DATA STORE | 4. DATA STORE
** NOT USED AT LEVEL 0 ** | ** NOT USED AT LEVEL 0 **
KEY DIFFERENCES:
• Yourdon/DeMarco: process is a CIRCLE
• Gane-Sarson: process is a ROUNDED RECTANGLE
• Both treat external entities and flows identically
• Pick one per project and use it consistently
An e-commerce system must accept orders from customers, charge a payment gateway, and hand packages to a shipping carrier. At Level 0 we do not care how it does this — only that those three interactions exist.
┌──────────────────────┐
│ Customer │
└──────────┬───────────┘
│
Order Request │ Order Confirmation
Account Signup │ Shipment Tracking
▼ │ ▲
│ │ │
│ ▼ │
┌─────────────────────────────────────────┐
│ │
│ 0 │
│ E-Commerce Ordering System │
│ │
└─────────────────────────────────────────┘
▲ │ ▲ │
│ │ │ │
Auth │ │ Charge │ Shipment │ Tracking
Result │ │ Request │ Request │ Number
│ ▼ │ ▼
┌─────────────────┐ ┌────────────────────┐
│ Payment Gateway │ │ Shipping Carrier │
└─────────────────┘ └────────────────────┘
EXTERNAL ENTITIES:
• Customer — places orders, receives confirmations
• Payment Gateway — authorizes and captures card payments
• Shipping Carrier — accepts packages, returns tracking numbers
DATA FLOWS (boundary crossings):
IN: Order Request, Account Signup, Auth Result, Tracking Number
OUT: Order Confirmation, Shipment Tracking, Charge Request,
Shipment Request
Everything else — the product catalog, inventory, order database, user accounts, pricing engine — is hidden inside the single process and will surface only when we draw the Level-1 DFD.
0 or 0.0. If you find yourself drawing a second process, you are already at Level 1.Order Request, not Send Order.Order Request and Cancellation Request as two arrows rather than folding them into one generic Order Input.Payment Authorization, not HTTP POST /authorize.| Check | What to Verify |
|---|---|
| One process | Exactly one bubble is drawn, numbered 0 or 0.0. |
| No data stores | No parallel-line symbols anywhere on the diagram. |
| Flows are labeled | Every arrow has a noun-phrase label. |
| Entities are connected | No orphaned external entities. |
| Boundaries are sharp | Every party you depend on is either "in" (part of the process) or "out" (an external entity) — never ambiguous. |
| Stakeholder sign-off | Business sponsors and architects have explicitly agreed to the scope shown. |
Once the Context Diagram is signed off, the next step is functional decomposition: opening the single process and showing the major sub-processes that implement it. This produces the Level-1 DFD.
0 decomposes into 1.0, 2.0, 3.0, ... (or 1, 2, 3, ...).D1, D2, D3, ...0 must now terminate at exactly one of its children.Flow balancing is the single most important consistency constraint when decomposing a Context Diagram. It states:
The set of data flows crossing the boundary of a parent process must be exactly the set of data flows crossing the outer boundary of its decomposition.
In concrete terms:
Order Request arriving at process 0, then the Level-1 DFD must show Order Request arriving at exactly one sub-process — no more, no fewer.Shipment Tracking leaving the system, the Level-1 DFD must produce that same flow from exactly one sub-process.Balancing is checked manually or with a CASE tool. Breaking balance is one of the most common and most damaging mistakes in DFD modeling because it silently hides requirements or invents them.
CONTEXT DIAGRAM (Level 0) LEVEL-1 DFD (decomposition of 0)
───────────────────────── ─────────────────────────────────
Customer ── Order Request ──▶ 1.0 Receive Order
┌──────────┐ │
│ Customer │── Order ─▶ │ Order Details
└──────────┘ Request ══▶ ▼
2.0 Validate Order
┌──────────┐ │
│ Customer │◀── Order │ Valid Order
└──────────┘ Confirm ▼
3.0 Fulfill Order
│
0 │ Order Confirmation
┌───────────────┐ ▼
│ E-Commerce │ Customer
│ System │
└───────────────┘ D1 - Orders D2 - Customers
Balancing: the single "Order Request" flow at Level 0 becomes the single
input arrow to process 1.0 at Level 1. The single "Order Confirm" output
at Level 0 is produced by process 3.0 at Level 1. External entity
"Customer" is preserved.
A university library operates a Library Management System that serves three external entities: members (who borrow and return books), librarians (who manage the catalog and enforce policy), and suppliers (who sell new titles to the library).
┌──────────────┐
│ Member │
└──────┬───────┘
│
Loan Request │ Loan Receipt
Return Notice │ Overdue Notice
│ Reservation Confirm
▼ │ ▲
│ │ │
│ ▼ │
┌───────────────────────────────────┐
│ │
│ 0 │
│ Library Management System │
│ │
└───────────────────────────────────┘
▲ │ ▲ │
│ │ │ │
Catalog │ │ │ │ Purchase
Update │ │ │ │ Order
│ ▼ │ ▼
┌───────────────┐ ┌─────────────────┐
│ Librarian │ │ Supplier │
└───────────────┘ └─────────────────┘
│ │
Policy Report Invoice /
Inventory Report Book Shipment
EXTERNAL ENTITIES
• Member — borrows and returns books; reserves titles
• Librarian — manages catalog, enforces lending policy, receives reports
• Supplier — fulfills book purchase orders, sends invoices and shipments
FLOWS CROSSING THE BOUNDARY
IN: Loan Request, Return Notice, Reservation Request,
Catalog Update, Invoice, Book Shipment
OUT: Loan Receipt, Overdue Notice, Reservation Confirm,
Policy Report, Inventory Report, Purchase Order
Notice what is not on this diagram: the catalog database, the member-records database, the overdue-fine calculation engine, the email server that sends notices. All of those are internal and will surface at Level 1.
Documenting these decisions on or next to the Context Diagram is itself a form of scope documentation.
An online banking platform is a substantially more regulated system. Its Context Diagram must capture not only customers and payment networks but also external regulators and fraud-detection services.
┌────────────────┐
│ Customer │
└────────┬───────┘
│
Login Credentials│ Account Balance
Transfer Request │ Transaction Receipt
Bill Payment │ Statement
▼
▲ │ ▼
│ │ │
┌─────────────────────────────────┐
│ │
│ 0 │
│ Online Banking System │
│ │
└─────────────────────────────────┘
▲ ▲ ▲ ▲
│ │ │ │
│ │ │ │
ATM/Card │ Fraud│ Wire│ Regulatory
Auth │ Score│ Msg │ Report
│ │ │ │
▼ ▼ ▼ ▼
┌───────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────────┐
│ ATM / Card │ │ Fraud │ │ Payment │ │ Regulatory │
│ Network │ │ Detection │ │ Network │ │ Reporting │
│ │ │ Service │ │ (SWIFT) │ │ System │
└───────────────┘ └────────────┘ └────────────┘ └──────────────┘
EXTERNAL ENTITIES
• Customer — account holder using web/mobile channels
• ATM / Card Network — authorizes debit/credit card transactions
• Fraud Detection Service — scores transactions in real time
• Payment Network (SWIFT) — settles interbank transfers and wires
• Regulatory Reporting — consumes compliance reports (SAR, CTR, etc.)
FLOWS CROSSING THE BOUNDARY
IN: Login Credentials, Transfer Request, Bill Payment,
ATM/Card Auth Result, Fraud Score, Wire Settlement Status
OUT: Account Balance, Transaction Receipt, Statement,
ATM/Card Auth Request, Transaction Snapshot (to fraud),
Wire Instruction, Regulatory Report
0.| Mistake | Why It Is Wrong | How to Fix |
|---|---|---|
| Showing data stores | Stores describe internal state and do not exist at Level 0. Drawing them leaks implementation into scope. | Remove the stores. They belong on the Level-1 DFD that decomposes process 0. |
| Showing internal processes | More than one process bubble means you are already at Level 1 and have defeated the purpose of the diagram. | Collapse the bubbles into a single process and move the detail to a separate Level-1 DFD. |
| Unlabeled data flows | An arrow without a name does not specify what crosses the boundary and cannot be validated with stakeholders. | Add a noun-phrase label to every arrow. If two labels collide, reroute or duplicate the entity. |
| Missing external entities | A stakeholder or upstream/downstream system that actually interacts with the platform has been forgotten, creating hidden scope. | Walk every use case, every legal/regulatory obligation, and every integration point to enumerate every party. |
| Entity-to-entity arrows | External entities do not communicate through the system if the system is not involved. Drawing that flow is out of scope. | Either remove the flow or, if the system really does mediate it, route it through process 0. |
| Verb-phrase flow labels | Send Order describes behavior rather than data. It confuses "what" with "how". |
Rewrite as a noun phrase: Order Request, Order Confirmation, etc. |
| Implementation-specific labels | HTTP POST /orders or Kafka topic orders.v1 couples the diagram to technology that may change. |
Use logical names: Order Request. Transport and format belong in interface specifications. |
| Vague system name | The System or Platform does not tell the reader what is being modeled. |
Use the business name: Order Management System, Online Banking System, etc. |
| Mixing notations | Circles and rounded rectangles on the same diagram confuse readers familiar with either convention. | Choose Yourdon/DeMarco or Gane-Sarson and apply consistently across the project. |
| Too many entities (20+) | The diagram becomes unreadable and suggests the system is actually several systems. | Group related entities (e.g., all regulators into one box) or split the system into multiple subsystems, each with its own Context Diagram. |
| Drift from Level 1 | Level-1 DFD shows external entities or flows not present on the Context Diagram (balance broken). | Re-balance: either update the Context Diagram to reflect the new scope or remove the unauthorized additions from Level 1. |
Context Diagrams are simple enough to draw by hand on a whiteboard, but most teams use a tool for version control and reuse.
@startuml
left to right direction
actor Customer
rectangle "Payment Gateway" as PG
rectangle "Shipping Carrier" as SC
usecase "E-Commerce\nOrdering System\n(0)" as SYS
Customer --> SYS : Order Request
SYS --> Customer : Order Confirmation
SYS --> PG : Charge Request
PG --> SYS : Auth Result
SYS --> SC : Shipment Request
SC --> SYS : Tracking Number
@enduml
This is not strictly DFD notation, but it captures the topology and is easy to maintain in source control.
The Context Diagram is a root artifact: many later deliverables are derived from it, and changes to it ripple through the rest of the project.
0 becomes the parent of the Level-1 DFD.Order Request → use case Place Order).Order Request → Order, OrderLine, Customer).Customer is both external and a persistent entity).Dn should correspond to a coherent cluster of ERD entities.The Context Diagram is the Level-0 DFD — the smallest, simplest, and most important diagram in structured analysis. It shows the entire system as a single process, enumerates the external entities that interact with it, and labels every data flow crossing the boundary. It deliberately excludes data stores, internal processes, timing, and implementation detail.
Key Takeaways: