Functional and Quality Requirements

Functional requirements state what a solution must do. Quality requirements describe the qualities it must exhibit under stated conditions, including performance, security, accessibility, and maintainability. They are often grouped under non-functional requirements, although the scope of that label varies and may include constraints. Performance is one quality area, not a synonym for every quality requirement. NASA’s systems-engineering guidance distinguishes functions to be performed from how well those functions must be performed; use its terminology within that framework.

The same lookup, two kinds of sentence

“Retrieve the receipt record for a supported order identifier” and “record a clerk’s correction with who made it and when” are functional. “At least 95% of eligible lookups return a correct result within two seconds under the agreed workload,” “usable with a screen reader,” and “restored within four hours after an outage” are quality requirements. A function without its quality conditions is easy to pass in a demonstration and easy to fail in daily use.

Common quality areas include performance, availability and recovery, security, accessibility, maintainability, and portability. Constraints, such as an approved data location or a fixed budget, form a third group; the categories help ask different questions and need not be perfectly disjoint.

A quality requirement needs its conditions

“Fast” and “secure” are not verifiable; NASA lists words of that kind as terms to replace. A usable quality requirement names the population it applies to, the measurement boundary, the workload and data conditions, and the pass rule. “Two seconds from submission to display, for all eligible lookups, at the agreed request rate and record mix, with errors and timeouts counted as failures” can be tested; “fast search” cannot.

State the denominator. A latency figure computed only over successful responses answers a narrower question than a requirement about every request the user submitted. Quality requirements also change with the environment: a result measured on a vendor’s cached sample does not transfer to the organization’s data, network, and screens.

References: NASA: Technical requirements definition, NASA: How to write a good requirement. Examples here are illustrative.