Software Requirements Specification

for

Restaurant Automation System

Prepared by :

Soumyashree Parida
Rashmi Kanta Das

date :17:03:2023
Table of Contents:
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................... ……………………………..4
1. Introduction ..............................................................................................................................4
1.1 Purpose...................................................................................................................................... 4
1.2 References ................................................................................................................................. 4
2. Overall Description ..................................................................................................................4
2.1 User Classes and Characteristics ................................................................................................ 4
2.2 Operating Environment .............................................................................................................. 5
2.3 Design and Implementation Constraints ..................................................................................... 5
2.4 Assumptions and Dependencies ................................................................................................. 5
3. External Interface Requirements ...........................................................................................5
3.1 User Interfaces........................................................................................................................... 5
3.2 Hardware Interfaces ................................................................................................................... 6
3.3 Software Interfaces .................................................................................................................... 6
3.4 Communications Interfaces ........................................................................................................ 6
4. System Use Cases ....................................................................... ……………………………..6
4.1 Use case name and identifier ....................................................... ………………………………..6
4.2 Withdraw money from ATM (U2) .............................................. ………………………………..6
4.3 Deposit money into ATM (U3) .................................................. ………………………………..6
5. Other Nonfunctional Requirements .......................................................................................7
5.1 Performance Requirements ........................................................................................................ 7
5.2 Safety Requirements .................................................................................................................. 7
5.3 Security Requirements ............................................................................................................... 7
5.4 Software Quality Attributes ....................................................................................................... 7
6. Other Requirements .................................................................. ……………………………..7
7. System Requirements Chart ..................................................... ……………………………..7
Appendix A: Analysis Models .......................................................................................................7
Appendix B: To Be Determined List ............................................................................................8
Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

CHANGE HISTORY

DATE SECTION CHANGED CHANGE DESCRIPTION

10.03.2023 All Sections Initial version of SRS document

17.03.2023 Functional & Non-functional Incorporated feedbacks given by Prof A. K.

Requirements Behera

17.03.2023 Env. Requirement Section & Updated info on H/W & S/W platform &
Structure chart added structure chart

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 3

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

INTRODUCTION

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 Resturant Automation System (RAS). This SRS
will allow for a complete understanding of what is to be expected of the RAS
to be constructed. The clear understanding of the RAS 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 RAS can be
designed, constructed, and finally tested.
This SRS will be used by the software engineers constructing the RAS and
the resturant end users. The software engineers will use the SRS to fully
understand the expectations of this RAS to construct the appropriate
software. The resturant 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 Project Scope

The software product to be produced is a Resturant Automation 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 RMS. 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 Resturant Automation 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

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 4

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

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 Environmental characteristics

The product will be operating in windows environment. Also it will be compatible with
the IE 6.0 . Most of the features will be compatible with the Mozila Firefox and Opera
7.0 or higher version. The only requirement to use this online product would be the
internet connection.

1.4 Definitions, Acronyms and Abbreviations

SRS – Software Requirements
Specification.
RAS –Resturant Automation System.
Subjective satisfaction – The overall satisfaction of
the system .
End users – The people who will be actually using
the system.

1.5 References

www.google.com -the world's information.

www.wikipedia.com -free online encyclopedia.
www.cnet.com -technology portal.
www.slideshare.net -the world's largest professional content sharing
community.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 5

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

2. 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 RAS is an independent stand–alone system. It is totally self contained.Resturant

Application System is specifically to increase efficiency of the restaurant with 3
distinct components:- 1)Transmitter
2) Recevier
3) Main Dispatcher S/W Program
Transmitter:- Whenever a Customer requires help, their request can be more
promptly answered through ue of the transmitter.
The transmitter will send a signal to the main dispatch to be forwarded to the receiver
of server.

2.2 User Classes and Characteristics

Educational level of HMS computer software – Low
Experience of HMS software – None
Technical Expertise – Little

2.3 Operating Environment

The system shall run on a Microsoft Windows based system.

2.4 Design and Implementation Constraints

There are some constraints which costs more for the system. If those constraints can
overcome then this whole system will perform best. They are-
1. IOS App and Windows App.
2. Information flow or data flow can be controled and more effective.
3. Faster server system such as LINUX server.
4. Bengali language for Bangladesh and Other language for other countries.
5. C# can be use for more security.

2.5 User documentation

It will provide specific guidelines to a user for using the Restaurant automation
system.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 6

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

3. 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
The system shall record reservations.
The system shall record the customer’s first name.
The system shall record the customer’s last name.
The system shall record the number of occupants.
The system shall record the room number.
The system shall display the default room rate.
The system shall allow the default room rate to be changed.
The system shall require a comment to be entered, describing the
reason for changing the default room rate.
The system shall record the customer’s phone number.
The system shall display whether or not the room is guaranteed.
The system shall generate a unique confirmation number for each reservation.
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.
The system shall record the expected check-in date and time.
The system shall record the expected checkout date and time.
The system shall check-in customers.
The system shall allow reservations to be modified without having to reenter
all the customer inforamtion.
The system shall checkout customers.
The system shall display the amount owed by the customer.
To retrieve customer information the last name or room number shall be used
The system shall record that the room is empty.
The system shall record the payment.
The system shall record the payment type.
The system shall charge the customer for an extra night if they
checkout after 11:00 a.m.
The system shall mark guaranteed rooms as “must pay” after 6:00
pm on the check-in date.
The system shall record customer feedback.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 7

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

