Problem solve Get help with specific problems with your technologies, process and projects.

Understanding functional and non-functional requirements in the software development lifecycle

The premise that functional and non-functional requirements exist separately is a misconception. In this expert response, Robin Goldsmith explains the how these two types of specifications are inter-related and correlate with particular functionalities in the software development lifecycle.

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. 

Dig Deeper on Topics Archive