WACHEMO UNIVERSITY COLLEGE OF

ENGINEERING & TECHNOLOGY DEPARTMENT OF

SOFTWARE ENGINEERING

A senior project submitted for the partial fulfillment of B.Sc. in

Software Engineering

Project title: CrowdScourced Delivery platform

Under the guidance of Miss Fozia A.

Group members
Name ID
Amanuel Fentahun ……………………………….1303883
Amanuel Desalegn ………………………….........1308166
Kirubel Deke ……………………………………..1402409
Mebratu Dejene …………………………………. 1402430
Yordanos Mengistu …………………………........1307550

Date: - 1/24/2025
Contents
CHAPTER ONE........................................................................................................................................................ 4
1.1. Introduction................................................................................................................................................... 4
1.2. Background of the organization....................................................................................................................4
1.3. Organization Structure..................................................................................................................................5
1.4. Statement of problem.....................................................................................................................................6
1.5. Literature Review and Related Work............................................................................................................6
1.6. Objectives of the project.................................................................................................................................8
1.6.1. General Objective....................................................................................................................................8
1.6.2. Specific Objectives...................................................................................................................................8
1.7. Significance of the Project..............................................................................................................................9
1.8. Feasibility Study............................................................................................................................................. 9
1.8.1. Technical Feasibility Study.....................................................................................................................9
1.8.2. Operational Feasibility Study...............................................................................................................10
1.8.3. Economic Feasibility Study...................................................................................................................10
1.8.4. Legal Feasibility Study..........................................................................................................................11
1.8.5. Political Feasibility Study......................................................................................................................11
1.9. Beneficiaries of the System...........................................................................................................................11
1.10. Methods and tools.......................................................................................................................................13
1.10.1. Requirements gathering techniques...................................................................................................13
1.10.2. System Analysis and Design Methods................................................................................................14
1.10.3. Requirement validation & verification..............................................................................................15
1.10.4. System Implementation Methods.......................................................................................................15
1.10.5. Development Environment and Programming Tools........................................................................16
1.11. Scope and Limitation..................................................................................................................................18
1.11.1. Scope.....................................................................................................................................................18
1.11.2. Limitations...........................................................................................................................................19
1.12. Task and Schedule.......................................................................................................................................19
1.12.1. Time Plan.............................................................................................................................................19
1.12.2. Budget Planning..................................................................................................................................20
CHAPTER 2.............................................................................................................................................................21
DESCRIPTION OF THE EXISTING SYSTEM...................................................................................................21
2.1. Introduction.................................................................................................................................................. 21
2.2. Business Rules and Constraints...................................................................................................................21

1
 2.3. Functions or Main Activities of Existing System........................................................................................23
2.4. Players of Existing System...........................................................................................................................24
2.5. Documents used in the Existing System......................................................................................................24
2.6. Strength and Weakness of the Existing System..........................................................................................25
2.6.1. Strength of the Existing System............................................................................................................25
2.6.2. Weakness of the Existing System..........................................................................................................25
2.6.2.1. Alternative solutions.......................................................................................................................26
CHAPTER 3.............................................................................................................................................................28
PROPOSED SYSTEM............................................................................................................................................ 28
3.1. Introduction.................................................................................................................................................. 28
3.2. Description of the Proposed System............................................................................................................28
3.2.1. User Characteristics..............................................................................................................................28
3.2.2. Constraints.............................................................................................................................................29
3.2.3. Assumptions and Dependencies............................................................................................................29
3.3. Requirement Specifications..........................................................................................................................30
3.3.1. Functional Requirement.......................................................................................................................30
3.3.2. Non-functional Requirement................................................................................................................32
3.4. System Modeling...........................................................................................................................................32
3.4.1. Actor Identification...............................................................................................................................33
3.4.2. Use-Case Identification.........................................................................................................................34
3.4.3. Use-Case Diagram.................................................................................................................................35
3.4.4. Description of Use-Case........................................................................................................................36
3.5. Requirement Analysis...................................................................................................................................51
3.5.1. Activity Diagram....................................................................................................................................51
3.5.2. Sequence Diagram.................................................................................................................................55
3.5.3. Requirement validation & verification................................................................................................59
3.5.3.1. Validity checks..................................................................................................................................60
3.5.3.2. Consistency checks...........................................................................................................................60
3.5.3.3. Completeness checks.......................................................................................................................61
3.5.3.4. Realism checks.................................................................................................................................61
3.5.3.5. Verifiability.......................................................................................................................................61
References................................................................................................................................................................. 63

2
3
 CHAPTER ONE

1.1. Introduction

Cities like Hossana, a rapidly developing urban center in Ethiopia's Central Region, face
challenges in establishing a formalized and automated delivery infrastructure. Based on

4
observations and feedback from local residents and businesses, delivery services for essential
items, specially for food are largely managed through informal and as the same time through
semi-automated delivery arrangement. This indicates a potential need for a structured, web-based
delivery platform to improve efficiency and accessibility.

Crowdsourced delivery systems represent a modern solution to such challenges by leveraging the
power of decentralized networks. In these systems, independent drivers or delivery providers,
often equipped with their own vehicles, accept delivery tasks through a digital platform.
Customers place orders through an app or website, which connects them to nearby delivery
Coordinator. This approach is cost-effective, scalable, and efficient, as it utilizes local resources
and reduces the need for dedicated delivery fleets. (Patel, 2024)

The primary objective of this project is to develop a Crowdsourced Delivery Platform that links
customers with local businesses and delivery providers by Eliminate limitation of the current
exiting delivery system in Hossana. This platform will allow customers to place orders from
nearby vendor, features like order tracking for customers, secure payment options to improve
trust, and creating opportunity for local businesses in hossana for effective order management
and increase in exposure. Additionally, creating a job opportunity for the local drivers.

In completion of this project, we aspire to deliver a transformative delivery platform that fulfills
the needs of residents and businesses in Hossana by use the current existing manual delivery
system as reference.

1.2. Background of the organization

The Ezezugn delivery system was launched on December 31, 2024, in Hossana. It is designed to
facilitate food delivery directly to residents' homes. Its primary objective is to improve the
connection between local restaurants and customers, effectively minimizing logistical challenges
in the delivery process. In addition to improving access to food services, the platform is
committed to supporting local restaurants and hotels, fostering a thriving ecosystem that benefits
the consumers and suppliers within the city.

In the Ezezugn delivery system, the customer places an order by providing their name and phone
number through the web app. Once the customer submits the order, the system generates an order
ID and notifies the call center. Additionally, the order is also visible to administrators.

5
The call center then contacts the vendors directly to place the order. Following that, they call an
available driver and provide the order details, including pickup and destination information,
along with the customer's contact details. The driver then goes to the vendor to pick up the order
and delivers it to the destination.Upon arrival, the customer receives the order from the driver
and pays the total fee via cash on delivery.

Despite its efforts, Ezezugn delivery system is semi-automated. It faces several challenges in its
day-to-day operations, particularly with the involvement of multiple parties. For example,
customers are offered only one payment option, and the system lacks real-time tracking. These
issues interfere the system’s ability to effectively and efficiently fulfill its broader objectives.

1.3. Organization Structure

CEO

Manager

Marketing
Call Center
Team

Grpahic Social media

Driver
Designer manager

Figure 1.1. Organization structure

1.4. Statement of problem

The existing delivery system presents significant operational challenges, including delayed
deliveries, a lack of order tracking for customers, insufficient payment integration, and issues
with customer responsiveness after order placement, which can lead to dire consequences for
drivers. Vendors find it difficult to manage multiple orders efficiently, limiting their customer
reach and resulting in a suboptimal customer experience.
6
Additionally, the current system struggles with driver matching because it does not include third-
party integrations. As a result, delivery fees are fixed regardless of the distance from different
locations. Furthermore, the absence of a driver portal prevents drivers from accessing order
details and customer locations, leading to potential delays in deliveries and customer
dissatisfaction.

Overall, Ezezugn Delivery faces these issues despite having semi-automated features available
only for clients. Other functionalities, such as driver assignment, vendor notifications regarding
orders, and the delivery process, are still handled manually by personnel. These challenges
significantly restrict local vendors' ability to expand their customer base and enhance their
services.

A crowdsourced delivery platform could automate these processes, offering real-time order
tracking, secure online payment integrations, efficient driver management including matching,
and variable delivery fees based on the distance of the order.

Implementing a crowdsourced delivery platform benefits various stakeholders. Furthermore, the

growth of local businesses contributes to a stronger economy, creating a mutually beneficial
environment for all parties involved.

1.5. Literature Review and Related Work

Reviewed literature:

Online crowdsourced truck delivery using historical information: (Huili Zhang a, 2021)This
study introduces the Online Crowdsourced Truck Delivery (OCTD) problem, modeled as an
online bipartite hyper-matching problem, and develops algorithms that utilize historical data to
improve delivery efficiency. Two cases, inseparable and separable orders, are addressed with
innovative algorithms like Hyper-Matching and Separable-Hyper-Matching, which
outperform existing methods.

