I've yet to meet a requirements document that was good enough for both parties to agree that the contract had been fulfilled. It's almost always come down to browbeating or going unpaid.
What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want.
I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team.
With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet.
Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.