0% found this document useful (0 votes)
16 views18 pages

Wali Azhar

The Software Requirements Specification (SRS) document outlines the development of a mobile-based food ordering application named Meher's Kitchen, designed to streamline the food delivery process for restaurants. It details the application's purpose, scope, functional and non-functional requirements, and user roles, including customers and administrators. The document also includes technical specifications, user interface design, and operational constraints to ensure effective implementation and user satisfaction.

Uploaded by

atahi2020
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views18 pages

Wali Azhar

The Software Requirements Specification (SRS) document outlines the development of a mobile-based food ordering application named Meher's Kitchen, designed to streamline the food delivery process for restaurants. It details the application's purpose, scope, functional and non-functional requirements, and user roles, including customers and administrators. The document also includes technical specifications, user interface design, and operational constraints to ensure effective implementation and user satisfaction.

Uploaded by

atahi2020
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 18

The Islamia University of

Bahawalpur
Department of Information Technology

SOFTWARE REQUIREMENTS
SPECIFICATION (SRS
DOCUMENT)

for

FOOD APP
Version 1.0

By
Wali Azhar
Mahnoor
FA19M2BC067
FA19M2BC001

Session Fall 2019 – 2023

Supervisor
1
Mr Wahaj Ali

Bachelor of Science in Information Technology

Table Content
Revision History................................................................................................................................1
Application Evaluation History.........................................................................................................2
1. Introduction..................................................................................................................................3
1.1 Purpose...................................................................................................................................3
1.2 Scope......................................................................................................................................4
2. Overall description.......................................................................................................................4
2.1 Product perspective................................................................................................................4
2.2 Operating environment..........................................................................................................5
2.3 Design and implementation constraints.................................................................................5
2.4 System Interface.....................................................................................................................5
3. Requirement identifying technique..............................................................................................5
3.1 Use case diagram:...................................................................................................................6
3.2 Use case description...............................................................................................................8
3.3Functional Requirements:.......................................................................................................10
3.3.1 CUSTOMER REQUIREMENTS...........................................................................................10
3.3.2 ADMIN REQUIREMENTS..................................................................................................10
3.3.3 System Mode..................................................................................................................11
3.3.4 User Class........................................................................................................................11
3.3.5 Objects............................................................................................................................11
3.4Menu Management System Module:.................................................................................12
3.5 Non-Functional Requirements...............................................................................................13
3.5.1 Performance Requirements:...........................................................................................13
3.5.2 Safety Requirements:......................................................................................................14
3.5.3 Security Requirements:...................................................................................................14
3.5.4 Software Quality Attributes:...........................................................................................14
3.6 Usability................................................................................................................................14
3.7 Performance.........................................................................................................................14
References......................................................................................................................................15

2
Revision History
Name Date Reason for changes Version
Mehr’s New updates for new features 1.0.0
kitchen

3
Application Evaluation History
Comments (by committee) Action Taken
*include the ones given at scope time both in doc
and presentation

Supervised by
Wahaj Ali

Signature

4
1 Introduction:
Meher’s Kitchen is an application designed primarily for use in the food delivery industry.
This system will allow restaurant to increase scope of business by reducing the labor cost
involved. The system also allows to quickly and easily manage an online menu which
customers can browse and use to place orders with just few clicks. Restaurant employees then
use these orders through an easy to navigate graphical interface for efficient processing. It is
known globally that, in today’s market, it is extremely difficult to start a new small-scale
business and live-through the competition from the well-established and settled owners. In
fast paced time of today, when everyone is squeezed for time, the majority of people are
finicky when it comes to placing a food order. The customers of today are not only attracted
because placing an order online is very convenient but also because they have visibility into
the items offered, price and extremely simplified navigation for the order.

1.1 Purpose:
The project aims to build a Mobile Based system for restaurant that is Meher’s Kitchen,
which automates food ordering system. It will also help the management to manage the
online orders and view the status. The management can add menus and take orders with the
system. The system also has a simple mobile-friendly user interface which can be used
through different types of devices and screens. Google API will be integrated with the
application so customers can login with their Google account and like or share menus which
can work a new customer as word of mouth. In order to achieve the mentioned aim, following
objectives should be achieved:

1.2 Scope:
In this project, a fast-food company is designed and Meher’s Kitchen, this is taken as a case
study to enable customers order for food and get it delivered accordingly and also to reduce
the long queues of customers at the counter ordering for food and to reduce the work lord on
the employees. The following things are among other things that are discussed and

what the software would handle: 5


 About the fast-food company
 The fast food and the services offered there
 Online purchase
 Type of food provided
 IoT based food ordering system
 Physical smart system for restaurant
 Mobile application

2. Overall Description:
2.1 Product Perspective:
The software described in this SRS is the software for a complete Food Ordering system. The
system merges various hardware and software elements and further interfaces with external
systems. Thus, while the software covers the majority of the system's functionality, it relies
on a number of external interfaces for persistence and unhandled tasks, as well as physically
interfacing with humans. For user acceptance testing, random selection process is used. A
questionnaire is made to obtain user evaluation of the system. The questionnaire consists of
five questions, which are set to gain user perspective on the ease of use, user friendliness, and
responsiveness of UI and performance of the application. The answers have been taken
anonymously from 20 random persons.

