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. Specifying Quality Requirements With Planguage 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." |