"The most common problem with specs is when they’re written by someone without any idea of the things programmers really need to know." That's true. But the real problem here is the fact that when the project goes sideways, and the stakeholders are in a tizzy over the divide between what has been specified and what has been delivered, you as a developer, or architect, or project manager, need to have a 'CYA' strategy.
So, how can you both try to deliver what the business analysts have promised, while also covering yourself when things go wrong? The strategy isn't an earth shattering secret.
You communicate and document. That's the biggest and simplest self-preservation strategy out there. If you're doing your job right, make sure there's a papertrail attesting to that point.
Spend some time making your solution configurable. That way it can adapt to a change or two when the top architect gets fired, and the new architect comes in and wants to assert her authority.
And of course, keep your configuration routines separate from your data routines. And keep both of those separate from your code.
Then, bring it all together. Will the end result win your programmer of the year? Perhaps not, but a configurable, layered, well documented project with a well communicated history will deliver an end product you can defend to the death if the need arises.
For a more clever and in-depth analysis of the situation, head over to Mock's blog and read the entire article on how to make the systems guy love you.