2.2 Operating Environment:


The system/application will be used in following environment:
 The users will be located close to each other in one region, same city. Later this can
be extended to different cities if required.
 The users will access the system from 11am onwards to 11pm or 12pm, according to
mall and food court timings.
 The users cannot tolerate service interruptions as this would annoy the user resulting
in not using the application. Moreover, any service interruption would affect the
entire process, placing orders etc. which would result in loss of business of food brands.

2.3 System Interface:


Food app is designed using Flutter framework in Android Studio.
6
2.4 Design and Implementation Constraints
 Internet enabled computers are required. Moreover, for food brands a Web app is
required.
 Customers will be required internet access to scan and order
 The mobile app and web app development can be done using a framework
 The system should follow all the business rules as stated in “Business rules”
document
 The memory usage of the app will have to be constrained by the devices it is intended
to run. Since most tablets, Android phones may have limited memory

3. Requirement Identifying Technique


This section describes the requirements identifying technique(s) which further
help to derive functional requirements specification. The selection of the
technique(s) will depend on the type of project. For instance,
 Use case is an effective technique for interactive end-user applications
 Event- response tables is for real time system and
 Story boarding for graphically intensive applications.
In addition to above, the projects involving data warehouses, batch processes, hardware
devices with embedded control software, and computationally intensive applications required
to follow other suitable techniques. Such techniques are described further in Chapter 12, “A
picture is worth 1024 words.” For documenting this section let consider identifying
requirements through use case as an example.

3.3 Functional Requirements:


7
3.3.1 Customer Requirements :
 Create an account.
Customers create their account either by using google or simple entering some
information first Name, last Name, email and password,
 Manage their account.
Customer can manage his account like can update account name etc, and can see his
information like cart detail
 Log in to the system.
Customer can login with email and password when he comes
after sometime into app. Just for authenticate himself
 Navigate the restaurant’s menu.
Customer can see menus that offered by mehars’kitchen and navigate to other menus
based on need . List of menus are visible to customer
 Select an item from the menu.
Customer can select an item from menu’s list based on his need by clicking
the specific item and it will be add into the cart.
 Add an item to their current order.
When item is selected and added into cart then finally customer can press order button
and order will be placed to the mehar’s kitchen
 Review their current order.
Customer can review his order that is recently placed like it is done or
in processing etc
 Checkout
Customer gives his detail here like delivery address, location,
 Place an order.
Customer finally place his order after checkout
 Receive confirmation in the form of an order number
Customer receive an order number when order is successfully placed and this is his
own order id
 View order placed.
Customer can view the status of order either it is placed or not
Create an account Customers create their account either by
using google or simple entering some 8
information first Name, last Name, email
and password,

Customer can manage his account like can


Manage their account update account name etc, and can see his
information like cart detail

Customer can login with email and


Log in to the system password when he comes after sometime
into app. Just for authenticate himself

Customer can see menus that offered by


mehars’kitchen and navigate to other menus
Navigate the restaurant’s menu.
based on need . List of menus are visible to
customer

Customer can select an item from menu’s


list based on his need by clicking
Select an item from the menu
the specific item and it will be add
into the cart.

When item is selected and added into cart


then finally customer can press order button
Add an item to their current order
and order will be placed to the mehar’s
kitchen

Customer can review his order that is


Review their current order. recently placed like it is done or in
processing etc

Customer gives his detail here like delivery


Checkout
address, location

Customer finally place his order after


Place an order
checkout

View Order Customer can view the status of order either


it is placed or not

9
3.3.2 Admin Requirements :

 Log in to the system.


Admin just login to the app using the same information that is already in system
can login using google or giving email and password. Admin login into admin app by
using the email and password that is given to admin by db admin
 Add the item to the menu list.
Admin add items into menu list and also can add menu based on his business
 Delete items from the menu list.
Admin can delete menus and items from menu list base on need
 Update the menu list.
Admin can update menu list by deleting the or adding items into menu list
 Manage users.
Admin also manage users/customers can see which user place the order and from
where this order is placed
 Manage orders.
Admin also manage the order like delivery against order and can see history of orders
for some business analysis

Table Admin Requirement:


Admin Requirements Description
Admin just login to the app using the same information that
Login
is already in system

Admin add items into menu list and also can add menu
Add Item to menu List
based on his business

Admin can delete menus and items from menu list base on
Delete Item to menu List
need

Admin can update menu list by deleting the or adding items


Update the menu list
into menu list

Manage Users Admin also manage users/customers can see which user 10
place the order and from where this order is placed

Admin also manage the order like delivery against order and
Manage Orders
can see history of orders for some business analysis

3.3.3 System Mode:


This system has two modes:
 When there is an end user logged in, it will show categories, and products to order and
buy from the restaurant.
 When there is admin Logged in to the system it shows order status at main page
where admin can confirm, deliver or cancel order. It also shows admin to add or
update settings/products.

3.3.4 User Class:


There are two classes of User in this system.
 User: This will be the end user which visited the Application to order/buy some food
online.
 Admin: This will be the restaurant owner or manager to handle the orders coming
from the users.

3.3.5 Objects:
Objects are real-world entities that have a counterpart within the system. Associated with
each object is a set of attributes and functions. These functions are also called services,
methods, or processes. Note that sets of objects may share attributes and services. These are
grouped together as classes.
Objects which are going to be classes in this System are:
 User
 Category
 Product
 Food Settings
11
 Order
 Cart

3.1 Use Case Diagram:


Fig.2. Use case #1:
Use case diagram for user side and Admin :

12
13
Figure 3.2 Data Flow Diagram for Admin and Customer

3.2 Use Case Description:

Table 1. Use case description Registration

Use Case Name: Registration

Actors: Customer

Description: Customer must have to register when he comes first


time after that he can enter into app and can view list of
food and place order , without registration Customer
can’t view items and not place order for a food

Trigger: Customer Wants to Register

Table 1. Use case description Login

Use Case Name: Registration

Actors: Customer and Admin

Description: Customer and Admin both can be login by using google


sign in method or entering their email and password
after that both can enter in app . And after login
customer will see the list of items and admin will see the
number of all orders and the deliverable orders and
status of orders
Trigger: Customer and Admin Wants to Login

14
Table 1. Use case description Cancel Order

Use Case Name: Cancel Order

Actors: Admin

Description: Admin can cancel any customer order based if he


wants based on different reasons like delivery not possible
at that place or some other reasons

Trigger: Admin wants to Cancel Order

Table 1. Use case description Add Menu

Use Case Name: Add Menu

Actors: Admin

Description: Admin can Add menu list from admin side and these
lists contains food items . These items will be show
to each customer menu vise.

Trigger: Admin wants to Add menu

Table 1. Use case description Delete Menu

Use Case Name: Delete Menu

Actors: Admin

Description: Admin can delete menu list from admin side and these
lists contains items and all food items will be delete when
menu will be delete. Admin using this case can delete
menus in app based on business requirement

15
Trigger: Admin wants to Delete menu
Table 1. Use case description Cart

Use Case Name: Cart

Actors: Customer

Description: Customer after choosing the item can add it into cart and
cart is bind to individual customer but cart will be
managed locally inside app, after adding multiple items
into cart customer now can order . A cart can contains
multiple items
Trigger: Customer Add items into Cart

Table 1. Use case description Checkout/ Payment

Use Case Name: Checkout/Payment

Actors: Customer

Description: Customer after completing the cart now before ordering


move to checkout page where he will give the location
of delivery

Trigger: Customer wants to Checkout

Table 1. Use case description Order

Use Case Name: Order

Actors: Customer

Description: Customer after completing the cart now can order . This
order will be sent to admin side and user can see status
of his order whether it id canceled or in processing.

Trigger: Customer wants to order


16
3.5 Non-Functional Requirements
3.5.1 Performance Requirements:

The app should provide greater performance with no delay. For food brands, who would be
using web app on their desktop computers, the performance should be good and queries with
minimum “join” statements are preferred for better and fast results. Too many tables in
database can result in slower execution of queries, hence effecting the entire system 92% of
the queries shall be completed in approximately 3.5-4 seconds. There should be no more than
0.5 – 0.8 second of delay in communication between customers and food brands.

3.5.2 Safety Requirements:


RPO and RTO should be clearly defined to avoid loss of data that could affect the business.
The system cannot afford loss of data of its customers because it provides analysis on basis of
it.

3.5.3 Security Requirements:


 Every user must change his initial password after first successful login
 If any user uses his credit card for payment, OTP is sent via text or call for
confirmation • The user shall receive a text message by bank on successful transaction

3.5.4 Software Quality Attributes:

The mobile app should have a responsive layout and should be portable the web app should
be saleable and manages the data load accordingly the mobile app should follow recognition
rather than recall i.e., it is simple and easy to use and learn.

3.6 Usability:
The Meher’s Kitchen will allow a user to retrieve the previous food ordered with a single
interaction.
17
3.7 Performance:
This App can be installed and used by the any numbers of user but backend processing
depends on the server load.
 It supports as many users as possible
 more than 1000 simultaneous requests can be processed within seconds
 1000 orders can be placed and handled within 5 seconds.
95% of the transactions will be processed in less than 1 second.
An operator will not have to wait for the transaction to complete.

References
(SRS Documentation of Online Food Sell Purchase Project in Android

( https://t4tutorials.com/srs-documentation-of-online-food-sell-purchase-project-in-android-
php-or-asp-net/
)
(Report of Meher’s Kitchen)
(https://kupdf.net/download/online-food-orderingystem_59ba111908bbc5fb65894d32_pdf
)

18

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy