Some interesting statistics:
Thus, we have the requirements challenge,
Attempts to face this challenge by early detailed requirements analysis and freeze can rarely succeed, given the high rates of change. In a study of failure factors on over 1,000 software projects [Thomas01], such practices were associated with the largest contributing factor for failure, being cited in 82% of the projects as the number one problem.
It is also instructive to learn how valuable early specified features really are: As mentioned previously, research of many projects [Johnson02] showed that 45% of features were not used with an additional 19% rarely used (Figure 5.3).
Figure 5.3. actual use of requested features
Even so, some waterfall requirements advocates have used the above-mentioned cost-of-change research by Boehm [BP88] to continue justifying the practice. It is noteworthy that the creator of this cost data, Boehm himself, was an early and active advocate of evolutionary IID methods, rather than the waterfall, to solve this problem [Boehm85, Boehm96].
Thus, another approach, evolutionary requirements, is now recommended to meet the requirements challenge.
The reality of how people handle the requirements challenge is indeed becoming more iterative. In a study of 107 projects [CM95] only 18% of the projects tried to complete the requirements in a single early step; 32% used two cycles of requirements refinement (with programming in between); and in 50% of the projects the requirements analysis was completed over three or more iterations.