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.

---

{{Video|src=https://www.youtube.com/watch?v=3fgfUHKITts}}

---

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

---

The scenario: a school event booking app. A student is writing requirements for C3-1.

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

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

---

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

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.

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

---

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.

---

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