DRAFT — under teacher review.

Data Flow Diagram (Level-1)

The Hamilton and Alexandra College · Year 12 · 2026

A Level-1 DFD is the floor-plan view of your software: the single circle from your context diagram is split open to reveal the major processes inside, the data stores where information lives, and the labelled flows connecting everything. Every entity that appeared on your context diagram must reappear here — and no new ones should suddenly show up.

Tip

Your C2-2 validation is a rubric ladder: you need a working context diagram to score 3–4, and a working Level-1 DFD to reach 5–6. The DFD is the second rung. Getting the four notation rules right (see below) is what separates a 5–6 from a diagram that costs you that band.

Watch first (≈10 min total)

Mark O'Meara (Geelong High School) — 1½-min VCE-targeted revision. Watch for: numbered processes, data stores as parallel lines, and the rule that every flow goes through a process.

Mr O'Meara — 8-min purpose and conventions of a DFD (Yourdon-DeMarco notation). The longer companion to the revision clip — work through this one first if DFDs are new.

Why a DFD / what it shows

Think of the relationship between your context diagram and your Level-1 DFD as the difference between a satellite view and a floor plan.

The context diagram (Level 0) shows the building's outline and everything crossing its boundary — nothing inside.
The Level-1 DFD opens the roof and shows the rooms (processes), the filing cabinets (data stores), and the corridors connecting them (data flows).

It does four jobs:

Decomposes the system — the single context-diagram circle becomes 3–6 numbered processes
Reveals data storage — shows where your system persists data (databases, tables, files)
Traces data transformations — every process takes in data and produces different data out
Maintains consistency — entities and flow names must match your context diagram exactly

Why entities must stay the same. The VCAA rubric at 9–10 requires "no errors, inconsistencies or omissions". An entity labelled "User" on the context diagram but "Customer" on the DFD is an inconsistency — even if both diagrams are otherwise perfect. Use the exact same names throughout.

The four elements

Element	Symbol	Rules
Process	Circle (Yourdon-DeMarco)	Numbered verb-noun phrase (e.g. "1. Verify Login", "2. Save Order"). Must have at least one input and one output — and the output must differ from the input (the process transforms the data).
External entity	Rectangle	Same entities as your context diagram — same names, same roles. They sit outside the logic of the system and can only connect to processes.
Data store	Two parallel horizontal lines (or cylinder)	A named repository where data persists (e.g. "Orders", "User Accounts"). Must have at least one flow in and one flow out. Can only connect to processes.
Data flow	Labelled arrow	Carries the specific data moving between elements. Every arrow must be labelled (not "data" or "info"). All flows are unidirectional — one arrowhead, one direction.

Three connections that are never allowed

Entity ↔ Entity — two external entities cannot exchange data directly on this diagram
Data store ↔ Data store — data cannot move between stores without passing through a process
Entity ↔ Data store — an entity cannot read from or write to a store directly; data always flows through a process first

If data genuinely moves in both directions between two elements, draw two separate arrows, each with its own label — one for each direction. Never use a double-headed arrow.

Worked example: Sales Order System

The same Sales Order System from the context diagram page, now decomposed to Level 1. Three entities (Managers, Employees, Customers), four processes, three data stores.

flowchart LR
    M[Managers]
    E[Employees]
    C[Customers]

    P1(("1. Manage<br/>Employees"))
    P2(("2. Manage<br/>Products"))
    P3(("3. Process<br/>Order"))
    P4(("4. Generate<br/>Invoice"))

    DS1[("Employee<br/>Records")]
    DS2[("Product<br/>Catalogue")]
    DS3[("Orders")]

    M -->|new employee details| P1
    P1 -->|employee record| DS1
    DS1 -->|employee list| P1
    P1 -->|employee lists| M

    E -->|product & category info| P2
    P2 -->|product record| DS2
    DS2 -->|product list| P2

    C -->|customer details & order| P3
    P3 -->|order record| DS3
    DS3 -->|order data| P4
    P2 -->|product pricing| P3
    P4 -->|invoice| C

Read it like this:

Processes (numbered circles): 1. Manage Employees, 2. Manage Products, 3. Process Order, 4. Generate Invoice
External entities (rectangles): Managers, Employees, Customers — identical to the context diagram
Data stores (cylinders): Employee Records, Product Catalogue, Orders
Selected data flows to trace:
- Managers → P1: new employee details
- P1 → Employee Records: employee record (write)
- Employee Records → P1: employee list (read — a separate arrow back)
- P1 → Managers: employee lists (output back to manager)
- C → P3: customer details & order
- P3 → Orders: order record
- Orders → P4: order data
- P4 → C: invoice

