Non-functional requirements checklist (ISO 25010)

A non-functional requirements checklist is the set of "how well" questions a PRD has to answer before engineering can estimate it: not what the feature does, but how fast, how reliable, how secure, how it behaves under load and over time. The cleanest one to borrow from is ISO/IEC 25010, the software quality model engineers already think in. It has eight attributes. This is one question and one measurable example for each.

Functional requirements describe behavior. Non-functional requirements describe quality of that behavior, and they are where sprint estimates blow up, because most PRDs cover the first half and go quiet on the second. "The user can export a report" is a functional requirement. How fast the export returns, how many run at once before the queue backs up, what happens when the file is 400MB: those are the non-functional ones, and they are usually missing.

Why "how well" is the half that gets skipped

A feature list answers what the system does. It says nothing about how well it has to do it, and "how well" is where the cost lives. An engineer can build the export. Whether they build it to return in two seconds or two minutes, to survive a thousand concurrent users or fall over at fifty, depends entirely on a number you either gave them or didn't. When you don't, they pick one, usually the cheapest one to build, and you find out the difference in production.

That is the gap this checklist closes. Each attribute below is a question your draft should already answer, paired with what a measurable answer looks like. "Fast" is a vibe. p95 response under 500ms at 1,000 concurrent users is a requirement. The first one an engineer will quietly reinterpret. The second one they can build against and you can hold them to.

The order here follows the eight ISO 25010 attributes. The standard does not rank them, and neither should you blindly. Weight them by what your feature actually risks: a payments flow leans on reliability and security, a public API leans on compatibility and performance.

The eight attributes, one measurable NFR each

1. Performance efficiency

The question: How fast, and under how much load, before it degrades?

This is the attribute people think of first and still write badly. "The page should load quickly" is not a requirement, because nobody can fail it. Performance efficiency covers three things: time behavior (latency), resource use (CPU, memory), and capacity (how much before it breaks).

A measurable example: Search results return in under 300ms at p95 with 2,000 concurrent users; the endpoint holds 500 requests per second before queueing. Now there is a target, a percentile, and a ceiling. An engineer can choose an architecture against that. Against "quickly," they can't.

2. Reliability

The question: What happens when something fails, and how often is it allowed to?

Reliability is maturity, availability, fault tolerance, and recoverability. The trap is writing the happy path and assuming the rest. Every system fails. The requirement is about what failure costs and how the system behaves inside it.

A measurable example: 99.9% monthly uptime (about 43 minutes of allowed downtime); on a failed payment webhook, retry with exponential backoff for 24 hours before flagging for manual review; no data loss on a single-node failure. That gives QA something to test and ops something to alert on.

3. Security

The question: Who can access what, and what is the system protected against?

Security in ISO 25010 spans confidentiality, integrity, non-repudiation, accountability, and authenticity. For a PRD you do not need a threat model on the page, but you do need the access rules and the data-handling rules stated, not assumed.

A measurable example: All data encrypted at rest (AES-256) and in transit (TLS 1.2+); role-based access so a viewer cannot reach an admin endpoint; every permission change written to an audit log retained for 90 days; PII never sent to a third-party processor without a signed DPA. If your feature touches an LLM, this is also where you state that user content is never used for training, which is the line we hold on Thinkr's Gemini stack.

4. Compatibility

The question: What does it have to run alongside, and what does it have to talk to?

Compatibility is co-existence and interoperability: the browsers, the OS versions, the third-party APIs, the existing services it shares a database or a queue with. The bug here is the one filed by the user on the version you forgot existed.

A measurable example: Supports the latest two major versions of Chrome, Safari, Firefox, and Edge; degrades to a read-only view on unsupported browsers rather than erroring; consumes the v3 billing API and tolerates a v3-to-v4 migration without a hard cutover. Two browsers, four names, an explicit fallback, beats "works on modern browsers."

5. Maintainability

The question: How easily can the next person change this without breaking it?

Maintainability covers modularity, reusability, analysability, modifiability, and testability. PMs skip this one because it feels like an engineering-only concern. It isn't. The PRD decisions that make a feature hard to change later (a hard-coded business rule, a flag that should be config, a one-off schema) start in the spec.

A measurable example: Pricing tiers and limits are configuration, not code, so a tier change ships without a deploy; the feature is behind a flag that can be killed in under a minute; new code ships with test coverage on the core path. That is a non-functional requirement even though no end user ever sees it.

6. Usability

