CHAPTER THREE

3.PROPOSED SYSTEM

3.1 Overview of the Proposed System

This part deals with the description of the proposed Food Delivery System, detailing
what will be accomplished in this section. It includes the purpose of the proposed
system, its functional and non-functional requirements, system requirements,
supplementary specifications, and the UML modeling used to visualize and design the
system.

Purpose of the Proposed System

The Food Delivery System is designed to streamline operations by automating various

aspects of restaurant management. Its primary purpose is to enhance efficiency,
reduce human error, improve customer service through fast food order delivery, and
provide a comprehensive overview of the restaurant's performance through data-
driven insights.

Functional Requirements

The functional requirements outline the specific behaviors and functions that the
system must perform. These include:

1. Order Management: Taking orders and tracking order status.

2. Payment Processing: Handling multiple payment methods, generating bills,
and managing transactions.
3. Customer Feedback: Collecting and managing customer feedback,
generating alerts for responses.

Non-Functional Requirements

1
These are the criteria used to judge the operation of a system, rather than specific
behaviors. These include:

1. Performance: The system should handle concurrent users efficiently with

minimal latency.
2. Reliability: The system must be robust and available 99.9% of the time.
3. Security: Implementing secure authentication, data encryption, and user
access control.
4. Usability: The system should be user-friendly and easy to navigate.
5. Scalability: The system should be scalable to accommodate future growth.

System Requirements

These include hardware and software requirements necessary for the development and
deployment of the system:

 Hardware Requirements:
o Server Hardware: Intel Xeon or AMD EPYC with a minimum of 8
cores, 32 GB RAM, 1 TB SSD, Gigabit Ethernet, and 2 TB external
backup.
o Client Devices: Tablets/Computers (Intel i5, 8 GB RAM, 256 GB
SSD, touch screen, Wi-Fi), POS Terminals (ARM Cortex, 4 GB RAM,
32 GB SSD, touch screen, Ethernet/Wi-Fi), Receipt Printers, Barcode
Scanners, Payment Terminals.
 Software Requirements:
o Frontend: ReactJS, HTML, CSS, JavaScript.
o Backend: Node.js, Express, MongoDB.
o Development Tools: Visual Studio Code, Git.

Supplementary Specification

This section includes additional specifications that support the main requirements,
ensuring that the system adheres to quality standards and user expectations.

UML Modeling

2
To model the proposed system, various Object-Oriented Analysis (OOA) models are
used:

1. Use Case Diagram:

o Represents the system’s functionality from the user’s perspective.
o Identifies the main actors and their interactions with the system.
2. Sequence Diagrams:
o Illustrates the sequence of interactions between objects to achieve
specific use cases.
o Shows how different components of the system interact over time to
complete a process.
3. Class Diagram:
o Depicts the system's static structure by showing system classes, their
attributes, methods, and relationships.
o Provides a blueprint of the system’s data and functionalities.
4. Activity Diagrams:
o Visualizes the dynamic aspects of the system by modeling the
workflow of various activities.
o Shows the flow of control or data from one activity to another.
5. State Chart Diagram:
o Represents the states of an object and transitions between these states.
o Models the dynamic behavior of individual system components.

Each of these models will be detailed under specific sub-titles, providing a

comprehensive view of the proposed system. This detailed modeling helps in
understanding, designing, and implementing the system efficiently.

3.2 Requirement Determination

3.2.1 Functional Requirements
The functional requirements of the proposed system outline the specific
functionalities that provides:

I. Order Management

3
  Take orders using a computer
 Send orders directly to the restaurant
 Update order status (e.g., In Progress, Ready, Served)

II. Menu Management

 Add, update, or remove menu items

 Display current menu to customers
 Manage special offers and discounts

III. Billing and Payment Processing

 Automatically generate bills based on orders

 Process various payment methods (cash, credit/debit card, digital wallets)

 Handle split billing for group payments

V. Customer Relationship Management (CRM)

 Store customer information and preferences

 Record customer feedback and complaints
 Send promotional offers and loyalty rewards

3.2.2 Non Functional Requirements

I. Performance

 Handle multiple transactions simultaneously with minimal delay

 Ensure quick response time for user interactions
 Support high-volume data processing during peak hours
 Achieve a response time of less than 2 seconds for 90% of user interactions, as
recommended by recent studies on user experience (Kumar et al., 2020)

II. Scalability

 Support increased number of users and data as the restaurant grows

 Maintain performance during peak hours
 Ability to scale up or down to meet changing business needs
4
  Use a scalable architecture that can handle increased traffic and data, such as a
cloud-based infrastructure (Alam et al., 2020)

III. Security

 Secure customer and payment data through encryption

 Implement user authentication and role-based access control
 Regular security audits and updates to prevent vulnerabilities
 Compliance with relevant security standards and regulations, such as PCI-DSS
for payment card industry (PCI Security Standards Council, 2022)

IV. Usability

 User-friendly interface for staff and customers

 Intuitive navigation and minimal training required
 Accessibility features for users with disabilities, as required by recent
accessibility guidelines (W3C, 2021)
 Consistent and clear error messages and feedback

V. Reliability

 High system availability with minimal downtime

 Regular backups and failover mechanisms to prevent data loss
 Redundancy and fault tolerance to ensure continuous operation
 Quick recovery from failures and errors, with a mean time to recovery
(MTTR) of less than 1 hour (Dantas et al., 2019)

VI. Maintainability

 Easy to update and maintain the system

 Modular architecture to facilitate enhancements and bug fixes
 Clear and concise documentation for maintenance and troubleshooting
 Ability to adapt to changing business needs and requirements, using agile
development methodologies (Conboy et al., 2019)

5
3.2.3 System Requirement

Hardware and Software Requirements

1. Hardware Requirements

1. Server Hardware:

 Processor: Intel Xeon or AMD EPYC with a minimum of 8 cores.

 Memory: 32 GB RAM or higher.
 Storage: SSD with at least 1 TB of storage capacity.
 Network: Gigabit Ethernet for high-speed network connectivity.
 Backup: External hard drive or NAS with at least 2 TB for backups.

2. Client Devices:
I. Tablets/Computers for Order Taking:
 Processor: Intel i5 or equivalent.
 Memory: 8 GB RAM.
 Storage: 256 GB SSD.
 Display: 10-inch screen or larger with touch capability.
 Network: Wi-Fi 802.11ac.
II. POS (Point of Sale) Terminals:
 Processor: ARM Cortex or equivalent.
 Memory: 4 GB RAM.
 Storage: 32 GB SSD.
 Display: 15-inch screen with touch capability.
 Network: Ethernet or Wi-Fi 802.11ac.
3. Peripheral Devices:
I. Receipt Printers: Thermal printers with Ethernet or USB connectivity.
II. Barcode Scanners: USB or Bluetooth-enabled barcode scanners.
III. Payment Terminals: Devices supporting EMV, NFC, and magnetic
stripe payments.

2. Software Requirements

1. Frontend:

6
  Technologies: ReactJS, HTML, CSS, JavaScript

2. Backend:

 Technologies: Node.js, Express

 Database: MongoDB

3. Development Tools:

 IDE: Visual Studio Code

 Version Control: Git

This comprehensive list of hardware and software requirements ensures that the
proposed system is built using current technology standards, providing a robust,
scalable, and efficient solution.

3.3 Supplementary Specification

The supplementary specification includes requirements that may not have been
captured during initial requirement determination through use cases, UI prototypes,
and CRC models. These um-captured requirements are essential for the
comprehensive functioning of the proposed Food Delivery System.

Security and Safety Procedures

To ensure the security and safety of the Food Delivery System and its users, the
following procedures will be implemented:

Security Procedures

1. Data Encryption:

- Use HTTPS for Secure Data Transmission: All data exchanged between the client
and the server will be encrypted using HTTPS to protect against eavesdropping and
man-in-the-middle attacks.

- Encrypt Sensitive Data Stored in the Database: Sensitive information such as user
passwords, payment details, and personal data will be encrypted in the database to
prevent unauthorized access in case of a data breach.

7
2. Authentication and Authorization:

- Implement Strong Password Policies: Enforce strong password policies requiring a

combination of letters, numbers, and special characters. Passwords will be stored
using secure hashing algorithms.

- Use JWT for Secure User Sessions: JSON Web Tokens (JWT) will be used for
user authentication and maintaining secure sessions, ensuring that only authenticated
users can access protected resources.

3. Regular Audits:

- Conduct Regular Security Audits and Vulnerability Assessments: Regularly

perform security audits and vulnerability assessments to identify and mitigate
potential security threats. These assessments will include code reviews, penetration
testing, and compliance checks.

Safety Procedures

1. Data Backup:

- Perform Regular Backups of the Database: Regularly backup the database to

ensure that data can be recovered in case of accidental deletion, corruption, or
hardware failure.

- Store Backups in a Secure, Off-Site Location: Store backup copies in a secure, off-
site location to protect against data loss due to physical damage to the primary site
(e.g., fire, flood).

2. Disaster Recovery:

- Develop and Maintain a Disaster Recovery Plan: Create a comprehensive disaster

recovery plan outlining steps to restore system functionality in case of a major
disruption. This plan will include procedures for data restoration, system recovery,
and communication with stakeholders.

- Regularly Test the Disaster Recovery Procedures: Periodically test the disaster
recovery procedures to ensure that they are effective and that staff are familiar with

8
the steps to take in an emergency. Regular testing will help identify any gaps or
weaknesses in the plan.

3.3.1 Business Rule

ID Name Description
BR-01 Customer All customers must register with a valid phone number before
Registration placing an order. Modifications to existing registration
information are allowed.
BR-02 Order Placement Customers can only place an order if they have provided a
Eligibility valid delivery address and selected at least one item from the
menu. Incomplete orders cannot proceed.
BR-03 Payment The system processes payments through integrated payment
Processing gateways (credit card, debit card, or wallet). Cash-on-delivery
Standards is allowed if enabled by the restaurant.
BR-04 Delivery Orders are automatically assigned to a delivery executive
Assignment based on proximity to the restaurant and customer location.
Protocol Admins can manually assign in exceptions.

3.3.2 Constraints

Platform Requirements

1. Compatibility with Legacy Systems

o The new system must integrate seamlessly with existing legacy
systems currently used by the restaurant, such as the accounting
software and older POS terminals.
o Technical Constraint: Ensuring compatibility with older systems may
require additional development time and resources.

2. Cross-Platform Support
o The system must be compatible with multiple operating systems
(Windows, Linux, macOS) and devices (desktops, tablets,
smartphones).
o Technical Constraint: Developing and testing the system across
different platforms increases complexity and resource requirements.

3. Network Dependence

9
 o The system should operate effectively even during network outages,
with the ability to synchronize data once connectivity is restored.
o Technical Constraint: Implementing offline functionality and
synchronization mechanisms can be complex and resource-intensive.

4. Data Protection and Privacy

o The system must comply with data protection regulations such as
GDPR, ensuring that customer data is securely stored and processed.
o Technical Constraint: Ensuring compliance may require additional
security measures and regular audits, increasing development and
maintenance costs.

Process Requirements

1. Project Timeline
o The system must be developed, tested, and deployed within a specified
timeframe, typically six months.
o Schedule Constraint: A tight development schedule may limit the
ability to implement all desired features and thoroughly test the
system.

2. Budget Limitations
o The development and implementation of the system must stay within
the allocated budget.
o Economical Constraint: Budget constraints may impact the choice of
technology, tools, and the scope of features that can be developed.

3. Development Team Expertise

o The development team should have expertise in the technologies and
platforms being used (e.g., React, Nodejs, MongoDB).
o Technical Constraint: Limited expertise may require additional
training or hiring of specialized personnel, affecting the project
timeline and budget.

4. Stakeholder Involvement

10
 o Regular input and feedback from key stakeholders (e.g., restaurant
managers, staff, customers) are necessary to ensure the system meets
user needs.
o Process Constraint: Coordinating with stakeholders and incorporating
their feedback can be time-consuming and may cause delays.

5. Regulatory Compliance
o The system must adhere to local and international regulations
regarding food safety, health, and safety standards.
o Political Constraint: Keeping up with changing regulations may
require ongoing updates and modifications to the system.

6. Third-Party Integration
o The system must integrate with third-party services such as payment
gateways, online reservation platforms, and food delivery services.
o Technical Constraint: Ensuring reliable and secure integration with
multiple third-party services can be complex and may require ongoing
maintenance.

These constraints outline the various restrictive conditions that impact the
development and Food Delivery System. Addressing these constraints effectively is
crucial for the successful completion and implementation of the project.

3.4 System Model

This part includes the various restrictive conditions that exist in providing/delivering
Food Delivery System. These constraints might be economical, political, schedule-
related, technical, or any other factors that hinder the development team and the
organization from meeting the objectives of the systems development project. These
constraints are similar to pseudo requirements and can be categorized as follows:

Platform Requirements

11
Platform requirements are constraints on the environment and technology of the
system:

1. Hardware Limitations: The system must be compatible with existing

hardware infrastructure, including servers, client devices, and peripheral
devices. Upgrading hardware may require significant investment.
2. Software Compatibility: The system should be compatible with the current
software ecosystem, including operating systems, databases, and development
tools.
3. Network Requirements: The system should operate efficiently within the
existing network infrastructure, ensuring reliable connectivity and data
transfer.
4. Security Standards: The system must adhere to industry security standards to
protect sensitive data and ensure secure transactions.

Process Requirements

Process requirements are constraints on the project plan and development methods:

1. Budget Constraints: The project must be completed within the allocated

budget, which may limit the scope of development and the ability to
incorporate advanced features.
2. Time-frame: The system must be developed and deployed within a specified
time-frame to meet organizational goals and customer expectations.
3. Resource Availability: The availability of skilled developers, designers, and
other personnel may impact the project timeline and quality.
4. Regulatory Compliance: The system must comply with local and
international regulations and standards related to data privacy, financial
transactions, and industry-specific guidelines.
5. Stakeholder Requirements: The system must address the needs and
expectations of various stakeholders, including management, employees, and
customers, which may require balancing conflicting priorities.

3.4.1 System Use Case Model

12
In this part of the project, we will develop the system use case model for the Gursha
Restaurant Management System. This involves identifying the key actors interacting
with the system, the use cases representing the system's functional requirements, and
documenting each use case. The following steps will be undertaken:

· 1. Actors Identification:
The actors are the primary entities that interact with the system. These are:

 Customer: End-users of the system who browse menus, place orders, and
provide feedback.
 Restaurant: Partners who manage their menu, receive and prepare orders, and
track order statuses.
 Delivery: Individuals responsible for picking up orders from restaurants and
delivering them to customers.
 Admin: System administrators who manage overall operations, resolve issues,
and ensure the smooth functioning of the platform.

2. Use Case Identification:

Identifying specific use cases that represent the key functionalities the system must
support. For example:

 User Registration
 Place Order
 Process Payment
 Assign Delivery Executive
 Manage Feedback

3. System Use Case Diagram:

A UML diagram is created to illustrate the interactions between the actors and the
system. It shows which use cases each actor participates in and the relationships
between the use cases themselves.

4. System Use Case Documentation:

Detailed documentation for each identified use case. This includes:

 Name: The title of the use case.

 Identifier: A unique ID for reference.
 Description: A short explanation of the functionality.
 Actor(s): The entities involved in the use case.
 Precondition: Conditions that must be met before the use case is executed.
 Postcondition: The expected outcome after the use case is executed.
 Basic and Alternative Flows: Steps describing how the functionality is
performed, including variations.

13
1. Use Case: User Registration

Field Description

Name User Registration

Identifier UC-01

This use case allows a new user to create an account in the system
Description
by providing necessary details.

Actor Customer

Precondition The user must not already have an account in the system.

Post condition The user is successfully registered and can log in to the system.

Extends None

Include Input Validation

1. The user navigates to the registration page. 2. The system prompts

Basic Course of the user to enter their details (name, phone number, and password).
Action 3. The system validates the input for completeness and correctness.
4. The system creates the account and stores user information.

Alternative If the user did not provide complete or valid details, the system
Course of displays an error message and prompts the user to re-enter the
Action required information.

2. Use Case: Place Order

Field Description

Name Place Order

Identifier UC-02

This use case allows a registered user to place an order for items
Description
from the restaurant's menu.

14
 Field Description

Actor Customer

The user must be logged into the system and have added items to
Precondition
the cart.

The order is successfully placed and a confirmation is sent to the

Post condition
user.

Extends None

Include Verify Delivery Address

1. The user reviews the items in the cart. 2. The system prompts the
Basic Course of user to confirm their delivery address. 3. The user selects the
Action payment method. 4. The system processes the payment and places
the order. 5. An order confirmation is sent to the user.

Alternative If the payment fails, the system informs the user and allows them to
Course of Action retry with a different payment method or cancel the order.

3.4.1.1 Identification of Actors

No Actors Description

A user who registers on the system, browses menus, places orders,

1 Customer
makes payments, and provides feedback after delivery.

A user who manages their menu, processes incoming orders, updates

2 Restaurant Owner
availability, and oversees order fulfillment.

A user responsible for picking up orders from restaurants and delivering

3 Delivery Executive
them to customers within the specified time.

A user responsible for managing the system, resolving technical issues,

4 System Administrator
handling disputes, and overseeing system updates.

An external actor that processes online payments, ensuring secure

5 Payment Gateway
transactions for customers and restaurants.

6 Support Staff A user responsible for assisting customers, delivery executives, or

15
No Actors Description

restaurant owners with queries or complaints.

3.4.1.2 Identification of System Use Cases

No Use Case Id Use Case Name

1 UC-01 User Registration

2 UC-02 Log In

3 UC-03 Browse Menu

4 UC-04 Place Order

5 UC-05 Process Payment

6 UC-06 Assign Delivery Executive

7 UC-07 Track Order

8 UC-08 Deliver Order

.3.4.1.3 System Use Case Diagram

The use case diagram for the Food Delivery System provides a visual representation
of the interactions between the identified actors and the system's functionalities. It
serves as a high-level overview, showcasing how different users engage with the
system and the key use cases they interact with.

In the diagram, actors are represented as stick figures, while the use cases are depicted
as ovals. Lines connect actors to the use cases they are involved with, illustrating the
relationships and interactions. This diagram aids in understanding the scope of the
system and facilitates discussions around system requirements.

A Use Case Diagram is a visual representation of the interactions between the actors
(users or external systems) and the system to achieve specific goals. It provides an
overview of:

16
  Actors: Represent entities (users or systems) that interact with the system.
 Use Cases: Represent the functionalities or processes the system supports.
 Relationships: Show the interactions between actors and use cases, as well as
any extensions or inclusions.

Use-Case Diagram for a Food Delivery System

Below is a description of the use-case diagram components:

1. Actors:

o Customer: Registers, places orders, and provides feedback.

o Restaurant Owner: Manages menu and orders.
o Delivery Executive: Delivers orders.
o System Administrator: Handles system management.
o Payment Gateway: Processes payments.

2. Key Use Cases:

o User Registration: Allows customers to sign up.

o Place Order: Enables customers to order food.
o Process Payment: Facilitates online payment.
o Assign Delivery Executive: Allocates a delivery agent for orders.

