Restaurant Management System: Software Requirement Specifications

Software Requirement Specifications
RESTAURANT MANAGEMENT SYSTEM
Version: 1.1
Project Code C 01
Supervisor Ms Faiza Sattar
Co Supervisor Sir Muhammad Nadeem
Project Team Muhammad Anas

Muhammad Safi
Abdullah Siraj
Waleed Hasan
Submission Date 24/09/17

<CS491 Project-I> Software Requirements Specifications <Version 1.5>
Page 2 of 21
Document History
[Revision history will be maintained to keep a track of changes done by anyone in the document.]
Version Name of Person Date Description of change
15/09/2017 Document Created
18/10/2017 Document Revised
18/10/2017 Document Edited
22/10/2017 Document Revised
24/10/2017 Use cases added and Document Revised.
Page 3 of 21
Distribution List
[Following table will contain list of people whom the document will be distributed after every sign-off]
Name Role
Ms Faiza Sattar Supervisor
Sir Muhammad Nadeem Co- Supervisor
Page 4 of 21
Document Sign-Off
Version Sign-off Authority Sign-off Date

1.1 Sir Muhammad Nadeem
1.2
1.3
1.4
1.5
Page 5 of 21
Table of Contents
1. INTRODUCTION ...................................................................................................................................... 7
1.1. Purpose of Document .............................................................................................................. 7
1.2. Intended Audience .................................................................................................................. 7
1.3 Abbreviations ………………………………………………………………………………………...7
1.4. Document Convention ............................................................................................................. 7
2. OVERALL SYSTEM DESCRIPTION ............................................................................................................ 8
2.1. Project Background ................................................................................................................. 8
2.2. Project Scope .......................................................................................................................... 8
2.3. Not In Scope ............................................................................................................................ 9
2.4. Project Objectives ................................................................................................................... 9
2.5. Stakeholders............................................................................................................................ 9
2.6. Operating Environment ........................................................................................................... 9
2.7. System Constraints ................................................................................................................. 9
2.8. Assumptions & Dependencies .............................................................................................. 10
3. EXTERNAL INTERFACE REQUIREMENTS ................................................................................................. 11
3.1. Hardware Interfaces .............................................................................................................. 11
3.2. Software Interfaces ............................................................................................................... 11
3.3. Communications Interfaces ................................................................................................... 11
4. FUNCTIONAL REQUIREMENTS ............................................................................................................... 12
4.1. FUNCTIONAL HIERARCHY .............................................................................................................. 12
4.2. Use Cases ............................................................................................................................. 13
4.2.1. [Title of use case] .................................................................... Error! Bookmark not defined.
5. NON-FUNCTIONAL REQUIREMENTS ....................................................................................................... 18
5.1. Performance Requirements .................................................................................................. 18
5.2. Safety Requirements ............................................................................................................. 19
5.3. Security Requirements .......................................................................................................... 19
5.4. User Documentation .............................................................................................................. 19
6. REFERENCES ...................................................................................................................................... 20
7. APPENDICES ....................................................................................................................................... 21
Page 6 of 21
1. Introduction
1.1 Purpose of Document
The purpose of this document is to present detailed description of the overall system. The
document will explain the purpose and features of the system, the interface of the system,
what the system will do, the constraints under which the system should work, and the final if
the abnormal situations occurs, what the system should response.
1.2 Intended Audience

The intended audience of this documents are both the stakeholder and developers, and it will
be proposed to FYP-Jury.
1.3 Abbreviations
RMS- Restaurant Management System
1.4 Document Convention
Font: - Times New Roman
Heading Font Size: - 16 with Bold
Subheading Font Size: - 12 with Bold
Paragraph Font Size: - 12
Page 7 of 21
2 Overall System Description