2.Food
The system shall track all meals purchased in the restaurant.
The system shall record payment and payment type for meals.
The system shall bill the current room if payment is not made at time of service.
The system shall accept reservations for the restaurant and room service.

3.Management
The system shall display the hotel occupancy for a specified period of
time (days; including past, present, and future dates).
The system shall display projected occupancy for a period of time (days).
The system shall display room revenue for a specified period of time (days).
The system shall display food revenue for a specified period of time (days).
The system shall display an exception report, showing where default
room and food prices have been overridden.
The system shall allow for the addition of information, regarding rooms,
rates, menu items, prices, and user profiles.
The system shall allow for the deletion of information, regarding rooms,
rates, menu items, prices, and user profiles.
The system shall allow for the modification of information, regarding
rooms, rates, menu items, prices, and user profiles.
The system shall allow managers to assign user passwords.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 8

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

4. External Interface Requirements

4.1 User Interfaces

The User Interface Screens are described in the 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

4.2 Hardware Interfaces

The system shall run on a Microsoft Windows based system.

4.3 Software Interfaces

The system shall run on a Microsoft Windows based system.

4.4 Communications Interfaces

The system shall be a standalone product that does not require any
communication interfaces.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 9

Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

5.Other Nonfunctional Requirements

5.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.

5.2 Safety Requirements

The source code developed for this system shall be maintained in configuration
management tool.

5.3 Security Requirements

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.

5.4 Software Quality Attributes

Software quality attributes are the characteristics of a software system that
determine its overall quality and effectiveness.Those attributes are:- Reliability,
Scalability, Security, Usability, Performance, Maintainability, Compatibility,
Portability etc.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 10

 Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

Appendix A: Analysis Models

To create an analysis model for an SRS (Software Requirements
Specification) of a restaurant automation system, we need to follow certain
steps:

1. Requirements Gathering: In this step, we need to gather all the

requirements from the stakeholders of the restaurant automation system.
We can conduct interviews, surveys, and meetings with the stakeholders
to understand their needs.

2. Use Case Diagram: After gathering the requirements, we need to create a

use case diagram to understand the system's functionalities. This diagram
will help us to identify the different actors and their roles in the system.

3. Activity Diagram: We need to create an activity diagram to represent the

workflow of the system. This diagram will help us to understand how the
different components of the system interact with each other.

4. Class Diagram: We need to create a class diagram to represent the

system's objects and their relationships. This diagram will help us to
understand the system's data model.

5. Sequence Diagram: We need to create a sequence diagram to represent

the interactions between the different components of the system. This
diagram will help us to understand how the system responds to different
user actions.

6. State Diagram: We need to create a state diagram to represent the

different states of the system. This diagram will help us to understand how
the system transitions between different states based on the user's
actions.

7. Data Flow Diagram: We need to create a data flow diagram to represent

the flow of data between different components of the system. This diagram
will help us to understand how data is processed within the system.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 11

 Mar 17 ,2023 SRS DOCUMENT FOR <RESTAURANT AUTOMATION SYSTEM>

Appendix B: To Be Determined List

1. Hardware and Software Requirements: The specific hardware and software
requirements needed to run the system may still need to be determined, including
the minimum system specifications required for the system to operate effectively.

2. Payment and Ordering Options: The specific payment and ordering options that the
system will support may still need to be determined. This could include options such
as credit card processing, online ordering, and mobile payments.

3. Reporting and Analytics: The specific reporting and analytics features that the
system will include may still need to be determined. This could include the ability to
generate sales reports, track inventory levels, and monitor customer feedback.

4. Integration with Other Systems: The specific third-party systems or software that
the system will integrate with may still need to be determined. This could include
integrations with point of sale (POS) systems, accounting software, and customer
relationship management (CRM) systems.

5. Data Backup and Recovery: The specific data backup and recovery protocols that
the system will use may still need to be determined. This could include how often
data is backed up, where it is stored, and how it can be restored in the event of a
system failure.

6. Customer Support: The specific customer support channels and options that will be
available for the system may still need to be determined. This could include options
such as phone support, email support, and live chat support.

7. Regulatory Compliance: The specific regulatory requirements that the system must
comply with may still need to be determined, such as data protection regulations,
privacy laws, and payment processing regulations.

CONCLUSION

The SRS for the restaurant automation system provides a comprehensive overview of
the system's requirements, functionalities, and specifications. The document highlights
the key features of the system, including the user interface, system architecture,
database design, system security, performance, and usability. It also considers software
quality attributes such as reliability, scalability, maintainability, and compatibility.

Group:-A2 Names:-Soumyashree Parida , Rashmi Kanta Das Page 12