Getting non-functional requirements right

Getting non-functional requirements right early on is an important success factor for successful projects. This is why, in the course on software project management, one of the practical assignments focused exactly on this topic. In this article we summarize the most important steps: discovering requirements, making them precise and making them flexible .

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

What are non-functional requirements?

Each software project has two kinds of requirements. The functional requirements describe the functions of an IT system: each requirement describes something that a user can do with the system, such as reserving a boat or checking a bank account. The non-functional requirements describe how the system does this. The requirements for instance specify how fast the system should be, or whether it should run on any device.

The problem with non-functional requirements is that users are often not aware of non-functional requirements they have. In many software projects no performance requirements are given because everyone assumes performance will not be an issue. Only when the first version of a system is delivered and it is very slow, do people realize that speed is an important factor.

The second problem with non-functional requirements is that adding these requirements to a system can lead to a lot of rework. When a new functional requirement is discovered, it can often be addressed by adding a new function to the system. Non-functional requirements often have impact in the whole system. When a new non-functional requirement is added, lots of changes throughout the system have to be made.

Due to these two problems, it is important to address no-functional requirements early on in a project. Even if one cannot get these requirements perfect the first time, it is important to have the fundamental requirements discussed in a project plan so that they get enough attention throughout the project.

Discovering non-functional requirements: the user perspective

There are multiple ways of discovering non-functional requirements. The first is using a software quality framework such as ISO 25010. This standard defines eight quality areas. One of these is functionality, the other seven areas are all non-functional requirements areas. By filling in all these areas, one makes sure that no important topic is missing.

The disadvantage of using a framework is that one might add more requirements than are needed: one should only add requirements that users really need and care about. The best way to understand the real requirements is by interviewing and observing users. In those interviews, the project leader and other project team members should try to understand the usage and use of software in detail: who are the users, what does their job entail, how often and when do they use IT systems, and how are they know they are successful? It can also be helpful to follow the users at their work floor to see the circumstances in which they work. Only by understanding what the users do, can one create the right requirements.

Making non-functional requirements specific

When interviewing users about non-functional requirements, one often gets high level values or properties. E.g. the system should be fast, reliable, easy to use. The high level properties are good starting points, but they must be expanded into usable requirements. The best way to do this, is by adding a value, a measurement unit, and a comparison. For instance, the following are examples of specific non-functional requirements.

• 90% of the intended users should rate the usablity of the system with a grade of 8 or higher (after two days of training and two weeks of working with the system)
• The system should perform 80% of the functions within 1 second.
• The system should operate without problems for more than two hours when it 
is powered by a standard AA (2700mAh) NiMH battery.

Making requirements specific takes some effort, but it yields great advantages during testing and acceptance activities.

Making requirements flexible

Another challenge in defining the right non-functional requirements, is setting the right ambition levels. When first discussing the non-functional requirements it is not clear what a realistic target is. There is a risk of setting targets that are not realistic or cost effective, or levels that are too easy. The problem is that the requirements are black and white. Reality is more nuanced and often involves a trade-off in costs and benefits of meeting a certain non-functional requirements.

One way to bring nuance back in the requirements is by defining four levels, so that there are four steps in importance. Instead of reporting yes/no, teams can no discuss with clients which level has already been reached, and how urgent further improvement is. The four levels are labelled must, should, could, won’t (often abbreviated as MoSCoW).

Image: Stopwatch by Mathew (creative commons) – timing /performance is a common nonfunctional requirement