10.2 Use Cases Beyond Software

Use cases have fulfilled the role of software requirements well. Perhaps because of that fact, use cases have moved into other areas that have had problems in notation. Two applications of use cases we'll examine here are service use cases and business use cases.

10.2.1 Service Use Cases

A great example of use cases being applied to a pressing business problem is the emergence of service use cases . Lance Tracy, a pioneer in this field based in California, has done work for several companies to help them define the services they offer to their clients with use cases as his central tool.

As a company is defining (or redefining itself), a series of questions must be addressed:

1. What is the vision of this company?

2. What is its mission?

3. How do we define the business we are in?

4. What are the services we provide to our customers?

In response to the last question, the team creates use cases for each service they intend to offer to their customers. The customer is the actor, and substantial effort goes into defining that actor (the target market in marketing terms). Then they examine two critical components of Service Use Cases: the goals of each actor (what a customer wishes to accomplish when he or she deals with the company) and the service level agreement (SLA) that must be met (basic agreements the company can provide to a customer regarding the performance of services). An SLA is essentially a set of nonfunctional requirements for a set of service offerings. If an internal IT group agrees to offer a set of services to the company's business groups, it is likely to set up an SLA to govern what it means to offer "acceptable service." This includes defining how fast the services will be completed, the level of customer service, and so on. These agreements are very similar to how nonfunctionals describe how fast a computer system will offer its services to its users.

Once this framework of goals and standards is established, they begin to define service use cases, the interactions between the customer actor and the company's "system" (system of processes, not necessarily software) that provides customers with what they want, how they want it, and when they want it. The team then elaborates these service use cases into internal business processes that will satisfy those criteria set out in the service use cases.

The use of service use cases also helps training efforts for service offerings in a company. For instance, instructional designers do something called "front end analysis," where they ask similar questions to what a person creating service use cases would ask:

• What is the participant's goal?

• What sequence of steps do we take to accomplish that goal?

• How will we know when we are done?

• How will the participant know that he or she has completed the task correctly?

Lance and his teams have also used the service use case process to uncover hidden costs in existing service offerings and to identify labor issues that could cause problems later in the company's life.

We like how use cases provide a tremendous amount of focus for the often fuzzy process of service definition. Since such a big percentage of Western economies are made up of service companies, and even product companies are turning themselves into service companies, the timeliness of Lance's approach is good. Service use cases are in their infancy at the moment, but we're certain they'll catch on and replace many of the older methodologies of reorganizing companies and their service offerings once people see how use cases bring such focus to the task.

10.2.2 Business Use Cases

Related to service use cases but different are business use cases . Business use cases describe business processes, similar to how process diagrams or flowcharts have been used. But there is an important difference. Business use cases define business processes from the outside in, beginning with the external business actors : customers, suppliers, partners, nonprofit partners , shareholders, and so on. The business process team examines the goals of these "business actors" and then identifies the ways these actors want to interact with the business in order to achieve those goals. Those interactions become use cases, but the "business" is treated like a black box, where we don't care how the business provides the right reactions to the actors, only that it does (the same way we treated the software in software use cases). Once those use cases are written, the team can begin to map the internal processes to satisfy those external actors' goals.

First, we should explain that when we say "the business," this could mean the entire organization (corporation, government department, and so on) or it could mean just one division of an organization (personnel, purchasing, shop floor, and so on). The place where the boundary is drawn is dictated by the scope of the project. If the project team has been tasked with reorganizing the entire company, then "the business," and therefore the black box, is drawn around the entire company. But if it is meant to reorganize only one department, say Purchasing, then the box is around Purchasing. This means that anyone outside Purchasing who needs to interact with Purchasing to fulfill a goal ( vendors , other departments, company executives, and so on) is a business actor. The team will examine the goals of each actor and then identify business use cases that fulfill those goals, and finally create internal processes (perhaps using UML sequence diagrams) to show what has to happen internally to satisfy the business actors' goals.

