How to Make an NFR (Non-Functional Requirement)
Your organization’s NFRs can impact time overruns, user satisfaction, compliance, and many other issues. But knowing how to make an NFR is difficult.
It is hard because building non-functional requirements can be a major point of contention for different teams with different backgrounds and methodologies.
Even then, <customers> can struggle to manage the demands or multiple teams, third-party software limitations, organisational quirks, and other business priorities that can get in the way.
For that reason, this article covers what NFRs are and how to build them, with examples and templates to guide you along.
What is an NFR?
If you open the texting app on your phone, you will notice a few functions. They include texting, emojis, editing contacts, and others. They define what the app does. But these functions work because of several requirements that define how they will work. For example, texting only works if your phone is compatible with all major carriers.
These aspects that define how a system will work by laying out its requirements and limitations are called Non-functional Requirements (NFRs).
They are contrasted with functional requirements, which set the primary function of a system. If the functional requirement of your car is to seat four people in comfort, a non-functional requirement is the size of each headrest.
Why Should You Change or Add To Your List of NFR’s?
As time goes on, teams, companies, and stakeholders will notice that their list of non-functional requirements will grow and change. This is expected as the needs of an organization adapt and change.
You may need to add, remove, and change NFRs in response to organizational changes, implementation changes, or even changes in business needs.
Regardless of how small or extensive these changes may be, a team can easily identify how implementing a change might affect their success measures by re-evaluating their NFRs. Teams may notice that a small implementation change could lead to a completely new NFR that will help them identify a project’s success.
As teams continue to expand their list of non-functional requirements, you might be wondering how do they keep this expanding NFR list organized?
Teams keep their NFR’s organized by using categories with which they can evaluate overall success. A typical grouping of non-functional requirements would be:
Operational NFRs, like security, accessibility, and usability
Revisional NFRs, like flexibility and scalability
Transitional: NFRs, like portability, reusability, and interoperability
Step 1: How Do You Define Project Attributes Using Non-Functional Requirements?
When setting up a project’s requirements, you must set the following conditions:
Aim
A best practice when setting NFRs is establishing measurement benchmarks. But what do your measurement benchmarks (e.g., headrest size) work towards? Ultimately, any requirement has to work towards fulfilling larger business objectives.
These objectives can be very specific, like hitting quarterly revenue targets. Sometimes they can also be less empirical, like building a brand. In both cases, your NFRs should work towards fulfilling your company’s business needs.
Scope
Unlike their functional counterparts, non-functional requirements cover an incredibly broad scope. In defining the overall qualities, a project, system, or process should exhibit, the list of non-functional requirements can grow very large
While these non-functional requirements might not “do anything specifically,” they do specify the attributes a system, process, or project must have on completion. You can then use these non-functional requirements to measure the overall success of a given project, process, or system, and provide measurable insights into how close to completion our project might be.
Step 2 - For Which Project Attribute Are You Building an NFR?
When building non-functional requirements, the first thing a team must consider is whether they are tackling the NFR’s that are relevant to the project. This makes the first step of the process simple.
Identify the project attribute for which you want to build success indicators. Here’s a more exhaustive
breakdown some of the Operational, Revisional, and Transitional aspects of a project.
Operational attributes:
- Security
- Accessibility
- Efficiency
- Reliability
- Survivability
- Usability
- Availability
- Confidentiality
- Integrity
- Safety
Revisional attributes:
- Flexibility
- Maintainability
- Modifiability
- Scalability
- Verifiability
Transitional attributes:
- Installability
- Interoperability
- Portability
- Reusability
Typically, business analysts, developers, and project stakeholders develop and refine NFRs.You can tune NFRs to be product oriented, addressing specific attributes such as performance (like processor speed on a phone) or the project’s costs.
Some NFRs are created to address criteria like product longevity and growth, which are based on attributes like the modifiability of a product. Other non-functional requirements could be process facing attributes that define aspects of a product such as its reusability.
Each of these non-functional requirements will fall into either the Operational, Revisional, or Transitional categories respectively.
The next step after deciding the actionable attribute is learning how to make an NFR.
Step 3 - How to Make an NFR
- What are you measuring? Is it an application, a system, a project, or a process?
- What attribute are you measuring? Is it scalability, maintainability, security, or something else?
- What is your goal?
- What metrics are you using to determine success?
- “The system should be scalable to 10,000 users within the next 2 years.”
- “The application should be scalable to handle 10,000 concurrent logins per minute”
You can also build a non-functional requirement using an operational attribute like reliability.
As always, operational attributes of a project are concerned directly with the operational functions of the project from both the system and the user’s perspective. Reliability here refers to a system’s ability to consistently perform to its specification within its intended environment.
As we are trying to establish an NFR for our system, understanding that this is an operational attribute helps us understand how we can make our NFR measurable to make it achievable.
This requires the application of both a measure and a metric where possible. Some common examples of a metric that would apply to reliability is mean time to failure, probability of failure, or a level of uptime per degree of time.
If we wanted to create a reliability non-functional requirement using our NFR template, we can ask the following questions with their respective answers
- Whatare you measuring?
“We are measuring a system.” - What attribute(s) are you measuring?
“We are measuring reliability.” - What is the goal?
“We want 100% uptime in the first year.” - What are the measures and metrics you are using to determine the goals success?
“Our measure is 100% uptime, our metric is uptime/first year.”
You can condense these answers into one statement:
“The system should be operational so that we see a 100% uptime for the first year of operation in order to meet our 1-year performance guarantee.”
Adding some more information about why this NFR has these criteria as above is option. But it can be helpful to link an NFR to an initiative in order give it more context.
Despite the template, it’s always possible to forget to add non-functional requirements. You should take appropriate caution in that case.
How Non-Functional Requirements Help with Standardization
There are many instances where regulatory and compliance issues require the creation of NFRs.
For instance, in the highly regulated medical devices industry, confidentiality (an operational attribute) is paramount .
Specific requirements have been well defined by The International Organization for Standardization (ISO). These well-defined non-functional requirements must be strictly adhered to during the development of any medical device.
Let’s take a look at how these ISO-mandated requirements are categorized, and discuss some tools used to build compliant NFR’s quickly and easily.
ISO 13485 – Medical Devices –Quality Management Systems – are comprised of NFRs based on:
- Management Controls
- Product Planning
- Quality Process Evaluation
- Resource Control
- Feedback Control
ISO 14971: 2007 – Medical Devices – Application of Risk Management to Medical Devices – are requirements related to:
- Management Responsibilities
- Risk Analysis Process
- Risk Control
- Risk Management Process
- Risk Management Report
Tools for Building Effective NFR’s
Due to the broad and complex nature of NFRs, even creating examples of non-functional requirements is a difficult task. This can be especially true for novice business analysts (BAs) and even for veteran BAs who are gathering non-functional requirements in an unfamiliar space.
The elicitation of the correct NFRs is integral to asking the right questions. To do so, BAs must use social science derived data-gathering techniques like interviews, focus groups, surveys, brainstorming, and more
The next step isn’t much easier. Coming up with an example is an issue that many novice business analysts (BAs) face. Even veteran BAs are gathering non-functional requirements in an unfamiliar space can struggle.
But by using cutting-edge tools like Modern Requirements4DevOps, you can assist users with elicitation, authoring, and management of non-functional requirements.
Modern Requirements4DevOps’ FAQ module enables users with the ability to review focused question lists based on specific attributes of each of the four aspects of a project. These question lists provide the user with examples of questions that can be asked to elicit strong non-functional requirements based on each attribute.
The tool is preloaded with over 2500 questions found within 29 topics. By answering questions, users are building their non-functional requirements. Stakeholders can answer questions using existing backlog work items. Or users can create new backlog items right from within the module. They also have the freedom to make new questions and build their own custom question lists.
Interested in seeing for yourself?
Try Modern Requirements4DevOps today and build non-functional requirements using pre-built question lists that address topics such as ISO compliance, and more.
Experience for yourself how our Modern Requirements toolbox can empower Microsoft’s industry leading Azure DevOps into a single application requirements management solution.
Time to Read: 15 minutes
Author: Arunabh Satpathy
