Are non-functional requirements a support service to functional requirements in the software development cycle...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
Related Q&A from Robin F. Goldsmith
How do you engage high-level business executives in the process of writing business requirements?continue reading
Why don't users seem to appreciate typical software QA testing status reports?continue reading
What is the value of online discussion forums? This expert sees the good and the bad in online forums.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.