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, the part most tutorials skip and serious engineers pin down early. They quietly decide how the app has to be built, long before you write a single feature.
This chapter gets you a short list of measurable targets, set now, while changing them is still cheap.
2.5.1What it does vs. how well it does it
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.
2.5.2Set a number, never an adjective
"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 seven categories. For each, turn the vague wish into a number a test can check:
| Category | Vague (won't do) | Measurable target |
|---|---|---|
| Performance | "fast" | A page loads in under 2 seconds |
| Availability | "reliable" | Up 99.9% of the time |
| Security | "secure" | Passwords never stored as plain text, login enforced on private data |
| Scale | "handles growth" | 10,000 users and 1 GB of data in year one |
| Accessibility | "usable by all" | Works by keyboard and screen reader, meets WCAG AA |
| Cost | "cheap to run" | Under 50 euro a month at launch, hosting and database included |
| Privacy and law | "we respect privacy" | We store names and emails only, no card details on our servers, and a user can delete their account |
2.5.3Write them down for your AI before it builds
These are not paperwork, they are the most important thing you decide in this part. Your objective, whether you need raw speed, tight accuracy, or a set number of users, decides how the whole app is put together.
A "handle 500 uploads at once" target changes your database and hosting from day one. Bolt scale or accessibility on after launch and you are usually rewriting the foundation.
The last two rows earn their place the same way. A cost ceiling rules out the expensive host before you fall for one. And the personal data you choose to store today is exactly what you answer for later, long before this book reaches the law.
Hand these targets to your AI before it designs anything, and it builds the structure to hit them. You are not implementing any of it yet, a later part covers how. Here you just set the bars, 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.
This prompt proposes your targets, tuned to your goal:
Do this now: paste the prompt with your objective, and let your agent propose the seven measurable targets into your specs folder. Then adjust any number that does not match your goal.
