Nonfunctional Requirements Explained: Examples, Types, Tools

1. Performance requirements

Performance requirements focus on the speed and efficiency of any system. It defines how quickly the system should process the user’s requests and respond to them. Users often get frustrated while using low-performance systems, leading to high bounce rates.

Examples (Generative AI system)

• The system must respond to the user’s queries within 1.2 seconds.
• When typing the query in the input box, the latency should not be more than 500 ms.

2. Scalability requirements

Scalability is about the system’s ability to grow and still perform well. When system users or data processing requests increase, a scalable system works without needing a full system rebuild.

Scalability requirements are important for businesses accepting future growth or seasonal traffic surges. If scalability requirements are ignored, the system may crash when it can’t handle the load during peak traffic.

Examples

• The messaging system should continue to work smoothly even as the user base grows from 100,000 to 5 million active users.
• During the sale, the e-commerce store should be able to handle 10x traffic without any degradation in performance.

3. Availability requirements

Availability requirements describe how much time the system should be accessible to users. The high availability of the system significantly reduces downtime risks and improves the user’s trust. For some systems, even a few minutes of downtime can lead to the loss of millions of dollars, users, and reputation.

Example

• The online banking system should be available 99.95% of the time. For maintenance activities, the system may have a downtime of 30 minutes between 2 AM and 4 AM local time.

4. Portability requirements

Portability NFRs are about how easily the system can work with different environments, including operating systems, cloud providers, or devices. A portable system saves time and effort when shifting from development to production or expanding to new platforms.

Examples (Social media platform)

• An application should run on all mobile devices.
• Android and IOS users should get the same core features.
• The system should be container-ready (e.g., Docker) to support quick deployment on different cloud environments like AWS, Azure, or GCP.

5. Compatibility requirements

Compatibility NFRs define how well the system works with other systems, software, or hardware. This matters in environments where the system has to connect to APIs, databases, browsers, or third-party services. Poor compatibility can lead to broken features, user complaints, and integration issues.

Examples

• The screen-sharing option in a video conferencing application should work in mobile and desktop browsers.
• A project management tool should seamlessly integrate with various platforms like Google Calendars, Slack, etc., without users manually configuring it.

6. Reliability requirements

Reliability requirements assess how often the system works without failure, even during unexpected events. It’s important for applications such as banking software, healthcare systems, etc., which people use on a daily basis.

Examples (Hospital patient management system)

• The system should operate without failure for 99.95% of the time during any 30-day period.
• When the database connection fails, the system should retry three times to auto-recover.
• When the system crashes, it should roll back the latest deployment for recovery.

7. Maintainability requirements

Maintainability NFRs define how easily and quickly the system can be updated or fixed. It covers the time and resources required to maintain the system. Maintainability is always important in large-scale projects or products under constant improvement.

Examples (CRM system for sales teams)

• Any bugs should be fixed within 30 minutes.
• Developers must be able to deploy the new version or updates without affecting the active user sessions.

8. Security requirements

Security NFRs define how the system should protect and save sensitive user data from unauthorized access, security breaches, and cyberattacks. It mainly includes implementing authentication and encryption mechanisms to protect the data.

Examples (Stock trading application)

• The user’s data must be encrypted while making an API request between the frontend and backend of the system to update the data.
• Users must log in using two-factor authentication (2FA) for all financial actions.
• The system should lock an account after five failed login attempts and alert the user via email.

9. Usability requirements

Usability focuses on how easy it is for users to interact with the system. A product with high usability improves the user experience and can be adopted by new users with minimal training. Poor usability leads to frustration and increases support costs.

Example

• In the online food delivery app, all major actions (add to cart, apply coupon, reorder) should be accessible in 2 taps or less on mobile.

Why non-functional requirements matter: Real-world failures and lessons

Product development teams mainly focus on functional requirements but don’t pay attention to non-functional requirements. Teams think that if the feature works, it’s done. However, they don’t consider performance, reliability, security, and other NFRs.

