Update and Refine Requirements

In iterative development, requirements evolve incrementally. As described earlier, a majority of the work in defining the requirements is done in Inception and Elaboration. As discussed in the section Describe the Remaining Use Cases and Other Requirements, in Chapter 8, some less-critical use cases are described first in Construction. It should be noted, however, that as you design, implement, and test the various use cases, as you expose the system to users, and as you learn more about the problem domain and the implemented solution, you will need to continually refine the requirements.

Today's systems are too complex to allow you to define the right system from the beginning. This is why you need to be very open to reasonable modifications to the requirements during Inception and Elaboration. Major modifications ("Are you changing the scope or the vision of the system?", "Should you?") need to be carefully considered and discussed.

As your investment in the design, implementation, and testing of the system increases and as the delivery date creeps closer, you need to be more careful about allowing changes to requirements. You need to consider carefully the impact of each change on risk, cost, schedule, and resources, compared to the value the change will bring. In many cases, you need to state, "This is a great suggestion for improvement, and we should absolutely consider implementing this change in a later version of the system." But if the customer insists, you should make it clear what the cost will be and let the customer decide whether to cut scope or extend the project. In many projects, however, it is the Change Control Board or the project manager making decisions as to whether to allow late changes to requirements. Analysts also need to understand the overall approach to changes in requirements so they can support and guide people in making the right decision.