Right now I hear rumblings that the "crappy" quality of our software is a direct reflection of our developers not taking the time to "properly" read the requirements. I quote those two words for two very important reasons.
Number One: ALL software will be crappy... we're in the dark ages of software development. Accept it, if you think you've written perfect software, you probably didn't stick around long enough to have a hundred (thousand/million) customers. I've never met anyone (sane) who actually believes they wrote perfect software. Most of the time software is clunky and stupid 1/2 way through the project. The answer? Make your projects so small that having it turn into clunky and stupid 1/2 way through is no big deal because everybody knows you'll just fix it in the next iteration (i.e. next month). The only exception to this rule is in wonderland where people just proclaim victory even when the facts of failure abound.
Number Two: If I write a book that nobody can understand...It isn't that my audience is stupid and lazy, it means I'm a crappy author who doesn't understand my audience. If developers don't "properly" understand documents, you've probably written a "crappy" document. I've heard variations of this complaint from multiple directions... developers think non-technical users are dumb because they don't understand the "back button" behavior of a Web 2.0 AJAX application and Help Desk personnel think developers are dumb because they don't tell users exactly what went wrong in the system.
The fact is, it's easy to sling mud at a third party to absolve yourself from responsibility for mistakes that have been made, but it's much harder to come up with solutions to get things done.