A

SRS
REPORT
on
Hotel Management System
Submitted
In partial fulfillment
For the award of the degree of
Bachelor of Computer Application

Submitted To: Submitted By:

Dr. Vaibhav Sharma Sir Kshitij Soni
(2242114)

Department of Computer Science

S.S JAIN SUBODH P.G (AUTONOMUS) COLLEGE

Affiliated to

University of Rajasthan,Jaipur

B.C.A

ACKNOWLEDGMENT

Presenting the report of the project work completed during the B.C.A. final year brings me tremendous

joy. For his unwavering support and direction during my work, I am especially grateful to my project

coordinator, Dr. VAIBHAV SHARMA SIR of the Department of Computer Science at S.S. JAIN SUBODH

(AUTONOMUS), Jaipur. Only because of his conscious efforts have my efforts been successful.
I would also want to take this occasion to thank Dr. Vaibhav Sharma Sir for his entire support

and assistance during the project's development, as well as Prof. K.B. Sharma, the principal of

S.S. JAIN SUBODH (AUTONOMUS), Jaipur for his contributions.

Additionally, I would prefer not to pass up the chance to thank the department's faculty for

their kind assistance and cooperation in helping me with my final project.

Last but not the least, I acknowledge my friends for their contribution in the completion of the

project.

Kshitij Soni

(2242114)

DECLARATION

I so certify that I completed this project work in 2023–24 under the

direction of VAIBHAV SIR, Department of Computer Science, S.S.
JAIN SUBODH (AUTONOMUS), Jaipur, in partial fulfillment of the
requirements for the college's Bachelor in Computer Application degree.

I also declare that this project is an output of my own work and that I
haven't submitted it to another university in order to receive a degree.

DATE:
Kshitij Soni
(2242114)

Table of Contents

1 Introduction…………………………………………………………………
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations.
1.4 Overview.

2 The Overall Description.……………………………………………………

2.1 Product Perspective
2.1.1 Hardware Interfaces
2.1.2 Software Interfaces
2.2 Product Functions
2.3 User Characteristics
2.4 Apportioning of Requirements.
2.5 Assumptions and Dependencies
3 Specific Requirements…………………………………...........................
3.1 External Interfaces
3.1.1 User Interfaces
3.1.1.1 Data Requirements
3.1.2 Software Interfaces
3.1.3 Hardware Interfaces
3.1.4 Communication Interfaces
3.1.5 Technologies Used
3.2 Functional Requirements
3.3 Non Functional Requirements
3.3.1 Performance Requirements
3.3.2 Logical Database Requirements
3.3.4 Standards Compliance
3.3.5 Software System Attributes

4 Data Flow Diagram ..................................................................................

4.1 Zero Level

4.2 First Level

4.3 Second Level

5 Test Case ....................................................................................................

5.1 Introduction

5.2 System Testing

5.3Unit Testing

5.4 Integration Testing

5.5 Validation Testing

5.6 Output Testing

5.7 User Acceptance Testing

1. Introduction
An overview of the whole Software Requirements Specifications (SRS) document can be found
in the following subsections.
1.1 Purpose
The Software Requirements Specification (SRS) will provide a detailed description
According to the specifications for the Hotel Management System (HMS).An in-depth grasp of
the specifications for the HMS construction will be possible thanks to this SRS. The proper
software can be built for the end user and will be utilized in the creation of the project's
subsequent stages if the HMS and its capabilities are clearly understood. The foundation of the
project will be provided by this SRS. Design, construction, and testing of the HMS can be done
using this SRS.

Both the hotel end users and the software engineers building the HMS will use this SRS. In order
to create the proper software, the software engineers will use the SRS to completely comprehend
the requirements of this HMS. This SRS will serve as a "test" for the hotel end users to determine
whether the software engineers are building the system to their specifications. If the end users are
not satisfied, they can explain why it is not to their satisfaction, and the software engineers will
modify the SRS to meet their requirements.

1.2 Scope
The principal Hotel processes will be automated by the software solution, which is a Hotel
Management System. The initial subsystem is to maintain a log of the rooms.
Of the available room and the reserved date. Billing and customer record keeping are handled by
the second subsystem. Keeping track of sales, suppliers, and earnings and losses constitutes the
third subsystem. The functionality of these three subsystems will be covered in depth in section
2-Overall Description.
For the HMS, there are two end users. The customar members and the hotel manager are the end
users.

It is the complete hotel management software is so designed as to ease the work load of medical
shop professionals. The main feature includes invoicing, maintain a log of the rooms, accounting,
client and vendor management

This software helps you to track all the profits, loss, profitable clients and products of hotel
moreover it's a hotel accounting software. Flexible and adaptive software suited to hotel of any
size.
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
There are two primary sections to the SRS. The general description comes first, followed by the
specific requirements. The HMS requirements will be covered in general, high-level detail in the
Overall Description. The system requirements will be covered in detail in the section on specific
requirements.
2 The Overall Description
outlines the broad influences on the product and its needs. No particular requirements are
mentioned in this section. Rather, it makes those requirements more understandable by giving
them some context, which is specified in section 3.

2.1 Product Perspective

The HMS is a Wab Applicartion.

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 MS Access. These databases include maintain a log
of the rooms,customers information and their billing. These can be modified by the end users. The room
database will include the number of the available room and the reserved date. The customers
information database will contain all information of the customer such as first name, last name phone
number Id, number of room booked, details of rooms, total amount, mode of payment(cash/debit or
credit card)

2.2 Product Functions

Hotel Record Management System
• Customer Registration
• Check for Availability of Rooms
• Display the Rate
• Confirmation Of Booking
• Email Notification
 • Payment
• Set Room Details
• Manage Booking Details
• Generate Report
• Customer Servies
Customer information and Billing System
• Keeps track of the customer information.
• Billing is done with their proper record.

Sale Management System

• Keep track of the profit and losses of the hotel.
• Keep record of the sales of hotel.
• Complete record of all the purchases is maintained.

2.3 User Characteristics

There are 3 user levels in our Hotel Management
• Hotel manager
• Receptionist
• Customer

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 Requirements

3.1.1 User Interfaces
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 bil
Hotel Payment Accept payment for room and food
Room Service/Restaurant Create order, modify order, view order, cancel order,
generate meal bill
Screen Name Description
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

Data Requirements
The logical database requirements include the retention of the following data elements.

This list is not a cornplete list and is designed as a starting point for development.

• Booking/Reservation System

• Customer 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

3.1.2 Software Interfaces

User on Internet : Wab Browser(any)

Application Server : WAS

Data Base Server : DB2

Network : Internet
 Development Tools : PHP, HTML, OS(windows)
3.1.3 Hardware Interfaces
Processor : Pentium IV or higher

RAM : 1 GB or more

Disk Space : more then 40 GB

3.1.4 Communication Interfaces
Client on Internet will be using HTTP/HTTPS protocol.

Client on Intranet will be using TCP/IP protocol

A Web Browser such as IE 6.0 or equivalent

TECHNOLOGIES USED
Technology Description

IDE VS Code
 Languages HTML, JavaScript ,CSS ,PHP

Recommended Google Chrome,

Browser Microsoft Edge

Operating System Windows 10,8,7,XP

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, Rooms, Customer
information and billing, Staff and Sale and supplier info. For further details, refer to the use cases.

1. Medicine Stock
1.1. The system shall record stock of medicines.
1.2. The system shall be updated with arrival of new stock.
1.3. The system shall notify the expired stock of medicines.
1.4. The system shall keep record of medicine details,

2. Customer info and billing

2.1. The system will display the customer info.
 2.2. The system will generate the bill.
2.3. The system shall store the customer information.
2.4. The system shall keep record of the billing.

3. Staff
3.1. The system shall store the staff information.
3.2. The system will display the staff information.
3.3. The system shall keep record of the staff salary.

3. Sale and supplier info

3.1. The system shall display the supplier information and update it from time to time.
3.2. The system shall display the number of sale with record of profit and losses.

3.3 Non Functional 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 ten 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.
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.

Software System Attributes

• Correctness: This system should satisfy the normal regular Hotel Management

operations precisely to fulfill the end user objectives

• Availability: The system shall be available during normal hotel operating hours

• Reusability: Specify the factors required to use the available component of the available

components of the system in other system as well.

• Efficiency: Enough resources to be implemented to achieve the particular task efficiently

without any hassle.

• Flexibility: System should be flexible enough to provide space to add new features and to

handle them conveniently

• Integrity: System should focus on securing the customer information and avoid data
losses as much as possible

• Portability: The system should run in any Microsoft windows environment.

• Usability: The system should provide user manual to every level of users.

• Testability: The system should be able to be tested to confinn the performance and

clients specifications.

• Maintainability: The system should be maintainable.

• Zero Level DFD

• First Level DFD

 • Second Level DFD

TEST CASES

AIM:- Test cases for Hotel Management System.

5.1 Introduction:
Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and coding. Testing presents an interesting of a system using
various test data. Preparation of the test data plays a vital role in the system testing. After
preparation the test data, the system under study is tested those test data. Errors were found and
corrected by using the following testing steps and corrections are recorded for future references.
Thus, series of testing is performed on the system before it is already for implementation.
The development of software systems involves a series of production activities where
opportunities for injection of human errors are enormous. Errors may begin to occur at the very
inception of the process where the objectives may be erroneously or imperfectly specified as well
as in later design and development stages. Because of human in ability to perform and
communicate with perfection, software development is followed by assurance activities.
Quality assurance is the review of software products and related documentation for
completeness, correctness, reliability and maintainability. And of course it includes assurances
that the system meets the specification and the requirements for its intended use and
performance. The various levels of quality assurance are described in the following sub sections.
5.2 System Testing
Software testing is a critical element of software quality assurance and represents the ultimate
review of specifications, design and coding. The testing phase involves the testing of system
using various test data; Preparation of test data plays a vital role in the system testing. After
preparation the test data, the system under study is tested.
Those test data, errors were found and corrected by following testing steps and corrections are
recorded for future references. Thus a series testing is performed on the system before it is ready
for implementation.
The various types of testing on the system are:
• Unit testing
 • Integrated testing
• Validation testing
• Output testing
• User acceptance testing

5.3 Unit testing

Unit testing focuses on verification effort on the smallest unit of software design module. Using
the unit test plans. Prepared in the design phase of the system as a guide, important control paths
are tested to uncover errors within the boundary of the modules. The interfaces of each of the
modules under consideration are also tested. Boundary conditions were checked.

All independent paths were exercised to ensure that all statements in the module are executed at
least once and all error-handling paths were tested. Each unit was thoroughly tested to check if it
might fall in any possible situation. This testing was carried out during the programming itself.
At the end of this testing phase, each unit was found to be working satisfactorily, as regarded to
the expected out from the module.

5.4 Integration Testing

Data can be across an interface one module can have an adverse effect on another's sub function,
when combined may not produce the desired major function; global data structures can present
problems. Integration testing is a symmetric technique for constructing tests to uncover errors
associated with the interface. All modules are combined in this testing step. Then the entire
program was tested as a whole.

5.5 Validation Testing

At the culmination of integration testing, software is completely assembled as a package.
Interfacing errors have been uncovered and corrected and final series of sof of software test-
validation testing begins. Validation testing can be defined in many ways, but a simple definition
is that validation succeeds when the software functions in manner that is reasonably expected by
the consumer. Software validation is achieved through a series of black box tests that
demonstrate conformity with requirement. After validation test has been conducted, one of two
conditions exists.
• The function or performance characteristics confirm to specification that are accepted.
• A validation from specification is uncovered and a deficiency created.
Deviation or errors discovered at this step in this project is corrected prior to completion
of the project with the help of user by negotiating to establish a method for resolving
deficiencies. Thus the proposed system under consideration has been tested by using validation
testing and found to be working satisfactorily.
5.6 Output Testing
After performing the validation testing, the next step is output testing of the proposed system,
since a system is useful if it does snot produce the required output in the specific format required
by them tests the output generator displayed on the system under consideration. Here the output
is considered in two ways: one is onscreen and the other is printed format. The output format on
the screen is found to be correct as the format was designed in the system design phase according
to the user needs. As far as hardcopies are considered it goes in terms with the user requirement.
Hence output testing does not result any correction int the system.

5.7 User Acceptance Testing

User acceptance of the system is a key factor for success of any system. The system under
consideration is tested for user acceptance by constantly keeping in touch with prospective
system and user at the time of developing and making changes whenever required