I know firsthand that the most important aspect of a specification is signoff. The spec that doesn't have signoff by all involved parties (customer, programmer, and managers in between) will cause arguments. The spec that does have signoff will cause arguments, but these arguments can be solved by stating "Aha, here it is in the Spec."

But this isn't to suggest that the Spec is written and then placed under lexan glass in a humidity controlled environment for all tourists to come and be awed by. Until the deliverable is produced in final form, the Spec is a living document. Getting to that final form can be a pain with some Specs. I have one Spec come to mind where I produced code (part of which some monks gave me some really cool ideas for) that met every part of the Spec. The problem was that the client kept getting error messages (that were part of the Spec if an appropriate string wasn't entered). In review, my code met every requirement of the Spec, but the client had not met their end of the bargain. Guess who wins that situation?

So, I changed the program's code so that the client would not have to ensure that they had all of the data in their database built properly. The entered string still had to be verified, but it shows that signoff on a Spec doesn't mean that the client knows what they want (and this was a very detailed technical spec). I know that I've heard that somewhere before, maybe college. :)

Lexicon I don't think anybody gets the Spec right the first time, because the first time means that you have an idea. And no matter how well-formed that idea is, it's still not a set of electrons being beamed at your eyeballs in a concrete form you can interact with.

ALL HAIL BRAK!!!