Business Requirement

Document
Food Ordering
Mobile Application (Swiggy App)

Document details
Document Prepared By Document preparation date
Sudarshan kalwankar 28-05-2019

Page | 1
BUSINESS REQUIREMENT DOCUMENT
 Version History
Date Version Description Author
17-12-2018 1.1.0 Initial Draft Sudarshan K

Approvals
Role Name Title Signature Date
Project Sponsor

Business Owner

Project Manager

System Architect

Development Lead

User Experience Lead

Quality Lead

Content Lead

Page | 2
BUSINESS REQUIREMENT DOCUMENT
Table of contents

Table of Contents
1.Introductions........................................................................................................................................ 5
2.Purpose ................................................................................................................................................ 6
3.Scope .................................................................................................................................................... 6
3.2 In Scope Functionalities ................................................................................................................ 6
.1.1 Registration ......................................................................................................................... 6
.2.1 Login .................................................................................................................................... 6
.1.1 Home ................................................................................................................................... 6
.1.1 Search.................................................................................................................................. 6
.1.2 Membership ........................................................................................................................ 6
.1.3 Logout ................................................................................................................................. 7
.1.1 Food and Restaurant display Enlarge Image ....................................................................... 7
.1.1 Similar Product .................................................................................................................... 7
.1.1 Cart ...................................................................................................................................... 7
.1.1 Cart ...................................................................................................................................... 7
.1.1 Placed order ........................................................................................................................ 7
.1.1 Notifications ........................................................................................................................ 7
.1.1 Payment .............................................................................................................................. 7
.1.1 Your Order........................................................................................................................... 7
.1.1 Order Tracking..................................................................................................................... 7
.1.1 Customer Care .................................................................................................................... 7
.1.1 My Account ......................................................................................................................... 8
.1.1 Restaurant and Dishes Description Page ............................................................................ 8
.1.1 Filter .................................................................................................................................... 8
.1.1 Sort ...................................................................................................................................... 8
.1.1 Widget ................................................................................................................................. 8
.1.1 Review/Rating ..................................................................................................................... 8
.1.1 Coupons .............................................................................................................................. 8
.1.1 Bills ...................................................................................................................................... 8
3.3 Out Functionalities ........................................................................................................................ 8
A. Fingerprint Login: ........................................................................................................................ 8
B. Restaurant and Dishes Video: ..................................................................................................... 8
C. Virtual Restaurant and Dishes: ................................................................................................... 8
D. HD Restaurant and Dishes Image: .............................................................................................. 9
Page | 3
BUSINESS REQUIREMENT DOCUMENT
 E. Group Purchase: .......................................................................................................................... 9
F. Language Issue: ........................................................................................................................... 9
4. Overall description ............................................................................................................................. 9
4.1 Product Perspective ...................................................................................................................... 9
A. Web Ordering System Module ............................................................................................... 9
B. Menu Management System Module .................................................................................... 10
C. Order Retrieval System Module............................................................................................ 10
D. Environment and Technology requirement. ......................................................................... 10
5. Assumption ....................................................................................................................................... 11
6. Constraints ........................................................................................................................................ 11
7. Workflow Diagram ............................................................................................................................ 11
7.1 Login & Registration Process Workflow Diagram ....................................................................... 12
7.2 Order Placement Process Workflow Diagram ............................................................................ 12
7.3 Order Replace, Return, Cancel and Tracking Process Flow Diagram .......................................... 13
8. FUNCTIONAL REQUIREMENTS .......................................................................................................... 15
9. UML ANALYSIS MODEL ..................................................................................................................... 18
9.1 Use case ...................................................................................................................................... 19
9.3 Use case for Customer: ........................................................................................................... 20
9.4 Use case for Restaurant: ............................................................................................................. 21
10. NON-FUNCTIONAL REQUIREMENT ................................................................................................. 22
10.1 Some typical non-functional requirements are: ....................................................................... 22
11. DESIGN SPECIFICATION ................................................................................................................... 24
11.1 DESIGN FLOW FOR USER........................................................................................................... 24

Page | 4
BUSINESS REQUIREMENT DOCUMENT
1.Introductions
Our client Swiggy had asked SUD Technologies to develop a modern well-established
food chain App looking for a mobile platform. Offline delivery services looking for a
convenient mobile delivery. Basically, we aim to provide a mobilized method for food
delivery system.

In current formal dining environments, some form of physical static menu is utilised to
convey the available food and beverage choices to customers. This document specifies
the requirements for a restaurant paper menu and ordering replacement strategy to
overcome the problems associated with the current Traditional method. Four related
concepts are encompassed by the general scope of the Swiggy system. The first concern
is to replacement of paper-based menus using an electronic format, the second relates to a
complementary electronic strategy for the front of house handling of a customer’s order
and the third surrounds the process of transferring said electronic orders to the kitchen for
preparation and finally the orders are delivered to user.
It should be noted that The Business Requirements Document is designed to document
and describe the agreement between the customer and the Business Analyst regarding the
understanding of the software product requested. Its primary purpose is to provide a clear
and descriptive “statement of user requirements” that can be used as a reference in further
development of the software system.

Page | 5
BUSINESS REQUIREMENT DOCUMENT
2.Purpose
In short to Defining and describe the functions and specifications of the Swiggy Mobile
Application is the primary goal of this Business Requirement Document. This Business
requirement Document is an Illustrates of client requirement in clear terms, the
system’s primary uses and required functionality as specified by customer. The
document also provides a detailed profile of the external interfaces, performance
considerations and design constraints imposed on the subsequent implementation the
document should act as a foundation for efficient and well-managed project completion
and further serve as an accurate reference in the future

3.Scope
3.2 In Scope Functionalities

.1.1Registration
.2 If User is a New User, then He/she can register on the System. For registration user
needs to fill the registration form (First Name, Last Name, Email Id, Mobile Number,
Password, Security Questions) after this System send OTP and Verification Mail to
register Mobile number and Email Id to activate the account.

.2.1Login
 After successfully registration User can login into the system by registered Mobile
number and password OR Registered Email Id and Password.

.1.1Home
 Home is the Dynamic page that shows Food, Restaurant, Offers, Categories, and
widgets. By clicking on any function of the home page User can navigate to that page
or function.

.1.1Search
Search is the function from that user can search any product or service. User need to
write any keyword and system show related products and services according to that
keyword.

.1.2Membership
If User get access of Membership then He/she get the Free delivery, Additional
discount, No Surge fee and more. For getting access User must Pay decided Amount.

Page | 6
BUSINESS REQUIREMENT DOCUMENT
 .1.3Logout
 User can remove from the system by clicking Logout.

.1.1Food and Restaurant display Enlarge Image

 It shows Food and Restaurant the Enlarge image after clicking on the Food and
Restaurant

.1.1Similar Product
 If User Search any Food and Restaurant, then system shows Similar types of Product
on the display.

.1.1Cart
 User can add products in the cart and purchase it. User can buy more products at
same time via Cart. They edit, remove and add product in the cart.

.1.1Cart
 User can add Food to wish list if user want to buy food later.

.1.1Placed order
 By clicking on the Placed order User can buy food at that time.

.1.1Notifications
 Notification send to user for reminder, Order confirmation, as an alert and Offers.

.1.1Payment
 After buying of the product user need to pay the amount online OR Cash on Delivery.
If User want to pay online then they have different options like Credit Card, Debit
Card, Wallets, Net Banking.

.1.1Your Order
 Your Order is the one page where user can get all the Food details current as well as
previous orders.

.1.1Order Tracking
 User will able to track the order from this function.

.1.1Customer Care
 User can get in touch with customer care executive if user have any query or any
question.
Page | 7
BUSINESS REQUIREMENT DOCUMENT
 .1.1My Account
 From my account user can manage all the details of them like: Address, Phone
Number, Pin code, Email Id and many more.

.1.1Restaurant and Dishes Description Page

 Restaurant and Dishes description page shows all the description of the Particular
Product.

.1.1Filter
 Filter will be useful to get the specific product from the lots of Restaurant and
Dishes.

.1.1Sort
 From Sort function they get Restaurant and Dishes list in ascending or descending
Order OR Prise Low to High and High to Low.

.1.1Widget
 Widget will help to show slider and different Offers and Restaurant and Dishes.

.1.1Review/Rating
 User can review and rating the Restaurant and Dishes.

.1.1Coupons
 Coupon code scan apply at the time of purchase to get discount or get the benefit of
any offer.

.1.1Bills
 There will auto Bill generator after the buying of food and it will send to User on
register email id.

3.3 Out Functionalities

A. Fingerprint Login:
There is lack of fingerprint login which is safer and easier for the customers.

B. Restaurant and Dishes Video:

Vender must upload Restaurant and Dishes video to understand the Restaurant and
Dishes specifications clearly.

C. Virtual Restaurant and Dishes:

Vender must upload real photos of the Restaurant and Dishes.

Page | 8
BUSINESS REQUIREMENT DOCUMENT
D. HD Restaurant and Dishes Image:
Photos of the Restaurant and Dishes must be in high definition so that customer can
easily watch it and that will be more attractive for the customers.

E. Group Purchase:
There should an option to buy Restaurant and Dishes in group.

F. Language Issue:
There are many other language options based on different region.

4. Overall description
The following section presents an overall description of the subject RMOS. In particular, the product
has been put into perspective through a detailed assessment of the system, user, hardware,
software and communication interfaces, memory considerations, operational modes and site
adaptation requirements. Further, characteristics of the system’s end-users are discussed along with
the identified system constraints and assumptions. To conclude the section, an apportioning of
requirements has been outlined

4.1 Product Perspective

The Online Food Order System application would have the following basic functions:

A. Web Ordering System Module

This module provides the functionality for customers to place their order and supply necessary
details. Users of the system, namely restaurant customers, must be provided the following functionality:
 Create an account.
 Manage their account.
 Log in to the system.
 Navigate the restaurant’s menu.
 Select an item from the menu.
 Add an item to their current order.
 Review their current order.
 Remove an item/remove all items from their current order.
 Provide payment details.
 Place an order.
 Receive confirmation in the form of an order number.
 View order placed.

Page | 9
BUSINESS REQUIREMENT DOCUMENT
 B. Menu Management System Module

This module provides functionality for the power user-Administrator only. It will not be available
to any other users of the system like Restaurant Employees or Customers.
Using a graphical interface, it will allow an Admin to manage the menu that is displayed to users of the
web ordering system:
 Add/update/delete food category to/from the menu.
 Add /update/delete food item to/from the menu.
 Update price for a given food item.
 Update additional information (description, photo, etc.) for a given food item.
Before customers can use this system, functionality provided by this component will have to
be configured first. Once the initial configuration is done, this will be the least likely used component as
menu updates are mostly seasonal and do not occur frequently.

C. Order Retrieval System Module

This is the simplest module out of all 3 modules. It is designed to be used only by restaurant
employees, and provides the following functions:

 Retrieve new orders from the database.

 Display the orders in an easily readable, graphical way.

D. Environment and Technology requirement.

 Cloud hosting space will be used to entirely host the application.

 The application will be fully workable on PC, Mac machines/Android/iOS. The

minimal required hardware resources can be assumed as the same as for using for the
Project we have.
 Webpages are required to properly fit on mobile devices, working on iOS and
Android platforms.
 Application must be implemented in PHP (Web), Java (Android), Objective-C/Swift
(iOS) technologies.
 MySQL 5.1 will be used as a database.

Page | 10
BUSINESS REQUIREMENT DOCUMENT
5. Assumption

➢ List of Restaurant and dishes will be provided by the Client.

➢ Images of the Restaurant and dishes will be provided by the vendors.

➢ Images of the Restaurant and dishes will be in High Definition.

➢ Restaurant and dishes description will be provided by vendors.

➢ Terms and Conditions will be provided by legal team.

➢ Return Policy will be provided by legal team.

➢ Discount & Offers will be provided by the merchants.

➢ Newsletters and Emails will be provided by the marketing team.

➢ Company Address will be provided by the client.

➢ Company Contact Number will be provided by the Client.

➢ All the Content of the Company will be provided by the Client.

➢ Requirement will be Sign off by the Client.

6. Constraints
➢ Return Policy is subject to approval by legal team.

➢ Design is subject to approval by UI team.

➢ License is subject to approval by Government.

7. Workflow Diagram

Page | 11
BUSINESS REQUIREMENT DOCUMENT
7.1 Login & Registration Process Workflow Diagram

7.2 Order Placement Process Workflow Diagram

Page | 12
BUSINESS REQUIREMENT DOCUMENT
7.3 Order Replace, Return, Cancel and Tracking Process Flow Diagram

Page | 13
BUSINESS REQUIREMENT DOCUMENT
 Page | 14
BUSINESS REQUIREMENT DOCUMENT
8. FUNCTIONAL REQUIREMENTS

This subsection presents the identified functional requirements for the

subject Swiggy Clone. Initially, general requirements that pertain to the
whole system are given. Where possible, subsequent requirements have
been demarcated based on their relevance to the users of the system,
that is, Customers, Restaurants, Admin, Delivery boy and Dispute panel

Req ID Requirement Description

R1 Customer Shall be able to login or skip from registration to
enter the menu dashboard
R2 Customer shall be able to view nearby
restaurants(Specified Distance)
R3 Customers shall be able to choose their favourite restaurant
or restaurant they wish to order food
R4 Customer shall be able to view menu and categories and
subcategories involved

R5 Customer shall be able to order foods and add to cart

R6 Customer shall be able to remove orders from cart

R7 Customer shall be able to navigate between menu and can

add items to cart

R8 Customer shall be able to engage bill mode to finalise

payment through their engaged menu by cash

R9 Customer shall be able to disengage bill mode to cancel the

billing process through their engaged menu by card

R10 Customer shall be able to cancel the order

R11 When in billing mode, app shall display a representation of

a cash payment for the item ordered

R12 When in billing mode, app shall display a representation of

a bankcard payment for each customer

R13 Customer shall able to order item from wallet amount

Page | 15
BUSINESS REQUIREMENT DOCUMENT
 R14 Customer shall able to cancel order and if cancelled
money will be transferred to wallet to order food for next
time(If Card Payment)

R15 Customer shall able to receive delivery boy details once

order picked up

R16 Customer shall able to track the delivery boy details

R17 Customer shall able to give rating for restaurant and

delivery boy

R18 Customer shall able to favourite the restaurant

R19 Customer receives notification for order accepted and once

order picked and delivered

R20 Customer shall able to use offers for restaurants have

R21 Restaurant shall able to (CREATE, READ, UPDATE,

DELETE) items from menu
R22 Restaurant shall be able to receive orders from customers
R23 Restaurant shall be able to view the orders which has been
ordered by customers

R24 Restaurant shall be able accept or cancel order depends

upon the order received and availability of order

R25 Restaurant shall be able to assign delivery boy to deliver

order

R26 Restaurant shall be able to receive acknowledgement from

Delivery Boy

R27 Restaurant shall be able to view the payment

R28 Restaurant shall able able to receive notifications once

order delivered

R29 Restaurant shall able to give offers

Page | 16
BUSINESS REQUIREMENT DOCUMENT
 R30 Delivery boy shall able to start the shift

R31 Delivery boy shall able to receive incoming request from

restaurant

R32 Delivery boy shall able to acknowledge for the request

R33 Delivery boy shall able to toggle Online/Offline/Break

option

R34 Delivery boy shall able to reach the restaurant and check
with order details

R35 Delivery boy shall able to receive customer details from

restaurant

R36 Delivery boy shall able to pick up and deliver order to

customer

R37 Delivery boy shall able to receive rating from customers

R38 Delivery boy shall able to receive notification for

restaurant details, payment details of customer

R39 Delivery boy shall able to receive payment if order is done

with cash
R40 Admin shall able to Manage users

R41 Admin shall able to Manage providers

R42 Admin shall able to Mange accounts

R43 Admin shall able to CRUD items for restaurant

R44 Admin shall to manage restaurant details

R45 Admin shall to manage restaurant rate and reviews

R46 Admin shall able to manage Delivery boy details

R47 Admin shall able to display top rated restaurant

Page | 17
BUSINESS REQUIREMENT DOCUMENT
 R48 Admin shall able to display offers for specific restaurant

R49 Admin shall able to contact between Delivery boy and

restaurant to replace or cancel order if items are not
available

R50 Admin shall to add promo code/offers

R51 Dispute panel shall able to reassign order in the case, if

delivery boy dint acknowledge the request

R52 Dispute panel shall manage, if customer needs replacement

of order or cancel order in case of order not available

9. UML ANALYSIS MODEL

This subsection extends upon the functional requirements given through the
presentation of detailed use cases. To facilitate an unambiguous and clear view
of how the end-users interact with the Swiggy Clone system, the actors (end-
users) involved in the use cases, a use case diagram and detailed use case
descriptions are provided. The use cases that find representation are Log In, Log
Out, Accept Order, Deliver Item, Process Bankcard Payment, Process Cash
Payment, Abort Meal, Abort Account, Issue Refund, Place Order, Call Delivery
boy, Pay Bill, Accept/Reject Item and Indicate Item Ready.

Page | 18
BUSINESS REQUIREMENT DOCUMENT
9.1 Use case
There are four actors in the Swiggy are Customer, Restaurant, Admin,
Delivery Boy. While the Customer, Restaurant and Admin actors are base
specialisations, the Delivery boy interacts between both the Customer
and Restaurant actors as a generalisation.

