Where Do Non-Functional Requirements Actually Live in a Living Spec?

Non-functional requirements live wherever the PRD template happens to have a slot for them — which, for most teams, is nowhere. Give them a dedicated section in the living spec, reviewed on the same cadence as feature requirements, with every item written as a measurable, testable target instead of an adjective like "fast" or "secure."

Quick answer: Non-functional requirements need a permanent section in the spec — covering performance, security, accessibility, reliability, and observability — with each requirement written as a number, a condition, and a test method, not an adjective.

Why Non-Functional Requirements Get Orphaned in the First Place

NFRs get orphaned because PRD templates are built around user stories and acceptance criteria — a format that rewards describing what a feature does, not how well it has to do it. Non-functional requirements cut across multiple features, have no single obvious owner, and are hard to write as a checkbox, so they default to tribal knowledge.

A few specific reasons this happens, over and over, on otherwise well-run teams:

• Templates are functional-shaped. "As a user, I want... so that..." has no field for latency, uptime, or contrast ratio — so nobody is prompted to fill one in.
• No natural owner. A feature team owns the checkout button; nobody feels like they own "the system stays up." Everyone assumes someone else has it covered.
• Hard to demo. A demo shows the button working once, for one person, on a fast laptop. It doesn't show what happens at 10x load, on a screen reader, or after a dependency times out.
• "Engineering will handle it." PMs frequently treat NFRs as an implementation detail rather than a product decision — but a p95 latency < 2s target is a product trade-off (cost, scope, timeline), not a technicality.

Frameworks built around customer intent don't automatically catch this gap either. Even a thorough jobs-to-be-done exercise can nail the functional job steps — the "what" the customer is trying to accomplish — while skipping the quality bar they expect that job done at. "I need the report to not time out during the board meeting" is a non-functional requirement wearing a customer-language disguise, and it deserves the same rigor as any functional one.

The Real Cost: Rework, Incidents, and Trust

The cost of an orphaned NFR always comes due later, and later is more expensive. A latency target missed at launch turns into emergency re-architecture; a skipped security control becomes an incident response; an ignored accessibility gap becomes a legal complaint or lost customers.

This isn't a new observation — it's one of the oldest, most consistent findings in software engineering economics. Barry Boehm's widely cited cost-of-change research found that the same defect costs dramatically more to fix the later it's caught, because the fix compounds through every layer built on top of it since. Directionally, most follow-up studies land in the same neighborhood:

*Directional, following the shape of Boehm's cost-of-change curve — exact multipliers vary by system and team, but the direction is remarkably consistent: catching the gap earlier is always cheaper, usually by an order of magnitude.

The Standish Group's long-running CHAOS research on project outcomes has repeatedly cited incomplete or unclear requirements among the top reasons projects run over budget or fail outright — and non-functional requirements are disproportionately the "unclear" ones, precisely because they're rarely written down in the first place. Reliability specifically has its own well-documented cost model: Google's Site Reliability Engineering practice popularized the idea of the error budget — a deliberate, numeric allowance for unreliability — precisely because "reliable" isn't a decision you can make once; it's a trade-off you have to keep making, and you can't make it without a number to trade against.

Checklist: The Five NFR Categories and How to Make Each Measurable

Every spec benefits from checking five NFR categories — performance, security, accessibility, reliability, and observability — and writing each as a number attached to a condition and a test method. Skipping straight to "it should be fast and secure" is the default; turning that into something a test can pass or fail is the actual work.

Performance

Write performance targets against percentiles, not averages — a p50 can look healthy while a p95 or p99 is quietly punishing your slowest cohort of users. Always attach a load condition (concurrent users, request rate) — "fast" with no stated load is not a testable claim.

Security

Security NFRs benefit from anchoring to an existing control catalog rather than inventing one per feature — NIST SP 800-53 control families and the OWASP Top 10 both give you a checklist of things to actually state a position on: authentication, authorization, encryption at rest and in transit, audit logging, and secrets management.

Accessibility

WCAG 2.2 AA, published by the W3C, is the closest thing this category has to an industry-standard bar, and it's specific enough to test against: color contrast ratios, keyboard navigation, screen-reader labels, focus order. Accessibility failures are also customer-journey failures — a form a screen-reader user can't complete is a hard stop on the customer journey's emotion curve, not a minor friction point, and it's worth treating it with that weight in the spec.

Reliability

Borrow the vocabulary Google's SRE discipline made standard: an SLI (the metric you measure), an SLO (the target for that metric), and an error budget (how much you're allowed to miss it before it becomes everyone's top priority). Writing "reliable" without these three is writing a wish, not a requirement.

Observability

Observability is the NFR that makes every other NFR verifiable after launch — without it, you're guessing whether your SLO held. At minimum, specify what gets logged, what gets traced end-to-end (a pattern the OpenTelemetry project standardized across logs, metrics, and traces), and how fast an alert fires after a breach.

A section this dense deserves the same lifecycle discipline as any other part of the spec — tracking whether the NFR section itself is draft, reviewed, or locked is exactly the kind of section-level maturity signal that keeps a spec honest about what's actually been thought through versus what's still a placeholder.

From Vague to Ready-to-Ship: One NFR Turned Into a Shippable Criterion

Take one vague NFR — "the dashboard needs to be fast" — and rewrite it with a metric, a load condition, a measurement method, and an owner, and it becomes something engineering can build to and QA can sign off on. That rewrite is also the dividing line between a requirement that merely states intent and one a team can actually ship against.

Before: "The dashboard needs to be fast."

After: p95 dashboard load time under 1.5s for the primary cohort (up to 200 concurrent viewers), measured via synthetic monitoring in production; two consecutive days above 2.5s p95 pages the on-call engineer.

Four ingredients turn an adjective into a criterion:

1. A metric — pick the one that matches how users actually experience it (p95, not average).
2. A condition — the load, cohort, or environment the metric has to hold under.
3. A measurement method — how and where it's actually observed, not just asserted.
4. An owner and a trigger — who gets paged, and at what threshold, if it slips.

This is the same distinction that separates a feature ready to start from one ready to ship. A vague NFR can clear a ready-to-start gate as a stated intention — it's fine to write "needs to be fast" during discovery. It cannot clear a ready-to-ship gate, because nothing about "fast" is testable. The rewrite above is what a ready-to-ship checklist should actually be checking for.

Give NFRs a Permanent Home in the Spec, Not a Footnote

NFRs belong in their own labeled section of the living spec, next to — not buried inside — the functional requirements, reviewed with the same rigor and the same change history as everything else. Bolting them onto a footnote or a wiki page nobody revisits guarantees they drift out of date the moment the system does.

A living spec is only as trustworthy as its least-maintained section, and NFRs are usually the section nobody remembers to touch when a feature scales past its original design. Treating changes to a latency target or an uptime commitment as a reviewable event — the same way PR-style spec diffs treat a change to a functional requirement — is what keeps that section from silently going stale while the rest of the document keeps evolving.

Key Takeaways

• NFRs get orphaned structurally, not carelessly — most PRD templates are shaped around functional user stories and simply have no field for latency, uptime, or contrast ratio.
• Later is always more expensive. Cost-of-change research from Barry Boehm through decades of follow-up studies agrees on the direction: catching a gap in production costs an order of magnitude more than catching it in spec review.
• Five categories cover most of the surface area: performance, security, accessibility, reliability, and observability — each needs a metric, a condition, and a test method, not an adjective.
• A measurable NFR has four ingredients: a metric, a load or usage condition, a measurement method, and an owner with a trigger threshold.
• Reliability without an error budget is a wish. Borrowing SLI/SLO/error-budget vocabulary from SRE practice turns "reliable" into something you can actually trade off against other priorities.
• The fix is structural, not heroic — give NFRs a permanent, reviewed section in the spec rather than relying on any one person to remember to raise them.