DRAFT — under teacher review.
Excalidraw Diagram Starters — C02
Hamilton College · Year 12 · 2026
Drawing from scratch each session costs 10–15 minutes of setup time and often produces inconsistent notation across the three diagrams. These Excalidraw starters give you pre-framed skeletons — correct shapes, correct labels — so you can focus on the content, not the canvas.
Start in Excalidraw, then practise hand-drawing from your finished version. The Excalidraw skeleton is the plan; your hand-drawn version under timed conditions is the performance.
Watch first (≈3 min)
Lvl 99 TechSkillz — beginner Excalidraw tour. Watch for: navigation and shape drawing (0:23), styling (0:38), and library/sharing basics. You only need the first 90 seconds for C02 — the rest is optional polish.
Why consistent notation matters
All three C02 diagrams use the same cast of external entities. If the entity is named "Student" on your context diagram, it must be named "Student" (not "User" or "Person") on your DFD. Starting from a shared canvas makes this consistency automatic.
The 9–10 rule. The rubric requires "no errors, inconsistencies or omissions" across all three diagrams. Inconsistent entity names between diagrams is a named inconsistency — even if both diagrams are otherwise correct.
Getting started in Excalidraw
Excalidraw is available free at excalidraw.com. No account required. Your teacher may share a .excalidraw file directly — open it with File → Open.
Skeleton: Context Diagram
The context diagram has exactly one system circle. Everything else is an external entity (rectangle) or a data flow (labelled arrow).
flowchart LR
A[Entity A]
B[Entity B]
C[Entity C]
S(("Your System<br/>Name"))
A -->|labelled flow| S
S -->|labelled flow| B
C -->|labelled flow| S
S -->|labelled flow| C
Shape key
| Shape | What it represents |
|---|---|
| Rectangle | External entity (a person, organisation, or external system) |
| Circle / oval | The entire system — one only |
| Labelled arrow | Data flow — must carry a specific name (not "data" or "info") |
Common setup errors to avoid before you start drawing
- Do not add a second circle — multiple circles make it a DFD, not a context diagram.
- Do not add data stores (double-line rectangles) — they do not exist at context level.
- Label every arrow with the specific data exchanged, not a direction. Wrong: "sends data". Right: "assignment submission form".
Skeleton: Level-1 Data Flow Diagram
The Level-1 DFD decomposes the single system circle into 3–6 numbered processes. Use the same external entities as your context diagram.
flowchart LR
A[Entity A]
B[Entity B]
P1((1. Process<br/>Name))
P2((2. Process<br/>Name))
P3((3. Process<br/>Name))
DS[("Data Store")]
A -->|input| P1
P1 -->|store| DS
DS -->|retrieve| P2
P2 -->|output| B
P2 --> P3
P3 -->|update| DS
Shape key
| Shape | What it represents |
|---|---|
| Rectangle | External entity — same names as context diagram |
| Circle / oval | A numbered process (verb–noun phrase, e.g. "1. Verify Login") |
| Cylinder / double-rectangle | Data store (named collection of stored data) |
| Labelled arrow | Data flow |
Minimum check before you submit your DFD
- Each process has at least one input AND one output arrow.
- At least one data store is present.
- Every entity name matches your context diagram exactly.
- No entity ↔ entity arrows (all flows route through a process).
- No entity ↔ data store arrows (data stores only connect to processes).
Skeleton: Use Case Diagram
The use case diagram shows who can do what with your system. Actors (stick figures) sit outside the system boundary; use cases (ovals) sit inside.
flowchart LR
A1(["👤 Actor A"])
A2(["👤 Actor B"])
subgraph SB["The System"]
UC1((Use Case 1))
UC2((Use Case 2))
UC3((Use Case 3))
UC4((Use Case 4))
end
A1 --- UC1
A1 --- UC3
A2 --- UC2
UC1 -.->|«include»| UC2
UC4 -.->|«extend»| UC3
Shape key
| Shape | What it represents |
|---|---|
| Stick figure (outside box) | Actor (a person or external system that uses the system) |
| Oval (inside box) | Use case (a function the system performs) |
| Rectangle | System boundary |
| Solid line | Association (actor participates in use case) |
| Dashed arrow «include» | Use case A always triggers use case B |
| Dashed arrow «extend» | Use case B sometimes triggers optional use case C |
Arrow direction rules (the most common exam mistake)
- «include»: arrow points FROM the base use case TO the included use case. (Login includes Verify Credentials → arrow: Login → Verify Credentials.)
- «extend»: arrow points FROM the extending use case TO the base use case. (Display Error Message extends Login → arrow: Display Error Message → Login.)
Rule of thumb: the arrow always points towards the use case that is being used or extended into.
Practice check — before the hand-drawn validation
Run through this list with your Excalidraw diagrams before the timed hand-drawing session
- Context diagram: exactly one system circle, no data stores, every arrow labelled.
- DFD: 3–6 numbered processes, at least one data store, entity names match context diagram.
- Use case diagram: all actors outside the boundary, all use cases inside, «include»/«extend» arrows pointing the correct direction.
- All three diagrams use identical names for the same entities and data stores.
If you can redraw all three from memory using only these skeletons as a prompt, you are ready for the hand-drawn validation.
See also
- Context Diagram vs Data Flow Diagram — what can appear on each diagram; the most common notation errors
- What Is an Entity? — human and non-human entities; how to find all entities from your user stories
- C02 Resources: external reading and videos
← Back to VCE Software Development Hub
