RSI - A Structured Approach to Use Cases and HCI Design
Worked Example - Hotel Reservation System (Full Listing)
Mark Collins-Cope

PDF version

This document acts as a companion to the paper: "RSI - A Structured Approach to Use Cases and HCI Design" which should be read in order to understand the contents of this document.

1. Ad-hoc requirements documentation

The worked example shown is based on the following ad-hoc requirements documentation:

Reference Problem Statement

A. The guest makes a reservation.

B. The hotel will take as many reservations as it has rooms available.

C. When a guest arrives, he or she is processed by the registration clerk.

D. The clerk will check the details provided by the guest with those that are recorded.

E. Sometimes, guests do not make a reservation before they arrive.

F. Some guests want to stay in non-smoking rooms.

G. When a guest leaves the Hotel, he or she is again processed by the registration clerk.

H. The clerk checks the details of the guest staying and prints a bill.

I. The guest pays the bill, and leaves the Hotel and the room becomes unoccupied.

Reference	Problem Statement
A.	The guest makes a reservation.
B.	The hotel will take as many reservations as it has rooms available.
C.	When a guest arrives, he or she is processed by the registration clerk.
D.	The clerk will check the details provided by the guest with those that are recorded.
E.	Sometimes, guests do not make a reservation before they arrive.
F.	Some guests want to stay in non-smoking rooms.
G.	When a guest leaves the Hotel, he or she is again processed by the registration clerk.
H.	The clerk checks the details of the guest staying and prints a bill.
I.	The guest pays the bill, and leaves the Hotel and the room becomes unoccupied.

2. «Requirements» model

2.1. Summary use case diagram

2.2. «Requirement» 'stay at hotel'

Actor: Customer
Objective: To book and stay in a room.

Normal flow: [assumes everything goes fine]
1.    The customer contacts the hotel and requests a booking (A)
2.    The clerk processes the booking (automated) (B - must check availability) (F - must check if smoking preference available).
3.    The customer turns up at the hotel to check in. (C)
4.    The clerk processes the customer (automated) (C) (D - checks details against reservation)
       (E - guest may not have reservation) (F - check smoking preferences) confirms the customer has arrived.
5.    The customer stays in the room.
6.    The customer requests check out. (G)
7.    The clerk prints the bill showing the cost, date, and a description of each item, (G) (H) and the room is freed up. (automated)
8.    The customer checks the bill and pays it (automated). (I)

Extensions:
[ These are generated by taking each step in the above normal flow, and asking: what could possibly go wrong?
1a: indicates something is wrong with step 1; 1a1, etc. indicates alternative steps taken, etc. ]

2a.   No room is available for the required dates (B)
2a1.  Use case terminates. No further action. No record on interaction on system.

2b.   The customers smoking preference is unavailable, and they will compromise.
2b1.  Continue normal flow.

2c.   The customers smoking preference in unavailable, and they won't compromise.
2c1.  Bye bye customer. Use case terminates. No further action.

3a.   The customer doesn't turn up.
3a1.  The system checks reservations every midnight, and cancels no-shows
         (automated - see «requirement» use case 'cancel no-shows')

3b.   The customer cancels the reservation.
3b1.  The clerk cancels the reservation (automated)

4a.   The customer doesn't have a reservation.
4a1.  The clerk checks availability and creates a reservation as per step 2, normal flow continues.
         [note: step 2 error conditions may apply]

4b.   The customers details as per the reservation are incorrect (but smoking preference is ok)
4b1.  The clerk updates them to be correct (automated).

4c.   The customer smoking preference is wrong.
4c1.  The clerk cancels the existing booking (automated) and makes a new reservation as per step 2.

7a.   The customer doesn't check out.
7a1.  The system alerts the clerk after check-out time that the customer hasn't checked out
         (automated - see «requirement» use case 'check-out due')

etc.

2.3. «Requirement» 'check-out due'

Actor: Customer, Clerk
Objective: To alert the clerk that a customer has not checked out.

Normal flow:
One or more customer fails to turn up at check-out time.
The system alerts the clerk at {alert-interval} intervals of customers who haven't checked out.
[{item} is used to indicate a system configuration item]

2.4. «Requirement» 'cancel no-shows'

Actor: Customer
Objective: To cancel bookings for which the customer does not turn up.

Normal flow:
One or more customers fail to turn up at check-in time.
The system deletes reservations at {no-show-time} on the day of the reservation.

3. «Interface» model

3.1. Summary use case diagram

3.2.«Requirement» 'cancel no-shows' from«requirement» 'stay at hotel' steps 2, 4, 7, 8, 3b,4a1, 4b1, 4c1.

Actor: Clerk
Objective: to enable the management of customers and reservations.

Normal flow:

(«interface» 'customer/reservation management')
Functionality:

NOTE: Enlarge the diagram above by clicking on the picture.

3.3. «Interface» 'bill' from «requirement» 'stay at hotel' step 7.

Format:
          Bill for <surname>, <first name>
          Printed: dd/mm/yy
          Item                                 Date                                 Value                                 Balance
          cccccccccccccccccc         dd/mm/yy                      #####.##                         ######.##
          ...

          Total:                                                                                                             ######.##

Functionality:
1.       Lines within the report are filled in using '«query» get bill details'.

3.4. «Interface» 'customer details'

from «requirement» 'stay at hotel' step 2, 4b, 4c1.

Actor: Clerk
Objective: to enable creation and update of Customer details.

Formats and Functionality

3.5. «Interface» 'payment details'

from «requirement» 'stay at hotel' step 8.

Actor: Clerk
Objective: to enable entry of payment details onto the system.

Formats and Functionality

3.6. «Interface» 'check-out due'

from «requirement» 'check-out due' step 2.

Actor: Timer
Objective: to provide details of customers who have not checked-out of the hotel on time.

Formats
The following report is printed by the system
               Customers due to check-out on <date> who have not done do.
               Name
               ccccccccccccccccccccccc
               etc.

Functionality
1. All customers who have a reservation due to end today are printed (using «query» 'find check-out due customers')

3.7. «Interface» 'cancel no-shows'

from «requirement» 'cancel no-shows' step 2.

Actor: Timer
Objective: to cancel reservations of customers who haven't turned up.

Formats
none.

Functionality
1. All customers who have a reservation for today but who have not checked-in have their reservation cancelled (using «query» 'find no show customers', and «update» 'delete reservation.'

4. «Service» model

4.1. Summary use case diagram

NOTE: Enlarge the diagram below by clicking on the picture.

4.2. Core specification model

«Service» descriptions cross-reference the following object model:

NOTE: Enlarge the diagram below by clicking on the picture.

4.3. «Update» 'make reservation'

[Note: the service descriptions below are part of the essential model until indicated otherwise]

from «requirement» 'stay at hotel' step 2

in:- [what information is passed from the actor to the system]
start-date, end-date, aRoom, aCustomer;
out:- [what information does the system pass back to the actor]
status [shorthand for ok/fail]
pre:-conditions:- [what must be true before this service can be invoked]
start-date <= end-date;
aRoom is available from start-date to end-date inclusive;
aCustomer does not have any existing Reservations between start-date and end-date inclusive;
post:-conditions:- [what state changes will have taken place when this use case ends]
aReservation is added to Hotel.reservations, such that

aReservation.start-date = start-date
aReservation.end-date = end-date
aReservation.reservedby = aCustomer
aReservation.reserved = aRoom

In OCL:

Hotel::MakeReservation(start:Date, end:Date, aRoom:Room, aCustomer:Customer)
pre: ( start <= end ) and
        ( aRoom.reservations->forAll( (end < start-date) or (start > end-date) ) ) and
        ( aCustomer.reservations->forAll( (end < start-date) or (start > end-date) ) )

post: ( self.reservations->includes(aReservation) ) and
         ( aReservation.start-date = start ) and
         ( aReservation.end-date = end ) and
         ( aReservation.reservedby = aCustomer ) and
         ( aReservation.reserved = aRoom )

4.4. «Update» 'create customer'

in:-
aSurnameString, aFirstNameString, anAddressString1 anAddressString2, anAddressString3
out:-
status
pre:-conditions:-
none
post:-conditions:
A new Customer (aCustomer) is added to Hotel.customers, such that
aCustomer.FirstName = aFirstNameString,
aCustomer.LastName = aLastNameString,
aCustomer.Address1 = anAddressString1,
aCustomer.Address2 = anAddressString2,
aCustomer.Address3 = anAddressString3

4.5. «Update» 'update customer'

in:-
aCustomer, aSurnameString, aFirstNameString, anAddressString1 anAddressString2, anAddressString3
out:-
status
pre:-conditions:-
aCustomer is in Hotel.reservations (i.e. it already exists).
post:-conditions:
aCustomer attribute values are set such that:
aCustomer.FirstName = aFirstNameString,
aCustomer.LastName = aLastNameString,
aCustomer.Address1 = anAddressString1,
aCustomer.Address2 = anAddressString2,
aCustomer.Address3 = anAddressString3

4.6. «Update» 'delete reservation'

from «requirements» 'stay at hotel' step 2c, 'cancel no-shows' step 2.

in:-
aReservation
out:-
status
pre:-conditions:-
aReservation is in Hotel.reservations - i.e. it already exists.
post:-conditions:
aReservation is no longer in Hotel.reservations.

The post-condition of this «service» could have specified that aReservation should also be 'de-coupled' from its associated Customer and Room. This is unnecessary, however, as it is implied by an invariant on the model.

4.7. «Update» 'add payment information'

from «requirement» 'stay at hotel' step 8

in:-
aCustomer, aMoneyValue
out:-
status
pre:-conditions:-
aCustomer is in Hotel.reservations - i.e. already exists.
post:-conditions:
anAccountItem is added to aCustomer.account.items, such that anAccountItem.value = aMoneyValue.

4.8. «Update» 'confirm check-in'

from «requirement» 'stay at hotel' step 4

in:-
aReservation
out:-
status
pre:-conditions:-
aReservation is in Hotel.reservations - i.e. it already exists.
post:-conditions:
aReservation.checked-in = True.

4.9. «Query» 'get bill details'

from «requirement» 'stay at hotel' step 7

in:-
aCustomer
out:-
anAccountItemSet
pre:-
aCustomer is in Hotel.customers
post:-
anAccountItemSet contains all the AccountItems associated with the Account (via Account.items) which is associated with aCustomer (via aCustomer.account).

4.10. «Query» 'find no-show customers'

[Note: the service descriptions below are part of the consolidated services model]

from «interface» 'cancel no-shows'

in:-
none.
out:-
aNoShowCustomerSet
pre:-
none
post:-
aNoShowCustomerSet contains all the Customers in Hotel.customers with an associated Reservation in which start-date is today, and checked-in is set to false.

4.11. «Query» 'find check-out due customers'

from «interface» 'check out due'

in:-
none.
out:-
aCheckOutDueCustomerSet
pre:-
none
post:-
aCheckOutDueCustomerSet contains all the Customers in Hotel.customers for whom a Reservation is held in which the end-date is set to today.

4.12. «Query» 'find customers by name'