Document Non-Functional Requirements — Requirements Engineering, Part 8
- Shawn West
- Jul 28
- 7 min read
Updated: Aug 17
Requirements Engineering · Part 8
You cannot interview your way to a non-functional requirement. Nobody will ever tell you "the export must finish in under thirty seconds for an account holding eighty thousand rows" — customers don't know their own row counts, and stakeholders don't know your gateway timeout. The number lives in your database and your infrastructure config, and getting it means going to look.
This tutorial produces a documented, testable NFR set in about 90 minutes. For why these go missing and what the four parts of the sentence do, see functional vs non-functional requirements explained and capturing the quiet ones. This is the documenting.
Illustrative composite continuing the support-tooling example from Parts 1–7. Figures are illustrative, not measured.
Before You Start
The requirements set you're adding to. Use cases from Part 2, INVEST-checked stories from Part 3, and the traceability matrix from Part 4 — NFRs become rows in that matrix like anything else.
The release scope from Part 5. You can't mark a category not this release without knowing what the release is.
Read access to production data, APM or access logs, and the gateway, proxy, and job config. Step 2 is a query session, not a meeting. Request the credentials before you book the time — without them the step degrades into exactly the speculation it exists to replace.
The incident log and support tickets for the last twelve months. You need what breaks today, not what someone remembers breaking.
An engineering lead who can price the set, and one stakeholder per bound who'd notice it being missed. Both need to be reachable this week — Steps 5 and 8 are the two you can't do alone.
Block about 90 minutes for Steps 1 through 7. Step 8 comes back on engineering's clock, not yours.
What You'll Build
An NFR set for one release: the applicable categories, a four-part sentence each, per-component bounds, a named verification method per requirement, and an explicit out-of-scope list.
Step 1: Select Categories, Reject the Rest (10 min)
Walk the list and mark each applies or not this release: performance, scalability, reliability, security, privacy, accessibility, compatibility, usability, maintainability, compliance.
Ours, for the refund queue: performance, reliability, accessibility, privacy. Explicitly not: scalability beyond current peak (no business case), compliance beyond existing PCI scope (no change to how card data is handled).
Check: you have rejected at least two categories in writing. An NFR document covering all ten is a template someone filled in, and it will be read as such.
Step 2: Pull the Numbers From Your Own Systems (25 min)
This is the step that makes the difference, and it is not a meeting. Before asking anyone what "fast" means, go and measure:
What to pull | Where | Ours |
Current volume, median and max | Production database | 60 median / 240 peak refunds in queue |
Growth over the last year | Same query, windowed | ~35% more refunds than 12 months ago |
Current latency at p95 | APM / access logs | queue loads in 900ms at p95 |
Hard limits already in the path | Gateway, proxy, job config | API gateway closes idle connections at 30s |
What breaks today | Incident log, support tickets | two SLA breaches last month |
Twenty-five minutes of querying replaces an hour of speculation, and the numbers are not negotiable in the way opinions are.
Check: you have a peak figure, not just an average, and you know the tightest timeout standing between the user and the data. Those two numbers decide most of your design.
Step 3: Write the Four-Part Sentence (15 min)
Each NFR names the attribute, the bound, the condition, and the qualifier:
The system shall [attribute] [bound] [under conditions], measured [qualifier].
Ours:
NFR-01 The refund queue shall render the first screen of results
within 1.5 s for queues up to 300 refunds, under normal
production load, measured at p95 server-side.
NFR-02 The queue shall remain usable by keyboard and screen reader
to WCAG 2.1 AA for all interactive controls.
NFR-03 The refund export shall complete within 30 s for accounts up
to 100,000 transactions, measured at p95.
NFR-04 Refund records shall be retained for 7 years and exclude full
card numbers from all logs and exports.
The qualifier is the part teams drop and the one that decides whether the requirement survives its first month. Without "at p95," one slow request during a deploy makes NFR-01 "fail," everyone learns to ignore it, and you've spent the credibility of the whole document.
Check: every NFR has all four parts. Count them out loud — a missing part is an argument deferred to the incident review.
Step 4: Set Bounds Per Component (10 min)
One bound across a whole system is either impossible somewhere or trivial everywhere.
Agent-facing queue p95 < 1.5s · 99.9% uptime · WCAG 2.1 AA
Admin configuration p95 < 3s · 99.5% uptime · keyboard operable
Nightly reconciliation no latency bound (async) · 99% completion
Applying the agent-facing bound to a nightly batch job produces expensive engineering for nobody's benefit; applying the batch bound to the queue ships something agents can't use.
Check: each component's bound is different from at least one other. Identical numbers across all components usually means one number was copied everywhere.
Step 5: Ask the Stakeholder to Confirm, Not to Invent (15 min)
Now bring the numbers to people — with a proposal, not a blank.
Weak: "How fast should the queue be?" — invites a number pulled from nowhere, usually "instant."
Strong: "It loads in 900ms today at p95 and peaks at 240 refunds. I propose we hold 1.5 seconds up to 300. Does that work, and is there a moment when it wouldn't?"
The second version got a useful answer: month-end is the constraint, when a batch of automated refunds pushes the queue past 400 — which nobody had mentioned in three prior conversations because nobody had asked with a number in hand.
The decision you'll face: stakeholder says "it just needs to be instant." Don't argue the word. Ask what happens at 1.5 seconds, then at 3, then at 5 — the point where they flinch is your real bound, and now it's theirs.
Check: every bound has been confirmed by someone who'd notice it being missed. Numbers you set alone are numbers you'll defend alone.
Step 6: Name the Verification for Each (15 min)
An NFR without a verification method is a wish with a number in it.
NFR-01 k6 load test in CI against staging at 300-refund fixture;
production alert if p95 > 1.5s for 5 minutes
NFR-02 axe-core in CI, plus one manual screen-reader pass per release
NFR-03 load test with a synthetic 100k-transaction account
NFR-04 log scanner in CI asserting no PAN patterns; annual retention review
Note that NFR-03's verification requires a fixture nobody has built yet. That's a finding — it's why the requirement was never checked before, and it goes in the plan as work.
Check: every NFR names a tool, a trigger, and a threshold. "We'll monitor it" names none of the three.
Step 7: Write the Out-of-Scope List (5 min)
Not committed this release:
- Performance beyond 300 queued refunds (revisit at increment 2)
- IE11 or legacy Edge support (deprecated internally 2024)
- Real-time push updates — 60s polling is acceptable
- GDPR data-portability export (no EU customers on this product)
Explicit exclusions end arguments before they start, and — as with the Won't list in Part 5 — each one carries a reason or a revisit point.
Check: every exclusion has a reason or a date. A bare exclusion reads as an oversight to whoever finds it next.
Step 8: Review With Engineering for Conflicts (varies)
Send the set to the engineering lead with three questions: achievable with the planned architecture? any two of these in conflict? what does the expensive one cost?
Ours surfaced a real conflict: NFR-01's 1.5s at 300 refunds and NFR-04's exclusion of card data from exports pulled against a plan to denormalize refund data into a fast read model — the fast path would have carried fields the retention rule forbids. Better found on paper than in a security review.
Check: engineering has named the most expensive NFR and roughly what it costs. If everything is "fine," they haven't priced it.
You're Done When
Pick any NFR in your document at random and read it aloud: it has all four parts, and beside it a named tool, trigger, and threshold.
At least two categories appear in writing as rejected, and every line on your out-of-scope list carries a reason or a revisit point.
Every NFR is a row in your Part 4 traceability matrix, and every bound has the name of the person who confirmed it.
If This Goes Wrong
No production access when you reach Step 2. File the access request, then run Steps 1 and 7 while you wait — category selection and the out-of-scope list don't need numbers. Do not substitute a stakeholder's estimate for a query; a guessed baseline anchors every bound that follows it.
The latency query returns nothing usable — no APM, no structured logs. Instrument one endpoint and take a week of real traffic before you write NFR-01. A bound you have no current measurement for is a bound you can't tell you've broken.
The stakeholder won't move off "instant." Run the ladder from Step 5 — 1.5 seconds, then 3, then 5 — and write down where they flinch. If they still won't name a number, record "no bound agreed" as an open question with their name against it rather than inventing one on their behalf.
A verification method needs a fixture nobody has built, as NFR-03's 100,000-transaction account did. Don't drop the requirement. Put the fixture in the release plan as work, and mark the NFR unverified until it lands.
Engineering comes back and says the whole set is fine. They haven't priced it. Go back with one question — which of these is the most expensive, and what would you cut to buy it? — and don't close Step 8 until you have a named NFR and a rough cost.
Common Failure Modes
Asking before measuring. You get "instant" and "always available," and you've anchored the conversation on fantasy.
Averages instead of peaks. The system has to survive the worst day, not the median one.
No qualifier. The requirement is violated constantly, gets ignored, and takes the rest of the document's credibility with it.
One bound for every component. Expensive where it doesn't matter, insufficient where it does.
No verification named. The NFR is aspirational, and nobody discovers that until it's missed.
No out-of-scope list. Every unstated non-commitment becomes a future argument you'll have under pressure.
Sources
Web Content Accessibility Guidelines (WCAG) 2.1 — W3C Recommendation, current edition 6 May 2025. The standard NFR-02 and the per-component table refer to. https://www.w3.org/TR/WCAG21/
WCAG 2 Overview — W3C Web Accessibility Initiative. Defines the A, AA, and AAA conformance levels, including the AA bar used above. https://www.w3.org/WAI/standards-guidelines/wcag/
Payment Card Industry Data Security Standard (PCI DSS), v4.0.1 — PCI Security Standards Council. The basis for the existing PCI scope rejected in Step 1 and the card-number exclusion in NFR-04. https://www.pcisecuritystandards.org/document_library/
Continue the Requirements Engineering path
Part of the Requirements Engineering learning path.
