Commit b5de46

2026-04-26 09:46:12 lisa: Add C03 wiki pages: Technical Environment, Evaluating Questions, SRS 2.0 Three new DRAFT pages targeting the C3-1 9-10 differentiator (technical environment five categories), the C3-2 self-assessment ladder (Evaluating Your Own Questions H/M/L), and the C3-2 ripple-effect skill (SRS 2.0 — one scenario traced across all six SRS sections). C03-home updated with Key Concept links to the three new pages. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

sd/C03/C03-home.md ..
@@ 13,6 13,9 @@
	- [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — the exact difference, with a side-by-side table for the same project; the most common mislabelling errors that cost marks at 5–6
	- [Scope vs Constraints](/sd/C03/Scope%20vs%20Constraints) — why budget is a constraint, not a scope decision; how MoSCoW and the constraints table work together; what the 9–10 band cross-reference looks like
	- [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.0%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
/dev/null .. sd/C03/Evaluating Your Own Questions.md
@@ 0,0 1,86 @@
+	> **DRAFT** — under teacher review.
+
+	# Evaluating Your Own Questions
+
+	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)
+
+	---
+
+	## What the table looks like
+
+	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.
+
+	---
+
+	## Worked evaluation table — one High, one Medium, one Low
+
+	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** |
+
+	### Why these ratings?
+
+	**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.
+
+	---
+
+	## What viva examiners look for (verb-laddered categories)
+
+	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. |
+
+	> At the 7–8 viva, *"I gave it a High because it was useful"* will not hold under examiner probing. You need the SRS-improvement column filled with specific section changes to defend any High rating.
+
+	---
+
+	## The most common mistakes
+
+	- **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.
+
+	---
+
+	## Why VCAA cares
+
+	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.
+
+	---
+
+	## 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.0%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)
+
+	---
+
+	← Back to [C03 Home](/sd/C03/C03-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C03/SRS 2.0 — Tracing One Scenario Across the Document.md
@@ 0,0 1,158 @@
+	> **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)
/dev/null .. sd/C03/Technical Environment — Five Categories.md
@@ 0,0 1,112 @@
+	> **DRAFT** — under teacher review.
+
+	# Technical Environment — Five Categories
+
+	Hamilton College · Year 12 · 2026
+
+	The technical environment section is the **sole 9–10 differentiator for C3-1**. Every student who reaches 7–8 band has already described users and scope — the jump to top marks lives entirely here. Students most commonly submit a bare table with one-word cells ("Windows", "Wi-Fi", "MySQL") and wonder why they stall at 7–8.
+
+	The rubric language is: *"Describes the technical environment in which the proposed software solution will operate."* That word — *describes* — means context, specificity, and justification, not a list of product names.
+
+	Scaffold: [`C031-Step-6-Technical-Environment.md`](../../../applied-computing-au/vic/unit3-4/sat/C03-2026/C031-Step-6-Technical-Environment.md)
+
+	---
+
+	## The five categories
+
+	| Category | What belongs here | One-line test |
+	|---|---|---|
+	| **Hardware** | Devices, peripherals, minimum specs (CPU, RAM, storage, screen) | "Would a different device break this feature?" |
+	| **Software** | OS, browser, frameworks, libraries, school-installed tools, version numbers | "Would a different OS or version break this?" |
+	| **Network** | Internet access, speed/bandwidth, intranet vs cloud, offline needs | "Would no internet break this?" |
+	| **Data** | Database type, storage volume, backup method, sync/export needs | "What happens to the data when the session ends?" |
+	| **Security** | Authentication method, access roles, encryption, compliance | "Who can see what, and how is that enforced?" |
+
+	---
+
+	## One-word entry vs complete entry
+
+	The difference between 7–8 and 9–10 is not more categories — it is *more justification inside each row*.
+
+	### Hardware — example
+
+	| Band | Entry |
+	|---|---|
+	| **One-word (5–6)** | Windows |
+	| **Described (7–8)** | Runs on Windows 10 desktop computers and iPads (iOS 14+) |
+	| **Complete (9–10)** | Runs on Windows 10+ desktop computers (2 GHz processor, 4 GB RAM minimum) and iPads (iOS 14+). Must load on school-issued devices; no admin privileges are available to install additional software. Responsive layout required for both 13-inch laptop and 9.7-inch iPad screen. |
+
+	The complete entry answers: *which devices, which specs, and why those specs matter for this project.*
+
+	### Software — example
+
+	| Band | Entry |
+	|---|---|
+	| **One-word (5–6)** | Python |
+	| **Described (7–8)** | Python 3.12, Django 4.2, Chrome browser |
+	| **Complete (9–10)** | Backend: Python 3.12 with Django 4.2.x. Frontend accessed via Chrome 90+ or Safari 15+ (school standard). No additional student installations — all dependencies run server-side. School-installed Compass (timetable) must not conflict with browser sessions. |
+
+	### Network — example
+
+	| Band | Entry |
+	|---|---|
+	| **One-word (5–6)** | Internet |
+	| **Described (7–8)** | Requires internet access via school Wi-Fi (25 Mbps) |
+	| **Complete (9–10)** | Requires internet access via school Wi-Fi (minimum 25 Mbps). Core booking features must degrade gracefully if Wi-Fi drops — a read-only offline cache of the next 24 hours' events is acceptable as fallback. Cloud-hosted on school server; no external hosting cost. |
+
+	### Data — example
+
+	| Band | Entry |
+	|---|---|
+	| **One-word (5–6)** | Database |
+	| **Described (7–8)** | MySQL database stores user data and event bookings |
+	| **Complete (9–10)** | MySQL 8.0 database stores user profiles, event bookings, and attendance logs. Expected volume: ~300 student records, ~500 event rows per term. Daily automated backup to school server. Data export (.csv) required for end-of-year reporting. Student data must not be retained beyond the school year without consent (Privacy Act 1988, s 6). |
+
+	### Security — example
+
+	| Band | Entry |
+	|---|---|
+	| **One-word (5–6)** | Login |
+	| **Described (7–8)** | School SSO login; students can view, teachers can edit |
+	| **Complete (9–10)** | Authentication via school Single Sign-On (LDAP). Role-based access: students (view/book only), teachers (create/approve/cancel events), administrators (full access including user management). HTTPS enforced; TLS 1.2+ for all data in transit. Passwords never stored in plain text (bcrypt hashing). Complies with the Privacy and Data Protection Act 2014 (Vic) for student records. |
+
+	---
+
+	## Rubric language at each band
+
+	| Band | Exact rubric language | What it means in practice |
+	|---|---|---|
+	| **7–8** | *"Describes the characteristics of the users for the proposed software solution. Describes the scope of the proposed software solution."* | You reached 7–8 by completing the user and scope sections — technical environment is still ahead of you. |
+	| **9–10** | *"Describes the technical environment in which the proposed software solution will operate. Organises the formal document using clear headings, sections and appendices."* | All five categories described (not listed), with justification per row, and the section is clearly labelled in the SRS using a heading. |
+
+	> **The 9–10 band has two requirements.** Describing the technical environment gets you the mark. But the document structure (headings, sections, appendices) must also be correct. A thorough technical environment buried in an unlabelled section still caps at 7–8.
+
+	---
+
+	## Common mistakes
+
+	- **One-word cells.** "Windows", "MySQL", "HTTPS" are product names, not descriptions. Add version, context, and why it matters for this project.
+	- **Missing the data category.** Students focus on hardware and software, then skip data entirely. Data storage is a separate mark-earning entry.
+	- **Security = password only.** A single bullet saying "students need a password" does not demonstrate understanding of access roles or compliance. Name the authentication method, list the roles, cite the relevant legislation.
+	- **No justification for specs.** Saying "4 GB RAM minimum" means nothing without a sentence linking it to the project (e.g., "school devices typically have 4 GB; the app must not exceed this to remain deployable on existing hardware").
+	- **Copying the Step-6 template headers without filling them.** Placeholder text left in the submitted SRS is an immediate mark ceiling at 3–4.
+
+	---
+
+	## Why VCAA cares
+
+	The technical environment section is where the SRS moves from *what the software does* to *how it fits into the real world*. At 7–8, a student has shown they understand users and scope. At 9–10, VCAA wants evidence that the student understands the deployment context — the actual hardware, the school's network, the data implications, and the security obligations.
+
+	The rubric separates these bands deliberately: it is possible to write excellent requirements and scope but still miss 9–10 by leaving the technical environment as a one-row table.
+
+	---
+
+	## See also
+
+	- [Scope vs Constraints](/sd/C03/Scope%20vs%20Constraints) — technical environment sits above the constraint layer; don't conflate a hardware constraint with the technical environment description
+	- [Functional vs Non-Functional Requirements](/sd/C03/Functional%20vs%20Non-Functional%20Requirements) — non-functional requirements (performance, security) inform the technical environment entries
+	- [C03 Resources](/sd/Resources/C03-Resources)
+
+	---
+
+	← Back to [C03 Home](/sd/C03/C03-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)