Home A - Z
Page Index

An Otter Wiki

Blame

e15de9 lisa 2026-04-30 07:50:48
C02: add 4 new pages closing remaining wiki gaps Closes the original 8-gap audit by consolidating into 4 pages (parallel sonnet build): - Building Your C2-1 Poster — poster structure + labelled raw-data artefact + findings-to-SRS mapping (covers gaps 2, 3, 4) - Data Flow Diagram (Level-1) — standalone DFD page with mermaid worked example, mirrors Context Diagram and UCD pattern (gap 1) - User Stories and MoSCoW — three-part formula + MoSCoW matrix + user-story-to-method-choice pipeline (gap 6) - Hand-Drawing Cheat-Sheet — cross-cutting notation reference for hand-drawn versions of all 3 diagrams; right-vs-wrong tables (gap 5) Plus enhancement (gap 7): - Data Collection Methods: new 'Qualitative or quantitative?' section with same-project two-data-point comparison and decision rule C02-home updated with both new C2-1 pages, the new DFD page, and the cheat-sheet — restructured order so each section reads in pedagogical order.
1 
> **DRAFT** — under teacher review.
2
3
# Data Flow Diagram (Level-1)
4
5
Hamilton College · Year 12 · 2026
6
7
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.
8
9
> [!TIP]
10
> 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.
11
12
---
13
14
## Why a DFD / what it shows
15
16
Think of the relationship between your context diagram and your Level-1 DFD as the difference between a **satellite view** and a **floor plan**.
17
18
- The **context diagram** (Level 0) shows the building's outline and everything crossing its boundary — nothing inside.
19
- The **Level-1 DFD** opens the roof and shows the rooms (processes), the filing cabinets (data stores), and the corridors connecting them (data flows).
20
21
It does four jobs:
22
23
- **Decomposes the system** — the single context-diagram circle becomes 3–6 numbered processes
24
- **Reveals data storage** — shows where your system persists data (databases, tables, files)
25
- **Traces data transformations** — every process takes in data and produces *different* data out
26
- **Maintains consistency** — entities and flow names must match your context diagram exactly
27
28
::: info
29
**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.
30
:::
31
32
---
33
34
## The four elements
35
36
| Element | Symbol | Rules |
37
|---|---|---|
38
| **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). |
39
| **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. |
40
| **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. |
41
| **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. |
42
43
::: warning
44
**Three connections that are never allowed**
45
46
- **Entity ↔ Entity** — two external entities cannot exchange data directly on this diagram
47
- **Data store ↔ Data store** — data cannot move between stores without passing through a process
48
- **Entity ↔ Data store** — an entity cannot read from or write to a store directly; data always flows through a process first
49
50
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.
51
:::
52
53
---
54
55
## Worked example: Sales Order System
56
57
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.
58
59
```mermaid
60
flowchart LR
61
M[Managers]
62
E[Employees]
63
C[Customers]
64
65
P1(("1. Manage\nEmployees"))
66
P2(("2. Manage\nProducts"))
67
P3(("3. Process\nOrder"))
68
P4(("4. Generate\nInvoice"))
69
70
DS1[("Employee\nRecords")]
71
DS2[("Product\nCatalogue")]
72
DS3[("Orders")]
73
74
M -->|new employee details| P1
75
P1 -->|employee record| DS1
76
DS1 -->|employee list| P1
77
P1 -->|employee lists| M
78
79
E -->|product & category info| P2
80
P2 -->|product record| DS2
81
DS2 -->|product list| P2
82
83
C -->|customer details & order| P3
84
P3 -->|order record| DS3
85
DS3 -->|order data| P4
86
P2 -->|product pricing| P3
87
P4 -->|invoice| C
88
```
89
90
**Read it like this:**
91
92
- **Processes** (numbered circles): *1. Manage Employees*, *2. Manage Products*, *3. Process Order*, *4. Generate Invoice*
93
- **External entities** (rectangles): *Managers*, *Employees*, *Customers* — identical to the context diagram
94
- **Data stores** (cylinders): *Employee Records*, *Product Catalogue*, *Orders*
95
- **Selected data flows to trace:**
96
- **Managers → P1**: *new employee details*
97
- **P1 → Employee Records**: *employee record* (write)
98
- **Employee Records → P1**: *employee list* (read — a separate arrow back)
99
- **P1 → Managers**: *employee lists* (output back to manager)
100
- **C → P3**: *customer details & order*
101
- **P3 → Orders**: *order record*
102
- **Orders → P4**: *order data*
103
- **P4 → C**: *invoice*
104
105
> [!IMPORTANT]
106
> 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.
107
108
---
109
110
## How to draw one
111
112
1. **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.
113
114
2. **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. …*).
115
116
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.
117
118
4. **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.
119
120
5. **Validate against the rules.** See the quality check below before moving on.
121
122
::: success
123
**Quality check before you move on**
124
125
- Every process has **at least one input *and* one output**? ✓
126
- Every process label is a **numbered verb-noun phrase**? ✓
127
- Every data store has at least one flow **in** and one flow **out**? ✓
128
- **No entity↔entity, no store↔store, no entity↔store** connections? ✓
129
- Every arrow has a **specific** label (not *"data"* or *"info"*)? ✓
130
- All arrows are **unidirectional** — two-way data = two separate arrows? ✓
131
- **Entity names match** your context diagram exactly? ✓
132
133
Seven ticks → your DFD is ready for the validation.
134
:::
135
136
---
137
138
::: danger
139
**Most common DFD mistakes**
140
141
1. **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.
142
2. **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.
143
3. **Direct entity-to-data-store connection.** Data must pass through a process first. An arrow from *Customer* directly to *Orders* is a notation error.
144
4. **Store-to-store flow.** Data cannot travel between two stores without a process in between.
145
5. **Double-headed arrows.** Each direction of data flow is a separate, labelled, single-headed arrow.
146
6. **Unlabelled or vague arrows.** *"info"* or *"data"* is not a label. Name the actual data (*"login credentials"*, *"order confirmation"*).
147
7. **Inconsistent entities.** If your context diagram says *"Year 7 Student"*, your DFD must say *"Year 7 Student"* — not *"Student"* or *"User"*.
148
:::
149
150
---
151
152
## Check Your Understanding
153
154
Answer in your head first, then click the spoiler to check.
155
156
**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?
157
158
>! **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.
159
160
**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?
161
162
*(a) One double-headed arrow between Customer and the Orders data store*
163
*(b) One double-headed arrow between Customer and the relevant process*
164
*(c) Two separate single-headed arrows between Customer and the relevant process, each labelled differently*
165
*(d) A single arrow labelled "orders (in and out)"*
166
167
>! **(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.
168
169
**3.** Which of these connections is **allowed** on a Level-1 DFD?
170
171
*(a) Customer → Orders (data store)*
172
*(b) Orders (data store) → Product Catalogue (data store)*
173
*(c) Process 2 → Orders (data store)*
174
*(d) Customer → Employee (entity)*
175
176
>! **(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.
177
178
**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?
179
180
>! **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.
181
182
---
183
184
## See also
185
186
- [Context Diagram](Context%20Diagram.md) — Level 0; the entities and flows here must be consistent with your DFD
187
- [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — side-by-side comparison of what appears on each level
188
- [Use Case Diagram](Use%20Case%20Diagram.md) — the third C2-2 analytical diagram; actors must match entities across all three
189
- [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed DFD canvas for rehearsing before the timed validation
190
- [Essential Terms](Essential%20Terms.md) — definitions of *process*, *data store*, *data flow*, *external entity*
191
192
---
193
194
← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)