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?
Continue reading to learn what non functional requirements are and to find types and examples of non functional requirements — or skip ahead to the section that interests you most:
Table of Contents
- What Are Non Functional Requirements?
- Types of Non Functional Requirements
- Non Functional RequirementsExamples
- Best Practices for Writing Non-Functional Requirements
- How to Manage Non Functional Requirements
MANAGE REQUIREMENTS IN HELIX ALM
Back to top
What Are Non Functional Requirements?
Non functional requirements are the criteria that define howa 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.
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.
Non functional requirements also keep functional requirements in line, so to speak. Attributes that make the product affordable, easy to use, and accessible, for example, come from non functional requirements.
Let’s get more specific.
Essential Tips for Modern Requirements Management | Perforce
Back to top
Types of Non Functional Requirements
There are many common categories of non functional requirements.
Non functional requirements (NFRs) 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’s what we mean:
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?
Maintainabilityand 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.
Need help writing great requirements?
📖 Get the Guide:
9 TIPS FOR WRITING USEFUL REQUIREMENTS >>
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?
Back to top
Non Functional RequirementsExamples
Now that you understand the types of NFRs, let’s look at some actual examples of non functional requirements:
- Each page must load within 2 seconds.
- The process must finish within 3 hours so data is available by 8 a.m. local time after an overnight update.
- The system must meet Web Content Accessibility Guidelines WCAG 2.1.
- Database security must meet HIPAA requirements.
- Users shall be prompted to provide an electronic signature before loading a new page.
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.
Learn essential tactics for better requirements management, from discovery to review and testing.
▶️ Watch the webinar now:
ESSENTIAL TIPS FOR MODERN REQUIREMENTS MANAGEMENT >>
Back to top
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 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."
For the full list, and more on functional requirements, read the blog >>
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.
Keep requirements churn in check.
Download the white paper: 5 Best Practices for Reducing Requirements Churn
SAVE MONEY with reduced churn
Back to top
How to Manage Non Functional Requirements
With the many types of non functional requirements you need to keep track of, plus functional requirements, trying to track requirements with spreadsheets is not going to cut it. Spreadsheets can't scale to meet the needs of complex product development.
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 allow you to link requirements to test cases, source code, and more, for complete visibility of product quality.
Ready to see it in action? Watch the on-demand demo now to see how Helix ALM simplifies requirements management, automates traceability, and so much more.
SEE TRACEABILITY IN HELIX ALM
Editor's Note: This blog was first published in August 2020 and was updated for quality and accuracy in March 2023.
Back to top
