There's a famous quote from the United States Supreme Court a few years ago. They were trying to determine what was art and what was pornography. Lawyers being what they are, they were trying to quantify what pornography was so they could write it down... encode the definition into rules. Unfortunately this is a very difficult task. One of the judges expressed his frustration by saying that he couldn't tell you what pornography was, but he knew it when he saw it (link
Software is a lot like pornography. It's difficult to quantify and write down in the form of requirements and design documents. It's very difficult, if not impossible, to completely extract a project's requirements and details, but we keep trying. At some point we need to step back and understand the only way to really understand what software is, and what it should be, is to see it.
That's where the Agilist's time-boxed iterations (link http://agile.dzone.com/articles/hard-stop-iterations-no-where ) come into play. The goal of time-boxing is to have a product completed and ready for a demonstration in a very short period of time. In practice most teams don't have a demo each week, but some do. And it puts your team in a position of being able to show
the customer the product much more quickly than our traditional timeline. And by showing the product to your customer, you can find out what it is they really meant by their original descriptions. You'll understand exactly where the words didn't work, and only seeing the project will allow you to make this evaluation.
After all, software is very difficult to write down perfectly. It's often fuzzy, the requirements change, and people aren't sure what they want. If you want to define it, you'll need to show it to your customer... it's the only way to know for sure.