Experiment No: 1: Purpose The Software Requirements Specification (SRS) Will Provide A Detailed Description
Experiment No: 1: Purpose The Software Requirements Specification (SRS) Will Provide A Detailed Description
Experiment No: 1: Purpose The Software Requirements Specification (SRS) Will Provide A Detailed Description
Introduction
The following subsections of the Software Requirements Specifications (SRS) document provide an
overview of the entire SRS.
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.
Scope
The software product to be produced is a Hotel Management System which will automate the major
hotel operations. This system is a Reservation and Booking System to keep track of reservations
and room availability. There is one end user for the HMS. The end user is the hotel staff (customer
service representative) who can access the Reservation and Booking System.
The Hotel Management Systems objective 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.
Product Perspective
The HMS is an independent standalone system. It is totally self contained.
Hardware Interfaces
The HMS will be placed on PCs throughout the hotel.
Software Interfaces
All databases for the HMS will be configured using Oracle /SQL/Access. 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.
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 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
User Characteristics
Educational level of HMS computer software Low
Experience of HMS software None
Technical Expertise Little
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
er Interfaces
The User Interface Screens are described in table 1.
Table : 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
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
Software Interfaces
The system shall interface with an Oracle or Access database.
Hardware Interfaces
The system shall run on a Microsoft Windows based system.
Communication Interfaces
The system shall be a standalone product that does not require any communication interfaces.
Functional Requirements
Functional requirements define the fundamental actions that system must perform.
The functional requirements for the Reservation/Booking System. 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 customers first name.
1.3. The system shall record the customers 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 customers 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 information.
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.
Nonfunctional Requirements
Functional requirements define the needs in terms of performance, logical database requirements,
design constraints, standards compliance, reliability, availability, security, maintainability, and
portability.
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.
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
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.
Standards Compliance
There shall be consistency in variable names within the system. The graphical user interface
shall have a consistent look and feel.
Reliability
Specify the factors required to establish the required reliability of the software system at time of
delivery.
Availability
The system shall be available during normal hotel operating hours.
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. Managers
will also have access to the Management subsystem as well as the Reservation/Booking. Access to
the systems will be protected by a user log in screen that requires a user name and password.
Maintainability
The Hotel Management System is being developed in Java. Java is an object oriented programming
language and shall be easy to maintain.
Portability
The Hotel Management System shall run in any Microsoft Windows environment that contains Java
Runtime and the Microsoft Access database.
Supporting Information
A system context diagram as well as use cases and use case descriptions have been developed in
separate documents.
Conclusion:
7. What is Purpose?
------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
EXPERIMENT NO: 2
Name of the Student :-__________________________________________________
Roll No.____________ Subject:-_______________________
Date of Practical Performed :-___________ Staff Signature with Date
& Marks
TITLE: Prepare DFD , ER Diagram, sequence diagram for assigned Project
Aim: Draw DFD for project
Theory: A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. Often they are a preliminary step used to create
an overview of the system which can later be elaborated.[