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.

---

{{Video|src=https://www.youtube.com/watch?v=PKWCogQ8v7U}}

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

{{Video|src=https://www.youtube.com/watch?v=fWNrc6GNK14}}

*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".*

---

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.

---

| 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](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md))

- Data stores (no parallel-line rectangles at this level)

- Arrows between two entities (every flow must touch the system circle)

---

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

---

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.

---

1. **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.

2. **Unlabelled arrows** — *"data"* or *"info"* is not a label. Name the actual data.

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

4. **Missing entities** — forgetting downstream systems (email server, payment gateway, reporting tool) that your system sends data to.

5. **Inventing detail** — showing data stores or internal logic. Save those for the Level-1 DFD.

---

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

1. Which of these is **not** a component of a context diagram?

*(a) process · (b) entity · (c) data flow · (d) data store*

2. 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*

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*

---

- [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — when you move to Level 1, what changes and what stays the same

- [What Is an Entity](What%20Is%20an%20Entity.md) — entities aren't only people; non-human systems count

- [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed canvases for rehearsing all three diagrams under timed conditions