Are non-functional requirements a support service to functional requirements in the software development cycle?
If I’m interpreting this question as it was intended, it’s very insightfully highlighting the seldom-recognized reason the term “non-functional requirements” is ill-conceived.
The term is widely used to refer to quality factors or attributes such as usability, reliability, and availability -- which are also often called “ilities.” Very often, problems and subsequent creep occur because the requirements definition failed to adequately address these types of factors.
Consequently, many requirements books and courses explicitly distinguish functional from non-functional requirements. While it’s good to prompt awareness that requirements definition also needs to address these topics, too often the authorities’ distinguishing them as different also leads to mistakenly suggesting that they should be elicited and documented separately. For example, IEEE Std. 830 for Software Requirements Specifications (and many other common requirements documentation formats) documents categorize such requirements in their own individual subsections, a method I call “pigeon-holing.”
“Non-functional” is an unsuitable adjective because it views each as existing by itself, which leads essentially to only one question: How much usability, reliability, availability, etc. do you need? It should be obvious that the question is has no meaningful answer.
These requirements don’t exist by themselves, but rather exist only with regard (in service) to particular functionality. I don’t need a bunch of usability; I need usability related to the uses I have. Moreover, one size doesn’t fit all. The usability characteristics I need vary, and could differ considerably from required function to required function. Usability is only an example. The concept applies to all quality factors. When defining each required function, all relevant quality factors for it need to be identified along with their respective requirements.
Most quality factors are real business requirements that exist irrespective of whatever product, system, or software solution ultimately is chosen. However, design decisions and resulting implementation approaches can create the need for identifying additional quality factor requirements.
This was first published in December 2010