Ricky & Stick - Nailing Down Requirements Early Isn't Always a Good Thing
Ricky & Stick main page
|
|
|
|
|
People have the annoying habit of changing their minds. When these people are end users of software systems, then requirements have the annoying habit of mutating.
Given this reality, some of the best advice about dealing with requirements for today's information systems is to maintain flexibility as long as feasible. Sometimes the ideal strategy is lots of prototyping, to gain buy-in from end-users. Sometimes it's possible, using iterative cycles, to delay freezing the requirements until some fairly late point. But it's almost always a poor idea to make a ton of early commitments if there's no compelling reason to do so.
Because if we do make some early commitment, we often don't (or can't) be sure what that commitment implies. And then when things change, which they always do, recovery is sometimes possible, but sometimes it's not. For Ricky, the first time things changed, he got away with it, by switching from red to dark blue. But when things changed again, and he had to convert that dark blue to pale yellow, he was lost. All he had was a useless picture of a blue airplane—there was no way to erase the blue crayon, and no recovery was possible.
The lesson is that while it's attractive to make early choices and "nail down the requirements," it's not always the wisest course. That approach can sometimes save a lot of time and money, true. But as you're thinking of taking that step, you might also take the trouble to determine from your stakeholder community whether all the assumptions that underpin the requirements are still applicable. Because it may be that there's a Gloria in your future, unseen right now, but just waiting for a chance to say: "Yellow, Mrs. Perillo."
For More Information
Send comments or questions to asp-requests@sei.cmu.edu
return to top
Ricky & Stick main page
Acquisition Support main page