Non Functional Requirements in Software Development

Software development is impossible without defining functional and non-functional requirements for the future product. They act as the guidelines on the system’s whats and hows, connecting stakeholders’ views on a project and the development team’s capabilities.

This article will be useful for anyone who wishes to learn more about non-functional requirements to reach a better understanding of system analytics.

What Are Non-Functional Requirements?

Let’s start by figuring out what requirements are in general. The requirements are the benchmarks of a project, a list of features and properties that the future product must have to meet both business aims and customers’ expectations. They form a bridge between contractors and the development team so these groups will be on the same page about software functionality. There are:

business requirements, showing the sponsors’ vision of a project and how the software would apply to their business;
user requirements, characterizing user goals and actions within the software;
system requirements, examining features, functionality and how the software would work. The functional and non-functional requirements are set up here.

We already defined functional and non-functional requirements in general. Now, we will focus on non-functional requirements.

Non-functional requirements (NFRS) describe how the software would work, not the features, but the quality of the features and the properties of the system. They are mistakenly considered less important than the functional requirements because it seems like NFRS affects the system unnoticeably. In actuality, the role of non-functional requirements is equal to that of functional requirements. While functional requirements build the software, non-functional requirements manage the efficiency of the software work and help deliver a better user experience.

Who defines non-functional requirements?

Analytics for software development are performing requirement analysis and defining necessary ones. It’s important to assemble a group of people to define the non-functional requirements not only from the perspective of analysts, but also from users, key developers and architects as well. Their roles in establishing the non-functional requirements are as follows:

System analysts collect, analyze and document non-functional requirements;
Users evaluate parameter values that are used to evaluate non-functional requirements. These values come from use cases — the scenarios when certain actions must be done under certain conditions at certain times;
System architects and key developers participate in defining non-functional requirements and verify their feasibility;
The testing group analyses the non-functional requirements and proposes testing scenarios for them.

Let’s review a generalised example of non-functional requirements. The scenario for the system functionality goes as follows:

The system files a request for an action;
The system commits to an action.
If the action fails, the system tries to commit to it again.

The requirements for this scenario would be:

The request for an action must be delivered to the system in XX seconds after its creation;
The system must finish the action by YY seconds after receiving a request;
The repeated attempts to finish the action must happen X times within an X second interval after each failed attempt.

There are three main groups of non-functional requirements:

Product requirements. Everything related to software efficiency falls into this category: performance standards, operating and storage memory required, usability, portability, scalability and many others.

Organizational requirements. This category describes the qualities of tools that are used to build the software: programming languages, software development standards, design methods, output requirements and related documentation.

External requirements. This category includes the qualities that are not related to development in a direct way but are still influencing the process. Those requirements are local legislation, ethical requirements, confidentiality settings, and accessibility to a user.

We will take a closer look at some of these requirements in the following paragraph.

Non-Functional Requirements List

There are a lot of non-functional requirements and they are mostly business-specific. We will discuss some of the standard non-functional requirements that can be used for the majority of products because of their versatility.

Performance

Performance is an expectation of how well and how fast the system should work. This criteria is usually described in numbers. For example:

How many concurrent users can be in a system?
How many transactions can occur in the same moment?
What is the system response and computation time?
What is the speed of communication channels?

Answers to these questions help you define the performance of your software. Good performance, however, requires skillful programming and should leave room for adaptations to accommodate weak hardware that the users might have.

Usability

Usability is a quality metric used to determine how well the user may apply the product to effectively achieve their goal. In other words, usability shows if the interface is comfortable for the user. It should answer to 5 quality criteria:

Easy to learn. How easy it is for users to complete their main goals interacting with the software for the first time.
Effective. How fast users get comfortable with the interface.
Memorable. How easy it is for users to use the software after not interacting with it for a while.
Mistakes. How many mistakes a user would make, how crucial these mistakes are and how easy it is to prevent these mistakes from happening.
Satisfaction. How much users enjoy interacting with the interface.

Reliability

Let’s define reliability as an attribute of software to consistently perform up to the specifications. It’s the expectation that the software will work adequately for a prolonged period of time. There are a few types of reliability:

Mean Time to Failure (MTTF) — the time between the two system malfunctions;
Mean Time to Repair (MTTR) — how much time it takes to identify the failures and fix them;
Mean Time Between Failures (MTBF) — is calculated from MTTF and MTTR and evaluates when to expect a next failure;
Rate of Occurrence of Failures (ROCOF) — the frequency of errors in a time interval. A ROCOF of 0,01 means that 1 malfunction can be expected in each 100 operational time units;
Probability of Failure on Demand (ROFOD) — is the probability of a failure occurring when the software is in demand (the request is made, an input is given by the user). A ROFOD of 0,1 is a probability that 1 out of 10 servers will fail.
Availability — the probability of a software being ready to use at a given time. An availability of 0.995 means that in every 1000 time units, the software will work for 995 of them.

Scalability

We can define scalability as the system’s ability to adapt to changing workloads so the performance stays at a high level. The system can be scaled:

Vertically — by transferring the application to more efficient and powerful SMP systems, increasing memory storage;
Horizontally — by clustering the data and increasing the fault tolerance of the system.

A typical example of scalability is that of a business getting more cloud storage so it can handle ten times more customers than before.

Maintainability

The definition of maintainability is the measure of the ability of a software’s functionality to be restored to a desired condition after maintenance is performed. This requirement estimates how much time the support will spend to release a solution for a problem, increase performance or scale the system to adapt to the workload. Maintainability is calculated in a probability of repair in a certain time. For example, 50% maintainability for 12 hours means that the problem within the system has a 50% chance of being resolved in 12 hours.

Portability and compatibility

This parameter is used to establish software capability to run on different operating systems, mobile platforms, browsers and hardwares, if there would be any conflicts while installing on different devices or incompatibilities with other software. The best example of software portability are SPA websites — as they are written in Java, they would be incompatible with browsers where the JavaScript is turned off. Another example is PWA — they are made to be compatible with most of the smartphones to ensure most users can utilize the app.

Security

Security requirements include privacy settings, access control and protection from external attacks.

Access control. Who is going to have full access to the system? Will all users have the same access level or will there be a hierarchy? What restrictions will support the chosen access control?
Privacy settings.
Protection from external attacks. Check how well your system is prepared for doxing (bots sending huge amounts of requests to achieve server failure), machines making accounts rather than real people, are your user’s passwords strong enough.

The examples of security requirements include:

Password field requires a string of characters, including numbers, uppercase and special characters;
Only the head administrator should have full access to the client’s private information.

Documentation for Non Functional Requirements

All of the non-functional requirements have to be written in a non-functional requirement document. Its main goal is to provide stakeholders with all the necessary information. It also helps to track and manage what is being done in the project. Documentation should be revised and agreed upon by all the people involved in the software development process.

What are the criteria of non-functional requirements?

In preparing the documentation for non-functional requirements, it’s important to consider requirement quality criteria — the description of the qualities that the requirements should meet. The standard characteristics of requirement quality criteria are:

Totality. The requirement must include all the necessary information vital for its implementation. If some information is missing, this should be commented on.
Certainty. The requirement must be internally consistent and everyone who works with it should interpret it the same way. The requirements should be described in a simple, short and exact manner, using common terminology.
Correctness. The requirement must not include incorrect or uncertain information. Different requirements should never conflict with each other in a system.
Necessity. The requirement must reflect on a feature or characteristic that is essential for the software or connected to other requirements in an inseparable way.
Feasibility. The requirement must be feasible, taking into account the system’s characteristics and boundaries. The feasibility analysis is conducted by the developers. For a non-functional requirement, the possibility of reaching the evaluated numbers is tested.
Testability. There must be a coherent and sensible way to test manually, or by machine work, if the software meets the requirement. Every requirement should have enough information to test it. For a non-functional requirement, a testing criteria is if the evaluated numbers are present in the software.

By following this criteria, you will achieve a comprehensive document that properly describes expected non-functional requirements matching your views on the project. Here is a template you can use for documentation:

Conclusion

The non-functional requirements are an important part of a software development process. To evaluate them is not an easy task, but it is worthwhile because it allows you to provide your customers with a high quality user experience. If you are considering applying for software consulting services, contact us and we will gladly estimate the non-functional requirements for you.

Non Functional Requirements: Definition, Types and Examples