TRIBHUVAN UNIVERSITY

INSTITUTE OF ENGINEERING
THAPATHALI CAMPUS

Case Study
On
DriveLink

Submitted By:
Abilash Maharjan (THA077BCT004)
Anmol Kumar Gupta (THA077BCT011)
Shailendra Rawal (THA077BCT041)

Submitted To:
Department of Electronics and Computer Engineering
Thapathali Campus
Kathmandu, Nepal

Under the Supervision of

Er. Santosh Giri

August, 2023
INTRODUCTION

DriveLink is a mobile application that allows users to easily travel from one place to another.
It is a car/bike service that allows a person to use a smartphone app to arrange a ride in a usually
privately owned vehicle.

In today's world of emerging technology, commuting from one place to another has become a
significant challenge. The conventional transportation system often faces issues such as traffic
congestion, high fuel consumption, and limited parking spaces. Additionally, many individuals
struggle to find affordable and convenient transportation options, especially during peak hours
or in areas with inadequate public transportation.

To address the aforementioned challenges, we propose developing a ride-booking application

that will revolutionize how people travel by providing a convenient, affordable, and
environment-friendly solution. This application will connect individuals and riders to book
rides based on pickup & destination location and type of vehicle (car or bike) they want to
choose for the ride.

i
Table of Contents

INTRODUCTION......................................................................................................... i
List of Figures ............................................................................................................... v
1. FUNCTIONAL REQUIREMENTS ....................................................................... 1
R.1: User Type Selection........................................................................................1
R.1.1: Select User Type ............................................................................... 1
R.2: Customer Registration ....................................................................................1
R.2.1: Register New Customer .................................................................... 1
R.2.2: Add Customer ................................................................................... 1
R.3: Rider Registration ...........................................................................................1
R.3.1: Register New Rider ........................................................................... 1
R.3.2: Add Rider .......................................................................................... 2
R.4: User Login ......................................................................................................2
R.4.1: Select the Login option ..................................................................... 2
R.4.2: Enter credentials ................................................................................ 2
R.4.3: Forgot Password option .................................................................... 2
R.4.3.1: Validate OTP .................................................................................. 2
R.4.3.2: Setup New Password ...................................................................... 2
R.5: Ride Booking Interface ...................................................................................3
R.5.1: Pick up and Destination place selection ............................................ 3
R.5.2: Type of vehicle selection (Car or Bike) ............................................ 3
R.5.3: Display estimated fare for the ride .................................................... 3
R.5.4: Review and confirmation .................................................................. 3
R.5.5: Cancel Booking a Ride...................................................................... 3
R.6: Real-Time Tracking ........................................................................................3
R.6.1: Estimation of arrival time.................................................................. 4
R.6.2: Real-Time Location Tracking ........................................................... 4
R.7: Show Rider’s Information ..............................................................................4
R.7.1: Display Available Riders .................................................................. 4
R.7.2: Accept Ride ...................................................................................... 4
R.8: Payment ..........................................................................................................4

ii
 R.8.1: Select the payment option ................................................................. 4
R.8.2: Choose Payment Gateway................................................................. 4
R.8.3: Make Payment ................................................................................... 5
R.9: Riders Review and Ratings.............................................................................5
R.9.1: Write a Review .................................................................................. 5
R.9.2: Give Ratings ...................................................................................... 5
R.10: Dashboard .....................................................................................................5
R.10.1: View Dashboard .............................................................................. 5
R.11: Edit Profile....................................................................................................6
R.11.1: Select Edit Profile Option ............................................................... 6
R.11.1.1: Edit Phone Number ...................................................................... 6
R.11.1.1.1: Change Phone Number ............................................................. 6
R.11.1.2: Edit email ..................................................................................... 6
R.11.1.2.1: Change email ............................................................................. 6
R.11.1.3: Edit Password ............................................................................... 6
R.11.1.3.1: Change Password ...................................................................... 6
R.12: Emergency Support and Help Center ...........................................................7
R.12.1: Contact Customer Support .............................................................. 7
2. NON-FUNCTIONAL REQUIREMENTS............................................................. 8
R.1: Performance ....................................................................................................8
R.2: Scalability .......................................................................................................8
R.3: Availability .....................................................................................................8
R.4: Security ...........................................................................................................8
R.5: Design Constraints ..........................................................................................8
R.6: Usability and Accessibility .............................................................................9
R.7: Compliance with Regulations .........................................................................9
R.8: Integration .......................................................................................................9
R.9: Maintainability................................................................................................9
3. DATA FLOW DIAGRAMS .................................................................................. 10
3.1 DFD Level-0...................................................................................................10
3.2 DFD Level-1...................................................................................................11

iii
 3.3 DFD Level-2...................................................................................................13
4. UML USE CASE DIAGRAMS............................................................................. 17
4.1 DriveLink Use Case Diagram ........................................................................17
4.2 Use Case Description .....................................................................................19
4.2.1 User Registration .............................................................................. 19
4.2.2 User Login ........................................................................................ 20
4.2.3 Book Ride ......................................................................................... 21
4.2.4 Payment System ................................................................................ 22
4.2.5 Edit Profile ........................................................................................ 23
4.2.6 Rider Review and Ratings ................................................................ 24
4.2.7 Emergency Support ........................................................................... 25
PROJECT SCHEDULE ............................................................................................ 26

iv
List of Figures

Figure 1 : Level-0 DFD of DriveLink System ......................................................................... 10

Figure 2 : Level-1 DFD of User Registration .......................................................................... 11
Figure 3 : Level-1 DFD of User Login ................................................................................... 11
Figure 4 : Level-1 DFD of Ride Booking ................................................................................ 11
Figure 5 : Level-1 DFD of Fare Calculation of the Ride ......................................................... 12
Figure 6 : Level-1 DFD of Edit Profile Information................................................................ 12
Figure 7 : Level-1 DFD of Dashboard ..................................................................................... 12
Figure 8 : Level-1 DFD of Review and Rating System ........................................................... 12
Figure 9 : Level-1 DFD of Emergency Support System.......................................................... 13
Figure 10 : Level-2 DFD for Customer Registration ............................................................... 13
Figure 11 : Level-2 DFD for Rider Registration ..................................................................... 13
Figure 12 : Level-2 DFD for User Login ................................................................................. 14
Figure 13 : Level-2 DFD for Ride Booking............................................................................. 14
Figure 14 : Level-2 DFD for Payment ..................................................................................... 15
Figure 15 : Level-2 DFD for Change Phone Number Function .............................................. 15
Figure 16 : Level-2 DFD for Change Email Function ............................................................. 15
Figure 17 : Level-2 DFD for Change Password Function ....................................................... 16
Figure 18 : DriveLink System Use Case Diagram................................................................... 18
Figure 19 : User Registration Use Case Diagram .................................................................... 19
Figure 20 : User Login Use Case Diagram .............................................................................. 20
Figure 21 : Book Ride Use Case Diagram ............................................................................... 21
Figure 22 : Payment System Use Case Diagram ..................................................................... 22
Figure 23 : Edit Profile Use Case Diagram ............................................................................. 23
Figure 24 : Rider Review and Ratings Use Case Diagram ...................................................... 24
Figure 25 : Emergency Support Use Case Diagram ................................................................ 25

v
1. FUNCTIONAL REQUIREMENTS

R.1: User Type Selection

Description: This function allows users to choose how they are going to use the application
either as a customer or as a rider.

R.1.1: Select User Type

 Input: Choose between Customer or Rider Mode.
 Output: User prompted to an interface to choose between whether to register or login.

R.2: Customer Registration

Description: The register customer function is prompted if the customer is not registered to
the application. The customer has to enter his/her name, phone number, email address and set
up password. It checks if an account already exists with the entered phone number and also
checks if the password entered by the customer is valid. If no account exists with the entered
phone number and the password entered is valid, the customer is added to the database;
otherwise, it generates an error message.

R.2.1: Register New Customer

 Input: “Register as Customer” option is selected.
 Output: User prompted to enter the name, phone number, email address and password.

R.2.2: Add Customer

 Input: User enters name, phone number, email address and password.
 Output: Registration Successful message is displayed.
 Processing: The user is added to the database along with the user details if the details
provided are verified to be unique, otherwise an error message is displayed.

R.3: Rider Registration

Description: The rider registration function is prompted if the user wants to register as a rider
on the application. The user is required to enter their personal and contact details, along with
the necessary documentation (driving license) to become a registered rider. The system verifies
the provided information and checks for the validity of the required documents. If the entered
information is accurate and all necessary documents are valid, the user is successfully
registered as a rider. In case of any errors or missing information, appropriate error messages
are generated to guide the user through the registration process.

