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
4d8191 lisa 2026-04-30 07:56:26
Data Flow Diagram: add Mark O'Meara DFD videos as Watch first Pairs the same author's 1.5-min revision clip with the 8-min purpose/conventions overview — students new to DFDs work through the longer one first; revision uses the short clip.
14
## Watch first (≈10 min total)
15
16
{{Video|src=https://www.youtube.com/watch?v=DXjr63VFiik}}
17
18
*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.*
19
20
{{Video|src=https://www.youtube.com/watch?v=IDJeqOdIbeI}}
21
22
*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.*
23
24
---
25
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.
26
## Why a DFD / what it shows
27
28
Think of the relationship between your context diagram and your Level-1 DFD as the difference between a **satellite view** and a **floor plan**.
29
30
- The **context diagram** (Level 0) shows the building's outline and everything crossing its boundary — nothing inside.
31
- The **Level-1 DFD** opens the roof and shows the rooms (processes), the filing cabinets (data stores), and the corridors connecting them (data flows).
32
33
It does four jobs:
34
35
- **Decomposes the system** — the single context-diagram circle becomes 3–6 numbered processes
36
- **Reveals data storage** — shows where your system persists data (databases, tables, files)
37
- **Traces data transformations** — every process takes in data and produces *different* data out
38
- **Maintains consistency** — entities and flow names must match your context diagram exactly
39
40
::: info
41
**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.
42
:::
43
44
---
45
46
## The four elements
47
48
| Element | Symbol | Rules |
49
|---|---|---|
50
| **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). |
51
| **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. |
52
| **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. |
53
| **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. |
54
55
::: warning
56
**Three connections that are never allowed**
57
58
- **Entity ↔ Entity** — two external entities cannot exchange data directly on this diagram
59
- **Data store ↔ Data store** — data cannot move between stores without passing through a process
60
- **Entity ↔ Data store** — an entity cannot read from or write to a store directly; data always flows through a process first
61
62
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.
63
:::
64
65
---
66
67
## Worked example: Sales Order System
68
69
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.
70
71
```mermaid
72
flowchart LR
73
M[Managers]
74
E[Employees]
75
C[Customers]
76
77
P1(("1. Manage\nEmployees"))
78
P2(("2. Manage\nProducts"))
79
P3(("3. Process\nOrder"))
80
P4(("4. Generate\nInvoice"))
81
82
DS1[("Employee\nRecords")]
83
DS2[("Product\nCatalogue")]
84
DS3[("Orders")]
85
86
M -->|new employee details| P1
87
P1 -->|employee record| DS1
88
DS1 -->|employee list| P1
89
P1 -->|employee lists| M
90
91
E -->|product & category info| P2
92
P2 -->|product record| DS2
93
DS2 -->|product list| P2
94
95
C -->|customer details & order| P3
96
P3 -->|order record| DS3
97
DS3 -->|order data| P4
98
P2 -->|product pricing| P3
99
P4 -->|invoice| C
100
```
101
102
**Read it like this:**
103
104
- **Processes** (numbered circles): *1. Manage Employees*, *2. Manage Products*, *3. Process Order*, *4. Generate Invoice*
105
- **External entities** (rectangles): *Managers*, *Employees*, *Customers* — identical to the context diagram
106
- **Data stores** (cylinders): *Employee Records*, *Product Catalogue*, *Orders*
107
- **Selected data flows to trace:**
108
- **Managers → P1**: *new employee details*
109
- **P1 → Employee Records**: *employee record* (write)
110
- **Employee Records → P1**: *employee list* (read — a separate arrow back)
111
- **P1 → Managers**: *employee lists* (output back to manager)
112
- **C → P3**: *customer details & order*
113
- **P3 → Orders**: *order record*
114
- **Orders → P4**: *order data*
115
- **P4 → C**: *invoice*
116
117
> [!IMPORTANT]
118
> 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.
119
120
---
121
122
## How to draw one
123
124
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.
125
126
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. …*).
127
128
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.
129
130
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.
131
132
5. **Validate against the rules.** See the quality check below before moving on.
133
134
::: success
135
**Quality check before you move on**
136
137
- Every process has **at least one input *and* one output**? ✓
138
- Every process label is a **numbered verb-noun phrase**? ✓
139
- Every data store has at least one flow **in** and one flow **out**? ✓
140
- **No entity↔entity, no store↔store, no entity↔store** connections? ✓
141
- Every arrow has a **specific** label (not *"data"* or *"info"*)? ✓
142
- All arrows are **unidirectional** — two-way data = two separate arrows? ✓
143
- **Entity names match** your context diagram exactly? ✓
144
145
Seven ticks → your DFD is ready for the validation.
146
:::
147
148
---
149
150
::: danger
151
**Most common DFD mistakes**
152
153
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.
154
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.
155
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.
156
4. **Store-to-store flow.** Data cannot travel between two stores without a process in between.
157
5. **Double-headed arrows.** Each direction of data flow is a separate, labelled, single-headed arrow.
158
6. **Unlabelled or vague arrows.** *"info"* or *"data"* is not a label. Name the actual data (*"login credentials"*, *"order confirmation"*).
159
7. **Inconsistent entities.** If your context diagram says *"Year 7 Student"*, your DFD must say *"Year 7 Student"* — not *"Student"* or *"User"*.
160
:::
161
162
---
163
164
## Check Your Understanding
165
166
Answer in your head first, then click the spoiler to check.
167
168
**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?
169
170
>! **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.
171
172
**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?
173
174
*(a) One double-headed arrow between Customer and the Orders data store*
175
*(b) One double-headed arrow between Customer and the relevant process*
176
*(c) Two separate single-headed arrows between Customer and the relevant process, each labelled differently*
177
*(d) A single arrow labelled "orders (in and out)"*
178
179
>! **(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.
180
181
**3.** Which of these connections is **allowed** on a Level-1 DFD?
182
183
*(a) Customer → Orders (data store)*
184
*(b) Orders (data store) → Product Catalogue (data store)*
185
*(c) Process 2 → Orders (data store)*
186
*(d) Customer → Employee (entity)*
187
188
>! **(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.
189
190
**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?
191
192
>! **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.
193
194
---
195
196
## See also
197
198
- [Context Diagram](Context%20Diagram.md) — Level 0; the entities and flows here must be consistent with your DFD
199
- [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — side-by-side comparison of what appears on each level
200
- [Use Case Diagram](Use%20Case%20Diagram.md) — the third C2-2 analytical diagram; actors must match entities across all three
201
- [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — pre-framed DFD canvas for rehearsing before the timed validation
202
- [Essential Terms](Essential%20Terms.md) — definitions of *process*, *data store*, *data flow*, *external entity*
203
204
---
205
206
← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)