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, because they quietly decide your architecture and stack 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.
1.6.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.
1.6.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 five 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 encrypted, 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 |
1.6.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.
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:
Act as a senior engineer setting my non-functional targets.
For my app, propose one measurable target in each of:
performance, availability, security, scale, accessibility.
Every target must be a number a test could check, and must
fit my real objective, not generic best practice. Save them
in my specs folder.
My app, and my main objective (speed, accuracy, scale...):
Do this now: paste the prompt with your objective, let your agent propose the five measurable targets into your specs folder, and adjust any number that does not match your goal.
