Guidelines for handling changes in software requirements

The first step is to recognize and accept that changes and growth in requirements will be a reality on nearly every project. It's almost impossible to fully identify and specify every requirement at the outset. So you need to plan your project schedule to anticipate and accommodate a certain amount of requirements change. A good way to do this is through the use of contingency buffers built into the project schedule. Without such buffers, the very first new requirement or altered requirement that necessitates rework will guarantee a schedule slippage.

To help your own organization cope with change, study previous projects to learn where requirements changes come from. Were certain user classes overlooked? Did the wrong people provide requirements or were certain important individuals not involved? Were new business rules discovered during the project? Did the business or regulatory environment change, thereby demanding requirements changes? Did the analyst misunderstand customer input? Did apparently simple requirements conceal large icebergs of implied or unstated functionality? Understanding previous experiences that led to changing requirements and the magnitude of the changes will help you adjust your approaches to requirements development to minimize such changes in the future.

Incremental or iterative development life cycles, such as agile development, provide another strategy to cope with change. If you know the requirements are highly uncertain at the outset, plan to execute the project through a series of fairly small increments.

Software requirements gathering resources: How to document system, software requirements Clarifying software requirements Learning Guide: Software requirements gathering techniques

Begin by implementing that portion of the requirements that is well understood and obtaining user feedback. Progressively discover additional requirements through future incremental development increments. This reduces the chance of going far astray on requirements. Prototypes and simulations also are good ways to get user feedback on the preliminary requirements to confirm their validity and to fill in gaps.

It's important to have an effective change control process in place, not to stifle changes but rather to make sure that the right people make good business decisions to accept the right proposed changes. But perhaps most important is the need to recognize that change happens, so your project plans have to be sufficiently elastic to accommodate change.