SRS Document - FIVE

Software Requirements
Specification
for
Online Food Ordering System
Version <1.0>
Prepared by
Group Name: FIVE
202177 202177
@stude
nt.upm.
edu.my
NOORAMIRAH AMNANI BINTI NASRI 202369 202369@student.upm.edu.my
SHAIKH MUHAMMAD MUSTAFA BIN SHAIKH SABRI 202181 202181@student.upm.edu.my
YU ZEXU 201460 201460@student.upm.edu.my
FILZA SYAFIRA BINTI ZULKIFLI

Software Requirements Specification for Online Food Ordering System Page ii
Instructor: Jamilah binti Din

Course: SSE3001-4 : Introduction to Sofware Engineering
Date: 4 December 2020
Contents
CONTENTS................................................................................................................................................. II
REVISIONS................................................................................................................................................. II
1 INTRODUCTION................................................................................................................................ 1
1.1 DOCUMENT PURPOSE................................................................................................................... 1
1.2 PRODUCT SCOPE......................................................................................................................... 1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW...........................................................................1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...............................................................................2
1.5 DOCUMENT CONVENTIONS............................................................................................................ 2
1.6 REFERENCES AND ACKNOWLEDGMENTS......................................................................................... 2
2 OVERALL DESCRIPTION................................................................................................................. 3
2.1 PRODUCT OVERVIEW.................................................................................................................... 3
2.2 PRODUCT FUNCTIONALITY............................................................................................................. 3
2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS.................................................................................3
2.4 ASSUMPTIONS AND DEPENDENCIES............................................................................................... 4
3 SPECIFIC REQUIREMENTS............................................................................................................. 5
3.1 EXTERNAL INTERFACE REQUIREMENTS..........................................................................................5
3.2 FUNCTIONAL REQUIREMENTS........................................................................................................ 6
3.3 USE CASE MODEL........................................................................................................................ 7
4 OTHER NON-FUNCTIONAL REQUIREMENTS..............................................................................13
4.1 PERFORMANCE REQUIREMENTS.................................................................................................. 13
4.2 SAFETY AND SECURITY REQUIREMENTS.......................................................................................13
4.3 SOFTWARE QUALITY ATTRIBUTES................................................................................................ 13
APPENDIX A – DATA DICTIONARY....................................................................................................... 15
Appendix B - Group Log............................................................................................................................ 16
Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Filza Syafira, The draft of SRS document version 1 is 04/12/20
Version Nooramirah
Software Requirements Specification for Online Food Ordering System Page iii
Version Primary Author(s) Description of Version Date Completed

1.0 Amnani, Shaikh completed.
Muhammad
Mustafa and Yu
Zexu
Software Requirements Specification for Online Food Ordering System Page 1
1 Introduction
The online food ordering system (OFOS) is the process of ordering meals from a website or other
application before being delivered by the riders. The system also provides updates to customers
regarding their order.
1.1 Document Purpose
The purpose of this SRS is to attract developer / stakeholder interaction by outlining the
functional and non-functional needs of online food ordering system subjects, especially the
addition of real-time tracking systems. Therefore, the document should be an important basis for
completing the project efficiently and in accordance with the needs of stakeholders.
To groups of audiences involving customers, riders and restaurant owners, this SRS should
deliver and validate all required functions and represent contractual agreements between the
parties involved.
1.2 Product Scope
In today's environment, the use of online food ordering is on the rise. Therefore, the OFOS
system needs to be upgraded for the convenience of the users. However, the increase in the rate
of problems in the estimated meal time for food can also not be ignored. therefore, this document
sets the conditions to add real-time tracking features as a replacement to the problem.
The real-time tracking features are developed for general purpose and to replace the old “track
and trace” food ordering application. Instead, OFOS is built with “live track and trace” to increase
customer satisfaction interactively. With this system, food delivery can be easily tracked till the
last mile, thus ensuring timely delivery and customer satisfaction, resulting in customer retention.
OFOS also helps to improve the order completion process. By having real-time tracking about the
current location of each delivery vehicle, kitchen staff will be able to notify the fleet manager to
set the route for the next orders.
1.3 Intended Audience and Document Overview