R.3.1: Register New Rider

 Input: “Register as Rider” option is selected.
 Output: User prompted to enter the name, email, phone number, password, and copy
of the driving license.

1
R.3.2: Add Rider
 Input: User enters name, email address, phone number, password and copy of driving
license.
 Output: Registration Successful message is displayed.
 Processing: The user is added to the database along with the user details if the details
provided are verified to be unique otherwise, an error message is displayed.

R.4: User Login

Description: If the user already has an account, he/she can log in to the system by entering
his/her phone number and password. Logging in to the system provides access to all the features
of the application. In case of invalid user credentials, access is denied.

R.4.1: Select the Login option

 Input: Login option is selected.
 Output: User prompted to choose user type.

R.4.2: Enter credentials

 Input: User enters the login credentials.
 Output: Successfully logged in message is displayed.
 Processing: The entered credentials are validated. If they are not valid, the user is asked
to enter the credentials again.

R.4.3: Forgot Password option

 Input: “Forget Password” option is selected.
 Output: User prompted to enter OTP sent to his/her phone number.
 Processing: OTP is generated by the system and is sent to the user’s phone number.

R.4.3.1: Validate OTP

 Input: User enters the OTP.
 Output: User is prompted to set up a new password.
 Processing: If entered OTP is matched, the user is allowed to set up a new password
for his/her account, otherwise an error message is displayed.

R.4.3.2: Setup New Password

 Input: User enters a new password.
 Output: Successful message is displayed after setting up a new password.
 Processing: The user account password is updated in the database if the user enters the
password according to the requirements, otherwise an error message is displayed.

2
R.5: Ride Booking Interface
Description: From this interface, customers can book a ride, either bike ride or car ride,
according to their preference. Customer should enter their pickup and destination location.
Based on the provided keywords the suggestions of the matched places are shown to the user.
Then, the user selects the pickup and destination location and confirms the ride by selecting a
rider from the list of available riders nearby him/her. After that, a pickup request is sent to the
rider. The rider can accept the request and further proceed to complete the ride.

R.5.1: Pick up and Destination place selection

 Input: User selects pickup and destination location from the map.
 Output: Prompt to choose type of vehicle for the ride.

R.5.2: Type of vehicle selection (Car or Bike)

 Input: User selects either a bike or a car according to his/her preference.
 Output: Prompt to review and confirm booking.

R.5.3: Display estimated fare for the ride

 Input: User selects the Next option after filling in all the booking details.
 Output: Estimated fare for the ride is displayed and the user is prompted to review and
confirm the booking.
 Process: The system calculates the estimated fare of the ride based on the distance and
resources used by the chosen vehicle type.

R.5.4: Review and confirmation

 Input: Users are shown the details they have entered, provide an option to edit if
necessary, and finally confirm the ride.
 Output: Prompt to rider searching interface.

R.5.5: Cancel Booking a Ride

 Input: Cancel Booking a Ride option is selected.
 Output: User prompted to initial page of the ride booking interface.
 Processing: The system aborts the process of booking a ride.

R.6: Real-Time Tracking

Description: From this interface, customers are shown the available riders around their pickup
location and they can also get real-time information of the available riders around them. Also,
they can track their current location during their ride. This service helps to increase the security
of the ride.

3
R.6.1: Estimation of arrival time
 Process: Through internal estimation using real-time traffic conditions, the probable
estimated time for the rider to reach the pickup location and also the ride duration is
calculated.
 Output: Users are shown the estimated arrival time of the rider and ride duration.

R.6.2: Real-Time Location Tracking

 Process: By using the GPS real-time tracking system, the current location of all the
riders is tracked.
 Output: Tracked location is shown on the map.

R.7: Show Rider’s Information

Description: This function provides customers to select a rider from the provided list of
available riders. Once the user has entered their pickup and destination location, the system
retrieves a list of drivers who are nearby and available to accept the ride request. The list
typically includes relevant details such as the rider's name, vehicle type, vehicle details and
their ratings. Customers can review this information to make an informed decision when
selecting a driver.

R.7.1: Display Available Riders

 Input: “Find Rider” option is selected.
 Output: All the necessary information of the riders are shown.

R.7.2: Accept Ride

 Input: “Accept Ride” option is selected.
 Output: Booking Successful message and arrival time is displayed to the user.
 Processing: The rider and customer are mutually selected for the completion of a ride.

R.8: Payment
Description: After completion of the trip, customer must pay the estimated/calculated fare of
the ride. Customer can use any payment gateway like mobile banking or digital wallets
integrated within the system. They must login to any of the payment gateway using their
credentials to make a payment of the ride.

R.8.1: Select the payment option

 Input: Payment option is selected.
 Output: Prompt user to choose between available payment gateways.

R.8.2: Choose Payment Gateway

 Input: Selects a payment gateway from the integrated payment gateways within the
system.
 Output: Prompt user to enter credentials.

4
R.8.3: Make Payment
 Input: Input login credentials of the payment gateway.
 Output: Display payment successful message along with receipt and prompt the user
to write a review and give ratings to the rider.
 Processing: The system deducts a certain commission as per the company’s policy
from the total amount of the fare and the remaining amount is transferred to the rider’s
account.

R.9: Riders Review and Ratings

Description: The users can write their reviews and give ratings to the rider based on their
behavior and the service provided after completing a ride with them. This will help other users
to know about the riders and help them to choose a good rider for their ride.

R.9.1: Write a Review

 Input: Write Review option is selected.
 Output: The entered review is displayed.
 Processing: The system adds the review given by the user under the Review section of
the rider’s profile.

R.9.2: Give Ratings

 Input: Rate Rider option is selected.
 Output: The entered rating is displayed.
 Processing: Adds the rating points of the rider in the database along with the
information of the customer who has given a rating.

R.10: Dashboard
Description: Both the rider and customer have access to see their details from the dashboard.
From this interface, they can get information about previous rides and ratings. There is a
separate dashboard interface for riders and customers.

R.10.1: View Dashboard

 State: The user has logged in and has chosen the view dashboard option.
 Input: Clicks on the View Dashboard button
 Output: The user is redirected to his dashboard page where all the information of the
user is displayed.
 Processing: The system fetches all the information of the user from the database and
display it to the user. In case, the system fails to fetch data of the user, an error message
is displayed.

5
R.11: Edit Profile
Description: When the edit profile option is selected from the dashboard, the user will be
prompted to a new page to view their profile details. The user can then select to edit the profile
information like phone number, email, and password, and update the details by entering valid
information. If the details are invalid, the user will get an error message.

R.11.1: Select Edit Profile Option

 State: The user is currently on the Dashboard page and has selected the edit profile
option.
 Input: Select Edit Profile Option
 Output: The user is redirected to a page where they can edit their details.

R.11.1.1: Edit Phone Number

 Input: Select Edit Phone Number Option
 Output: Prompt to enter a new phone number.

R.11.1.1.1: Change Phone Number

 Input: User enters the new phone number.
 Output: Phone number updated successfully message is displayed.
 Process: Phone number validation is performed by the system. If the phone number is
valid, the phone number is updated in the system; otherwise, an error message is
displayed.

R.11.1.2: Edit email

 Input: Select Edit email option.
 Output: Prompt to enter a new email address.

R.11.1.2.1: Change email

 Input: User enters the new email address.
 Output: Email address updated successfully message is displayed.
 Process: Email validation is performed by the system. If the email is valid, the email is
updated in the system; otherwise, an error message is displayed.

R.11.1.3: Edit Password

 Input: Select Edit Password option.
 Output: Prompt to set up a new password.

R.11.1.3.1: Change Password

 Input: User enters the new password.
 Output: Password changed successfully message is displayed.
 Process: Password validation is performed by the system. If the password is valid, the
password is updated in the system; otherwise, an error message is displayed.

6
R.12: Emergency Support and Help Center
Description: From this, customers and riders can seek assistance, report issues and receive
responses from the customer support. In critical situations, like when an accident occurs
Emergency Support System is responsible for handling it. With this system both customer and
rider can send help request to the system then system generate request query to the admin.
Admin respond to the request through appropriate assistance.

R.12.1: Contact Customer Support

 Input: Select emergency contact
 Output: User prompt to the admin contact page

7
2. NON-FUNCTIONAL REQUIREMENTS

R.1: Performance
 The application should have fast response times and minimal latency to provide a
smooth and seamless user experience.
 The load time for user interface screens shall take no longer than 3 seconds.
 The login information shall be verified within 5 seconds.
 Riders must be returned within 30 seconds after clicking on the Find Riders button.
 Response from the maps API should be received within 5 seconds.
 It should be able to handle a high volume of concurrent users and ride requests without
significant performance degradation.

R.2: Scalability
 The application should be designed to handle an increasing user base and growing
demand without compromising performance.
 It should have the ability to scale horizontally by adding more servers or instances to
accommodate increased load.

R.3: Availability
 The application should be available 24 hours, ensuring minimal downtime and
uninterrupted service.
 It should have backup systems to handle unexpected failures and ensure data integrity.

R.4: Security
 The application should prioritize data security and user privacy by implementing
secure authentication and encryption mechanisms.
 It should protect user information, transaction data, and communication channels from
unauthorized access or breaches.
 The application must not grant access until the user creates a strong password
 The app shall have secure payment system integration.

R.5: Design Constraints

 The application should be compatible with various mobile for both IOS and Android to
cater to a wide range of users.
 It should support different operating systems with consistent functionality and user
experience.
 The system must use the Google Maps API.
 System should be able to handle large databases.

8
R.6: Usability and Accessibility
 The application should have a user-friendly interface with intuitive navigation and clear
instructions.
 It should comply with accessibility standards to ensure that users with disabilities can
access and use the application effectively.

R.7: Compliance with Regulations

 The application should adhere to local transportation regulations and legal requirements
in the regions where it operates.
 It should comply with data protection and privacy laws to safeguard user information
and ensure regulatory compliance.

R.8: Integration
 The application should support seamless integration with external services, such as
payment gateways, mapping services, and SMS/notifications providers.
 It should allow for easy integration with third-party APIs and services to enhance
functionality and user experience.

R.9: Maintainability
 The application should be designed with clean code practices, making it easy to
maintain, update, and enhance in the future.
 It should include appropriate documentation and facilitate bug fixing.

9
3. DATA FLOW DIAGRAMS

Data-flow diagrams (DFDs) are system models that show a functional perspective where each
transformation represents a single function or process. DFDs are used to show how data flows
through a sequence of processing steps. The DFD aims to capture the transformations that take
place within a system to the input data so that eventually the output data is produced. The
processes are shown by named circles and data flows are represented by named arrows entering
or leaving the bubbles. A rectangle represents a source or sink and is a net originator or
consumer of data. A source or a sink is typically outside the main system of study.

3.1 DFD Level-0

Level-0 depicts the basic overview of the whole system or process being analyzed or modeled.
It is also called as a Context Diagram. It’s designed to be an at-a-glance view, showing the
system as a single high-level process, with its relationship to external entities. It is easily
understood by audiences including stakeholders, business analysts, etc.

Figure 1 : Level-0 DFD of DriveLink System

The DriveLink software consists of three external entities; Customer, Rider and Admin. The
customer and rider must provide their information for the purpose of registration. To book a
ride, the customer needs to provide the location of pickup and destination to the system. Based
on that, the system will search for available riders and display them to the customer. Customer
then can select riders from the list and confirm the booking. The rider will be provided

10
necessary information of the ride booked. On completion of the ride, the customer must pay
fare for the ride using available payment gateway in the system. The system then adds the fare
amount to the rider’s account. The admin of the system is responsible for maintenance of
system and users account as well as provide assistance the users.

3.2 DFD Level-1

Level-0 DFD is broken down to Level-1 DFD into more specific and depicts basic modules in
the system and flow of data among various modules.

Figure 2 : Level-1 DFD of User Registration

The user first has to create and register their account. There are two kinds of accounts: customer
and rider. Everyone should register their account according to their roles. The Customer info
and Rider info are stored into their respective Customer and Rider databases.

Figure 3 : Level-1 DFD of User Login

To login into the system, the user has to enter their login Credentials. The login information
is verified using the user database. The user database provides the token and verifies the
account. Once verified, the system is ready to be used.

Figure 4 : Level-1 DFD of Ride Booking

11
To book a ride the customer must send a pickup request. The status of availability of nearby
riders is sent by the rider database to system. Then send the request info to the rider. On
acceptance by rider, the system sends the rider’s information and the confirmation prompt to
the customer.

Figure 5 : Level-1 DFD of Fare Calculation of the Ride

Based on the ride information (ride distance and type of vehicle), the system calculates the fare
cost. The system fetches the per unit ride cost Fare Database. After calculating the fare, the
Estimated fare is shown to the customer.

