Requirements Quest announces Roxanne Miller's retirement 06-30-2024!
Requirements Quest announces Roxanne Miller's retirement 06-30-2024!
Click on an image below to learn more.
Click on an image below to learn more.
Nonfunctional requirements are vital to the success of software systems. If they are not properly addressed, undesirable results occur such as unsatisfied users, developers, and clients, and schedule and budget overruns to correct the software that was developed without the nonfunctional requirements in mind.
Inconsistent terminology, confusing definitions, and the absence of a universally accepted classification scheme make understanding nonfunctional requirements a challenge. As presented in chapter 4 of The Quest for Software Requirements, the following simplified definition is used in the context of this site:
Nonfunctional Requirement – a specification of how well a software system must function.
In addition to alternative names such as quality attributes, quality requirements, and non-behavioral requirements, nonfunctional requirements also have been referred to by nicknames such as ILITIES and ITIES. These nicknames are derived from adjectives that end in the suffix ILITY, which are commonly used to describe the desired nonfunctional characteristics. Furthermore, nonfunctional requirements are referred to by the acronym NFR.
No doubt also stemming from inconsistent terminology and confusing definitions, we cannot agree on how to spell these important requirements. Is it non-functional or nonfunctional? This may be quite trivial to many, but it is still an indication of the lack of uniformity.
Nonfunctional requirements can be classified based on the user’s need for software quality. Addressing a user concern will necessitate the formulation of a number of functional requirements, but the user concerns will also act to constrain other requirements that are characteristic of nonfunctional requirements.
In order to apply a user-focused approach, it is necessary to understand who the user is. The software user is any person who comes into contact with the software system. User contact with the software system might occur in the following ways:
Based on the user-focused approach, nonfunctional categories can be classified into three requirement groups: Operation, Revision, and Transition. Each group is explored further in the following sections.
The OPERATION group describes the user needs for a system that performs or functions well. The operation group subdivides into the following nonfunctional categories:
The REVISION group describes the user need for a system that is easy to correct when errors occur, and is easy to add on new functions. The revision group comprises the following nonfunctional categories:
The TRANSITION group describes the user need for ease of adaptation to changes in the technical environment. The transition group includes the following nonfunctional categories:
This quick-reference job aid is included as a download in the on-demand course, Nonfunctional Requirements.
Overlooked and poorly defined nonfunctional requirements are widely recognized to be among the most expensive and difficult errors to correct following the implementation of a software system.
Before diving in, let's establish some common terms. A definition that I prefer is a nonfunctional requirement is a specification of how well a software system must function. Nonfunctional requirements are known by several alternative names such as quality attributes, quality requirements, and non-behavioral requirements. Furthermore, many abbreviate nonfunctional requirements as NFRs.
Following are 10 reasons why we overlook these hard-to-identify, yet vital, requirements.
1) Subjective nature. Nonfunctional characteristics can be viewed, interpreted, and evaluated differently from user to user. For instance, one user contends that a two-second response time is acceptable, while another user feels that a sub-second response time is necessary.
2) Integrated nature. The goals of nonfunctional requirements can conflict with one another. Nonfunctional requirements typically have a broad effect on systems. That is, nonfunctional requirements are combined to produce a whole, complete system.
3) Relative nature. The interpretation of relevance and importance might vary depending on the specific system under consideration, as well as the products and services produced by a business. For example, organizations in the financial industry such as banks and insurance companies are likely to view precision, accuracy of information, and access control (security) of the confidential information as prominent desired quality attributes.
4) Don’t know what they [NFRs] are. Inconsistent terminology, confusing definitions, and the absence of a universally accepted classification scheme make understanding nonfunctional requirements a challenge. The industry can't even agree on how to spell nonfunctional--should it contain a hyphen or not? (In case you haven't noticed, I prefer to leave the hyphen out.)
5) Don’t know who to ask. Particularly due to the reasons stated above, it is a challenge to identify the stakeholders to elicit nonfunctional requirements from.
6) Don’t know what to ask. It's quite difficult interviewing a stakeholder for nonfunctional requirements without a consistent definition of what it is you're trying to ask them about. It's much easier for a user to respond to, "tell me what you want the system to do," than responding to, "tell me how well the system needs to function."
7) Don’t know how to represent (write) them [NFRs]. Functional requirements often conform nicely into a neat pattern such as, "The [specific system] shall [describe function to be performed] when [condition]." Nonfunctional requirements don't have such a generalized, prescribed pattern.
8) Don’t know where/when to represent them. Nonfunctional requirements generally don't trace consistently to user and functional requirements. Some NFRs support a specific user role, while some apply to all users. Should you write the nonfunctional requirements within the Business Requirements Document (BRD), or a separate document devoted solely to NFRs? What if you write use cases and user stories to communicate functional requirements? Where should you write the NFRs? If the NFR is directed at more than one user or spans more than one system, when should the NFR be addressed in development--during the first iteration or sprint, or later?
9) Make-It-Work-Just-Like syndrome. New products are often variations of a product that already exists with a few exceptions or tweaks. The stakeholder supplying the requirements for the new product often requests, "Make it work just like [product such and such, except this or that]." The problem is that the requirements for how the original product was developed either weren't documented at all or if documented, not kept up to date.
10) Assuming that “Everybody knows”. Nonfunctional requirements are often not documented because nothing is changing. That it, the new or enhanced system is supposed to work the same way all of the other systems work. However, what happens when development is outsourced to a vendor? The vendor doesn't know what standards are to be maintained.
Now that you have a better understanding of why nonfunctional requirements are overlooked or poorly defined, what can you do about it? Here are things your organization can do to reduce the risk of missed nonfunctional requirements.
Miller, Roxanne E., 2009. The Quest for Software Requirements, MavenMark Books, Milwaukee, WI.
Miller, Roxanne E., 2009. Software Requirements Questions.
Now, you can hear about how to reduce the risk of missing nonfunctional requirements by listening to the following podcast: Mastering Business Analysis/episode92
Photo Source: Technology Builders Inc (TBI)
Copyright © 2024 Requirements Quest - All Rights Reserved.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.