DRAFT — under teacher review.

SRS 2.0 — Tracing One Scenario Across the Document

Hamilton College · Year 12 · 2026

In the SRS 2.0 writing test (C3-1, validated at T2W5), you are given a new scenario — a change your client has just notified you of — and you must update your SRS to respond to it. Students who stall at 7–8 typically update one or two sections and stop. The 9–10 band requires you to trace the change through the entire document and justify why each section changed (or why it stayed the same).

The scenario is not an isolated edit. It is a ripple. A single new constraint can change requirements, scope, users, technical environment, and analytical tools — in a chain. This page shows what that chain looks like for one concrete example.

Scaffold: C031-SRS-2-0.md

The scenario used in this example

New constraint: The school has updated its data-protection policy. Any system that stores student names or student numbers must now:

encrypt all stored records (AES-256 or equivalent)

delete personal data within 30 days of the student's last login

log every access to a student record (read or write) to an audit trail

This is a legal + technical constraint entering the project from outside. Here is how it ripples.

Trace across the six SRS sections

1. Constraints

What changes: A new legal/technical constraint row is added.

Category	New constraint entry
Legal	New school data-protection policy (effective 2026-T2) requires AES-256 encryption for all stored student personal data (name, student number). Aligns with Privacy and Data Protection Act 2014 (Vic), s 13.
Technical	All student records must be automatically deleted 30 days after last login. Access to student records must be logged to an audit trail (read + write events, timestamp, user ID).

Why this section changes first: Constraints are facts of the world imposed on the project. The policy exists before you update a single requirement — the constraint section must reflect the new reality first, because everything else flows from it.

2. Non-Functional Requirements

What changes: Two or three NF requirements are updated or added.

#	Updated / new requirement
NF5 (new)	All student personal data (names, student numbers) shall be encrypted at rest using AES-256 or equivalent.
NF6 (new)	Student records shall be automatically deleted 30 days after the associated account's last login event.
NF7 (new)	Every read or write operation on a student record shall be logged to an audit trail table, capturing: timestamp, user ID, operation type (read/write), and affected record ID.
NF2 (updated)	The system shall comply with the Privacy and Data Protection Act 2014 (Vic) and the updated school data-protection policy (2026-T2 revision).

Why this section changes: Constraints define the world the system lives in; non-functional requirements define how the system must perform within that world. The new constraint directly generates three testable standards the system must meet.

3. Functional Requirements

What changes: One new functional requirement is added for data export/deletion.

#	Updated / new requirement
F9 (new)	The system shall allow an administrator to trigger manual deletion of a student's personal data on request, prior to the 30-day automatic period.

Why this section changes: The auto-deletion rule implies a manual override may be needed (e.g., a student requests data deletion under their rights). A functional requirement captures the feature; the constraint captures why the feature exists. Do not merge them.

What does NOT change: Most functional requirements are unaffected — the booking flow, event display, and notification features still work the same way. Only features that handle personal data are touched.

4. Scope (MoSCoW)

What changes: Audit-trail logging is promoted from Could to Must.

Priority	Feature	Before scenario	After scenario
Must	AES-256 encryption for stored student data	Was not in scope	Added: Must — legally required
Must	Audit trail logging	Was: Could — nice-to-have	Changed: Must — legally required
Could	Manual data-deletion trigger for admin	Was not in scope	Added: Should — implied by new NF requirements

Why this section changes: Scope reflects decisions about what the system will and won't do. A legal constraint converts an optional feature (audit logging) into a non-negotiable one — the scope table must reflect that shift. Failing to update the MoSCoW table leaves a contradiction: the constraint says "must log", the scope says "could log".

5. User Characteristics

What changes: The Administrator row is updated to reflect new responsibilities.

User Type	Before	After
Administrator	Manages events, approves bookings	Manages events, approves bookings; also responsible for monitoring the audit trail and actioning data-deletion requests within 30 days. Requires awareness of school data-protection policy.

Why this section changes: New responsibilities change the description of what the administrator does. A user characteristics entry must be accurate to the system as it will be built — if the admin now has a legal obligation (reviewing audit logs), that belongs in the characteristics table. It also informs training needs, which the 9–10 band examiner may probe.

What does NOT change: Student and teacher user characteristics are unaffected — they interact with the system the same way. Note this explicitly to show you considered all users, not just the one that changed.

6. Technical Environment

What changes: Security and data categories are updated.

Category	Updated entry
Security	AES-256 encryption for all student records at rest. HTTPS + TLS 1.2+ for data in transit (unchanged). Role-based access updated: administrators now have audit-trail read access in addition to existing permissions.
Data	MySQL 8.0 with `students` table encrypted at column level (AES_ENCRYPT). New `audit_log` table added: fields — `log_id`, `timestamp`, `user_id`, `operation`, `record_id`. Automated deletion trigger runs nightly; records older than 30 days post last-login are purged. Storage estimate increases by ~5 MB/year for audit logs.

Why this section changes: The technical environment documents how the system is deployed. New encryption, a new database table, and a nightly deletion trigger are all implementation-level changes — they belong here, not in the constraints section. Constraints explain why; technical environment explains how the system meets the constraint.

Analytical Tools (UCD, CD, DFD)

What changes: Review required — likely minor.

UCD: No new use cases for students or teachers. A new use case may be needed: «Review Audit Trail» for Administrator. Add if it wasn't already present.
Context Diagram (CD): No new external entities. The school data-protection authority (policy source) is an external entity only if your project has a data feed from them — unlikely in a basic school app. Probably no change.
DFD: The Audit Log is now a new data store. Add it, with data flows from each process that reads or writes student data. Update the data dictionary table to include audit_log entry.

Why you must check: The diagrams are meant to match the requirements. If you add a functional requirement (F9: admin-triggered deletion) and do not add a corresponding use case or DFD process, the traceability matrix breaks. The 9–10 band requires consistency across the whole document.

What the 9–10 answer looks like vs 7–8

Band	What the student does
7–8	Updates 2–3 sections (typically constraints + non-functional requirements). Notes that changes were made. Does not explain the chain of reasoning.
9–10	Traces the constraint through all six sections. For each section: states what changed, what stayed the same, and why. Points to contradictions the change resolves (e.g., scope table now consistent with constraints section).

The justify your changes instruction in C031-SRS-2-0.md is not a formality. The examiner is specifically looking for the chain: "The constraint changed X, which changed the requirement, which changed the scope, which changed the technical environment."

Common mistakes

Updating constraints but not scope. A new legal constraint that makes a feature mandatory must be reflected in MoSCoW (e.g., promoting an item from Could to Must). Leaving the scope table unchanged creates a contradiction.
Writing the justification inside the constraint row. The why for each change belongs in your narrative — not crammed into a table cell. Write a sentence per section: "Section 3.5 Technical Environment was updated because…"
Ignoring the diagrams. Any new functional requirement or data store should be cross-checked against the UCD, CD, and DFD. A new data store (e.g., audit_log) that appears in the requirements but not in the DFD is a traceability gap.
Changing sections that are unaffected. Do not bulk-edit your SRS to look thorough. The 9–10 band examiner will ask why you changed section X — if you can't answer, the mark is at risk. Noting that a section was reviewed and not changed is better than silently changing it.

Why VCAA cares

SRS 2.0 is explicitly a test of how well you understand the relationships between SRS sections. Writing good requirements is a 5–6 skill. Understanding that a legal constraint generates non-functional requirements, which promote a scope item, which update the technical environment — that is the 9–10 skill. The scenario is designed to expose whether the chain is understood or whether the student treats each SRS section as an isolated document.