Home A - Z
Page Index

An Otter Wiki

Context Diagram

The Hamilton and Alexandra 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.

Tip

Your C2-2 validation asks you to hand-draw a context diagram, a Level-1 DFD, and a use case diagram under timed conditions. The context diagram is the simplest of the three — but the entities and flows you choose here lock in what the other two must show. Get this one right and the rest become much easier.

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

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.

Worked example: Sales Order System

flowchart LR
    M[Managers]
    E[Employees]
    C[Customers]
    S(("Sales Order<br/>System"))

    M -->|New Employee| S
    S -->|Employee Lists| M
    S -->|Vendor & Product-vendors| M
    E -->|Updates Employee| S
    E -->|Product & Category| S
    C -->|Customer details| S
    C -->|Order & Order-line| S
    S -->|Order & Order-line| C
    S -->|Order Invoices| C

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
Important

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. Restraint is the diagram's whole point.

How to draw one

  1. Name the system. What are you building? That name goes inside the single circle.
  2. 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.
  3. 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").
  4. 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.

Check Your Understanding

Answer in your head first, then click the spoiler to check.

1. Which of these is not a component of a context diagram? (a) process · (b) entity · (c) data flow · (d) data store

(d) data store. Data stores belong on the Level-1 DFD, not the context diagram. At Level 0 the whole system is a single black box — its internal storage is hidden.

2. In a context diagram, which statements are correct? (select all that apply) (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

Both (b) and (d) are correct. (b) — Every arrow must touch the system circle. Entity↔entity flows are never allowed. (d) — Each data flow is a single-headed (unidirectional) arrow labelled with the data crossing that way. If data moves both ways between an entity and the system, you must draw two separate arrows (one each direction), each with its own label — not one line with arrowheads at both ends. Why (a) and (c) are wrong: (a) breaks the entity-to-system rule above; (c) describes a DFD — a context diagram has exactly one process circle (the whole system).

3. 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

(c) A data flow labelled "Book borrowing request" from Borrower to the system. Borrowing is an action, not an entity or a thing. On a context diagram, actions surface as labelled data flows. (b) would be a process — but the context diagram has only one process (the whole system).

See also