What is the difference between a functional requirement and a quality (non-functional) requirement?
A functional requirement says what the system does — a result or behaviour a function must provide; a quality requirement says how well it does it (performance, availability, security…) and is defined as everything not covered by the functional ones.
This is the most fundamental split in requirements engineering:
| Functional requirement | Quality (non-functional) requirement | |
|---|---|---|
| Concerns | A result or behaviour a function must provide | A quality concern not covered by a functional requirement |
| Subtypes | Function, behaviour and data requirements | Performance, availability, dependability, scalability, portability… |
| Example | "The user can log in" / "transfer money" | "Login responses return in under 2 s" / "log data is stored securely" |
Note how the quality side is defined negatively — as the concerns the functional requirements do not cover. That is not sloppiness; it is what makes the pair exhaustive, and it is also why the quality bucket is the one that silently ends up empty when nobody is looking.
The practical test for telling them apart: a functional requirement can be demonstrated by doing something with the system — it either logs you in or it does not. A quality requirement qualifies how that same function behaves: fast enough, reliably enough, securely enough. Which is why quality requirements are hard to test until someone attaches a number to them.
Tip: Security is a quality (non-functional) requirement. "Store log data securely" adds no new feature — it constrains how well an existing function behaves. That is exactly why security is easy to forget: nobody asks for it as a feature, so the requirements engineer has to bring it into the game.
Go deeper:
Functional requirement (Wikipedia) — the "what" side in detail, with its function, behaviour and data subtypes.