Your user stories say what the software does. They say nothing about how well it has to do it: how fast, how reliably, how safely, for how many people. Those quality bars are non-functional requirements, and they quietly decide your architecture and stack long before you write a feature. This chapter gets you a short list of measurable targets, set now, while changing them is still cheap.
What it does vs. how well it does it1.5.1
A functional requirement is a thing the software does. A non-functional requirement is a standard it must meet while doing it.
| Functional | Non-functional |
|---|---|
| A shopper can pay for a cart | Checkout completes in under 3 seconds |
| A user uploads a photo | The site handles 500 people uploading at once |
| An admin views a report | The report is available 99.9% of the time |
The functional side is the feature. The non-functional side is the quality bar that feature is held to.
Set a number, never an adjective1.5.2
"Fast" and "secure" cannot be tested. A number can. Every target you write should be something you or your agent can measure and get a clear yes or no on.
Walk these five categories and set a target for each:
- Performance: how fast a page loads or an action completes.
- Availability: your uptime, the share of time the app is working, often written as a percentage like 99.9%.
- Security: the minimum bar, such as encrypted passwords and enforced login on private data.
- Scale: how many users and how much data you expect at launch and in a year.
- Accessibility: usable with a keyboard and a screen reader, meeting a named standard.
Set them now, because they shape the build1.5.3
These targets are not paperwork. A "handle 500 uploads at once" target changes your database and hosting choices from the first commit. Bolting scale or accessibility on after launch often means rewriting the foundation.
You are not implementing any of this yet. A later part of this handbook covers how to actually hit these bars. Here you only decide what the bars are, so every choice downstream has something to aim at.
Example: 95% of pages load in under 2 seconds on a mobile connection, and the app is available 99.9% of the time.
Do this now: write one measurable target for each of the five categories (performance, availability, security, scale, accessibility), each a number a test could check.
