[greenyoda]

"so that we knew exactly what we were building, what it needed to accomplish and what does 'finished' mean"

That only works when the people who are asking for the software know what they want. In the situation described in the article:

"The one where you try to replace an expert user’s years of experience and intuition with software. What started out as a vague and wooly requirement, soon became a monster as we started to dig into it."

In my experience, the business people aren't good at turning vague and wooly requirements into precise specifications for software - they're not trained as logical thinkers. Usually, that job falls on the developers, who will try to clarify the requirements until they have something that's precise enough to be translated into logically consistent code. This may involve a lot of trial an error, since trying to extract the requirements from the business people is a non-linear process (e.g., they can change their minds on what the spec is, and a seemingly small change in the spec can have a large effect on the architecture).