Non-Functional Requirements Nobody Reads Until Production

What a non-functional requirement is, six of them rewritten from adjective into something that can fail, and who really knows the load figure.

The performance section ran to three pages. It promised a system that was fast, responsive under load and ready to scale with the business. Every reviewer signed it. I wrote it, and I could not tell you today whether it was met, because there was nothing in it that could have failed.

A non-functional requirement is a measurable statement of how well a system has to work, and under what conditions, rather than what it does: how fast, how available, how secure, at what load. Measurable is the load-bearing word. With no number, no condition and no way to check it, what you have written is an adjective.

Non-functional requirements do not fail because they are technical, or because the team cannot handle percentiles. They fail because an adjective cannot come back false. Drop the number and the condition it holds under, and the sentence sails through review for the same reason it is useless: nobody argues with a promise that cannot be broken.

In short

• A line with no number, no condition and no measuring point cannot be met and cannot be missed, and nobody finds that out until production.
• The load figure sits with the engineer who was on call at the last peak and the supervisor who booked the extra shifts, not with the sponsor who names the ambition.
• Ask what the system withstood last time rather than what it should withstand. The past has a date and a witness; the future invites a wish.
• A threshold with no owner and no review trigger gets quietly relaxed by whoever sits nearest the deadline.

A requirement nobody can fail is a requirement nobody has to build. That is why adjectives survive every review and lose the first real peak.

The checks I run on acceptance criteria apply here too, and they are not enough on their own. A criterion asks whether one behaviour happened. A non-functional requirement asks how much of it the system holds under pressure, and that carries a cost somebody has to agree to pay.

Six that actually bite, as they arrive and as they go out

The case is the one I use throughout this site: returns and refunds at a mid-size online retailer, reconstructed from public material - the published returns policy, the help centre articles, and ten public complaint threads I picked myself. Nobody inside the company was asked anything. Every number below is therefore either mine and labelled as mine, or a placeholder for the figure your own evidence would put there, which is the position you are in every time you write these before anyone has handed you access.

The textbooks list more attributes than this, in a tidier order. These six bit on this case. Two more get a paragraph at the end, because a paragraph is what they were worth here.

Performance

Weak: The returns portal must be fast, even under load.

Fixed: The refund form confirms submission in under 2 seconds at the 95th percentile with 3,000 sessions active, measured in the browser, not at the load balancer. The 3,000 is my own estimate and the requirement says so on its face; where there is access, that figure comes out of analytics and carries the name of whoever pulled it, with the date.

What changed: fast picked up a number, a statistic, a stated load and a measuring point, and the load figure got a source.

The first thing a reviewer says to that is that I have swapped a vague requirement for a precise fiction, and more than once they have been right. A confident 3,000 with nothing behind it is worse than fast, because it looks defensible and gets built to. The answer is not a better guess. It is the label: a threshold carries the person, the date and the pull it came from, or it goes in as an open question and stays visible until somebody closes it.

Availability

Weak: The portal must be highly available.

Fixed: At least 99.9% availability per calendar month, measured 06:00 to 22:00 local time by an external check every 60 seconds against the refund form itself, not the home page. Maintenance announced 48 hours ahead and run outside that window does not count.

What changed: the nines got a window, a probe, a page worth probing and one written exclusion, so the monthly report means the same thing to both sides.

This is the line a developer declines to sign, and the refusal is fair: nines cost money and I am not the one paying for them. A demanding threshold goes in with the cheaper option written next to it and one sentence on what the business gives up by taking that option. Three nines and four nines are not two versions of the same sentence; they are two budgets, and the choice belongs to the person holding one.

Security

Weak: Customer data must be secure.

Fixed: Evidence photos are encrypted at rest and served over TLS 1.2 or higher. Every view of a customer's photo writes a log line with agent id, case id and timestamp, retained 12 months. No critical or high finding from the penetration test is open at go-live, and the release manager signs that line.

What changed: one adjective became three statements that can be shown to be false, and the last names the person who reads the report before release.

This is also where requirements start pulling against each other. Stronger authentication and fewer clicks want opposite things, and a conflict nobody writes down gets settled quietly at build time by whoever is nearest the code. Where two requirements pull like that, the pair gets a line saying which one wins, and who decided.

Usability

Weak: The refund flow must be intuitive and user friendly.

Fixed: A first-time customer completes a damaged-delivery refund in no more than four screens without contacting support. In the first month after launch, at least 80% of started cases reach a decision with no support contact logged against the case id.

What changed: a judgement nobody can fail became a count anyone can check, plus one outcome measured after launch, which is the half that usually goes missing.

That second half attracts the flattest objection of the lot: nobody will measure this after go-live. Often true, and fatal. An 80% target with no report behind it is a sentence in a file, exactly like an availability target with no monitor. Before I sign, every line of this kind names how it will be verified and who owns the dashboard or the report it lands on.

Compliance

Weak: The solution must be GDPR compliant.

Fixed: Evidence photos are deleted 90 days after the refund case closes, and the deletion is logged. A data subject request is answered inside the statutory window named by legal, not the one I remember. The 90 days is not mine to set: it goes in as an open question with the data protection officer as its owner and a due date before build starts, and when the answer comes back the requirement carries the rule id and the date it was confirmed in writing.

What changed: a regulation nobody can test against became two obligations this system can be tested against, with the deadline I am not qualified to state left to the person who is.

Scalability

Weak: The solution must be scalable.

Fixed: A new country is added by configuration - currency, returns window, address format - with no code change and no downtime. The architecture holds a fourfold rise in monthly cases over 18 months without re-platforming. Fourfold is a placeholder for a figure that lives in somebody's expansion plan; until it has that owner and that date, it stands as my assumption and is marked as one.

What changed: scalable got an axis to scale along, a price for adding the next country, and a note saying where the multiple has to come from before anyone builds to it.

Maintainability and browser support, kept short on purpose

Weak: The code must be maintainable and well documented. The portal must work on all devices and browsers.

Fixed: A developer who has never seen the repository runs it locally from the README in under an hour, and adding a new refund reason touches configuration and one module rather than four. Supported browsers are the current and previous major versions of Chrome, Safari, Edge and Firefox on desktop, plus Safari on iOS and Chrome on Android, drawn from real traffic rather than from anyone's preference, with a named owner and a quarterly review. Anything outside that list gets a plain message and the support number instead of an upload that fails without saying why.

These two share one entry for the reason a reviewer usually gives out loud: half of this belongs in the definition of done. Correct. The browser list holds for everything the team ships, so repeating it story by story turns it into wallpaper. Thresholds that change from feature to feature stay on the requirement; constraints that hold everywhere live in the definition of done, and the requirement points at them. Writing a full set of eight quality attributes because a textbook lists eight is how documents get long and reviews get skimmed.

Who actually knows the load figure?

Ask the sponsor how many people will use this at once and you get a figure that describes the ambition. That is not dishonesty. The sponsor sits furthest from the graphs, and their number is the one they would like to be true by next year.

The people holding the real figure sit two or three rungs down and are rarely in the workshop. The engineer who was on call knows what the system survived last time and the hour it gave up. The supervisor who staffs the support queue knows the week when volume triples, because they are the one booking the extra shifts. Somebody in marketing or operations is already sitting on the next peak without thinking of it as load at all: a campaign send, an enrolment deadline, a policy change with a cut-off date. All of them sit in a calendar weeks before they reach anybody's requirement. The infrastructure lead has last January in a dashboard and is almost never asked before the target is written. And on anything touching retention or reporting, the figure belongs to whoever would answer the regulator, not to the person who read the same summary of the regulation that you did.

None of them are hard to reach. They are simply not on the invitation list for the workshop where the number gets written, which is the whole problem: the target is drafted in the one room where nobody has the evidence.

So the question I ask is not how much this should withstand. It is: how much did it withstand last time, who was watching, and where is that written down. A wish has no author and no date. A past peak has both, usually with a graph attached, and it holds six months later when somebody wants the threshold relaxed: the conversation is then not my opinion against theirs, but a named person and a dated observation against a preference. And when nobody can answer at all, that is the finding. It goes in as an open question with a name and a due date, not as a round number chosen because the document needed one.

What makes a non-functional requirement testable?

Six slots. Every one I keep has them filled in, and the empty slots are where the argument goes once the system is live.

Template. X is number unit at statistic, under condition, measured by method at point. Set by name on date. Review when trigger.

Where to start

Open the last requirements document you wrote and read only the non-functional section. Count the sentences that could come back false. If the count is zero, that section was skimmed, not reviewed.

Then take the line that matters most and fill the six slots. Twenty minutes for the line. The twenty minutes after that are the phone call to whoever was on call last January, and that call is the actual work.

The scorecard I hold my own documents to is on the downloads page. It has no check aimed at a non-functional line, so do not go looking for one: the nearest two are 16 and 18, which ask a business rule who set it and what event would make it wrong, and those are the same two questions this page turns on.

All field notes · The portfolio guide · More in Requirements That Survive Review