Important

Notice that P1 reads back from Employee Records with a separate arrow — it does not use a double-headed arrow. Every read and every write is its own labelled flow. This is the most-tested notation rule in C2-2.

How to draw one

Start from your context diagram. Pull in the same external entities and the same flow names. The boundary of your DFD is the same boundary as your context diagram — you're just looking inside it now.
Identify 3–6 major processes. Each is a major function your system performs. Ask: "What are the key things my system actually does?" Name each with a verb-noun phrase and number them sequentially (1. …, 2. …, 3. …).
Add data stores. For every piece of data your system needs to remember across sessions or between processes, add a named data store. If your software saves nothing, you have no stores — but most SAT projects have at least one.
Map the data flows. Work systematically: for each process, ask "what data does this need as input, and what does it produce as output?" Label every arrow with specific data. Check that every entity flow from the context diagram has made it onto the DFD.
Validate against the rules. See the quality check below before moving on.

Quality check before you move on

Every process has at least one input and one output? ✓
Every process label is a numbered verb-noun phrase? ✓
Every data store has at least one flow in and one flow out? ✓
No entity↔entity, no store↔store, no entity↔store connections? ✓
Every arrow has a specific label (not "data" or "info")? ✓
All arrows are unidirectional — two-way data = two separate arrows? ✓
Entity names match your context diagram exactly? ✓

Seven ticks → your DFD is ready for the validation.

Most common DFD mistakes

One circle only — it's still a context diagram. A DFD must decompose the system into multiple numbered processes. If there's only one circle, you have not drawn a DFD.
Process with no output (or no input). A process that takes data in but sends nothing out is not transforming anything. Every process needs both sides.
Direct entity-to-data-store connection. Data must pass through a process first. An arrow from Customer directly to Orders is a notation error.
Store-to-store flow. Data cannot travel between two stores without a process in between.
Double-headed arrows. Each direction of data flow is a separate, labelled, single-headed arrow.
Unlabelled or vague arrows. "info" or "data" is not a label. Name the actual data ("login credentials", "order confirmation").
Inconsistent entities. If your context diagram says "Year 7 Student", your DFD must say "Year 7 Student" — not "Student" or "User".

Check Your Understanding

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

1. A Level-1 DFD has a process called "Save Record" with one arrow in ("new record" from an entity) and nothing going out. What is wrong?

The process has no output. Every process must transform data — it takes something in and produces something different out. "Save Record" should output something (e.g. "confirmation" back to the entity, or a "saved record" to a data store). A process with only an input arrow is not doing anything by DFD rules.

2. You need to show that a Customer can read their past orders and add a new order. How do you show both on the DFD?

(a) One double-headed arrow between Customer and the Orders data store (b) One double-headed arrow between Customer and the relevant process (c) Two separate single-headed arrows between Customer and the relevant process, each labelled differently (d) A single arrow labelled "orders (in and out)"

(c) Two separate single-headed arrows, each labelled. All data flows are unidirectional. If data moves in both directions, you draw two arrows — one for each direction — each with its own specific label (e.g. "new order" going in, "order history" coming out). Double-headed arrows are never valid in Yourdon-DeMarco notation.

3. Which of these connections is allowed on a Level-1 DFD?

(a) Customer → Orders (data store) (b) Orders (data store) → Product Catalogue (data store) (c) Process 2 → Orders (data store) (d) Customer → Employee (entity)

(c) Process 2 → Orders (data store). A process can write to (or read from) a data store — that is a valid and normal DFD connection. The other three all break the rules: (a) entity directly to a data store — not allowed; (b) store to store — not allowed; (d) entity to entity — not allowed.

4. Your context diagram shows entities "Homeroom Teacher", "Student", and "School Admin". On your Level-1 DFD you wrote "Teacher", "Learner", and "Admin". What rubric consequence does this have?

It is an inconsistency — and at 9–10, any inconsistency is disqualifying. The VCAA descriptor for 9–10 reads "no errors, inconsistencies or omissions". Mismatched entity names between diagrams is an inconsistency even if both diagrams are otherwise perfect. At 5–6 "some errors or omissions" are tolerated, so you would still score that band — but you cannot reach 9–10 with mismatched names. Always copy entity names exactly from your context diagram.