An all-too-frequent complaint from business users is not that systems do not do what they need, but that they do not work as they expected. Perhaps responses are too slow for them, or perhaps it is difficult and expensive to make changes to the system, or perhaps the interface works differently from other applications they are using.
This note is the first in what is hoped will be a series which will explore some of the reasons and some of the answers to this classic failing of requirements gathering.
Most business analysts are pretty adept at identifying the functions that the business needs but are not always so good at finding the further requirements, those that condition how the functionality is implemented, and which, today, we call 'non-functional' requirements.
Let's be clear, a requirement is a requirement is a requirement. The distinction between functional and non-functional is an aid to identification, and helps us to gather a more complete set of requirements; it is not a difference to be agonised over.
To make the distinction obvious let's take an example the need to record customer data. Is this a functional requirement? Of course it is. It can be designed, tested and implemented as a part of a development. But might the business users expect that the design will allow them to work in particular ways? For example, might they need to enter a minimum number of new customers per hour? Or might they need the user interface to conform to their organisation's standards? Or might they expect that the entry be easy to learn? If the answer to any of these questions, and many more like them, is yes, then we have a non-functional requirement.
Non-functional requirements cannot be implemented by themselves you cannot implement a requirement for speed of response without having a transaction to worry about (the functional requirement); the ability easily and quickly to enhance the application makes no sense without some functionality to enhance; what are users supposed to find easy to learn if it is not a function that has been implemented? And so it goes on.
Non-functional requirements add a wrapper to the functional needs. They tell us how much, how many, by when, to what level, with what control, to what accuracy, the functional needs must be designed and implemented. In that sense they constrain our design options. In fact you could replace the term non-functional with constraint. I think it was Tom Gilb who first introduced the idea of product constraints and that it exactly what we have with non-functional requirements, a set of constraints on our freedom to design and implement the functional needs as we might like.
Note that this has nothing to do with technical design, albeit the final set of requirements may influence the choice of technology or package, or the revision of business practices. Technical design is purely and simply about how the requirements will be achieved, whether functional or non-functional. What we are talking about in this note is the requirements that will be the subject of technical design.
The theory is all very well but there are some practical issues to unearthing these non-functional requirements or NFRs. For example, does every functional requirement (FR) have an NFR? Can it have more than one? Can one NFR apply to multiple FRs? What questions do we need to ask in order to identify the NFRs? How do we document them? We know about testing FRs but do NFRs also need to be tested, and how do we do that?
Perhaps the most pressing question at the outset is what NFRs are there?
This is not intended to be comprehensive, and you may well know of some others, but gives some idea of the range of NFRs that we need to consider. Not all will apply in every project but it helps to have a shopping list to fall back on.
Of course other authors see things in their own way. Comments on this and answers to some of the other questions will be addressed in a later note. If you want to know more before then try our Requirements Engineering course.