Functional vs non-functional requirements
Functional requirements describe what the product does. Non-functional requirements describe how well it does it. Here is the difference, examples of each, and why both need to be measurable and traced.
Functional requirements: what it does
A functional requirement specifies a behaviour, feature, or capability the product must have. It is usually easy to test because it describes a concrete action and outcome.
Examples: the system shall record every configuration change with a timestamp and user; the pump shall reject rate entries above the configured maximum; the report shall export to PDF.
Non-functional requirements: how well it does it
A non-functional requirement specifies a quality attribute: how well the product performs its functions. These are the requirements teams most often leave implicit, and where late surprises hide.
Common categories: performance, security, usability, reliability, availability, maintainability, and portability.
Examples: the system shall complete a search within 2 seconds for up to 1,000 rows; access shall require multi-factor authentication; the interface shall meet the organisation accessibility standard.
Both need to be measurable and traced
Whether functional or non-functional, a requirement that cannot be measured cannot be verified. Both types should carry a unique identifier and trace to the need they serve and the test that proves them. Treating non-functional requirements as first-class, traceable items is how you avoid the classic late failure where the product does everything it should but too slowly, or not securely enough. See how to write good requirements and requirements management software.
Common questions
What is a functional requirement?
A functional requirement describes what the product must do: a specific behaviour, feature, or capability. For example, the system shall log every configuration change with a timestamp and user.
What is a non-functional requirement?
A non-functional requirement describes how well the product must do it: quality attributes such as performance, security, usability, reliability, and maintainability. For example, the system shall complete a search within 2 seconds.
Why do non-functional requirements get missed?
They are easy to leave implicit because they describe qualities rather than features. Missing or vague non-functional requirements are a common source of late, expensive surprises, so they should be captured, measurable, and traced like any other requirement.
Capture every requirement, and trace it
Manage functional and non-functional requirements as structured, linked data.