Hamilton College · Year 12 · 2026

For C3-2, the **7–8 band** requires you to *evaluate* your critical analysis questions — rating each one as High, Medium, or Low against what it would actually improve in your SRS. Most students assign High to every question. That is not an evaluation; it is a claim. The rubric is checking whether you can honestly judge your own work.

Scaffold: [`C032-Step-3-Evaluate-Questions.md`](../../../applied-computing-au/vic/unit3-4/sat/C03-2026/C032-Step-3-Evaluate-Questions.md)

---

Your evaluation table has four columns:

| Question | Data Obtained | SRS Improvement | Effectiveness Rating |

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

| The question you asked | What information the answer actually gave you | Which section of your SRS changed — and how | High / Medium / Low |

The **SRS Improvement** column is the one students skip or write vaguely. It must name a specific section and a specific change. "Helped my SRS" earns nothing. "Added a non-functional performance requirement in Section 3.2 specifying a 3-second load time on school Wi-Fi" earns marks.

---

Project scenario: a school timetable viewing app.

| Question | Data Obtained | SRS Improvement | Effectiveness Rating |

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

| "What frustrates you most about checking your timetable at the moment?" | Students miss room changes because they only check the timetable once in the morning; they don't receive push alerts when rooms change. | Added F4 (Functional): *"The system shall send a push notification when a room change is logged for an enrolled class."* Also added NF3 (Non-functional): *"Notifications must arrive within 60 seconds of the change being made."* Changed scope: room-change alerts promoted from Should to Must in MoSCoW table. | **High** |

| "Do you prefer dark mode or light mode?" | Responses were split roughly 50/50 with no strong preference. | Added a note to the non-functional usability requirements: *"The interface should support both light and dark colour schemes."* Promoted to Should in MoSCoW. Small change — no new section required. | **Medium** |

| "What is your favourite colour for a school app?" | Students named blue, green, and white. No actionable pattern. | No SRS section was changed. Colour preference at this level of vagueness belongs in the design phase, not the requirements specification. | **Low** |

**High** — the question about frustrations surfaced a missing functional requirement, a missing non-functional requirement, and a scope priority change. Three separate SRS sections were updated with specific, testable content. The question could not have been rated lower because the data it produced directly filled gaps in the formal document.

**Medium** — the dark/light mode question produced a real (if modest) SRS change: one non-functional requirement and one scope upgrade. But the impact was narrow — one row in one section — and the change was optional, not essential. Calling this High would overstate its contribution.

**Low** — the colour preference question produced data that is relevant to *design*, not *requirements*. A requirements specification documents what the system must do, not how it will look. Assigning High to this question would mean the student does not distinguish between requirements gathering and visual design. Honest self-assessment means rating it Low and explaining why.

---

The C3-2 viva voce is structured around five categories that match the rubric bands:

| Band | Rubric descriptor | What you need to show at interview |

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

| **1–2** | *"Identifies the data that needs to be collected to inform the development of the software requirements specification."* | Can name what data was collected and why it was needed. |

| **3–4** | *"Outlines the use of questions to critically analyse the data collected to inform the development of the software requirements specification."* | Can describe how questions were used to analyse the data — not just that questions were asked. |

| **5–6** | *"Writes questions to critically analyse the development of the software requirements specification."* | Can read out a question and explain what SRS element it was designed to test. |

| **7–8** | *"Evaluates questions to critically analyse the development of the software requirements specification."* | Can justify a High/Medium/Low rating under questioning — not just state it. Examiner will push back: *"You gave that question a High — could you have discovered the same thing another way?"* |

| **9–10** | *"Writes follow-up questions to clarify the data collected to inform the development of the software requirements specification."* | Has follow-up questions ready that are genuine clarifications (new information), not restatements of the original question. |

---

- **All High, no Medium or Low.** If every question gets High, the examiner knows the evaluation was not genuine. At least one Low is almost always defensible for any real question set.

- **SRS Improvement column is blank or says "helped me understand."** The column must name a section (e.g., Section 3.2 Non-functional Requirements) and a change (e.g., added one requirement). Without this, the table is a rating exercise, not an evaluation.

- **Rating a question High because the answer was interesting.** Interest is not the criterion. The criterion is: did this answer change something in your SRS? If yes, High. If it changed something small, Medium. If nothing changed, Low.

- **Confusing evaluation with criticism.** A Low rating is not a failure — it shows analytical honesty. Examiners reward students who can say "this question didn't improve my SRS and here's why" more than students who claim all questions were equally valuable.

---

The 7–8 band descriptor is *"evaluates questions."* Not lists, not describes — *evaluates*. VCAA is checking that you can apply critical judgement to your own process. This is one of the two criteria where self-assessment is the skill being assessed — the other being your ability to justify changes in SRS 2.0.

A student who can defend a Low rating with a clear SRS-specific argument is demonstrating exactly the kind of analytical thinking that separates the 7–8 band from 5–6.

---

- [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — knowing what changes in the SRS is a prerequisite for rating impact

---

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