Industry Status and Platform Classification: (Aliaa Alnaggar, 2019)Analyze the industry
landscape of crowdsourced delivery, categorizing platforms based on matching mechanisms,
target markets, and compensation schemes. The study bridges gaps between theoretical
operations research (OR) models and practical applications, identifying critical challenges like

7
matching efficiency and real-world constraints. It highlights emerging research areas focusing
on the unique attributes of crowdsourced delivery platform.

Crowdsourced delivery and customer assessments of e‐Logistics Service Quality: (Ha Ta,
2023)This study explores how customers perceive the quality of crowdsourced delivery (CD)
compared to traditional delivery methods, focusing on key dimensions like timeliness, price,
and reliability. Findings reveal that CD is particularly valued for high-turnover products
requiring minimal effort, enhancing customer experience. The research highlights CD's potential
for improving last-mile delivery and tailoring customer segmentation strategies.

Improve deliveries through crowdsourcing: (Arslan, 2017) This research highlights the
growing impact of internet shopping on retail, which pressures retailers to reduce delivery times
and improve speed. It identifies crowdsourced deliveries, utilizing ad-hoc external parties, as a
cost-effective solution to mitigate increased transportation costs and maintain operational
efficiency, compared to using dedicated delivery fleets.

Risks and Rewards of Crowdsourcing Marketplaces: (Chandler, 2013)This explores the

strengths and challenges of crowdsourcing through microtask labor marketplaces like Amazon
Mechanical Turk, focusing on managing human and hybrid human-machine computing.
Crowdsourcing enables flexible problem-solving by leveraging the diverse skills, perspectives,
and time of a large, fluid workforce. It highlights the importance of data quality, task design, and
proper incentives to minimize errors and increase outcomes. Examples like the Oxford English
Dictionary and Innocentive illustrate how crowdsourcing can solve complex problems and
aggregate large-scale contributions effectively.

Crowdsourced Delivery as a Dynamic Pickup and Delivery Problem (DPDP): (Alp Muzaffer
Arslan, 2018) introduce a rolling horizon framework to address the DPDP, incorporating ad
hoc drivers alongside dedicated vehicles. Their experiments demonstrate potential cost-
efficiency improvements of up to 37% in vehicle miles. The study emphasizes the need for
adaptive algorithms to manage real-time operations and explores the impact of driver behavior
on system performance, suggesting that hybrid models increase scalability.

Related Works

8
In our exploration of related works that inform the development of our crowdsourced delivery
solution, we examine In Ethiopia, local platforms like BeU, Zmall, and Tikus Delivery have
emerged to address challenges in food and package delivery services. BeU offers an intuitive
app-based solution for food delivery, catering primarily to urban areas with a focus on
restaurants. Zmall expands beyond food to include a variety of goods, providing a complete e-
commerce experience. Tikus Delivery, on the other hand, specializes in quick and affordable
delivery of everyday essentials and packages. These platforms aim to increase the delivery
process for local businesses and customers, though they still face limitations in infrastructure and
technology compared to global counterparts.

Internationally, platforms like UberEats, DoorDash, Postmates, and Dropoff have revolutionized
delivery services with advanced features like real-time tracking, optimized route navigation, and
payment integration. UberEats and DoorDash focus on food delivery, offering vast restaurant
networks and personalized recommendations. Postmates extends its services to include groceries
and other goods, while Dropoff caters primarily to businesses with same-day courier services.
These platforms leverage robust technology and data analytics to provide efficient, customer-
centric solutions, setting benchmarks for innovation in the delivery industry.

1.6. Objectives of the project

1.6.1. General Objective

To develop a web-based platform that facilitates delivery services through crowdsourcing in

Hossana, Ethiopia.

1.6.2. Specific Objectives

Here are some of specific objectives of the project:

 Gather detailed requirements.

 Analyze the gathered requirements.
 Design the platform architecture, database, and user interface.
 Implement a crowdsourced delivery platform.
 Test the platform.
 Deploy the platform.

9
  Providing ongoing maintenance.

1.7. Significance of the Project

The Crowdsourced Delivery Platform solution has a lot of socio-economic value for regional
cities like Hossana, Ethiopia, addressing the delivery ecosystem that is in desperate lag in the
area. Through the system's implementation of a tech-based, web-based solution, it aims to:

 Making Life Easier for Residents: Access to food without needing to travel physically
or make informal pickup arrangements.
 Local Economic & Business Growth: Businesses can increase operations, visibility and
local sales, leading to sustainable growth of the local economy of regional cities.
 Creating Jobs: Providing flexible income streams to individuals with motorbikes or
bicycles, predominantly young people, boosting local employment.
 Driving Digital Transformation: Aligning with Ethiopia digital development goals by
introducing modern delivery solutions that will support the adoption of technology in
regional cities.
 Promote Digital Literacy: Help the use of online ordering, secure payments, and order
tracking among residents and businesses, promoting digital skills and confidence.

This system aims to bridge the gap between local businesses and customers while contributing to
Ethiopia’s broader goals for economic and technological progress.

1.8. Feasibility Study

1.8.1. Technical Feasibility Study

The project will utilize a scalable technology stack, featuring React for the frontend, Node.js for
the backend, and Postgres SQL or similar databases for flexible data storage. To enable real-time
delivery tracking, geolocation services such as Google Maps API will be integrated, while secure
payment processing will be managed through Tele-Birr, Chapa, SantimPay or ArifPay. Security
measures will include SSL encryption and password hashing. The platform will be hosted on a
scalable cloud infrastructure to support growth, with real-time notifications provided by Firebase
Cloud Messaging. It will be compatible with Android, iOS, and desktop devices, ensuring wide

10
accessibility. Local drivers will operate as freelancers, and vendor will have the ability to manage
their menus and orders through the system.

1.8.2. Operational Feasibility Study

The project shows strong operational potential, as the semi-automated delivery system has
already gained traction with customers who are familiar with digital platforms, which have
successfully penetrated the local market. This familiarity ensures a smooth transition to the
proposed system. Local drivers, who are comfortable using mobile devices, are eager to work as
freelancers, ensuring that deliveries are made on time. The system will offer affordable payment
options and allow customers to select from a variety of restaurants. There is a clear demand for
reliable and cost-effective delivery solutions in Hossana, and the growing use of digital platforms
is likely to encourage user engagement. Furthermore, the platform will feature essential
Customer Assistance Technology (CAT) support, including real-time order tracking, timely
notifications, driver mapping, and additional support services.

1.8.3. Economic Feasibility Study

The project’s primary costs include software development, cloud hosting, and third-party API
integrations for payment processing, google map API and notifications, with plans to secure
initial investment for API integration while keeping other development expenses manageable.
Operational costs will be optimized through scalable cloud infrastructure. The revenue model
will rely on an affordable transaction fee per delivery, ensuring sustainable income while
remaining accessible to users. Payments to drivers will be transparent and fair, fostering a
motivated workforce. High market demand from local businesses and customers justifies the
system, as it provides a reliable and cost-effective delivery solution. The platform will be design
to scale beyond Hossana as demand grows, supported by internet access improvements and
added features like business promotions to encourage repeat usage. By creating jobs for local
drivers and expanding customer reach for businesses, the system will stimulate the local
economy and drive digital transformation in the region.

1.8.4. Legal Feasibility Study

The system will fully comply with Ethiopian Civil and Labour Law, ensuring that all operations
meet local legal standards. This includes adhering to Proclamation No. 1321/2024, (GAZETTE,

11
Personal Data Protection, 2024) which safeguards user privacy and ensures the secure handling
of personal information. We will also comply with Proclamation No. 980/2016, (GAZETTE,
Commercial Registration and Licensing Proclamation, 2016) to obtain the necessary business
licenses and permits. Contracts and agreements with drivers, businesses, and customers will be
drafted in accordance with Proclamation No. 1156/2019 on Labour law, (Portal, 2019) .
Additionally, compliance with Proclamation No. 813/2013, (GAZETTE, Trade computation and
consumer protection, 2014) and relevant tax regulations will be ensured. These measures provide
a robust legal framework for the platform, minimize disputes, and build trust among
stakeholders.

1.8.5. Political Feasibility Study

The development of this system aligns with Ethiopia's goals for digital transformation and
fostering innovation, as outlined in various national development strategies and reports. For
instance, the Digital Transformation Strategy for Ethiopia (Demissie, 2020), which aims to
improve the country’s digital infrastructure and improve service delivery, emphasizes the
importance of technology-driven solutions, which validate the feasibility of the project.
Additionally, Ethiopia’s policies encouraging the growth of small and medium enterprises
(SMEs), particularly in the digital space, as seen in the (Industry Development Strategy of
Ethiopia, 2002), create a favorable environment for services like ours. These policies align with
national priorities and significantly improve the likelihood of successful implementation.

1.9. Beneficiaries of the System

 Customers

o Faster and more flexible delivery options.

o Access to a wide range of products and services, including food, groceries, and
packages.

o Convenience of ordering from anywhere using web app and receiving goods at
their doorstep.

o Tracking systems to monitor order status and delivery progress.

o Cost-effective delivery charges compared to traditional methods.

12
 Delivery Drivers

o Flexible working hours allowing drivers to work part-time or full-time at their

convenience.

o Opportunity to earn income without needing to commit to a formal job.

o Access to consistent demand through the platform, reducing idle time.

o Increase networking opportunities.

 Vendors or Local Business Owners

o Increased sales by reaching a broader customer base beyond physical stores.

o Reduced logistics costs by outsourcing delivery operations to the platform.

o Improved visibility through the platform, which acts as a marketing channel.

o Improved customer satisfaction with reliable and efficient delivery services.

 Team Members (Platform Developer)

o Career opportunities in managing, optimizing, and supporting logistics operations.

o Professional growth through working on innovative, scalable, challenging

technologies, and problem-solving skill which may we apply in the real world.

o Engagement in a dynamic, technology-driven industry with room for innovation.

o Exposure to operational challenges that foster skills in problem-solving and

strategic planning.

 Local Economy

o Job creation for drivers, platform staff, and local businesses.

o Strengthening small businesses by connecting them to customers.

o Fostering economic activity by increasing access to goods and services.

 Payment Service Providers (e.g., Ethio Telecom)

o Benefit from transaction fees associated with payment integrations.

13
 o Increased usage of mobile payment solutions as customers engages with the
delivery platform.

 Government Organizations

o Potential for tax revenue from increased business activity and job creation.

o Opportunities for public-private partnerships that can drive technology adoption

and innovation.

1.10. Methods and tools

We have chosen the Iterative Waterfall methodology as our approach for this project because it
aligns well with our project's scope, structure, size and dynamic needs. This methodology allows
us to follow a structured, phase-by-phase process while incorporating feedback loops to revisit
and refine earlier stages as necessary.

Using this approach, we will first complete the documentation of the requirements and system
design before moving on to the implementation phase. However, unlike the traditional Waterfall
methodology, the Iterative Waterfall approach provides the flexibility to revisit and adjust
previous stages based on feedback from our instructor or unforeseen challenges. This ensures
that potential issues or overlooked requirements can be addressed promptly, reducing errors
during development and ensuring the system meets expectations.

1.10.1. Requirements gathering techniques

The project team uses the following Requirements gathering techniques to understand the
problem from the existing system.

Interview:

Interview was one of our methods used during gathering the requirements for our
crowdsourced delivery platform. We have tried to gathering some important information
by interviewing an existing system owner. In doing so, we collected detailed information
on how the existing system works and other important aspect of its business rules.

In our interview session they told us that first they aimed at automating the manual
delivery system in Hossana. Currently they are accepting order through web app.

14
Customer needs to provide some basic information such phone number, name and
password. They have also call center which helps them to contact with the vendors and
drivers for placing order and assigning available free driver. They have also managers,
marketing department and chief executive officer. These stakeholders have different roles
and level of access in the system. They have also told us that they do formal agreement
with the vendors and drivers. Lastly, they said that they will continue improving they
system to make delivery effective and efficient and reach out customers in a better way.
The interview session was very interesting and has laid groundwork for our proposed
system

Observation

As the word observation implies, we tried to closely observe Ezezugn delivery existing system to
get a clear understanding on how the current existing system operate on their daily task and to
get a clear understanding about the problems that exist in the current system. We observed how
orders are handled and delivered to the customers.

1.10.2. System Analysis and Design Methods

To analyze and design the system, we will use the following methods:

 Use Case Modeling

 We are going to use use-case diagrams to define the functional requirement the
proposed system clearly in a diagram and to identify actors and their role.

 Entity Relationship Diagram (ERD)

 ERDs will be used to design the database structure, defining the relationships
between entities such as orders, users, and delivery tasks.

 Unified Modeling Language (UML)

 UML diagrams, including class diagrams and sequence diagrams, will be used to
model system behaviors and interactions.

1.10.3. Requirement validation & verification

Validation: Are we building the right product?

15
We aim to ensure that we are building the right product while automating the current existing
system by developing a requirements specification based on the needs and goals of the
stakeholders, including vendors, customers, and drivers. To validate these requirements, we plan
to engage directly with these stakeholders through interviews and discussions. Their feedback
will guide us in aligning the system's design with their expectations, ensuring that the product
addresses their actual needs.

Verification: Are we building the product, right?

To verify that we are building the product correctly, we will focus on gathering accurate and
complete requirements directly from the stakeholders. This process will involve documenting
their needs thoroughly and reviewing the requirements at every development stage. Regular
reviews and stakeholder feedback will allow us to verify that the system design and
implementation align with the outlined requirements, minimizing any potential gaps between
expectations and the final output.

1.10.4. System Implementation Methods

The System Implementation Methods section outlines the process and strategies for
implementing the proposed system, translating the design into a functional product. The
implementation begins with modular development, where the system is divided into smaller,
manageable modules such as user authentication, order management, and delivery tracking.
Next, these modules are integrated incrementally, allowing the system to be built gradually while
ensuring each module functions as intended.

During development, version control and collaboration tools like Git and GitHub are utilized
to manage code versions and facilitate teamwork among developers. Testing is conducted at
every stage, with unit testing performed on individual components for accuracy and integration
testing used to verify the combined functionality of the modules.

Once the system is functional, user training sessions are conducted to familiarize end-users,
such as vendors, drivers, and administrators, with the system’s features. Feedback is gathered
during these sessions to refine and improve the system, ensuring it aligns with user expectations.
Finally, the system is deployed to a production environment using local hosting service

16
providers. These methods collectively ensure that the system is developed, tested, and deployed
in a structured, efficient, and user-focused manner.

1.10.5. Development Environment and Programming Tools

Here are most tools and environment we will use for our system development:

Category Tools/ technologies purpose

Development Environment Visual Studio Code Writing code locally.

(VSCode)

Programming Tools JavaScript, HTML, CSS Building dynamic and

responsive user interfaces.

Node.js with Express Server-side logic and routing,

ensuring efficiency and
scalability.

MongoDB (NoSQL) or Flexible and reliable data

PostgreSQL (SQL) storage based on scalability
and data structure needs.

Socket.io Enabling live order tracking

and notifications.

Design Tools Visual Paradigm Designing system

architecture and modeling
components using UML
diagrams.

Figma Creating user-centric designs

and prototypes to increase
user experience.

17
 Version Control Git and GitHub Managing code versions,
collaboration, and
maintaining a history of
changes.

Mapping Services Google Maps API Providing real-time tracking

and map services.

Payment Solution Tele-birr, chapa Supporting secure, cashless

transactions widely used in
Ethiopia.

Hosting Providers Local hosting services (e.g., Hosting the system in the
Yegara.com) production environment.

API Testing Postman Testing and documenting

APIs to validate interactions
between front-end and back-
end.

Automated Testing Selenium Automating front-end testing

to ensure interface
functionality across various
browsers and platforms.

1.11. Scope and Limitation

1.11.1. Scope

The Crowdsourced Delivery platform initiative seeks to establish a lively, effective, and
community-focused delivery network designed specifically for the needs of regional cities like
Hossana, Ethiopia.

18
  Customer Registration and Profiles: Secure registration for customers, then they can
manage their account and profile.
 Vendor Registration: Providing the access for vendors and businesses so they can be
registered and later be verified by the platform administrators.
 Driver Registration: Also allow driver to register to the system and then verified by the
platform administrator to ensure their validity.
 Order Placement and Tracking: Order placement and Real-time tracking through a live
map interface for customers.
 Payment Integration: Multiple secure payment options, including mobile money
services like Tele-birr and other local methods.
 Driver Matching System: An algorithm to assign orders to nearby available drivers,
ensuring timely deliveries, and make the price of the delivery as fair and affordable as
possible by using metered delivery logic.
 Customer Support: A dedicated module to assist users with order-related queries and
platform issues.
 SEO Optimization: Built-in optimization to make the platform easily discoverable
through search engines.
 Prepared User Agreement: For drivers, vendors and customers, outlining the terms of
service and establishing contracts in alignment with our custom business rules.
 Product Registration: Service providers can efficiently register and manage their
inventory.
 Rating and Review System: Customers can provide feedback on delivery experiences to
promote accountability.
 Delivery Notifications: Real-time notifications for order updates, such as acceptance,
driver assignment, and estimated arrival time.

1.11.2. Limitations

Despite the broad range of features, this system has certain limitations:

 Driver Verification Process: The system will not include advanced background checks
or verification tools for drivers beyond registering the standard identity verification.

19
  Offline Accessibility: The platform will not offer offline functionality for users without
access to internet services.
 Cross-Regional delivery: The system is only taking order in specific region, like
Hossana and will not initially support deliveries across multiple regions or cities.
 Customizable Features: The platform will not allow businesses or drivers to extensively
customize their interfaces or functionalities beyond predefined settings.
 Multi-Language Support: Initially, the system will only operate in two and will not
include extensive multi-language options.
 Multiple Order Taking: Drivers will not take multiple order at a time, delivery assign to
the next order only after successful order of the first one.
 Refund Issue: The platform will not provide an instant refund, after the customer cancel
the order.

1.12. Task and Schedule

1.12.1. Time Plan

The project will be completed over a period of 6 months. The key phases of the project and their
estimated durations are outlined below:

Time plan for our Crowdsourced delivery platform

24 25 25 25 25 25 25
/ 20 20 / 20 / 20 / 20 / 20 / 20
/5 2/ 30 27 27 24 22
12 1/ 1/ 2/ 3/ 4/ 5/

Requirement Gathering, Analysis & system design

Documentation

Frontend Development

Backend Development

Integration and Testing

Deployment

Start date

20
1.12.2. Budget Planning

Below is a cost estimate for each component needed to bring the project to completion:

Item Cost Details

Cloud Hosting 1700-5600 Hosting the system on a cloud platform.

birrs

API Integration 36,000 Integration of third-party APIs (for payment, maps, etc.).
birrs

Other Free Open-source tools used for development and testing.

Development
Tools

Training cost 2000 birr The expense incurred for providing training sessions to users or
stakeholders

Emergency fund 15,000 A reserved amount allocated to cover unexpected expenses or

birrs unforeseen circumstances that may arise during the project
development, deployment phases or after deployement.

Total Estimated 54,700 – Total project cost estimate.

Budget 58,600
birrs

21
 CHAPTER 2

DESCRIPTION OF THE EXISTING SYSTEM

2.1. Introduction

Understanding the functionality of existing systems is critical to identifying their strengths and
weaknesses. This analysis allows for the development of alternative solutions, the selection of
the most feasible options, and the definition of the functional requirements for a proposed
platform.

The Ezezugn delivery system is the only semi-automated delivery service in Hossana. Customers
place orders through a web app by providing their name and phone number. The system notifies
the call center, which coordinates with vendors and drivers to assign the order is with available
driver, with payment made via cash on delivery.

In this chapter, we will analyze the business rules, main functionalities, key players, and the
strengths and weaknesses of Ezezugn's delivery system. This analysis will help identify the gaps
and requirements necessary to inform the design of our proposed platform.

2.2. Business Rules and Constraints

The business rules of an existing system refer to the set of policies, procedures, conditions, or
guidelines that govern how the system operates to fulfill its objectives. These rules define the
logic and constraints that dictate how various processes and transactions are carried out within
the system. They ensure that the system aligns with the organization's goals and meets user or
business requirements. So, the business rules of Ezezugn delivery system are:

BR1. The system shall operate until 1:00 PM local time.

BR2. Customers must be members of the Ezezugn delivery service to place an order.

BR3. Customers must provide their full name, phone number, and password to create an account.

BR4. The system shall allow customers to remain logged in for up to 100 days.

BR5. The system shall accept payments using the cash-on-delivery option.

BR6. The system's call center shall notify restaurants of incoming customer orders.

22
BR7. The system's call center shall register restaurant menu items under their respective
categories.

BR8. The system's call center shall monitor vendors' menu items and incoming orders.

BR9. The system's call center shall assign drivers for order pickups.

BR10 The delivery fee for all orders, regardless of delivery distance, shall be fixed.

BR11. To become a member and work with the Ezezugn delivery system as a driver, applicants
must provide an identification card, a next-of-kin, and the address of their next-of-kin.

BR12. The system shall allow customers to cancel an order if it has not yet been started.

BR13. The customer's device used to place an order must remain operational until the delivery is
completed.

BR14. Payments will be made on a [weekly/bi-weekly/monthly] basis, with a detailed statement

of orders delivered during the period.

Constraints

The constraint is the element factor or a subsystem that works as a block. It restricts an entity,
project, or system from achieving its potential (or higher level of output) concerning its goal.
Some of the constraints are:

 Time Limitation: The system operates only until 1:00 PM local time, which restricts
service availability and may reduce customer convenience.
 Fixed Delivery Fee: A fixed delivery fee for all distances might not cover operational
costs for long-distance deliveries.
 Login Duration: Allowing users to stay logged in for 100 days may create security risks
or require additional measures to ensure secure sessions.
 System Notifications: The reliance on a call center for notifying restaurants might cause
delays or errors due to human dependency.
 Device Dependency: Customers must ensure their devices remain operational until
delivery is complete, which might not always be feasible.

23
2.3. Functions or Main Activities of Existing System

The Ezezugn delivery system in Hossana currently operates using a semi-automated approach to
meet the delivery needs of the community. Analyzing the functionalities of this system provides
valuable insights into its strengths and weaknesses. The following section outlines the key
features and processes of the existing Ezezugn delivery system.

 Order Placement: Customers can place orders through a web app by providing their
name, phone number and address.
 Order Confirmation: Upon submitting an order, the system generates an order ID and
notifies the call center.
 Administrative Visibility: Administrators have access to order details for tracking and
coordination purposes.
 Call Center Coordination: The call center manages orders by contacting vendors and
assigning drivers.
 Driver Assignment: The call center manually informs an available driver about the order
details, including pickup and delivery locations.
 Order Delivery: Drivers are responsible for collecting orders from vendors and
delivering them to customers.
 Cash on Delivery: Customers pay for their orders in cash upon delivery.
 Manual Order Processing: Vendors receive orders directly from the call center and
prepare them for pickup.

2.4. Players of Existing System

The players of the existing system refer to the key individuals and entities involved in its
operation. These are the stakeholders who interact with the system to fulfill delivery requests and
other stakeholders which ensure the process runs smoothly. Each player has a specific role and
responsibility, contributing to the overall workflow of the delivery system. Understanding these
roles is essential in analyzing the system's efficiency and identifying areas for improvement.
Here are the players of existing delivery system.

 Customer: The individual who places an order for food or other goods by using the web
application.

24
  Vendor: The vendor prepares the customer's order based on the instructions received
over the phone from Ezezugn Call Center.
 Call Center: The Stakeholder which receives the order details from the customer, passes
the order to the vendor and assigns driver which picks up the order and delivers to the
customer.
 Driver: An individual which is responsible for picking up the customer order from the
vendor and delivers to customer.
 Admin: The individual responsible for managing user accounts, permissions, and system
configurations within an organization, ensuring that all systems operate efficiently and
securely.

These are all the players involved in system provided by the Ezezugn delivery.

2.5. Documents used in the Existing System

Documents refer to any contract, agreement, or form that the system owner signs with the vendor
and driver. However, in the manual delivery system, no documents were available for reference.
Currently, they are in the process of being legalized.

2.6. Strength and Weakness of the Existing System

2.6.1. Strength of the Existing System

The Strength of the Existing System refers to the positive aspects or advantages of the Ezezugn
delivery system. These are the factors that make the system functional and effective within its
operational context. Identifying these strengths helps highlight what is already working well,
which can be preserved or improved in the transition to a new system.

 Semi-automation: The use of a web app for placing orders simplifies customer
interaction and improves accessibility.
 Centralized order management: The system notifies both the call center and
administrators, ensuring transparency and coordination in order processing.

25
  Structured workflow: The workflow integrates customers, vendors, drivers, and the call
center effectively to fulfill orders.
 Customer convenience: Customers can place orders easily via the web app without
needing to visit vendors physically.
 Priority order processing: When customers place an order, the call center directly calls
vendors, prompting them to start preparing the order immediately.
 Legal agreements with vendors and drivers: The system operates based on formal
agreements, ensuring accountability and smooth coordination among all involved parties.
 Provision of bikes and delivery bags: Ezezugn provides employed drivers with bikes
and delivery bags, ensuring efficient transportation and safe delivery of orders.
 Quality Packaging: The delivery system utilizes high-quality packaging that ensures the
products are well-protected during transit.

2.6.2. Weakness of the Existing System

Ezezugn delivery is being reliance heavy on manual coordination for order placement, vendor
communication, and driver assignments, which increases the likelihood of delays and errors. So,
this are weakness of the existing system:

 Limited Payment Options: Currently, there is only one payment method available cash
on delivery. This may inconvenient some customers.
 Lack of Real-Time Order Tracking: The absence of real-time order tracking for
customers creates uncertainty and negatively impacts the user experience.
 Fixed Delivery Fees: Uniform delivery fees are charged regardless of distance, which
does not account for variable costs and may affect profitability.
 Driver Challenges: Drivers do not have access to a portal for viewing orders and
customer details, resulting in delays and miscommunication. Inefficient driver matching
contributes to logistical challenges and slower deliveries.
 Customer Responsiveness: Delays in contacting customers after they place an order can
led to canceled deliveries and dissatisfied clients.
 No vendor dashboard: Vendors are not directly manage their menu item and incoming
order throw a portal for effective order management.

26
 2.6.2.1. Alternative solutions

There are different alternative systems of a possible solution to address the weaknesses in the
existing systems. These are:

 Automation and Integration of Communication Channels: Develop an app or web

platform to centralize all communication (order placement, delivery coordination, and
payment) and integrate it with automated notifications (SMS, or push notifications) to
keep customers and vendors updated. This eliminates the dependency on phone calls,
reduces miscommunication, and speeds up communication.
 Real-Time Tracking and Estimated Delivery Time: Implement GPS tracking for
deliveries to enable customers to monitor their orders in real-time. The system should
also predict estimated delivery times based on traffic and distance. Provides transparency,
reduces customer uncertainty, and improve user experience by allowing real-time
updates.
 Digitized Record-Keeping: Develop a database-driven platform for order management
that automates the recording of orders, payments, and delivery status. Use cloud storage
for backups to prevent data loss. Reduces errors and increases the reliability of records,
enabling easy access and updates from anywhere.
 Error Reduction through Automation: Automate key processes such as order entry,
payment processing, and delivery scheduling through the app. Implement real-time order
confirmation and updates for both customers and vendors. This reduces human error,
ensures more accurate and timely deliveries, and improves overall system efficiency.
 Driver and Vendor Ratings: Integrate a rating and review system for drivers and
vendors into the platform. Allow customers to rate drivers and vendors based on service
quality and reliability. This encourages better performance, improves service quality, and
increases accountability for both drivers and vendors.
 Pickup Option for Customers: Include an option for customers to choose between home
delivery and self-pickup from the vendor’s location through the app or website. This
increases flexibility for customers and provides more convenience, especially for those
who prefer picking up their orders.

27
By implementing these alternative solutions, it is possible to improve and resolve the weaknesses
of the existing delivery system, enhancing efficiency, reliability, and user satisfaction across all
aspects of the process.

CHAPTER 3

PROPOSED SYSTEM
3.1. Introduction
The proposed crowd-sourced delivery platform aims to improve and boost the current semi-
automated delivery system by addressing existing system limitations. It introduces new features
such as real-time tracking, flexible payment options, and driver ratings while focusing on
efficiency and scalability.

This chapter details the proposed system's structure, functionalities, and requirements. It
introduces the user characteristics, identifies the constraints, and discusses the assumptions and
dependencies for successful implementation. Furthermore, diagrams such as use-case, activity,

28
and sequence diagrams will illustrate the workflow and interactions between different actors.
Finally, the system's requirements undergo validation and verification to ensure accuracy,
consistency, and feasibility.

3.2. Description of the Proposed System

The proposed crowd-sourced delivery platform is a web-based and mobile-enabled system
designed for customers, vendors, and delivery drivers. It incorporates modules for order
management, payment integration, real-time tracking, and driver assignment. Customers can
place orders, track their deliveries, and provide ratings for drivers and vendors. Vendors can
manage orders and payments, while drivers have options for order acceptance, navigation, and
payment processing. The system also includes an admin panel for monitoring and managing
overall operations.

3.2.1. User Characteristics

The proposed system will be utilized by four user groups, each with distinct roles and needs,
including customers, vendors, delivery drivers, and administrators of the platform.

Customers: Use the platform to browse vendor offerings, place orders, track their order in real-
time and rate their experience on the delivery.

Vendors: Utilize the platform to manage their menu including each items feature, and manage
orders.

Delivery Drivers: Operate as independent workers responsible for collecting orders from
vendors and delivering them to customers.

Platform Administrators: Oversee the overall operation, manage users and maintenance of the
system.

3.2.2. Constraints
The expected Constraints that we may face in this project are:

 The platform needs to balance its revenue model to ensure the commission taken from
vendors is fair and sustainable.

29
  Payment providers may charge significant fees per transaction, which could impact the
overall profitability of the platform.
 The system must be designed to handle a growing number of users, vendors, and
transactions without performance degradation.
 Developing and maintaining a reliable tracking system can be expensive, involving
software development, server costs, and ongoing maintenance.
 Building trust among users and vendors is crucial for adoption, requiring secure payment
methods, reliable delivery, and transparency in operations.
 Encouraging local vendors to join the platform and providing them with training or
support may take significant effort and time.
 Integrating with widely used local payment systems, such as Tele-birr, could introduce
technical and contractual complexities.
 Users of the platform, including vendors and customers, may struggle to adapt to the
system if they are not familiar with its features, requiring user-friendly design and
training support.

3.2.3. Assumptions and Dependencies

Assumptions are statements considered true for planning purpose, while dependencies are
conditions or external factors that the system relies on but are outside the project team’s control.

Assumptions

The platform assumes that customers, vendors, and drivers have access to smart devices and the
internet to use its services effectively. It also relies on the availability of a sufficient number of
crowd-sourced drivers to ensure timely deliveries. Customers are expected to provide accurate
delivery details, including addresses and contact numbers, and to be open to cashless payment
options and a tipping feature to motivate drivers. Additionally, vendors are anticipated to partner
with the platform willingly and provide accurate item details to ensure an effective service
experience.

Dependencies

30
The platform heavily relies on external factors, including the availability and functionality of
local payment gateways, third-party map and communication API, and telecommunication
infrastructure. It also depends on vendor cooperation for timely updates on menus, price, and
order status and an adequate pool of drivers for fulfilling delivery requests. Regulatory
compliance is another critical dependency, as any changes in laws could affect the system’s
operation.

3.3. Requirement Specifications

3.3.1. Functional Requirement
The functional requirement explains and describes the interaction between the system and the
users or in general with the environment. A functional requirement is a requirement that
describes “What the platform should do?” That means what the Crowdsourced delivery platform
for Hosanna city residents should do. The new platform will have the following functional
requirement: -

FR-01: The platform shall allow customers and delivery drivers to register and create their
accounts.

FR-02: The platform shall allow users to log in to their accounts.

FR-03: The platform must allow the users to manage their account.

FR-04: The platform must allow the customers to make their payment with an online payment
option.

FR-05: Customers can review their ordered meals and personal information such as customer’s
name, phone number, location (address) before they submit the order. Then, they have to check
out the items in the cart.

FR-06: The platform shall enable customers to track their orders in real-time.

FR-07: The platform shall notify customers when the order has been delivered.

FR-08: The platform shall allow customers to rate their delivery service.

FR-09: The platform shall allow customers to filter for a vendor by name, location, or cuisine.

FR-10: The platform shall display a list of restaurants that are currently available for delivery.
31
FR-11: The platform shall allow customers to view the menu and prices of each restaurant.

FR-12: The platform shall allow customers to modify their order by adding or removing items
from their cart.

FR-13: The platform shall allow customers to add items from the vendor’s menu to their cart.

FR-14: The platform must allocate a nearby driver to vendor for incoming orders from the
customer.

FR-15: The platform must allow vendors to display and modify (add or remove) their menu,
price and items details on the system.

FR-16: The platform must send notification to vendors when an order has been placed.

FR-17: The platform shall allow vendors to accept or decline an incoming order and update the
status of the accepted order.

FR-18: The app shall allow delivery drivers to view and accept delivery requests.

FR-19: The app shall allow delivery drivers to view the details of the order and the customer's
location.

FR-20: The app shall allow delivery drivers to update the status of the delivery.

FR-21: The platform shall allow the administrator to manage user.

FR-22: The platform shall allow the administrator to manage notifications.

FR-23: The platform shall allow the administrator to manage revenue.

FR-24: The platform shall allow the administrator to manage review or rating.

3.3.2. Non-functional Requirement

Non-functional requirements (NFRs) define the quality attributes and operational constraints of
the platform. For the above functional requirements, here are some non-functional requirements
the platform might have:

NFR-01: The platform shall be able to handle a large number of concurrent users without any
performance issues.

32
NFR-02: The platform shall process an order and allocate a nearby delivery driver within short
time.
NFR-03: The platform shall encrypt sensitive data, including passwords, payment details, and
personal information, using industry-standard encryption protocols.
NFR-04: The platform interface shall be intuitive and user-friendly, allowing users to perform
core functionalities with no more than three clicks.
NFR-05: The platform shall be compatible with major web browsers (Chrome, Firefox, Safari,
Edge).
NFR-06: The platform shall support multiple languages, starting with English and Amharic, with
the ability to add more languages in the future.
NFR-07: The platform must comply with Ethiopian e-commerce and digital payment regulations.
NFR-08: In case of system failure, the platform must recover within short period of time to
ensure service continuity.

3.4. System Modeling

System modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system. It is about representing a system using
some kind of graphical notation, which is now almost always based on notations in the Unified
Modeling Language (UML). Models help the analyst to understand the functionality of the
system; they are used to communicate with customers.

3.4.1. Actor Identification

Actors are those who are interact with the platform directly. So, these actors are the following:
Customer: The Customer initiates the interaction with the platform to order items.

 Create an account and log in.

 Place orders and check out.
 Make payments for their orders.
 Track their orders in real-time.
 View notifications regarding order status.
 Provide ratings for drivers and orders.

Vendor: The Vendor provides the items that customers order through the platform.
33
  Create an account and manage their profile.
 Manage menu items available for order.
 Respond to order requests.
 Collect payments for completed orders.

Driver: The Driver is responsible for delivering the orders from vendors to customers.
 Create an account and log in.
 View and manage delivery requests.
 Navigate using the GPS system.
 View their earnings after completing deliveries.

Admin: The admin oversees the entire platform and manages users and system settings.

 Manage user accounts for customers, vendors, and drivers.

 Send notifications to users regarding updates or changes.
 Manage revenues and monitor transactions.
 Verify drivers for eligibility and compliance.
 Manage orders and filter them based on various criteria.

Payment Gateway: The Payment Gateway facilitates online.

 Process payments securely during checkout.

 Handle payment confirmations and notifications.
 Support split payments between vendors and drivers.
 Ensure compliance with financial regulations and security standards.

GPS System (Google Maps API): The GPS System provides location services to track
deliveries and find nearby drives.

 Help drivers navigate to customer addresses.

 Provide real-time tracking of delivery status.
 Assist in matching drivers with nearby delivery requests based on location.
 Enable customers to view the location of their orders in real-time.

34
 3.4.2. Use-Case Identification
Use Cases are an effective technique for narrating the ways a platform works in fulfilling a User
requirement. Use Cases explain what happens when someone uses the system to (try to) achieve
a goal; this will help us understand how it should work in detail. Use cases of the platform are
the following.

Create account Manage delivery request

login Checkout

Place order Collect payment

Driver matching Process payment

Filter vendor Manage notification

Track order Manage revenues

Manage account Verify drivers

View notification Manage Users

Review order & personal information View customer & vendor location

Rate drivers Manage orders

Manage menu Send notification

Table 3.1 System Use Cases

3.4.3. Use-Case Diagram

Use case diagram shows the interaction between the actors and the use cases which are found in
our proposed Crowdsourced delivery platform. Use case diagrams describe what a platform does
from the viewpoint of an external observer. A scenario is an example of what happens when
someone interacts with the platform. Our platform is represented using a use case diagram in the
figure below:

35
Figure 3.1 Use Case Diagram
3.4.4. Description of Use-Case
Use case description explains in detail the general flow of use case diagrams. Each table contains
the use case name, use case ID, the actor that initiates and interacts with the use case, and flow of
event that shows the interaction between the actor and the use case which enables the user to
easily understand the functions of the proposed system.

Use Case Name Place Order

Use Case Identifier UC #1

36
Actors Primary Actor: Customer

Secondary Actor: Vendor & Payment Provider

Precondition ● The Customer must have an active account and be logged into the
system.
● The Customer must have items in their cart.

Description This use case describes how a Customer places an order on the system.

Basic Flow of Actor’s Request System’s Response

Events
1. The Customer reviews the 1. The system displays the order
items in their cart. summary, including cart
2. The Customer enters or items, total cost, and delivery
selects a delivery address. details.
3. The Customer chooses a 2. The system will save the
payment method. customer's address
4. The Customer presses the 3. The system generates a
"Place Order" button. unique order ID and stores
the order details in the
database.
4. The system sends the order
details to the Vendor for
confirmation.
5. The system processes the
payment through the
Payment Provider.
6. The system sends a
confirmation notification to

37
 the Customer.
7. The use case ends
successfully.

Alternative Events ● A5. If the delivery address or payment method is not fulfilled:
○ A5.1 The system displays an error message: “Invalid
address or payment method. Please try again.”
○ A5.2 The use case returns to step 2.

Post condition ● If there is no error, the order is successfully placed, and the
Customer receives a confirmation notification.
● Otherwise, the order is not placed, and the Customer is prompted
to resolve the issue.

Table 3.2 Use Case Description for Order Placement

Use Case Name Filter Vendor and Items

Use Case Identifier UC #2

Actors Customer

Precondition ● The Customer must have an active account and be logged into the
system.
● The Customer must be on the platform’s vendor or menu browsing
page.

Description This use case describes how a Customer filters vendors and items based on
specific criteria such as vendor name, location, or cuisine type.

38
 Basic Flow of Events Actor Request System Response

1. The Customer accesses 1. The system displays the available

the vendor or menu filter options (e.g., dropdown for
browsing page. location, list of cuisine types).
2. The Customer selects 2. The system processes the selected
filter criteria (e.g., filter criteria.
vendor name, location, 3. The system displays a list of
cuisine type). vendors and items matching the
3. The Customer presses filter criteria.
the "Apply Filters" 4. According to the filter, the system
button. updates the displayed vendors and
items in real time.
5. The use case ends successfully.

Alternative Events A4. If no vendors or items match the filter criteria:

● A4.1 The system displays a message: “No vendors or items match your
filter criteria.”
● A4.2 The Customer may adjust the filter criteria or clear the filters.

Post condition ● The system displays the filtered results if there are matching vendors or
items.
● Otherwise, the system informs the Customer that no results were found
based on the applied filters.

Table 3.3 Use Case Description for Filter Vendor and Items

Use Case Name Track Order

Use Case Identifier UC #3

39
Actors Primary Actor: Customer

Secondary Actor: Map Provider

Precondition ● The Customer must have an active account and be logged into the
system.
● The Customer must have placed an order that is in progress or
completed.

Description This use case describes how the Customer tracks the status of their placed
order, including updates on its current delivery status and estimated delivery
time.

Basic Flow of Events Actor Request System Response

1. The Customer accesses 1. The system fetches the order status from
the "My Orders" or the database.
"Track My Order"
2. If the order is ready for pickup:
section of the platform.
2. The Customer selects the  The system updates the
order they want to track. order status to "Ready for
3. The Customer presses Pickup."
the "Track Order"  The system notifies the
button. Customer that the order is
ready for pickup.

3. If the order is not ready:

 The system displays a

message: "Order not ready
for pickup."
 The Customer may retry
tracking the order or check
back later.

4. If the order is ready:

40
  The system checks if a
driver has been assigned.
 If a driver is assigned, the
system fetches the driver's
current location from the
Map Provider and displays
it to the Customer.

5. The system provides real-time updates

about the order's progress:

 Status updates such as

"Driver picked up the
order" or "On the way" are
shown.

6. Once the order is delivered:

 The system updates the

order status to "Delivered."
 The Customer receives a
notification confirming the
delivery.

7. The use case ends successfully.

Alternative Events A4. If the order cannot be tracked (e.g., due to system error or missing
details):

● A4.1 The system displays a message: "Unable to track your order at

this time."
● A4.2 The Customer may retry tracking the order or contact customer
support.

Post condition ● The Customer successfully tracks the order's status and is kept
informed of its progress.
● If the order is delivered, the Customer is notified accordingly.

41
Table 3.4 Use Case Description for Track Order

Use Case Name Rate Driver

Use Case Identifier UC #4

Actors Customer

Precondition ● The Customer must have an active account and be logged into the
system.
● The Customer must have completed an order with a driver assigned for
delivery.
● The Customer must be able to access the order details for the
completed delivery.

Description This use case describes how the Customer rates the driver after the order has
been delivered, providing feedback on their delivery experience.

Basic Flow of Events Actor Request System Response

1. The Customer accesses the 1. The system displays the order

"Order History" or details, including the driver’s
"Completed Orders" section information and delivery
of the platform. performance.
2. The Customer selects the 2. The system validates the rating
completed order for which and comment provided by the
they want to rate the driver. Customer.
3. The Customer clicks the 3. The system saves the rating and
"Rate Driver" button or link. comment in the database,
4. The Customer provides a linking it to the driver’s profile
rating (e.g., a star rating or a and the corresponding order.
numeric scale) and 4. The system updates the driver’s
optionally adds a comment. average rating based on the
5. The Customer presses the new feedback.
"Submit Rating" button. 5. The system may notify the

42
 driver about the new rating and
comment.
6. The use case ends successfully.

Alternative Events A4. If the Customer enters invalid data (e.g., rating exceeds the allowed
range):

● A4.1 The system displays a message: "Please provide a valid rating."

● A4.2 The Customer can correct the rating and resubmit.

Post condition ● The Customer’s rating and comment are successfully saved, and the
driver’s profile is updated with the new rating.
● The driver is notified of the feedback if required by the system’s
design.

Table 3.5 Use Case Description for Rate Driver

Use Case Name Manage User

Use Case Identifier UC #5

Actors Administrator

Precondition ● The Administrator must be logged into the platform with appropriate
administrative privileges.
● There must be an active user account (Customer, Vendor, or Delivery
Driver) that requires management (e.g., update, delete, or block).
● The system must have a list of all users (customers, vendors, and
delivery drivers) in the platform database.

Description This use case describes how the Administrator manages user accounts
(customers, vendors, or delivery drivers), including tasks like updating account
details, deleting users, or blocking/unblocking accounts. This ensures that the

