I think you must not forget the other side. For any user it is difficult to produce a complete list of details of what you want. Think of yourself, you think of new things all the time.
It is an incredible hard job to come up with all the requirements and details of something you only have a vague idea about. I don't think anyone can.
I have a book here from the 70's called "why software projects fail". When I read on blogs and get IT magazines I read on the cover "why software projects fail". And when I compare the book contents with the current listings.... nothing changed. Iterative development: yes lots of variations and it helps at some level. But after all this time the contents of the magazines have the same covers. If you don't believe me go digg up some magz from the way past and see how you can copy and paste the text to the now.
This problem is not solvable on the IT end. We have been inventing new tools, processes, checklists, requirements analysis schemes, (business) use cases, development frameworks, BPM, SOA, you call it and still the same problem exists...
You need to optimize this around 'the requirements specifier'. So you need to give those people the adequate tools, whatever to enable them to bring their level higher:
So e.g. for these persons: spec patterns out of the box, input from other projects and companies doing the same copy their end-result requirements and lessons, get people in there who have been through the dirt and can help this person to specifiy the things that caused the greatest problems and are not "trivial" but can only be learned after doing it (e.g. senior technical consultants doing the same stuff at other companies), give these people requirements composer tooling, for insurance, banks, telco etc...: dont invent your own processes buy the generic processes out of the box, etc... they NEED tools just like developer need tools and patterns and frameworks.
Does not solve it but improves it significantly IMHO the improvement should be around that area and not later down the road.
Just like a developer these persons just try to do the best they can. But unlike developers for their field most of the stuff we take for granted after 30 years is not even present in that field. In general their tools are outlook, excel, word and a board. Their processes are brainstorm sessions. A lot of improvement can be done in this field.
Ofcourse the problem is mostly that they are sitting "outside" IT so even plans from the CIO to improve the situation in that field fall on deaf ears... but that is another question: how to "sell" this.