From SRS to UI Design — A Worked Example

The Hamilton and Alexandra College · Year 12 · 2026

The hardest part of C05 is not drawing a screen. It is showing that the screen came from somewhere — from a requirement you wrote in your SRS, through a rough idea you sketched in C04, into an exact design you can build and then check. This page traces that chain on a real project, not a toy.

The project is vsd-sat-grader: a small web app your teacher actually built to grade VCE SAT folios. Every artefact named below — the SRS, the wireframe, the design docs, the corrections — is a real file you can open on GitHub (links in The real files). Nothing here is invented for the lesson.

We will trace one requirement fully, then a second with the guidance faded, then hand you a third to trace on your own.

The chain in one picture

Every design feature you submit should be traceable along this chain. The loop at the end matters most: you do not just build, you evaluate the build against the requirement, and when it falls short you write a design correction and feed it back in.

flowchart TD
    A["C03 · SRS<br/>the requirement<br/>(FR3, FR9, FR6…)"] --> B["C04 · Sketch / wireframe<br/>which idea, roughly"]
    B --> C["C05-1 · Detailed design<br/>exactly how it is built"]
    C --> D["Build"]
    D --> E["Evaluate<br/>against the requirement<br/>(does it serve the user's task?)"]
    E -->|"gap found"| F["Design correction<br/>record before → after"]
    F -.->|"feeds back into"| C
    E -->|"passes"| G["Done"]

The three traces below each walk a different distance along this chain.

Trace 1 — FR3, fully worked

Here is FR3, quoted exactly from the SRS:

FR3 — Each criterion shows the rubric bands (1–2, 3–4, 5–6, 7–8, 9–10) the score falls in.

Hop 1 — the requirement (C03). FR3 says the teacher must see which rubric band a score falls in. That is the user's task on this screen: decide a band quickly.

Hop 2 — the sketch (C04). The chosen wireframe shows where that band selector lives on the Grade screen — a set of band boxes near the score input:

Look at the Grade panel: the band boxes are placed, but the wireframe never says what text sits inside them or where the band descriptions come from. A wireframe is deliberately rough — it fixes layout, not detail. Hold that thought.

Hop 3 — the detailed design and build (C05-1). Detailing the chosen idea produced the built Grade tab:

The bands are there — exactly as the wireframe drew them: 1-2, 3-4, 5-6, 7-8, 9-10. The build matches the sketch. So far, so good.

Hop 4 — evaluate against the user's task. Now the punchline. Walking through this build, the question is not "does it match the wireframe?" — it is "can the teacher decide a band quickly?" And the answer was no: the band selector showed only the numbers. To actually choose a band, the teacher had to remember the descriptors from memory or open the rubric in another window — the exact friction the app exists to remove. The wireframe drew band boxes; it never said where the descriptors would live. That gap was invisible in C04 and only surfaced when the build was tested against the real task.

Hop 5 — the design correction. This gap was recorded as design correction 01: show the full rubric for the selected criterion (every indicator's band-descriptor table) right there in the Grade tab, in a collapsible accordion between the band radio and the score input.

Before	After

Before — bands are bare numbers; no descriptors anywhere on screen. After — the selected criterion's indicators show their 1–10 band descriptors while you score, and the accordion collapses when an experienced marker no longer needs them.

That is the whole chain, spelled out:

FR3 (requirement) → band boxes in the wireframe (sketch) → band radio in the built Grade tab (detailed design) → can the teacher decide a band quickly? (evaluation) → no, the descriptors are missing → show them in an accordion (correction 01).

The lesson is the one Connect the Dots makes: a design is judged against the user's task, not just against the wireframe. The wireframe is correct and the design was incomplete — both can be true, because they answer different questions.

Trace 2 — FR9, with the guidance faded

Now you do more of the work. Here is FR9, quoted exactly from the SRS:

FR9 — Save-on-navigate + stateful Save buttons — switching student or criterion saves the view being left before loading the new one, so navigation can never silently discard edits. Each tab's Save button shows its dirty state: "To save" (orange, enabled) when unsaved edits exist, "Saved" (green, disabled) when clean — green buttons mean it is safe to quit.

The detailed-design doc for FR9 weighed three ways to stop navigation losing edits, then chose one. Here is the options-considered table, summarised from the real design doc:

The chosen design gives each Save button two states. Here they are, built:

Dirty: "To save" (orange, enabled)	Clean: "Saved" (green, disabled)

Now trace it yourself. You have FR9 above, the options table, and the two screenshots. Answer these in your design log:

1. Which exact words in FR9 forced the clean button to be DISABLED when green? Quote them. (Hint: what does "green buttons mean it is safe to quit" promise the user — and how does disabling the button prove that promise?)

2. The options table rejected the warn-dialog and full auto-save. For each rejection, name the requirement or constraint it clashed with. (One is a technical environment fact from the SRS; one is about keeping the Save button meaningful.)

3. Run the chain like Trace 1 did: requirement → which option was chosen → how the two button states are the detailed design → what the user can now trust about navigation. Write it as one arrow-chain sentence.

Trace 3 — FR6, your turn

No worked steps this time. FR6 is the leaderboard, and it is the most interesting trace of the three because of where it starts:

FR6 — (Could have) A leaderboard ranks students by total score across the cohort.

Read the SRS scope line for it, quoted exactly:

Could have — a leaderboard ranking students by total score (not in the wireframe — optional feature); hosted online for cross-school sharing.

So FR6 is a Could-have that is explicitly NOT in the C04 wireframe — yet it was built and corrected (design correction 08) in C05. Your job is to trace it end-to-end yourself, using the files linked below. Answer these three questions in your design log:

1. FR6 has no wireframe panel to start from. If the chain normally begins with a C04 sketch, where did the detailed design for the leaderboard come from instead? (Look at what the SRS §8 "UI / Screens" list and correction 08 give you.)

2. Correction 08 moved one table off the Score tab and split the Leaderboard into two sub-tabs. What was the user's task that the original single rank-list failed to serve? (The correction states it — quote it.)

3. Run the full chain for FR6 the way Trace 1 did — requirement → (no wireframe) → detailed design → evaluation → correction. Where the wireframe hop is missing, say so explicitly: a real trace names the gap, it does not paper over it.

The real files

Open these on GitHub and read the originals. Each link is the exact artefact a hop above refers to.

Check Your Understanding

1. In Trace 1, the design log writes FR3 — not "requirement 3" or "the rubric one". Why does the exact SRS label matter?

2. The FR3 wireframe drew band boxes but no descriptors, and that was not a mistake. What does a wireframe deliberately leave out, and at which later hop does that detail get filled in?

3. Design correction 01 keeps a "before" screenshot, not just the fixed "after". Why is the before-evidence worth keeping?

4. Trace 3's leaderboard (FR6) was a Could-have not in the wireframe, yet it reached a detailed design and a correction. In terms of breadth vs depth, what does that show about the difference between C04 and C05?

See also

• Connect the Dots — the theory this page demonstrates: annotate → link to the SRS → trace one feature all the way through.
• C04 to C05 - Choose then Detail — why C04 (choose which idea) and C05 (detail it until it is buildable) are different jobs; the breadth → depth shift behind every trace above.

← Back to C05 Home · VCE Software Development Hub