> **DRAFT** — under teacher review. # Functional vs Non-Functional Requirements — What's the Difference? The Hamilton and Alexandra College · Year 12 · 2026 One of the most common errors in C3-1 is writing performance targets ("the app shall load in under 2 seconds") under functional requirements, or writing feature steps under non-functional requirements. These two requirement types are defined differently — and the C3-1 rubric checks both at 5–6 band. --- ## Watch first (≈5 min) {{Video|src=https://www.youtube.com/watch?v=3fgfUHKITts}} *Jelvix — side-by-side walkthrough of functional and non-functional requirements using concrete software examples. Watch for the pattern: functional = what the system does; non-functional = how well it does it.* --- ## The one-sentence rule | Type | One-sentence definition | Test question | |---|---|---| | **Functional** | A specific behaviour, action, or feature the system must perform | "Does the system **do** something specific here?" | | **Non-functional** | A quality standard or constraint on **how** the system performs | "Does this set a **standard** for how well the system works?" | --- ## Side-by-side: same project, both types The scenario: a school event booking app. A student is writing requirements for C3-1. ### Functional requirements (what it does) | # | Requirement | |---|---| | F1 | The system shall allow a student to search for events by date or category. | | F2 | The system shall send a confirmation email when a booking is made. | | F3 | The system shall allow an administrator to add, edit, and cancel events. | | F4 | The system shall display available seat counts for each event. | Each one describes **a specific action** — you could test it with a yes/no: either the system does it or it doesn't. ### Non-functional requirements (how well it does it) | # | Requirement | |---|---| | NF1 | The system shall load the event list in under 2 seconds on a standard school Wi-Fi connection. | | NF2 | The system shall be accessible to users with screen readers (WCAG 2.1 AA compliance). | | NF3 | The system shall be available 99.5% of the time during school hours (8am–4pm, school days). | | NF4 | The system shall store all user data in accordance with the Privacy Act 1988 (Cth). | Each one sets a **measurable standard** on how the system performs — you could test it with a metric (time, percentage, compliance standard). --- ## The most common mistakes ### Mistake 1: Performance targets under functional requirements > ~~F1: The system shall load quickly.~~ "Load quickly" is a performance standard — it belongs under non-functional requirements, with a number attached (e.g., "in under 2 seconds"). Functional requirements describe actions, not speeds. ### Mistake 2: Features buried under non-functional requirements > ~~NF1: The system shall have a login feature.~~ A login feature is something the system **does** — it is a functional requirement. Non-functional requirements cannot introduce new features; they can only constrain how existing features perform. ### Mistake 3: Vague non-functional requirements > ~~NF1: The system shall be easy to use.~~ "Easy to use" is not measurable. A non-functional requirement must be testable. Rewrite: *"A first-time user shall be able to complete a booking in under 4 minutes without assistance."* Now it can be tested. --- ## The categories of non-functional requirements The C3-1 rubric mentions "non-functional requirements of the proposed software solution." These commonly map to: | Category | Example | |---|---| | **Performance** | Load times, response times, throughput | | **Usability** | Learnability, error recovery, accessibility | | **Reliability** | Uptime percentage, mean time between failures | | **Security/Legal** | Privacy Act compliance, password requirements | | **Portability** | Runs on mobile browsers, no installation required | | **Maintainability** | Code must be documented for handover | You do not need to use all categories — pick the ones that are genuinely relevant to **your** project. --- ## Why VCAA cares At **5–6** band, the rubric requires you to *"document the functional and non-functional requirements of the proposed software solution."* This means both types must appear — and they must be correctly labelled. A submission that puts performance targets under functional requirements has mislabelled requirements, which sits below 5–6. At **9–10**, your non-functional requirements must be precise enough to be testable and tied to real constraints (legal, usability, etc.). Vague NF requirements suggest the student does not understand the distinction. --- ## See also - [Scope vs Constraints](/sd/C03/Scope%20vs%20Constraints) — the other common C3-1 pair confusion - C03 Resources: [external reading and videos](/sd/Resources/C03-Resources) --- ← Back to [C03 Home](/sd/C03/C03-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)