This guide walks you through understanding what non-functional requirements (NFRs) are, why they matter, and how to organize them into a Software Requirements Specification (SRS).
1. Understand What NFRs Are
Non-functional requirements define the quality attributes, constraints, and operational characteristics of a system. Unlike functional requirements, which describe what a system does, NFRs describe how well the system performs under specific conditions — for example, "the system shall respond within two seconds" or "the system shall ensure confidentiality when printing invoices."
NFRs cover aspects such as performance, reliability, maintainability, usability, scalability, security, and portability.
2. Know Why NFRs Matter
Write strong NFRs early to reduce ambiguity and rework. Studies cited in the source material show that 60–80% of software development cost goes to rework, and well-defined NFRs can eliminate up to 50–80% of defects by preventing misunderstandings early.
Many NFRs are described as the "-ilities" of a system: reliability, scalability, usability, maintainability, serviceability, and upgradeability.
3. Categorize Your Requirements
When drafting NFRs, sort each one into a category. Use the table below as a checklist while reviewing your system's needs.
| Category | What to Capture |
|---|---|
| Performance & Scalability | Response times, throughput, and behavior under increased load. |
| Operating Constraints | Required system configurations, runtime limitations, or environmental conditions. |
| Platform Constraints | Hardware, OS compatibility, or external systems the solution must integrate with. |
| Modifiability | Effort required to update or extend the system in the future. |
| Portability | Ease of moving the system to different platforms or environments. |
| Reliability | Failure frequency, error detection, and recovery strategies. |
| Security | Access control, data protection, vulnerability mitigation, threat resistance. |
| Usability | How quickly and easily users can learn, operate, and navigate the system. |
| Legal & Compliance | Regulations related to privacy, data protection, and intellectual property. |
Most projects share common quality categories such as availability, capacity, reliability, and security — start with these to build a reusable template for future projects.
4. Distinguish Functional from Non-Functional Requirements
- Ask "what must the system do?" — this is a functional requirement (e.g., send a welcome email when a user signs up).
- Ask "how must the system behave while doing it?" — this is a non-functional requirement (e.g., stability, reliability, efficiency, privacy, portability).
- Keep both types clearly separated in your documentation so reviewers can evaluate each on its own terms.
5. Place NFRs Within the SRS Document
Non-functional requirements typically live in the "Specific Requirements" section of a Software Requirements Specification (SRS). Structure the SRS as follows:
- System Overview — high-level system goals, definitions, and context.
- General Description — assumptions, constraints, and overall vision.
- Specific Requirements — functional and non-functional requirements together.
Review existing SRS examples to see how NFRs integrate into complete requirements documentation before finalizing your own.