Figure 6 : Level-1 DFD of Edit Profile Information

The customer can change their profile information. They have to provide their updated email,
phone number, password to the system. The system updates the given information in the user
database and the updated information is shown to the customer.

Figure 7 : Level-1 DFD of Dashboard

The user can see their profile information from dashboard. The system retrieves their
information from the user database and displays it to the user.

Figure 8 : Level-1 DFD of Review and Rating System

12
Customer can rate their riding experience after he/she has reached to the destination. A
customer can give reviews and rating to his trip rider through Review and Rating system. Thus,
provided information's are stored in feedback database for future use.

Figure 9 : Level-1 DFD of Emergency Support System

In critical situations like when an accident occurs Emergency Support System is responsible
for handling it. With this system both customer and rider can send help request to the system
then system generate request query to the admin. Admin respond to the request through
appropriate assistance. Such information are stored in database as log information.

3.3 DFD Level-2

DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach
the necessary level of detail about the system’s functioning.

Figure 10 : Level-2 DFD for Customer Registration

Figure 11 : Level-2 DFD for Rider Registration

13
Firstly, the user has to select their role in the system. Their role may be a Customer or Rider.

For the customer, after they enter all the required information correctly, the data is saved into
the Customer Database. The registration confirmation is sent to the customer. After the
confirmation from the customer, the account is registered.

For the rider, after they enter all the required information correctly, the data is saved into the
Rider Database. The rider also needs to upload their driving license which is saved in the
Document Database after verification. The registration confirmation is sent to the rider. After
the confirmation from the rider, the account is registered.

Figure 12 : Level-2 DFD for User Login

Users provide their login details to the system and that users’ credentials are further checked
by the subsystem, check credentials. Check credentials subsystems then query the specific
details provided by the user with the user databases. In response, databases provide either the
valid or invalid notification back to the check credentials. If the response is valid then the user
is redirected to their specific dashboard or interfaces. Otherwise if the response is invalid then
the user again asks to provide the login details.

Figure 13 : Level-2 DFD for Ride Booking

14
After the selection of the rider by the customer, the booking is confirmed. Then the system
displays the rider's location on the map as well as the estimated arrival time of the rider.

Figure 14 : Level-2 DFD for Payment

The customer must pay the calculated fare using the available payment gateway in the system.
After payment is done by the customer, the system calculates the commission amount, deducts
the commission amount and credits actual fare amount to the rider’s account. The amounts are
saved into the Transaction Database by the system. Finally, a receipt is generated and provided
to the customer in PDF format.

Figure 15 : Level-2 DFD for Change Phone Number Function

To change phone number, the user should enter new phone number to the system. The system
then searches for the details of the user through the User ID and updates the entered phone
number of the user in the User Database.

Figure 16 : Level-2 DFD for Change Email Function

To change email address, the user should enter new email address to the system. The system
then searches for the details of the user through the User ID and updates the entered email
address of the user in the User Database.

15
 Figure 17 : Level-2 DFD for Change Password Function

For changing password first user have to provide the valid old password which is validated
from password database. Along with old password users also must verify captcha which is
generated from Captcha recognition system. Once the old password and captcha is validated
then the user’s phone number is extracted from the user database and OTP is sent to that phone
number. Thus provided OTP is entered by user so he/she has access to change password. Then,
finally, the user enters a new password which is saved into the password database.

16
4. UML USE CASE DIAGRAMS

In UML, use-case diagrams model the behavior of a system and help to capture the
requirements of the system. Use-case diagrams describe the high-level functions and scope of
a system. These diagrams also identify the interactions between the system and its actors. The
purpose of a use case diagram in UML is to demonstrate the different ways that a user might
interact with a system.

4.1 DriveLink Use Case Diagram

Table 1 : DriveLink System Use Case Description

Use Case Name: DriveLink

Participating Actors: Customer, Rider, System, Admin, Gateway

Preconditions:  Users must have done registration and logged into the
DriveLink system.
 Customer must book a ride by entering valid pickup and
destination location.
 Riders must be available in the system to accept rides.

Basic Flow of Events:

Customer: Accesses the DriveLink application and logs in using his/her login credentials.
System: Displays Ride Booking Interface with input options like Pickup Location, Destination
and Type of Vehicle (Car or Bike).
Customer: Enters required input fields for booking a ride and press Find Rider button.
System: Displays all the available riders near the pickup location along with estimated fare of
the ride.
Customer: Selects a rider from the list of riders shown by the system and confirms the booking
of the ride.
Rider: Accepts the booking of the ride done by the customer.
System: Tracks the real-time location of the rider and displays the estimated arrival time to the
customer.
Customer: Makes payment through available payment gateways in the application.
Gateway: Generates Receipt of the payment and displays it to the customer.
System: Calculates and deducts the commission amount and transfers the remaining amount
of the fare to the rider.
Customer: Gives rating to the rider and writes review based upon his/her experience during
the ride.

17
System: Updates the rating and review given by the customer into the database.
User: Accesses Edit Profile option and updates his/her details.
System: Updates the details of the user into the database.
User: Asks for Emergency Support in case of any critical circumstances.
Admin: Provides Assistance to the user.

Figure 18 : DriveLink System Use Case Diagram

18
4.2 Use Case Description

4.2.1 User Registration

Table 2 : User Registration Use Case Description

Use Case Name: User Registration

Participating Actors: User, System

The user has a valid phone number. The user is on the homepage of
Preconditions:
the application.

Description: 1. The user has selected either customer or rider.

2. User enters name, email id, phone number and password.

3. The system checks the validity of the credentials entered.

4. A confirmation email is sent to the user’s provided email

address.

Figure 19 : User Registration Use Case Diagram

19
4.2.2 User Login
Table 3 : User Login Use Case Description

Use Case Name: User Login

Participating Actors: User, System

Preconditions: The user is registered and is on the login page of the application.

Description: 1. The user selects Login.

2. The user enters the phone number and password.

3. System checks the validity of the login credentials.

4. If the credentials are matched, the user is logged into the

system.

Figure 20 : User Login Use Case Diagram

20
4.2.3 Book Ride

Table 4 : Book Ride Use Case Description

Use Case Name: Book Ride

Participating Actors: Customer, Rider, System
Preconditions: The customer is logged in.
Description: 1. The customer selects the pickup and destination location on the
map.
2. The customer selects the vehicle type, either bike or car.
3. The user selects a rider from the available list of riders which is
displayed by the system.
4. The ride is finally confirmed when the rider accept pickup
request.
5. The location of the rider and fare is displayed by the system.

Figure 21 : Book Ride Use Case Diagram

21
4.2.4 Payment System

Table 5 : Payment System Use Case Description

Use Case Name: Payment System

Participating Actors: Customer, Gateway, System

Preconditions: The customer has booked a ride and the ride is completed.

Description: 1. The user selects the payment

2. The user enters their account credentials and is checked by the
gateway. In case of invalid credentials, the gateway blocks
access.
3. The system generates the ride fare, and the gateway deducts
that amount.
4. The gateway generates the receipt and sends it to users.

Figure 22 : Payment System Use Case Diagram

22
4.2.5 Edit Profile

Table 6 : Edit Profile Use Case Description

Use Case Name: Edit Profile

Participating Actors: User, System

Preconditions: The user is logged in and is on Edit Profile page.

Description: 1. User views the profile and makes necessary changes to his/her
profile.
2. The system updates the changed details into the system
database.

Figure 23 : Edit Profile Use Case Diagram

23
4.2.6 Rider Review and Ratings

Table 7 : Rider Review and Ratings Use Case Description

Use Case Name: Rider Review and Ratings

Participating Actors: Customer, System

Preconditions: The customer is logged in and has completed a ride.

Description: 1. Customer select write review option which is completely

optional for them.
2. The customer shares their riding experience, rider’s behavior
review, vehicle comfort review and rate the overall riding
experience out of five stars.
3. The reviews and ratings data is updated to the system which is
shown in rider’s profile.

Figure 24 : Rider Review and Ratings Use Case Diagram

24
4.2.7 Emergency Support

Table 8 : Emergency Support Use Case Description

Use Case Name: Emergency Support

Participating Actors: User, Admin

Preconditions: The user is logged in and is on the trip.

Description: 1. User (Rider or Customer) in case of any critical situation make

request to the admin for emergency support by providing
necessary details of emergency condition.
2. The admin responds to the request through appropriate
assistance as soon as possible.

Figure 25 : Emergency Support Use Case Diagram

25
PROJECT SCHEDULE

Table 9 : Gantt Chart of the Project Activities and Schedule

1. Feasibility Study (3 weeks)

1.1 Market Analysis (5 days)
 Analyze the demand of the ride booking application for general people.
 Analyze the target audience, their preferences, and travelling behaviors.
 Study competitors and their offerings to identify market gaps and opportunities.

1.2 Technical Analysis (5 days)

 Evaluate the technical feasibility of implementing the DriveLink project.
 Consider whether the required technology and resources for the project are available or
can be acquired.
 Assess the compatibility of different technologies like geolocation, built-in maps and
traffic that need to be integrated.

1.3 Financial Analysis (5 days)

 Calculate the costs involved in developing, operating, and maintaining the project.
 Estimate potential revenues and profits including commission.
 Conduct financial projections, including return on investment (ROI), payback period,
and net present value (NPV) calculations.

1.4 Operational Analysis (3 days)

 Assess how the project will fit into existing ride booking operations.
 Determine the staffing and skill requirements for project development and ongoing
operations.
 Identify potential operational bottlenecks and how they can be addressed.
26
1.5 Risk Analysis (3 days)
 Identify potential risks and uncertainties associated with the project.
 Assess the impact and likelihood of each risk occurring.
 Develop strategies to mitigate or manage risks.

2. Requirements Analysis (6 weeks)

2.1 Requirements Definition (2 weeks)
 Define project scope, objectives, and deliverables.
 Conduct initial research and gather requirements related to ride booking application.
 Develop the project plan, including timelines and resources.

2.2 Requirements Collection (3 weeks)

 Gather requirements from stakeholders through interviews and surveys about their
specific requirements as well as expectation from the DriveLink system.
 Determine the important features and functions of the application such as booking ride,
user registration and login, real-time location tracking, review and rating, etc.
 Evaluate the user requirements and prioritize those on the basis of their importance.

2.3 Requirements Refinement (1 week)

 Refine the requirements by adding missing details, removing redundancies, and
clarifying ambiguities.
 Analyze the gathered requirements to ensure they are complete, unambiguous, and
ready for implementation.

3. Design (4 weeks)
3.1 UI/UX Design (2 weeks)
 Design the user interface (UI) of the application, including home page, registration
forms, login screens, ride booking interface and other interactive elements.
 Plan user flows and navigation paths to ensure users can easily achieve their goals
within the app and get smooth experience while using the application.

3.2 Database Design (1 week)

 Set up the database infrastructure, including creating tables, indexes, and relationships
to store all the information related to customers, riders and rides booked.
 Implement data access layers and database connectivity.

3.3 System Architecture Design (1 week)

 Plan the overall architecture of the system which includes the frontend and the backend
components.
 Integrate UI components with backend functionality.

27
4. Review and Update (2 weeks)
 Evaluate the feasibility of incorporating user feedback during DriveLink application
development and making iterative improvements.
 Gather user feedback and implement changes based on user needs to create a new
prototype that aligns better with the users’ requirements.

5. Programming (4 weeks)
5.1 Frontend Development (1 week)
 Implement interactive frontend elements such as buttons, menus, sliders, and forms.
 Implement animations for loading screens, page transitions, and interactive elements.
 Implement responsive design to ensure compatibility across devices and screen sizes.

5.2 Backend Development (1.5 week)

 Implement the server-side logic and APIs to handle user requests and process data.
 Develop user authentication and authorization mechanisms.
 Integrate with third-party services, such as mapping and payment gateways.

5.3 Real-Time Tracking and Navigation (1 week)

 Integrate mapping and navigation services for real-time location tracking.
 Develop features to provide accurate ETA and route optimization for drivers and
passengers.
 Implement geolocation-based matching algorithms for efficient ride dispatch.

5.4 Rating and Review System (0.5 week)

 Develop the functionality to capture and store customer and rider ratings and reviews.
 Implement mechanisms to calculate and update overall ratings for drivers and
passengers.
 Display rating information on driver and passenger profiles.

6. Testing and Debugging (2 weeks)

 Conduct unit testing, integration testing, and system testing to ensure functionality and
performance.
 Perform user acceptance testing to validate the application's usability and user
experience.
 Identify and fix any bugs or issues discovered during testing the DriveLink application.

7. Implementation (2 weeks)
 Deploy the tested and validated version of the DriveLink application to the production
environment.
 Conduct immediate testing in the production environment to ensure the deployed
DriveLink application is functioning correctly.

28