CHAPTER 9
Using Use Cases

In this chapter, you’ll learn how to easily transition a textual business requirement into a use case, if required.

What Is a Use Case?

A use case is a description of the interaction between actors relating to a specific objective. This definition may make a use case seem as if it’s the same thing as a process description for a business event. But use cases describe in more detail how the interaction is going to happen. The use case method is an alternative strategy for documenting business requirements. It allows organizations to reuse requirements—i.e., reuse the definitions of activities already defined for another process. As a method it often yields quality requirements, but users may find it inordinately technical.

Here’s how a use case can be applied to the simple banking event A customer makes a deposit. We begin by creating an event process model to capture all the necessary objects and document the process of receiving the deposit (Figure 9-1).

Data Flow Diagram

FIGURE 9-1: Data Flow Diagram for Receiving a Customer Deposit

Process Description
Bank receives customer deposit

For each deposit received from a CUSTOMER,

The process description outlines a fairly simple process. The description is written in business terms. It does not explain how the process is done or what error messages are displayed when, but it does describe what the business needs to achieve without detailing the design of the system.

What objects are required by this event? Customer, Account, and Deposit.

Customer

Data attributes:

• Customer number

• Customer name

Account

Data attributes:

• Account number

• Account type

• Account balance

Deposit

Data attributes:

• Date when deposit is made

• Deposit amount

• Method of deposit.

The event entity relationship diagram (EERD) shows the relationships (Figure 9-2):

FIGURE 9-2: EERD for Customer/Account/Deposit Relationships

These object relationships can be expressed in plain English:

• A Customer may have one or many Accounts.

• A Customer may make one, many, or no Deposits (he or she may have simply opened up an Account without making a Deposit. Note that the event A customer opens an account may be in scope of the target project, too.).

• An Account must belong to one and only one Customer.

• An Account may have one or many Deposits; an Account may never have a deposit.

• A Deposit must be made by one and only one Customer.

• A Deposit must be made into one and only one Account.

Table 9-1 shows a use case developed for the business event A customer makes a deposit. It is based on the process description and EERD.

TABLE 9-1: Use Case for a Customer Making a Deposit

Each step listed in the main (ideal) flow section identifies who does what. Each step is done by a different Actor. Step 1 is performed by the customer, step 2 by the teller, step 3 by the system, and so on.

Note that the precondition and the post-condition to a use case are based on business rules and that for every exception flow, there must be a postcondition failure.

As an appendix to the use case documentation, the expansion of the data dictionary defined in the BRD should include the characterization of each data attribute required by the use case.

Look at step 4 of the main (ideal) flow for the use case detail shown in Figure 9-3. We can ask ourselves many questions about the listed data attributes:

• How many characters make up an account number?

• Should there be a maximum number of characters displayed for the name of the account holder?

• Can there be a negative account balance? If so, how should it be displayed—perhaps in red?

• Should the type of account appear as a code? If so, what should the code be?

• How should active and inactive account statuses be displayed?

FIGURE 9-3: Detail from Use Case

We can then create a use case diagram based on this use case (Figure 9-4):

FIGURE 9-4: Use Case Diagram for “A Customer Makes a Deposit”

You can develop more than one use case for the same event if multiple media or methods can be used for the event. For example, if a customer can make a deposit through an automated teller machine, the Internet, or mail, you can create three additional use cases. The end result, recording the deposit and updating the customer’s account balance, may be the same, but the processes to get to that result may vary.

How Business Events
and Use Cases Relate to One Another

So far, we’ve used the business event as the basic beginning unit for requirements analysis. But when we decompose the requirements into a use case, we use the process as the basic unit on which use cases are based.

As shown in Figure 9-5, a business event requires one process. A process may be shared by more than one business event and may decompose into one or more use cases.

FIGURE 9-5: Relationship between Events and Use Cases

Figure 9-6 is a similar diagram illustrating the banking example above.

FIGURE 9-6: Relationship between Customer Making a Deposit and Use Cases

Requirements Elicitation in a Use Case Structure

Once you have documented the business requirements, how do you translate them into use cases, if required? Let’s say that an outside organization is going to construct the target system. We recommend that you convert the requirements into a set of use cases because use cases are more detailed than a full business requirements document.

Use cases are part of a comprehensive language called the Unified Modeling Language (UML), which offers a way to document your business requirements but does not suggest a process for getting the information required. How do the architects of the use case approach and the UML suggest you elicit requirements using use cases? The authors of The Universal Modeling Language User Guide, second edition, prescribe that “to model the requirements of a system:

• Establish the context of the system by identifying the actors that surround it.

• For each actor, consider the behavior that each expects or requires the system to provide.

• Name these common behaviors as use cases.

• Factor common behavior into new use cases that extend more main line flows.

• Model these use cases, actors, and their relationships in a use case diagram.

• Adorn these use cases with notes or constraints that assert nonfunctional requirements; you may have to attach some of these to the whole system.”¹

There are four implicit assumptions when the use case model is used to elicit business requirements. But it is very difficult, if not impossible, to fulfill all of these expectations.

1. An analyst will be able to first organize the tasks associated with the processes into mutually inclusive but individually unique use cases.

   For a large project—one involving, say, 1,000 use cases—this exercise could be overwhelming. More important, the analyst could never be certain that he or she had analyzed and documented all the pieces.

2. The analyst or the subject matter expert (SME) can describe the tasks performed.

   Discussing actor interaction does not necessarily make obvious the process flow required to get that interaction. It is not necessarily true that an analyst or SME can completely describe a process without assistance.

3. The analyst and the SMEs together have unlimited time to explore all the different scenarios in a given system.

   One of the most frequently heard comments from business users is that they do not have enough time to spend with analysts defining their requirements. They are juggling far too many projects at any given time.

4. SMEs understand how to construct use cases.

   SMEs are businesspeople who normally do not speak the use case language. They cannot realistically be expected to speak fluently in business and technical language.

Considering these obstacles, do you think use cases are a good means of gathering requirements? My answer is no! I don’t recommend this approach for a number of reasons:

• The analyst can easily lose control of the assignment if the target project is very complex. It is far easier to manage small pieces of information, such as one event, than it is to analyze many events at once.

• Use cases are very detailed, bordering on being a design document for an application. They explain some of the “how” associated with the project.

• Analysts must spend a lot of time with SMEs to detail use cases. SMEs usually cannot spend all of their time gathering business requirements with analysts. If you choose the use case method, maximize your time with SMEs by working with them to elicit textual requirements via business events, and then derive use cases from those without the SMEs. It’s easy for SMEs to explain how to respond to various business situations. They’re used to discussing this. But it will take a long time to explain use cases and all the associated details to an SME.

Though I don’t encourage the use of the use case method for gathering requirements, you can use it as long as you recognize that it may prolong your requirements discovery session. It might take you twice, three times, or even four times as long to analyze your requirements. You will probably be bogged down more by design considerations than by process and business drivers. However, you might prefer to use this approach if your project is relatively small, involving up to ten use cases; you are a skilled facilitator; and you and the users can afford to spend as much time together as possible.

Process Flow Charts

A process flow chart shows the sequence of activities that must be done to complete a process. Figure 9-7 is a process flow chart illustrating the banking use case detailed in Table 9-1.

The flow chart has a start point and an end point, symbolized in Figure 9-7 by an oval. A process is designated by a rectangle; the odd shape around “System displays account information” is for a display function; anything that requires a manual input is shown in the other quadrilateral shape. A decision point, which can lead to an alternative flow, is shown as a diamond. Data attributes are bulleted.

A use case and a process flow chart give us exactly the same information. Each tells us:

• The trigger for the process

• When activities will be performed

• Which activities can be automated

• What data is required for each task

• Logic—the sequence of activities.

Both a use case and a process flow chart must be supported by a document that identifies the objects, data attributes, and characteristics of each data attribute. Both may also need a GUI design document before any real development can happen. So what does the use case offer that the “primitive” flow chart does not? You can decide for yourself. Remember that you may have to analyze many process flows for the target project.

FIGURE 9-7: Process Flow Chart for “A Customer Makes a Deposit”

In Brief

A process modeling approach such as use case documentation and diagramming is not, in and of itself, a silver bullet for business analysts and subject matter experts, but using a modeling approach to extract textual requirements from business users guarantees that the model will have a consistent and rigorous format. This will eliminate a lot of the quality and accuracy issues often encountered when use cases are used to elaborate business requirements—i.e., elaborate on the information that has already been elicited from the subject matter experts.

Process flows can be shown in a number of ways: use case, use case diagram, process flow chart, or swim lane diagram. It does not matter which method you choose. What matters is that when gathering business requirements, you select an approach that will allow you to communicate with business users in their language rather than in technical jargon; that you optimize the time you spend with the subject matter experts; and that you can accurately evaluate the completeness of the requirements.

NOTE

1. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Universal Modeling Language User Guide, 2nd ed. (Boston: Addison-Wesley, 2005), 245.