Copyright Rational Software 2003 http://www.therationaledge.com/content/oct_03/m_hunting_ng.

jsp

Hunting for use-case scenarios

Part I: Analyzing customer psychology

by Pan-Wei Ng
Independent Consultant

Use cases, an increasingly popular

technique, are often the basis for
successful projects. One reason the
technique is so powerful is that use
cases force both user representatives
and analysts to explore system usage
scenarios -- and reach consensus on
how to handle them -- early in the
project lifecycle. This is crucial to
project success, as these same
scenarios also drive the analysis,
design, and test processes. However, hunting down every possible user or
system behavior is not simple; it requires lateral thinking and venturing
out of the box. Frequently, practitioners give up too easily and simply let
use cases terminate.

In this three-part series, I will discuss techniques for "hunting down"

scenarios and illustrate how to document them using alternate flow
descriptions. Each part will focus on different perspectives: the customer's
perspective (Part I), the stakeholder's perspective (Part II), and a problem-
focused perspective (Part III).

Example: A hotel management system

Let's make our discussion concrete by using a hotel management system
as an example problem for this series. The primary actor is a customer --
perhaps a traveler who needs a room for the night, a businessperson who
needs a room for an extended period while setting up a local office, or a
romantic man planning a second honeymoon for his wife of twenty years.
Whoever that customer is, he will need to make a reservation; then he will
stay in the hotel. This results in the three use cases depicted in Figure 1
for our hotel management system: Make Reservation, Check In Customer,
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

and Check Out Customer.

Figure 1: Use cases for hotel management system

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.

Make Reservation use case

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.

Table 1: Make Reservation use-case specification: Basic Flow

UC-1. Make Reservation use case: Basic Flow

The use case begins when a customer wants to reserve a room(s).

1. The customer enters a request to reserve a room.

2. The system shows the type of rooms available and their
prices.
3. The customer chooses a room type, and specifies start and
end dates for the stay.
4. The system checks availability for the room type.
5. If a room of that type is available, the system computes
deposit charges based on the room type and length of stay.
It then prompts the customer to confirm the reservation.
6. The customer confirms.
7. The system requests the customer's credit card payment
details.
8. The customer submits credit card payment details as well as
personal details: name, email address, and billing address.
9. The system sends the transaction to the credit card payment
gateway, and creates a new reservation with a unique
reservation number.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

10. The system sends a confirmation email to the customer.

11. The system displays the reservation details, including the
room type, start and end dates, and reservation number.
12. The use case terminates.

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.

Table 2: Terminator alternate flows

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.

Hunting for scenarios

As I have discovered through my field work, there are far too many
"Terminators" developing software. If you have friends who treat alternate
flows as we described in Table 2, then please recommend that they read
this article. A better approach than termination is to "hunt for" -- or
anticipate -- scenarios, based on customer behavior.

Analyzing customer tendencies

By definition, a use case must deliver some observable result of value to

some actor. One of the most important actors is the customer for a
system. If there are no customers, the business will cease to exist. If the
customers are not satisfied, or the business cannot retain customers, the
business will also collapse in the long run. As analysts, we must
understand our customers' psychology and behavioral tendencies. For this
we do not need a psychiatric degree; we just need to exercise some
common sense.

First, of course, it is important to understand the personality of users in

general. This includes everyone in an organization, from clerks to
executive managers. But in this article, we will focus on the customers for
our particular hotel management system.

The ideal customer

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

use case within the Basic Flow.

In truth, ideal customers, or actors, are almost extinct, but programmers

still like to mimic them. They always execute programs the way the
programmer would like them to, but not the way most people would do it.
That is why we have testers who are supposedly trained to think laterally
and try to crash the system. Every time the system crashes, the
developers understand that they must devise a way to handle the
situation. But why wait until then? Why not do that thinking early in the
project?

The careless customer

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.

So how do we handle the careless customer? We might seek alternate

verification sources, such as the police department, but that option is
probably unavailable. It would require that the system have an external
interface to the police IT infrastructure, which is probably illegal.
Alternative verification sources would also require external interfaces,
which in turn would require a development effort. So we must apply
common sense here: Is the information critical enough to make the effort
required for validation worthwhile?

Another option would be to validate the information when the customer is

present -- in this case when he checks into his room. With this approach,
although the source of the error is in the Make Reservation use case, the
error would be handled within another use case: the Check-In use case,
whose Basic Flow is described in Table 3.

Table 3: Check-In use-case specification: Basic Flow

UC-2. Check-In use case: Basic Flow

The use case begins when the receptionist wants to check in a
customer.

1. The receptionist enters one or more of the following:

customer's reservation number, name, passport number.
2. The system searches for an existing reservation, and then
displays the reservation and customer details.
3. The system searches for rooms available for the stay period
and displays details about these rooms.
4. The receptionist selects one of the rooms.
5. The system marks the room as booked.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

6. The use case terminates.

The alternate flow for correcting erroneous information that the customer
(or reservation clerk) entered earlier is depicted in Table 4.

Table 4: Check-In use case alternate flow: Correct Wrong

Information

UC-2-A-1. Correct Wrong Information

If during step 2 of the basic flow the receptionist finds that the
customer's retrieved information is incorrect, the receptionist re-
enters the correct information. The system stores the updated
values. The use case resumes.

The paranoid customer

A close sibling of the careless customer is the paranoid customer. This is a

very careful person who will scrutinize the system for any possible security
loophole. Such customers will turn off cookies and even disable JavaScript
on their browsers. They will not divulge any information unnecessarily and
may only partially fill in forms with deliberately incorrect data. In such
cases, the system must determine which information fields are mandatory
and which are optional.

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.

The absent-minded customer

The absent-minded customer is the careless customer's closest sibling.

Such customers create problems through their forgetfulness; they forget
passwords or that they have already made submissions (so they repeat
submissions), and so on. Or, they might simply forget to turn up!

Most of us have encountered systems that handle forgotten passwords.

Some send the password via email if the customer can answer some
secret questions (whose answers they might forget as well). The same
techniques can be applied to membership registration or account
management use cases.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

Let's consider what happens when a customer forgetfully makes a

duplicate submission -- by clicking the "Submit" button twice, or by
making duplicate submissions in two different system sessions. In either
case, the check for duplications is the same, as depicted in Table 5.

Table 5: Make Reservation use case alternate flow: Duplicate

Submission

UC-1-A-1. Duplicate Submission

If during step 9 of the Basic Flow the system discovers an identical
reservation (same name, email, and start and end dates), the
system displays the existing reservation and asks the customer if he
wants to proceed with the new reservation.

1. If the customer indicates that he wants to continue, the

system proceeds with the reservation. The use case resumes.
2. If the customer indicates that the new reservation is a
duplicate, the use case terminates.

Checking duplications is important, especially when payment is involved,

because the customer will naturally want a refund if he makes a duplicate
payment. The duplication check will prevent additional work on the hotel's
part.

The regretful customer

The regretful, or indecisive, customer is a close relative of careless and

absent-minded customers. Such people are impulsive, often regret their
decisions, and are likely to change their minds. These customers might opt
to either cancel their reservation or modify it before or during check-in.
The alternate flow for handling these regretful/indecisive customers is
depicted in Table 6.

Table 6: Make Reservation use case alternate flow: Amend or

Cancel Reservation

UC-1-A-2. Amend Reservation

After the reservation is made, the customer can make an
amendment or cancellation.

1. The customer submits the reservation number or name.

2. The system retrieves the reservation details.
3. The customer amends the appropriate fields and confirms the
changes.
4. The system checks room availability against the new
reservation data.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

5. If a suitable room is available, the system updates the

reservation.
6. The use case terminates.

UC-1-A-2.1. Cancel Reservation

If in step 2 of the Amend Reservation alternate flow, the customer
indicates a desire to cancel, the system marks the reservation as
invalid.

Note that Table 6 expresses cancellation as a subset of the Amend

Reservation alternate flow. You might want to put both of these flows into
a separate use case instead, but my preference would be to keep them
within the same use case, because they are closely related to other
alternative flows in the use case. For example, the system checks for new
reservations and amendments are fundamentally the same: The
mandatory and optional fields are the same, and the alternate flows will
also be similar.

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.

The procrastinating customer

This customer is in a different group from those we described above.

Procrastinators are always caught up in a meeting, a fight, a traffic jam, a
nap, or studying use cases. Whatever their excuse, the effect is always the
same: a delay in taking care of business. Sometimes the delay is only a
few minutes; sometimes it can be days. Procrastination may not be so
common when it comes to making hotel reservations, but it is quite
common with respect to paying bills, taxes, and so on.

In our example, the customer makes a deposit when he makes a

reservation, so the system cannot release the room if the customer is late
for check-in; after all, he may arrive any moment. Therefore, we need the
alternate flow for the Check-In use case depicted in Table 7.

Table 7: Check-In use case alternate flow: Delayed Check-In

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

UC-2-A-2. Delayed Check-In

If the customer fails to arrive on the check-in date, the system
sends a daily email reminder to the customer.

UC-2-A-2.1. Late Cancellation.

If the customer makes a cancellation after failing to
arrive on the check-in date, the system marks the
reservation as invalid and makes the reserved room
available. The system stops sending email reminders. The
use case terminates.

UC-2-A-2.2. Late Arrival.

If the customer arrives to check in after the check-in
date, the system stops sending email reminders. The use
case resumes at step 3 of the Basic Flow.

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.

The absent customer

The procrastinating customer has an elder sister who not only

procrastinates, but also sometimes does not show up. She may be absent
minded as well. Hotels do not like to have absent customers because they
tie up rooms and make the hotel look less occupied -- and therefore less
desirable to other customers. So we may want to "black list" customers
who do not show up by the end date of their reservation. In the future, if
these customers want to make a reservation, they might be automatically
rejected or designated as low priority. We can represent putting customers
on a black list (even if it is a tentative one) as another alternate flow in
the Check-In use case (depicted in Table 8); think of it as a continuation
of the Delayed Check-In alternate flows shown in Table 7. We must also
consider situations in which customers can be removed from the black list,
so managing the black list should actually be a separate use case.

Table 8: Check-In alternate flow: Absent Customer

UC-2-A-2.3. Absent Customer

If the customer does not arrive or cancel by the end date of the
reserved stay period, the system marks the customer as "black
listed."

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 deceased customer (bless his soul)

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.

Table 9: Check-Out use-case specification: Basic Flow

UC-3. Check-Out use case: Basic Flow

The use case begins when the customer comes to the Reception
Desk to check out of the hotel.

1. The receptionist selects the customer's room number from

the system's room menu.
2. The system computes the outstanding charges for the room
and prints a bill. The system transfers the amount to the
credit card gateway.
3. The customer authorizes the credit card payment.
4. The credit card gateway acknowledges that the amount has
been paid.
5. The system marks the bill as paid and prints a final copy for
the customer.
6. The system makes the room available for booking and check-
in.
7. The use case terminates.

Let's consider what happens if some tragic event happens to the customer
(as depicted in Table 10).

Table 10: Check-Out alternate flow: Tragic Event

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

UC-3-A-1. Tragic Event

If for any reason a customer cannot perform the checkout process
(e.g., the customer has died, had an accident, etc.), the receptionist
can check out the room on behalf of the customer.

1. The receptionist selects the room number from the system's

room menu.
2. The receptionist types in a reason for the customer's inability
to check out.
3. The system computes the outstanding charges and marks the
bill as pending.
4. The system marks the room as unavailable for booking or
check-in until investigations have been completed.
5. The use case terminates.

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.

The agent, or stand-in customer

The procrastinating customer, the absent customer (also known as the

busy customer), and the deceased customer typically have a proxy whom
we will call the agent, or stand-in customer. This person might be an
actual agent (e.g., a travel agent), friend or relative, or personal assistant.
If we incorporate the agent as an actor in our hotel management system,
we can update the use-case diagram as depicted in Figure 2.

Figure 2: Make Reservation use case (with agent)

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

customer. We will add an alternate flow to handle this scenario, as

depicted in Table 11.

Table 11: Make Reservation alternate flow: Agent Reservation

UC-1-A-3. Agent Reservation

If the reservation is made by an agent, the agent must supply her
particulars.

1. At step 8 of the Basic Flow, the applicant indicates that she is

an agent.
2. The system prompts for details about the agent.
3. The agent submits the requested details.
4. At step 9 of the Basic Flow, the system stores the agent's
details with the reservation.
5. At step 10 of the Basic Flow, the system also sends a
confirmation email to the agent.

We can generalize the customer and agent into an "applicant," as depicted

in Figure 3, but we'll still have to consider situations in which the customer
makes the reservation herself apart from those in which an agent acts on
her behalf.

Figure 3: Make Reservation use case (with a generalized actor)

We will also have to generalize the actor into an applicant in the Basic
Flow, updating it as shown in Table 12.

Table 12: Make Reservation use-case specification: Basic Flow

(generalized)
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

UC-1. Make Reservation use case: Basic Flow

The use case begins when an applicant (customer or agent) wants
to reserve a room(s) for himself or another.

1. The applicant requests to reserve a room.

2. The system shows the type of rooms available and their
prices.
3. The applicant selects a room type, and enters start and end
dates for the customer's stay.
4. The system checks availability for the room type on the dates
specified.
5. If an appropriate room is available, the system computes the
deposit charges based on the room type and the number of
days, and then prompts the applicant to confirm the
reservation.
6. The applicant confirms.
7. The system requests the customer's credit card payment
details.
8. The applicant submits the customer's credit card payment
details and personal details (name, email, and mailing
address).
9. The system sends the transaction to the credit card payment
gateway and creates a new reservation in the reservation
database, assigning a unique reservation number.
10. The system displays the reservation details, including the
room type, start and end dates, and reservation number. The
system also sends a confirmation email to the applicant.
11. The use case terminates.

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.

The sentimental customer

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.

Table 13: Make Reservation use case alternate flow: Additional

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

Preference

UC-1-A-4. Additional Preference

If the customer has specific preferences, the Basic Flow can be
modified as follows:

1. At step 3 of the Basic Flow, the customer enters her

preferences.
2. The system appends the preferences to the room search
criteria. The use case resumes.
3. At step 9 of the Basic Flow, the system stores the customer's
preferences along with the reservation. The use case
resumes.

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.

Moreover, customer preferences may potentially affect and cut across

multiple system activities. Handling customer preferences in a separate
extension use case has the advantage of localizing the application of these
preferences in one use case instead of multiple use cases. In addition,
removing a Handle Customer Preference use case would not invalidate
other use cases: The applicant can still reserve a room, check in, and
check out. Handling these preferences truly is a separate concern and
should be treated as such.

The showy customer

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.

Table 14: Make Reservation alternate flow: Alternate Payment

Modes
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

UC-1-A-5. Alternate Payment Modes

If in step 7 of the Basic Flow the customer want to use an alternate
means of payment, the customer can select from a list of payment
methods.

1. The system asks for details about the selected payment

method.
2. The customer supplies the details.
3. The system performs the payment transaction with the
selected payment gateway.
4. The use case resumes.

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.

The bargain-hunting customer

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.

Table 15: Check-Out alternate flow: Offers and Discounts

UC-3-A-2. Offers and Discounts

If in step 2 of the Basic Flow the customer indicates that he has
discount vouchers or loyalty credits, the system verifies the validity
of the discount.

1. If the discount is valid, the system deducts the discount

amount from the bill.
2. The use case resumes.

We would need additional steps to handle situations in which the hotel

accepts a mixture of discount vouchers and loyalty credits.

The geeky customer

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

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.

Table 16: Check-In alternate flow: SMS Check-In

UC-2-A-3. SMS Check-In

If in step 1 of the Basic Flow the customer wants to check in without
being physically present, he has the option to do so with his mobile
phone.

1. Using SMS, the customer sends a message to the hotel with

his name, passport number, or reservation number.
2. The system validates the customer's caller ID.
3. The system retrieves his reservation and assigns him a room.
4. The system sends the room number to the customer and
marks the room as taken.
5. The use case terminates.

Of course, in a real system, we would have to handle situations in which

the SMS sender is an impostor. The flow in Table 16 uses the customer's
caller ID as an identification mechanism, but there are other possibilities
as well, such as passwords.

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

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.

The persistent customer

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

At one time or another we have all encountered people who will go to

great lengths to get their way, possibly even by submitting an appeal to a
higher authority. We will consider a mildly persistent customer, who
simply wants to be put on a waiting list (see Table 17) if no rooms are
available when she requests a reservation.

Table 17: Make Reservation alternate flow: Waiting List

UC-1-A-6. Waiting List

If in step 4 of the Basic Flow no rooms are available, the system
asks whether the customer wants to be put on the waiting list.

1. The customer indicates that he wants to be put on the

waiting list.
2. The system asks for customer particulars.
3. The customer submits his name, contact information, and
email.
4. The system confirms the reservation request details with the
customer.
5. The system adds the customer to the waiting list.
6. The use case pauses.
7. The use case resumes when a room becomes available.

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.

Table 18 describes the case in which a room becomes available through a

cancelled reservation. The system will then check to see whether there is
a waiting list. If there is, then the use-case instance for the alternate flow
in Table 17 will resume at step 8, which will resume back at the Basic
Flow.

Table 18: Make Reservation alternate flow: Person on Waiting List

The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

UC-1-A-2.2 Person on Waiting List

If during the Cancel Reservation alternate flow the system discovers

a person(s) on the waiting list, the system checks to see whether
the available room matches that person's request. If so, then the
system notifies that person, who then has the option to reserve the
room (by initiating a separate use case instance).

This scenario involves synchronization between two use-case instances.

Use-case text is not precise enough to describe synchronization effects;
this is usually done during analysis.

The VIP customer

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.

Table 19: Make Reservation alternate flow: Priority Reservation

UC-1-A-7. Priority Reservation

If in step 4 of the Basic Flow the customer identifies himself as a
VIP and the specific room he requests is already reserved, he can
make a priority reservation.

1. The system verifies that the customer is actually a VIP.

2. The system makes a priority reservation and notifies the
hotel management.
3. The hotel management reviews the priority reservation.
4. The system displays reservation details for both the VIP and
the customer(s) who has reserved the room the VIP
requested.
5. The hotel management decides whether it is acceptable to
cancel the existing reservation.
6. If a cancellation is approved, the system credits the deposit
back to the existing customer and informs that person that
his reservation has been cancelled.
7. The system notifies the VIP customer of his confirmed
reservation.
8. The use case resumes.
The Rational Edge -- October 2003 -- Hunting for use-case scenarios Part I: Analyzing customer psychology

Bumping an existing customer is an extremely tricky issue and may

damage a business's reputation. Before we allow such an action, we
should carefully consider the business consequences (i.e., business
scenarios) and how the system supports them. Table 19 shows just one
example -- a simple one.

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.

A word about semantics and patterns for use cases

We have explored a number of scenarios relating to different types of
customers and documented them as use-case flows. Personally, I find that
categorizing customers can be a good way to infuse some humor into the
stressful job of an analyst. I use these stereotypes to help people think
out of the box and find better ways to discover use-case scenarios for
their projects. This is extremely important, because if you do not, the
customer will. We certainly do not want customers to start complaining
before we do anything -- or we risk losing them.

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.

Developing more precise use-case semantics and harvesting use-case

patterns will require a separate effort, but the scenarios we define in this
series will surely provide a means to "test" such patterns. Watch for Part
II, in which we'll "hunt" for scenarios from a different perspective -- the
stakeholder's.

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

For more information on the products or services discussed in this

article, please click here and follow the instructions provided.
Thank you!

Copyright Rational Software 2003 | Privacy/Legal Information