- Iterative Development
- Risk-Driven and Client-Driven Iterative Planning
- Timeboxed Iterative Development
- During the Iteration, No Changes from External Stakeholders
- Evolutionary and Adaptive Development
- Evolutionary Requirements Analysis
- Early "Top Ten" High-Level Requirements and Skillful Analysis
- Evolutionary and Adaptive Planning
- Incremental Delivery
- Evolutionary Delivery
- The Most Common Mistake?
- Specific Iterative & Evolutionary Methods
- What's Next?
- Recommended Readings
This chapter is from the book
This chapter is from the book
This chapter is from the book
Evolutionary Requirements Analysis
In evolutionary and adaptive development, it is not the case that the requirements are forever unbounded or always changing at a high rate. Rather, most requirements discovery and refinement usually occurs during early iterations, and the earliest attention is given to understanding the most architecturally significant or high-business-value requirements. For example, on an ultimately 20-iteration project, it is likely that most requirements will be discovered and refined within the first three or four iterations (that include, in parallel, early software development).
In each iteration, there is a one- or two-day requirements workshop in which the specifications expand and refine, in response to further analysis and feedback from the system under development. See Figure 2.4. For example, the first workshop focuses on detailed analysis of 20% of the most architecturally significant and risky requirements; this gives the software architect enough meaningful input to start development and test in short cycles.
)
Figure 2.4. evolutionary and iterative requirements
Note as a design comment, that it is not true that 100% of the functional requirements need be known to start building an excellent core architecture. The architect needs to know most nonfunctional or quality requirements (e.g., load, internationalization) and a much smaller representative subset of functional requirements.