• If you don't say you what you really want then you cannot complain when it doesn't do what you wanted it to
• Only you understand your requirements, state them as fully and completely as possible. Write them down. Get other people to read them.

These points assume that the clients know what they want ahead of time. I don't think that's necessarily a fair assumption - there's no reason to expect that they're omniscient.

Let me give you a somewhat monomaniacal example. I keep a bunch of utility code around for my own use. I'm both the client (writing applications using these libraries) and the developer (writing the libraries). When I'm writing the libraries, I usually stick with a simple interface until I know what I want. When I'm writing the applications, I run into a lot of mistaken assumptions at the interface, and modify the libraries appropriately.

For example, I do a fair bit of real-time 3d graphics hacking. One of my assumptions was "a texture is always created from a bitmap". I ran into trouble when I tried to build textures procedurally on the graphics card.

The point I'm trying to make is that people aren't likely to know what the Right Thing To Do is until they have some experience with the problem. Making people sign off on requirements ahead of time isn't a great idea; planning for requirements changes (yes, and allowing a lot more time for development) is more realistic.