There is an important benefit that use cases provide in this process over other methods . Since use cases are focused on the goals of the external parties, they can help provide some abstraction away from the "as is" view of the internal business processes. By treating the department (or company) as a black box initially, it is easier to try to imagine "in a perfect world" what the absolute best results are that we could provide to the actors. Then our job is to create internal processes that satisfy those goals. This is a completely different perspective than simply examining internal processes step-by-step and trying to find incremental improvements by looking for places where we can take out steps or do things faster. It gives the organization a much more "stakeholder-driven" style, whether the stakeholders are the customers, partners, or company executives. The difference can be dramatic.

10.2.2.1 Challenges of Business Processes

As software gets more involved in business processes, the auditing function for a business is likely to ask for a completely auditable process no matter whether the process is carried out by a human being or a piece of software. Since a business auditor is not necessarily computer literate, the proper auditability of the process with the involved software is a key business concern.

If we also consider the fact that the business process in question may have to change, a reasonable requirement for the software involved will be its flexibility, or configurability. That is, it should be able to be reconfigured according to the changing structure or at least the changing parameters of the process. Note that this is business process configuration and it is not just another nonfunctional requirement for the software. In order to identify and develop the needed solutions in a changing business environment, another form of requirements documentation must be introduced to capture the necessary business requirements with the bigger picture, that is, complete and end-to-end business processes, which present the solutions to business needs.

Once the needed information of the business processes is included into the use- case-based requirements, this inclusion will provide necessary specifications on both why and how the software should be installed and maintained in the context of the business solution. The understanding of the usage of the software in the "real world" context will enable the IT professionals involved (business analysts, architects , developers, testers, and so on) to develop better software.

The IT professionals who are directly involved in software development are not the only beneficiaries of the business use cases. A business use case that relates the IT functions to process context is also an educational tool that demonstrates not only the business value of the IT package, but also how the package should be operated to support the values for the end users.

10.2.2.2 Features of Business Use Cases

Table 10.1 shows a sample business use case. Business use cases share these common attributes with system use cases:

• A business use case focuses on end-to-end business processes. It must provide concrete business reasons to get started and business consequences or values to end.

• A business use case focuses on interactions between all parties involved, no matter if it is a human being or a software system. Therefore, it requires identification of all business actors including the need for IT support.

• A business use case focuses on identifying the responsibilities of all business actors in the context of the business process from end to end. The functions of the IT system to be developed are a subset of the scope identified in the business use cases.

• A business use case focuses on identifying the business information contents in the context of the business process from end to end. The information processed by the software systems to be developed is a subset of the contents identified in the business use cases.

Table 10.1. Review Leasing Document Business Use Case

Basic Flow	The use case begins when the Portfolio Manager wants to review the lease document after being notified by the Investment Manager that the document has been completed.
Retrieve the Leasing Application.	The system retrieves and displays the leasing document.
Review the Leasing Application.	The Portfolio Manager reviews the system specification and legal terms of the leasing application.
Retrieve the Credit History of the Applicant .	The system retrieves and displays the credit history of the applicant.
Review the Credit History of the Applicant.	The Portfolio Manager reviews the credit history.
Application Acceptable.	The Portfolio Manager accepts the application and notifies the Investment Manager. The use case terminates.
Alternate Flows
The Legal Terms Unacceptable	If in step 2 of the Basic Flow the Portfolio Manager finds the legal terms unacceptable, the Portfolio Manager will notify the Investment Manager of the reasons for rejection . The use case terminates.
The Credit History Disqualified	If in step 4 of the Basic Flow, the Portfolio Manager finds that the credit history of the applicant disqualifies the applicant, the Portfolio Manager will notify the Investment Manager of the reasons for rejection. The use case terminates.
The System Specification Unacceptable	If in steps 2 or 4 of the Basic Flow the Portfolio Manager finds the system specification unacceptable, the Portfolio Manager will notify the Investment Manager of the reasons for rejection. The use case terminates.

Once we have captured the business information in the form of business use cases, we can easily start developing our system use cases as a result. Note that the requirement development process between business use cases and system use cases is not a waterfall approach. Iterations between business use cases and system use cases will be needed to facilitate the process of specifying the best possible business solution as well as the software systems that support the solution.