Change Cases: An Agile Introduction

Change cases are used to describe new potential requirements for a system or modifications to existing requirements. Change cases are modeled in a simple manner. You describe the potential change to your existing requirements, indicate the likeliness of that change occurring, and indicate the potential impact of that change. Figure 1 presents two change cases, one potential change that is motivated by technical innovation-in this case the use of the Internet-and a second by a change in your business environment. Notice how both change cases are short and to the point, making them easy-to-understand. The name of a change case should describe the potential change itself.

Figure 1. Change cases.

Change case: Registration will occur completely via the Internet.

Likelihood: Medium likelihood within two to three years, very likely within ten years.

Impact: Unknown. Although registration will be available online starting in September, we currently expect less than one quarter of registrations to be made via the Internet this year. Response time will be an issue during the peak use periods, which are the two weeks prior to the beginning of classes each term, as well as the first week of classes.

————————————————————————————————————

Change case: The university will open a new campus.

Likelihood: Certain. It has been announced that a new campus will be opened in two years across town.

Impact: Large. Students will be able to register in classes at either campus. Some instructors will teach at both campuses. Some departments, such as Computer Science and Philosophy, are slated to move their entire programs to the new campus. The likelihood is great that most students will want to schedule courses at only one of the two campuses, so we will need to make this easy to support.

Change cases can be identified throughout the course of your overall development efforts, although I have a tendency to create them when I’m focusing on architectural modeling. Change cases are often the result of brainstorming with your stakeholders. Good questions to consider include:

How can the business change?
What is the long-term vision for our organization?
What technology can change?
What legislation can change?
What is your competition doing?
What systems will we need to interact with?
Who else might use the system and how?

My experience is that you can use change cases in a very agile manner. First, they enable you to consider long term issues and potential changes that your system may need to support. This puts you in a position to make better architectural decisions, such as choosing one platform over another, and thus increase the chance that you’re taking the best approach. This in turn reduces your desire to overbuild your system because you’re not as worried about the architectural choices you’ve made. Second, change cases provide an easy way for you to justify architectural decisions that you’ve made because you can show that you’ve considered a wide range of issues. This can help to reduce the politics that your team has to endure, allowing you to spend more time actually building software instead of attending meetings. Third, if you identify a very high-likelihood change case you can simply write it up as a normal requirement(s) with your stakeholders. They can prioritize the requirement(s) as usual and your team can then implement it as appropriate. Your architecture should be based on real requirements, otherwise you risk goldplating your system with “really cool” features that your stakeholders don’t actually need. Fourth, they’re simple.

Source

This artifact description is excerpted from Chapter 10 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese