After more than 15 years of writing and discussing the distinction between functional requirements and quality requirements, the definition of functional requirements still eludes me. Quality attribute requirements are well defined – performance has to do with the timing behavior of the system, modifiability has to do with the ability of the system to support changes in its behavior or other qualities after initial deployment, availability has to do with the ability of the system to survive failures, and so forth.
Function, however, is much more slippery. An international standard (ISO 9126) defines functionality as “the capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.” That is, functionality is the ability to provide functions. One interpretation of this definition is that functionality describes what the system does and quality describes how well the system does its function. That is, qualities are attributes of the system and function is the purpose of the system.
This distinction breaks down, however, when you consider the nature of some of the “function.” If the function of the software is to control engine behavior, how can the function be correctly implemented without considering timing behavior? Is the ability to control access through requiring a user name/password combination not a function even though it is not the purpose of any system?
I like much better the use of the word “responsibility” to describe computations that a system must perform. Questions such as “What are the timing constraints on that set of responsibilities?”, “What modifications are anticipated with respect to that set of responsibilities?”, and “What class of users are allowed to execute that set of responsibilities?” make sense and are actionable.
Now the achievement of qualities induces responsibility – think of the user name/password example above – but one can track the genesis of a responsibility and identify responsibilities as being a portion of the computation associated with this set of requirements.
So does this mean that the term “functional requirement” shouldn’t be used? Not at all. We have long argued that a requirement such as “the system shall be modifiable” is not testable and should not be used but that does not mean that the concept of “modifiable” is meaningless. People understand the term and it is a useful category for discussion and elicitation of requirements. It is only when there is a requirement for precision that some more precise specification of modifiable is needed. Similarly with functional requirements. People have an understanding of the term and it has served us well. It is only when we wish to be precise that we may wish to talk about sets of responsibilities rather than functionality.
Paul Clements has long ranted against the use of the term “non-functional,” and now it’s my turn to rant against the term “functional” – probably equally ineffectually.
– Len Bass, SEI