Hotel Management
System
Table
of Contents
1 Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions,
Acronyms, and Abbreviations. 5
1.4 Overview 5
2 The
Overall Description 5
2.1 Product
Perspective 5
2.1.1 Hardware
Interfaces 5
2.1.2 Software
Interfaces 5
2.2 Product
Functions 5
2.3 User
Characteristics 6
2.4 Apportioning
of Requirements. 6
2.5
Assumptions and Dependencies 6
3 Specific
Requirements 7
3.1 External
Interfaces 7
3.1.1 User
Interfaces 7
3.1.2 Software
Interfaces 7
3.1.3 Hardware
Interfaces 7
3.1.4 Communication
Interfaces 8
3.2 Functional
Requirements 8
3.3 Nonfunctional
Requirements 100
3.3.1 Performance
Requirements 100
3.3.2 Logical
Database Requirements 100
3.3.3 Design
Constraints 111
3.3.4 Standards
Compliance 111
3.3.5 Reliability 111
3.3.6 Availability 111
3.3.7 Security 111
3.3.8 Maintainability 11
3.3.9 Portability 111
4 Change
Management Process 122
5 Document
Approvals 122
5.1 Team One
Approval 122
5.2 Team Two
Approval 122
6 Supporting
Information 122
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
Management System (HMS). This SRS will
allow for a complete understanding of what is to be expected of the HMS to be
constructed. The clear understanding of the HMS 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 HMS can be designed,
constructed, and finally tested.
This SRS
will be used by the software engineers constructing the HMS and the hotel end
users. The software engineers will use
the SRS to fully understand the expectations of this HMS 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 Management System which will
automate the major hotel operations. The first subsystem is a Reservation and
Booking System to keep track of reservations and room availability. The second subsystem is the Tracking and
Selling Food System that charges the current room. The third subsystem is a General Management
Services and Automated Tasks System which generates reports to audit all hotel
operations and allows modification of subsystem information. These three subsystems’ functionality will be
described in detail in section 2-Overall Description.
There are two en users for the HMS. The end users are the hotel staff (customer
service representative) and hotel managers.
Both user types can access the Reservation and Booking System and the
Food Tracking and Selling System. The
General Management System will be restricted to management users.
The Hotel
Management System’s objectives is to provide a system to manage a hotel that
has increased in size to a total of 100 rooms.
Without automation the management of the hotel has become an unwieldy
task. The end users’ day-to-day jobs of
managing a hotel will be simplified by a considerable amount through the
automated system. The system will be
able to handle many services to take care of all customers in a quick manner. The system should be user appropriate, easy
to use, provide easy recovery of errors and have an overall end user high
subjective satisfaction.
1.3 Definitions, Acronyms, and Abbreviations.
SRS – Software
Requirements Specification
HMS – Hotel Management
System
Subjective satisfaction –
The overall satisfaction of the system
End users –
The people who will be actually using the system
1.4 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 HMS from a general
high level perspective. The Specific
Requirements section will describe in detail the requirements of the system.
2 The Overall Description
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 HMS is
an independent stand–alone system. It is
totally self contained.
2.1.1
Hardware Interfaces
The HMS will be placed on PC’s throughout
the hotel.
2.1.2 Software Interfaces
All databases for the HMS will be
configured using Oracle 8i. These
databases include hotel rooms and customers information. 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 information 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.
2.2 Product Functions
Reservation and Booking System
·
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 customer’s 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 customer’s feedback
Tracking and Selling Food System
·
Tracks all
meals purchased
·
Charges
the current room as necessary
General Management Services and Automated
Tasks System
·
Reports
generated to audit hotel occupancy, future occupancy, room revenue, and food
revenue
·
Exception
reports listing exceptions to the normal cost
·
Allows
addition, deletion and modification of information on rooms and rates, menu
items and prices, user profiles
·
Creation
of users and assigning passwords
2.3 User Characteristics
Educational level of HMS computer software
– Low
Experience of HMS software – None
Technical
Expertise – Little
2.4 Apportioning of Requirements
The audio and visual alerts will be
deferred because of low importance at this time.
2.5 Assumptions and Dependencies
- The system is not required to save generated
reports.
- Credit
card payments are not included
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 CSR or Manager
|
|
Reservation
|
Retrieve button, update/save reservation, cancel
reservation, modify reservation, change reservation, adjust room rate, accept
payment type/credit card
|
|
Check-in
|
Modify room stay (e.g., new credit card), check-in
customer (with or without a reservation), adjust room rate, special requests,
accept payment type/credit card
|
|
Checkout
|
Checkout customer, generate bill
|
|
Hotel Payment
|
Accept payment for room and food
|
|
Room Service/Restaurant
|
Create order, modify order, view order, cancel
order, generate meal bill
|
|
Customer Record
|
Add or update customer records
|
|
Administer Rooms
|
Availability and rates
|
|
Administer User
|
Create, modify, and delete users; change password
|
|
Administer Meals
|
Create, modify, and delete meal items and prices
|
|
Reports
|
Select, view, save, and delete reports
|
3.1.2 Software Interfaces
The system shall interface with an Oracle
or Access database.
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 three main categories, Reservation/Booking, Food, and
Management. For further details, refer to the use cases.
1.
Reservation/Booking
1.1.The system shall record reservations.
1.2.The system shall record the customer’s first
name.
1.3.The system shall record the customer’s last
name.
1.4.The system shall record the number of
occupants.
1.5.The system shall record the room number.
1.6.The system shall display the default room rate.
1.6.1.
The system
shall allow the default room rate to be changed.
1.6.2.
The system
shall require a comment to be entered, describing the reason for changing the
default room rate.
1.7.The system shall record the customer’s phone
number.
1.8.The system shall display whether or not the
room is guaranteed.
1.9.The system shall generate a unique confirmation
number for each reservation.
1.10.
The system
shall automatically cancel non-guaranteed reservations if the customer has not
provided their credit card number by 6:00 pm on the check-in date.
1.11.
The system
shall record the expected check-in date and time.
1.12.
The system
shall record the expected checkout date and time.
1.13.
The system
shall check-in customers.
1.14.
The system
shall allow reservations to be modified without having to reenter all the
customer inforamtion.
1.15.
The system
shall checkout customers.
1.15.1.
The system
shall display the amount owed by the customer.
1.15.2.
To
retrieve customer information the last name or room number shall be used
1.15.3.
The system
shall record that the room is empty.
1.15.4.
The system
shall record the payment.
1.15.5.
The system
shall record the payment type.
1.16.
The system
shall charge the customer for an extra night if they checkout after 11:00 a.m.
1.17.
The system
shall mark guaranteed rooms as “must pay” after 6:00 pm on the check-in date.
1.18.
The system
shall record customer feedback.
2.
Food
2.1.The system shall track all meals purchased in
the hotel (restaurant and room service).
2.2.The system shall record payment and payment
type for meals.
2.3.The system shall bill the current room if payment
is not made at time of service.
2.4.The system shall accept reservations for the
restaurant and room service.
3.
Management
3.1.The system shall display the hotel occupancy
for a specified period of time (days; including past, present, and future
dates).
3.2.The system shall display projected occupancy
for a period of time (days).
3.3.The system shall display room revenue for a
specified period of time (days).
3.4.The system shall display food revenue for a
specified period of time (days).
3.5.The system shall display an exception report,
showing where default room and food prices have been overridden.
3.6.The system shall allow for the addition of
information, regarding rooms, rates, menu items, prices, and user profiles.
3.7.The system shall allow for the deletion of
information, regarding rooms, rates, menu items, prices, and user profiles.
3.8.The system shall allow for the modification of
information, regarding rooms, rates, menu items, prices, and user profiles.
3.9.The system shall allow managers to assign user
passwords.
3.3 Nonfunctional Requirements
Functional requirements define the needs in
terms of performance, logical database requirements, design constraints,
standards compliance, reliability, availability, security, maintainability, and
portability.
3.3.1 Performance Requirements
Performance
requirements define acceptable response times for system functionality.
- The load time for user interface screens shall take no longer than two seconds.
- The log in information shall be verified within five seconds.
- Queries shall return results within five seconds.
3.3.2 Logical Database Requirements
The logical database requirements include
the retention of the following data elements. This list is not a complete list
and is designed as a starting point for development.
Booking
/Reservation System
- Customer first name
- Customer last name
- Customer address
- Customer phone number
- Number of occupants
- Assigned room
- Default room rate
- Rate description
- Guaranteed room (yes/no)
- Credit card number
- Confirmation number
- Automatic cancellation date
- Expected check-in date
- Expected check-in time
- Actual check-in date
- Actual check-in time
- Expected check-out date
- Expected check-out time
- Actual check-out date
- Actual check-out time
- Customer feedback
- Payment received (yes/no)
- Payment type
- Total Bill
Food Services
·
Meal
- Meal type
- Meal item
- Meal order
- Meal payment (Bill to room/Credit/Check/Cash)
3.3.3 Design Constraints
The Hotel
Management System shall be a stand-alone system running in a Windows
environment. The system shall be developed using Java and an Access or Oracle
database.
3.3.4 Standards Compliance
There shall be consistency in variable names within the system. The
graphical user interface shall have a consistent look and feel.
3.3.5 Reliability
Specify the factors required to establish
the required reliability of the software system at time of delivery.
3.3.6 Availability
The system shall be available during normal
hotel operating hours.
3.3.7 Security
Customer Service Representatives and
Managers will be able to log in to the Hotel Management System. Customer
Service Representatives will have access to the Reservation/Booking and Food
subsystems. Managers will have access to the Management subsystem as well as
the Reservation/Booking and Food subsystems. Access to the various subsystems
will be protected by a user log in screen that requires a user name and
password.
3.3.8 Maintainability
The Hotel Management System is being
developed in Java. Java is an object oriented programming language and shall be
easy to maintain.
3.3.9 Portability
The Hotel
Management System shall run in any Microsoft Windows environment that contains
Java Runtime and the Microsoft Access database.
4 Change Management Process
Changes to
this document may be made after approval from the project manager and the
client approval officer.
5 Document Approvals
5.1 Team One Approval
________________________ ____________
Sandra Busik/Reita Sikka Date
5.2 Team Two Approval
________________________ ____________
Lisa Ferrett
Date
6 Supporting Information
A system
context diagram as well as use cases and use case descriptions have been
developed in separate documents.
إرسال تعليق