Managing change in Requirements!

[Srikanth Gandla]

Moderators and fellow members,

I would really appreciate if members can share their experiences with handling changes in requirements by the stakeholders and business users after the Business requirements have been gathered, functional requirements have been documented, Use case, Sequence diagram are completed and the development has developed GUI components. In the construction phase for example In an application which involves member registration in a web based system. A small change in requirements

From Question: Are you 18 years old or more?  Yes/ No

To Question: Date of Birth  3 drop down boxes with date, month, year


How would you handle change in this type of a scenario or a scenario in which more development effort is required?

I appreciate your comments and responses in advance.

Thanks
-S.G

[Roy Manalo]

in my experience, we have change management. this is a team that manages all changes in specs and other development concern outside the terms of agreement. If the requirement and specification has been established. it is hard for the development team to re acquire the momentum if there are drastic changes, but if the changes is minor and does not affect on the other parts of development, its ok to pursue that change. the key here is to have a team that will handle the analysis and  implementation of change.

 

hope this helps

 

always,

 

Roy M. Manalo

Project Manager

BluePython Corp.

+639182360804

 

--
cheers!!!

[BA Forum Moderator]

Hi Srikanth,

In my case, I would always try to look at the motivations or reasons for the change. In your example below, I would probably ask the stakeholder two questions:

1. Does she want to validate if the user is 18 years old?
2. Does she want to capture the actual date of birth?

For question #1, if the answer is yes, then you can probably propose that you retain the original specifications.  If the answer is no, then consider question #2.

For question #2, if the answer is yes, then you may really have to change the specification.  Otherwise, dig deeper for the reason behind the change.

As much as possible, when dealing with our stakeholders on change in requirements, I make sure that I make impressions/communicate the following areas:

A. Flexibility - I say that the change can possibly be done (if it's really possible to do - one that wouldn't require a breakthrough invention, like run MS Office without Windows).  But it's up to them, if they'd really like to implement the change (given considerations in B below). 

B. Quantify!  - Next, I tell them how much effort the change is going to take and how many days the project will be delayed because of the change.  I then compute my late cost per week (LCPW) or per day and present this to the stakeholder.  It should get her thinking.

C. Bargain! - Of course, either way, the stakeholder should be happy. Tell her you can accommodate the other change requests, but not this one.  Or, tell her you can apply the change request in the next release.  Put your imagination to work here. :D

All the best,
Moderator

On 1/26/06, Srikanth Gandla <sga...@gmail.com> wrote: