Back in my undergraduate days I worked as an engineering intern for the USGS. One day one of the geophysicists and I went up into the mountains behind Central City (back before the days of gambling in Colorado) to a bunch of old ghost towns to collect data from a CHIM experiment that he was conducting. While we were up in the mountains I had the opportunity to learn how to pan for gold. That day I earned a deep respect for the hard work of prospecting, it is hard work and requires knowledge and experience to be successful.
In Software Engineering, Requirements Analysis is like panning for gold. The same amount of talent, effort, skill and dedication, can go into two projects. One fails and one succeeds. Requirements are often the difference. It requires knowledge, patience and experience to develop a good set of requirements. At the end of the day you will either have gold (solid requirements), fools-gold (useless requirements) or sludge (bad requirements). I have had experience working on projects that started from all three different requirements sets.
The best projects are the ones that found gold when performing requirements analysis. They have a clear description of the problem, it is understandable and easy to grasp. The requirements also have a clear expression of the desired solution. There are not many assumptions and there is not a lot of ambiguity. These projects rarely get off track and are often quite successful and fun to work on.
The other two styles are painful for everyone involved. For the "Fools Gold" type projects the requirements exist, but they are not understood by leadership. I have been on projects with thousands of requirements that are heralded as quality work, but when examined, don't express the essence of the problem. In the end the requirements for these projects end up being useless and the software often becomes "shelfware" and never sees the light of day.
Then there are projects that never seem to complete the task of Panning for requirements - they run out of time to do the job right, or they never have a clear sense of the core problem in the first place. This is expressed in the requirements for the system that does everything for everyone (except ten times faster). A many-headed hydra that has no direction and is trying to solve too many different problems. This is like coming back with a pan full of hematite - useless grey sludge.
At its core the customer (without any IT background) needs to be able to read over the requirements specification (use case / user story etc.) and answer the following questions:
Do the requirements capture the essence of my problem?
Do the requirements describe a solution to the problem?
Is there a central theme? Are there many themes? (Is this a hydra?)