This is a step, it's not a total solution IMHO. The problem is that people will look at a Word document and say "Yeah, that looks good. Do that" but when they get the application in their grasp they'll see things they want to change.

Yeah, they will. But, that's when you say: I met the design. If you want to change the product, please find the hours for me to:
1. Change the design
2. Change the test-suite
3. Develop
4. Change the documentation
Treat it like a "real" product and you'll find that they will, too.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

True - they need to accept that you delivered what they said they wanted and if they now want something different, someone has to 'pay' for the effort to implement it. But, in my experience, it is important to set the expectation at the outset that this is what will happen, so the initial estimate includes a proof of concept or pilot and a couple of iterations.

People almost never know what they want until they have something that they can play with. Then they are able to say "yes, this is what I want except ...".

The problem with documenting a spec before starting work is that it is very hard to strike a balance between the document being precise enough to be useful (and uncontestable after the fact) and the document being accessible enough that it will actually be read and understood. If I write a spec that someone misinterprets and signs off in error, then I should share the blame.

I do agree the importance of documenting things up front. However the point of documenting is so that everyone's expectations are in sync and (IMHO) one important expectation that everyone should have is that developing a solution is an iterative process.