Non-functional requirements (NFRs) specify quality attributes, constraints, and operational characteristics that govern how a system performs its functions, rather than what those functions are. They include: performance (speed, throughput, latency), reliability (MTBF, availability), safety (hazard compliance, fail-safe behavior), security (authentication, encryption), environmental (operating temperature, IP rating, vibration resistance), size and weight constraints, and cost targets. NFRs often span the entire system rather than a single component.
NFRs are frequently the requirements that kill hardware projects. A product may meet every functional requirement and still fail if it draws too much current, overheats under load, fails EMC testing, or weighs twice the allowed mass. Because NFRs cut across the architecture, they constrain the entire design space and must be established before component selection begins. A weight budget, for example, determines which sensors, housings, and actuators are even candidates.
Quantifying NFRs is critical. 'The system shall be reliable' is not a requirement — it cannot be tested. 'The system shall achieve a Mean Time Between Failures (MTBF) of at least 10,000 hours under rated operating conditions' is a testable requirement. IEEE 29148-2018 explicitly requires that quality attributes be stated as measurable criteria with defined test conditions and acceptable ranges.
Practical Example
NFR-01: 'The device shall operate continuously at ambient temperatures from -20°C to +60°C without performance degradation.' NFR-02: 'The product shall weigh no more than 450g including battery.' NFR-03: 'The system shall meet IEC 61000-4-2 Level 4 ESD immunity.'
How SpecZero handles this
In SpecZero, non-functional requirements are captured as ESSENTIAL requirements with target values that represent measurable pass/fail criteria. They drive concept evaluation just as functional requirements do — an NFR for operating temperature constrains which components and materials are acceptable.
Related terms
Functional Requirements
Statements of what a system must do — behaviors, inputs, outputs, and capabilities.
System Requirements Specification(SRS)
A formal document defining all requirements a system must satisfy, derived from stakeholder needs.
Requirements Traceability Matrix(RTM)
A document that links requirements to their sources, design elements, and verification tests.
Acceptance Criteria
The measurable conditions a system or component must meet to be considered complete and accepted.