Here’s how skipping non-functional requirements led to major failures in real-world systems.

Amazon: Outage During Prime Day (2018)

In 2018, Amazon faced a major outage during the Prime Day event. The number of site users unexpectedly increased, and the system could not handle them. Due to this, the Amazon website crashed, and buyers were getting error messages. Amazon lost almost $90 to $100 million during this 1-hour outage.

This outage happened due to poor scalability management. So, the system should always be ready to scale in every situation and must be available most of the time.

Knight Capital: Trading System Failure (2012)

In 2012, Knight Capital launched the trading software without proper testing. Within 45 minutes of launch, the system started placing bad trades that caused the company a loss of $440 million.

This system failure happened as software reliability was not tested properly, and there were no safety controls to stop the faulty actions.

TSB Bank: IT Migration Disaster (2018)

TSB Bank in the UK ran into serious trouble in 2018 after moving customer data to a new system. The data migration from the old platform to the new platform was successful. But after that, many customers couldn’t log in, some saw incorrect details on their profile, and a few users could see other people’s private data. In the end, the bank paid around £330 million to fix everything and lost customer trust.

The reasons behind this failure were poor system reliability and weak security measures.

Tips and best practices for writing clear non-functional requirements

As discussed previously, non-functional requirements are crucial for a project’s success. However, writing them correctly is challenging. Many teams run into common mistakes that can lead to delays or poor system behavior later. Teams should follow the best practices below to avoid common mistakes and write good software requirements.

1. Be specific and avoid vague terms: While defining the non-functional requirements, be clear and avoid any ambiguities. For instance, rather than saying, “The System should be fast,” say things like, “The System should load the dashboard in under 2 seconds for 90% of users.” This way, each team member can understand the clear goal of NFR.
2. Make all NFRs measurable and testable: Always set metrics or ranges to measure the success criteria. For instance, instead of stating that an application should have “High Scalability,” say, “The application should support 500 concurrent users without affecting the performance.” This helps teams track progress and ensure that the application successfully follows NFR.
3. Define NFRs for system components: Instead of defining a particular NFR for the whole system, define it for the specific component. For instance, while developing an e-commerce store, you don’t need to define scalability requirements for the admin panel if only a fixed number of admins are going to interact with it.
4. Collaborate with all key stakeholders: While defining non-functional requirements, involve all key stakeholders, including developers, QA testers, security teams, architects, product owners, and even end users where needed. Everyone has different aspects that can help in making NFRs stronger.
5. Connect requirements to business goals: Every NFR should serve a real purpose. If uptime, speed, or security help your company make money or keep customers, it must be clearly reflected in your requirements. Say “99.9% uptime to meet online order commitments” instead of just “high uptime.” This makes sure the team understands why the requirement matters.
6. Group NFRs into categories: Rather than having a long list of NFRs, group them based on the types, such as performance, reliability, scalability, and so on.
7. Use consistent formatting and terminology: Make sure to use a standard format to write requirements. You may define requirement ID, description, priority, and measurement criteria for each requirement.
8. Use the right tools to simplify the work: Use the right tools for requirements management. Modern Requirements4DevOps, a natively built-in requirements management solution within Azure DevOps, offers features like requirements traceability, version and variant management, document management, review management, etc.

Using Modern Requirements4DevOps to write better non-functional requirements documents

Documenting non-functional requirements is important to ensure each team member and stakeholder has a shared understanding of the project goals. With clear documentation, teams can minimize the risk of miscommunication, which can lead to costly rework.

Here, we have introduced a few key features of Modern Requirements4DevOps that can simplify the requirements documentation creation workflow.

1. Smart Docs: This module allows teams to create and manage living requirements documents directly within Azure DevOps. It offers a Microsoft Word-like interface to author and edit documents. Furthermore, it allows teams to link the requirements from backlogs to documents directly. So, whenever any requirements data is changed, it will be instantly reflected in the document.