DRAFT — under teacher review.

Connect the Dots — Trace One Feature Through Every Layer

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

🎯 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.

Three Levels of Connection

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

Level 1 — Annotate Your Designs

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:

• "Dropdown instead of text field → reduces input errors for non-technical users"
• "Red colour for delete button → follows convention, prevents accidental use"

Level 2 — Link to Your SRS Requirements

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."

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

Level 3 — Trace Through to Detailed Designs

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.

flowchart TD
    A["🖼️ Mood board<br/>Search icon included<br/>in initial style references"]
    B["📐 Mock-up<br/>Search bar placed top-centre<br/>on home screen (Step 1)"]
    C["📋 SRS link<br/>FR-3: Users can search<br/>by name or category"]
    D["🗄️ Data dictionary<br/>field: search_query<br/>type: String<br/>format: max 100 chars"]
    E["📊 IPO chart<br/>Input: search_query<br/>Process: filter records<br/>Output: filtered list"]
    F["💻 Pseudocode<br/>IF search_query is not empty THEN<br/>  results ← filterBy(search_query)<br/>ENDIF"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

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

The Performance Ladder

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.

Common Mistakes

• 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").

Quick Checklist

• 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

Check Your Understanding

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

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?

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

See also

• Sketch vs Mock-up
• Data Dictionary — Format is not Type
• IPO Charts — Process Means Steps
• VCAA Pseudocode — Not Python
• Plan B Contingency Table

← Back to C05 Home · VCE Software Development Hub