NONFUNCTIONAL REQUIREMENTS

---

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.

The OPERATION group describes the user needs for a system that performs or functions well. The operation group subdivides into the following nonfunctional categories:

• Access Security — how well the system is safeguarded against deliberate and intrusive faults from internal and external sources. 
• Accessibility — how easily people with the widest range of capabilities can use the system. 
• Availability — how dependable the system is able to function during normal operating times. 
• Confidentiality — how well the system protects sensitive data and allows only authorized access to the data. 
• Efficiency — how well the software system handles capacity, throughput, and response time. 
• Integrity — how well the data are maintained by the software system in terms of accuracy, authenticity, and without corruption. 
• Reliability — how well the software system consistently performs the specified functions without failure. 
• Safety — how well the system prevents harm to people or damage to the environment. 
• Survivability — how well the software system continues to function and recovers in the presence of a system failure. 
• Usability — how easily the user is able to learn, operate, prepare inputs and interpret outputs through interaction with a software system.

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:

• Flexibility — how easily the software can be modified to adapt to different environments, configurations, and user expectations. 
• Maintainability — how easily faults in the software system can be found and fixed. 
• Modifiability — how easily changes to the system can be developed and deployed in an efficient and cost effective manner. 
• Scalability — how well the software system is able to expand its processing capabilities upward and outward to support business growth. 
• Verifiability — the extent to which tests, analysis, and demonstrations are needed to prove that the software system will function as intended.

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:

• Installability — how easily the system can be installed, uninstalled, or reinstalled into a target environment. 
• Interoperability — how well the software system is able to couple or facilitate the interface with other systems. 
• Portability — how easily the software system can be transferred from its current hardware or software environment to another environment. 
• Reusability — how easily a portion of the software system can be converted for use in another.

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.

• Use a defined classification. For example, nonfunctional requirements can be classified into three groups: operation, revision, and transition. A classification will help stakeholders and the development team build a consistent language for discussing nonfunctional needs.
• Use a pre-defined list of elicitation questions. Having a list of pre-defined elicitation questions can increase the productivity of the team. The lists save time when preparing for elicitation interviews and workshops. For example, Software Requirements Questions (see references below) contains over 2,000 suggested questions for eliciting nonfunctional requirements across 14 common categories.
• Use a structure to ask good questions. I have been using the Requirements Framework successfully for years. The structure is based on the Zachman Framework. However, it has been tailored for usage in eliciting requirements from two perspectives: requirement suppliers and requirement receivers. The six requirements focus points (what, who, why, where, when, and how) are considered for each perspective. A detailed explanation and application of the Requirements Framework is found in my book, The Quest for Software Requirements (see references below).
• Engage the right stakeholders. The stakeholder profiling technique can be used to effectively identify not only who should be involved in the requirements definition, but also when the stakeholder should be engaged, and how much the stakeholder is expected to be involved.
• Use 'Invented Wheels'. Take full advantage of nonfunctional examples that others have already written. Software systems have a lot in common when comparing nonfunctional requirements so reuse and tweak the requirements written for other systems.
• Use State-of-the-Art Tools. If there is an automated tool that can help you do your work faster and more efficiently, why continue to do it the old-fashioned way? 

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