IBM—华为PDM项目软件需求管理.doc

Writing Good Requirements All too often, software requirements are badly written and hard to follow. Clarifying your specifications will benefit everyone involved. by Karl Wiegers. Software Development Magazine, May, 1999 It looks like your project is off to a good start. Your team had customers involved in the requirements elicitation stage and you actually wrote a software requirements specification. The specification was big, but the customers signed off on it, so it must have been O.K. Now you’re designing one of the features and you’ve found some problems with the requirements: You can interpret requirement 15 a couple different ways. Requirement 9 states precisely the opposite of requirement 21; which should you believe? Requirement 24 is so vague that you don’t have 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 meant something different. And the only customer who can clarify these points won’t return your calls. You’re forced to guess what many of the requirements mean, and you can count on doing 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 its raw materials, poor requirements cannot lead to excellent software. Sadly, few software developers have been educated about how to elicit, analyze, document, and verify requirement quality. There aren’t many examples of good requirements 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 the public domain. This article describes several characteristics of high-quality software requirement statements and specifications. I 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 writ