Non-functional requirements
Non-functional requirements describe how well a system must work rather than what it does: performance, availability, security, scalability, accessibility, maintainability. They are also called quality attributes, and the ISO/IEC 25010 standard organizes them in a quality model. Written well, they are measurable: “95% of searches return in under 500 ms” instead of “search must be fast”.
Why it matters for a PM
These requirements drive architecture choices and costs far more than most features, and they often stay implicit until something fails in production. A PM who states them early, with numbers tied to user impact, lets engineers design for the right load and lets the team test what matters before launch.
Example
For a search feature, the PM writes: “For 95% of queries, results appear in under 400 ms with 2,000 concurrent users; the feature remains available 99.9% of the month; all controls are usable with a keyboard.” Engineers can now size the system and write tests against those numbers.
Key points
- Use percentiles (p95, p99) for latency, because averages hide slow experiences.
- A quality attribute scenario states the stimulus, the context and the expected measurable response.
- Availability targets have a cost: each additional nine requires more redundancy and operations.
- Accessibility requirements can reference a standard such as WCAG 2.2 level AA.
- Security expectations get numbers too, for instance the maximum delay before a critical vulnerability is patched.
Common mistakes
- Writing adjectives (fast, secure, scalable) instead of thresholds.
- Asking for maximum performance everywhere, which multiplies costs without user benefit.
- Discovering the expected load only after launch.
Go further with Module
The courses and lessons that cover this concept: