Guidelines for handling changes in software requirements

Guidelines for handling changes in software requirements

How do I cope with a change in requirements?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

This was first published in July 2007