The Hamilton and Alexandra College · Year 12 · 2026

C5-3 asks you to do more than produce nice-looking designs — it asks you to make your **thinking visible**. The performance descriptors say it clearly:

Notice the three rising levels: annotate → link to requirements → trace all the way through to code-level artefacts. Each level builds on the one before, and stopping early is the single most common reason students miss the top band.

---

An annotation is not a description. Saying "the button is red" tells the reader what you built. A real annotation tells them **why** — and implies you considered an alternative.

Test yourself with this question: *Can I name the thing I didn't do, and explain why I rejected it?*

| Weak annotation (describes) | Strong annotation (justifies) |

|---|---|

| "The button is red." | "Red delete button — follows the stop-sign convention and creates friction before an irreversible action, reducing accidental deletion. Considered orange but red is the universal danger signal." |

| "I used a sans-serif font." | "Inter (sans-serif) chosen over a serif font — cleaner at small sizes on screen; the target display is 1080p at arm's length, where serifs add noise." |

| "The health bar is at the top-left." | "Health bar anchored top-left to match the player's primary scan path; tested top-right in early sketch but eye-tracking research shows players check top-left first in action games." |

The more you justify, the more evidence you give a marker that you made a **deliberate design decision**, not a guess.

---

Every design feature exists because of a requirement. Level 2 makes that link **explicit and traceable** — using the exact same reference numbers as your SRS document.

If your SRS says FR-3 and your design log says "requirement 3" or "functional requirement about jumping", the marker cannot confirm the trace. Use the **same label**, exactly.

Include a traceability table in your design log. Here is an example from a Godot game project:

| Design element | Requirement (SRS ref) | Justification |

|---|---|---|

| Double-jump shown as two small arc icons on HUD | FR-3 (player may jump twice before landing) | Icons make the remaining jump count readable at a glance during gameplay, satisfying FR-3's need for real-time feedback on jump state. |

| Health pickup glows green for 0.5 s on collection | FR-7 (player receives visual confirmation of pickup) | Glow duration is long enough to register but short enough not to distract; fulfils FR-7 without impeding player focus. |

| Settings screen accessible from pause menu only | NFR-2 (system shall not interrupt active gameplay) | Restricting settings access to the pause state ensures NFR-2 is never violated by an accidental menu trigger mid-run. |

---

The top band requires you to show a feature flowing continuously from inspiration all the way into code-level artefacts. Here is one complete trace for a **double-jump** feature in a Godot platformer.

Each node in that chain leaves evidence in a different artefact. A marker reading your folio can pick up any artefact — the data dictionary, the IPO chart, the pseudocode — and trace it back to the mood board and forward to the next layer.

---

| Band | What your evidence shows |

|---|---|

| Basic (1–4) | Designs exist but have no written reasons; annotations describe rather than justify |

| Developing (5–6) | Some annotations present; connections to requirements implied but not mapped |

| Proficient (7–8) | Annotations clearly outline connections between design ideas; alternative choices mentioned |

| Strong (8–9) | Traceability table maps design elements to SRS references with justification |

| Excellent (9–10) | Full trace from inspiration through mock-up into data dictionary, IPO and pseudocode; every artefact is connected |

---

- [ ] Every significant design element has an annotation that **justifies**, not just describes

- [ ] Each annotation names the alternative I rejected and why

- [ ] My traceability table uses **exact SRS reference numbers** (FR-x, NFR-x)

- [ ] Every SRS ref in my table actually exists in my SRS document

- [ ] I can trace at least one feature from mood board all the way to pseudocode

- [ ] My data dictionary has an entry for every variable named in my IPO charts

- [ ] My IPO charts connect to my pseudocode (same variable names, same logic)

---

>| The annotation describes an aesthetic preference but gives no justification. It does not name what "cleaner" means in context (fewer visible options, reduced cognitive load, less screen space?), does not reference an alternative that was considered (e.g. radio buttons, a list box), and does not link to any SRS requirement. A strong revision would explain *why* a dropdown serves this specific design better than the alternative and cite the relevant requirement.

>| You need to trace at least one feature all the way through to detailed design artefacts: a data dictionary entry (naming the variable, its type and valid range), an IPO chart that uses the same variable names, and pseudocode that implements the logic from the IPO chart. The mock-up and table earn Strong; the continuous trace from mock-up into data dictionary, IPO and pseudocode is the Excellent-band move.

>| The traceability table is only useful if a reader can verify the link. If your table says FR-3 but your SRS labels it FR-03 or "Requirement 3" or omits a number entirely, the marker cannot confirm the connection exists — and may treat it as unsubstantiated. Consistency of labelling is what makes a trace auditable.

---

- [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants)

- [Plan B Ready](/sd/C05/Plan%20B%20Ready)

- [Sketch vs Mock-up](/sd/C05/Sketch%20vs%20Mock-up)

- [Data Dictionary](/sd/C05/Data%20Dictionary)

- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)

- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python)

- [C05 Resources](/sd/Resources/C05-Resources)

---

← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)