Software Configuration Management -Change Control

At the start, we know very little about the software requirements. The original idea may be scribbled on a bar napkin, but then we start the Requirements Discovery process. During Requirements Discovery we quickly ramp up as we rapidly write the initial round of requirements - the ones that everyone can agree on. Our goal is to reach 100% understanding of the requirements.

Then something happens. We run out of easy requirements and get to those that are in dispute or have yet to be defined. To top it off, requirements that were already defined begin to change - they want it this way, not that way. The rate of increase slows.

Then disaster strikes! Someone wants a NEW feature! Now our percent of knowledge declines. Unless we do something to close the gap and complete the process, we will devolve into Requirements Instability. At that point, everyone may be convinced that they, and only they, understand the real requirements! Documentation lags, consensus is lost, but there is still hope - we can still try to blame others for the poor state of the requirements!

And the code? Once Requirements Instability sets in, the programmers will probably just write whatever they think needs to be written. At that point, the management can only hope that the programmers guess correctly!

Change Control is simply the formal process of requesting and approving/rejecting proposed changes.

NOTE: Change Control is normally NOT required when fixing defects, unless the time or method required to fix the defect will force another Configuration Item to change. For example, if fixing a defect will drive the project over schedule, the the Change Control Board may need to choose between accepting the defect or extending the schedule.