DRAFT — under teacher review.

Context Diagram

Hamilton College · Year 12 · 2026

A context diagram is the highest-level view of your software system: one shape for the whole system, the external entities it talks to, and the named data flows between them. Nothing inside, nothing extra. It is the diagram that defines the scope of what you are building — and it is the foundation every later diagram (Level-1 DFD, use case) must stay consistent with.

Watch first (≈5 min total)

Mark O'Meara (Geelong High School) — 1½-min VCE-targeted revision. Frames the context diagram as a Level 0 DFD using the Yourdon-DeMarco notation you'll use in C2-2. Watch for: one circle in the middle, entities outside, no internals.

Christopher Kalodikis (Maximum Education, HSC) — 3-min overview building the intuition. Watch for: the purpose (showing inputs/outputs at a glance), why every external entity must have at least one labelled flow, and what counts as "external".

Why a context diagram

Think of it as a satellite view of your software. You can see the system's outline and everything crossing its boundary, but not what's happening inside.

It does four jobs:

Defines scope — what's part of your system, and what isn't
Identifies stakeholders — every external entity that interacts with the system
Visualises data exchanges — every input and output, named
Anchors later diagrams — your Level-1 DFD must show the same entities and flows

If you can't draw a clean context diagram for your project, you don't yet know what you're building.

The three elements

Element	Symbol	Rules
The system	One circle (Yourdon-DeMarco)	Exactly one — the whole system. Named after the system itself (e.g. Sales Order System, Library Loans).
External entities	Rectangles outside the circle	People, organisations, or other systems that interact with yours. Examples: Customer, Administrator, Payment Gateway, Email Server.
Data flows	Labelled arrows	Every arrow names the specific data crossing the boundary. Direction shows whether data goes in or out.

What's not allowed on a context diagram:

More than one process circle (that's a DFD — see Context Diagram vs Data Flow Diagram)
Data stores (no parallel-line rectangles at this level)
Arrows between two entities (every flow must touch the system circle)

Worked example: Sales Order System

          ┌───────────┐
          │  Managers │
          └─────┬─────┘
                │ New Employee ▼     ▲ Employee Lists
                │                    │ Vendor & Product-vendors
                │                    │
                ▼                    │
        ┌──────────────────────────────────┐
        │                                  │
        │     ( Sales Order System )       │
        │                                  │
        └──────────────────────────────────┘
           ▲          │             │  ▲
           │          │             │  │ Order Invoices
   Updates │          │ Customer    │  │
   Employee│          │ Order &     │  │ Order &
   Product │          │ Order-line  │  │ Order-line
   & Cat.  │          ▼             │  │
        ┌──┴────────┐         ┌─────┴──┴─┐
        │ Employees │         │ Customers │
        └───────────┘         └───────────┘

Read it like this:

The system (centre): Sales Order System
External entities: Managers, Employees, Customers — all rectangles outside the circle
Data flows:
- Managers → System: New Employee
- System → Managers: Employee Lists, Vendor and Product-vendor info
- Employees → System: Updates Employee, Product and Category
- Customers → System: Customer details, Order and Order-line
- System → Customers: Order Invoices

Notice what is not shown: how the system stores employees, how it validates an order, how it produces an invoice. Those are internal — they belong on the Level-1 DFD, not here.

How to draw one

Name the system. What are you building? That name goes inside the single circle.
List external entities. Who or what interacts directly with the system? Include only direct interactions — if Entity A only talks to Entity B (and never to your system), A doesn't belong here.
Name every data flow. Walk through each entity in turn: what specific data does it send in? What does the system send back? Use specific labels ("payment details", not "information").
Check completeness. Every entity should have at least one arrow connecting it to the system. Every arrow should be labelled. No entity should connect directly to another entity.

Most common mistakes

Drift toward a DFD — adding a second circle (e.g. "Verify User") inside the system. If there's more than one circle, it's no longer a context diagram.
Unlabelled arrows — "data" or "info" is not a label. Name the actual data.
Entity-to-entity arrows — every flow must touch the system. If two entities exchange data without your system involved, that exchange isn't on this diagram.
Missing entities — forgetting downstream systems (email server, payment gateway, reporting tool) that your system sends data to.
Inventing detail — showing data stores or internal logic. Save those for the Level-1 DFD.

Self-check

Test yourself before moving on. Answers in your notes, not on the page.

Which of these is not a component of a context diagram? (a) process · (b) entity · (c) data flow · (d) data store
In a context diagram, which statement is correct? (a) Entities can connect directly to other entities · (b) Data flows can only connect entities to the system process · (c) Multiple processes can be shown · (d) All flows must be unidirectional
You're drawing a context diagram for a Library Management System. How should "borrowing a book" appear? (a) An entity labelled "Borrowing" · (b) A process inside the system · (c) A data flow labelled "Book borrowing request" from Borrower to the system · (d) A rectangle showing the book collection