2.1 Project Background
The food industry is a high-risk business proposition. You’ve got a lofty level of competition
and a lot of details to perfect.
Common problems faced by consumers when visiting restaurants which leads to
dissatisfaction;
● Poor Customer Service
● Incompetent Staff
● Great Variation in customer service between peak and off peak timings
Solution:
● An ‘Automated Ordering System’ at restaurants would enable customer’s to no longer
wait in queues when making and receiving orders.
● Benefits to restaurant would be cost and time saving, effective resource utilization.
Market Size:
● Initial research by FCP suggests Pakistani’s spend over a $1bn on dine-outs in a year
● Research further indicated there are around 2000 higher end restaurants in the leading
cities of Pakistan i.e. our target market
2.2 Project Scope
This system will help to manage and run the restaurant business systematically. In this
management system, we will provide an app that can be used by the customers to order food.
Customers can also give feedback through this app. So that owner of the restaurant can
evaluate the whole system. This will ultimately lead to hire less waiters and create an
opportunity to appoint more chefs and better kitchen place to serve food faster. Customers
can also make payment through debit or credit cards which will be integrated with the
management software. Customers can see current discount facility of the restaurant. All the
information about daily expenses and profit will be saved in the system. Also, the required
information’s about employees will be saved in the system which can be only accessed by
the system admin.
The boundaries of the system are:
a. User must have installed application.
b. Cashier must be sign in the system.
c. Restaurant must purchase the application to use.
d. User must follow the instruction guide before using the application, instruction guide
will be helpful
Page 8 of 21
The features of the system are:
2.3 Not in Scope

The system is only limited to the same-restaurant, that means that system is not supposed to
develop for the cross restaurant.
2.4 Project Objectives

This document presents a detailed explanation of the objectives, features, user interface and
application of Restaurant Management System in real life. It will also describe how the
system will perform and under which it must operate. In this document it will be also shown
user interface. Both the buyers and the developers of the system can benefit from this
document.
2.5 Stakeholders
Primary: Customer and Staff.
Secondary: Database servers and Bank Debit/credit card verification.
2.6 Operating Environment

The system requires a Mobile Handset (Android).
The system will compatible with Windows 7 and onwards.
The system requires a networking system.
2.7 System Constraints

Software constraints
Android version below 4.4 is not supported.
Windows version below 7 is not supported.
Network connection between the two interfaces is required.
Page 9 of 21
Hardware constraints
PC:
Intel core 2 duo processor
Minimum 50 MB hard drive space.
Minimum 512 MB RAM.
Mobile:
Dual core 1 GHz processor.
ROM 50 MB
RAM 1 GB
Cultural constraints (includes language etc.)
English language is used.
Legal constraints
Software must be purchased and licensed by a restaurant in order to use.
Data protection is guaranteed.
Environmental constraints
TBD
User constraints
TBD
2.8 Assumptions & Dependencies

If this system uses on kind of OS then it will be beneficial. If there are more Tablets for each
table the whole system performance will be better.
Page 10 of 21
3 External Interface Requirements

3.1 Hardware Interfaces
There are three external hardware devices used by the FOS, each related to a user interface.
These devices are the surface computers, the wireless tablets and the touch displays. All
three devices must be physically robust and immune to liquid damage and stains. The
devices (with the possible exception of displays) must also have good industrial design
aesthetics, as they are to be used in place of normal restaurant tables and notepads and will
be in direct contact with customers. The devices behave as 'terminals' in the sense that they
never have a full system image, do not store data and are not used for the core logic of the
system. However, they should be fully capable computers that can use textual data from the
server along with local UI/interpretation code to display UI elements and take input. All
order and transaction records should be stored on the server.
Required devices are: As the application is windows based, so windows based tablet pcs
Laptops or Desktops are required to make the system work.
3.2 Software Interfaces

The system should be able to communicate with the person in-charge of operations to get
update version of product specifications. The RMS will interface with a Database
Management System (DBMS) that stores the information necessary for the RMS to operate.
The DBMS must be able to provide, on request and with low latency, data concerning the
restaurant's menu, employees (and their passwords) and available dietary requirements.
Additionally, it should take and archive data provided to it by the RMS. This data will
include records of all orders and transactions (system states and state changes) executed by
the RMS. The DBMS must store all data such that it can be used for accounting, as well as
accountability.
3.3 Communications Interfaces

The RMS will interface with a Local Area Network (LAN) to maintain communication with all
its devices. It should use a reliable-type IP protocol such as TCP/IP or reliable-UDP/IP for
maximum compatibility and stability. All devices it will interface with should contain standard
Ethernet compatible, software accessible LAN cards to maintain communication between the
server and the surface computers, tablets, displays and the external payment system. Devices that
are wireless should also use Ethernet compatible cards, using the IEEE 802.11b/g standard and
having support for WPA2-PSK encryption. The use of IEEE 802.11n transmission standard
hardware is also acceptable if all other local hardware is conformant to the same standard.
Page 11 of 21
4 Functional Requirements
4.1 Functional Hierarchy
The system is decomposed into main three modules/components.
a. Client Side (User Application)
b. Cashier’s Interface
c. Kitchen’s Interface
d. Bank Authorization
Following part of the section briefly describe the above three listed modules.
1. Food order via android app
2. Order received by kitchen staff
3. Order delivered notification
4. Two possible payment methods (cash or card)
5. Instant order completion and information confirmation
6. Computerized Billing
7. System update
8. Auto save records in database
Page 12 of 21
4.2 Use Cases
Page 13 of 21
Page 14 of 21
4.2.1 Use Case :-

