Small Hotel Reservation System (SHORS)

Requirement Document
A. Problem: The proposed software system will be used to manage the front-desk activities of a hotel. It will be able to accept reservations, to record information about the hotel guests, to verify room availability, and to allocate rooms to guests. B. Background information: See Lethbridge and Laganire Object-oriented Software Engineering page 149 for a short description of the problem. Note that the writing of this document would normally have been preceded by a sound domain analysis. The goal of this project is to create a system to manage the front-desk activities of the Interface Rapids Hotel. You have been contracted to replace the existing paper-based system, since your customers believe an automated system will save money and help them to serve guests better. The system will be used to enter reservations as well as to check people in and out of the hotel. The hotel contains 30 rooms in which guests can stay. Some hotel rooms adjoin others; i.e., there are internal doors between them, so they can be used individually or as a suite. A guest can stay in either an individual room or a suite. Each hotel room is assigned a quality level (e.g. a larger room or a room with a view would be better than a smaller room without a view). Each room also has a certain number and type of beds, a room number, and a smoking/non-smoking status. Each quality level has a maximum daily rate, although the rate that a guest pays may be less. When a hotel guest wishes to make a reservation, the hotel clerk asks him or her what nights he or she wants to stay and the type of room he or she wants. The system must verify if room(s) are available on those nights before allowing a reservation to be made. The hotel needs to record basic information about each guest, such as his or her name, address, telephone number, credit card etc. A reservation can be cancelled at any time. When a guest checks in, a room is allocated to him or her until he or she checks out. The system must keep track of the guests account, and print his or her bill. C. Environment and system models: In its first version, the SHORS will be a simple application to be run from a single computer. The second version should be a client/server system where the client component is used to manage the reservations and the server centralizes the corresponding data. A third version is also envisaged where guests will be able to make their reservations from the Internet. D. Functional requirements: 1. Guest 1.1. The information associated with each guest is: name, address and phone number. 1.2. The full name of a guest is represented by a single string of characters. 1.3. Guests are searched using a substring, any guest name that contains that substring is returned by the search operation.

1.4. The address of a guest is represented by a single string of characters. This contains the complete address (street, city, postal code, ) 1.5. The phone number is represented by a string of characters. 1.6. An account can be printed and contains the information about a guests stay and the amount to be paid. The printed account also includes the name of the hotel and the date at which it has been issued. 2. Room 2.1. Each room has a number. Some of them are also designated by a special name. 2.2. A quality level is associated with each room. 2.3. A quality level is identified by a number. Standard rooms usually have quality number 0. This number increases as the quality of the associated increases. 2.4. Quality level can also be given a name. 2.5. A list of characteristics is associated with each quality level. It describes the equipment common to the room having this quality level as well any other special elements such as location, views or privileges. 2.6. All rooms having the same quality level have the same maximum daily rate. 2.7. The maximum daily rate is for one person. There may be an additional charge for each extra person. 2.8. The room charge per night can be less than the specified daily rate. 2.9. A room is either smoking or non-smoking. 2.10. A room contains a certain number of beds, all of the same type. Typical configurations are 2 Queen beds or 1 King bed. 2.11. Some rooms can adjoin 1 or 2 other rooms. 2.12. Adjoining rooms always belong to the same quality level. 2.13. Equivalent rooms are said to belong to the same category. When a guest makes a reservation, recording the room category is sufficient. On check-in, any available room of the required category can be assigned to the guest. 2.14. Two rooms are equivalent if they belong to the same quality level, they have the same smoking status and they have the same type and number of beds. 3. Reservation 3.1. To make a reservation, the guest must specify the arrival date and the departure date (or the number of nights) for the proposed stay. 3.2. Normally, a room is not allocated when a guest makes a reservation, the room allocation being made only when the guest checks in. 3.3. A reservation is accepted only if rooms are available. 3.4. A room is available if the total number of rooms of the required category is greater than the number of rooms of that category requested by the reservations, throughout the specified period. 3.5. When a reservation is made for a suite (i.e. two or more adjoining rooms), the room allocation must be done immediately. 3.6. A reservation is for one guest, for one sequence of consecutive nights for rooms of one category. 3.7. A reservation can be cancelled at any time. E. Non Functional Requirements

Although this project has been undertaken to satisfy the needs of a particular hotel, it should be built with enough flexibility such that it can be used by a wide variety of hotels. 2. In its client/server version, the amount of information sent to the client should be minimized. 3. The user interface of the system does not have to allow a user to enter and modify information concerning the hotel configuration (number of rooms, room descriptions, etc.). However, there should exist a simple means by which the hotel can be described (such as a text file). 4. Information concerning guests and their reservations must be persistent.

Some comments concerning the requirements: Req. 1.1 : Credit card information is not included here. Card type, number and expiration date is the information generally associated with a credit card. This information could also be associated with each stay. Sometimes a guest can provide more than one credit card. Adding this information is left to a future release. Req. 1.2 : Having first name and last name as separate attributes would be a better choice. This would be required, for example, if one wants to display the list of guests in alphabetical order of their last names. However, using a single attribute simplifies the implementation, and gives more flexibility in case of unusual name formats. Req. 1.4 : For more flexibility, each component of the address could be a separate attribute. Req. 1.6 : The guest account is used here only to produce a bill concerning a guests stay. More investigation should be done to determine what information should be recorded here. It should also be possible to include the various items that can also appear on a hotel bill such as food, movie rental, purchases at hotels boutique, etc. Req. 2.6 : Note that in most hotels, the actual rates charged depend on time of year, whether the hotel is near capacity, day of the week etc. Req. 2.12 : The quality level restriction on adjoining rooms has been added for simplicity. A good domain analysis would confirm if this assumption is realistic. Req. 2.13 : Even if this requirement is not explicit in the project description, any quick domain analysis would reveal the necessity of introducing the concept of equivalent rooms. Indeed, even if rooms are not allocated at reservation time, the fact that this guest wants, lets say, a twoqueen-bed smoking room must be recorded to make sure that such a room will be available when the guest arrives. Req. 3.5 : This restriction must be added to reduce the complexity of the room availability and room allocation procedures. One can verify that it would be quite complex to guarantee that two adjoining rooms will be available without actually allocating them at reservation time.