[ellius]

As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.