Use Case : Process Sale
Primary Actor: Cashier
Stakeholders and Interests: -
Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are
deducted from his/her salary. –
Customer: Wants purchase and fast service with minimal effort. Wants proof of purchase to
support returns.
Preconditions:
Cashier is identified and authenticated.
Postconditions:
Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions
recorded. Receipt is generated. Payment authorization approvals are recorded via bank
authorization system finally database is updated.
Main Success Scenario (or Basic Flow):
1. Customer arrives or send credit card via waiter to cashier.
Page 15 of 21
2. Cashier starts a new sale.

3. System records price calculated from a set of price rules.
4. System presents total with taxes calculated.
5. Customer pays and System handles payment.
6. System logs completed sale and sends sale and payment information to the external
Accounting system (for accounting and commissions) and Inventory system (to update
inventory).
9. System prints receipt.
10.Customer leaves with receipt and goods (if any).
11.Cashier updates the database.
Extensions:-
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. Invalid identifier so System signals error and rejects entry.
3. Paying by credit Customer enters their credit account information. System sends payment
authorization request to an external Payment Authorization Service System, and requests
payment approval. System detects failure to collaborate with external system System
signals error to Cashier. Cashier asks Customer for alternate payment.
4. Paying by cash System records the cash payment.
Special Requirements: -
Text must be visible from 1 meter.
Credit authorization response within 30 seconds 90% of the time.
Language internationalization on the text displayed.
4.2.2 Use Case :-

Use Case 2: Manage Order
Primary Actor:
Kitchen Staff Worker
Stakeholder and interests:
To fetch orders and add them to kitchen queue and remove completed orders from kitchen queue.
Preconditions:
Interface shows the Order Queue (with orders from customers) and the Kitchen Queue (may or
may not have orders).
Postconditions:
Order has been removed from both Queues and waiter has been notified for pick up.
Main Success Scenario:
1. Kitchen staff worker approaches screen to view and fetch orders.
2. System displays both Order Queue and Kitchen Queue, which are automatically refreshed to
account for new incoming orders. Suppose the Kitchen Queue is initially empty.
3. Kitchen staff worker presses the “Transfer to Kitchen Queue” button for each order he wants
to prepare from the Order Queue.
4. System transfers just the name of the food item to the Kitchen Queue and removes the
“Transfer to Kitchen Queue” button for each order pressed to prevent multiple clicks on the same
order.
5. Kitchen staff worker presses the “Complete” button after he/she finishes an order.
Page 16 of 21
6. System signals the waiter to pick up the order and clears the order from the Kitchen Queue
and Order Queue.
Extensions:
1. Customer cancels an order. System refreshes and the order is removed from the Order
Queue.
2. Customer attempts to cancel an order after the order has been moved to the Kitchen
Queue. System does not cancel the order because the “Delete” button in the Order Queue
is not there.
4.2.3 Use Case :-

Use Case 3: Serve Table
Primary Actor:
Waiter
To maintain servicing of different tables for customers by bringing food to customers.
Preconditions:
Waiter's interface shows status of food for his/her assigned tables.
Postconditions:
The food status becomes "Ready" to deliver to restaurant customer.
1. System displays the table numbers that the waiter is to serve, the status of the table's orders
and the table's cheque.
2. Waiter selects one of the table numbers he/she is assigned.
3. System displays the order details of the table
4. Kitchen queue reports "Order Ready" for a given table number.
5. Waiter selects the "Acknowledged" button after serving the food to table.
6. System changes the status of table to "Served".
7. System alerts waiter that table wants to pay by cash.
8. Manager alerts for the table to be cleaned.
9. System deletes the table from the list of tables to serve.
Extensions:
At any time, the staff alerts waiter to assist table. The system changes or deletes table order
details when order is in "In Order Queue" status and when table wants to add/delete their order.
4.2.4 Use Case :-

Use Case 4: Order Food
Primary Actor:
Restaurant Customer
To view the menu, select preferred items, and order the food.
Preconditions:
Tablet Screen displays main GUI with options to view men
Postconditions:
Come back to main menu or show status of food.
Page 17 of 21

