Data Architect

Exploring the business through stories

Scenario-Based Analysis

Terry Moriarty

In the unified modeling language (UML), an object-oriented (OO) modeling approach that is rapidly becoming the industry standard, a scenario is defined as "a single path through a use case, one that shows a particular combination of conditions within that use case."1 The intent of a scenario is to illustrate, by example, the intended behavior of the system. While in OO the focus is on information systems, scenarios can be equally effective in exposing and validating the business rules within a business system.
      Scenarios seem to have grown in importance within the OO community. Scenarios are subservient to use cases in Ivar Jacobson's book Object-Oriented Software Engineering (Addison-Wesley, 1993). Although alternate paths can be described within a use case, there almost appears to be a one-to-one relationship between a use case and its scenario. Other OO analysis approaches afford more importance to the scenario. For example, IBM has espoused scenarios to the point that its OO approach is said to be "scenario-driven."2
      A scenario is a story used to illustrate specific nuances of the business concept being analyzed. By treating the enterprise as a state machine, a scenario depicts specific states of interest to the business, one or more events that can make an impact on those states, and the business rules that govern how the business transforms from one state to another.
      A scenario includes the following components:

• A situation describing the business problem being analyzed
• The initial state of the business objects involved
• The business rules invoked by the events being analyzed
• The business behavior
• The new business state representing the impact of the behavior on the business objects.

      The following example of a scenario (presented in Figures 1 through 5) illustrates these components. A bank wants to offer student credit cards to the college-bound children of its preferred customer households. In this case, the bank doesn't know that the Wagner household includes Amber. Therefore, the bank decides that its bankers should regularly peruse external sources, such as the local newspaper, in search of any information that can allow them to enhance their customer relationships. In this situation, an event triggers an action: The banker for the Wagner household finds the article about Amber Wagner being college-bound, which triggers these follow-up actions (see Figure 1):

Mary Wagner's daughter Amber turns 18 and graduates from high school. Newspaper Article on "Best Students" says Amber has been accepted to UCLA. Mary Wagner is a Perferred Customer.

FIGURE 1. The situation.

      Because no record for Amber exists, the banker realizes that the bank's knowledge base is incomplete (see Figure 2). To correct the situation, the banker adds and links Amber to the Wagner Household. In addition, the banker notes that Amber has been accepted to UCLA. This action invokes the related business rules (see Figure 3) which causes the desired behavior: Amber is sent a congratulation card and an offer to apply for a Student Credit Card (see Figure 4). The scenario completes with the representation of the new state of the Wagner Household (see Figure 5); Amber is now a member of the household, which has been included in the Student Credit Card campaign.

      The power of a scenario is found in its use of business objects instead of business object classes. The above story describes Mary and Amber Wagner, their household relationship, and their accounts. It also describes how the business should behave with respect to a specific event in the context of a specific campaign (the Student Credit Card offering). The business problem takes on a greater sense of reality when "real" people and business situations provide the context for the analysis. While flushing out the details of a scenario, the subject matter expert (SME) exposes details that represent essential requirements in how the business operates. Using traditional requirements-gathering approaches, the analysts may miss these types of requirements because they are so obvious that the SMEs neglect to mention them. The scenario also provides a mechanism for exploring why a specific set of business rules exist and why management wants the organization to behave in a specific manner.
      A scenario can be a powerful communication vehicle between the SME and the business rule analyst. The SME can use the scenario to clarify and describe nuances of a specific set of business rules or business object states to a business rule analyst. Similarly, the scenario helps business rule analysts communicate their understanding of business problems back to the SMEs; if a discrepancy exists, the scenario can be enriched or altered until both parties agree that it clearly illustrates the business problem under analysis.
      You can use scenarios to analyze the business from several different perspectives, such as:

• Business event simulation
• Life cycle analysis
• Reality-knowledge assessment.

      In the remainder of this column, I'll explore the first two perspectives. I'll discuss the remaining perspective in my next column.

BUSINESS EVENT SIMULATION SCENARIO

