time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 分析与建模 > 探索用例场景(1)分析客户心理

探索用例场景(1)分析客户心理

时间:2009-12-01 20:27 点击:3766次 字体:[ ]




    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 problemfocused 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, 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.
    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 usecase
scenario represents one complete path through a use case; a usecase
alternate flow is one segment of that path. If you compare two
distinct scenarios, the difference between them is the alternate flow. A usecase
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
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
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.
    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 reenters
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 userexperience
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.
    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.
    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
    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 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 checkin.
    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
    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 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)
    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
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
    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 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
    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
    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.
    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.


本文地址 : http://www.fengfly.com/plus/view-158662-1.html
标签: 探索 场景 分析 客户 心理 The To
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: