GROUP -07

Software Requirements
Specification
(SRS) Document
Food Order & Delivery Management System
1. INTRODUCTION
1.1 Purpose
The purpose of this document is to define the software requirements for the Food Order &
Delivery Management System. The system allows users to order food online, select from
menus, and have it delivered efficiently with real-time tracking and secure payment
processing, ensuring a smooth experience for customers and delivery personnel.

1.2 Document Conventions

This document uses the following conventions for the Food Delivery System:
Labe Definition
l
DB Database
DDB Distributed Database
ER Entity Relationship
FDS Food Delivery System
API Application Programming Interface
OID Order Identifier
RID Restaurant Identifier
CID Customer Identifier
DP Delivery Personnel
RW Reward Points
D

1.3 Intended Audience and Reading Suggestions

 Customers: To understand the features and services provided by the system.
 Developers: To gain a clear understanding of functional and non-functional
requirements.
 System Administrators: To understand the administrative capabilities and
constraints.
 Testers: To derive test cases and scenarios from the requirements.
 Business Analysts: To ensure the requirements align with business goals.
Reader Guidelines:
  Section 2 (Overall Description): Begin here for a system overview.
 Section 3 (Specific Requirements): Refer here for detailed requirements.
 Appendices: Review for additional terminology and references.

1.4 Project Scope

The Food Order & Delivery Management System will act as a comprehensive platform
connecting customers, restaurants, and delivery personnel. It will support features such as
browsing restaurant menus, ordering food, secure payments, real-time tracking, and
restaurant/DP management. The platform aims to streamline operations and ensure a
seamless user experience, benefiting all stakeholders.

1.5 References
IEEE Standard 830-1998. Software Requirements Specifications. IEEE. Available at:
https://standards.ieee.org/standard/830-1998.html
Industry Standards for E-commerce Platforms. Available at:
https://www.w3.org/standards/
Documentation on Secure Payment Gateway Integration (e.g., PayPal, Stripe).
 PayPal API Documentation: https://developer.paypal.com/docs/api/overview/
 Stripe API Reference: https://stripe.com/docs/api
Guidelines for GPS Tracking API Usage.
 Google Maps Geolocation API Documentation:
https://developers.google.com/maps/documentation/geolocation/overview
 Oracle GPS API SDK:
https://docs.oracle.com/cloud/may2015/servicecs_gs/FAGPS.pdf
Local Regulations for Online Food Delivery and Data Protection Policies.
 Food Safety and Standards Authority of India (FSSAI): https://www.fssai.gov.in/
 Data Protection Policy – Delivery Drivers & Riders: https://beep.je/pdf/beep-data-
protection-policy-delivery-drivers-riders.pdf
2. OVERALL DESCRIPTION
2.1 Product Perspective
The Food Order & Delivery Management System stores the following information:
 Restaurant Details: It includes the restaurant name, location, menu items, pricing,
and availability of items.
 Customer Description: It includes customer ID, name, address, phone number,
and order history. This information may be used for order tracking, emergency
contact, or future promotions.
 Order Description: It includes customer details, order number, restaurant ID,
items ordered, total amount, order status, and delivery details.

2.2 Product Features

2.3 User Classes and Characteristics
Users of the system should be able to retrieve available food items and restaurants for
delivery between two locations (customer address and restaurant location) with the given
delivery date/time. Orders can include items from one or more restaurants, subject to delivery
constraints such as:
1. Orders can include items from at most two restaurants.
2. The delivery time must be within 30–60 minutes after the food is prepared.
The system will support two types of user privileges: Customer and Employee.
 Customers will have access to customer functions.
 Employees will have access to both customer and delivery management functions.
Customer Functionalities:
1. Place a New Order:
o Single Restaurant: Order food from one restaurant.
o Multi-Restaurant: Combine items from up to two restaurants in a single
order.
o Schedule Delivery: Set delivery for a future date/time.
o Order Confirmation: Receive details of the confirmed order.
2. Cancel an Existing Order:
o Cancel an order before preparation starts.
3. View Order History:
o Access details of all past orders.
4. Track Current Orders:
o Monitor real-time updates for food preparation and delivery.
5. Rate and Review Restaurants:
o Provide feedback and ratings for completed orders.

Employee Functionalities:
Customer Functions:
 Employees can perform all customer functionalities listed above.
Delivery Management Functions:
1. Get All Active Orders for a Restaurant:
o Retrieve ongoing orders being prepared by a specific restaurant.
 2. Get All Orders for a Delivery Personnel:
o View orders assigned to a specific delivery person.
3. View Delivery Schedule:
o Access a schedule of delivery assignments and their status.
4. Get Orders by Status:
o Retrieve all orders with specific statuses (e.g., Pending, Preparing, Delivered,
Cancelled).
5. Calculate Total Sales for a Restaurant:
o Compute revenue for a specific restaurant over a given time period.

Administrative:
1. Add/Delete Restaurants:
o Add new restaurants to the system or remove existing ones.
2. Add/Update Menu Items:
o Add new items to a restaurant menu or update details (price, availability, etc.).
3. Add/Delete Delivery Personnel:
o Manage delivery personnel profiles.
4. Update Delivery Status:
o Change the delivery status of an ongoing order (e.g., Out for Delivery,
Delivered).
5. Define Delivery Slots:
o Assign delivery time slots for restaurants and personnel.
o System Constraints:
1. Maximum Restaurants per Order:
o Orders can include items from no more than two restaurants.
2. Delivery Time:
o All deliveries must be completed within 30–60 minutes of dispatch.
3. Delivery Radius:
o Delivery locations must be within 20km of the restaurant.
4. Delivery Personnel Capacity:
o Each delivery person can handle up to three active orders simultaneously.
 5. Scheduled Orders:
o Scheduled orders must be prepared 30 minutes before the set delivery time.

2.4 Operating Environment

The operating environment for the food delivery management system is as listed below:
 Distributed database
 Client/Server system
 Operating system: Windows/Linux/MacOS
 Database: MySQL/PostgreSQL
 Platform: Java/PHP/Node.js
 Frontend technologies: React/Angular/HTML5
 Mobile application support: Android/iOS

2.5 Design and Implementation Constraints

1. The Global Schema, Fragmentation Schema, and Allocation Schema
Global Schema:
 The global schema defines the logical structure of the database. For the Food Delivery
System:
o Customers (customer_id, name, address, email, phone)
o Restaurants (restaurant_id, name, location, contact)
o Menus (menu_id, restaurant_id, item_name, price, availability_status)
o Orders (order_id, customer_id, restaurant_id, total_amount, order_status)
o Order_Items (order_item_id, order_id, menu_id, quantity, price)
o Delivery_Personnel (delivery_person_id, name, contact, vehicle_details)
o Deliveries (delivery_id, order_id, delivery_person_id, delivery_status,
delivery_time)
o Payments (payment_id, order_id, payment_method, payment_status)
Fragmentation Schema:
Data can be divided into fragments for efficient processing:
1. Horizontal Fragmentation: Split data by location (e.g., customers, orders, and
restaurants by city).
 o Example: Customers_CityA and Customers_CityB.
2. Vertical Fragmentation: Split tables based on frequently accessed attributes.
o Example: Restaurant_Basic_Info (restaurant ID, name) and
Restaurant_Contact_Info (location, contact).
3. Derived Fragmentation: Related fragments are grouped based on shared attributes like
restaurant_id.
Allocation Schema:
Data is distributed to servers based on location or usage:
 Customers and Orders: Allocated near customer locations.
 Restaurants, Menus, and Deliveries: Allocated near restaurant hubs.
 Payments: Centralized for secure transaction processing.

2. SQL Commands for Key Queries/Applications

a) Retrieve available food items for delivery between two locations:
sql
Copy code
SELECT m.item_name, m.price, r.name AS restaurant_name, r.location
FROM Menus m
JOIN Restaurants r ON m.restaurant_id = r.restaurant_id
WHERE r.location = 'Location1' AND 'Location2' IN (
SELECT location FROM Delivery_Personnel
WHERE delivery_person_id IN (
SELECT delivery_person_id
FROM Deliveries
WHERE delivery_status = 'Available'
)
);
b) Place an Order:
sql
Copy code
 INSERT INTO Orders (order_id, customer_id, restaurant_id, total_amount,
order_status, order_date)
VALUES (1001, 1, 10, 500, 'Pending', NOW());
c) Assign Delivery Personnel to an Order:
sql
Copy code
UPDATE Deliveries
SET delivery_person_id = (SELECT delivery_person_id FROM Delivery_Personnel
WHERE delivery_status = 'Available' LIMIT 1),
delivery_status = 'Assigned'
WHERE delivery_id = 101;
d) Calculate Total Sales for a Restaurant:
sql
Copy code
SELECT SUM(o.total_amount) AS total_sales
FROM Orders o
WHERE o.restaurant_id = 10 AND o.order_status = 'Completed';

3. Generating Responses for Global Queries

Scenario 1: Retrieving Food Items Between Two Locations
 Fragments Involved:
o Restaurants fragment (filtered by location).
o Menus fragment (linked by restaurant_id).
o Delivery_Personnel fragment (availability filtered by locations).
Process:
1. Query fragments to retrieve restaurants in Location1 and Location2.
2. Join the Menus table with filtered restaurants using restaurant_id.
3. Join the delivery personnel availability to determine feasible delivery options.
Combined Result: Food items and restaurants available for delivery.
Scenario 2: Calculating Total Sales for a Restaurant
 Fragments Involved:
 o Orders fragment (filtered by restaurant_id).
o Order_Items fragment (to calculate item-level prices, if needed).
Process:
1. Filter the Orders table by the restaurant_id and order_status = 'Completed'.
2. Aggregate the total_amount from the relevant fragments.
Combined Result: Total sales for the given restaurant.

4. Implementation Using a Centralized Database Management System

To implement the database for the Food Delivery System in a centralized DBMS:
Steps:
1. Database Setup:
o Use MySQL/PostgreSQL.
o Define schemas for all tables.
2. Table Creation:
sql
Copy code
CREATE TABLE Customers (
customer_id INT PRIMARY KEY,
name VARCHAR(100),
address VARCHAR(255),
email VARCHAR(100),
phone VARCHAR(15)
);

CREATE TABLE Restaurants (

restaurant_id INT PRIMARY KEY,
name VARCHAR(100),
location VARCHAR(100),
contact VARCHAR(50)
);
 CREATE TABLE Menus (
menu_id INT PRIMARY KEY,
restaurant_id INT,
item_name VARCHAR(100),
price DECIMAL(10, 2),
availability_status BOOLEAN,
FOREIGN KEY (restaurant_id) REFERENCES Restaurants(restaurant_id)
);

CREATE TABLE Orders (

order_id INT PRIMARY KEY,
customer_id INT,
restaurant_id INT,
total_amount DECIMAL(10, 2),
order_status VARCHAR(50),
order_date TIMESTAMP,
FOREIGN KEY (customer_id) REFERENCES Customers(customer_id),
FOREIGN KEY (restaurant_id) REFERENCES Restaurants(restaurant_id)
);
3. Data Insertion: Populate tables with initial data for customers, restaurants, menus, and
orders.
4. Application Integration: Use a centralized server running on Java/PHP with SQL
queries embedded into the application to interact with the database.
5. Testing: Validate that queries and updates (e.g., placing orders, assigning delivery
personnel) are executed correctly.

2.6 Assumptions and Dependencies

Let us assume that this is a distributed Food Delivery Management System and it is used in
the following applications:
 A request for placing/cancelling an order for food items from any restaurant to any
delivery location, with support for multi-restaurant orders if a single restaurant cannot
fulfill the order.
 Calculation of top customers (most frequent food orderers) and assigning
appropriate reward points based on their order history.
Assuming both the transactions are single transactions, we have designed a distributed
database geographically dispersed at four cities: Delhi, Mumbai, Chennai, and Kolkata, as
shown below:

Distributed Database Design

Application 1: Request for Placing/Canceling an Order
1. Description:
o A customer places or cancels an order using the system. If a single restaurant
cannot fulfill the order, it supports multi-restaurant orders.
o The system retrieves restaurants, menu items, and delivery personnel
availability from distributed fragments to process the request.
2. Steps:
o Placing an Order:
a) Retrieve the list of available menu items and delivery personnel from
fragments in the customer's location.
b) Assign delivery personnel, update the order status, and confirm the order.
o Cancelling an Order:
a) Update the Orders table to mark the order as canceled.
b) Release assigned delivery personnel and update the restaurant's menu
availability.
Application 2: Calculation of Top Customers
1. Description:
o The system identifies top customers (frequent orderers) from distributed
fragments and calculates reward points based on their total order value and
frequency.
2. Steps:
o Query customer order history across distributed fragments for each city.
o Aggregate order frequency and total spending for each customer.
o Calculate reward points and update the Rewards table.
3. SYSTEM FEATURES
3.1 DESCRIPTION and PRIORITY
The food delivery application manages information about restaurants, menus, food items,
delivery locations, pricing, and customer orders. This project has a high priority as it provides
convenience and efficiency in ordering and delivering food, meeting the demand for quick
and reliable food services.

3.2 STIMULUS/RESPONSE SEQUENCES

1. Search for Restaurants or Food Items
o Displays a detailed list of restaurants or food items based on user preferences
and location.
o Allows users to view menus and select items to add to the cart.
2. Place an Order
o Processes the selected food items and confirms the order.
o Displays an estimated delivery time and tracks the delivery status.
3. Cancel an Order
o Enables users to cancel an order before it is dispatched for delivery.

3.3 FUNCTIONAL REQUIREMENTS

DISTRIBUTED DATABASE:
The food delivery application uses a distributed database system to ensure seamless
operations across multiple locations and entities. It allows users to:
1. Access menus and food availability in real-time from various restaurants.
2. Process orders and manage delivery logistics efficiently across a network of
databases.
3. Maintain customer profiles, order histories, and preferences with high scalability and
reliability.
The application connects various data sources (e.g., restaurant systems, delivery personnel
data, and customer records) over a communication network, providing transparency and real-
time updates.

3.4 CLIENT/SERVER SYSTEM

The food delivery application follows a client/server architecture, dividing responsibilities
between:
1. Client (Front-End):
o User interface for searching restaurants, viewing menus, placing orders, and
tracking deliveries.
 2. Server (Back-End):
o DBMS that manages restaurant data, orders, customer profiles, and delivery
logistics.
Key Features:
 Distributed System: Some sites are clients (customer apps), others are servers
(centralized databases).
 Data at Server Sites: All data is stored and managed centrally.
 Applications at Client Sites: Users interact with the app, while the server processes
data requests.
4. EXTERNAL INTERFACE REQUIREMENTS
4.1 USER INTERFACES
 Front-end software: ReactJS or Flutter for cross-platform compatibility and modern
UI/UX.
 Back-end software: MySQL or PostgreSQL for database management.

4.2 HARDWARE INTERFACES

 Operating System: Windows, macOS, or Linux.
 Browser Support: Supports modern browsers that comply with HTML5, CSS3, and
JavaScript standards.

4.3 SOFTWARE INTERFACES

Software Used Description

Operating System Windows or Linux chosen for reliability and scalability.

MySQL/PostgreSQL to store restaurant details, customer data, and

Database
order history.

Programming ReactJS/Flutter for front-end and Node.js/Python (Django) for

Language back-end due to their modern support and flexibility.

4.4 COMMUNICATION INTERFACES

 Browser Compatibility: Compatible with all modern web browsers for customer
access.
 Communication Forms: Includes electronic forms for food ordering, cart
management, and payment processing.
 API Support: REST APIs enable seamless interaction between client and server
components.

5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps for implementing the food delivery system database are as follows:
A) E-R DIAGRAM
The E-R Diagram provides a pictorial representation of the database's logical structure, which
is used to organize data into relations, normalize these relations, and create a relational
database.
 ENTITIES: Represent key real-world components in the application, such as
Customers, Restaurants, Delivery Personnel, Orders, and Food Items.
 PROPERTIES/ATTRIBUTES: Represent characteristics of entities, such as
Customer Name, Order ID, Restaurant Location, and Food Price.
 RELATIONSHIPS: Define meaningful dependencies, such as "Places Order"
between Customers and Orders, or "Prepares Food" between Restaurants and Food
Items.
The E-R Diagram illustrates the relationships between these entities in the food delivery
system.

B) NORMALIZATION
Normalization minimizes redundancy in the database by ensuring that:
 Data is stored only once, reducing storage wastage.
 Relationships between entities are optimized to avoid duplicate or inconsistent data.
For example:
 Separate tables for Restaurants, Menus, and Orders to ensure that changes to a
restaurant menu do not require updating multiple records.
 Linking tables through primary and foreign keys, such as linking an Order table to a
Customer table via Customer ID.

5.2 SAFETY REQUIREMENTS

In the event of catastrophic failure (e.g., server crashes or data corruption), the recovery
process restores the database using:
1. A past backup copy stored on archival storage (e.g., cloud or tape).
2. Reapplying logged transactions to bring the database to its most current state prior to
the failure.

5.3 SECURITY REQUIREMENTS

The food delivery system must implement robust security measures, as sensitive customer
data and financial transactions are handled. These include:
 Encryption of sensitive data such as payment details and personal information.
 Role-based access control to limit unauthorized access.
 Secure database storage for user and system data, ensuring compliance with data
protection regulations.

5.4 SOFTWARE QUALITY ATTRIBUTES

AVAILABILITY:
 The application must provide uninterrupted service, allowing users to place orders and
track deliveries anytime.
CORRECTNESS:
 Orders should be delivered to the correct address with the right items. Restaurant
menus and item availability should be accurately displayed.
MAINTAINABILITY:
 The system should support regular updates for bug fixes, security improvements, and
compatibility with new devices or technologies.
USABILITY:
 The application should meet diverse customer needs, offering intuitive navigation and
accessibility across devices (desktop, mobile, and tablets).