Q
Problem solve Get help with specific problems with your technologies, process and projects.

Guidelines for handling changes in software requirements

Software requirements are subject to change. Expert Karl E. Wiegers explains how to understand the causes of these fluctuations and how to handle them.

How do I cope with a change in 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. 

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.

Next Steps

How to document system, software requirements

Clarifying software requirements

Learning Guide: Software requirements gathering techniques

This was last published in July 2007

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close