You can use the scenario to simulate business behavior in response to a specific business event. This is the type of scenario that has been incorporated into OO approaches. The first step is to identify the business events that the information system must support as use cases. The desired behavior is then specified in terms of the activities to be performed, including the sequencing of those activities. At this point, you develop several scenarios to illustrate the various paths that can be taken through the use case.
      A Swimlane diagram, used to represent the intended behavior of complex business processes, shows how the responsibilities for each activity within the business process have been allocated to the various stakeholders.3 A stakeholder can be a person, an organization, or an application. In our example scenario, Amber decides to apply for the student credit card by telephone. She assumes the role of the "Caller" in the Loan Application Swimlane (see Figure 6) and interacts with the customer care agent. Using the relationship management and loan application systems, the customer care agent interviews Amber to obtain the pertinent personal information to determine if Amber qualifies for the loan. The loan application system interacts directly with the credit bureau to obtain the Wagner household credit report. This information is incorporated into the loan scoring routine that advises the customer care agent on Amber's credit worthiness. The Swimlane would continue until the business process is completed.

      The Swimlane for the "Make a Loan" business process can be very extensive, depicting many more stakeholders and activities. One of the primary benefits of a Swimlane analysis is that it forces the SMEs to use a deeper level of detail in which they must explicitly state the expected behavior; you can use it to expose and discuss the business rules driving the process. Every time control passes from one stakeholder to the next, you need to ask why this transfer of responsibility is required. Business rules lurk behind every decision point, and each decision needs to be analyzed to understand its business significance and the rationale behind the various actions it controls. The Swimlane approach can be valuable in exposing business rules that can be modified or eliminated because they are no longer essential to the reengineered business process. In addition, new business rules may be introduced to ensure that the desired behavior occurs.
      Swimlane diagrams have been incorporated into a number of methodologies, diagramming approaches, and modeling tools, such as UML and Oracle's Designer/
      2000. In addition, there are diagrams that are similar in nature to Swimlanes called Line of Visibility charts by IBM4 and Cross-Functional Flow Charts in Visio Professional 5.0.

LIFE CYCLE ANALYSIS

The business events that an organization supports are often dictated by the life cycle of the things it manages; the business assets, such as products and capital assets, and the business relationships with its customers, employees, and vendors evolve through their own specific set of events during their life. While each life cycle is specific to the business asset or relationship being managed, the same types of events occur: planning, acquisition, use, management, and retirement.
      Planning is the process of identifying what assets or relationships are of interest to the business, describing the characteristics of each and specifying the business environment that will be established to perform the other processes required to support the asset or relationship (acquisition, use, ongoing management, and retire). Acquisition is the process of bringing a new asset into the organization or initiating a new business relationship. Use, which applies primarily to a specific business asset, is the process of applying the asset to specific business situations. For example, an employee is "used" when she is assigned to a specific job within the organization. Similarly, money is "used" as the organization pays for the services it receives or purchases other assets. Management involves the ongoing monitoring of the business asset or relationship to ensure the effectiveness of the asset and viability of the relationship. Finally, retirement is the process of removing an asset from the organization or terminating a business relationship.
      Scenarios can be used to support life cycle analysis by depicting a specific asset or relationship as it evolves. Scenarios can be extremely effective when used to analyze how the organization wishes to manage and expand the customer relationship. To manage a customer relationship effectively, the business must be able to recognize if a milestone has occurred in the customer's life cycle that can trigger the need for support from your organization. The milestones for a retail bank's customers include getting a new job, getting married, buying a house, starting a business, having children, taking a vacation, having a child start college, and retiring; each event can trigger the need for additional financial services. The customer relationship management scenario examines each event that can occur in a customer's life to identify how the organization should respond. For example, Amber Wagner's acceptance to UCLA represents an event of interest to the Wagners' bank. Sending a congratulation card is an attempt to enhance the relationship with the Wagner household by re-enforcing its relationship with its bank. But the real opportunity to grow the relationship comes with offering the student credit card to Amber.
      The life cycle scenario provides a mechanism for determining which products best meet the needs of the customer at any specific stage of the life cycle. This scenario can also be used to examine how the organization can anticipate that a milestone event is about to occur. For example, account officers may allocate time to research their customers' activities by reading the local newspaper or conducting routine searches on the Internet. Likewise, the customer's interactions with the business may be monitored to identify interesting behavior, such as late loan payments or larger payments than required to service the loan. The former situation may indicate a customer who may be having problems servicing his or her debt while the latter may indicate that the customer is trying to pay off his or her loan before the maturity date; both conditions can result in the loss of interest revenue to the bank.
      Scenarios can also be valuable in assessing how close the enterprise's knowledge base approximates reality by conducting a "Reality Knowledge" assessment. This perspective will be the topic of my next column, which will also provide some tips for developing and managing scenarios.

I want to thank Janey Frazier for introducing me to Swimlanes and the picture approach to scenarios. Few people have affected how I think about business rule analysis as she has. The scenarios shown in this article are based on real business scenarios originally developed by Frazier. Swimlanes are trademarks of Frazier Technologies Inc.

References

      1. Fowler, M. and K. Scott. UML Distilled. Addison-Wesley, 1997.
      2. IBM Object-Oriented Technology Center. Developing Object-Oriented Software: An Experience-Based Approach. Prentice Hall, 1997.
      3. Frazier, J. and G. McKenzie. The Swimlane Handbook. Frazier Technologies Inc. and McKenzie and Associates, 1998.
      4. Tkach, D., W. Fang, and A. So. Visual Modeling Technique: Object Technology Using Visual Programming. Addison-Wesley, 1996.

Terry Moriarty is president of Inastrol, a San Francisco-based information management consultancy, and she specializes in customer relationship information and metadata management. You can reach her at terry_moriarty@compuserve.com.