What are non functional requirements:

How do I build them?

Creating consistent and worthwhile non-functional requirements can be a difficult process. In this article we cover how a simple 2-step template help your team build the requirements that will help you determine project success.

Client approval of Requirements in Azure DevOps

Building non-functional requirements tends to be a major point of contempt for many different teams from many different backgrounds and methodologies.

When building non-functional requirements, one of the major difficulties is identifying what a specific non-functional requirement (NFR) is being built for, and then how to easily articulate this.

In our in-depth what are non-functional requirements article, we cover in more detail what non-functional requirements are, and how building great NFR’s can help your team, stakeholders included, easily gauge the success of a project, process, or system from a particular viewpoint.

But even with that knowledge, defining these requirements can still be difficult task to complete.

For that reason, we’ve created this article to help you understand the more granular details of NFR creation and to give you both a template and examples that will help your team write NFR’s easily in only two simple steps.

Defining Project Attributes Using Non-Functional Requirements

To properly discuss examples of non-functional requirements (NFRs), we first need to understand the scope of this type of requirement.

Unlike their functional counterparts, non-functional requirements cover an incredibly broad scope. While a functional requirement specifies what a system should do exactly in a given scenario, the non-functional requirement instead specifies the overall qualities a project, system, or process should exhibit.

While these non-functional requirements might not “do anything specifically”, they do however outline concretely the attributes a system, process, or project must have on completion. Non-functional requirements will then be used 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.

As time goes on, teams, companies, and stakeholders will notice that their list of non-functional requirements will continue to grow. This is expected, as NFR’s will need to be created, changed and adapted as the needs of an organization change.

What can incite changes or additions to our list of NFR’s?

The need to add new NFR’s, or to change existing NFR’s, can stem from incidents such as: organizational changes, changes in implementation, 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 NFR’s. 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, Revisional, or Transitional. This means that teams will be able to easily identify the successes of a project from any of these perspectives.

You might have a specific non-functional requirement in mind right now and might be trying to identify whether it fits into the Operational, Revisional, or Transitional category.

Below we provide a breakdown of these categories into their relevant aspects.
This is the first step in building a non-functional requirement.

STEP 1 - Identify the Project Attribute for which you want to build a success indicator (non-functional requirement) for.

When building non-functional requirements, the first thing a team must consider is whether they are tackling the NFR’s that 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.
Since attributes fall into categories, here is a helpful list that will 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, NFRs fall into either the operational, revisional, or transitional attribute categories and are developed and refined by business analysts, developers, and project stakeholders.

NFRs can be product oriented, addressing specific attributes such as performance (aka how quickly and how much of something a system can complete) or the project’s costs.
Some NFRs are created to address criteria such as product longevity and growth, which are based on attributes such as 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 their own category; the examples above would be Operational, Revisional, and Transitional respectively.

After we have decided which attribute from these categories we are building success indicators for, we then move into writing our actual NFR’s.

STEP 2 - Construct your Non-functional Requirement.

NFRs may be broad and confusing to grasp for some, however they are just as critical to a project’s success as functional requirements.

While the functional requirement defines what a system should do, a non-functional requirement will define how we measure the success of any given piece of a system.

Therefore, the way we structure a non-functional requirement should indicate a few important pieces.

Non-functional requirement template

A – What is it are you measuring; is this an application, system, project, process?

B – What attribute are you measuring; is this scalability, maintainability, security…?

C – What is the goal, and what are the measures and metrics you are using to determine the goals success?

“The [insert answer to A] should be [insert answer to B] so that/to [insert answer to C]

 For example:

Scalability Non-functional Requirements
“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

In our what are non-functional requirements article, we cover the importance of a non-functional requirement having both a measure and a metric when possible.

Let’s consider building a non-functional requirement using the attribute reliability.

First, we know that reliability is an operational attribute.
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 as an attribute refers to a systems ability to consistently perform to its specification within its intended environment.

As we are trying to establish an NFR, or success indicator, 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:

A – What is it are you measuring? We are measuring a system.

B – What attribute are you measuring? We are measuring reliability.

C – What is the goal, and what are the measures and metrics you are using to determine the goals success?  We want 100% uptime in the first year. Our measure is 100% uptime, our metric is uptime/first year.

 “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.”

You can see that we have added more information about why this NFR has these particular criteria. Although this is an optional part of building non-functional requirements, it can be helpful to link an NFR to an initiative in order give it more context.

How Non-Functional Requirements help with Standardization

There are many instances where the creation of NFRs is required by regulation.

The best example of this is the highly regulated medical devices industry.

Specific requirements have been well defined by The International Organization for Standardization (ISO), and these well-defined non-functional requirements must be strictly adhered to during the development of medical.

Let’s take a look at how these 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

Modern Requirements tools for building compliant 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.

The creation of NFRs can be a difficult task. The scope of NFRs are both broad and complex and as a result even coming up with an example can be a difficult task.

This is an issue that many novice business analysts (BAs) face. NFR creation might also be a concern to veteran BAs who are gathering non-functional requirements in an unfamiliar space.

Modern Requirements4DevOps offers several tools that assist users with the 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. Questions can be answered using existing backlog work items or new backlog items can be created right from within the module. Users 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.

Recommended Posts