Writing quality requeriments

Writing Quality Requirements1
Karl E. Wiegers
Process Impact www.processimpact.com It looks like your project is off to a good start. The team got some customers involved in the requirements elicitation stage and you actually wrote a software requirements specification. The spec was kind of big, but the customers signed off on it so it must be okay. Now you are designing one of the features andyou’ve found some problems with the requirements. You can interpret requirement 15 a couple of different ways. Requirement 9 states precisely the opposite of requirement 21; which should you believe? Requirement 24 is so vague that you haven’t got a clue what it means. You just had an hour-long discussion with two other developers about requirement 30 because all three of you thought it meantsomething different. And the only customer who can clarify these points won’t return your calls. You’re forced to guess at what many of the requirements mean, and you can expect to do a lot of rework if you guess wrong. Many software requirements specifications (SRS) are filled with badly written requirements. Because the quality of any product depends on the quality of the raw materials fed into it,poor requirements cannot lead to excellent software. Sadly, few software developers have been educated about how to elicit, analyze, document, and verify the quality of requirements. There aren’t many examples of good requirements available to learn from, partly because few projects have good ones to share, and partly because few companies are willing to place their product specifications in thepublic domain. This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these qualitycriteria. It may be too late to revise them, but you might learn some things that will help your team write better requirements the next time. Don’t expect to create an SRS in which every requirement exhibits all of these desired characteristics. No matter how much you scrub, analyze, review, and refine the requirements, they will never be perfect. However, if you keep these characteristics in mind, youwill produce better requirements documents and you will build better products. Characteristics of Quality Requirement Statements How can we distinguish good software requirements from those that have problems? This section describes six characteristics individual requirement statements should exhibit, while the next section presents desirable characteristics of the SRS document as a whole. Aformal inspection of the SRS by project stakeholders who represent different perspectives is one way to

1

This paper was originally published in Software Development, May 1999. It is reprinted (with modifications) with permission from Software Development magazine.

Copyright © 1999 by Karl E. Wiegers

Writing Quality Requirements

Page 2

determine whether each requirement has thesedesired attributes. Another powerful quality technique is to write test cases against the requirements before you cut a single line of code. Test cases crystallize your vision of the product’s behavior as specified in the requirements and can reveal fuzziness, omissions, and ambiguities. Correct. Each requirement must accurately describe the functionality to be delivered. The reference forcorrectness is the source of the requirement, such as an actual customer or a higherlevel system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could itself be incorrect). Only user representatives can determine the correctness of user requirements, which is why it is essential to include them,...