How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer. Hearing such requests from users should lead to conversations to help explore what user-friendly means to the speaker. Even then, though, many business analysts still write fuzzy quality attribute requirements that do not do a good job of conveying expectations to developers and testers.

You can’t evaluate a product to judge whether it satisfies vague quality requirements. Unverifiable quality requirements are no better than unverifiable functional requirements. To address the problem of ambiguous and incomplete nonfunctional requirements, consultant Tom Gilb developed Planguage, a language with a rich set of keywords that permits precise statements of quality attributes and other project goals. For a comprehensive discussion of Planguage, see Gilb’s book Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage (Butterworth-Heinemann, 1995).

Planguage offers a very large number of keywords to permit expressing different types of requirements, but you need only a few of them to get started. Following is an example of how to express a performance requirement by using Planguage. Expressed in traditional form, the requirement might read: “At least 95 percent of the time, the system shall take no more than 8 seconds to display any of the predefined accounting reports.”

• TAG: Performance.Report.ResponseTime
• AMBITION: Fast response time to generate accounting reports on the base user platform.
• SCALE: Seconds of elapsed time between pressing the Enter key or clicking OK to request a report and the beginning of the display of the report.
• METER: Stopwatch testing performed on 30 test reports that represent a defined usage operational profile for a field office accountant.
• GOAL: No more than 8 seconds for 95 percent of reports. ß Field Office Manager
• STRETCH: No more than 2 seconds for predefined reports, 5 seconds for all reports.
• WISH: No more than 1.5 seconds for all reports.
• base user platform DEFINED: Quad-core processor, 8GB RAM, Windows 8, QueryGen 3.3 running, single user, at least 50 percent of system RAM and 70 percent of system CPU capacity free, network connection speed of at least 30 Mbps.

Each requirement receives a unique tag, or label, using a hierarchical naming convention. Requirement labels like Performance.Report.ResponseTime are long but self-explanatory. The ambition states the purpose or objective of the system that leads to this requirement. Scale defines the units of measurement and meter describes how to make the measurements. All stakeholders need to have the same understanding of what “performance” means. Suppose that a user interprets the measurement to be from the time that he presses the Enter key until the complete report appears, rather than until the beginning of the report display, as stated in the example. The developer might claim that the requirement is satisfied, whereas the user insists that it is not. Unambiguous quality requirements and measurements prevent these sorts of debates.

One advantage of Planguage is that you can specify several target values for the quantity being measured. The goal criterion is the minimum acceptable achievement level. The requirement isn’t satisfied unless every goal condition is completely satisfied, so make sure the goals are justifiable in terms of real business needs. An alternative way to state the goal requirement is to define the fail (another Planguage keyword) condition: “More than 8 seconds on more than 5 percent of all reports.” The stretch value describes a more desirable performance objective, and the wish value represents the ideal outcome. Consider showing the origin of performance goals. The “ß” notation following the goal criterion shows that it came from the Field Office Manager. Any specialized terms in the Planguage statement are defined to make them clear to the reader. This example provides a definition of something called the Base User Platform on which the test is to be conducted.

This unfamiliar notation is intimidating to some people. Others, though, recognize the merits immediately. I always describe Planguage when I describe quality attribute requirements in my training classes, and I encourage students to give it a try when we’re doing a practice session on writing quality requirements. When teaching a class at a high-tech company that makes electron microscopes, the entire class decided to adopt Planguage. They recognized how superior it was to their current approach for writing these all-important nonfunctional requirements.

Planguage includes many additional keywords to provide flexibility and precision in specifying unambiguous quality attribute requirements, and even business objectives. Specifying multiple levels of achievement yields a far richer statement of a quality requirement than a simple black-and-white, yes-or-no construct can. The drawback to using Planguage is that the resulting requirements are much bulkier than simple quality requirement statements. However, the richness of information provided outweighs this inconvenience. Even if you don’t write the quality requirements using the full Planguage formalism, using the keywords to think through exactly what people mean by “fast” will yield much more precise and shared expectations.

Joy co-authored this article with Karl Wiegers, Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.