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)

---

| 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?" |

---

The difference between 7–8 and 9–10 is not more categories — it is *more justification inside each row*.

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

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

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

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

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

---

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

---

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

---

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.

---

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