Manage Learn to apply best practices and optimize your operations.

Software requirements: Why the term 'nonfunctional requirements' misleads

Requirements expert Robin Goldsmith explores the problems with common nonfunctional requirements scenarios and offers more useful alternatives.

Missed and mistaken nonfunctional requirements account disproportionally for project and product problems. Most requirements books and courses explicitly split requirements into functional and nonfunctional and advise separately addressing each.

Terms such as 'quality factors' and 'quality attributes' are preferable but still have issues.

While seemingly straightforward, the conventional characterization and treatment of nonfunctional requirements actually may unwittingly create critical additional and seldom-recognized issues. In this tip, I explore the problems with common nonfunctional requirements scenarios and offer alternatives that can give development teams better views into user needs.

Before delving further into the mislabeling issue, let's define functional and nonfunctional requirements and explore the distinction between them. In essence, a functional requirement explains what the application does, and a nonfunctional one describes how well it does the function. An obvious comparison comes in use cases, which are a popular format for defining functional requirements of products, systems and software. Use cases describe step-by-step how an actor interacts with the system. An actor usually is the user, but also could be another system or a piece of hardware. Nonfunctional requirements, as well as business rules, are explicitly not described in a use case and must be documented in a separate supplementary specification.

How much usability do you need?

In my work, I've found that the term "nonfunctional" is misleading. It implies that such requirements exist in the abstract and can be defined all together, usually with a single brief entry for each type. Were this true -- and unfortunately, too many requirements definers act as if it is -- one would have to ask only a question for each type like, "How much usability do you need?" When it is put that way, most people realize it is a meaningless and unanswerable question.

You don't just need a bunch of usability. Usability is not nonfunctional. Usability is only relevant with respect to functionality. Moreover, usability requirements frequently differ from one function/use to another, and the differences are defined in terms of relevant characteristics, not some sizing unit as the single-entry-per-type approach implies.

Consequently, when gathering data to discover requirements, inquiries about various functions each need also to address applicable nonfunctional characteristics, of which there may be many. In turn, rather than grouping all such requirements together, they really need to be described in conjunction with the functionality to which they pertain.

More on this topic

Learn how to use nonfunctional requirements templates

Read more about issues relating to nonfunctional requirements

Learn the difference between functional and nonfunctional requirements

See how requirement types relate to software engineering

The conventional approach tends to consider both functional and nonfunctional requirements as aspects of the product, system or software expected to be created. A typical requirements definer often just expects a stakeholder to describe their desired product, system or software.

Such an approach creates creep by failing to recognize the need for first defining business requirements: deliverable whats that provide value when satisfied by a product/system/software how. Most nonfunctional requirements are real business requirements that exist within the business situation and must be met by any product, system or software. However, particular product/system/software choices may give rise to some additional nonfunctional requirements specific to the solution choice.

For all these reasons, I encourage my students and clients not to use the misleading term 'nonfunctional requirements.' Terms such as 'quality factors' and 'quality attributes' are preferable but still have issues because they easily lead to the common term 'quality requirements,' which mistakenly implies that only these factors affect quality. In fact, relevant functionality is the overwhelmingly dominant determiner of quality.

Instead, I suggest referring to all of these types of requirements as 'ilities,' because many of them end in 'ility' -- usability, availability, reliability -- and the term 'ilities' has no extra baggage connotations.

About the author:
Robin F Goldsmith, JD is president of consulting and training firm Go Pro Management, Inc. A subject expert for IIBA's BABOK®, he is the creator of the Proactive Testing™ and REAL ROI™ methodologies and author of the Artech House book, Discovering REAL Business Requirements for Software Project Success.

Dig Deeper on Software requirements

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What is the most common barrier you encounter in getting reliable user requirements?
That's easy... The requester has no idea of the feasibility and scope of their request. They have an understanding of the budget and duration they have. Bringing reality into the process is an art.
Assumptions that are never documented.
The project was not well defined and specs keep changing. Mainly due to lack of interdepartmental communications. What is good for one department my not work for others. You need to work as a team.
Thanks Todd, 
It sounds like abs2013 and JRTArch are running into issues related to communication as well. For abs it's about communicating what can realistically be done with the current budget and time. For JRT it's about documenting assumptions so that they can be communicated to others. 

  • Do you have advice for increasing communication at the outset and creating that important spirit of teamwork?
getting to the real core issue that needs fixed.  many users think they understand the system now, and come up with a "solution" they want you to build, when if they just told us the problem they were experiencing we could come with something better, faster, and cheaper.
BigKat hit on a good point. End users may not know what tools are available to complete a project in a more effective manner. They may not know that some of the data they may be looking for is already available in another format. No need to duplicate the database efforts when we can re-use existing data.
The requester often unwilling to take the time to fully define what they want.  
Communication is key, but even before needing to communicate with different areas, we need to make sure we have identiifed the real reason behind the requirement. We don't really need to know what they want us todo do, but the real problem they need solved.

We've found that asking lots of 'why' questions usually helps getting there.
Thank you all for your discussions. I didn’t have much to add to Editor James Denman’s comments regarding the first several responses. Starting with BigKat’s comments, though, we’re getting into more productive territory. By the way, while I agree communications are (always) an issue, I find that citing it seems to make people feel as though they’ve solved the problem when in fact such a general, nebulous term really doesn’t lead to any improvements. Some of you may remember the Pogo comic strip, which once said, “we is met the enemy, and they is us.” I fear that the requirements/business analysis establishment in many ways is a major factor in its own difficulty getting reliable requirements. Although there certainly are many good things, some of the main models and supposed good practices touted by many prominent requirements ‘authorities’ and institutionalized in BABOK actually interfere with reliably getting the right requirements right. Much of business analysis is predicated upon the mistaken presumptions that requirements describe the product/system/software to be built and the business analyst’s job is simply to gather requirements by asking, “What do you want,” and then documenting the user’s design of said product/system/software. Wrong on both counts. Users (more accurately, ‘stakeholders’) don’t need your product/system/software. Rather, stakeholders need their problem, opportunity, or challenge addressed adequately and appropriately. Effective business analysis focuses on the business/stakeholders, interactively and actively eliciting and analyzing data to identify and understand the REAL business problem, opportunity, or challenge that will provide value when addressed adequately and appropriately. By gathering and analyzing sufficient data to understand the REAL problem’s causes, the effective business analyst discovers the REAL business requirements deliverable _whats_ that provide REAL value by overcoming the causes and thereby achieving objectives when satisfied by a product/system/software _how_. When we focus on discovering the REAL business requirements deliverable _whats_ that provide value when met, we have a much better chance of designing and implementing a suitable product, system, or software; and the business stakeholders are far more likely to participate and communicate productively. See more in my book and articles, “How to avoid requirements creep” at and “Problem pyramid discovering REAL software requirements” at