jsp
by Pan-Wei Ng
Independent Consultant
For now, we will use our customer as the actor, but this will evolve into a
more generic role, such as applicant. In addition, we have left out the
actor representing the credit card payment gateway because the purpose
of this article is to explore scenarios based on how customers interact with
the system.
Let's first consider the Basic Flow for the Make Reservation use case
depicted in Table 1. Much of our discussion will focus on this use case.
The Basic Flow in Table 1 looks straightforward. And it is true that most
use-case Basic Flows of events are straightforward; the complexities lie in
how to handle different scenarios through alternate flows. What is the
difference between a scenario and an alternate flow for a use case? A use-
case scenario represents one complete path through a use case; a use-
case alternate flow is one segment of that path. If you compare two
distinct scenarios, the difference between them is the alternate flow. A use-
case flow highlights the details of a particular scenario that distinguish it
from other scenarios. Scenarios consolidate use-case flows into a complete
path and thereby help us view alternate flows in a more complete and
meaningful context.
Don't be a "Terminator"
Before we go on, let's see how some practitioners treat alternate flows. In
our consulting engagements, we meet all sorts of people. There's a certain
group that we stereotype as "The Terminators" (our apologies, Gov).
For such people, their alternate flows for the Make Reservation use case
might look like those shown in Table 2.
Flow Description
A1 If in step 3 of the Basic Flow there are any missing fields, the
use case terminates.
A2 If in step 3 of the Basic Flow the start and end dates are
invalid, the use case terminates.
A3 If in step 4 of the Basic Flow there are no available rooms, the
use case terminates.
A4 If in step 8 of the Basic Flow the credit card is not valid, the
use case terminates.
A5 If in step 9 of the Basic Flow the credit card payment gateway
is not available, the use case terminates.
A6 If in step 9 of the Basic Flow the reservation database is not
available, the use case terminates.
You have probably guessed why I call these folks The Terminators. All
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology
their alternate flows terminate the use case without any attempt to rectify
and manage the situation, and somehow force resumption of the Basic
Flow.
Are the alternate flows in Table 2 wrong? Not technically. But if a system
were to be built around them, it would be rather boring and unusable -- an
unfriendly system that would abort on the first failure. And one that would
be far from our goal of idiot-proof.
The power of the use-case technique lies in getting users and analysts
alike to explore how to handle alternate situations. Terminator flows don't
explore anything at all. When a developer programs the Basic Flow, the
terminator flows are there by default, as manifested by UNIX Core Dump,
Windows General Protection Fault (GPF), Java Stack Trace, System
Reboot, NT blue screen, and so on.
If you are a movie buff like me, you will remember the line, "I'll be back!"1
Likewise, we should think about how our use case can resume and
continue the flow. A useful system always seeks to either resolve or steer
around problems, back toward a successful transaction. To do this, we as
analysts must understand our users' and other stakeholders' mentalities,
as well as the diversity in the business domain, and the technical
challenges to be resolved.
Let's begin with the ideal customer, one who aligns with your business
practice or basic use-case flow, and will go to great lengths to keep the
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology
The second personality type is the careless customer, who may forget to
enter mandatory fields or submit the wrong information. Sometimes the
system can detect the errors -- an incorrect credit card number, for
example. However, sometimes it's almost impossible for the system to
validate the submitted information -- telephone numbers and addresses,
for example.
The alternate flow for correcting erroneous information that the customer
(or reservation clerk) entered earlier is depicted in Table 4.
There are several ways to do this. One is to have a table in the special
requirements section of the use-case specification that lists the fields to be
captured as rows. For each table column, we can indicate whether it's
mandatory and whether validation checks are required, and enter any
remarks about the field. This table can also be located in the glossary.
Another option is to put the information in the domain model or the user-
experience storyboard. In the domain model, information groups are
represented as classes and fields as attributes. We can define tag values
for these attributes to indicate whether they are optional or mandatory.
We can do the same on a user-experience storyboard, except that our
classes will be «screen» classes, as opposed to the «entity» classes in the
domain model.
Note that the alternate flows in Table 6 do not describe what happens if
the deposits required for different room types or booking dates are
different. Nor do they describe how to handle refunds for room
cancellations. But we could easily add more steps to the alternate flows to
cover these conditions.
Also note that in step 3, we say that the customer may amend
"appropriate fields." We could list these fields in the alternate flow
description, but that would create clutter. Instead, I would list these
amendable fields either in a table within the special requirements section
of the use-case specification or in a glossary, much as we listed
mandatory and optional fields earlier.
Note that there is another alternate flow for late cancellation that you can
either include here or treat as an alternate flow in the Cancel Reservation
flow of the Make Reservation use case. Or you could put it within an
alternate flow for a Cancel Reservation use case.
In real life, however, depending on the business you are in, you might not
want to rush into black listing a customer. Instead, you might want to
create another workflow to review such cases. The important point is that
some customers will be absentees, and you need ways to handle them.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology
The elder brother of the absent customer is very old and sickly. You may
wonder why he reserves a room in the first place, but we have no control
over that. If this customer can predict his future, he may cancel his
reservation before he dies. What happens if he doesn't? We'll need to ask
his good friend -- a stand-in customer -- what needs to be done. We will
discuss this in the next section.
Let's consider what happens if the customer dies before checking out of
the hotel. Table 9 shows the Basic (normal) Flow for the Check-Out use
case.
The use case begins when the customer comes to the Reception
Desk to check out of the hotel.
Let's consider what happens if some tragic event happens to the customer
(as depicted in Table 10).
To step 4 of this Tragic Event alternate flow, you might want to add a
manual override use case such as Maintain Room or Manage Room.
Hotels typically face few issues if someone dies in a room, but if your
project involves property, real estate, or stocks, a death will engender
legal issues that your system will need to handle.
Our Make Reservation use case must handle the scenario in which the
agent (or other stand-in actor) makes the reservation on behalf of the
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology
We will also have to generalize the actor into an applicant in the Basic
Flow, updating it as shown in Table 12.
Keep in mind that we have considered just one alternate flow in which an
agent can act on behalf of a customer. There is an "applicant" counterpart
for every flow we have discussed so far: for check-in and check-out,
amendments, cancellations, and even black listing. Moreover, an agent is
subject to the same unpredictable forces as other customers: illness,
disaster, bankruptcy, and so on.
Now we move to yet another group of customers -- and they can be very
choosy. Leading the pack is the sentimental customer who has many
preferences, such as a room facing the sea, or even the specific room she
had last year. To handle such customers, we can add another alternate
flow to the Make Reservation use case, as shown in Table 13.
Preference
The customer can specify her preferences during the reservation process
and also during check-in. We might add a similar alternate flow to the
Check-In use case, but this might be repetitive. At this point, it might be
useful to specify an "Inclusion" use case to handle the search for an
available room. Or, you might want an "Extension" use case with a
"Handle Customer Preference" alternate flow. In general, this use case
would extend other use cases whenever they must take customer
preferences into account: when the system searches for a room, or when
the customer modifies her profile either after some time after making a
room reservation or at check-in.
In short, there are multiple ways of incorporating alternate flows into use
cases. I prefer extension uses cases (or at least an alternate flow) because
they do not impede the regular flow of events. To include an alternate flow
in a use case, a step in that use case's Basic Flow must explicitly make the
inclusion, and that can be confusing.
The showy customer likes people to think he is rich. He has lots of credit
cards, debit cards, cash, travelers checks, and so on. Table 14 shows how
to handle alternate payment methods.
Showy customers are not the only ones who use different payment
methods. Sometimes customers are constrained to certain methods. For
example, a corporate customer might be limited to using a company
check; or her company might have a special arrangement with the hotel to
send a consolidated bill for a number of stays or customers. Such
restrictions make payment a challenging aspect of the system. We'll
discuss these concerns again when we explore the personalities of
business owners in Part II of this series.
This customer always looks for discounts. Maybe he won some free tickets
or received some discount vouchers -- and these freebies are probably
why he is taking a holiday in the first place. Table 15 depicts an alternate
flow for the Check-Out use case to handle discount vouchers or loyalty
credits.
The geeky customer has many gadgets and is always on the move. He
may want to make reservations with his mobile PDA (Personal Digital
Assistant) or mobile phone, or from an Internet kiosk. And the system
needs to handle these different access channels, some of which may
impose limitations on the number of fields you can display (this applies to
PDAs, for example) so we may want to minimize the information required
to complete the transaction.
Let's suppose the geeky customer wants to check in using SMS (Short
Message Service) through his mobile phone. One possible flow is depicted
in Table 16.
Alternative channels can also be applied in other use cases. Many hotels
now have at least one electronic checkout process that allows you to avoid
waiting in line at the desk. Thus, there will be variants to the Check-Out
use cases as well.
The ancient customer is the exact opposite of the geeky customer. She
will only use the traditional way to reserve a room, check in, and check
out -- no Internet, only the phone or a personal appearance -- and you
can forget about Interactive Voice Response (IVR) systems. When she
calls in to make the reservation, the receptionist becomes an agent, and
we can apply the flow we specified earlier for the agent, or stand-in
customer.
Note that the system has the request details (i.e., room type, and start
and end dates for the stay) before the alternate flow above executes.
Hence, at step 4 of this alternate flow, the system only needs to confirm
the details.
Also note that the use case pauses at step 7 of this alternate flow and
resumes when a room becomes available. This occurs when someone
cancels a reservation or checks out early, or when the hotel adds more
rooms, and so on.
A customer with VIP (Very Important Person) status really gets his way.
He may have a special relationship with a hotel executive, or he may be a
frequent visitor who spends lots of money at the hotel. The most
important thing is to ensure that he always gets the room he wants. One
possibility is to put him at the top of the list in step 6 of the Waiting List
alternate flow (see Table 17), but this VIP customer may be so important
that management lets him "bump" other customers and take their rooms.
Maybe you do not have such an extremely important customer that you
need to force another customer to cancel a reservation. However, there
may be other situations in which you may need to cancel existing
reservations: for example, unscheduled room maintenance. It's only fair,
and good business, to return customer deposits on cancelled rooms. There
is also the possibility of finding the existing customer another room (e.g.,
priority customer wants a specific room, which is booked, but there are
other rooms available). In addition, the use-case model needs another
actor to represent the hotel management.
The examples in this series highlight the need for use-case patterns to
help us write better use cases. And a prerequisite for effective patterns is
more precise semantics in our use-case specifications, a point we also
emphasize in IBM Rational University's "Mastering Requirements
Management with Use Cases" course.
Acknowledgments
I would especially like to thank Ian Spence for his detailed and extremely
helpful reviews, and also Maria Ericsson for her comments. Thanks as
usual to Catherine Southwood for her great job with the edits.
Notes
1 Quote from Arnold Schwarzenegger in the movie The Terminator.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology