It's a pretty complex methodology where one of the most important things to do is to get the user's requirements - what the customer wants it to do. And that is a harder job than you think. Last Sunday (29/1/06), Dilbert showed one of the most common problems in gathering requirements:
It's not the funniest Dilbert comic, but it really illustrates a common scenario where the users just don't know what they want. So that was a comic just for the software engineers among us. Thanks, Scott!
[Dilbert is a creation of Scott Adams and is distributed by UFS, Inc. The comic above was reproduced without permission]
1 comment:
You have to accept the fact that most of the time, you have to "draw" out the requirements from your users. They only roughly know what they want. So, after you've built what you think they want and let them test it, then they'll get a better idea of what they actually want. They'll start asking you to change the flow, add some features. To which you will vehemently decline, because it was not outlined in the requirements specification. Conclusion is, make sure the requierments document is clear (no vague words), and make sure they sign off on it before doing major development work. But actually, in such cases, building a prototype for them is ideal, so that they can get to "feel" the system before hand. However, time is usualy a luxury...
Post a Comment