Changing Software Development: Learning to Become Agile

6.5. Change Starts with Business Requirements

"Stable requirements are the Holy Grail of software development."

—Steve McConnell (1993)

Once upon a time, stable requirements were seen as a prerequisite for starting a software development project. There may be a few people who still believe this, but many in the IT world have given up looking for the Holy Grail of stable requirements.^[] In reality, changing requirements have become an accepted fact of life for software developers. Requirements change for good reasons: businesses don't stand still and neither should software projects, so to expect the business to freeze for months on end isn't realistic.

^[] The other Holy Grail, 'reusable software', is also finding fewer devotees since the emergence of Agile development.

The failure to accurately capture requirements is a regular problem with traditional, waterfall, approaches to development. Consequently, traditional development methodologies impose potentially lengthy requirements for capture and analysis phases before any design or coding begins. The longer the requirements phase, the greater is the gap between the start of requirements capture and the first working delivery. The greater the elapsed time between the start of a project and delivery, the greater are the chances that things will change. Increasing the time spent in the requirements and analysis phases comes at a substantial cost.

Project teams that believe that requirements have been successfully captured will resist ...