I do not consider demands for specifications to be always reasonable, nor do I consider strict adherance to them to always be a good idea.

Specifications are often a programmer's way of telling the customer to nail down what they want in detail before the customer can possibly really know. And then when the programmer is done the specifications is a weapon that the programmer can wave around to say that people really did ask for the system they got which doesn't do what they want. And finally since users do not understand the language of specifications, it is guaranteed that they won't produce what a programmer needs to see, and the result is that the programmers get a virtually guaranteed place to start complaining from.

In short demanding a complete formal specification is a seemingly reasonable demand which is doomed to fail in many real-world situations. And users who have been around this path a few times are likely to be wary, they know that programmers (like lawyers) can make weapons of words. If they answer these innocuous questions, they will get what they didn't want and be told that it is what they asked for in the first place. And if it is unreasonable to ask a programmer to make, "Just another small change" with no idea what the implications of that change are, it is likewise unreasonable to ask the user to visualize in vast detail the needs of a system they have never seen, particularly when the demands of the business are likely to have changed in unanticipatable ways by the time it is delivered.

Instead clemburg above indicates a better approach. Yes, the programmer needs some sort of specification. However if you are going to get one, you are going to need someone who understands specifications to sit down with someone who can recognize what a successful system will be, and they need to iterate the design. The specification should be in a combination of media, pencil drawings, example tables laid out in a spreadsheet, use cases, etc. It may need to make it clear where there are grey areas which will be adjusted later one you have a better sense of what is possible and works. It may need to specify some things as being up to the developer, in which case they truly should be. For any complex project it will be incomplete, and this should be formally recognized with contact numbers, and plans for delivery of prototypes from which the spec can be refined.

How much detail is needed will depend on the scope of the project. Clearly a new accounting system will require much more process than a form to email script. However some of the traps to look out for are specifications too incomplete for the programmer to work productively, specifications that the user does not understand, irrelevant and limiting details fixed in the specification which it would be better to leave open, and decisions fixed in stone before people can reasonably know what the answer is. Avoiding these traps often steers you in contradictory directions. But then again, if it was easy, they would't need to pay the big bucks...

Incidentally if someone gives you a spec that you have to make decisions on to implement, either be sure that you have the authority to make those decisions, or else throw the problem back and find something else to work on until you have your answers.