1.Restaurant customer sees the table number on Main Menu and selects "View Menu" option 7-8
inch tablet.
2. System displays menu categories (drinks, appetizers, specials, lunch, dinner, etc.) .
3. Restaurant customer selects a category.
4. System displays all items in that category .
5. Restaurant customer selects the "Add to Cart" option to the item.
6. System counts the number of items .
7. System automatically sends the orders from the cart to the Kitchen’s Order Queue.
8. System displays the status of order (whether it's options to “Add More Items” or “Remove
Items”.
9. When system displays "Food is Ready and Arriving".
Extensions:
1. Restaurant customer selects the "Call Waiter" option for help . System displays pop-up
message minute and system goes back to window previously visited.
2. Restaurant customer selects the "Return to Main Menu" option to go back.
4.2.5 Use Case :-

Use Case 5: Preparing Order
Primary Actor:
Cook
Prepare food for the order and notify the waiter when it is ready.
Preconditions:
An order has been made by a customer and the waiter has brought it to the cook.
Postconditions:
The waiter is notified when the food is ready to be delivered to the table. Also each time a
fooditem is prepared, the corresponding inventory items are decreased by the pre-specified
quantity.
1. The cook selects one of the pending orders from the database and clicks on item to cook.
2. System changes the status of the item to ‘ready’.
3. The waiter is then notified by the system that the order is ready.
5 Non-functional Requirements
5.1 Performance Requirements
• The product will be based on network connectivity. The performance will depend upon
hardware components for eg: (1 GB RAM) of the tablet .Payment system will be fully secure
through POS system
• Safety Requirements
Page 18 of 21
• A fine amount will be charged for any damage done to tablet or other restaurant goods.
5.2 Safety Requirements
The possible safety requirements of the system.
Server Crash/Failed/Overwhelmed
Too many request at one time might cause the server to be failed, the system should behave
accordingly with the error.
Database Error
The system should generate error, if error occurred.
Application might failed to respond
Application update should be checked at monthly based, or the system should generate
notification if there is any update about application.
The requirements that are concerned with possible loss, damage, or harm that could result
from the use of the system.
5.3 Security Requirements

Personal information will be secured.
• Encrypted data.
• Payment through credit cards will be safe and sound.
5.4 User Documentation
User guide will be provided to the end user for ease of the usage of application.
Page 19 of 21
6 References
[1]. http://www.remotedepositcapture.com/overview/rdc.overview.aspx
[2]. http://banking.about.com/od/businessbanking/a/remotedeposit.htm
[3]. https://www.remotedepositcapture.com/webinars/Mobile-RDC-A-Game-
Changer-for-Financial-Institutio.aspx
[4]. http://www.remotedepositcapture.com/overview/rdc.requirements.aspx
[5]. www.miteksystems.com
[6]. Peterson, David, and Ronnie McCulloch. "Remote check deposit." U.S.
Patent Application 11/340,537.
[7]. Ballard, Claudio R. "Remote image capture with centralized processing and
storage." U.S. Patent No. 5,910,988. 8 Jun. 1999.
[8]. Fisher, Dan M. "Home Banking in the 21st Century: Remote Capture Has
Gone Retail." (2008).
[9]. Uhland Sr, Joseph C. "Check image capture system." U.S. Patent No.
5,444,794. 22 Aug. 1995.
[10]. Oakes III, Charles Lee, et al. "Systems and methods for remote deposit of
checks." U.S. Patent No. 7,876,949. 25 Jan. 2011.
[11]. Peterson, David, and Ronnie McCulloch. "Remote check deposit." U.S.
Patent Application 11/114,254.
Page 20 of 21
6 Appendices
Appendix A: Project proposal (signed by supervisor)
Page 21 of 21

Restaurant Management System: Software Requirement Specifications

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Restaurant Management System: Software Requirement Specifications

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Requirement Specifications

RESTAURANT MANAGEMENT SYSTEM

Project Team Muhammad Anas

Submission Date 24/09/17

Version Sign-off Authority Sign-off Date

1.2 Intended Audience

2 Overall System Description

The features of the system are:

2.3 Not in Scope

2.4 Project Objectives

2.6 Operating Environment

2.7 System Constraints

2.8 Assumptions & Dependencies

3 External Interface Requirements

3.2 Software Interfaces

3.3 Communications Interfaces

4.2 Use Cases

4.2.1 Use Case :-

2. Cashier starts a new sale.

4.2.2 Use Case :-

4.2.3 Use Case :-

4.2.4 Use Case :-

Main Success Scenario:

4.2.5 Use Case :-

5.3 Security Requirements

Anda mungkin juga menyukai