The question: Can the intended user complete the task without being taught?

Usability in the standard is broader than "looks nice": learnability, operability, error protection, accessibility, user-error recovery. The measurable version is about task completion and the cost of mistakes, not aesthetics.

A measurable example: A first-time user completes onboarding without support contact in 90% of sessions; destructive actions require confirmation and are undoable for 10 seconds; the interface meets WCAG 2.1 AA, including keyboard navigation and a contrast ratio of at least 4.5:1. Accessibility belongs here, and it is a requirement, not a nice-to-have, in most jurisdictions you ship to.

7. Functional suitability

The question: Does it actually do the complete, correct job it claims to?

This is the one that sounds functional and lives in the non-functional model, because it is about the quality of the function: completeness (does it cover the whole task), correctness (right results), and appropriateness (the right function for the goal). A feature can do something and still not do the job.

A measurable example: The export includes every field shown in the table view, not a subset; totals in the export reconcile to the on-screen totals to the cent; the report covers all four account types, not only the two we tested. Completeness and correctness, stated as conditions, are testable. "Exports a report" is not.

8. Portability

The question: Can it move (environment, platform, vendor) without a rewrite?

Portability is adaptability, installability, and replaceability. For most product teams this is the lowest-stakes attribute day to day, which is exactly why it is the one that bites during a cloud migration or a vendor swap. State the assumptions you are baking in.

A measurable example: No dependency on a single cloud provider's proprietary service for the core flow; the data export is in an open format (CSV or JSON) so a customer can leave; the service runs in any environment that provides a Postgres connection string, with no machine-specific config. You will not always need strong portability. You should always know which way you chose, on purpose.

Turning the checklist into your Engineering Readiness pass

Run these eight against your next draft before anyone else opens it. The honest result, the first time, is uncomfortable: most PRDs answer two or three of the eight and assume the rest. Performance gets a "fast," reliability gets nothing, security gets "standard auth," and the other five aren't on the page at all. That silence is what the Engineering Readiness pass is for.

In Thinkr's 11-pass critique, Engineering Readiness is the pass that reads your draft for exactly this: are the functional and non-functional requirements specific enough to estimate, or will the first sprint stall on a follow-up meeting. It lands each gap as a comment on the line it concerns, classified blocker, major, or minor, with a suggested rewrite. A missing performance ceiling on a high-traffic endpoint is a blocker. An unstated browser matrix on an internal tool is a minor. Same eight attributes, scored the same way every time, which is the point: severity you can trust is severity assigned by a rubric, not by whoever is reviewing and how their afternoon is going. The longer argument for that is in the principles behind a rigorous critique.

Two things make this pass hard to run by hand. The first is that you have to read for what is absent, and you cannot proofread a requirement that was never written. The second is that "how well" lives outside the part of the doc you spent your energy on, so it is the part you skim. An automated pass does not get tired at 6pm on the day the doc is due, which is when the non-functional half usually gets skipped.

If you want the next layer down, write each of these as a testable condition rather than a sentence: that is testable acceptance criteria applied to the non-functional half. And if you are checking your own work before anyone sees it, the full standing list is the PRD review checklist and the self-review method is in how to critique your own PRD.

FAQ

What is the difference between functional and non-functional requirements?

A functional requirement describes what the system does: a behavior, an action, an output. "The user can reset their password" is functional. A non-functional requirement describes how well it does it: speed, reliability, security, accessibility, and the constraints it operates under. "The reset email arrives within 30 seconds at p95" is non-functional. Functional requirements answer "what," non-functional ones answer "how well," and a PRD that only answers "what" is the one that stalls in estimation.

What is the ISO 25010 quality model?

ISO/IEC 25010 is the international standard for software product quality. It defines eight quality characteristics: performance efficiency, reliability, security, compatibility, maintainability, usability, functional suitability, and portability, each with sub-characteristics. It is the vocabulary engineers already use to reason about quality, which is why borrowing it for your non-functional requirements section gets you a shared language instead of a list of adjectives. You can read the standard at iso.org.

How many non-functional requirements does a PRD need?

Fewer than the eight attributes might suggest, and never zero. Weight them by what the feature risks. A payments flow needs hard numbers on reliability and security and can be light on portability. A public API leans on compatibility and performance. The test is not "did I write one for all eight," it is "did I state a measurable target for every attribute this feature actually depends on, and consciously skip the rest." A skipped attribute you decided to skip is fine. A skipped attribute you never considered is the gap that ships.