You are on page 1of 13

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. Other Nonfunctional Requirements.......................................................................................7
4.1 Performance Requirements............................................................................................................7
4.2 Safety Requirements......................................................................................................................7
4.3 Security Requirements...................................................................................................................7
4.4 Software Quality Attributes...........................................................................................................7
5. Other Requirements...................................................................……………………………..7
6. 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 considerable amount through the automated system.
The system will be able to handle many services to take care of all

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


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

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

3.1 Order Management:


Input:- The order management system should allow customers to place orders through
various channels like mobile app and web portal. The system should also enable the
restaurant staff to manage orders, update order status, and send notifications to
customers about order updates.

Output:-The system should be able to manage and process customer orders efficiently.

3.2 Table Management:


Input:-The system should allow restaurant staff to manage tables and reservations.It
should enable staff to assign tables to customers, track table status, and manage
waiting lists.

Output:-

3.3 Menu Management:


Input:- The system should enable the restaurant to manage the menu, update prices,
add or remove items, and change descriptions. The system should also allow the
restaurant to offer special deals, discounts, and promotions.

Output:-

3.4 Payment Processing:


Input:- The system should allow customers to make payments through various modes
like cash, credit card, or mobile payments.It should also enable the restaurant to
process payments, generate receipts, and manage refunds.

Output:-

3.5 Inventory Management:


Input:-The system should help the restaurant manage its inventory, track stock levels,
and generate purchase orders. It should also enable the restaurant to manage its
suppliers and maintain supplier information.

Output:-

3.6 Reporting and Analytics:


Input:- The system should provide reporting and analytics features that help the
restaurant monitor performance, identify trends, and make data-driven decisions. The
system should provide reports on sales, inventory, customer feedback, and other key
metrics.

Output:-

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


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

3.9 Customer Feedback:


Input:- The system should allow customers to provide feedback on their dining
experience. The system should enable the restaurant to analyze feedback, identify
areas for improvement, and take action to improve the customer experience.

Output:-

3.10 Security and Privacy:


Input:-The system should ensure the security and privacy of customer data. The
system should be designed to protect customer data from unauthorized access, theft,
or loss. It should also comply with industry standards for data privacy and security.

Output:-

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>

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


10
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


11
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


12
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


13

You might also like