Non Functional Requirements | Quick Guide For The Business Analyst In 2024

Non Functional Requirements | Quick Guide for the Business Analyst in 2024


There is some dispute regarding the use of the term non functional requirements (NFRs) and whether it is the correct term. However, it is in common use and serves a recognised purpose. In this article it is used to describe general characteristics and properties that are required. They are non functional requirements in the sense that they don’t describe any sort of behaviour.

When designing a system solution, the first thing all stakeholders are concerned with is that it works, meaning that it satisfies the functional requirements. However, besides considering what the solution will do, it’s also important to think about how they’ll work. The fact that the system operates on a basic level, performing its primary function, doesn’t mean that the product will provide a good user experience. And, this is where the non-functional requirements come into play.

Defining and implementing non functional requirements will ensure that the system runs smoothly and features quality attributes that are necessary for meeting the needs of the end-user. While they’re not mandatory or related to system functionality, NFRs set constraints that define how the system should perform. Avoiding them can lead to vital problems and, ultimately, the product’s failure to meet stakeholder and user expectations or fulfil the needs of the business.

Table of Contents

What are Non Functional Requirements?

What are non functional requirements? Simply put, non functional requirements are constraints imposed on the system. They’re used to define the quality attributes which will determine how the system operates. Their main purpose is to make the product (application, software, website, or other) run more efficiently and thus improve the user experience. Unlike functional requirements that specify certainly functions of behaviours, the NFRs set the criteria to evaluate the performance of the system.

They provide information on the overall property of the solution and what it should be, rather than defining what a system should do. By setting constraints and describing operation capabilities, these requirements serve to enhance the system’s functionality.

Still, they don’t impact the basic functions, the system will function on a basic level even if the non-functional requirements are not set. Their true value lies in better usability. However, the qualities they define can be rather ambiguous and more complex than traditional functional requirements which often can make setting the NFRs and measuring success a bit tricky.

In most cases, non-functional requirements are expressed as declarative statements in textual format. The declarative form of NFRs features constraints that determine the level of freedom from both developers and users.

Failure to properly define NFRs or even avoid them altogether before the start of a project can result in critical issues which can leave stakeholders, developers, and users unsatisfied. Not addressing non-functional requirements properly will also lead to inconsistent products and significantly increase the time and cost needed to fix a potential issue.

Mastering The Requirements Process by Suzanne Robertson and James RobertsonOpens in a new tab. defines non functional requirements as properties that your product must have. Think of these properties as the characteristics or qualities that make the product attractive, usable, or fast or reliable.

The business have a tendency to miss them altogether which means the business analyst needs to help the business in identifying these. There are some obvious ones that are identified quickly and easily such as system availability, acceptable response times and there may be cost and time constraints.

The remainder are often overlooked. It is very important to devote the effort extracting these as they can be critical to the project success and a significant contributor to cost which will increase if they are identified later in the project. 

The only way to really identify these requirements is with a deep understanding of the business;Opens in a new tab. the processes and strategy and the specific objectives of the project.

The business analyst often doesn’t have this knowledge, in which case, there are many ways to identify non functional requirements which include:

  • Examining functional requirements to determine possible non functional requirements;
  • Walking through the business process or a prototype of the system;
  • Observing an user a work;
  • Interviewing a user.

Armed with this knowledge, it is more likely that the business analystOpens in a new tab. will be able to direct the stakeholders towards the non functional requirements they never thought they had. 

Non functional requirements (NFRs) are still important in an agile context and serve serve as constraints or restrictions on the design of the system in the  product backlogs.

non-functional requirements

What are the Types of Non Functional Requirements?

What is FURPS?

FURPS is a technique, developed at Hewlett-Packard and now widely used in software industry, used to validate prioritised functional and non functional requirements following an understanding of clients’ needs and demands. It features a set of quality attributes: functionality, usability, reliability, performance, and supportability.

The name of the technique itself is an acronym of these attributes. Quality factors defined by FURPS can be used to define quality metrics to support each step of the system development process. Over time, due to the need to observe the solution from more dimension, the model expanded to FURPS+ which puts more emphasis on non-functional requirements. FURPS+ also provides tools for the definition of design, implementation, interface, and physical constraints. Each of the attribute categories incorporates several other requirements:

The following is taken from WikipediaOpens in a new tab. from the acronym FURPS which is a useful model for classifying software quality attributes and provides a useful trigger for the categories of non functional requirements that may have been overlooked:

  • Functionality – Feature set, capabilities, generality, security;
  • Usability – Human factors, aesthetics, consistency, documentation
  • Reliability – Frequency/severity of failure, recoverability, predictability, accuracy, mean time to failure;
  • Performance – Speed, efficiency, resource consumption, throughput, response time;
  • Supportability – Testability, extensibility, adaptability, maintainability, compatibility, Configurability, Serviceability, installability, localizability, portability.

Functionality

Functionality – functional requirements generally represent the main product features of the solution. 

Depending upon the approach being taken on the project functional requirements may be expressed as use casesOpens in a new tab., use stories or traditional requirements statements which are usually action oriented, for example, when the user does X, the system will do Y.

Usability

Usability – this type of non functional requirement is concerned with characteristics such as aesthetics and consistency of the user interface.

It is important to describe the ease with which the solution can be learned and operated by the intended users.

Reliability

Reliability – this type of non functional requirement is concerned with characteristics such as availability of the solution. 

This includes consideration for the degree to which the solution must behave in a user-acceptable manner.

Performance

Performance – this type of non functional requirement  is concerned with characteristics such as throughput, response time, recovery time, of the solution.

This includes considerations for how fast how safe, how many, how accurate the functionality must be.

Supportability

Supportability – this type of non functional is concerned with characteristics such as maintainability, scalability of the solution.

This includes considerations for the ability of the solution to be easily modified to accommodate enhancements and repairs.

Which non-functional requirements will be needed for a certain project depends on the context and the expected outcome. There are literally hundreds of NFR’s that can be used. Some of them overlap or can’t be properly estimated without using others.

Below are the major categories of NFR’s which commonly require high attention. While rather useful for themselves, they can also serve as a starting point and guidance for the initial conversations as they allow flexibility to add additional quality attributes if needed.

Scalability

The scalability non-functional requirements are used to determine the highest workloads under which the system will still perform as expected (Black Friday Test). This NFR doesn’t necessarily define the maximum load the system has to process now, but rather the one it may have to deal with in the future. It should allow for a smooth business expansion and account for both software and hardware implications. The scalability NFR should, for example, take into consideration a potential growth in the number of users and simultaneous sessions and define improvement of the functionality of the system without impacting the performance.

Reliability

The reliability NFR defines the ability of the system to properly perform the required functions under predefined conditions for a certain period of time. Commonly, it’s expressed through probability percentages predicting chances that the system won’t experience critical failure under the normal usage, and during the set time. As a critical failure, normal usage, and the time period can be rather difficult to define, a somewhat simpler approach is often used. It includes counting the number of the system’s critical failures during testing and tracking the mean time between critical failures.

Regulatory

The NFRs from this category describe product compliance to laws or other regulatory requirements. If a product potentially violates these regulations, it may result in legal punishment, including fines, or even the inability to release the product on a certain market. These requirements commonly address various regulations, including privacy laws, GDPR, and international trade regulations. The audibility requirement usually falls under this category, too.

Maintainability

Maintainability is a quality attribute that defines how the solution can be modified to fix the fault or improve the performance. In order to be maintainable, the system should be capable to be managed or adapted in a cost-effective way over the expected lifespan. Similar to the reliability, this non-functional requirement includes can be expressed with the probability percentage showing the likelihood of system repair for a certain period of time. Maintainability often incorporates other requirements such as configurability, modifiability, interoperability, and extensibility.

Serviceability

Closely connected to maintainability, the non-functional requirement defines how easy it is to perform service on the component or the whole system when needed. Serviceability ensures that technical and support staff are able to monitor the operation of the system and quickly react if needed. Properly set serviceability positively impacts reliability and availability.

Utility

This type of non-functional requirement defines how effectively the system can be used or utilised to achieve required goals. When this NFR is properly set, the system is easy and straightforward to use by as many people as possible, including end-users, as well as operators and administrators. Defining these can be tricky, as there are many types of utility criteria and the requirements should be measurable.

Security

The security requirement is particularly important when the system involves handling sensitive data, such as personal or financial information. To define these NFRs, it’s important to fully understand regulatory and compliance requirements from the very start of the project and clearly communicate them to developers. This way, the security NFR can help them implement necessary actions to maintain necessary security levels. When done right, it ensures that all data inside the system or one of its components is secure and protected against unauthorised access and attacks. Security NFRs define specific threats that can be addressed in more detail by functional requirements. Security often incorporates other non-functional requirements, such as authentication or confidentiality.

Manageability

Manageability defines how easy it is for administrators to efficiently control the system to ensure continued optimal performance. This non-functional requirement dictates that the system architecture must have a built-in ability to monitor the system, allow dynamic configuration, and easily analyse the root cause of failure. Manageability is one of the crucial non-functional requirements as it has a significant influence on recurring costs and potential failures. It also influences several other NFRs, such as availability, reliability, performance, and security.

Non Functional Requirements Examples

In order to better understand how the non functional requirements are defined, here are some non functional requirements examples of the above-listed quality attributes.

  • Scalability – The limit of maximum attendance of the website must be scalable enough to support 300.000 visits at the same time while maintaining optimal performance
  • Reliability – The process of updating the database must be designed in a way that rolls back any related updates in case any of the updates fails
  • Regulatory – The security of the database must protect sensitive information in a way that complies with HIPPA requirements
  • Maintainability – In case the automated e-mail service becomes unavailable, it can’t be under maintenance for more than three hours
  • Serviceability – The automated e-mails can be edited or replaced by uploading an XML file eliminating the need for recompiling any code
  • Utility – For users who use to navigate the website, the “Add to cart” button mustn’t be removed from the product page more than 15 clicks
  • Security – Each time they load the new page, users will be prompted to provide an electronic signature
  • Manageability – The site will stay up and running while the administrator edits the code for users’ profile pages.

How to Manage Non Functional Requirements in Agile?

Managing non-functional requirements in an agile environment requires a different approach than traditional software development methodologies. Here are some steps you can take to manage non-functional requirements in agile:

  • Prioritise non-functional requirements: identify the most important non-functional requirements for the product and prioritise them based on their impact on the system’s overall success. Make sure that the prioritisation is based on the business value and customer needs.

  • Define acceptance criteria: clearly define the acceptance criteria for each non-functional requirement. This will help ensure that everyone on the team understands what needs to be done to meet the requirement and when it has been successfully met.

  • Continuously test and validate: continuously test and validate the non-functional requirements to ensure that they are being met. This includes testing during each sprint and conducting performance testing, security testing, and usability testing.

  • Use automation: use automation tools to test and monitor non-functional requirements continuously. This will help you catch any issues early and make it easier to track changes.

  • Collaborate with stakeholders: collaborate with stakeholders, including business owners, users, and testers, to ensure that their needs are being met. This will help ensure that the non-functional requirements are aligned with the business goals and customer needs.

  • Adapt to changes: adapt to changes in non-functional requirements as the project progresses. In an agile environment, requirements can change quickly, so it is important to be flexible and adaptable to change.

Non Functional Requirements Template

Business Analysis Excellence has a business analysis and agile template packageOpens in a new tab. that includes a non functional requirements template to specify the quality attributes a system must exhibit to support the required functional requirements.

Non Functional Reference Links

Non-functional requirements from WikipediaOpens in a new tab. – a huge variety of categories for non-functional requirements are suggested and described here

Volere requirements template and non-functional requirementsOpens in a new tab. – another view provided by Suzanne and James Robertson which is very useful.

Alex Papworth

Alex Papworth is a business analyst who has been working in IT for over twenty years. Business Analyst Mentor provides free articles and ebooks and recommends business analysis training courses.

Recent Posts