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`](../../../applied-computing-au/vic/unit3-4/sat/C03-2026/C031-SRS-2-0.md)

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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.

---

- [Scope vs Constraints](/sd/C03/Scope%20vs%20Constraints) — the boundary between constraints (facts of the world) and scope decisions (what the system will do)

- [Technical Environment — Five Categories](/sd/C03/Technical%20Environment%20%E2%80%94%20Five%20Categories) — how to update the technical environment section correctly

- [Evaluating Your Own Questions](/sd/C03/Evaluating%20Your%20Own%20Questions) — the related C3-2 self-assessment skill

- [C03 Resources](/sd/Resources/C03-Resources)

---

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