43
 platform’s user base is effectively managed, ensuring security and accuracy.

Basic Flow of Events Actor Request System Response

1. The Administrator logs into 1. The system displays a list of all

the platform. users (Customers, Vendors, and
2. The Administrator navigates Delivery Drivers) registered on
to the user management the platform.
interface. 2. The system retrieves the
3. The Administrator selects a selected user’s details and
specific user (Customer, displays them for review.
Vendor, or Delivery Driver) 3. The system provides options to
from the list to manage. manage the user (e.g., update
4. The Administrator chooses details, delete account,
the desired action (update block/unblock).
account details, delete user, 4. The system performs the
block/unblock user). selected action:
5. The Administrator confirms ● If updating, the system
the action. saves the new user
details.
● If deleted, the system
removes the user from
the platform, and their
data is deleted.
● If blocking/unblocking,
the system updates the
user's status
accordingly.
5. The system confirms the action
and updates the user’s status in
the database.
6. The system notifies the user of
the change (e.g. if the account
was deleted or blocked).

44
 7. The use case ends.

Alternative Events A4. If the Administrator attempts to update a non-existent user:

● A4.1 The system displays an error message: “User not found.”

● A4.2 The Administrator can search again for the user or cancel the
operation.
A5. If the Administrator tries to delete a user with pending orders:

● A5.1 The system displays a warning message: “User has pending

orders and cannot be deleted at this time.”
● A5.2 The Administrator can cancel the deletion or resolve the pending
orders before proceeding.

Post condition ● The user’s account is successfully updated, deleted, or blocked as per
the action chosen by the Administrator.
● If the user is blocked, their access to the platform is restricted.
● If the user was deleted, they are completely removed from the platform,
and their data is deleted.

Table 3.6 Use Case Description for Manage User

Use Case Name Manage Revenue

Use Case Identifier UC #6

Actors Administrator

Precondition ● The Administrator must be logged into the platform with appropriate
administrative privileges.
● The system must have active transaction records (orders, payments,
fees, etc.) stored in the database.
● The platform must have a defined revenue model, including vendor

45
 commissions, delivery fees, and any additional revenue sources.

Description This use case describes how the Administrator manages and tracks revenue on
the platform. It includes activities like viewing total revenue, adjusting
commission rates, generating financial reports, and ensuring that all
transactions are accounted for correctly.

Basic Flow of Events Actor Request System Response

1. The Administrator logs into 1. The system displays a

the platform. dashboard with revenue data
2. The Administrator navigates for the platform, including total
to the revenue management revenue, vendor commissions,
interface. and other fees.
3. The Administrator selects the 2. The system retrieves and
type of revenue data to view displays the selected revenue
(e.g., total revenue, vendor data, including breakdowns by
commissions, delivery fees). period (daily, weekly, monthly,
4. The Administrator generates etc.).
a report or views real-time 3. The system generates a report,
revenue data. showing revenue trends, vendor
5. The Administrator may payments, and delivery fees.
adjust commission rates or If adjusting fees or
other fees if needed. commissions, the system
6. The Administrator reviews provides options to modify the
financial data and makes percentage or amount.
necessary adjustments. 4. The system updates the
platform’s revenue data based
on any adjustments made by
the Administrator.
5. The system confirms that the
changes have been successfully
made and updates the database
accordingly.

46
 6. The system notifies the
Administrator of any critical
revenue-related issues (e.g., a
significant drop in revenue, or
failed transactions).
7. The use case ends.

Alternative Events A4. If the Administrator selects an invalid date range for the report:

● A4.1 The system displays an error message: “Invalid date range

selected.”
● A4.2 The Administrator can adjust the date range and retry generating
the report.
A5. If the Administrator tries to modify the commission rate outside
the allowed range:

● A5.1 The system displays an error message: “Commission rate cannot

exceed the maximum allowable limit.”
● A5.2 The Administrator can correct the rate or cancel the action.

Post Condition ● The revenue data is successfully updated or modified according to the
Administrator’s actions.
● Financial reports are generated and available for review.
● If commission rates or fees were adjusted, the new rates are reflected in
the system’s future revenue calculations.
● The system maintains accurate records of all revenue-related
transactions.

Table 3.7 Use Case Description for Manage Revenue

Use Case Name Manage Order

47
Use Case Identifier UC #7

Actors Administrator

Precondition ● The Administrator must be logged into the platform with appropriate
privileges to manage orders.
● Orders must exist in the system with a status such as "Pending,"
"Processing," "Delivered," or "Cancelled."
● The system must maintain a database of order details, including
customer information, order items, and delivery status.

Description This use case describes how the Administrator manages customer orders,
including viewing order details, updating order statuses, addressing disputes,
and canceling orders when necessary.

Basic Flow of Events Actor Request System Response

1. The Administrator logs into 1. The system displays a

the platform. dashboard with all orders
2. The Administrator navigates categorized by their current
to the order management status (e.g., Pending,
section. Processing, Delivered).
3. The Administrator selects a 2. The system retrieves and
specific order from the list to displays the details of the
manage. selected order.
4. The Administrator reviews 3. The system provides options
the details of the selected for the Administrator to update
order (e.g., items, delivery the status, cancel the order, or
status, customer view attached dispute reports.
information). 4. If the order status is updated,
5. The Administrator updates the system confirms the change
the status of the order (e.g., and notifies the relevant parties
from "Pending" to (e.g., customer, vendor, or
"Processing" or "Delivered"). driver).

48
 6. If needed, the Administrator 5. If the order is canceled, the
cancels the order or resolves system processes the
disputes reported by the cancellation and updates the
customer or vendor. status to "Cancelled."
6. The system ends the use case.

Alternative Events A5. If the Administrator tries to update the status of an invalid or
already completed order:

● A5.1 The system displays an error message: "The order cannot be

updated as it is already completed."
● A5.2 The Administrator reviews other orders.
A6. If the Administrator cancels an order for a paid transaction:

● A6.1 The system triggers a refund process for the customer, if

applicable.
● A6.2 The system notifies the vendor and the customer about the
cancellation.

Post Condition ● The order details are successfully managed (status updated, canceled,
or resolved).
● Notifications are sent to all relevant parties about the updates.
● The system maintains accurate records of order management activities.

Table 3.8 Use Case Description for Manage Order

Use Case Name Manage Menu

Use Case Identifier UC #8

Actors Vendor

Precondition ● The vendor must be logged into the system.

49
 ● The vendor’s profile must be active and verified.

Description This use case describes how a vendor manages their menu, including adding,
updating, and deleting menu items to keep their offerings current for customers.

Basic Flow of Events Actor Request System Response

1. The Vendor logs into the 1. 2. The system displays the

system. menu management interface
2. The Vendor navigates to the with options for adding,
menu management section. updating, or deleting items.
3. The Vendor selects an action: 2. The system processes the
add, update, or delete menu selected action:
items. ● For adding/updating:
4. The Vendor provides Validates input and
necessary details (e.g., item saves changes.
name, price, category, ● For deleting: Removes
availability status) to add or the selected item from
update actions. the menu.
5. The Vendor confirms the 3. The system confirms the
selected action. successful execution of the
selected action and updates the
menu.

Alternative Events A4. If the Vendor provides invalid or incomplete information for
adding/updating:

● A4.1 The system displays an error message (e.g., "Invalid input: Please
complete all required fields").
● A4.2 The Vendor is prompted to correct the details and retry.
A4. If the Vendor attempts to delete an item that is part of an active
order:

● A4.1 The system prevents deletion and displays a warning (e.g.,

"Cannot delete item currently in active orders").

50
 Post Condition ● The vendor’s menu is updated accurately to reflect current offerings
and availability for customers.

Table 3.9 Use Case Description for Manage Menu

Use Case Name Manage Delivery Request

Use Case Identifier UC #9

Actors Driver

Precondition ● The driver must be logged into the system.

● A delivery request must exist and be assigned to the driver.

Description Describes how the driver manages assigned delivery requests, including
updating the status, viewing request details, and accepting the request.

Basic Flow of Events Actor Request System Response

1. The driver logs into the 1. Displays the list of delivery

system. requests assigned to the driver.
2. The driver selects the 2. Displays detailed information
"Delivery Requests" option. about the selected request.
3. The driver views the list of 3. If the driver accepts the
assigned delivery requests. request:
4. The driver selects a specific
delivery request.  The system updates the
delivery status to
5. The driver updates the "Accepted."
delivery status or accepts the  The system confirms the
acceptance and updates the
request. request record.

4. If the driver declines the

request:

51
  The system updates
the status to "Declined."

 The system records

the decline and notifies
the platform.

Alternative Events A5. If the driver attempts to update the status without selecting a request:

● A5.1 The system displays a message: "Please select a request before

updating."
● A5.2 Return to step 3.

Post Condition ● If there is no exception, the request is successfully managed (status

updated or request accepted).
● Otherwise, no changes are saved, and the request remains pending.

Table 3.9 Use Case Description for Manage Delivery Request

3.5. Requirement Analysis

To produce a model of the system which is correct, complete and consistent we need to construct
the analysis model which focuses on structuring and formalizing the requirements of the system.

3.5.1. Activity Diagram

The activity diagram is another important diagram in UML to describe the dynamic aspect of the
system. It a follow chart to represent the flow of information one activity to another activity but
it is not exactly a flow chart as they have some additional capabilities. These additional
capabilities include branching, parallel flow, etc.

52
Figure 3.2 Activity Diagram for Create Account

Figure 3.3 Activity Diagram for Login

53
Figure 3.4 Activity Diagram for Place Order

Figure 3.5 Activity Diagram for Manage Incoming Order

54
Figure 3.6 Activity Diagram for Driver Matching

Figure 3.7 Activity Diagram for Manage Delivery Request

55
 Figure 3.8 Activity Diagram for Track Order

3.5.2. Sequence Diagram

A sequence diagram is an interaction diagram that shows how objects operate with one another
and in what order. It is a construct of a message sequence chart. A sequence diagram shows
object interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario.

56
Figure 3.9 Sequence Diagram for Login

Figure 3.10 Sequence Diagram for Place Order

57
Figure 3.11 Sequence Diagram for Manage Incoming Order

Figure 3.12 Sequence Diagram for Checkout

58
Figure 3.13 Sequence Diagram for Driver Matching

Figure 3.14 Sequence Diagram for Manage Delivery Request

59
 Figure 3.15 Sequence Diagram for Track Order

3.5.3. Requirement validation & verification

Although most of the time we use validation and verification interchangeably it is not right and
should be corrected. Software verification comes first, followed by validation.
Verification tests check to ensure the program is built according to the stated requirements. The
verification process includes activities such as reviewing the code and doing walkthroughs and
inspections.
Missing requirements or invalid requirements can be discovered during this phase, which can
minimize the risk of rework and the cost associated with overruns. It’s far more effective to fix a
small bug upfront than in the future when hundreds of lines of code must be identified and
corrected.
Validation isn’t focused on the path that you traveled to arrive at the destination but is instead
focused on whether you’ve hit the mark. For example, consider the last example of a person

60
traveling in a car and tracking landmarks, such as exit numbers. Let’s say the goal is to arrive at
a hiking trail. A few questions might be asked when you arrive.
 Does the hiking trail look as expected?
 Can I see a marked trail and trailhead sign?
 Does the location meet my expectations?
Validation is focused on the same types of questions. It’s not concerned with how you got there,
but that you arrived at the correct location.
3.5.3.1. Validity checks
The functions proposed by stakeholders should be aligned with what the system needs to
perform. This validation process is concerned with checking the requirements for omissions,
conflicts, and ambiguities and for ensuring that the requirements follow quality standards. The
validation guidelines which we suggest are as follows:

 To check that the requirements are acceptable to all system stakeholders.

 Increase your confidence that the specification represents a system that will meet the real
needs of the system customer.
 The system should provide the functions which best support the customer's needs
 Checking a final draft of a requirements document which includes all system
requirements and where known incompleteness and inconsistency has been removed.

3.5.3.2. Consistency checks

Requirements in the document shouldn't conflict or different descriptions of the same function.
There should not be different meanings of any single requirement stated at different
places/contexts in SRS. That is, there should not be contradictory constraints or dissimilar
descriptions of the same system function at two different locations. We use this technique in our
project to check the consistency of our project.

 No two or more requirements contradict each other which mean consistence

terminology.

 Requirements in the document should not conflict.

 Verify that requirements link to existing documents. Verify that requirements link to
valid locations (e.g., bookmarks, line numbers, anchors) within documents.

61
  Requirement uses terms in a manner consistent with their specified meanings.

 The requirement should be understood in the same way by every person who reads it.

3.5.3.3. Completeness checks

Check Completeness is to check that a complete set of requirements has been developed and
documented that defines all system functions that are needed to satisfy the stakeholder needs
with their associated performance, environmental, and other non-functional requirements. We
use this technique in our project to check the completeness of our project.

 A requirement must have all relevant components.

 All requirement should be written at a consistent and appropriate level of detail.

 The requirement must be complete and should be defined (which means the type of
requirement should be defined).

 It implies that all users' needs will be met when the system is implemented.

3.5.3.4. Realism checks

It must be ensured using existing technology that the requirements can be implemented.
Schedule and budget constraints for system development are also to be considered. In our
project, we used realism checks for implementing requirement reality.

3.5.3.5. Verifiability
Requirements should be written so that they can be tested. This means you should be able to
write a set of tests that demonstrate that the system meets the specified requirements. In our
project we used verifiability to check that:

 Checking our product against some standards and conditions imposed on this product and
of its development.

 Verify whether or not the products of the given phase fulfill the specifications established
during the previous phase.

 Verify whether or not the products of the given phase fulfill the specifications established
during the previous phase.

62
We conclude that Requirements validation and verification is a fundamental activity of the
requirements engineering process. Different validation techniques have been discussed above. To
complete the software projects successfully without correctness and completeness problems in
requirements.so in our project we use the v-v model as follows and the process.

References
63
Aliaa Alnaggar, J. H. (2019, October 8). Crowdsourced delivery: A review of platforms and academic
literature. Retrieved from sciencedirect:
https://www.sciencedirect.com/science/article/abs/pii/S030504831930578X

Alp Muzaffer Arslan, L. G. (2018, July). Crowdsourced Delivery—A Dynamic Pickup and Delivery Problem
with Ad Hoc Drivers. Retrieved from researchgate:
https://www.researchgate.net/publication/326283088_Crowdsourced_Delivery-
A_Dynamic_Pickup_and_Delivery_Problem_with_Ad_Hoc_Drivers

Arslan, A. (2017). Streamlining deliveries through crowdsourcing. Retrieved from academia:

https://www.academia.edu/95219117/Streamlining_deliveries_through_crowdsourcing

Chandler, J. (2013). Risks and Rewards of Crowdsourcing Marketplaces. Retrieved from academia:
https://www.academia.edu/82247730/Risks_and_Rewards_of_Crowdsourcing_Marketplaces

Demissie, D. B. (2020). Ethiopia’s Digital Transformation Strategy. Retrieved from

https://www.kiep.go.kr/aif/issueFileDownload.es?brdctsNo=341711&brdctsFileNo=84186

Gacheru, S. M. (2024, 05 14). Tikus Delivery Ethiopia; More than food delivery. Retrieved from
growthafrica: https://growthafrica.com/more-than-food-delivery-tikus-delivery/

GAZETTE, F. N. (2014, march 21). Trade computation and consumer protection. Retrieved from Ethiopian
Legal Berif: https://chilot.files.wordpress.com/2014/09/813_2013-trade-competition-and-
consumers-protection.pdf

GAZETTE, F. N. (2016, Augest 5). Commercial Registration and Licensing Proclamation. Retrieved from
metaapz: https://www.metaappz.com/References/ethiopian_laws/federal/pr_980_2016/en/
pdf#gsc.tab=0

GAZETTE, F. N. (2024, july 24). Personal Data Protection. Retrieved from metaapz:
https://www.metaappz.com/References/ethiopian_laws/federal/pr_1321_2024/en/
pdf#gsc.tab=0

Ha Ta, T. L. (2023, Jounary). Crowdsourced delivery and customer assessments of e‐Logistics Service
Quality. Retrieved from researchgate:
https://www.researchgate.net/publication/366879687_Crowdsourced_delivery_and_customer_
assessments_of_e-Logistics_Service_Quality_An_appraisal_theory_perspective

Huili Zhang a, Y. X. (2021, October 24). Online crowdsourced truck delivery using historical information.
Retrieved from sciencedirect:
https://www.sciencedirect.com/science/article/abs/pii/S0377221721008869

IEEE. (1984, February 10 ). 830-1984 - IEEE Guide for Software Requirements Specifications. Retrieved
from ieeexplore.ieee.org: https://ieeexplore.ieee.org/document/278253

Industry Development Strategy of Ethiopia. (2002, Augest). Retrieved from tralac:

https://www.tralac.org/files/2012/12/Industry-Development-Strategyy-of-Ethiopia.pdf?
__cf_chl_tk=Q48sD6JluTkKkWLrEQu7IQ.6KJYC_d1Xvc7QDUBJfEw-1734045996-1.0.1.1-
2l2enN8UibnQ_I4xfbNRjq8SZjxeibYJYubW96pFTGU

64
Patel, R. (2024, December 17). Crowdsourced Delivery: The Complete Guide for 2024. Retrieved from
upper: https://www.upperinc.com/blog/crowdsourced-delivery/

Portal, L. E.-E. (2019, 09 05). Labour law. Retrieved from natlex:

https://natlex.ilo.org/dyn/natlex2/r/natlex/fe/details?p3_isn=109825

65