Non-Functional Requirements Explained (With Real Examples)

Requirements that define how a system will work by laying out its operations and limitations are called non-functional requirements (NFRs).

The differences between a functional and non-functional requirement can be confusing, but using proper, measurable, and well-defined non-functional NFRs can help your projects succeed.

NFRs are as important as functional requirements, perhaps even more important. They are unlike functional requirements, which describe what a system or product actually does, and its response to inputs and actions.

Non-functional requirements describe how well a system functions. They create the basis for how a system feels. Most modern companies using application lifecycle management tools like Jira or Azure DevOps use NFRs these days. They’re also turning to new methodologies like Agile and BABOK to adapt to the changing market.

By defining how variables related to the system’s primary functions contribute to their aim, NFRs can be a key part of the overall user story. You can easily measure well-defined NFRs and test them against their success metrics. Teams can also gain insight into their progress without having reached a conclusion with NFRs.

Both types of requirements are important to successfully develop and launch a product or system. This article covers non-functional requirements in detail, including how they work, their different varieties, and their deployment in Azure DevOps.

Table of Content

Comparing Functional and Non-Functional Requirements
- Functional Requirements – What Should It Do?
- Non-Functional Requirements – How Should It Be?
Quantitative vs. Qualitative NFRs
Measure vs. Metric – Quantification is Key
- Measure
- Metric
Operational, Revisional, and Transitional
- Scalability
- Survivability
Azure DevOps and Non-functional Requirements
The Role of Modern Requirements4DevOps
Conclusion

Get a personalized demo and find an efficient way to

Improve Your Requirements Lifecycle Significantly

Comparing Functional and Non-Functional Requirements

The traditional comparison between functional and non-functional requirements is as follows:

Functional requirements apply to the specific behaviors of a system.
Non-functional requirements are measurable criteria that you can use to evaluate the success of an overall system, solution, or product.

Both types are essential parts of a well-defined requirements management strategy.

Functional Requirements – What Should It Do?

Functional requirements are requirements that define product features or functions that allow users to accomplish their tasks on a system.

Functional requirements are often simple to define, measure, and test. They are more easily described as requirements which tell a particular system to perform a specific function.

Functional requirements are typically less abstract than NFRs and generate very little confusion. If you asked someone to write a requirement, they would more likely create a functional requirement.

A functional requirement of a car sensor might be that the car should be able to stop from 60 miles per hour within 120 feet.

Non-Functional Requirements – How Should It Be?

NFRs define how a system will work with its operations and limitations.

But NFRs are usually more difficult to define, measure, test, and track. Because of this, teams may end up using only functional requirements or constantly re-evaluate their non-functional requirements for correctness.

Because NFRs act as the descriptor of success for a project, process, or system, any team that doesn’t explicitly define them will struggle to meet its objectives. Even so, they are important background components enhancing the overall user story. In our experience, they can even help maintain compliance.

For instance, an NFR for a car could say that its headlights should have a brightness of at least 10,000 lumens. This requirement doesn’t directly relate to the function of the headlights (i.e., turning on and off). But it does describe a characteristic of their performance – brightness level.

Teams should begin by defining their non-functional requirements for a wide variety of system characteristics. These characteristics are categorized within the three (3) following aspects of a system:

Operational NFRs
Revisional NFRs
Transitional NFRs

Many familiar characteristics fall into the operational category such as security, accessibility, and usability. Many other characteristics are focused entirely on the health and longevity of a product or system such as scalability, testability, and maintainability.

By covering every category and all aspects of each category, you can build non-functional requirements that give a goal for the system, process, and/or products that your team is involved with creating.

Quantitative vs. Qualitative NFRs

To help teams measure the success of a system, you must first make a non-functional requirement measurable.

NFRs tend to be qualitative as they are built to define attributes or qualities of a system.

You can phrase it as:

“The system should be scalable to handle enterprise expansion.”

Although the above is a valid non-functional requirement, it is not testable or easily measured. It may lead teams to build only qualitative NFRs without considering the application a quantitative measurement might have.

Adding quantitative values gives it a more definite measure of success for that requirement.

You could rephrase the above-mentioned example as:

“The system should be scalable to 10,000 users within the next 2 years.”

Making it easier to measure and test allows you to better understand if a project is successful around the time it’s ending. The way you structure a non-functional requirement should answer a few important questions:

What are you measuring? Is it an application, a system, a project, or a process?
What attributes are you measuring? Is it scalability, maintainability, security, or something else?
What is your goal?
What metrics are you using to determine success?

You can condense these answers into one statement:

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

Building well-defined non-functional requirements can be tricky and their scope can be massive. But not having the right ones is also risky, as we have shown in our webinar.

Not all NFRs need to be quantitative. In fact, qualitative and quantitative metrics can work together to meet your business goals. It is important to understand what the quantitative value represents and how that makes requirements more measurable. We have also shown some simple ways to reduce the time it takes to elicit them.

Measure Vs Metric

Requirements management metrics have a big effect on overall project success. But before you set up your metrics, it’s important to know the difference between measures and metrics.

Measure

When building NFRs with quantitative values, you must give both a metric, whether they are measured qualitatively or quantitatively depends on the requirement itself.

A measurement is an observation that includes a value that represents a snapshot in time. In business, it is used to the amount or degree or something. Common measures include sales, revenue, cost, active daily users, etc.

A measure helps set the target value used to determine how close a system comes to fulfilling an NFR.

Metric

A metric is a value derived by comparing two different measures. In business, it is used to assess a specific business process and judge its performance. Common metrics include inventory turnover, customer lifetime value, and employee turnover.

When building NFR’s, we use metrics to evaluate what a particular value means in relation to our goal.

Now, let’s apply this knowledge to improve the NFRs that we create.

In this example, adding quantitative values with both a measure and metric can yield easily testable and measurable NFRs which demonstrate the success of a project.

There are instances when providing both a metric and a measure might not apply to a non-functional requirement. For instance, let’s look at our previous example: “The system should be scalable to 10,000 users within the next 2 years.”

By swapping “allow multiple users” with “scalable,” this NFR is better than the qualitative version of the same requirement.

But there is no way to measure this non-functional requirement. That’s okay because we don’t need to. The purpose of improving NFRs is to set specific criteria that we can test and measure.

The quantitative requirement above does not include a metric but is still fully measurable and testable. We can for instance, measure in two years whether a system supports an ecosystem of 10,000 users.

Defining proper non-functional requirements allows us to test and measure the success of any given project, process, or system. By defining their success, you can assess the quality of your software more easily.

But modern companies have hundreds of NFRs in a project. So, you must categorize them to build them efficiently. That’s why non-functional requirements are divided into three big categories.

Operational, Revisional, and Transitional

Aspects of a system like scalability, durability, and reliability offer dozens of ways to group requirements. You don’t have to take each category during the development of a product, system, or process into account.

But there are several system aspects that you can group together into larger categories to measure success effectively. They are:

Operational Aspects, Revisional Aspects, and Transitional Aspects.

Let’s look at two examples of aspects that teams address when categorizing their non-functional requirements:

Scalability

Scalability is the revisional aspect of a piece of software, a product, or a process.

It refers to the ability of a product to scale (either up or down) to meet the usage demands imposed by its user base. Your team should consider scalability during the design phase of any product. If a product or system is well received, it should be ready to scale. An example could be that an ecommerce website should handle at least 15,000 users during peak hours in the holiday season without affecting performance.

Scalability can relate to concurrent users, throughput, storage, or anything within the architecture of software that surpasses base specifications of the product. This is not a basic requirement of any product. But it gives flexibility to a product to appropriately react to growth and changing user demands.

Project planning without proper consideration of scalability could hinder your product from doing well. Scalability requirements are important to consider during the early stages of your product’s development.

Establishing strong scalability requirements can help your team define how to measure the success of your system’s ability to scale.

A well-defined scalability related NFR could say, “The system shall be scalable to support 10,000 concurrent users while maintaining the performance requirement of a 0.1 second response time.”

Survivability

Survivability is an operational aspect of a piece of software, a product, or a process.

It refers to the ability of a product or system to continue to operate and recover when experiencing a failure. This could be a failure caused by physical damage to hardware like a medical device or a digital attack on a system such as a DDoS attack.

When developed properly, survivability NFRs directly impact how teams assess the success of a physical product’s build quality and durability.

A well-defined software survivability NFR could say, “The system can prevent users from accessing a function of the system that is experiencing failure while still granting users access to unaffected functions.”

A well-defined hardware survivability NFR could say, “The product will still operate at 100% of its functional capacity if it is submerged in water up to 30 meters for 1 hour.”

Product marketing teams frequently use NFRs as major selling points. For example, watch companies and electronics manufacturers advertise the water-resistant rating of their products.

Azure DevOps and Non-functional Requirements

Microsoft’s Azure DevOps is one of the world’s premiere Application Lifecycle Management tools today.

Here, teams can leverage the platform’s flexibility to make requirements of any type.

NFRs are among the work item types you can create in Azure DevOps. You can configure non-functional requirements to house any variation of configurable fields, allowing them to contain any data important to your team. Within ADO, they are stored and treated no differently than any other requirement (epic, feature, user story, etc.).

Azure DevOps also supports the ability to configure your project backlog to easily show non-functional requirements where needed in your project.

But ADO falls short on several functionalities. Among others, there are no elicitation tools, no way to create and share documents, or do trace analysis.

The Role of Modern Requirements4DevOps

Modern Requirements4DevOps (MR4DevOps) helps you build non-functional requirements and offers several solutions to aid in the non-functional requirements management process. There is a tool for every stage of an NFRs lifecycle: Elicitation, Authoring, Document Creation, and Management.

Frequently Asked Questions (FAQ)

Building strong NFRs is based on asking the right questions. Due to their abstract nature, this isn’t always a simple task. MR4DevOps lets users elicit their NFRs with the FAQ module.

The FAQ module is a series of focused question lists grouped by system attribute and categorized by the three (3) aspects of the product:

Operational
Revisional
Transitional

By answering questions from the list, you are authoring well-defined NFRs added to your Project Backlog. Users can modify existing lists by adding or removing questions and have the option of creating their own custom FAQ lists. The FAQ module also contains question lists to elicit compliance and risk based NFRs for medical device development.

Smart Docs

If documentation is part of your process, MR4DevOps’ Smart Docs gives you a single source of truth for your requirements documentation needs.

SmartDocs enables users to build non-functional requirements documents directly within Azure DevOps. You can insert existing NFRs directly from your backlog or author new ones on-the-fly while you build your Smart Doc. You can also build fully formatted documents using Smart Docs’ rich text editing functionality.

If your documentation process demands structure and consistency, you can employ reusable templates or tailor your specifications using the template designer. Additionally, a full version management feature is integrated directly into Smart Docs allowing users to quickly produce and output change documents.

Reuse

Storing your well-defined NFR’s within a repository for later reuse is a best practice in requirements management. But, retrieving stored requirements and implementing them within a new project is a bulky process. MR4DevOps solves this problem with its highly efficient Reuse tool.

This tool allows users to copy existing work items from a project and insert them into new or existing projects within your collection or even across servers. You will never have to rebuild your well-defined NFRs again.

You can also manage and store your NFRs directly within Azure DevOps. MR4DevOps’ Reuse Work Item tool gives users freedom from managing external repositories, using outside applications, and the tedious copy and paste process.

Trace Analysis

In terms of project management, accurate traceability of your non-functional requirements is one of the biggest challenges encountered by teams. Manually creating traceability matrices is a tedious, time-consuming, and error prone process. Projects typically evolve at a rate that renders them outdated. MR4DevOps’ Trace Analysis tool empowers users with the ability to create traceability matrices that show project coverage within seconds.

The Trace Analysis tool allows you to display and manage end-to-end traceability of your NFRs. Trace any relationship that exists between your project’s NFRs and any other requirement. Relationships between NFRs and other project requirements can also be created using the Trace Analysis tool.

MR4DevOps gives project managers an effective solution to one of the bulkiest processes in requirements management. Reclaim time lost to traceability. With MR4DevOps, traceability matrices can be built within seconds and are never out of date.

Conclusion

Non-functional requirements are an underappreciated but often critical part of application development. Done well, they have far greater depth and impact on your project than their functional counterparts. They can take your product, system, or service’s user experience to the next level.

MR4DevOps can help you elevate your NFR management capabilities with a set of tools that offer you support at every stage of your project. Contact us to find out how we can help you and your team with your goals.