This document is written for student and professor in Software Engineering subject and has been
implemented under the guidance of college professors. This project is useful for all smartphones
users. Following section describes the rest of the product function. Scope, other overall
description and references.
1.4 Definitions, Acronyms and Abbreviations
Term Description
Application A software program that runs on your computer
Customer Restaurant patron that orders/pays for a meal
E-wallet Known as digital wallets are financial accounts that allow users to store
funds, make transactions, and track payment histories by computer.
Hard disk An electro-mechanical data storage device that stores and retrieves
digital data using magnetic storage and one or more rigid rapidly
rotating platters coated with magnetic material.
Menu Surface computer representation of the available items and other
options
Order Comprises one or more items
Payment Comprises the total cost of zero or more meals and zero or more tips
Real-time tracking Collection of sensors that work together to automatically identify
and track the location of objects (including people) in real time.
Restaurant owner The one who is responsible for the daily operations of a restaurant
Rider Person who transport meals items from production areas to customers
Server Backend computer that hosts the restaurant menu and ordering system
Web Collection of websites stored in web servers and connected to
local computers through the internet.
Workstations Special computer designed for technical or scientific applications.
Acronym Description
ATA Advanced Technology Attachment
DBMS Database Management System
GPS Global Positioning System
IDE Integrated Drive Electronics
IEEE Institute of Electrical and Electronics Engineers.
O2O Online to offline
OFOS Online food ordering system
PC Personal Computer
SRS Software Requirement Specification
VI Visual Identification System
1.5 Document Conventions

SRS document for Online food ordering system follows the IEEE formatting requirements. The
document use Arial font with the size of 11 for the comments or descriptions and size of 14 for
subsections’ title. The document also use Italics for comments and the paragraph is justified.
Document text written is single spaced and maintain the 1” margins.
1.6 References and Acknowledgments

 IEEE Recommended Practice for Software Requirements Specifications, IEEE Standard
830, 1998.
2 Overall Description
2.1 Product Overview

The food ordering system is a process of ordering meals from a local restaurant or meals
cooperative through a web page or app and is a system that replaces the current manual
order, the figure below shows a context Diagram that is drawn for a Food Ordering System. It
contains a process (box) that represents the system to model, in this case, the "Online Food
Ordering System". In between the process and the external entities, there is (connectors) that
indicate the existence of information exchange between the entities and the food ordering
system.
2.2 Product Functionality

 The system must connect with the real-time tracking (GPS system) to track live location of
the rider.
 The system must save and store all data to operate using DBMS system.
 The OFOS system shows the menu online and the customers easily places the order with
