According to the book “Design For TrustWorthy Software” in chapter 11 – step 5:
“What does the customer need? We have to analyze their clarified statements before we can clearly understand what we must do to satisfy them. Statements about reliability, cost, technology, usability, portability, and so on are very different from customer needs, which are solution-independent statements of the benefits customers desire. As such, different people using different tools deal with them at different times during development.
To capture our customers’ voices, we must begin by listening to raw customer expressions – the verbatims. What customers say are not requirements. They are statements that we must understand, classify, organize, and prioritize… What are their problems, opportunities, and strategic directions? What does the customer want, or need to do, about these concerns? The answers to these questions are true requirements…
One common refrain in software development is that the “user’s requirements are vague or continually changing.” To deal with this various incremental, iterative, and prototyping methods are available. But, are the requirements actually changing, or is just our understanding of them changing? Is the ambiguity of the specification due to some fundamental instability of the user’s needs, or is it caused by a weak requirements discovery process? Customer needs originate from the customer’s problems, opportunities, and the look-good-and-feel-good issues the customer faces in their situation. If the customer’s situation is not changing in frequent or unpredictable ways, if their problems or opportunities are not suddenly emerging or vanishing, we cannot blame the problem on “change.” (By the same token, unless the customer continues to require changes at the same rate after their system is delivered, the cause of the original “ambiguity” was not “change,” but our own weak ways of obtaining requirements).”
The idea that most of the requirements can not be nailed down at the start of the project leads to great inefficiencies later on and increases the chances the project will fail.
One of the most common reasons cited for a project failing is due to changing requirements. In most, if not every project, some requirements will change. Some studies have shown that on average only about 75% of all requirements are discovered in the first pass. But, that should not imply that requirements analysis should not be done at the start of a project. The earlier the requirements are discovered, then the easier and more efficient it is to plan and design a system that meets those requirements.
Efficient Software Development Methodology 