Case Study on Room Booking

1
Case Study on Room Booking
2
Case Study on Room BookingInitial Requirements
Requirements   -         R1 Handle requests
automatically by o       R1.1 Offering one
candidate booking matching the request
or, o       R1.2 Offering to wait-list the
request -         R2 Pile down wait-listed
asap -         R3 Maintain availability of
rooms accurately timely -         R4 Maintain
customer list -         R5 Charge customer on
late cancellation request  
3
Class Schema (option 1)
Request
0..
0..
1..

• NumReq
• NbRoomReq

1
1..
Person

• NumPers
• FirstNamePers
• LastNamePers
• AddPers
• TelPers

Cancelled
Wait-listed
Accepted
1
1
Booking
Room
Customer
1
1..
1..
0..
NumBook /NbRoomBook
NumRoom BedType
allocates
1
1..
1..
1..
0.
1..
Time Point
is available
- DateTP
Booking State
StateBooking
1
1
begins
ends
1..
1.
1
Period
0..
Resort
1
1
1
NumResort NameResort
1
NumRoom
1..
Hotel Category
Hotel
1
1..
NumHot NameHot AddHot TelHot MailHot
NumHType DescHType
1
4
Case Study on Room BookingEvents Description
5
Case Study on Room BookingEvents Description
6
Case Study on Room BookingEvent Description
7
Case Study on Room BookingCompleted Requirements
  -         R1 Handle requests automatically
by R1.1 Offering one candidate booking
matching the request or, R1.2 Offering to
wait-list the request -         R2 Pile down
wait-listed asap -         R3 Maintain
availability of rooms accurately timely R3.1
For every booking R3.2 For every
cancellation R3.3 For stay ending
prematurely R3.4 For every acknowledgment of
real world change in resource portfolio -        
R4 Maintain customer list -         R5 Charge
customer on late cancellation request - R6
Keep track of request status over time - R7
Keep track of booking status over time - R8
Maintain prospect list (not only customer
list) - R9 Allocate rooms to bookings at
booking time - R10 Cancel wait-listed request
on requester demand when waiting delay is
over  
8
 
Case Study on Room BookingTrace
 
9
Case Study on Room BookingTrace
 
10
Case Study on Room BookingDiscussion
Issue 1 Why keeping track of request in the
database?

• Position 1 keeping track of all requests
• Positive arguments
• statistics about request flows are possible
• mining lead to better understanding of the ad
  equation
• of resources to client needs
• - better customer knowledge
• Negative arguments
• cost is higher
• history of request life cycle is a necessary
  condition

 
11
Case Study on Room Booking Discussion
Issue 1 Why keeping track of request in the
database?

• Position 2 keeping track of forthcoming
  bookings only
• Positive arguments
• minimal cost
• system simplicity
• Negative arguments
• no possible mining and therefore reasoning about
  flows and
• client needs is impossible

 
12
Case Study on Room Booking Discussion
Issue 2 Why managing availability at room level?

• Position 1 keeping track of hotel room
  day-to-day availability
• Positive arguments
• better customer servicing
• fine request tuning is possible
• tailored customer servicing is possible
• Negative arguments
• higher cost
• occupancy is not maximised
• resource updating is more complex

 
13
Case Study on Room Booking Discussion
Issue 2 Why managing availability at room level?

• Position 2 keeping track of hotel availability
  at room-category level
• Positive arguments
• less cost
• more simple system
• maximisation of room occupancy
• Negative arguments
• less customised servicing
• poor servicing (customer may be obliged to
  change room)
• standard request

 
14
Class Schema (option 2)
15
Case Study on Room BookingHierarchy of Goals
16
Case Study on Room Booking Requirements Flowing
From Goals
Secure customer loyalty
Reward customer loyalty
Provide personalised service
Upgrade booking
Install loyalty programme
Make proactive offers
Offer cancellation insurance
Give priority to loyal customer demands
Make personalised booking offer
Allow personalisedrequest
Assure stay/booking conditions conformity
R15
R11 implies R4, R8
R13
R17
R16 Implies R10
R14 Implies R2
R9 Implies R3
R12 Implies R1, R6 R7
17
Case Study on Room BookingAdditional Requirements
  -         R11 Handle requests of different
formats R4 Maintain customer list R8
Maintain prospect list R12 Take into account
customer booking history to make a booking
offer R1 Handle requests automatically R6
Keep track of request history R7 Keep track
of booking history R9 (justified) Allocate
rooms to bookings at booking time R3 Maintain
availability of rooms accurately timely R13
Manage rewarding point system R14 Select
wait-listed request according to priority R2
Pile down wait-listed asap R15 Offer booking
upgrade R16 Manage customer cancellation
insurance R10 Cancel wait-listed request on
requester demand R17 Handle special hotel
offers  
18
Case Study on Room BookingImpact on Schema
19
Case Study on Room BookingImpact on Schema
20
Case Study on Room Booking Hierarchy of Goals
(option 2)
21
Case Study on Room Booking Requirements Flowing
From Goals (option 2)
Maximise room occupancy
Standardise rooms prices
Simplify the booking process
Standardise request formulation
Deal with request instantaneously
Manage availability at hotel level
R1
System knows number of hotel rooms per category
R3 R4
R5
R2
R3System calculates a yes-or-no reply R4
System keeps track of forthcoming bookings only
System maintains hotel availability daily per
room category
A request is for one hotel and one room category
22
Customer
Data Schema (option 2)

• NumCust
• FirstNameCust
• LastNameCust
• AddressCust
• TelephoneCust

0..
Booking
1
0..
NumBook NbRoomBook DurationBook
1..
begins
0..
1
Room Category
NumRoomCat DesRoomCat
Availability
NumberOfRooms
1
1..
Date
1..
Hotel
1
NumHot NameHot AddressHot TelHot MailHot CapHot
23
(No Transcript)