Page | 19
BUSINESS REQUIREMENT DOCUMENT
9.3 Use case for Customer:

The actors involved in this use case are Customer, Delivery Boy and Admin.
User will be having a Social Login and Separate Signup Options. Unregistered
users can also view menu (Using Skip Option) and while ordering user should
sign-in. Once the user login, nearby restaurant will be displayed in the
Dashboard.
User can choose their own wish list restaurant and order foods. Once the order
is done, restaurant will accept the request based on the order done by user. User
can change menu based on the replacement menu given and can have different
dish or else say to cancel the order.
If user accepts replacement, restaurant will assign the order to Delivery boy.
Delivery boy should acknowledge the order request and reach the restaurant.
Once reached the restaurant, he checks for the order details which he received
and receives customer details from restaurant. Then, he picks the order and
delivers to the user. The payment can be done through cash or card, which
should be chosen once the order, is done.

Page | 20
BUSINESS REQUIREMENT DOCUMENT
 9.4 Use case for Restaurant:
Once customer confirms order, restaurant receives the order request.
Restaurant checks with order and confirms the availability and assign the
order to Delivery boy. Delivery boy needs to acknowledge the order and
reach the restaurant to pick the order. Once delivery boy reaches the
restaurant, he checks for the order details and deliver the order to
specified user

Page | 21
BUSINESS REQUIREMENT DOCUMENT
10. NON-FUNCTIONAL REQUIREMENT

Functional requirements define what a system is supposed to do and non-functional

requirements define how a system is supposed to be. A non-functional requirement is often
called Quality attributes of a system. They specify criteria that judge the operation of a
system, rather than specific behaviours, for example: “Modified data in a database should
be updated for all users accessing it within 2 seconds.”

10.1 Some typical non-functional requirements are:

➢ Security
It is important to specify the level of security that should be met.

➢ Privacy
Meeting basic requirements for GDPR.

➢ Scalability and performance

Ensuring that the system can scale to meet expected traffic and order volume at normal and
peak times.

➢ Speed of web services

Defining how long web services will take to provide a response.

➢ Accessibility
Ensuring that the platform meets the basic accessibility standards throughout.

➢ Documentation
Ensuring that the platform is sufficiently documented.

➢ Quality
Even the best e-commerce platforms can be used badly so you should insist that code is
developed to a good quality standard.

➢ Extensibility
Ensuring that the platform is extended in such a way to make future development feasible.

➢ Data integrity and retention

Defining how long data should be stored and how the integrity of data is maintained.

➢ Testing

Page | 22
BUSINESS REQUIREMENT DOCUMENT
Defining how unit testing will be built into the solution.

➢ Compatibility
Ensuring that the platform can be easily integrated with 3rd party systems.

➢ Search
Defining how quickly the system will return search results.

➢ Availability
Defining the agreed uptime of the platform under normal conditions.

➢ Infrastructure
Defining the infrastructure performance thresholds (CPU and memory usage).

Page | 23
BUSINESS REQUIREMENT DOCUMENT
11. DESIGN SPECIFICATION
11.1 DESIGN FLOW FOR USER
USER LOGIN/CREATE

ENTER RESIGSTER MOBILE NUMBER

Page | 24
BUSINESS REQUIREMENT DOCUMENT
 OTP VERIFICATION

MAIN MENU

Page | 25
BUSINESS REQUIREMENT DOCUMENT
 OFFER DISPLAYED

ITEM DESCRIPTION

Page | 26
BUSINESS REQUIREMENT DOCUMENT
 FILTER

ADD ITEMS

Page | 27
BUSINESS REQUIREMENT DOCUMENT
 MANAGE ADDRESS

ORDER DISPLAY

PROCCED TO PAY

Page | 28
BUSINESS REQUIREMENT DOCUMENT
 ORDER STATUS

ORDER STATUS
Page | 29
BUSINESS REQUIREMENT DOCUMENT
 ORDER STATUS

PROFILE EDIT
Page | 30
BUSINESS REQUIREMENT DOCUMENT
 FEEDBACK

MODE OF HELP

Page | 31
BUSINESS REQUIREMENT DOCUMENT
 CHAT PROCESS

Page | 32
BUSINESS REQUIREMENT DOCUMENT
 Page | 33
BUSINESS REQUIREMENT DOCUMENT