Change Cases

Another aspect of design, which doesnt really directly impact class design significantly, involves change cases. Its a fact of life that things change. People change (and change jobs), business rules change, and government agencies change. Therefore, your program will also change.

Change cases are documented much like technical requirements, using a simple numbered text approach. What you want to do is identify portions of your system that may be eligible for change some time in the future, and document them.

These change cases should include a single-line description of the anticipated change, a possibility indicator of the chance the change will be needed, and what sort of impact the change will have on your system. By describing these changes now, management has the ability to try and manage them.

The project manager may decide that a specific section of a design is complete but then suddenly get wind of a new change. Based on the impact and likelihood of the change, the project manager may authorize the design to be modified accordingly , or they may simply defer the change until it is a certain requirement.

Heres an example of the documentation for change cases (note that CC in the numbering system refers to change case):

• CC1 : A telephone response system needs to be implemented.

• Impact : Moderate. The existing user interface classes that work with the console need to have telephony-compatible versions created. The business rules and actor classes have been separated from the user interface, so these classes need not be aware of the change.

• Likelihood : Likely. The Vice Dean wants this implemented, but the Dean does not. The Dean will be retiring next year, however.