Non-functional Requirement

For a long time a requirements document held only one kind of line: what the product should do. Those are functional requirements — a user presses this, that appears. Teams wrote dozens of them, handed the list to engineering, and the result usually behaved fine in a demo.

The trouble showed up afterward. Pagedeck shipped document search, and the search box did return results, but for teams holding more than three thousand documents the results took four seconds to appear. In the review Mia said it was too slow. Theo said no line anywhere in the document had asked for a number of seconds. Neither of them was wrong. The requirement said results appear, and results appeared.

Fixing it at that point meant rebuilding how search worked. With a one-second target written down at the start the team would have chosen a different structure from the beginning, and finding out after everything was built cost two extra weeks. This column exists so that the level, not the behavior, gets decided before work starts.

Instead of describing a behavior, you write the condition that behavior has to satisfy, and you put a number in it. One line carries three things: what is being measured, the threshold, and how to check it. "Search should be fast" is not a condition. "Search results appear within one second for a team with three thousand documents" is. Nobody can rule on the first sentence, while the second is settled by pressing the button once in a review.

Five areas cover most of what teams write down.

1. Speed — how long things take. Put a ceiling on the time to draw a screen or answer a request. Borrowing a defined measure such as Largest Contentful Paint (LCP), the moment the biggest piece of content finishes rendering, keeps two people from counting the same thing differently.
2. Load — how many people it holds at once. A line reads something like "response time stays under double its normal value with 500 users on at the same time," and it gets checked with a load test, which fires a large volume of requests to find where things break.
3. Security — what is blocked and what is never stored. Passwords and payment details are not written into logs in readable form; knowing the address of someone else's document does not open it.
4. Accessibility — who can use it. Accessibility means designing screens that work for people who cannot see them well or cannot use a mouse, and the threshold is normally written as a conformance level from the Web Content Accessibility Guidelines (WCAG).
5. Availability — how rarely it stops. Uptime, the share of time a service ran normally, set at 99.9 percent leaves 43 minutes a month in which it may be down.

The number on each line comes from what missing it costs, not from an ideal. Four-second search makes people stop searching, so the target is one second. A document tool nobody can open for five minutes halts a whole team's day, so availability gets pushed out to a third decimal. An operations screen somebody opens twice a day can take three seconds without costing anyone anything, so that line stays loose on purpose.

The first place is a column in the requirements document, sitting directly under the list of behaviors and filled in at the same time as scope. Written after the build instead, the column only collects numbers the existing structure can already hit, and the document ends up recording an outcome rather than shaping one. Timing matters as much as content here: a number agreed before the build is an instruction, and the same number agreed afterward is only a report.

From there the numbers travel to three places.

1. Design decisions. Theo reads them when he chooses how to build. A line asking for search results in one second points toward a structure that prepares search terms in advance; three seconds allows something far simpler. The same feature turns into a different piece of software depending on that one line.
2. Review. Quality assurance (QA), the pass that checks quality before a release goes out, works through the lines one at a time. Unlike a review of behavior, this one times things, adds users, and moves around the screen with a keyboard only.
3. Customer commitments. Enterprise customers ask for service levels in writing. When the figure in a service level agreement (SLA) is stricter than the figure in the requirements document, the company has promised something it cannot keep, so Sofia lines the two numbers up before a contract goes out and asks for one of them to move.

"The non-functional requirements are empty here. Can someone give me a response-time target?"

A request to settle the number before anyone starts building.

"Accessibility isn't in scope this round. I'll write it down as something we're not doing."

Recording the decision to skip it so it doesn't quietly come back as a surprise.

"The features are all done, we just haven't hit the non-functional side yet."

The behavior works as specified, but a speed or security threshold is unmet, so the release is on hold.

At Pagedeck, when Mia opens a requirements document to start a review, Theo goes to this column first. What the numbers say swings his estimate anywhere from two weeks to six, so he reads it before he reads the feature list. Noa reads the accessibility line and works contrast and keyboard order into the mockups, because learning about it later means redrawing colors and structure. Sofia keeps her own copy of the availability figure, since that is the line customers quote back at her.

The most common mistake is reading these lines as nice-to-haves. They are not visible on screen and no user asked for them by name, which makes them easy to push down the list. From the user's side, though, a screen with a missing button and a screen that takes four seconds to react are the same screen: the job did not get done. Deferred, the repair costs several times what it would have cost up front, and nothing new ships while the structure is being rebuilt.

The other one is assuming a line counts without a number in it. "Works quickly" and "handles data safely" look like a filled column. Neither can be ruled on in review, so the person who thinks three seconds is quick and the person who expects one second argue over the same screen the night before release. A line nobody can judge does the same work as no line at all.