a simple tap.
2.3 Design and Implementation Constraints
The mobile application is constrained by the GPS navigation system within the mobile phone.
Since there are multiple systems and multiple GPS manufacturers. Also, there may be a
difference between what navigation features each of them provide.
The Interface needs to be user friendly for both the customers and restaurant manager. It may
need a little tip for the restaurant manager to make use of the application interface while the
customer which is a regular mobile phone user will easily get used to the interface.
The Internet connection is also a constraint for the application. Since the application fetches data
from the database over the Internet, it is crucial that there is an Internet connection for the
application to function.
2.4 Assumptions and Dependencies
One assumption about the product is that it will always be used on mobile phones that have
enough performance. If the phone does not have enough hardware resources available for the
application, for example the users might have allocated them with other applications, there may
be scenarios where the application does not work as intended or even at all.
The payment system depends on the other payment system. It may differ from the speed and
availability of the bank/e-wallet server.
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The interface of the FoodPanda Takeaway App is mainly in pink color and runs through the entire
product design. In addition to the background color, icons, and text, it also matches the rider
clothing, etc. The entire set of colors has been deeply rooted in the hearts of the people, and it
can be said to be a very successful VI design case.
As a take-out product, the design core revolves around how to better display the business and
guide users to place orders. The middle position of the page is used to display businesses and
meals, the search, settings, message center and other functions are placed at the top, and the
bottom is a fixed menu navigation bar. The operation mode is mainly swiping up and down,
single-point selection, and occasionally sliding left and right as auxiliary display. On the basis of
the prototype diagram, use Axure to simulate and draw a demo page, which can be directly
clicked to operate, which is convenient for more intuitive display of the hierarchical relationship
between pages.
3.1.2 Hardware Interfaces
The English full name of SCSI is "Small Computer System Interface", which is a completely
different interface from IDE (ATA). IDE interface is a standard interface for ordinary PCs, while
SCSI is not an interface specifically designed for hard disks. A high-speed data transmission
technology widely used in minicomputers. The SCSI interface has the advantages of wide
application range, multitasking, large bandwidth, low CPU usage, and hot plugging, but the higher
price makes it difficult to popularize like IDE hard disks, so SCSI hard disks are mainly used in
middle and high-end servers and high-end workstations. Using this high-end hardware to process
the service information of this takeaway system is an efficient and simple choice.
3.1.3 Software Interfaces
The OFOS will interface with a Database Management System (DBMS) that stores the
information necessary for the OFOS to operate. The DBMS must be able to provide, on request
and with low latency, data concerning the restaurant's menu and employees. Additionally, it
should archive data provided to it as the data will include records of all orders and transactions
executed by the OFOS.
Faced with such a complex decision-making problem, FoodPanda ’s intelligent delivery system
acts as the rider’s "super brain". It will track the rider’s direction and current position in real time,
and calculate according to the service requirements of the current waybill and the new waybill.
Distribute orders in the most efficient way for the system. The technical department is
continuously optimizing the algorithm, and ultimately hopes to more than double the per capita
distribution efficiency through technology.
In the offline service process, technology can do a lot of optimization. It is these optimizations one
by one, which together can continuously reduce the offline costs of FoodPanda and merchants,
and then improve the overall O2O production efficiency.
3.2 Functional Requirements
3.2.1 The system shall have real-time matching at the implementation level, that is, the dynamic
setting of the delivery fee involved when the user places an order, the assignment of the
order, and the execution of the rider. Give some examples, such as the planning of the
distribution range of the merchants, which area should be allocated to some disputed
communities, and what are the costs and benefits of dividing into each area? These all
need to be considered.
3.2.2 Functional Requirement or Feature
1. Customer (C)
Requirement Description
C01 Customers must register before they wants to order the meals .
C02 Customers can order their item/meals in the cart before submit the order.
C03 Customers can review their ordered meals and personal information such as
customer’s name, phone number, location (address) before they submit the
order. Then, they have to checkout the items in the cart.
C04 Customers can make their payment with credit card and online payment.
C05 Customers can track current location of their riders.
2. Rider (R)
R01 -The riders can view the restaurant and customers’ location before they take and
deliver the meals.
3. Restaurant owner (RO)
Requirement Description
RO01 The restaurant owner can display and modify (add or remove) their menu on the
system.
RO02 The restaurant owner will get notifies from the system if the order have been
checkout.
RO03 The restaurant owner can request delivery to the system.
3.3 Use Case Model (Author – Nooramirah Amnani bt Nasri, Filza Syafira & Shaikh
Muhammad Mustafa)
3.3.1 Use Case #1 (Register – C01)
Use Case Register

Purpose A customer registers into the app and the
system will save the user’s information
Requirement Traceability The customer have to register onto the account
to order meals.
Priority High
Precondition None
Post condition The customer is now logged into the system. If
not the system state is unchanged.
Actors Customer
Extends None
Flow of events
Basic Flow
1. The system requests that the actor

enter his/her name and password.
2. The actor enters his/her name and
password.
3. The system validates the entered name
and password and logs the actor into
the system.
Alternative Flow
Invalid Name / Password
If in the Basic Flow the actor enters an

invalid name and/or password, the system
displays an error message. The actor can
choose to either return to the beginning of
the Basic Flow or cancel the login, at which
point the use case ends.
Includes None
Notes/Issues None
3.3.2 Use Case #2 (Ordering - C02, C03, C04 & RO02)
Use Case Order Item, Review Order, Checkout and

Payment
Purpose To order items from the menus from the
application
Requirement Traceability The customer have to order their meal and
review the order before checking out. Then, the
will make the payment for the order.
Priority High
Precondition
1. The customer is registered.
2. The customer is logged in to the

system.
3. The customer find out the item he/she

wants to buy
Post condition
1. The system saves the order.
2. The system process the order
Actors Customer, Restaurant Owner and System

Extends None
Flow of events
1. The customer adds the item into cart
2. The customer click the shopping cart
and to review order and personal
information
3. The customer checks out the order by
clicking the ‘check out’ button.
4. The system calculates the total
amount and displays the order.
5. The system display payment method
of the order
6. Customer pays by their preferred
payment type.
7. The system confirms the order.
Includes Payment
Notes/Issues None
3.3.3 Use Case #3 (Track rider – C05)
Use Case Track rider

Purpose To track current location of the rider to the customer’s location
Requirement Traceability
The customer can track the order being delivered with the live
track through the GPS system service.
Priority High
Precondition 1. The customer order the meals.
2. The order request has to be assigned to the rider.
Post condition The customer successfully tracks the deliverable with GPS.
Actors Customer, GPS System
Extends None
Flow of events 1. The restaurant owner request to deliver the meals.
2. The rider start to deliver the meals.
3. The customer can track current location of the rider.
Includes None
Notes/Issues None
3.3.4 Use Case #4 (Display and Modify Menu – RO01)
Use Case Display and Modify Menu

Purpose The restaurant owner wants to add or change
menu info
Requirement Traceability The restaurant owner get the option to display
and modify the menu.
Priority High
Precondition
1. The restaurant owner is registered.
2. The restaurant owner is logged in to

the system.
3. The restaurant owner find out the

menu he/she wants to modify.
Post condition 1. The system saves the new menu.

2. The customer can view the new menu.
Actors Restaurant owner
Extends None
Flow of events
1. The restaurant owner log in to the
system.
2. The restaurant owner request to add or
change the menu info in the system.
3. The restaurant owner submit the new
update of menu info to the system.
4. The system will save the new menu

info.
Includes None
Notes/Issues None
3.3.5 Use Case #5 (Request Delivery – RO03)
Use Case Request for delivery

Purpose To deliver the order that have been purchased
by customer
Requirement Traceability The restaurant owner must request to deliver
meals to a specific location.
Priority High
Precondition The customer has to complete their payment.
Post condition The system will assign the order request to a
rider.
Actors Restaurant owner
Extends None
Flow of events
1. The customer select their order items
and review the order
2. The customer checkout and makes the
payment for the ordered item.
3. The customer complete the payment for
the order.
4. The restaurant owner will request
delivery to the system.
5. The system will assign the order request

to a rider near the merchant.
Includes None
Notes/Issues None
3.3.6 Use Case #6 (View customer and restaurants’ location – R01)
Use Case View customer and restaurants’ location

Purpose To reduce waiting time and be able to take or
deliver the meals in the right location
Requirement Traceability The rider can view location of customer and
restaurant to make delivery.
Priority High
Precondition The system should assign riders to deliver
meals from any restaurant before being
delivered to the customer.
Post condition The rider can start delivering meals to their
location according to the GPS system.
Actors Rider
Extends None
Flow of events 1. The restaurant owner request to deliver
the meals.
2. The rider will go to the specific
restaurant to take the order using GPS
system.
3. The rider start to deliver the meals.
4. The rider will go to customer’s location
based on map displayed by GPS
system
Includes None
Notes/Issues None
4 Other Non-functional Requirements
4.1 Performance Requirements
 The performance requirement is speed of network. It is to load the menu from the
databases. For the rider location, the location should be refreshed every 5 seconds to
avoid long delay.
 The user database should be normalized to prevent redundant data and improve
performance.
4.2 Safety and Security Requirements
4.2.1 Safety
There are no safety requirements with this application, other than any normal hazards of a mobile
device. The only hazard is a user using the device when they should not be, such as while
driving. The rider should have a phone holder to view the task.
4.2.2 Security
Information transmission should be securely transmitted to the server without any changes in
information.
4.3 Software Quality Attributes
4.3.1 Availability
If the internet service gets disrupted while sending information to the server, the information can
be sent again for verification after the device is coming back online.
4.3.2 Security
The main security concern is for users' accounts and payment. The application should use a
proper payment gateway. The other security measures are the location of the rider is only
available for the user and the restaurants only.
4.3.3 Usability
The user’s ability to input data into devices that have a small screen should be in reasonable
manner and not difficult to the user.
Appendix A – Data Dictionary
Variable Priority Type Contained in Use Description

Case(s)
(f or nf)
Register High Functional Use Case #1 Users sign up to the application before
have access to order
Display and High Functional Use Case #2 Restaurant owner adds and changes
modify menu menu information
Order item High Functional Use Case #3 Users order items from the menu
Request High Functional Use Case #4 Restaurant owner sends delivery

Delivery request to rider for food delivery
Track rider High Functional Use Case #5 Customer tracks the current locations
of the rider
View locations High Functional Use Case #6 Rider able to take or deliver the food to
the correct places
Appendix B - Group Log
DATE DESCRIPTION
19 NOV 2020  We discussed on sections for each member to handle
 We discussed on the use case for the system

22 NOV 2020  Introduction and Overall Description has been updated
 We discussed on the Context Diagram of the systems

23 NOV 2020
 We discussed on the Use Case of the systems

24 NOV 2020
 We edited some parts on the Overall Description

26 NOV 2020
 We had our meeting with the stakeholder presenting the specification

28 NOV 2020 requirements
3 DEC 2020  We updated the Use Case details of the systems to follow the client’s
requirements
4 DEC 2020  The SRS document is completed.

 All of the member will check the document together to avoid any mistake.
( validation technique).

SRS Document - FIVE

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS Document - FIVE

Uploaded by

Copyright:

Available Formats

Software Requirements

Online Food Ordering System

Group Name: FIVE

SHAIKH MUHAMMAD MUSTAFA BIN SHAIKH SABRI 202181 202181@student.upm.edu.my

YU ZEXU 201460 201460@student.upm.edu.my

FILZA SYAFIRA BINTI ZULKIFLI

Instructor: Jamilah binti Din

Appendix B - Group Log............................................................................................................................ 16

Version Primary Author(s) Description of Version Date Completed

1.1 Document Purpose

1.2 Product Scope

1.3 Intended Audience and Document Overview

1.4 Definitions, Acronyms and Abbreviations

1.5 Document Conventions

1.6 References and Acknowledgments

2.1 Product Overview

2.2 Product Functionality

2.3 Design and Implementation Constraints

2.4 Assumptions and Dependencies

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.2 Functional Requirements

3.2.2 Functional Requirement or Feature

C05 Customers can track current location of their riders.

3.3.1 Use Case #1 (Register – C01)

Use Case Register

1. The system requests that the actor

Invalid Name / Password

If in the Basic Flow the actor enters an

3.3.2 Use Case #2 (Ordering - C02, C03, C04 & RO02)

Use Case Order Item, Review Order, Checkout and

2. The customer is logged in to the

3. The customer find out the item he/she

2. The system process the order

Actors Customer, Restaurant Owner and System

7. The system confirms the order.

Use Case Track rider

3.3.4 Use Case #4 (Display and Modify Menu – RO01)

Use Case Display and Modify Menu

2. The restaurant owner is logged in to

3. The restaurant owner find out the

Post condition 1. The system saves the new menu.

4. The system will save the new menu

3.3.5 Use Case #5 (Request Delivery – RO03)

Use Case Request for delivery

5. The system will assign the order request

3.3.6 Use Case #6 (View customer and restaurants’ location – R01)

Use Case View customer and restaurants’ location

4 Other Non-functional Requirements

4.1 Performance Requirements

4.2 Safety and Security Requirements

4.3 Software Quality Attributes

Appendix A – Data Dictionary

Variable Priority Type Contained in Use Description

Request High Functional Use Case #4 Restaurant owner sends delivery

Appendix B - Group Log

19 NOV 2020  We discussed on sections for each member to handle

 We discussed on the use case for the system

 We discussed on the Context Diagram of the systems

 We discussed on the Use Case of the systems

 We edited some parts on the Overall Description