Summary

Taking an agile approach to your project does not have to mean abandoning up-front requirements gathering or up-front architecture and design. Often, spending the time to get the design right, based on what the customer really wants, can actually increase a project’s agility.

We aren’t suggesting that, taking this approach, requirements won’t change later on: they will. However, the level of “requirements churn” should be much lower, and what changes there are will have a lower probability of forcing a big, costly, high-risk change to the architecture.

The most visible (and probably the most often cited) reason for project failure is lack of effective user involvement, which often results in unstable requirements. One approach to fix this problem is to make the project as malleable (or agile) to the forces of change as possible. Another approach is to improve the requirements elicitation process (in other words, talk to the customer; find out what the customer really needs; use effective requirements elicitation techniques [as we describe in this book]; ask the customer hard, detailed questions; and hit the brakes if the customer doesn’t have the answers) and to model these requirements in the form of use cases.

Contrary to popular opinion, these two approaches are not mutually exclusive. In fact, combining the two approaches (traditionally seen as diametrically opposite—agile versus nonagile) should drastically reduce the risk that requirements churn places on your project.