Developing high-quality products involves careful definition and tracking of both functional and non-functional requirements (NFRs). But what exactly are non-functional requirements? And what's the best way to keep track of them?
Let’s dive into what non-functional requirements are and how they compare to functional requirements, review some common types of non-functional requirements with examples, learn best practices for writing them, then discuss how to track and manage them.
[ToC]
What Are Non-functional Requirements?
Non-functional requirements are the criteria that define how a system should behave, rather than what it is supposed to do. Unlike functional requirements, which describe specific system functions, non-functional requirements define aspects like performance, security, usability, reliability, and scalability.
Another way to explain this is that functional requirements define the functionalities a system should have, while non-functional requirements define the characteristics. While a system can still work if non-functional requirements are not met, it may not meet user or stakeholder expectations, or the needs of the business.
Attributes that make the product affordable, easy to use, and accessible, for example, come from non-functional requirements. They also keep functional requirements in line, so to speak, since they often act as constraints or quality goals for functional requirements. For example, by defining performance as a non-functional requirement, you're essentially setting a limit on how complex certain functional features can be to ensure the overall system meets the desired performance standards.
Non-functional requirements are often considered alongside functional requirements when prioritizing backlog items. More on this later.
▶️ Related resource: Essential Tips for Modern Requirements Management
Types of Non-functional Requirements
Common types or categories of non-functional requirements (NFRs) include security, capacity, compatibility, reliability, and more. You can see why they are often thought of as the “-itys.”
While the specifics will vary between products, having a list of these NFR types defined up front provides a handy checklist to make sure you’re not missing critical requirements.
This is not an exhaustive list, but here is a breakdown of the most common types of non-functional requirements:
NFR “-itys”
Security — Does your product store or transmit sensitive information? Does your IT department require adherence to specific standards? What security best practices are used in your industry?
Capacity — What are your system’s storage requirements, today and in the future? How will your system scale up for increasing data storage volume demands?
Compatibility — What are the minimum hardware requirements? What operating systems and their versions must be supported?
Reliability and Availability — What is the critical failure time under normal usage? Does a user need access to this all hours of every day?
Maintainability and Manageability — How much time does it take to fix components, and how easily can an administrator manage the system? Under this umbrella, you could also define Recoverability and Serviceability.
Scalability – The Black Friday test. What are the highest workloads under which the system will still perform as expected?
Usability — How easy is it to use the product? What defines the experience of using the product?
The "-ity” requirements don’t cover all types of non-functional requirements, however. There are a few other types:
Other Common Types of Non-functional Requirements
Performance — How quickly does the system respond to users’ actions, or how long does a user wait for a specific operation to happen?
Regulatory — Are there specific requirements you need to satisfy for compliance in your industry?
Environmental — What types of environments will the system be expected to perform within?
Need help writing great requirements?
Learn 9 tips.
Non-functional Requirements Examples
Now that you understand the types of NFRs, let’s look at some actual examples of them:
| Type of Non-functional Requirement | Example |
| Performance | Each page must load within 2 seconds. |
| Performance | The process must finish within 3 hours so data is available by 8 a.m. local time after an overnight update. |
| Usability (Accessibility) | The system must meet Web Content Accessibility Guidelines WCAG 2.1. |
| Security | Database security must meet HIPAA requirements. |
| Security | Users shall be prompted to provide an electronic signature before loading a new page. |
| Scalability | The system should be able to scale to support up to 10,000 concurrent users. |
| Compatibility | The application must support the following operating systems: Windows 10 and above, macOS 10.15 (Catalina) and above. |
All of these add more specific restrictions or instructions to what would be functional requirements. Where the functional requirement defines the “what,” it often needs a non-functional requirement to define the “how.” So, you might see something like:
Functional requirement: When an order is fulfilled, the local printer shall print a packing slip.
Non-functional requirement: Packing slips shall be printed on both sides of 4”x 6” white paper, the standard size for packing slips used by local printers.
More Examples of Functional vs. Non-functional Requirements
| Functional | Non-functional |
| The system must send email notifications to users for specific events, such as account creation, password reset, and order confirmation. | The system must send email notifications within 1 minute of the triggering event. |
| The system must allow users to register, log in, and log out using a unique username and password. | The system must handle authentication requests within 2 seconds under normal load conditions. |
| The system must allow users to search for products using keywords. | The search feature must maintain performance as the number of products in the database grows. |
Learn essential tactics for better requirements management, from discovery to review and testing.
Prioritizing Non-Functional Requirements in the Product Backlog
While functional requirements (what the system does) often take the spotlight in backlog prioritization, non-functional requirements (how well the system does it) are increasingly recognized as equally important.
Here's why:
User Experience: Non-functional requirements like usability, performance, and accessibility directly impact user satisfaction and adoption.
Business Value: Factors like security, reliability, and scalability contribute to the overall value of the system.
Risk Mitigation: Addressing non-functional requirements early can prevent costly issues later in the development cycle.
Compliance: Meeting regulatory and industry standards is often a critical non-functional requirement.
Best Practices for Writing Non-functional Requirements
Our blog on functional requirements outlines some tips on how to write requirements well, and they apply to both functional and non-functional requirements. Some tips include:
- Be consistent, both in terminology and format.
- Quantify requirements. If a stakeholder requires a website to load “quickly,” define exactly what that means (3 seconds or less? 2 seconds or less?).
- If you intend to reuse the requirement, write it in general enough terms to allow it to be reused. For example, use “accept payment” rather than “accept payment through Apple Pay."
Changes to requirements may be inevitable. But after all the work you put into writing your requirements, you need to ensure that you won't get bogged down by excessive changes, also known as requirements churn. Requirements churn can negatively impact cost, quality, and your team's ability to meet deadlines.
📘Get the Guide: 5 Best Practices for Reducing Requirements Churn
How to Manage Non-functional Requirements
Many smaller organizations start out by tracking requirements in text documents and spreadsheets, since this software is already available to them and is the easiest to get started with.
As an organization and its projects grow, though, trying to track requirements with spreadsheets and docs is not going to cut it. They can't scale to meet the needs of complex product development. They are time-consuming to maintain, they inadequately support traceability, and their susceptibility to human error can put an organization at serious risk of project delays, or worse — non-compliance.
At a certain point, a dedicated tool for requirements management becomes a necessity.
If your team is exploring requirements management solutions for traceability & compliance, check out our Requirements Management Software Buyer’s Guide. >>
Helix ALM — application lifecycle management from Perforce — offers development teams a unified requirements and test management platform. Because it’s a modular tool, teams who only need a requirements management tool can start with that module only, then add on test case and issue management if needed.
Helix ALM's dedicated requirements management module provides end-to-end traceability across the entire product development lifecycle — automatically. It can scale to support the most complex products and projects, improve alignment around requirements and changes, and allows you to link requirements to test cases, source code, and more for complete visibility of product quality.
See Helix ALM In Action
Watch a demo to see how Helix ALM streamlines and simplifies requirements management with:
- Automatic, end-to-end traceability.
- Easy-to-configure workflows — even for dynamic, multi-level needs.
- Test case management that is automatically traced back to requirements.
- Built-in risk tracking accommodations for FMEA, ASIL, Hazard Analysis, and others.
Editor's Note: This blog was first published in August 2020 and was updated for quality and accuracy in August 2024.