Commit e49970
2026-04-30 17:24:41 lisa: Delete SRS 2.0 wiki page and remove inbound links Page deleted because the C03 assessment is being run differently in 2026. Inbound links removed from C03-home and Evaluating Your Own Questions See-also section.| sd/C03/C03-home.md .. | |
| @@ 15,7 15,6 @@ | |
| - [Analytical Tools Template Guide](/sd/C03/Analytical%20Tools%20Template%20Guide) — how to use the pre-labelled Excalidraw file (UCD / Context Diagram / DFD skeletons) when updating your analytical tools in Step 1 (DRAFT) | |
| - [Technical Environment — Five Categories](/sd/C03/Technical%20Environment%20%E2%80%94%20Five%20Categories) — the 9–10 differentiator for C3-1; how to describe all five categories (hardware, software, network, data, security) with the justification the rubric requires (DRAFT) | |
| - [Evaluating Your Own Questions](/sd/C03/Evaluating%20Your%20Own%20Questions) — how to rate each C3-2 analysis question High / Medium / Low honestly; what the viva examiner probes at 7–8 band (DRAFT) | |
| - | - [SRS 2.0 — Tracing One Scenario Across the Document](/sd/C03/SRS%202%20%E2%80%94%20Tracing%20One%20Scenario%20Across%20the%20Document) — how a single new constraint ripples through all six SRS sections; what the 9–10 justify-your-changes requirement looks like in practice (DRAFT) |
| ## Resources | |
| sd/C03/Evaluating Your Own Questions.md .. | |
| @@ 78,7 78,6 @@ | |
| ## See also | |
| - [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — knowing what changes in the SRS is a prerequisite for rating impact | |
| - | - [SRS 2.0 — Tracing One Scenario Across the Document](/sd/C03/SRS%202%20%E2%80%94%20Tracing%20One%20Scenario%20Across%20the%20Document) — the related 9–10 skill: following a change through all six SRS sections |
| - [C03 Resources](/sd/Resources/C03-Resources) | |
| --- | |
| sd/C03/SRS 2 — Tracing One Scenario Across the Document.md .. /dev/null | |
| @@ 1,161 0,0 @@ | |
| - | > **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`](../../../applied-computing-au/vic/unit3-4/sat/C03-2026/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. |
| - | |
| - | --- |
| - | |
| - | ## See also |
| - | |
| - | - [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) |
| - | |
| - | <!-- touched 2026-04-30 to force OtterWiki re-render --> |
| - | |