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

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.