The Hamilton and Alexandra College · Year 12 · 2026

Your designs are not arbitrary choices. Every element you put on a screen should connect back to a real user need in your SRS, and every requirement should trace forward to a concrete implementation. This page shows you how to make that thinking visible — which is exactly what C5-3 Step 2 is testing.

The performance descriptor goes from "outlines connections" (annotations only) up to "documents connections across design ideas, requirements **and** detailed designs." That last level — full traceability — is the 9–10 evidence.

---

**🎯 Watch for:** how to follow a single design decision all the way from the mood board through to pseudocode, and why stopping at the mock-up is the most common reason students miss the top band.

---

Work through these in order. Each level adds a layer on top of the last.

Add a written reason to every significant element in your sketches and mock-ups.

A weak annotation describes: *"The button is red."*

A strong annotation justifies: *"Red delete button — follows platform convention and creates a visual stop-sign effect, reducing accidental deletion for non-technical users."*

Examples from a typical SAT project:

Map each design feature back to a requirement using the **same numbering as your SRS** (FR-1, NFR-3, etc.). This is what separates "I thought it looked good" from "this decision was required."

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

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

| Search bar on home screen | FR-3: Users can search by name | Fastest path to core feature |

| Password strength indicator | NFR-2: Security | Guides users without explaining rules |

| Offline mode indicator | NFR-5: Reliability | Users need to know when data may be stale |

Build this table for your own project using your own SRS numbers. Every significant design decision should appear in it.

This is the level most students miss. Once you have a design element annotated and linked to the SRS, you need to show that the same decision flows forward into your detailed designs: the data dictionary, the IPO chart, and the pseudocode.

The diagram below shows what that chain looks like for one feature.

If you can draw this chain for your most important feature, you have Level 3 evidence.

---

| Level | What your evidence looks like |

|---|---|

| Basic | Designs exist but no written reasons |

| Developing | Some annotations, inconsistent |

| Proficient | Annotations on most elements — outlines connections |

| Strong | Annotations + SRS table — documents connections to requirements |

| Excellent | Annotations + SRS table + full trace to detailed designs — 9–10 band |

Stopping at the mock-up is the most common failure mode. A well-annotated, well-linked mock-up with no trace into the data dictionary or pseudocode caps you at the Strong level. Full traceability is what lifts the work into the top band.

---

- **Connections implied, not documented** — you know why you made the decision, but you never wrote it down. Markers can only assess what is on the page.

- **No SRS reference** — annotations explain the choice but never name the requirement it satisfies. The link between design and requirements is missing.

- **Trace stops at the mock-up** — the design looks connected, but there is no data dictionary entry, no IPO chart, no pseudocode that picks up the same feature.

- **Wrong SRS numbering** — you use different identifiers in the table than you used in your SRS. Use the exact same labels (FR-3, not "Functional Requirement 3").

---

- [ ] Annotations added to sketches and mock-ups explaining each significant design choice

- [ ] Each annotation names an alternative and gives a reason (justifies, not just describes)

- [ ] Each significant design element linked to at least one SRS requirement (FR- or NFR- number)

- [ ] Traceability table built: Design Element | Requirement (SRS ref) | Justification

- [ ] At least one feature traced all the way: mood board → mock-up → data dictionary → IPO chart → pseudocode

- [ ] Connections documented in writing, not just implied

---

1. A student writes "I used a dropdown menu because it looks cleaner." What is missing from this annotation?

>| **Answer:** The annotation describes a visual preference but does not name an alternative or link to a user need. A stronger version: "Dropdown instead of free-text field → limits input to valid options, reducing input errors for non-technical users (FR-3)." It needs the rejected alternative, the user-facing reason, and the SRS reference.

2. Your mock-up has a search bar that is fully annotated and linked to FR-3. What additional evidence do you need to reach the top performance band?

>| **Answer:** You need to trace the feature forward into your detailed designs — a data dictionary entry for the search field, an IPO chart showing search as a process, and pseudocode that implements it. Stopping at the mock-up, even a well-annotated one, caps you below the 9–10 band.

3. Why must the SRS references in your traceability table use the same numbering as your SRS document?

>| **Answer:** The marker needs to verify the link exists. If you write "FR-3" in your traceability table, they can turn to FR-3 in your SRS and confirm the connection. Inconsistent labelling breaks the chain and suggests you have not actually mapped the decisions — it looks like the connections are invented rather than documented.

---

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

- [Data Dictionary — Format is not Type](/sd/C05/Data%20Dictionary%20-%20Format%20is%20not%20Type)

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

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

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

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