Writing quality requirements
Karl E. Wiegers · Software Development archive · 1999
Now you are designing one of the features and you’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 meant something 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.