Beyond Features : Why Non-Functional Requirements Are the Backbone of Successful Systems

During the launch of healthcare.gov, the U.S. government’s online marketplace for health insurance, the website faced massive technical failures. Despite extensive planning, the site crashed due to poor scalability and insufficient load testing. Millions of users flooded the platform on the first day, but it was unable to handle the volume, causing delays and frustration. The issue was traced back to overlooked non-functional requirements—such as performance, scalability, security and reliability. This case study pushes project managers to think and make NFRs a part of requirements gathering process.

You can read more on the healthcare website issue on below link

https://medium.com/@bishr_tabbaa/small-is-beautiful-the-launch-failure-of-healthcare-gov-5e60f20eb967

What are Non-Functional Requirements (NFRs)?

Non-functional requirements (NFRs) define the quality attributes, system performance, and constraints of a system. Unlike functional requirements, which describe what the system should do (e.g., the operations it should perform), non-functional requirements describe how the system should perform those functions.

NFRs focus on the overall user experience, the environment in which the system operates, and the constraints that influence the design and performance of the system. They play a key role in ensuring the system is usable, efficient, secure, reliable, and scalable.

Key Categories of Non-Functional Requirements

1. Performance Requirements
   These describe the expected speed, response times, throughput, and scalability of the system.

   • Examples:

     • The system must process 1,000 transactions per second.

     • The web application should load within 2 seconds.

2. Reliability and Availability Requirements
   These specify the expected uptime, error rates, and fault tolerance of the system.

   • Examples:

     • The system should have 99.9% uptime.

     • The system must be able to recover from failures within 10 minutes.

3. Scalability
   Describes the system’s ability to handle increasing loads without significant performance degradation.

   • Examples:

     • The system must support 10,000 concurrent users without a drop in performance.

     • The database must scale horizontally to accommodate growing data volume.

4. Security Requirements
   Define the system's needs related to data protection, authentication, and authorization.

   • Examples:

     • All data must be encrypted using AES-256 encryption.

     • Users must authenticate via two-factor authentication.

5. Usability
   Relates to how easy and efficient the system is for users to interact with.

   • Examples:

     • The system should allow a new user to complete the registration process within 5 minutes.

     • The interface should be intuitive, requiring no more than 3 clicks to complete any task.

6. Maintainability
   Focuses on the ease with which the system can be updated, fixed, and modified over time.

   • Examples:

     • The codebase must follow the SOLID principles to ensure maintainability.

     • The system should support rolling updates without downtime.

7. Compliance and Legal Requirements
   These requirements specify any legal, regulatory, or standardization obligations the system must comply with.

   • Examples:

     • The system must comply with GDPR regulations.

     • The application must adhere to ISO 27001 standards for information security.

8. Interoperability
   Describes how well the system works with other systems or platforms.

   • Examples:

     • The system must be able to integrate with existing CRM software via an API.

     • The system must support both Windows and macOS environments.

9. Portability
   This is about how easily the system can be moved to different platforms or environments.

   • Examples:

     • The system must be able to run on Linux and Windows servers without major modifications.

     • The mobile application must support both iOS and Android platforms.

How to Capture Non-Functional Requirements

Capturing non-functional requirements can be challenging because they are often more subjective than functional requirements. However, the following techniques can help ensure that NFRs are effectively captured:

1. Use Stakeholder Interviews

• Approach: Engage with stakeholders such as business analysts, developers, end-users, and system architects to understand the quality expectations.

• Example Questions:

  • What response time is acceptable for the system?

  • What level of system uptime is required for the business to function smoothly?

  • Are there any security or compliance regulations the system needs to meet?

2. Questionnaires and Surveys

• Approach: Distribute structured questionnaires or surveys that ask stakeholders about their expectations regarding system quality, performance, and constraints.

• Example:

  • A survey asking users to rate their expected maximum load time for a web application.

  • A questionnaire asking about data security preferences.

3. Workshops and Brainstorming Sessions

• Approach: Organize workshops or brainstorming sessions with key stakeholders to discuss and prioritize NFRs.

• Example:

  • During a workshop, participants might discuss the need for a system to scale as the company grows, identifying NFRs related to scalability, load handling, and fault tolerance.

4. Review Similar Systems

• Approach: Analyze existing systems or benchmarks in similar industries to derive common NFRs.

• Example:

  • If developing a mobile banking app, look at industry standards for transaction response time, security features (e.g., encryption), and uptime.

5. Prototyping

• Approach: Develop a prototype or mock-up of the system and validate NFRs through performance testing and user feedback.

• Example:

  • Create a prototype of the web app and run load tests to assess how it handles multiple simultaneous users.

6. Use Standards and Best Practices

• Approach: Leverage industry standards, regulatory requirements, and established best practices to define NFRs.

• Example:

  • Use OWASP security guidelines to set NFRs related to application security.

  • Use ISO 25010 for software product quality models to identify key non-functional areas.

7. Non-Functional Requirements Templates

• Approach: Use templates or frameworks that provide a structured way to capture non-functional requirements.

• Example:

  • A template could include sections for performance, security, reliability, etc., with specific parameters and thresholds to be filled out by stakeholders.

8. User Stories for NFRs

• Approach: Sometimes, non-functional requirements can be captured using user stories, especially for usability and performance.

• Example:

  • "As a user, I want the page to load in less than 2 seconds so that I can interact with it quickly."

  • "As an admin, I need the system to handle 1,000 concurrent users, so I can ensure availability during peak hours."

Examples of NFR Capturing Process

Example 1: Performance Requirement

• Stakeholder Input: "We need the system to handle peak traffic during sales seasons."

• Captured NFR: The system must support up to 5,000 concurrent users with response times under 3 seconds.

Example 2: Security Requirement

• Stakeholder Input: "We need strong encryption to protect user data."

• Captured NFR: All sensitive user data must be encrypted using AES-256 encryption both at rest and in transit.

Example 3: Usability Requirement

• Stakeholder Input: "The application should be intuitive for new users."

• Captured NFR: New users must be able to complete a basic task (e.g., creating an account) within 5 minutes of first use, without any training.

Conclusion

Non-functional requirements are crucial for defining how a system should behave in terms of performance, reliability, security, and other quality attributes. Properly capturing these requirements involves engaging stakeholders, using templates, leveraging standards, and ensuring that performance metrics are clearly defined. Since NFRs often require testing and validation, they should be defined with measurable attributes, clear thresholds, and realistic expectations to guide system development and ensure success in the long term.