Key Components of the Diagram:

 Actors: customer, restaurant, delivery, admin.

 Use Cases: View Restaurant Menu, Add Item, Remove Item, Rate Restaurant,
Create Order, Cancel Order, Track Order, Pay for Order.

17
Figure 3 System Use Case Diagram

3.4.2 Conceptual Class Diagram

The conceptual class diagram is a vital modeling tool used during the analysis phase
of the system development life cycle (SDLC). It helps in identifying and organizing
the key entities (classes) within the proposed system and their relationships. The
primary purposes of using a conceptual class diagram in this phase are:

1. Clarification of System Structure: It provides a high-level view of the

system’s structure, showing the main classes and their attributes, which helps
in understanding the core components and functionalities.
2. Facilitating Communication: The diagram serves as a communication tool
among stakeholders, including developers, analysts, and non-technical
stakeholders, ensuring everyone has a shared understanding of the system's
data and relationships.
3. Foundation for Design: By identifying the classes and their relationships
early, it lays the groundwork for subsequent design and implementation

18
 phases, making it easier to develop detailed class diagrams and database
schemas later.
4. Identifying Relationships: It illustrates how classes interact with each other,
which is crucial for understanding data flow and dependencies within the
system.

Figure 4 Conceptual Class Diagram

3.4.3 Sequence Diagram

The sequence diagram is a dynamic modeling tool used in the analysis phase of the
system development life cycle, particularly from the perspective of Object-Oriented
(OO) design. Its primary purpose is to illustrate how objects interact in a specific
scenario over time. Here’s why we use this model:

19
1. Visualizing Interactions: Sequence diagrams help visualize the flow of
messages between objects, showing how they collaborate to complete a
particular use case. This aids in understanding the behavior of the system and
the timing of events.
2. Clarifying Use Case Scenarios: They provide clarity on how use cases are
realized through object interactions, helping to ensure that all functional
requirements are accounted for.
3. Identifying System Behavior: Sequence diagrams highlight the order of
operations and the relationships between different objects, which can reveal
potential issues or inefficiencies in the system design.
4. Supporting Communication: These diagrams serve as an effective
communication tool among stakeholders, facilitating discussions on the
system’s functionality and design.

20
Figure 5 Sequence Diagram

3.4.4 Activity Diagram

The activity diagram is a modeling tool used in the analysis phase of the system
development life cycle to represent the workflow of activities and the flow of control
within a system. Its primary purposes are:

1. Visualizing Workflows: Activity diagrams provide a clear visual

representation of the flow of activities, decision points, and parallel processes
within a use case, helping to illustrate complex workflows.
2. Clarifying Logic and Processes: They help in understanding the sequence
and conditions under which activities occur, making it easier to identify
bottlenecks, redundancies, and areas for optimization.
3. Supporting Requirement Analysis: By detailing the workflow, activity
diagrams facilitate discussions around requirements, ensuring that all
scenarios are considered during the design process.

21
Figure 6 Activity Diagram

3.4.5 State Chart Diagram

The state chart diagram is an essential tool in the analysis phase of the system
development life cycle, particularly from an Object-Oriented (OO) perspective. It is
used to model the dynamic behavior of an object over its lifecycle, highlighting the
various states an object can occupy and the transitions between those states. Here’s
why this model was used:

1. Modeling Dynamic Behavior: State chart diagrams capture how an object

responds to events over time, making them invaluable for understanding the
lifecycle of complex entities within the system.

22
 2. Clarifying State Transitions: They provide a clear visualization of state
transitions, allowing stakeholders to understand how an object changes state in
response to events or conditions.
3. Identifying State-Dependent Behaviors: The diagrams help identify
different behaviors associated with various states, which can be crucial for
designing system responses in different scenarios.
4. Supporting Requirement Validation: By modeling states and transitions,
state chart diagrams facilitate discussions around requirements, ensuring all
possible scenarios are accounted for and correctly implemented.

Figure 7 State Chart Diagram

23