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
# Hand-Drawing Cheat-Sheet
4
5
Hamilton College · Year 12 · 2026
6
7
This page is your single reference for what every symbol should look like when drawn **by hand under timed conditions**. It does not re-teach concepts — it shows you the right shape, the wrong shape, and what gets crossed off by the marker.
8
9
> [!TIP]
10
> **The C2-2 stake.** The validation runs for a full lesson (~50 min) under locked conditions: no internet, no AI, no Excalidraw, no notes, no reference sheets. You draw all three diagrams — Context Diagram, Level-1 DFD, Use Case Diagram — from memory, for your own project. Band 9–10 requires *no errors, no inconsistencies, no omissions* across all three. One wrong shape or one unlabelled arrow and you cap at 7–8. This cheat-sheet is for **home practice only** — you cannot bring it to the validation.
11
12
---
13
14
## Context Diagram — Symbol Reference
15
16
### Shape key
17
18
| Symbol | What you draw | Rules |
19
|---|---|---|
20
| **System** | One circle in the centre, system name inside | Exactly **one** circle — the whole system is one shape |
21
| **External entity** | Rectangle, role name inside | All entities **outside** the circle |
22
| **Data flow** | Arrow with a label on the line | Every arrow must carry a **specific** data label |
23
24
### Right vs Wrong — Context Diagram
25
26
| Element | Correct | Common error |
27
|---|---|---|
28
| System shape | Clean circle, labelled with the system name | An oval squashed sideways, or a rectangle — the system must be a **circle** |
29
| Number of circles | Exactly one | Two circles (e.g. adding *"Verify User"* as a second circle) — that is a DFD, not a context diagram |
30
| Entity shape | Rectangle clearly outside the system circle | Rectangle drawn inside the circle — entities are always **outside** |
31
| Data flow label | *"Assignment submission form"* | *"data"* or *"info"* — these are not labels; name the actual data |
32
| Entity–entity arrow | Not present — all flows touch the system circle | Arrow drawn directly between two entities, bypassing the system |
33
| Data stores | Not present at context level | Double-line (data store shape) included — data stores do not exist at Level 0 |
34
35
### Canonical shape — mermaid
36
37
```mermaid
38
flowchart LR
39
E1[External Entity]
40
E2[External Entity]
41
S(("Your System\nName"))
42
43
E1 -->|specific data label| S
44
S -->|specific data label| E2
45
E2 -->|specific data label| S
46
```
47
48
::: warning
49
**Do NOT draw on a context diagram**
50
51
- A second circle (any internal process)
52
- Data stores (double-line shapes)
53
- Entity-to-entity arrows
54
- Arrows without labels
55
:::
56
57
---
58
59
## Level-1 DFD — Symbol Reference
60
61
### Shape key
62
63
| Symbol | What you draw | Rules |
64
|---|---|---|
65
| **Process** | Circle, numbered + verb-noun name inside | 3–6 circles; each needs ≥1 input AND ≥1 output |
66
| **External entity** | Rectangle — same names as context diagram | Never connect to a data store directly |
67
| **Data store** | Two parallel horizontal lines, name between them | At least one in AND one out flow; only connects to processes |
68
| **Data flow** | Arrow with a label | Every arrow must be labelled with the specific data |
69
70
### Right vs Wrong — Level-1 DFD
71
72
| Element | Correct | Common error |
73
|---|---|---|
74
| Process shape | Circle (round), with a number and verb-noun name | Oval so squashed it looks like a rectangle, or an actual rectangle — must be **clearly circular** |
75
| Process label | *"1. Verify Login"* | No number, or a noun only (*"Login"*) — processes need a number and a verb-noun phrase |
76
| Data store shape | **Two parallel horizontal lines** with a name between them | Plain rectangle without the second line — the double-line is what distinguishes a data store from an entity |
77
| Data store connections | Only to/from processes | Arrow from entity directly to data store — illegal; data must flow **through a process** first |
78
| Data store connections | Only to/from processes | Arrow from one data store to another — also illegal |
79
| Data flow label | *"student login credentials"* | Unlabelled arrow — every arrow on a DFD must have a label |
80
| Entity names | Exactly match the context diagram | *"User"* in the DFD vs *"Student"* in the context diagram — inconsistency costs marks |
81
| Every process | At least one input AND one output | A circle with only outputs (or only inputs) — a process must transform data |
82
83
### Canonical shape — mermaid
84
85
```mermaid
86
flowchart LR
87
E[External Entity]
88
P1(("1. Process\nName"))
89
P2(("2. Process\nName"))
90
DS[("Data Store")]
91
92
E -->|specific data| P1
93
P1 -->|stored data| DS
94
DS -->|retrieved data| P2
95
P2 -->|output data| E
96
```
97
98
::: warning
99
**Do NOT draw on a Level-1 DFD**
100
101
- Entity-to-data-store arrows (must go through a process)
102
- Data-store-to-data-store arrows
103
- A process with no input, or no output
104
- Unlabelled arrows
105
- Entity names that differ from your context diagram
106
:::
107
108
---
109
110
## Use Case Diagram — Symbol Reference
111
112
### Shape key
113
114
| Symbol | What you draw | Rules |
115
|---|---|---|
116
| **Actor** | Stick figure, **outside** the rectangle, role name below | Role name (e.g. *Teacher*), not a personal name; non-human systems are actors too |
117
| **Use case** | Oval, **inside** the system boundary rectangle | Verb-noun label: *"Submit Assignment"*, not *"Login Page"* |
118
| **System boundary** | Rectangle labelled with the system name | All use cases inside; all actors outside |
119
| **Association** | Solid line, actor ↔ use case | Every actor needs at least one |
120
| **«include»** | Dashed arrow, arrow points TO the included use case | Triggered **always**; arrow: base → included |
121
| **«extend»** | Dashed arrow, arrow points TO the base use case | Triggered **optionally**; arrow: extension → base |
122
123
### Right vs Wrong — Use Case Diagram
124
125
| Element | Correct | Common error |
126
|---|---|---|
127
| System boundary shape | **Rectangle**, labelled with the system name | Oval or circle as the boundary — the system boundary must be a **rectangle** |
128
| Actor position | Stick figure outside the rectangle | Stick figure drawn inside the rectangle — actors are **always external** |
129
| Use case position | Oval inside the rectangle | Oval outside the rectangle — use cases describe **your** system's functions |
130
| Use case label | *"Submit Quiz"* (verb-noun) | *"Quiz Submission Page"* or *"Database"* — labels must be action phrases |
131
| Actor label | Role name: *"Teacher"* | Personal name: *"Mr Smith"* — use the **role**, not the person |
132
| «include» arrow direction | Base use case → included use case | Arrow pointing the wrong way (included → base) — this is the most common mistake |
133
| «extend» arrow direction | Extending use case → base use case | Arrow pointing the wrong way (base → extending) |
134
| «include» / «extend» line style | **Dashed** line with the stereotype label | Solid line with no label — dashed + label is required |
135
| Association line | **Solid** line | Dashed line for a plain association — save dashed for «include»/«extend» |
136
137
### Canonical shape — mermaid
138
139
```mermaid
140
flowchart LR
141
A1(["👤 Actor A"])
142
A2(["👤 Actor B"])
143
144
subgraph SYS["Your System Name"]
145
UC1(["Use Case 1"])
146
UC2(["Use Case 2"])
147
UC3(["Use Case 3"])
148
end
149
150
A1 --- UC1
151
A1 --- UC2
152
A2 --- UC3
153
UC1 -.->|«include»| UC3
154
UC2 -.->|«extend»| UC1
155
```
156
157
*(In a hand-drawn version, actors are traditional stick figures. The mermaid icons above are just a stand-in.)*
158
159
::: warning
160
**Do NOT draw on a Use Case Diagram**
161
162
- Actors inside the system boundary rectangle
163
- A circle (oval) as the system boundary — boundary must be a **rectangle**
164
- «include» / «extend» arrows on solid lines
165
- «include» / «extend» arrows pointing the wrong direction
166
- Use case labels that are nouns only (*"Login Page"*, *"Database"*)
167
:::
168
169
---
170
171
## Arrow Direction Memory Aid
172
173
The «include»/«extend» arrows trip up nearly everyone. One rule covers both:
174
175
> **The arrow always points toward the use case that is being *used* or *added to*.**
176
177
| Relationship | Who initiates | Arrow direction | Reads as |
178
|---|---|---|---|
179
| **«include»** | Base use case (it needs the other one) | Base → Included | *"Base use case uses Included"* |
180
| **«extend»** | The optional extension | Extension → Base | *"Extension adds to Base"* |
181
182
Example:
183
- *Submit Quiz* **includes** *Validate Answers* → arrow: Submit Quiz → Validate Answers
184
- *Display Error* **extends** *Submit Quiz* → arrow: Display Error → Submit Quiz
185
186
---
187
188
## Before You Flip the Paper — Final Check
189
190
::: success
191
**Run through this list before you put your pen down.**
192
193
**Context Diagram**
194
- [ ] Exactly one circle, labelled with the system name
195
- [ ] All entities are rectangles, drawn outside the circle
196
- [ ] Every arrow has a specific data label
197
- [ ] No entity-to-entity arrows
198
- [ ] No data stores, no internal circles
199
200
**Level-1 DFD**
201
- [ ] 3–6 numbered processes (circles), each with a verb-noun label
202
- [ ] Every process has at least one input AND one output arrow
203
- [ ] At least one data store (two parallel lines, not a plain rectangle)
204
- [ ] No entity-to-data-store arrows
205
- [ ] No data-store-to-data-store arrows
206
- [ ] Every arrow labelled
207
- [ ] Entity names match the context diagram exactly
208
209
**Use Case Diagram**
210
- [ ] System boundary is a rectangle, labelled with the system name
211
- [ ] All actors (stick figures) are outside the rectangle
212
- [ ] All use cases (ovals) are inside the rectangle
213
- [ ] Actor labels are role names, not personal names
214
- [ ] Every actor has at least one solid association line
215
- [ ] At least one «include» (dashed, arrow to included use case)
216
- [ ] At least one «extend» (dashed, arrow to base use case)
217
- [ ] Arrow directions are correct for both «include» and «extend»
218
219
**Cross-diagram consistency**
220
- [ ] Entity and actor names are identical across all three diagrams
221
:::
222
223
---
224
225
## Check Your Understanding
226
227
Answer in your head first, then click the spoiler to check.
228
229
**1.** You're drawing a context diagram by hand and you've just drawn a second circle labelled *"Verify Login"* next to the main system circle. What's wrong?
230
231
>! A context diagram has **exactly one circle** — the whole system. Adding a second circle (like *"Verify Login"*) turns it into a DFD. Cross out the second circle; *"Verify Login"* belongs on your Level-1 DFD as a numbered process.
232
233
**2.** On your Level-1 DFD, you draw a data store as a rectangle with no second line because you're drawing quickly. How will the marker read it?
234
235
>! As an **external entity** — a plain rectangle is the entity shape. Without the second parallel line, the marker cannot distinguish it from an entity. The double-line is not optional; it is the notation. Draw it even when rushed.
236
237
**3.** You draw «extend» as a dashed arrow pointing FROM the base use case TO the optional extension. What mark does this attract?
238
239
>! This is a **notation error**. «extend» arrows point FROM the extending use case TO the base. The wrong direction means the marker reads your diagram as saying the base use case triggers the extension — the opposite of «extend» semantics. At 9–10 this is a credited error; it caps you at 7–8 or below.
240
241
**4.** Your context diagram shows *"Student"* as an entity. On your DFD you've written *"User"* for what is clearly the same person. Is this a problem?
242
243
>! Yes — it is a **named inconsistency**. The 9–10 band requires *"no errors, inconsistencies or omissions"*. Entity names must match across all three diagrams. Change *"User"* to *"Student"* on the DFD (and the UCD).
244
245
---
246
247
## See also
248
249
- [Context Diagram](Context%20Diagram.md) — concepts, worked example, and notation rules
250
- [Context Diagram vs Data Flow Diagram](Context%20Diagram%20vs%20Data%20Flow%20Diagram.md) — what can appear on each level
251
- [Use Case Diagram](Use%20Case%20Diagram.md) — the four relationships and arrow-direction rules
252
- [Excalidraw Diagram Starters](Excalidraw%20Diagram%20Starters.md) — skeleton canvases for pre-validation practice
253
254
---
255
256
← Back to [C02 Home](C02-home.md) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)