mindless ramblings

Dilbert describes it succintly. It is tough to perform good requirements elicitation, especially from people who may not be conversant with software development. What the client tells you is often nothing like what he really wants. Even worse, he may end up telling you when you are almost done coding that he forgot something and wants it implemented ASAP. If you are lucky, it’s something small and quickly fixed and not something that requires ugly hacks or going back to the design stage! It’s always nice to have a client who knows what they want and can tell you that in a clear and effective manner.

When I was doing my Software Development Project back in school, we had 3 teams who were working on the same project and trying to “win” over the client. During the initial requirements meeting, one of the members from another team kept asking the client if he wanted random extraneous features (eg. Unicode/internationalization support). Being the client, it’s hard to say to no if your development team offers to add features for you and as a result he just said yes to everything that they came up with. It almost became a brainstorming session to see just how many things they could add in to increase the feature list to become essay length. If this ever happens to you, make sure you direct the discussion away unless you are confident that you have the resources available to actually make it happen, or at least reduce the promised feature list that the client will sign off on. It’s better to have a stable well-written application with a smaller feature set as compared to a unstable app with a little bit of everything thrown in.