In-Depth

Change Case Analysis

• By Oscar Díaz, Juan José Rodriguez
• July 13, 2001

In today's competitive world, companies should adapt to changing conditions, and rapid evolution is a key success factor. The software systems that help these companies fulfill their objectives should evolve accordingly. Even if a system correctly matches the initial requirements, change is inexorable. This has led to an increasing awareness of the importance of considering change scenarios early in the analysis process so that potential changes can be identified early, leading to more robust software and lower maintenance costs. A systematic approach to this issue should provide means to identify potential changes and determine the impact of these changes. This article promotes a stepwise use case construction to be used as a baseline for change identification. Some insights on how to ascertain potential changes and examples to illustrate how to produce change-resilience designs are provided.

Business processes and their environments are currently suffering constant re-adaptation to a volatile worldwide economy. It is a frustrating experience to see how often the rigidity of the information system slows and restricts the evolution of the business that the information system is supposedly serving. This need for adaptability at the business level has changed the focus in many businesses from efficiency to opportunity, from reducing costs to generating revenue.¹

Object-oriented approaches target these issues. Indeed, encapsulation, subclassing, late-binding and other hallmarks of object-orientation, promise to deliver reusable and extensible software. However, using OO techniques does not necessarily lead to adaptable software. As stated by Faya and Cline, "adaptability must be explicitly engineered into the software....Furthermore, adaptability is not a generic quality of the software system as a whole: Software systems are adaptable in specific, designated ways, if at all."¹ Software is adaptable to some changes, but could be rigid for others. The key point is to foresee future business changes, and engineer the current software to smoothly evolve to cope with those changes.

Anticipating future changes is not an easy task. Cockburn suggests the use of the CRC technique to encourage users to invent impromptu scenarios rapidly to uncover likely but unstated future changes.² However, the root of the change should be sought in the business itself. Evolution of the market (new competitors or new clients) can impose more stringent conditions on the business processes; new and normative legislation can shape how business is conducted (previous operations may now be forbidden, or further conditions need to be accounted for); troubles with the current procedure or envisaged opportunities can also trigger changes in the business processes. Kavlaki and Locopoulos define business change management as "the process of identifying the business goals for change and analyzing the impact that these goals have to business processes."³ Changes are first referred to business goals, then percolate to the other artifacts.

A systematic approach to this issue should provide means to identify potential changes and determine the impact of the change. The former point is intimately related with the requirement analysis process. The final output of this stage is the set of requirements that conform the system specification. However, change should be sought in the business itself, hence we are better placed to detect future change if we are aware of the decisions, arguments, and discussions that finally end up as the system specification. Although business modeling is out of the scope of this article, we focus on use cases as a starting point.

USE CASE ELICITATION

Use cases have largely been used for requirement gathering and elicitation. Each use case abstracts different ways of interacting with the system to achieve a similar aim. It shows the response of the system to external stimuli, but does not show how the system actually achieves the goal. There are no internal objects visible, just the system itself and the actors originating the stimuli.⁴ It is a user-level, black-box view of the system. The popularity of this technique stems from grounding requirement gathering in concrete examples, whose intuitiveness facilitates user involvement. Indeed, recent reviews⁵ show that use cases help to unravel complex problem domains by talking about concrete examples and enforcing a usage- oriented decomposition of the requirement analysis problem from the very beginning.

Despite the large popularity and extensive use of this approach, evidence has been reported that users found it difficult to obtain the right use cases. Overly abstract use cases can be too vague to be useful, whereas too detailed use cases can be meaningless during analysis. These distinct levels at which use cases can be described is a constant source of confusion for practitioners. Indeed, Korson pleads for a hierarchical organization of use cases,⁶ whereas Weidenhaupt et al. state that the identification of "the right level of granularity and abstraction during scenario development and usage" is a main problem faced by practitioners.⁵ Moreover, different users with distinct views and interests in the use case outcomes get involved. After all, use cases are means of communication to ground thinking in concrete examples. But experience shows that unless some guidance is provided, a "Babe l" problem can easily arise due to the different backgrounds of the stakeholders. Requirement gathering is not a one-shot activity, because detailed requirements are refined and added as system development proceeds. Likewise, use cases are best developed iteratively and incrementally so that their inherent complexity can be better managed. But a comprehensive process for use case construction is still missing. Cockburn suggests the notion of goals as a guideline principle to decide "what to include, what to exclude, when to start, and when to stop" during the description of use cases.²"

Jacobson's definition of a use case as "a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system,"⁴ also suggests this notion of "measurable value" as the common purpose that keeps together the "sequence of transactions." Cockburn emphasizes the main role played by the goal when defining a use case as "a collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor (i.e., the initiator of the use case) has toward the system's declared responsibility, showing how the primary actor's goal might be delivered or might fail."² This notion of failure is central to Cockburn's approach. Uncovering the use case is guided by questioning how a main course of action can fail. This leads to the "striped trousers" image: One of the trouser legs stands for those courses that achieve the goal (either straightforwardly or after some recovery process), and the other leg represents the failure in delivering the goal.

Here we investigate a decision-making approach to use case elicitation. Rather than beginning with a successful course of action, and then, questioning how it can go wrong, this approach starts by identifying a set of meaningful alternatives, then questions when this can happen. By focusing on the when rather than the how our intention is to come up with more declarative and less functional use case descriptions. And, by classifying and arranging decisions among distinct layers, we can focus on main decisions first, and postpone secondary options for later analysis. Therefore, decisions during use case construction are arranged along four levels (see Fig. 1).

