Non-functional requirements (NFRs) specify how a system performs, not what it does: response times under load, the number of concurrent users it must support, uptime targets, security constraints, and behavior during failure. A PRD that lists only features hands engineers a product they can build but can't guarantee will survive real traffic, real attacks, or a real outage.
Quick answer: NFRs cover performance, scalability, reliability, security, usability, and maintainability — the qualities that decide whether a shipped feature survives contact with real users. Write each one as a testable number with a measurement method, never as an adjective like "fast" or "secure."
What Non-Functional Requirements Actually Are (and Why PMs Skip Them)
Non-functional requirements define the quality attributes and operating constraints of a feature — how fast it responds, how many users it supports, what happens when a dependency fails — while functional requirements define what the feature does. PMs skip them for three practical reasons: they feel like "engineering's job," they're harder to phrase in plain language than a user story, and no customer ever files a ticket asking for better non-functional requirements — they just churn when the app is slow.
The international standard ISO/IEC 25010 (the successor to ISO/IEC 9126) formalizes eight software quality characteristics — performance efficiency, reliability, security, usability, compatibility, maintainability, portability, and functional suitability. You don't need to memorize the taxonomy, but it's useful as a checklist: most PRDs that skip NFRs are missing five or six of those eight categories entirely, not just under-specifying one.
The cost of skipping them shows up late, which is exactly why it's easy to defer. A missing functional requirement usually surfaces in a design review or a sprint demo, days after it was written. A missing non-functional requirement tends to surface in production — the first traffic spike, the first slow query on real data volume, the first outage of a dependency nobody wrote a fallback for — when it's far more expensive to fix and far more visible to the business.
The trap most specs fall into is writing NFRs as adjectives instead of requirements. "The dashboard should load fast" and "the system should scale well" are aspirations, not specifications — they can't be tested, so they can't be verified before launch, and they become the subject of a heated Slack thread three days before release. A usable NFR table for a mid-sized feature looks like this:
| NFR Category | Question It Answers | Example Metric | Typical Owner |
|---|---|---|---|
| Performance | How fast does it respond? | p95 latency < 300ms | PM + Engineering |
| Scalability | How many can it handle at once? | 50,000 concurrent sessions | Engineering + Infra |
| Reliability / Availability | How often is it allowed to fail? | 99.9% monthly uptime | Engineering + SRE |
| Security | What must never happen? | No PII in logs; OWASP ASVS Level 2 | Security + Engineering |
| Usability / Accessibility | Can every intended user use it? | WCAG 2.1 AA conformance | Design + PM |
| Maintainability | How hard is it to change later? | New field ships in under 1 sprint | Engineering |
| Compliance | What external rules apply? | Data residency per GDPR | Legal + PM |
For the functional half of the spec — user stories, scope boundaries, acceptance criteria for what the feature does — a complete PRD writing masterclass for the AI era covers that anatomy in depth. NFRs are the section that sits alongside it, not instead of it.
Writing Performance Requirements Engineers Can Actually Test
A good performance requirement names a metric, a percentile, a target value, and a measurement method — never a vague adjective. "The page should load quickly" is unactionable; "p95 page load time under 2 seconds on a throttled 4G connection, measured via synthetic monitoring" is something an engineer can design against and QA can verify with a pass/fail result.
Percentiles matter more than averages because averages hide the tail. If 95 out of 100 requests return in 200ms but 5 take 8 seconds, your average looks fine while one in twenty users has a broken experience. That's why p95 and p99 (the 95th and 99th percentile response times) are the standard vocabulary in performance requirements, not "average response time."
Averages hide the tail. A "fast on average" system can still be broken for the exact users generating your support tickets — the ones on a slow connection, a large dataset, or a cold cache.
Response-time thresholds aren't arbitrary either. Researcher Jakob Nielsen's long-standing usability research (Nielsen Norman Group) established three human perception limits that still hold up: responses under 0.1 seconds feel instantaneous, up to 1 second keeps a user's train of thought unbroken, and beyond 10 seconds most users mentally disengage from the task. Anchor your targets to which of those three bands the interaction needs to land in, and justify the target instead of picking a round number.
A performance NFR section should read as a table of acceptance criteria, not a paragraph. Here's a real fragment for a search feature:
| ID | Requirement | Metric | Target | Measured By | Priority |
|---|---|---|---|---|---|
| NFR-PERF-01 | Search results render | p95 latency | < 400ms | APM trace on /api/search | Must |
| NFR-PERF-02 | Search results render | p99 latency | < 1200ms | APM trace on /api/search | Should |
| NFR-PERF-03 | Autocomplete suggestions appear | Time to first suggestion | < 150ms | Client-side RUM | Must |
| NFR-PERF-04 | Search index freshness | Data lag after write | < 5 minutes | Sync job monitoring | Must |
| NFR-PERF-05 | Search under peak load | Sustained throughput | 500 req/sec | Load test (k6) | Should |
Each row is independently verifiable. That's the bar: if an engineer or a QA lead can't design a test that produces a pass/fail answer against a row, it isn't a requirement yet — it's still an intention.
Scalability Specs: Sizing for Growth Without Gold-Plating
A scalability spec states the load a system must handle today, the load it must handle at a defined future date, and what happens when actual load exceeds both — not just "it should scale." Anchor the future number to a real growth forecast from your roadmap or finance team, not an arbitrary 10x safety margin that burns months of engineering effort on headroom nobody will use for years.
Martin Abbott and Michael Fisher's book The Art of Scalability introduced the AKF scale cube, a framework still widely taught in systems design: scale horizontally by cloning identical instances (x-axis), scale by splitting functionality into separate services (y-axis), or scale by partitioning data across shards (z-axis). A scalability NFR should say which axis the team is expected to use, because the answer changes the architecture, not just the deployment size.
The z-axis question — how data gets partitioned as volume grows — depends entirely on the shape of your schema, which is why scalability and data modeling are really one conversation. If you haven't defined how entities relate and where the growth pressure will land, our PM's guide to reviewing a data model is the right prerequisite before you commit to a sharding strategy in the spec.
A scalability spec should answer five questions explicitly, in the PRD, not in a hallway conversation with the tech lead:
- Current peak load — concurrent users, requests per second, or transactions per minute today.
- Forecasted load at a stated horizon (commonly 12–24 months), tied to an actual growth number, not a guess.
- Spike patterns — predictable surges like month-end reporting, a marketing launch, or a seasonal peak.
- Data volume growth — rows, storage, and per-tenant growth rate, since data size drives query performance long before request volume does.
- Degradation behavior — what the system does when it's over capacity: queue, rate-limit, shed load, or serve a cached/stale response.
That last point is the one PMs most often leave blank, and it's the one that matters most in an incident. "The system should scale to 50,000 users" says nothing about user number 50,001. A complete requirement says what happens to them too — a graceful queue is a very different user experience than a 500 error.
Reliability, Availability, and What Happens When It Breaks
Reliability requirements specify an acceptable failure rate and a recovery behavior: an uptime target, a Recovery Time Objective (RTO), a Recovery Point Objective (RPO), and explicit fallback behavior for every external dependency the feature touches. "The system should be reliable" is not a requirement; "99.9% monthly uptime, RTO of 15 minutes, RPO of 5 minutes" is.
Google's Site Reliability Engineering book popularized the vocabulary most eng orgs now use: a Service Level Indicator (SLI) is the metric you measure, a Service Level Objective (SLO) is the internal target for that metric, and a Service Level Agreement (SLA) is the external commitment with consequences attached. The gap between "three nines" and "four nines" of availability is where the engineering cost really lives:
| Uptime Target | Downtime Allowed / Year | Downtime Allowed / Month |
|---|---|---|
| 99% ("two nines") | ~3.65 days | ~7.3 hours |
| 99.9% ("three nines") | ~8.7 hours | ~43.8 minutes |
| 99.95% | ~4.4 hours | ~21.9 minutes |
| 99.99% ("four nines") | ~52.6 minutes | ~4.4 minutes |
Every additional nine typically costs disproportionately more in redundancy, on-call load, and architectural complexity than the one before it. The PM's job is to pick the number the business actually needs — a payments API and an internal analytics dashboard don't warrant the same target — and to write down the reason, not just the digit.
Security and Compliance Requirements
Security NFRs describe what must never be allowed to happen, and they belong in the PRD even when a security team owns the implementation, because the PM is usually the only person who knows the full data flow and user population. At minimum, name the authentication model, what data is classified as sensitive, encryption expectations (at rest and in transit), and any audit-logging requirement.
The OWASP Application Security Verification Standard (ASVS) is a practical reference for stating security requirements at the right level of detail — it defines verification levels (1 through 3) rather than leaving "secure" undefined. Pair it with any compliance obligation that applies — GDPR data residency, HIPAA if you touch health data, SOC 2 controls if you sell to enterprise — as explicit, testable lines in the same table, not a footnote.
Fitting NFRs Into Your PRD Without Bloating It
NFRs belong in a dedicated section of the PRD, expressed as a compact acceptance-criteria table linked to a test plan — not scattered as prose across the document or bolted on as an appendix nobody reads. Keep the section short enough that engineers actually read it: five to fifteen rows for most features, grouped by category, each with an ID, a target, and a measurement method.
Two structural habits keep this section useful instead of decorative:
- Tie every NFR to a test. A requirement without a verification method is a wish. If you can't say how it will be measured — a load test, an APM dashboard, a synthetic monitor, a manual accessibility audit — it isn't ready to ship in the spec.
- Revisit it as you learn. Performance targets and compliance requirements shift once load testing or legal review produces new information, so treat this section as part of a living PRD that stays current as requirements evolve rather than a document you write once and archive at kickoff.
Usability and accessibility NFRs are the exception to "keep it in a table" — a WCAG 2.1 AA target is easiest to validate against an actual interface, not written prose. Pair the written requirement with a detailed, clickable wireframe or prototype so design, engineering, and QA are checking the same artifact, not three different mental models of what "accessible" means.
Prioritize NFRs the same way you'd prioritize functional scope, rather than treating every row as equally mandatory. A Must/Should/Could label (borrowed from the MoSCoW prioritization method) on each requirement tells engineering which targets are launch-blocking and which are worth hitting but not worth delaying for — the search table earlier in this piece uses exactly that convention.
This is also where the spec tends to rot fastest in a static document: a performance target set in week one, a compliance requirement added in week six after legal review, an acceptance criterion revised after the first load test. Each edit ends up made in a different place, in a different file, by a different person.
Prodinja's Spec Studio is built around exactly this problem: it maintains a living PRD where requirements, acceptance criteria, and open questions stay in one structured document you can edit and version as the spec evolves, instead of forking into a pile of comments and side threads.
Key Takeaways
- Non-functional requirements define quality, not features — performance, scalability, reliability, security, usability, and maintainability all belong in the spec alongside functional requirements, not after them.
- Write NFRs as testable numbers, not adjectives — "fast," "scalable," and "secure" can't be verified; a metric, target, and measurement method can.
- Use percentiles, not averages, for performance targets —
p95andp99reveal the tail-latency problems that averages hide. - A scalability spec needs a degradation plan — state what happens to the user or request that exceeds your stated capacity, not just the capacity itself.
- Reliability targets have real cost tradeoffs — each additional "nine" of uptime costs disproportionately more; pick the number the business needs and document why.
- Security and compliance requirements belong in the PRD, even when another team implements them, because the PM usually owns the full picture of data and users.
- Treat the NFR section as living, not static — targets change after load tests, legal review, and real usage data, so the spec should be easy to revise in place.
Frequently Asked Questions
What is the difference between functional and non-functional requirements?
Functional requirements define what a system does — the features, user actions, and business logic. Non-functional requirements define how well it does it — response time, capacity, uptime, security, and usability constraints. A PRD needs both: functional requirements without NFRs describe a feature that works once, for one user, under ideal conditions.
How do you write a good non-functional requirement?
State a metric, a target value, and a measurement method in one sentence: "p95 API response time under 300ms, measured via APM." Avoid adjectives like "fast" or "reliable" with no attached number — if two engineers could disagree about whether the requirement was met, it isn't specific enough yet.
What are examples of non-functional requirements in software?
Common examples include p95 latency under 300ms, support for 50,000 concurrent users, 99.9% monthly uptime, WCAG 2.1 AA accessibility conformance, encryption of data at rest and in transit, and a Recovery Time Objective (RTO) of under 15 minutes after an outage. Each should be scoped to the specific feature, not copy-pasted company-wide.
How many non-functional requirements should a PRD include?
Enough to cover every category that's actually relevant to the feature — typically five to fifteen line items for a mid-sized feature, grouped by performance, scalability, reliability, security, and usability. Skip categories that genuinely don't apply rather than padding the table; an internal admin tool doesn't need the same scalability spec as a public checkout flow.
Who owns non-functional requirements — the PM or engineering?
Both, with different responsibilities. The PM is usually best positioned to set the business target — how much downtime is tolerable, how many users to plan for, what compliance rules apply — while engineering owns the architecture that meets it. Writing NFRs in the PRD, rather than leaving them to engineering to infer, is what keeps those two decisions aligned instead of guessed at separately.