Writing custom scripts is a tricky thing. Clients ask us for a script that does something and we build it. Sometimes we misunderstand those requirements, sometimes the client doesn't understand them, sometimes the client doesn't know until it's too late. It's an unfortunate situation when you deliver something that meets the spec but still doesn't do what the client asks for. In my experience, that means clients who are unhappy. In their mind they paid you to build something and it's wrong. In your mind, you built what they wanted. What do you do to ensure you've gotten the requirements right? What do you do when they're wrong?
Get them to complete a business requirements document which we use to create a technical design which cross references each design point to the business requirements it is there to address. The project manager then cross checks the two documents to ensure none have been missed. Once this is done a walk through is done with the client to double check understanding on both sides (though this has been done mainly through the terms of reference) and the documents are then base lined. To date we havent had a case of a client turning round and saying that we hadnt delivered what agreed. Naturally plenty of times when the client decides that they had missed parts off their requirements but we then go into change control mode.
We do a pretty good job of building what we say and explaining that to the client. They usually agree what we build and what they signed off on is correct. I should have been clearer. How do we limit the "forgetfulness" of clients to make sure they really are getting what they want? An iterative/milestone driven approach has so far been the best way to catch a client's "forgetfulness" early. While I love a properly done design document I find clients are "too busy", "don't understand" or any other such excuse to read them.
That's what I mainly do, I usually give the customer an URL where he can view the progress of what I'm making for him/her. This lets them know if I'm doing anything wrong and if I am, I can stop and fix it.
Have to say I would never send a client a tech spec/ design document and as they read them as they are control documents for the technical people and so in a language appropriate for them to understand. I will sit down and talk it through with them (face2face/ by phone) but I guess this is all where my personal project management background/ qualifications come in as whilst I can do basic .Net myself I am not a pro in that area
I think you've struck the nail on the head so to speak. Spending the appropriate amount of time reviewing the design and functionality with the client is key.