Meeting the Requirements Challenge Iteratively

Some interesting statistics:

• In a study of over 8,000 projects [Standish94], 37% of the factors on challenged projects were related to requirements (see Figure 5.2).

  Figure 5.2. factors on challenged projects

  

• A study of defects by category [SKTYBE92] found that the largest category was in requirements 41%.

• Boehm [BP88] showed that the cost of fixing a requirement defect increased non-linearly from early to late in the project.

• Requirements change 25% or more [Jones97, BP88].

Thus, we have the requirements challenge,

We want the requirements to be stable, but they aren't.

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 heart of why IID with evolutionary requirements works:

It provokes the inevitable change early.

Since requirements will change, IID provokes more of the change early on via early development iterations with feedback and practices such as multiple requirements workshops.

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.