LAYER 1

In a goal-driven approach, the analyst begins by identifying the general goals of the system. These goals provide measurable value to the business, that is, to the customers of the business, since it is the satisfaction of customer needs that fuels the business activity. As an example, consider a library. Possible goals include handle book purchase and improve member usage of the library. These goals can be further decomposed into lower level goals. For instance, handle book purchase involves applying for funding and handling book purchase request, where the former provides the money to handle the latter. At each refinement, any goal level describes what needs to be done to achieve the goals at the higher level. This stepwise process stops when objectives can be assigned to concrete actors who cooperate to obtain a higher-level, business-oriented goal. These actor-based goals constitute the starting point of use-case description. The actor that initiates the use case to obtain the measurable value is known as the primary actor.

To correctly identify actor-based goals without going too deep into the refinement process, we can follow Cockburn's advice and question: Does the actor's performance depend on how many of these he does today? Cockburn illustrates the point with the log on and register a new customer examples. Whereas succeeding in logging on ten times in a row is not an indication of responsibility fulfillment, registering a new customer can be one of the user duties. One rule of thumb proposed by Korson is that the top-level requirements of the system should be expressed in no more than 12 use cases.⁶

The goal-refinement hierarchy provides the frame to understand the rationale for each use case, i.e., why this use case is required. Notice that business goals are commonly fulfilled by a set of use cases, each use case contributing to a particular aspect of the objective. In this sense, business goals not only justify but also structure the use case set. In this sense, use cases can be seen as a byproduct of business process modeling, and the deliberations of this first layer should be within a large scope. Goal-driven approaches to business process modeling have been described at CAiSE³ and at the 5th European-Japanese Seminar on Information Modelling and Knowledge Bases.⁷

For each goal, the environment where the goal has to be fulfilled has a main influence in the nonfunctional requirements, such as interface usability, performance aims, or security requirements. Use cases serve as the grouping criterion around which requirements are collected. Here, we just record the goal prerequisite, that is, the required initial state for the actors or the environment to pursue the goal. As the environment guarantees their satisfaction, they are not the concern of the system⁸; they are purely indicative. However, they describe the context where the system will function, and help to cope with requirement evolution. For instance, book purchase request has as a precondition that the applicant has to be up to date with the library fee. This means that the environment will guarantee that no applicants with an overdue fee will request a book purchase from the system (e.g., a card control system will be installed that prevents these applicants from entering the library). If this control system is later removed once the purchase system is functioning, the analyst should be aware of this fact, and describe this control as part of the purchase system.

LAYER 2

Addressing a goal implies considering the set of alternatives or possible outcomes. The context in which each alternative is taken is described in business terms (i.e., interface independent) based on a set of criteria. In this way, focusing on book purchase request, the analyst is faced with the following alternatives: (1) handling the request, (2) rejecting the request, and (3) delaying the purchase till the end of the year based on available funding.

Next, we should decide the criteria that provide the basis for opting among the alternatives. In this case, three criteria are considered: the book's necessity, applicant's status, and funding availability.

LAYER 3

The previous vague criteria are now realized as more tangible aspects. For instance, book's necessity is now refined by considering two aspects: the shortage of this book for teaching purposes, and the need of this book for research.

Next, the analyst has to decide whether the tangible aspects are going to be evaluated by either the system or any of the actors. At this point, the boundaries of the system begin to be outlined. Notice that assessing the purpose of the system involves deciding what is inside and outside the system's boundaries. Use cases stress this distinction between the environment, reflected through the actors, and the system, where stimuli realize the interaction. By moving the responsibility for evaluating tangible aspects from the environment to the system realm, we are increasing the functionality of the system.

In our example, book's necessity refers to the shortage of this book for teaching and the need of this book for research. The former is assigned to the system, whereas the latter is required from the applicant actor, i.e., it will be inquired by the system at execution time. If the answer is not satisfactory, possible recovery actions can be suggested to overcome this situation and return to the alternative. For instance, if the applicant ignores the answer, a recovery action could be to ask the applicant's supervisor. Table 1 summarizes this discussion.

This process is undertaken for each of the criteria. As a further example, the funding availability criterion has, as a single tangible aspect, the budget available. This information is required from the librarian actor. If funding is not available, a recovery action could be to ask the accountant to provide extra money from next year's budget. Table 1 summarizes this process.

LAYER 4

Tangible aspects can be either outside or within the realm of the system. The latter requires the system to keep track of the facts involved in the so-called ground conditions, which conform the tangible aspect, that is, the raw data to be monitored during the operation phase to assess the validity of the tangible aspect. This data can either be requested by the system at runtime, or inferred by the system from its internal state. For the system to keep an accurate state, the user has to be informed of changes in the domain that affect this state. This in turn serves to ascertain secondary use cases to achieve these informative goals.

In the library example, the evaluation of shortage of this book for teaching is a system duty. Hence, the tangible aspect is further elaborated based on (1) whether this book appears in the bibliography of any of the subjects taught by the University, and (2) the number of copies of this book already available at the library (see Table 2). This implies that the system has access to this data (i.e., it must be part of the object model kept by the system) which leads to secondary use cases that are required to collect this raw data.

Overcoming the drawbacks of use cases

Despite its proven usefulness, the use case approach for requirement elicitation* is not without pitfalls. Bertrand Meyer points out the following risks⁹: