You are on page 1of 7

Hotel Automation Software Software Requirements Specification

Version <1.0>

Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics Specific Requirements 3.1 External Interface 3.1.1. User Interface 3.1.2. Software Interface 3.1.3. Hardware Interface 3.1.4. Communication Interface 3.2 Functional Requirement 3.3 Purchased Components 3 3 3 3 3 4 4 4 4 5 5 5 5 5 5 6 6 7

2.

3.

1. Introduction The following subsections of the Software Requirements Specifications (SRS) document provide an overview of the entire SRS. 1.1 Purpose The Software Requirements Specification (SRS) will provide a detailed description of the requirements for the Hotel Automation Software (HAS). This SRS will allow for a complete understanding of what is to be expected of the HAS to be constructed. The clear understanding of the HAS and its functionality will allow for the correct software to be developed for the end user and will be used for the development of the future stages of the project. This SRS will provide the foundation for the project. From this SRS, the HAS can be designed, constructed, and finally tested. This SRS will be used by the software engineers constructing the HAS and the hotel end users. The software engineers will use the SRS to fully understand the expectations of this HAS to construct the appropriate software. The hotel end users will be able to use this SRS as a test to see if the software engineers will be constructing the system to their expectations. If it is not to their expectations the end users can specify how it is not to their liking and the software engineers will change the SRS to fit the end users needs. 1.2 Scope The software product to be produced is a Hotel Automation Software which will automate the major hotel operations. The first subsystem is a Reservation System to keep track of reservations and room availability. The second subsystem is the Catering System that charges the current room. The third subsystem is a Management System which caters for General Management Services and allows modification of subsystem information. These three subsystems functionality will be described in detail in section 2-Overall Description. There are three end users for the HAS. The end users are the booking clerks, catering service representative and hotel managers. The first two have access to the Reservation and catering System respectively. The General Management System will be restricted to management users apart. The managers have access to the other systems as well. 1.3 Definitions, Acronyms and Abbreviations SRS Software Requirements Specification HAS Hotel Management System Subjective satisfaction The overall satisfaction of the system End users The people who will be actually using the system 1.4 References [1] The applicable IEEE standards are published in IEEE Standards Collection, 2001 edition. [2] The principal source of textbook material is Fundamentals of Software Engineering by Rajib Mall (PHI 2009).

1.5 Overview The SRS is organized into two main sections. The first is The Overall Description and the second is the Specific Requirements. The Overall Description will describe the requirements of the HAS from a general high level perspective. The Specific Requirements section will describe in detail the requirements of the system. 2. The Overall Description This section describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead it provides a background for those requirements, which are defined in section 3, and makes them easier to understand. 2.1 Product Perspective The HAS is an independent standalone system. It is totally self contained. The HAS will be placed on PCs throughout the hotel. 2.2 Product Functions Login Allows users with different profiles to login to the system and perform their desired functions. Reservation Allows for typing in customer information Has a default room rate that is adjustable Includes a description field for the changed rate When a customer checks in, the room number will be changed to occupied in the database Ability to modify a reservation When no rooms are available and a customer would like to extend their reservation their information will be placed in a database and when there are rooms available the first customer on the list will have the room When a customer checks out the amount owed is displayed If the internal clock states that is a customers time to have checked out and customer has not checked out, adds an extra night to amount owed and provides a report Records that room is vacant Records payment Allows for space to write customers feedback Catering Tracks all meals purchased Charges the current room as necessary General Management Services Querying room occupancy statistics Allows addition, deletion and modification of information on rooms and rates, menu items and prices, user profiles Registration of frequent customers 2.3 User Characteristics

There are essentially three profiles of users for the HAS: The booking clerk who will use it for reservation of customer related functions, Catering service representative who will use it to update meal records of customers and finally managers who will be administrators and will carry out various General Managerial Services like revision of room/meal rates etc. 3. Specific Requirements This section contains all the software requirements at a level of detail, that when combined with the system context diagram, use cases, and use case descriptions, is sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. 3.1 External Interfaces The Hotel Management System will use the standard input/output devices for a personal computer. This includes the following: Keyboard Mouse Monitor Printer 3.1.1 User Interfaces The User Interface Screens are described in table 1. Table 1: Hotel Management User Interface Screens Screen Name Description Login Log into the system as a Booking Clerk or Catering Service Manager or Manager Enquiry Check room Availability, Tariffs. Check-in Check-in customer (with or without a reservation), Modify room stay Checkout Checkout customer, generate bill Payment Accept payment for room and food Catering Add meals consumed, generate meal charges Administer Rooms Query Room occupancy statistics, revise room tariffs Administer Meals Create, modify, and delete meal items and prices Frequent customers Register Frequent customers/update details 3.1.2 Software Interfaces The system shall interface with an Oracle11g database. These databases include hotel rooms, customers details, meal menu, frequent customer. These can be modified by the end users. The room database will include the room numbers and if they are vacant or occupied. The customers details database will contain all the information of the customer such as first name, last name, number of occupants, assigned room, default room rate(may be changed), phone number, whether or not the room is guaranteed, credit card number, confirmation number, automatic cancellation date, expected check in date and time, actual check in date and time, expected check out date and time, amount owed by customer, and abbreviated customer feedback. The meal menu database will contain details of various food items available and corresponding rates. The Frequent customer database will include all customer personal like name, address, contact number etc along with a identification number. 3.1.3 Hardware Interfaces The system shall run on a Microsoft Windows based system.

3.1.4 Communication Interfaces The system shall be a standalone product that does not require any communication interfaces. 3.2 Functional Requirements Functional requirements define the fundamental actions that system must perform. The functional requirements for the system are divided into four main categories, Login, Reservation, Food, and Management. For further details, refer to the use cases. R.1 Login Input: User name and password Processing: Password Validation Output: Window corresponding to Next function is opened if password is valid. If password is invalid error message is displayed and user is asked to re-enter the password/user name. Next Function: R.2. if password is valid and username profile = Booking Clerk R.3. if password is valid and username profile = Catering Service Representative R.4. if password is valid and username profile = Manager R.1. if password is invalid R.2. Reservation Description This function would cater for all day to day booking related requirements like to querying about availability of rooms, booking of rooms, checkin/checkout of customers. R.2.1. Check Availability Input: Type of room Processing: Query room database and return available rooms Output: Room nos., if available. If rooms are not available apology message will be displayed. Next Function: R.2.2 R.2.2 Check Tariff Input: Type of room Processing: Query room database and return queried rooms tariff Output: Current applicable tariff Next Function: R.2.3 R.2.3. Checkin Input: Customer details, approx. duration of stay, type of room, checkin date and time. Processing: Allocate a room no. and update room occupancy status as occupied for the duration of stay. Allot Unique TOKEN No. for customer and update in customer database. Output: Allotted Room no. and Token no. Next Function: R.2.5 Constraint: In case of advance booking, the reservation will be automatically cancelled if payment is not made before checkin time+1 hour. R.2.4. Checkout Input: Token No. Processing: Calculate total amount due from customer and update in customer database. This includes (a) Room Tariff (b) Catering Charges (c) Taxes. Update room occupancy status as vacant.

Output: Bill indicating total amount due from customer. Next Function: R.2.5 R.2.5. Payment Input: Token No., payment mode, amount. Processing: Update customer dues in customer data base. Output: Generate payment receipt and display pending dues. R.3. Catering Input: Quantity and type of food, token no. Processing: Update catering details to customer record with date and time and update catering charges to customer dues. Output: Acknowledgement. R.4. Management This function allows the manager to carry out General Management Services. This function can be invoked only if logged in as manager profile. R.4.1. Register Frequent customers Input: Customer details Processing: Add customer to Frequent customer database. Output: Identity Number. R.4.2. Query Room Occupancy Input: Room No./Room type/All, duration (from date-to date, month) Processing: Calculate the occupancy rate as follows: (a) Room No.: (b)Room type: (c) All:

Specified duration: (a) For month, duration = 30 days (b)For from date-to date, duration = to date from date. Output: Average occupancy rate in days R.4.3 Revise Room Tariff Input: Room No./Room type/All, Up/Down,% Processing: Update room tariff in room database Output: Display updated tariffs. R.4.4. Add/Delete/Modify food item/rates Input: Item Description, rate. Processing: Add/Delete/Modify food item/rates in food database Output: Display updated menu. 3.3 Purchased Components It is presumed that the PCs on which the software is targeted will be running on Windows Operating System hence the same will not be provided. The database software (Oracle 11g) will be purchased and necessary licensing documents will be provided.

You might also like