What are Non-Functional Requirements?
As the use of non-functional requirements has evolved, the differences between functional and non-functional requirements have become much less apparent.
In this article we discuss the ways many ways in which having proper, measurable, and well-defined non-functional requirements can lead your projects to success.
What does your team need to know about
There is an argument to be made that non-functional requirements are as important as functional requirements. Perhaps they are even more important. The implementation of well-defined non-functional requirements can be used to gauge the overall success of a project. Unlike functional requirements that direct the system on a functional level, non-functional requirements create the basis for a how a system feels.
This represents itself in what is generalized as “user experience”. Well-defined non-functional requirements are easily measurable and can be tested. This way they can be used to evaluate a project’s success and give teams insight on how close their project comes to success. Additionally, well-defined non-functional requirements provide teams with the ability to test the outcome of a system, project, or process against their success factors.
So, what are non-functional requirements? To answer this question, we need to comprehend what a non-functional requirement is composed of. Developing an understanding of the differences between a functional and non-functional requirement is the best place to start.
TABLE OF CONTENTS
Functional Vs Non-Functional
The traditional comparison between functional and non-functional requirements is as follows:
Functional requirements apply to the specific behaviors of a system, whereas non-functional requirements form measurable criteria that can be used to gauge the success of an overall system, solution, or product.
Functional Requirements – What should it do?
Functional requirements are often simple to define, measure, and test, and they can be most easily described as requirements which instruct a specific system to perform a specific function.
When comparing non-functional and functional requirements, functional requirements are typically less abstract and generate very little confusion. Often if you asked someone to write a requirement, the default requirement they would create would be a functional requirement.
It might be easiest to think of functional requirements as the “WHAT SHOULD IT DO” aspects of your system. For example: As a user, when I launch the application, I should be provided with a user login screen.
Non-Functional Requirements – How should it be?
Non-functional requirements are traditionally the requirements that are more difficult to define, measure, test, and track. In many cases this can lead to teams using only functional requirements or having to constantly evaluate their non-functional requirements for correctness.
Despite this, properly constructed non-functional requirements are instrumental in understanding the successes of a given project, process, or system. This is because the role of any non-functional requirement is to act as the descriptor of success for a project, process, or system.
We can view non-functional requirements then, as the set of requirements that define the “HOW SHOULD IT BE” aspects of your system.
For example: All help text, in-application and documentation, will be provided in English, French, and Spanish.
When defining purposeful non-functional requirements (NFR’s), teams should begin by defining their non-functional requirements for a wide variety of system attributes. These attributes are categorized within three following aspects of a system:
- Operational NFR’s
- Revisional NFR’s
- Transitional NFR’s
Each aspect of your system will fall into either these operational, revisional, or transitional categories of requirements. Many familiar attributes fall into the operational category, such as security, accessibility, and usability. Many other attributes exist that are focused entirely on the health and longevity of a product or system such as scalability, testability, and maintainability.
By building non-functional requirements categorically, and by ensuring you are covering every aspect of each category, non-functional requirements can be built that provide a goal for the system, process, and/or products that your team is involved with creating.
In a way, both functional and non-functional requirements are goals that dictate what needs to be achieved by the system, process, or product. However, building non-functional requirements specifically that are well-defined, measurable, and testable allows teams to quickly and definitively measure the success of any project.
Quantitative Vs Qualitative
For non-functional requirements to help teams measure the success of a system, a non-functional requirement must first and foremost be measurable.
Because non-functional requirements are built to define attributes or qualities of a system, they are by nature qualitative. This can lead teams to building only qualitative NFR’s without considering the application a quantitative measurement might have.
For instance, let’s take the example of a non-functional requirement that could be made quantitative to reinforce the purpose of NFR’s.
Qualitative NFR – “The system should be scalable to handle enterprise expansion.”
Although this is a valid non-functional requirement it is not an easily measured requirement, nor is it testable. By adding quantitative values to this non-functional requirement, we can make a more definitive measure of success for that requirement.
Quantitative NFR – “The system should be scalable to 10,000 users within the next 2 years.”
By quantifying the non-functional requirement, we make a requirement that is more easily measured and tested which can translate to a better understanding of what the success of a project should look like. As teams draw closer to project end, quantitative non-functional requirements can provide a better picture of how close a project is to being successful.
A simple solution to moving towards proper NFR definition is to replace any subjective measurement (i.e. good or great) and replace these with well-defined quantitative values.
Admittedly, building well defined non-functional requirements can be tricky, and the scope of non-functional requirements in general can be massive.
For instance, a non-functional requirement can be built that says a system should automatically display in the local language of where it is being used. Another valid NFR can also apply to the aesthetic of a product, i.e. the application’s UI color scheme should match our company’s branding.
Finding quantitative values for these types of non-functional requirements can seem like a daunting task, but it is important to note that not all NFR’s require quantitative values.
If we intend to make better non-functional requirements, it is important to understand what the quantitative value will represent and how will that make our requirement more measurable.
Measure Vs Metric
Non-functional requirements must be measurable.
In our previous section we covered how adding a quantitative value can help an NFR become both measurable and testable. When we build NFR’s with quantitative values, we must do so mindfully by providing both a measure and a metric when possible.
So how do measures differ from metrics and how do we apply this?
When we evaluate the success of a non-functional requirement, we do so by taking a measurement. A measurement will produce a numerical observation that includes a value (the degree of something) accompanied by a relationship that describes what that value represents.
When building NFR’s, providing a measure will allow us to see the target value used to determine how close a system comes to fulfilling an NFR.
The relationship that exists between that value and our goal will be our metric.
When building NFR’s, we use metrics to evaluate what a particular value actually means in relation to our goal.
Let’s look at how we can apply this knowledge to improve the NFR’s that we create.
With this simple example we can see how adding quantitative values with both a measure and metric can yield easily testable, and measurable NFR’s which dictates the success of a project.
There are however instances where providing both a metric and a measure might not apply to a non-functional requirement. For instance, let’s revisit the example from our previous section.
“The system should be scalable to 10,000 users within the next 2 years.”
This NFR is better than the qualitative version of the same requirement.
However, there is no applicable metric for this non-functional requirement, nor is there a need for one. The goal of building better NFR’s is to create testable, and measurable criteria for our non-functional requirements that help us determine project success.
The quantitative requirement provided 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 being able to define the success of these, we are more easily able to gauge the quality of the software we produce.
Having definitive non-functional requirements provides teams with the ability to assess the quality of the software they produce.
Software quality assurance has become more important than ever.
With distributed teams, multi-functional teams, and more software applications being depended on than ever before, any contribution to the quality of software being produced is a major one.
So far, we covered that non-functional requirements help to identify the overall goals of a system, process, or product. We also know that well-defined, quantitative NFR’s allow teams to easily assess a project’s degree of success in specific areas.
But what are these areas?
When building non-functional requirements, we do so by identifying the aspect of our system we want to set goals for. An aspect could be durability, reliability, or scalability and we could build specific non-functional requirements that help us ensure the quality of what we create based on that context.
As we build NFR’s for each aspect of our system, we increase our ability identify how well our software performs in that context.
If we have 50 quantitative non-functional requirements that detail how our system should perform in terms of reliability, if all these NFR’s are met at project completion then we can feel confident that the quality of our software will be high in that aspect (reliability).
As NFR’s are built to address individual aspects they provide a context for us to use when assessing a software’s quality. The aspects that are typically addressed for non-functional requirements can yield many contexts with which to evaluate a project.
It is for this reason that we categorize attributes that are used to derive non-functional requirements (such as scalability, reliability, durability, etc.) into three major categories.
Categorizing Non-Functional Requirements
Non-functional requirements need to be categorized.
By categorizing NFR’s, teams can easily contextualize which aspects of their system are meeting their software quality expectations.
Recall that system aspects are how we group our requirements into non-functional topics such as reliability, durability, and scalability. When we know the aspects that relate to our system, we can more easily define the relevant non-functional requirements for our project. We can then use those NFR’s to assess the success of a project in the context of that aspect.
While aspects of a system such as scalability, durability, and reliability offer non-functional topics in which we group requirements, there are several system aspects that can be grouped together to form a greater context with which we can gauge the success of our project.
There are three categories we use to group the non-functional aspects.
There is no rule that says each category must be considered during the development of a product, system, or process. However, the development of well categorized non-functional requirements will greatly improve the quality of your product and allow teams to easily gauge the project success from any context.
Let’s look at a couple of the common aspects that teams address when categorizing their non-functional requirements.
Scalability is a revisional aspect of a piece of software, a product, or a process.
Scalability refers to the ability of a product to scale (either up or down) to meet the usage demands imposed by its user base. Scalability should be considered during the design phase of any product. If a product or system is well received, it should be ready to scale.
Project planning without proper consideration of scalability could hinder your product from doing well. Therefore, scalability requirements are important to consider during the early stages of your products development.
Scalability requirements are non-functional requirements and should therefore be both measurable and easy to track. Establishing strong scalability requirements can help your team define how to measure the success of your system’s ability to scale.
The system shall be scalable to support 10,000 concurrent users while maintaining the performance requirement of a 0.1 second response time.
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. However, it provides flexibility to a product to appropriately react to growth and changing user demands.
Survivability is an operational aspect of a piece of software, a product, or a process.
Survivability refers to the ability of product or system to continue to operate and recover when experiencing a failure. This could be a failure caused by physical damage to a product or a digital attack on a system such as a DoS attack.
Non-functional requirements are an important part of the development of software, but also play a crucial role in gauging the success of hardware components as well. Survivability NFR’s for example, when built properly will directly impact how teams gauge the success of a physical product’s build quality and durability.
The system can prevent users from accessing a function of the system that is experiencing failure while still granting users access to unaffected functions.
The product will still operate at 100% of its functional capacity if it is submerged in water up to 30 meters for 1 hour.
Survivability requirements are can in fact be seen frequently in product marketing.
Many non-functional requirements can be spun as major selling features for a product. For example, the water-resistant rating of watches and electronics such as cellphones and cameras.
Some cellphones are marketed as being able to operate when submerged up to 3ft for 30 minutes. From a product development standpoint, this is a survivability based non-functional requirement that has been achieved and is now being used as a primary selling feature of a product!
Non-Functional Requirements and Azure DevOps
In Azure DevOps teams can leverage the platform’s flexibility to make requirements of any type.
Non-functional requirements are simply a work item type which any team can create in Azure DevOps. Teams can configure non-functional requirements to house any variation of configurable fields, allowing your non-functional requirements to contain any data that would be important to your team.
As non-functional requirements are simply a created work item in Azure DevOps, they are stored and treated no different than any other requirement (epic, feature, user story, ect.).
Azure DevOps also supports the ability to configure your project backlog to easily show non-functional requirements where needed in your project.
But is that enough?
The Role of Modern Requirements4DevOps When Building Non-Functional Requirements
Modern Requirements4DevOps (MR4DevOps) offers several solutions to aid in the non-functional requirements management process. There is a tool for every stage of an NFR’s lifecycle; elicitation, authoring, document creation, and management.
Building strong NFR’s is based on asking the right questions. Due to the abstract nature of NFR’s this might not be a simple task. What if you are new to the requirements gathering process? MR4DevOps addresses this by enabling users to elicit their NFR’s with the FAQ module.
The FAQ module is a series of focused question lists grouped by system attribute and categorized by the three aspects of the product: Operational, Revisional, and Transitional. By answering questions from the list, you are authoring well-defined NFR’s that are 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 for the elicitation of compliance and risk based NFR’s for medical device development.
If documentation is part of your non-functional requirements process, MR4DevOps’ Smart Docs provides you with a single application solution to your requirements documentation needs.
Smart Docs enables users to build non-functional requirements documents directly within Azure DevOps. Insert existing NFR’s directly from your Backlog or author new NFR’s on-the-fly while you build your Smart Doc. Smart Docs can be built with unrestricted style using the Smart Editor’s rich text editing functions. If your documentation process demands structure and consistency, reusable templates can be tailored to 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.
Storing your well-defined NFR’s within a repository for later reuse is a best practice in requirements management. However, retrieving stored requirements and implementing them within a new project is widely considered to be 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 NFR’s again.
Manage and store your NFR’s directly within Azure DevOps. The Reuse Work Item tool gives users freedom from managing external repositories, using outside applications, and the tedious copy and paste process.
In terms of project management, accurate traceability of your non-functional requirements is one of the biggest challenge’s encountered by teams. Manually creating traceability matrices is a tedious, time-consuming, and error prone process. Projects typically evolve at a rate that renders these matrices constantly 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 NFR’s. Trace any relationship that exists between your project’s NFR’s and any other requirement. Relationships between NFR’s and other project requirements can also be created using the Trace Analysis tool.
The MR4DevOps provides 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.
There is truth in the argument that non-functional requirements are as important as functional requirements; perhaps even more important. Non-functional requirements have far greater depth and implications on your project than their functional counterparts. Non-functional requirements truly drive your product or system’s user experience and gauge the success of any project.
Hopefully this article helped you answer the question of what non-functional requirements are and presented some substantive evidence for the importance of non-functional requirements to your project.
MR4DevOps can help you elevate your NFR management capabilities with a set of tools that offer you support at every stage of your project.
Request a Demo!
Reduce UAT Efforts
50% Reduction in UAT efforts
Proven Time Saving
80% time saving on creating Trace Analysis
Significant reduction in approval delays
50% requirements productivity improvement
10-fold reduction in development rework
40% reduction in compliance reporting efforts