RSI - A Structured Approach to Use Cases and HCI Design

Worked Example - Hotel Reservation System

(Full Listing)
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.

Mark Collins-Cope Ratio Group Ltd. 17/19 The Broadway Ealing W5 3NH

Email: [email protected] [email protected] Web: www.ratio.co.uk

We Know the Object

RSI Use Cases - Companion Document Worked Example

Page 2 of 21

Table of Contents
TABLE OF CONTENTS ..................................................................................................................................................... 2 1. 2. AD-HOC REQUIREMENTS DOCUMENTATION.................................................................................................. 3 REQUIREMENTS MODEL .................................................................................................................................. 4 2.1. 2.2. 2.3. 2.4. 3. SUMMARY USE CASE DIAGRAM .............................................................................................................................. 4 REQUIREMENT 'STAY AT HOTEL' ........................................................................................................................ 4 REQUIREMENT 'CHECK-OUT DUE' ....................................................................................................................... 5 REQUIREMENT 'CANCEL NO-SHOWS'................................................................................................................... 6

INTERFACE MODEL........................................................................................................................................... 7 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. SUMMARY USE CASE DIAGRAM .............................................................................................................................. 7 INTERFACE 'CUSTOMER/RESERVATION MANAGEMENT' ........................................................................................ 7 INTERFACE 'BILL'............................................................................................................................................. 10 INTERFACE 'CUSTOMER DETAILS' ..................................................................................................................... 10 INTERFACE 'PAYMENT DETAILS' ....................................................................................................................... 11 INTERFACE 'CHECK-OUT DUE' .......................................................................................................................... 11 INTERFACE 'CANCEL NO-SHOWS' ...................................................................................................................... 12

4.

SERVICE MODEL ............................................................................................................................................... 13 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11. 4.12. 4.13. 4.14. 4.15. 4.16. 4.17. 4.18. SUMMARY USE CASE DIAGRAM ............................................................................................................................ 13 CORE SPECIFICATION MODEL ............................................................................................................................... 13 UPDATE 'MAKE RESERVATION'......................................................................................................................... 13 UPDATE 'CREATE CUSTOMER' .......................................................................................................................... 14 UPDATE 'UPDATE CUSTOMER' .......................................................................................................................... 15 UPDATE 'DELETE RESERVATION' ...................................................................................................................... 15 UPDATE 'ADD PAYMENT INFORMATION'............................................................................................................ 16 UPDATE 'CONFIRM CHECK-IN' .......................................................................................................................... 16 QUERY 'GET BILL DETAILS' .............................................................................................................................. 16 QUERY 'FIND NO-SHOW CUSTOMERS'................................................................................................................ 17 QUERY 'FIND CHECK-OUT DUE CUSTOMERS' ..................................................................................................... 17 QUERY 'FIND CUSTOMERS BY NAME' ................................................................................................................ 17 QUERY - 'GET CUSTOMER DETAILS'.................................................................................................................. 18 QUERY - 'GET AVAILABILITY BY DATES'........................................................................................................... 18 QUERY - 'GET RESERVATIONS BY DATES' ......................................................................................................... 18 QUERY - 'GET RESERVATIONS BY CUSTOMER'................................................................................................... 19 QUERY - 'GET CUSTOMER BY RESERVATION '.................................................................................................... 19 QUERY - 'GET ACCOUNT TOTAL' ...................................................................................................................... 19

5.

CONSOLIDATED TRACEABILITY MODEL ...................................................................................................... 21

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 3 of 21

1.

Ad-hoc requirements documentation

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

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 4 of 21

2.
2.1.

Requirements model
Summary use case diagram

<<requirement>> use case model

Stay at Hotel Customer <includes> <includes> Cancel no-shows

timer Check-out due

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

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 5 of 21

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

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 6 of 21

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 2. The system deletes reservations at {no-show-time} on the day of the reservation. For the purposes of the worked example it is assumed that the all requirements detailed above are undertaken in the first phase of the project.

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 7 of 21

3.
3.1.

Interface model
Summary use case diagram

interfaces

Timer

Clerk

Check out due Cancel no shows Customer and reservations

<<includes>> <<includes>> Payment

Bill

<<includes>>

Customer create/update

3.2.

Interface 'customer/reservation management' 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. Format

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 8 of 21

Customer/Reservation Management
Customer
surname
find

Reservation
start date
new...

collins-c

21-1-00 22-1-00
existing

end date

Collins-Cope, Liz Collins-Cope, Nathan Collins-Cope, Mark Collins-Cope, Lewis

details... payment... print bill reservations

S NS S NS

availability

21 20/1/00 24-1-00 24 17/1/00 04-2-00 01 20/1/00 24-1-00 22 20/1/00 24-1-00

delete

S -------S --------S --------S --------customer

check-in

check-out

reserve

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

(interface 'customer/reservation management') Functionality:

find button is disabled if no characters in surname field New button always available. Clicking new button pops up <<interface>> Customer details with all fields blank. On return, customer is entered into list box and selected. If a listbox contains one item, the item is selected by default. Clicking the existing button causes reservations between dates specified above to be displayed in the listbox. Uses <<query>> find reservations by dates. This group of buttons is disabled unless two dates are filled in above

Clicking the availability button causes room between the given dates to be displayed in the listbox. Uses <<query>> find availablity by dates

Clicking find button populates listbox with matching names. Uses <<query>> Find customers by name

Customer/Reservation Management Customer surname find collins-c new... start date end date Reservation 21-1-00 22-1-00 existing S -------S --------S --------S --------customer

This group of buttons is disabled unless a name is selected in the listbox above. Clicking the details button causes the <<interface>> Customer details to be poed-up, with details as per the selected Customer. Clicking the payment button causes the Payment <<interface>> to be pop-up, with the selected Customers details showing.

Collins-Cope, Liz S Collins-Cope, Nathan NS Collins-Cope, Mark S Collins-Cope, Lewis NS details... payment... print bill reservations

availability 21 20/1/00 24-1-00 24 17/1/00 04-2-00 01 20/1/00 24-1-00 22 20/1/00 24-1-00 delete

Clicking the deletei button causes the selected Reservation to be deleted. Uses <<update>> delete reservation Clicking the customer button causes the selected Reservations customer to be displayed opposite Uses <<query>> Get customer by reservation

check-in

check-out

reserve See main document. Clicking the reservations button and Reservation listbox is filled with selected Customers details. Creates a reservation using <<update>> make reservations Check-out confirms customer check-out. Uses <<update>> delete reservation.

Clicking the print bill button causes the bill to be printed as per the print bill <<interface>> Uses <query> Get bill details.

This group of buttons is disabled unless a customer and reservation are selected Clicking check-in button conforms check-in. Uses <<update>> confirm check-in.

We Know the Object

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
Fields may be initialised with customer details using <<query>> Get customer details. Customer Details
surname first name address address address Collins-Cope Mark

smoker

update

cancel

Clicking the update button updates the Customer using <<update>> create/update customer details.

We Know the Object

RSI Use Cases - Companion Document Worked Example

Page 11 of 21

3.5.

Interface 'payment details' from requirement 'stay at hotel' step 8. Actor: Clerk Objective: to enable entry of payment details onto the system.

Payment
The OK button is disabled until an amount is entered into the total paid field.

total owing total paid

2302.55 2302.55

OK

Cancel

Clicking on the OK button uses <<update>> Add payment details.

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 cccccccccccccccccccccc etc. Functionality 1. All customers who have a reservation due to end today are printed (using query 'find check-out due customers')

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 12 of 21

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.'

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 13 of 21

4. Service model
4.1. Summary use case diagram
essential <<services>> model

Find Customers by Name

Get Availability by Dates

Get Reservations by Customer

Get Account total Add Payment Information Find check-out due Customers Make Reservation Delete Reservation

Get Customer Details

Get Reservations by Date(s)

Get Customer by Reservation Find no-show customers Create/update customer

Confirm check-in Get bill details

<<full service>> model

4.2.

Core specification model Service descriptions cross-reference the following object model:
::Customer firstName surname address1 address2 address3 * customers 1

::Room 1 reservedby * reservations ::Reservation start-date end-date checked-in 1 * reservations 1 ::Hotel smoking-rule 1 * reservations 1 reserved * rooms

Invariant: Room reservations do not overlap.

Invariant: invarant: start-date < end-date All Reservations must have an associated Customer in Hotel.customers. All Reservations must have an associated Room in Hotel.rooms.

1 account ::Account <<singleton>> 1 * items ::AccountItem value description date

values: smoking,non-smoking

Invariant: The is no overlap in Reservation dates for all the Reservations associated with any particular Customer

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;

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 14 of 21

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' from requirement 'stay at hotel' step 2 in:aSurnameString, aFirstNameString, anAddressString1 anAddressString2, anAddressString3 out:status; pre:-conditions:none. post:-conditions: A new Customer (aCustomer) is added to Hotel.customers, such that

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 15 of 21

aCustomer.FirstName = aFirstNameString, aCustomer.LastName = aLastNameString, aCustomer.Address1 = anAddressString1, aCustomer.Address2 = anAddressString2, aCustomer.Address3 = anAddressString3 4.5. Update 'update customer' from requirement 'stay at hotel' step 2 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.

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 16 of 21

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).

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 17 of 21

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' from interface 'customer/reservation management' in:aCustomerName out:aMatchingCustomerSet pre:none post:-

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 18 of 21

aMatchingCustomerSet contains all the Customers in Hotel.customers for whom Customer.surname matches the (partial) name string aCustomerName. 4.13. Query - 'Get customer details' from interface 'customer/reservation management' in:aCustomer out:aFirstNameString, aLastNameString, anAddressString1, anAddressString2, anAddressString3 pre:aCustomer is in Hotel.customers - i.e. it already exists. post:aFirstNameString = aCustomer.FirstName aLastNameString = aCustomer.LastName anAddressString1 = aCustomer.Address1 anAddressString2 = aCustomer.Address2 anAddressString3 = aCustomer.Address3 4.14. Query - 'Get availability by dates' from interface 'customer/reservation management' in:aStartDate, anEndDate out:anAvailableRoomSet pre:aStartDate <= anEndDate post:anAvailableRoomSet contains all the Rooms in Hotel.rooms which have no Reservations overlapping with aStartDate and anEndDate inclusive. 4.15. Query - 'Get reservations by dates'

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 19 of 21

from interface 'customer/reservation management' in:aStartDate, anEndDate out:aReservedRoomSet pre:aStartDate <= anEndDate post:aReservedRoomSet contains all the Rooms in Hotel.rooms which have Reservations overlapping with aStartDate and anEndDate inclusive. 4.16. Query - 'Get reservations by customer' from interface 'customer/reservation management' in:aCustomer out:aReservationSet pre:aCustomer is in Hotel.customers post:aReservationSet is aCustomer.reservations. 4.17. Query - 'Get customer by reservation ' from interface 'customer/reservation management' in:aReservation out:aCustomer pre:aReservation is in Hotel.reservations post:aCustomer is Reservations.reservedby. 4.18. Query - 'Get account total' from interface 'payment details'

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 20 of 21

in:anAccount out:aTotal pre:anAccount is in Hotel.customers.account. post:aTotal is equal to the sum of all the value attributes of the AccountItems associated with anAccount (via anAccount.items).

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00

RSI Use Cases - Companion Document Worked Example

Page 21 of 21

5.

Consolidated Traceability Model

requirements
<<includes>> Stay at hotel <<includes>> Customer Cancel no shows Timer Check out due

Timer

Clerk

Cancel no shows

Check out due Customer and reservations

Make reservation <<update>> Delete reservation <<update>>

<<includes>> <<includes>> Payment Add payment information <<update>> Bill Get bill details <<query>> Customer create/update <<includes>>

essential services

Create customer <<update>> Update customer <<update>>

interfaces
Find customers by name <<query>> Get account total <<query>> Get customer details <<query>> Get reservations by dates <<query>> Get customer by reservation <<query>> Get availability by dates <<query>>

Find no show customers <<query>>

Find check-out due customers <<query>>

Get reservations by customer <<query>>

consolidated services = essential + these

W5b - RSI LONG PAPER [42 PAGES} (COMPANION DOCUMENT).doc( Rev: 3) - 03/09/00