> **DRAFT** — under teacher review. # Technical Environment — Five Categories The Hamilton and Alexandra 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)