Non-Functional Requirements

System Design Fundamentals: Requirements -> Non-Functional Requirements

This document outlines the transition from general requirements gathering to specifically defining Non-Functional Requirements (NFRs) in system design. It's a crucial step in building a robust and successful system.

1. Understanding Requirements: A Quick Recap

Before diving into NFRs, let's briefly revisit the types of requirements:

• Functional Requirements (FRs): What the system should do. These describe the specific features and behaviors. Examples: "User can log in," "System can calculate shipping costs," "Admin can add new products." They are typically expressed as user stories or use cases.
• Non-Functional Requirements (NFRs): How the system should do it. These define the quality attributes of the system. They describe constraints on the design and implementation. They are often more subjective and harder to test than FRs.

2. What are Non-Functional Requirements (NFRs)?

NFRs are critical for user satisfaction and system success. They ensure the system isn't just functional but also usable, reliable, secure, and performant. Ignoring NFRs can lead to a system that technically works but is unusable or unacceptable to users.

Key Characteristics of NFRs:

• Quality Attributes: They describe the qualities of the system.
• Constraints: They impose limitations on the design and implementation.
• Measurable (Ideally): Good NFRs are quantifiable, allowing for testing and verification. (e.g., "Response time must be less than 2 seconds" is better than "System must be fast.")
• Cross-Cutting Concerns: They often affect multiple parts of the system.

3. Common Categories of Non-Functional Requirements

Here's a breakdown of common NFR categories, with examples:

a) Performance: How quickly and efficiently the system operates.

• Response Time: The time it takes for the system to respond to a user request. (e.g., "95% of API calls must respond within 500ms.")
• Throughput: The number of transactions the system can process in a given time period. (e.g., "System must handle 10,000 concurrent users.")
• Latency: The delay between a request and its response. (e.g., "End-to-end latency for order placement must be less than 3 seconds.")
• Scalability: The ability of the system to handle increasing workloads. (e.g., "System must be able to scale to 1 million users without significant performance degradation.")

b) Reliability: How consistently the system performs its functions correctly.

• Availability: The percentage of time the system is operational. (e.g., "System must be available 99.99% of the time.")
• Fault Tolerance: The ability of the system to continue operating even in the presence of failures. (e.g., "System must be able to tolerate the failure of one database server without data loss.")
• Recoverability: How quickly the system can recover from failures. (e.g., "System must be able to restore from backup within 2 hours.")
• Mean Time Between Failures (MTBF): The average time a system operates without failure.

c) Security: Protecting the system and its data from unauthorized access and attacks.

• Authentication: Verifying the identity of users. (e.g., "System must support multi-factor authentication.")
• Authorization: Controlling access to resources based on user roles. (e.g., "Only administrators can access sensitive data.")
• Data Encryption: Protecting data in transit and at rest. (e.g., "All sensitive data must be encrypted using AES-256.")
• Compliance: Meeting regulatory requirements (e.g., "System must be compliant with GDPR.")
• Vulnerability Management: Regularly identifying and addressing security vulnerabilities.

d) Usability: How easy the system is to learn and use.

• Learnability: How quickly users can learn to use the system.
• Efficiency: How quickly users can perform tasks.
• Memorability: How easily users can remember how to use the system after a period of inactivity.
• Error Rate: The frequency of errors made by users.
• User Satisfaction: How satisfied users are with the system. (Often measured through surveys and feedback.)

e) Maintainability: How easy the system is to modify and update.

• Code Readability: How easy the code is to understand.
• Modularity: The degree to which the system is composed of independent modules.
• Testability: How easy it is to test the system.
• Extensibility: How easy it is to add new features.

f) Portability: How easily the system can be moved to different environments.

• Platform Independence: The ability to run on different operating systems.
• Database Independence: The ability to use different database systems.

g) Operational: Requirements related to the system's operation and management.

• Backup and Restore: Procedures for backing up and restoring data.
• Monitoring: Tools and processes for monitoring system health.
• Logging: Recording system events for debugging and auditing.
• Deployment: Process for deploying the system to production.

4. From Requirements to NFRs: A Practical Approach

Here's how to derive NFRs from initial requirements:

1. Analyze Functional Requirements: For each FR, ask "What qualities are needed to make this FR successful?" For example:

   • FR: "User can search for products."
   • NFRs: "Search results must be returned within 2 seconds," "Search must be able to handle a catalog of 1 million products," "Search results must be relevant and accurate."

2. Stakeholder Interviews: Talk to stakeholders (users, business owners, operations teams) to understand their expectations for the system's quality.

3. Risk Assessment: Identify potential risks and define NFRs to mitigate them. (e.g., if data loss is a major risk, define strong availability and recoverability NFRs.)

4. Use Cases & User Stories: Review use cases and user stories to identify implicit NFRs.

5. Prioritize NFRs: Not all NFRs are equally important. Prioritize them based on business needs and user impact. Use techniques like MoSCoW (Must have, Should have, Could have, Won't have).

5. Documenting NFRs

• Clear and Concise: Use simple language and avoid ambiguity.
• Measurable: Include specific metrics whenever possible.
• Testable: Ensure that NFRs can be verified through testing.
• Traceable: Link NFRs back to the functional requirements they support.

Example NFR Documentation:

Conclusion:

Defining clear and measurable NFRs is a vital part of system design. It ensures that the system not only works but also meets the needs of its users and the business. Investing time in NFRs upfront will save time and money in the long run by preventing costly rework and ensuring a successful system implementation.