Chapter 11 - Non Functional Requirements

Non Functional Requirements

 The explanation of the Non Functional Requirements starts with a story in our book. A story that really happened: The client rejected the delivered help desk software. The functionality was correct-it supported the help desk’s activity, and did all that it was supposed to do, but the client didn’t want it. Why not? Because the users-the help desk operators-refused to use it, preferring to use the existing manual procedures. Why was the product so bad? Because the requirements team had paid almost no attention to the non-functional requirements.
 We should explain that: The help desk staff already had nine other applications running on their desktops. The requirements team did not bother inquiring about the users’ look and feel requirements. As a consequence, the new software had a completely different interface style with a different set of icons and screen layouts. The help desk people had to use nine other applications and, quite rightfully, refused to learn a new, non-standard interface. The requirements team also ignored the usability requirements-the new software employed work sequences, metaphors, and terminology unfamiliar to the users.

An Introduction to Non Functional Requirements

The non-functional requirements describe the qualities that your product must have or, to put that another way, how well it does the things it does. Such requirements make the product attractive, or usable, or fast, or reliable, or safe. You use non-functional requirements to specify response times, or accuracy limits on calculations. You write non-functional requirements when you need your product to have a particular appearance, or be used by people in particular circumstances, or adhere to laws applicable to your kind of business. 

Formality Guide

On some occasions, the non-functional aspects of the product are the prime reason for doing the project. If the users find the existing product difficult to use, slow, or unreliable, then usability, performance, and reliability, respectively, could be considered the most important requirements for the new product.

Rabbit projects should use the requirements specification template as a checklist of non-functional requirements types. Go through the list-ensuring that you check the sub-types—with your key stakeholders and determine their priorities regarding non-functional requirements. 

Horse projects have multiple stakeholders. The requirements analysts must ensure that they capture everyone’s non-functional requirements, as well as identify and deal with the conflicts between non-functional requirements originating from the different and scattered stakeholders. 

Elephant projects have a need to capture all of their requirements in written form, including the non-functional ones. We suggest you group the nonfunctional requirements by type in the specification. 

Functional versus Non Functional Requirements

In our ongoing example, we have explored various aspects of the Icebreaker product in earlier chapters. Part of this product’s functionality is to record road temperatures and moisture levels each time this data is transmitted by the weather stations. Recording data is a functional requirement—it is part of the fundamental business process. Now suppose that this data has to be recorded within half a second; moreover, once it is recorded, no one except a supervising engineer is allowed to alter the data. These two requirements are non-functional, with the first being a performance requirement and the second a security requirement. 

Although these requirements are not part of the functional reason for the product’s existence, they are needed to make the product perform in the desired manner. Non-functional requirements do not alter the product’s essential functionality. That is, the functional requirements remain the same no matter which properties you attach to them. At the risk of confusing matters, the non-functional requirements might add functionality to the product. 

Use Case and Non Functional Requirements

A product use case represents a chunk of work the product does when the work is responding to a business event. In earlier chapters, you saw how the scenario breaks the product use case into a number of steps; for each of these steps, you determine the functional requirements. 

The non-functional requirements, however, do not fit so neatly into this partitioning theme. Some of them can be linked directly to a functional requirement, some apply to the product use case as a whole, and some apply to the entire product. Diagram below shows the links between the functionality and the associated non-functional requirements.