After the requirements have been signed off on by the userbase, more detailed, technical design documentation can be prepared. Having this general design in-hand and signed off on by your audience will prepare you for the unavoidable eventualities of users who are dissatisfied with the product or claim that the product lacks intended features.

While everyone's experiences will vary on this subject, this was the way it was done at a consulting firm I worked for. We tried to document everything up front (mistake #1), have the user sign off on them (mistake #2) and when the user wanted changes, the Project Manager had to say "You signed off on this...if you want changes it will cost you $x".

The customers would typically piss and moan about this until the sales people (weasels) would buckle under the pressure and tell our boss to tell us just to do it. This of course would lead to projects being a) overbudget (internally we would mark these extra hours as "unbillable") or b) late.

I am now pretty convinced that attempting to document things up front and having a user sign-off is not the way to go about things. They will inevitably want changes...oh...and they'll want the changes in the same amount of time as the original project.

Granted, I will write up as much documentation as I need to get the job done, but that's about it. Luckily, as an independant doing mostly sub-contracting work, I can bypass most of the issues I've had in the past and focus on what needs to be done, not what a bunch of sales weasels want. I'm starting to see the value in what the Extreme Programming people have to say although I haven't had the opportunity to try any of it yet.

mike