Non-Functional Requirements

Non-functional requirements (NFRs) define how well a system performs its functions rather than what functions it performs. While functional requirements describe features (the system shall display search results), non-functional requirements describe qualities (search results shall appear within 2 seconds). NFRs are also called quality attributes, system qualities, or constraints. They are critically important because a system that performs all required functions but is too slow, too insecure, or too difficult to use is worthless in practice. Yet NFRs are frequently under-specified, discovered late, and expensive to retrofit.

Categories of Non-Functional Requirements

Performance

How fast, how much, how efficiently the system operates:

• Response Time: "95% of page loads shall complete within 2 seconds"
• Throughput: "The system shall process 1,000 transactions per second"
• Resource Utilization: "CPU usage shall not exceed 70% under normal load"
• Capacity: "The system shall support 50,000 concurrent users"

Scalability

How well the system handles growth:

• Horizontal: "The system shall scale by adding server instances without code changes"
• Data: "Performance shall not degrade with up to 100 million database records"
• User: "Response times shall remain within SLA as user base grows from 10K to 1M"

Security

How well the system protects against unauthorized access:

• Authentication: "The system shall support multi-factor authentication"
• Authorization: "Users shall access only resources assigned to their role"
• Encryption: "All data in transit shall be encrypted with TLS 1.2 or higher"
• Compliance: "The system shall comply with GDPR data protection requirements"

Reliability

How consistently the system performs without failure:

• Availability: "The system shall maintain 99.9% uptime (less than 8.76 hours downtime per year)"
• Fault Tolerance: "Single server failure shall not cause service interruption"
• Recovery: "The system shall recover from database failure within 5 minutes with zero data loss"

Usability

How easy the system is to use:

• Learnability: "New users shall complete basic tasks without training within 10 minutes"
• Efficiency: "Experienced users shall complete common tasks in fewer than 5 clicks"
• Accessibility: "The system shall comply with WCAG 2.1 Level AA standards"
• Error Handling: "Error messages shall identify the problem and suggest corrective action"

Maintainability

How easy the system is to modify:

• Modularity: "New payment providers shall be integrated within 2 developer-weeks"
• Testability: "Automated test coverage shall exceed 80% of code lines"
• Analyzability: "Any component failure shall be diagnosable within 30 minutes using system logs"

Portability

How easily the system operates in different environments:

• Platform Independence: "The application shall run on Windows, macOS, and Linux without modification"
• Browser Support: "The web application shall function correctly on Chrome, Firefox, Safari, and Edge (latest 2 versions)"

Real-World Example: Healthcare System NFRs

A hospital patient record system has stringent non-functional requirements:

Writing Testable NFRs

The biggest problem with non-functional requirements is vagueness. "The system should be fast" is not a requirement—it is a wish. Every NFR must be measurable and testable:

Vague (untestable): "The system should have good performance" Specific (testable): "The system shall return search results within 2 seconds for 95% of queries when handling 500 concurrent users against a database of 10 million records"

Template: [System] shall [measurable quality] under [specific conditions] with [defined constraints].

NFR Tradeoffs

Non-functional requirements often conflict with each other:

• Security vs. Usability: Strong security (complex passwords, frequent re-authentication) degrades usability
• Performance vs. Security: Encryption adds processing overhead
• Availability vs. Cost: Each additional "nine" of availability costs exponentially more
• Flexibility vs. Performance: Abstract, flexible code is often slower than optimized, specific code

These tradeoffs must be made explicitly during requirements analysis, not discovered accidentally during implementation.

NFR Architecture Impact

Non-functional requirements drive architectural decisions more than functional requirements. The same feature (user login) might be implemented very differently depending on NFRs: a system requiring 99.999% availability needs redundant authentication servers across multiple data centers; a system with 99% availability can use a single server. Performance requirements determine caching strategies, database choices, and processing patterns. Security requirements influence every layer of the architecture.

Verifying Non-Functional Requirements

NFRs are verified through specific testing types: performance testing (load testing, stress testing), security testing (penetration testing, vulnerability scanning), usability testing (user observation, task completion rates), reliability testing (endurance testing, failover testing), and accessibility testing (automated scans, assistive technology testing). Unlike functional testing that verifies discrete behaviors, NFR testing often requires specialized tools, environments, and expertise.