Step 4: Non-Functional Requirements (NFRs)
If functional requirements are about *what* the system does, non-functional requirements are about *how well* it does it. Qualities like performance, security, scalability, usability, and maintainability often determine user satisfaction and long-term success. Including fields for metric/threshold and compliance standards ensures these requirements are specific and testable.
Key NFR Categories
These are often overlooked but are critical for a successful and robust product. Neglecting NFRs is a common cause of project failure, leading to systems that are slow, insecure, or impossible to maintain, even if they are functionally correct.
Category
Grouping NFRs into categories like Performance, Security, and Usability helps in organizing them and ensuring all quality aspects of the system are considered methodically, leaving nothing to chance.
- Performance: How fast must the system respond to user actions? Defines criteria for latency, throughput, and processing times.
- Scalability: How much can the system grow? Specifies requirements for handling increasing numbers of users, data volume, or transactions without degradation.
- Security: How is the system protected from threats? Details requirements for authentication, data encryption, access control, and vulnerability management.
- Usability: How easy and intuitive is the system to use? Focuses on user-friendliness, simplicity of workflows, and overall user experience.
- Accessibility: Can people with disabilities use the system? Defines standards that must be met, such as WCAG compliance, to ensure inclusivity.
- Reliability: How often can the system fail? Sets targets for uptime (e.g., 99.9%), mean time between failures (MTBF), and data integrity.
- Maintainability: How easy is it to update and modify the system? Covers aspects like code quality, documentation, and architectural simplicity to reduce long-term costs.
- Detailed questions for this section will be available soon.
Requirement Description
This is a brief, clear statement of the requirement that describes a quality or a constraint. For example: "The system must be secure against the OWASP Top 10 web vulnerabilities."
- Detailed questions for this section will be available soon.
Metric/Threshold
This is what makes an NFR tangible and testable. It's a quantitative target that the system must meet. Without a metric, an NFR is just a vague wish, impossible to verify objectively.
- Bad NFR: "The page should load fast."
- Good NFR: "The product detail page must achieve a Google Lighthouse performance score of 90 or higher on mobile."
- Good NFR: "API response times for all GET requests must be under 200ms at the 95th percentile."
Example: "API response time for 95% of requests < 200ms"
- Detailed questions for this section will be available soon.
Compliance Standard
This field specifies any external standards or regulations the system must adhere to, such as GDPR for data privacy, HIPAA for health information, or SOC2 for security controls. These are often non-negotiable and can have significant legal and business implications if not met.
Example: "OWASP ASVS Level 2"
- Detailed questions for this section will be available soon.
Priority
Just like functional requirements, NFRs must be prioritized. Achieving very high performance and military-grade security can be expensive and time-consuming, so it's crucial to decide which qualities are most critical for the product's success and align them with the budget and timeline.
Example: "High"
- Detailed questions for this section will be available soon.
Owner
Assigning an owner (often a technical lead or architect) ensures that someone is responsible for championing and verifying these quality attributes throughout the development process. This prevents NFRs from being forgotten or deprioritized during busy sprints.
- Detailed questions for this section will be available soon.
Key Artifacts
This module produces documents that ensure the system's quality attributes are treated with the same rigor as its features.
- NFR Matrix: A comprehensive table listing each non-functional requirement, its category, its metric/threshold, and its priority. This is a key document for architects and the quality assurance team.
- Service-Level Agreement (SLA) Draft: For services, this module helps generate a draft SLA document outlining commitments for uptime, performance, and support, which is crucial for managing customer expectations.