Using a nonfunctional requirements template, plus examples

Requirements expert Robin Goldsmith explains how and why to use a nonfunctional requirements template.

Creating a template is perhaps the most common approach to dealing with nonfunctional requirements. These generally differ from most other application development templates, which usually prompt for all the data attributes about a specific subject so that they are not missed. For instance, a template describing America's states might prompt to identify each state's capital, population, state bird, date of admission to the union, etc....

In contrast, typical nonfunctional requirements templates often are just a laundry list of different types of nonfunctional requirements. A states template in that format would simply list the 50 states.

Templates also tend to be in one of two formats: a basic list and a list-plus-description list. The basic nonfunctional requirements template lists a number of types of nonfunctional requirements and provides a space next to each type for the analyst to enter the project's requirements for that type. For some types, the project may not have any requirements to record. The premise is that no type will be missed and all will be documented on that one- or two-page template. Most templates list only a fraction of the nonfunctional requirements types listed below.

Most nonfunctional requirements lists don't seem to give much guidance.

The other format difference regards the location and extent of description for each type. Thus, many templates list only the types but have no description of them on the template, whereas some also have brief descriptions of each type on the template form to be filled in. While some templates have no accompanying descriptions of each type, others put the type descriptions in a separate instructions document, which take anywhere from a couple of pages to an entire book. Some refer to just the type descriptions as the "template." 

Regardless of whether the template just lists nonfunctional requirements types or also includes space for entering the project's requirements, the conventional approach captures the project's nonfunctional requirements for each relevant type all together in a single place.

Examples: Exterior and interior nonfunctional requirements lists

Following is a fairly comprehensive but by no means exhaustive list I use of nonfunctional requirements types along with a brief description of each. Your definitions may vary. The important thing is consistency among those working together. I've grouped the list in two major categories that most templates tend not to recognize. Some people also distinguish requirements that pertain to the current situation from those that pertain to the future. 

Even when recognized, many of the following types of nonfunctional requirements are difficult to test and thus frequently are not tested at all or at least not tested as adequately as may be desired.  Often their testing consists of surveys, which are of questionable validity. A few are tested in a separate manner, often involving special tools and carried out by specialists in the area. In general, the key to testing them involves creating test situations where the system will fail if the nonfunctional requirements are not met sufficiently.

First are exterior (or external) nonfunctional requirements types that generally are observable by and important to the user:

  • Usability: how easy it is to use, which often includes how easy it is to learn.
  • Reliability: the extent to which it works as and when needed.
  • Correctness: does the proper things properly, often applied especially to calculations.
  • Durability: the length of time between failures; may be the extent of damage when it fails.
  • Appearance: looking pleasant or even attractive, often promoting confidence in its use.
  • Availability: able to be used when needed, often related to uptime.
  • Safety: not causing harm, injury or damage.
  • Security: accessible and usable only in authorized ways by authorized users.
  • Privacy: protecting personal information and undesired access to personal space.
  • Scalability: able to be used by varying numbers of users, or with varying amounts of data.
  • Stability: the extent to which capabilities and characteristics stay the same.
  • Integrity: preserving data contents and structures, especially when failures occur.
  • Usefulness: meets relevant needs.
  • Delightfulness: going beyond expectations in ways that create delight.
  • Operability: can be operated in a reliably efficient manner.
  • Performance: speed and throughput.
  • Capacity: number of users, records or data volumes.
  • Supportability: timely and helpful assistance with usage and operation.
  • Adaptability: ability and ease of fitting to different circumstances.
  • Cost-Effectiveness: value of benefits outweighs costs of achieving them.

Second are interior (or internal) nonfunctional requirements types that generally are observable by and important to engineers/builders/operators but often not to users:

  • Efficiency: taking minimal time, effort, resources or cost to create, or operating a solution.
  • Style/Elegance: pleasant or clever design and/or implementation of the design.
  • Reusability: extent to which intermediate and/or end products can be reused rather than rebuilt. 
  • Structure: suitability, strength and economy of the design.
  • Database: structure, efficiency and integrity of stored data.
  • Configuration: other hardware and software components connected with the system.
  • Environment: physical and technological situation in which the system exists. 
  • Portability: ability and ease of using the solution in different configurations or environments.
  • Flexibility: ease or ability of adapting the product to deal with different situations.

    More on this topic

    Learn why the term "nonfunctional" misleads

    For a more in-depth analysis of nonfunctional requirements

    Differentiating between functional and nonfunctional requirements

    A look at requirement types in relation to software engineering

  • Traceability: ease or ability to trace artifacts to their sources and sources to artifacts.
  • Testability: ease or ability to create tests that demonstrate implemented design works.
  • Maintainability: speed and reliability of updating and/or correcting production products.
  • Supportability: speed, reliability and usefulness of assistance to product users.
  • Manageability: ease of keeping track of artifacts and changes to them.
  • Manufacturability: ease of implementing a design.
  • Operability: ease of operating an implemented design (product).
  • Understandability: ease of understanding a design or implemented design (product).
  • Documentation: suitability and sufficiency of explanatory descriptive information.
  • Interoperability: ability to function in different configurations or environments.
  • Compatibility: ease and ability to work with other products, systems and software.
  • Localization/Internationalization: ability to function in other geographic/cultural areas.
  • Installation: ease, speed and reliability of installing a product, system or software for use.
  • Distribution: ease, speed and reliability of distributing a product, system or software to users.

The main benefit of a laundry list template is that it prompts attention to identifying each listed type of nonfunctional requirement. That's necessary but hardly sufficient for accurately identifying relevant nonfunctional requirements. Most lists don't seem to give much guidance for how to tell what the requirements are. Indeed, there's a good chance that merely having a greater amount of descriptive verbiage about each type may not appreciably lead to more accurately identifying the project's nonfunctional requirements.

Let us know what types of requirements templates you use when gathering user requirements.

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.

This was first published in December 2013

Dig deeper on Software Requirements Gathering Techniques

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

2 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close