Iterative approach effect on prerequisite

Different kinds of software projects need different balances between preparation and construction.

(scroll to the Appendix at the end to see some good practices for common kind of software practices) 👇

Some projects need iterative & some need sequential approach.

A misinformed opinion is that iterative techniques don't need to focus on prerequisites.
However in reality, Iterative approaches only tend to reduce the impact of inadequate upstream work, but they don’t eliminate it.

Example table below compares 2 approaches with respect to prerequisites. Approach 1 relies solely on testing & discovers defects later, making the cost higher, and Approach 2 discovers defects iteratively as the project progresses.

Skipping Prerequisites	Focusing on Prerequisites

A focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach.

Most projects are neither completely sequential nor completely iterative. It isn’t practical to specify 100% of the requirements or design up front.

One common rule of thumb is to plan to specify about 80 percent of the requirements up front, and then practice systematic change control to accept only the most valuable new requirements. Another alternative is to specify only the most important 20 percent of the requirements up front and plan to develop the rest of the software in small increments.

How to choose between Iterative and Sequential Approaches

You might choose a more sequential (upfront) approach when:

• requirements are fairly stable.
• design is straightforward and well understood.
• development team is familiar with the applications area.
• project contains little risk.

You might choose a more iterative (as-you-go) approach when:

• requirements are not well understood.
• design is complex.
• development team is unfamiliar with the applications area.
• project contains a lot of risk.

Appendix

Table: Good practices for 3 common kinds of projects