Controlling the Change of Requirements

For example, say that as the design of the Graphical User Interface (GUI) gets underway, the designer realizes that there is no requirement for the GUI to provide transportation to the query subsystem, a function the designer thinks will be essential to the user. Using the requirements control process, the designer does not add the function (which would creep the requirements). Instead, the designer prepares an incident/problem report that notes the fact that there is not a requirement for the GUI to query transportation and notifies the keeper of the requirements list, who may be the quality assurance manager, the engineering manager, the project manager, or someone in configuration management.

The information provided by the designer is assessed for project impact and disposed of in one of the following ways:

1. The change is approved as a necessary component of the current system development effort. In this case, the schedule and budget will be assessed for impact. If the schedule must be maintained, a management decision will need to be made regarding adding a resource to do the programming, increasing hours for one or more existing programmers, or contracting out that piece of work. If the budget is already at bare bones and the schedule must be met, then the increased hours most likely will be included in the nonpaid exempt employee overtime category, but management must realize that they are increasing the project risk.

2. The change is approved as a modification to the current system to be implemented in the first software release subsequent to the initial delivery of the system. A work-around may or may not need to be developed for the initial implementation. The point is to make sure that there is agreement with the customer as to who is going to develop the work-around should it be needed. The other critical point to be made here is that the change control records and the process for using them must be implemented so that items such as this do not fall through the cracks as development for the next release gets underway.

3. The change is approved as a potential future enhancement to the current system without a specific schedule for implementation. Similar to the change approved as a modification, the change control records must be precise to ensure that the decision specific to this change is not lost. Because this change will not become part of the next release, it will go back to wish list status and be carried through the entire requirements process. The reason for this is to make certain that the development of this enhancement is scheduled for work and delivery within the context of all other existing work.

4. The change is rejected. This closes out the incident report. No work is scheduled now or for the future. There may be many reasons for this type of a response. Whatever the reason, the rejection action and the reason for rejection should be recorded within the change control process. A record of all closed changes is maintained to ensure accurate project history and to provide the rationale on why the change was rejected.

Whenever any software is released to the customer, the release should follow a defined release management process that includes the specific identification of all of the components that are included in the software release as well as the components that are assumed to be present (i.e., system software). This identification also should include the specific incident/problem reports that were corrected by the release and any work-arounds that were developed for the known problems that exist in the software.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment