DEDAN KIMATHI UNIVERSITY OF TECHNOLOGY

PROJECT DOCUMENTATION FOR FINAL YEAR STUDY IN BSC COMPUTER

SCIENCE

SUBMITTED BY

KIMELI PETER (C026-01-1025/2015)

PROJECT TITLE

eMechanic

A project submitted to the Department of Computer Science in the School of Computer Science
and Information Technology in partial fulfillment of the requirements for the award of the degree
of the Computer Science Dedan Kimathi University of Technology.

2020
DECLARATION
I hereby declare that the project entitled E-Mechanic submitted for the B.Sc. Computer Science
degree is my original work and has not formed the basis of an award of any degree, diploma or
any other similar titles.

Name: KIMELI PETER

Signature:

Date:28-4-2020

This project has been submitted for university examination with my approval as the University
Supervisor.

Name MR. MICHAEL KAGIRI

Signature: _______________________

Date: __________________________

ii
ACKNOWLEDGMENT
I wish to take this opportunity to thank and appreciate the contribution of all those who are
participating in the success of this project. Firstly, I would like to thank my very able supervisor
Mr. Kagiri who is diligently going through my work making corrections and constantly guiding
me and without which the comprehensive structure of this project would not be achieved.
Secondly, to my parents Samuel Kiptanui Metto and Dinah Metto who are continually encouraging
me and financially supporting me to make the outcome of this project a success. Thirdly, to my
colleagues in class and in particular Emmanuel Muema who is also undertaking a degree in
Computer Science who in his own special way is sharing ideas in the course of our daily work.
Special appreciation goes to the staff members at Dedan Kimathi University, Staff of Department
of Computer Science who have impacted us with knowledge and skills in the field of Computer
Science and Mr. Matu a mechanic at Nyeri Town Garage, who is also very helpful in the retrieval
of useful information during the entire research work. Finally, I would like to appreciate anyone
else who in one way or the other is assisting in the process of this work. All your contribution and
assistance are greatly appreciated.

iii
ABSTRACT
Motor vehicles have been breaking down ever since they were invented and if a repair was not
possible, then a recovery or tow was usually required. In early days, this was often achieved by
pushing or pulling it home. Many of the first vehicle repair shops had been bicycle repairers or
blacksmiths, and they quickly adapted to recovering their customers' disabled vehicles. In addition,
the motorists were often capable of carrying out minor repairs themselves, but as vehicles become
more complicated, this becomes harder. Nowadays, vehicles are towed to a garage of choice for
specialized diagnosis and repair.

This study addresses the relationship between road transport infrastructure and the growing
economic opportunities specifically in the informal sector i.e. mechanic within Kenya and how
this relation enhances economic growth and development in the region.

The notion is that improved road transport hugely contributes to regional integration and hence
enhances economic growth and development. There is a need to ensure that integration works as a
means to achieve development objectives. In so doing, this will facilitate the movement of goods
and services across all the regions with subsequent related benefits.

The study gives informed recommendation and solution aimed at addressing challenges facing the
road transport infrastructure and drivers especially in the case of a car breakdown. The study looks
into the real challenge facing the drivers along the road especially during the instance of car
breakdown and there is need to get a mechanic to repair/fix the problem. It also looks at the issues
caused by car breakdowns such as road accidents, road jams, and insecurity issues.

The solution illuminates the need to develop an effective system to help drivers search for
mechanics on Google Map based on the current location of the driver and display the distance
between the driver and the mechanic. The system should allow the mechanic to remotely locate
the driver who has a car breakdown issue and easily communicate to know more about the problem
the driver is facing prior to visiting the site of a car breakdown. It should also allow for the
administrator to verify the user's details i.e. driver/mechanic before displaying on the client’s side
for the purpose of attaining security issues. This is done to prove for the valid users.

iv
Table of Contents
DECLARATION ............................................................................................................................................... ii

ACKNOWLEDGMENT ................................................................................................................................... iii

ABSTRACT .................................................................................................................................................... iv

Table of figures ............................................................................................................................................ ix

LIST OF TABLES.............................................................................................................................................. x

ABBREVIATIONS ........................................................................................................................................... xi

1. CHAPTER ONE ......................................................................................................................................... 12

1.1 Background Information................................................................................................................... 12

1.2 Problem Statement........................................................................................................................... 14

1.3 Research Objective ........................................................................................................................... 15

1.3.1 General Objective .......................................................................................................................... 15

1.3.2 Specific Objectives ..................................................................................................................... 15

1.3.2 Justification of the study ........................................................................................................... 15

1.3.3 Scope of the study ..................................................................................................................... 16

1.4 Limitations ........................................................................................................................................ 16

2 CHAPTER 2: LITERATURE REVIEW ............................................................................................................ 17

2.1 Introduction ...................................................................................................................................... 17

2.2 Case Studies ...................................................................................................................................... 17

2.2.1 Case Study 1: J&F Auto Repair ................................................................................................... 17

2.2.2 Case Study 2: Openbay .............................................................................................................. 18

2.2.3 Case Study 3: Auto Connect....................................................................................................... 19

2.2.4 Case Study 4: Engie .................................................................................................................... 19

2.2.5 Case Study 5: Breakdown Recovery Vehicles ................................................................................ 20

2.2.6 Case Study 6: Breakdown, Towing & Recovery Services ............................................................... 21

v
 2.3 Summary........................................................................................................................................... 21

2.4 Proposed System .............................................................................................................................. 22

2.5 Comparison of Features ................................................................................................................... 22

3 CHAPTER THREE: SYSTEM METHODOLOGY............................................................................................. 23

3.1 Introduction ...................................................................................................................................... 23

3.2 System Development Methodology ................................................................................................. 23

3.2.1 Stage 1: Planning ........................................................................................................................... 24

3.2.2 Stage 2: Requirements analysis ..................................................................................................... 24

3.2.3 Stage 3: System analysis and design .............................................................................................. 25

3.2.4 Stage 4: Coding/Building................................................................................................................ 25

3.2.5 Stage 5: Testing.............................................................................................................................. 25

3.3 TOTAL POPULATION ......................................................................................................................... 26

3.3.1 Sample Size ................................................................................................................................ 26

3.3.2 Sampling Design ........................................................................................................................ 26

3.4 Requirements Gathering Techniques ............................................................................................... 27

3.4.1 Questionnaires............................................................................................................................... 27

3.4.2 Interviews ...................................................................................................................................... 27

4 CHAPTER FOUR: RESULTS ........................................................................................................................ 28

4.1 Questionnaire Results........................................................................................................................... 28

4.2.1 Questionnaire Analysis .................................................................................................................. 28

4.2.2 Interviews ...................................................................................................................................... 31

Figure 2: Recommendation for a new system interview pie chart ............................................................ 32

5 CHAPTER 5: SYSTEM DESIGN .............................................................................................................. 33

5.1 Introduction .......................................................................................................................................... 33

5.2 Functional Requirements...................................................................................................................... 33

vi
5.3 Non-Functional Requirements.............................................................................................................. 33

5.4 UML Diagrams ...................................................................................................................................... 34

5.4.1 Deployment Diagram ..................................................................................................................... 34

5.4.2 Sequence Diagram ......................................................................................................................... 35

5.4.3 Activity Diagram ...................................................................................................................... 37

5.4.4 Use Diagram ............................................................................................................................ 39

CHAPTER 6: SYSTEM IMPLEMENTATION AND TESTING ............................................................................. 40

6.1 Introduction .......................................................................................................................................... 40

6.2 Test Plan................................................................................................................................................ 40

6.2.1 Unit testing .................................................................................................................................... 40

6.2.2 Integration testing ......................................................................................................................... 41

6.2.3 Acceptance testing ........................................................................................................................ 41

6.3 Test Cases ............................................................................................................................................. 42

6.3.1 Registration and Login Test Case ................................................................................................... 42

6.3.2 Manage User Accounts Test Case .................................................................................................. 43

6.3.3 Locating Nearest Mechanics Test Case.......................................................................................... 44

6.3.4 Mechanic’s Receive Driver Request Test Case .............................................................................. 46

6.4 Implementation .................................................................................................................................... 47

6.5 Deployment .......................................................................................................................................... 47

7.0 CHAPTER 7: CONCLUSION AND RECOMMENDATION .......................................................................... 49

7.1 Discussion ............................................................................................................................................. 49

7.2 Limitations ............................................................................................................................................ 49

7.3 Recommendation ................................................................................................................................. 49

7.4 Conclusion............................................................................................................................................. 49

8.0 REFERENCES .......................................................................................................................................... 51

vii
8.1 APPENDICES .......................................................................................................................................... 52

8.1.1 Resources ....................................................................................................................................... 52

8.1.1.1 Hardware resources.................................................................................................................... 52

8.1.1.2 Software resources ..................................................................................................................... 52

8.1.2 Gantt chart ................................................................................................................................. 53

8.1.3 Budget............................................................................................................................................ 54

viii
Table of figures
Figure 1:Agile Development Methodology .................................................................................. 23
Figure 2:Deployment diagram ...................................................................................................... 34
Figure 3:sequence diagram ........................................................................................................... 35
Figure 4:registration and login test case ....................................................................................... 42
Figure 5:Manage User Accounts Test Case .................................................................................. 43
Figure 6:Manage User Accounts Test Case .................................................................................. 44
Figure 7:Driver Request Test Case ............................................................................................... 46

ix
LIST OF TABLES

Table 1: Comparison of Feature.................................................................................................... 22

Table 2:Recommendation for a new system interview table ........................................................ 31
Table 3:Unit testing table .............................................................................................................. 40
Table 4: integration testing table ................................................................................................... 41
Table 5 :Acceptance testing table ................................................................................................. 41
Table 6:Hardware Resources ........................................................................................................ 52
Table 7:Software Resources.......................................................................................................... 52
Table 8:Gantt chart........................................................................................................................ 53
Table 9:Budget .............................................................................................................................. 54

x
ABBREVIATIONS
ERS - Economic Recovery Strategy…………………………………………………………….9

GDP - Gross Domestic Product………………………………………………………………….9

xi
 1. CHAPTER ONE
1.1 Background Information
Transportation developments have taken place since the beginning of the industrial revolution have
been linked to growing economic opportunities. At each stage of societal development, a particular
transport technology has been developed or adapted with impacts. Transportation influences
economic opportunities for production and consumption.

In Kenya for example, the transport sector contributes between 5 to 15 % of the GDP(Summary,
2007). However, the impact of transport goes well beyond its share of the economy as it serves as
an intermediary service to all sectors and is therefore critical to economic growth and poverty
eradication. For instance, by identifying the transport sector as one of the main pillars of the
economic recovery effort in the “Economic Recovery Strategy for Wealth and Employment
Creation 2003-2007” (ERS), the Government of Kenya has shown recognition of the transport
sector contribution towards facilitation of rapid economic growth and reconstruction, poverty
eradication and in employment creation.

Because of its intensive use of infrastructure, the transport sector is an important component of the
economy and a common tool used for development. This is even more so in a global economy
where economic opportunities have been increasingly related to the mobility of people, goods, and
information (Sarah Anyango, 2014). A relation between the quantity and quality of transport
infrastructure and the level of economic development is apparent. they provide economic and social
opportunities and benefits such as better accessibility to markets, employment (both in the informal and
formal sector) and additional investments. The added value and employment effects of transport
services usually extend beyond those generated by that activity. For instance, transportation
companies purchase a part of their inputs (fuel, supplies, maintenance) from local suppliers. The
production of these inputs generates additional value-added and employment in the local economy.
The importance of specific transport activities is the employment creation in the informal sector
i.e. mechanics. Many youths with skills have been employed as mechanics and are now able to
earn a living through this sector.

Due to the good transport sector, goods and services have been able to reach the market on time.
Unfortunately, there are other issues that have affected this sector negatively causing transported
goods to the market perish. The main one being car breakdown on the roads causing traffic jams

12
along the roads especially on the road highways and road accidents mainly on the black spot’s road
sections for example in Kenya we have the black spot along Nakuru-Eldoret; Salgaa. This has led
to the loss of lives and destructions of property during the incident. Car breakdown along the road
is also associated with insecurity especially when the driver experience car breakdown while
driving in new areas and can’t find a nearest trusted mechanic and can find ending up being
attacked by someone pretending to be a mechanic. Mechanics also aren’t aware that there is a
vehicle that has broken down on the remote areas. Therefore, there is a need to develop a platform
to help drivers find nearby mechanics in case of a car breakdown.

According to the latest sector statistics from the Communications Authority, Kenya now has over
90% mobile penetration (Kemibaro et al., 2019). In the period April to June 2016, mobile
subscriptions reached 39.7 million up from 38.3 million subscriptions recorded last quarter. This
translates to an increase of 3.7 percent or 1.4 million new mobile subscriptions during the quarter.
According to Google’s Consumer Barometer, smartphone uptake in Kenya was at 44% in 2016.
This is a massive jump from 2014 when smartphone uptake was measured in the same survey as
being only 27%. This suggests inexpensive smartphones that are now going for as little as Kes.
3,000.00 are clearly driving a massive shift from feature phones which used to be the dominant
mobile device in Kenya (Google’s Consumer Barometer, smartphone uptake in Kenya, 2019) .

13
1.2 Problem Statement
Currently, drivers, especially in the remote areas, encounter difficulty in accessing the
nearest mechanic in the cases of experiencing car breakdown due to the barrier in
communication between them and the mechanics. Also, the mechanics can’t notice that
there is a vehicle that is broken down in the remote areas and needs to be repaired because
they only operate in their station; garage/petrol station waiting for the clients to come to
them physically or respond to phone calls from the clients who have been referred to them.
Sometimes when they receive a call from a stuck driver, they gather some information from
the drivers prior to them traveling to the car breakdown site. Secondly, those operating at
the garage have two types of breakdown they do which include major breakdown and
minor breakdown. Major breakdown includes engine knock gearbox failure and deferral
failure. This will be done at the garage because it requires more time and tools. Therefore,
they normally offer recovery/toy services to transport the car to the garage station. Minor
breakdown includes brakes, clutch, and fuse wiring failure. This will be repaired at the site
of a car breakdown. In the scenario where a driver is new in an area and knows no-one, it’s
very hard to find a trusted mechanic since there is no means to find them. This poses a
challenge to the transportation of goods and services to the market due to delay in the
process of finding a mechanic. The drivers are the ones mostly affected this problem mainly
in accessing the nearest mechanic within their current location site of a car breakdown. To
find the nearest mechanic is only limited to physical means and making inquiries from the
local people residences. The study addresses the need to develop an E-Mechanic
application to help drivers find the nearest mechanics in the case of car breakdown to cater
to the process of using physical means It focusses on connecting the drivers with mechanics
at the comfort of the smartphone in a safer, faster and convenient way.

14
 1.3 Research Objective
1.3.1 General Objective
The main objective of this study was to develop an E-Mechanic Mobile Application that helps

drivers locate nearby mechanics in case of a breakdown in a simplified and convenient way.

1.3.2 Specific Objectives

To develop a platform that:

1. display mechanics’ location from the driver’s location via Google Maps.
2. enables driver search mechanics based on distance.
3. displays the path between the driver and mechanic via Google Map
4. enables drivers rate Mechanics based on their work.

1.3.2 Justification of the study

Car breakdown is one type of incident that often occurs on motorways and it is a nonrecurrent
event. It is not a planned closure of a road nor a special event; therefore, there is no advanced
notice. Car breakdown along the roads have become one of the main causes of traffic congestion,
risk of secondary crashes for other road users, burglary and increased fuel consumption caused by
the congestion especially along the highways and the black spot road regions in Kenya. This has
become a threat to national security and slow growth rate in economic activities. In 2014, it was
estimated that traffic in Nairobi costs $570,000 per day. This is a significant amount and can be
used productively elsewhere. One of the main reasons for this congestion is seen to be the ever-
expanding population and hence the increase in the number of vehicles growing at a higher rate
than the road capacity. The population of Nairobi has grown from 350,000 in 1963 to about 3.3
million. The number of vehicles in Nairobi was estimated at over 300,000 in 2008. In the same
period, there has been a limited increase in the existing road infrastructure capacity (Attri, 2016).
This shows us that the problem is one that cannot be ignored and therefore, this problem needs to
be tackled as soon as possible. As car breakdown cause more congestion, more congestion brings
with it more incidents of traffic jams and accidents especially in the urban areas and along the
highways. Many Kenyans utilize different transport modes to reach their various destinations on
a daily basis. Nearly 3000 people are killed on Kenyan roads annually. This translates to
approximately 68 deaths per 10,000 registered vehicles, which is 30-40 times greater than in highly

15
motorized countries. Nairobi County has one of the highest road fatality rates in relation to vehicle
ownership in Kenya, with an average of 7 deaths from the 35 road crashes that occur each day.
Despite the huge burden the major causes of accidents in Nairobi, have not been modeled so as to
outline the major causes and their inter-relatedness. Current interventions are scattered,
uncoordinated and less effective despite the huge economic burden exerted by RTAs (Daniel,
2016). There was need for E-Mechanics to be developed to help drivers in searching and locating
nearby mechanics thereby facilitating easy communication between the driver and the mechanic
in the event of car breakdown and the driver knows no-one especially when driving in new areas.
E-Mechanic will also help mechanics to locate the drivers from the remote areas who are stuck
due to a car breakdown. This will solve the problem of traffic jams and road accidents since it will
be faster to find a mechanic to solve the problem of a car breakdown.

1.3.3 Scope of the study

The study was limited to developing an E-Mechanic System, an Android smartphone system that
facilitates searching and locating the nearest mechanic along the roads in the case of a car
breakdown. The target market for this system includes the drivers and a mechanic. However, this
study was undertaken within Nyeri Town, King’ongo’, Mweiga and Othaya so as to help in
establishing a general problem and a solution under investigation.

1.4 Limitations
The system is only limited to drivers and mechanics who own an Android smartphone. The system
uses Google Maps API which needs regular payment on a yearly basis. It also needs data to
displays the Map which needs regular purchase from a network service provider.

16
2 CHAPTER 2: LITERATURE REVIEW
2.1 Introduction
This chapter focuses on the discussion of the literature found important to this study, a review of
the available case studies, theoretical literature, review of the critical literature, the summary of
the topic, gaps to be filled and in conclusion the proposed system. Also, it focuses on describing
their structures, architectures and their implementation.

2.2 Case Studies

2.2.1 Case Study 1: J&F Auto Repair
An analysis of a system developed by J&F Auto Repair found the following features and
functionalities:

• Auto repair appointment booking

• Contact details functionality
• Car towing and recovery services

It is a web-based system auto-repair shop located just outside of Indianapolis in the town of
Clermont. They strive to provide high-quality repairs at a fair price to keep the customers happy.
They provide an online auto-repair booking appointment to its customers(drivers) either for a
routine inspection or an oil change, alignment or engine replacement. It has mechanics who are all
certified and have over 65 years of experience, knowledgeable and friendly. They also offer towing
services in case of car breakdown along the road. The driver can find the contact details listed on
the website. The driver can visit the website and check for routine service prices and the small
amount of information about the services and if satisfied with the service, the driver can contact
the company using the contacts provided at the bottom of their website for assistance in getting to
know more about the service and how they can reach the station.

At J&F Auto Repair, the driver has followed the guidelines on the website, he/she will add to the
list of those who have booked for the service (J & F Auto Repair, 2019). However, drivers have to be
careful since they can find that at the time of booking, the mechanic is busy with other customers
and can’t help them at that moment. This may frustrate them before resuming for other income
generating activities. Currently, there is no way the drivers can be advised on the right time to
book for the mechanic before they come to the garage. The system above is a web-based which

17
can be improved by making it android hence reducing the time required searching through a
series of web-pages. It focusses only on providing routine auto-repair online booking services to
its customers. The e-Mechanic app is more competitive in that it focuses on driver satisfaction
based on the real-time access of the mechanic/garage anywhere from the mobile app in a safer,
faster and secure way.

2.2.2 Case Study 2: Openbay

An analysis of the system developed by Openbay found the following features and functionalities:

• Online booking of the auto mechanic services

• List of mechanics

Openbay is a web-based online platform where drivers can compare, book and pay for auto
mechanic services online. It was launched last year October and is easy for the drivers to use. It is
a platform where mechanics can submit their details and then drivers can find them here. It has a
dashboard for drivers to access all the account activities and even offers the ability to sign into the
account via Facebook. The driver has to establish an account, during which time he/she can list
his/her vehicle, enter billing information and complete a few other profile details. When the driver
needs a repair, he/she select Request Service for a particular car and state preferences: for instance,
the driver not only enters the need of a wheel alignment but also use a dropdown menu to say how
soon they want the repair. Additionally, they can select what kind of amenities they desire from a
list that includes loaner car, early drop-off, shuttle service. If they don’t exactly know what is
wrong with the car, they can submit a Custom Service Request or select General Diagnosis and
provide a detailed description in the Notes box. Once they submit the request, Openbay will contact
providers on their behalf. They’ll receive a list of nearby mechanics, who will respond to them
with offers. They can compare their prices, locations, and amenities as well as user ratings and
reviews before booking the service appointment.

Openbay is also a web-based which can be improved by making it android hence reducing the time
required searching through a series of web-pages. It allows for online booking of a mechanic but
does not have a mechanism of contacting a mechanic in case of an emergency breakdown. Openbay
also provides a list of mechanics but not the exact location (openbay.com, 2019).

The e-Mechanic app is different in that it focuses on driver satisfaction based on the real-time
access of the mechanic/garage anywhere from the mobile app via Google Map in case of
18
emergency car breakdown and needs repair or towing services in a safer, faster and secure way
instead of visiting web pages.

2.2.3 Case Study 3: Auto Connect

An analysis of the system developed by Auto Connect (CodeCanyon, 2019) found the following
features and functionalities:

• User sign up
• List of the nearest mechanics
• Online booking of auto repair services

Auto-Connect is a High-end mobile application for automotive technicians or Auto Mechanics,

Auto Repair Chains and small, medium and large shops. It facilitates online mechanic booking for
any vehicles from any time anywhere. Auto-Connect helps drivers book a full auto service or repair
by finding the nearest mechanic. This app is meant for auto repair companies situated in towns.

The app has an interface where a drive can sign up and find a list of mechanics but it has no exact
location where the driver can find the mechanic and it is only meant for booking of a mechanic but
does not provide emergency services especially in case of a car breakdown. Also, Auto Connect
does not provide exact location where the mechanic is located. E-mechanic is different from Auto
Connect in that it focusses on providing drivers a list of nearest mechanic. It is also competitive in
that it focuses on driver satisfaction based on the real-time access of the mechanic/garage anywhere
from the mobile app in a safer, faster and secure way.

2.2.4 Case Study 4: Engie

An analysis of the system developed by Engie (Play.google.com, 2019) found the following features
and functionalities:

• List of mechanics
• Monitoring of parts of a car
• Mechanics ratings
However, for many years, drivers have been facing the challenge of being unable to monitor parts
of a car and get regular information on the performance of the car. Engie was developed to solve
this challenge. It aims at solving this problem of providing regular updates on the performance of
all the parts of a vehicle in a timely manner. The driver has to purchase the Engie device through
the app and plug it in under the dash. Engie simplifies car repair and maintenance and once paired
19
with the Bluetooth device, the app scans and reports on over 10,000 car faults, as well as provides
analytics on fuel consumption, trip tracking, and parked car location.

Engie aims at assisting drivers diagnoses when the car malfunctions and immediately provide a
warning. Automatic warnings of a car’s motor’s status are sent text to the phone number of the
driver; therefore, the driver will know when they need a repair. It also provides simple explanations
of over 10,000 malfunctions, from warning lights to issues under the bonnet.

Engie also provides a list of local mechanics, so that the driver can’t travel with a check engine
warning light for long. Mechanics also have ratings so that the drivers are confident they will
accurately and affordably repair their car. It has a list including multiple mechanics with various
specialties and prices. Engie aims at helping the driver understand how the car works and keep up
with maintenance, monitors important parameters, such as battery life, oil and petrol volume, and
fuel consumption, alerts the driver when they have upcoming maintenance.

The e-Mechanic app is more competitive in that it will cater for the issue of finding the nearest
mechanic within the drivers’ location .It also provides the distance from the driver to a nearby
mechanic.

2.2.5 Case Study 5: Breakdown Recovery Vehicles

An analysis of the system developed by Breaking Recovery Vehicles found the following features
and functionalities:

• Company Location
• Contact details
• Services offered by the company

Breakdown Recovery company is a 24-hour local Car breakdown recovery service situated in
Hurlingham Nairobi with safe and secure overnight storage facilities. They are able to provide full
support to assist car drivers, along with drivers of vans and the light commercial vehicle drivers in
the case of an accident or simply when the car has broken down. The e-Mechanic app is different
in that it focuses on driver satisfaction based on the real-time access of the mechanic/garage
anywhere from the mobile app in a safer, faster and secure way. The app will provide the nearest
mechanic registered to operate.

20
 2.2.6 Case Study 6: Breakdown, Towing & Recovery Services
An analysis of the system developed by Breakdown, Towing and Recovery Services found the
following features and functionalities:

• Company Location
• Contact details
• Services offered by the company

They offer vehicle towing and recovery services within and outside Nairobi at affordable costs.
Their flatbeds are modern and available to transport cars countrywide. They guarantee the safety
of cars from one location to the final destination. The driver can find the contact details listed at
the bottom of the company website. The e-Mechanic is more competitive in that it focuses on driver
satisfaction based on the real-time access of the mechanic/garage anywhere from the mobile app
in a safer, faster and secure way.

2.3 Summary
Most of the systems identified from the case studies are having certain concepts of locating
mechanics while lacking others. For instance, the J&F Auto Repair web-based system is an
Indianapolis online mechanic booking system which can be improved by making it android hence
reducing the time required searching through a series of web-pages.
Auto-Connect is an android app that facilitates the booking of mechanics and also displays a list
of mechanics. It does not show exactly where the mechanic is located from the driver’s location.
This can be improved by adding the functionality of Google Maps to help drivers search for
mechanics and view them in Google Map. Engie is a hardware that is embedded to the hardware
of a car to help in detecting the malfunctioning of the car parts then an SMS to the driver’s phone.
It will also help update the driver of when to visit the mechanic for the service. This can be
improved by developing an android app that helps in finding the nearest mechanic to fix the
problem identified by the Engie.
The e-Mechanic app will be different from Engie in that it is running on the Android platform and
cater to the problem of locating mechanics to respond to an emergency car breakdown. It caters
for contacting the nearest mechanic to fix the problem.

21
2.4 Proposed System
e-Mechanic app helps drivers locate nearby mechanics in case of a breakdown in a simplified way
using their mobile phones. It displays the mechanics’ location and distance from the drivers’
location via Google Maps. Finally, the system also helps drivers search mechanics based on
distance.

2.5 Comparison of Features

Feature J&FAutoRepair Openbay Auto-Connect Engie My Solution
(E-Mechanic)
Location on Maps × × ×
Emergency repair × × ×
Contact × ×
Search functionality × × × ×

Table 1: Comparison of Feature

22
3 CHAPTER THREE: SYSTEM METHODOLOGY
3.1 Introduction
In this chapter, the focus is fact-finding techniques that is used in the preparation of developing the
system, population, sample, sampling technique, and requirements gathering technique are
discussed. The information system development methodology used to develop the E-Mechanic is
also specifically described. The techniques were to enable the gathering of facts that concern the
development of this project. The facts are used as a user and functional requirements of the
application because they depict what the users expect the application to do on its completion.

3.2 System Development Methodology

The Agile development model was appropriate for the development of this project because of its
interactive and iterative nature. The development is based on stages, and with the use of the model,
once the first phase of the project is done, it is released to the users and if they have any feedback
the process is repeated from stage one after which it will be released again. The process iterates
several times till the whole project is complete and the customer is satisfied. The model goes
through the following activities.

Figure 1:Agile Development Methodology

23
For iteration one, the aim is to develop a user interface for both the driver and mechanic to register
and log in. This phase is released for users to check for all the details they need and provide the
feedback on issues needed to be addressed if they are not satisfied it.

During iteration two once the user interface for authentication has been done to its completion, the
user current location is captured and whether he/she is the driver or mechanic. This is done to help
during car breakdown on who has encountered the difficulty, for this case is the driver who needs
the mechanic. It is then deployed to the users of the system (drivers and mechanics) to test and
ascertain that all the requirements needed have been captured. They will then provide any feedback
for the sections they are not satisfied with. If they are not satisfied with the system at this stage and
they provide the feedback, the process is repeated again to include all the requirements and
deployed again.

The final iteration is an iteration 3. At this stage, user authentication is connected with the current
location on Map with the details of that user whether he or she is the driver or mechanic. The app
is then deployed for the drivers and mechanics to ascertain that it is working according to their
needs.

3.2.1 Stage 1: Planning

The planning phase is helpful in the identification of stakeholders (drivers and mechanics) and the
infrastructure and components required in developing the system. It is useful in security-related
information gathering requirements for the drivers and mechanics. Tasks are then prioritized to
build the system.

3.2.2 Stage 2: Requirements analysis

All possible requirements of the e-Mechanic app were captured in this phase and documented in a
requirement specification document. Interviews and questionnaires techniques was used to collect
data from the drivers who will be searching for mechanics through the system in case of a car
breakdown. This was helpful in getting a deeper understanding of the challenge drivers to undergo.
With this, existing challenges were established and the possible solutions on the modules being
developed. The gathered information from the planning phase were used for requirements analysis
whereby charts has been drawn, tables and pie charts.

24
3.2.3 Stage 3: System analysis and design
Based on the information gathered from the research of the current
stakeholders(drivers/mechanics); all the challenges and recommendation from the current system
have been obtained. This system design is helpful in specifying hardware and system requirements
and helps in defining the overall system architecture. The requirements of the users have been
taken into account. Moreover, evolving requirements will be considered as they come up to make
the system better every day. At this stage, designing of the system began. Different diagrams have
been drawn which includes class diagram, activity diagram, state transition diagrams etc. They are
done on paper before the actual implementation.

3.2.4 Stage 4: Coding/Building

After gathering enough system requirements, the process of system implementation and actual
coding will be commenced using Firebase in conjunction with other web-based languages for the
administration side and Android for other system users. Also, Firebase database is used for data
storage. The aim of all this is to come up with a working system that meets its requirements and
the defined functionality.

3.2.5 Stage 5: Testing

Testing is carried out by system users and will continue to be undertaken to verify that the modules
are achieving the intended objective. This involve activities such as checking for data validations
and correctness of processes. The various test types include unit test, integration test, system test,
and acceptance test

Unit testing specifically White Box Testing will be carried out for each individual units/
components of an E-Mechanic System. The purpose is to validate that each unit of the E-Mechanic
System performs as designed. Integration testing level was done where individual units are
combined and tested as a group. The purpose of this level of testing is to expose faults in the
interaction between integrated units. Test drivers and test stubs are used to assist in Integration
Testing. After the Integration Test, system testing is done where a complete and integrated is
tested. The purpose of this test is to evaluate the system’s compliance with the specified
requirements. Finally, acceptance testing was carried out to test for acceptability by the users. The
purpose of this test is to evaluate the system’s compliance with the business requirements and

25
assess whether it is acceptable for delivery. It is the last phase of the testing, after which the E-
Mechanic System goes into production. This is also called User Acceptance Testing (UAT).

3.3 TOTAL POPULATION

The study focused on the drivers who are dealing directly with the transportation of goods and
services from one region to another. It also targeted the owners of garages and mechanics.
Mugenda and Mugenda (2003), explains that the target population should have some observable
features, to which the research should generalize the results. And therefore, the assumption of the
definition is that the population is not homogenous.

3.3.1 Sample Size

According to Mugenda & Mugenda (2003), good study research should have a well-formulated
procedure of selecting the subject or cases that should be included in the sample thus the
importance of a sampling frame which forms the unit of observation in a study. A sample
population will be drawn from the sampling frame. A sampling frame includes the actual list of
individuals included in the population (Nesbary, 2000). According to Patten (2004), the quality of
the sample affects the quality of the research generalizations. Nesbary (2000), suggests the larger
the sample size, the greater the probability the sample will reflect the general population
(Караштин, Шлюгаев, & Гуревич, 2005). The sample size is calculated from the total population
and there are formulas for calculations.

The respondents above were drawn from 4NTE Matatu SACCO and National Petrol Station
(Nyeri). However, for objectivity purposes, other respondents were drawn from the private
transport sector, mechanics from within Nyeri and other key informants from main garages from
Nairobi who are well conversant with the car repair and maintenance issues.

3.3.2 Sampling Design

The research study for this project was to adopt a simple random sampling technique. Simple
random sampling was adopted in the selection of 10 respondents from 4NTE SACCO
The initial task was to obtain a sample frame, which is a list of drivers from this SACCO. Being
that the sample frame consists of a maximum of 10 respondents,5 respondents were eligible to
participate in the study. During planning, requirement analysis, design, development and testing
the project has been and will be working with a sample size of six drivers and six mechanics.

26
3.4 Requirements Gathering Techniques
It is the process of collection of data and information usually based on techniques. I will engage in
these techniques in coming up with my project using data facts to create useful information,
process functions to perform the objectives and interface designs to interact with users. The
techniques are interviews, document analysis and questionnaires. The goal of this study is to
determine whether the current platforms are available and improve on them. The methods for data
collection include:

3.4.1 Questionnaires
The project prepared ten structured forms with a relevant set of questions that were designed to
collect information from the potential users of the e-Mechanic. These respondents were required
to write answers, tick checkboxes, suggest ranges and give their personal opinions concerning the
development of the e-Mechanic System.

3.4.2 Interviews
This is the most commonly used requirement elicitation technique. Interviews were useful during
the study to get to talk with the drivers and mechanics to know how they operate and also if they
think having an app will be useful. The main target drivers and mechanics that was used in the
interview study was from within Nyeri and also outside Nyeri Town. It is the main fact-finding
technique since it’s accurate, reliable and it allow for clearing and cross-checking the doubts in
real time.

27
4 CHAPTER FOUR: RESULTS
4.1 Questionnaire Results
This technique aimed at collecting data from 6 mechanics and 6 drivers within Nyeri Town. Hence
the survey managed to collect data from all the 6 drivers and mechanics.

4.2.1 Questionnaire Analysis

Driver

QUESTIONS RESPONSES RESPONDENTS

1. Have you ever encountered Yes Yes = 5

mechanical car breakdown?
No No = 1

2. How do you get assistance? Stop an Incoming Car 4

Online 0

Asked a friend 2

0-3 hours 3
3 How long did it take to get help from 3-5 hours 1
the mechanic?
More than 5 hours 2

4. How far did you did you get help from 0-3 Kilometres 2
the car breakdown site? 3-5 Kilometres 3

5-20 Kilometres 1

More than 20 Km 1

28
5. Are you aware of any app/tool that can Yes 0
connect you to the mechanic? No 6

6.If an app that displays the nearest Yes Yes = 5

mechanic and distance between you and No No = 1
the mechanic was provided would such
an app be useful? And would you support
and use it?

7 Would recommend such an app/tool to Strongly recommend 3

someone? Recommend 2

Least recommend 1

Not at all 0

29
Mechanic

QUESTIONS RESPONSES RESPONDENTS

1. Have you ever been to a car Yes Yes = 5

breakdown site in the emergency
notification from the driver? No No = 1

2 When did you last visited the site 0-3 Months 4

of car breakdown for the service?
4-12 Months 0

More than a year 2

Through a friend 2
3. How did you get notified that Phone Call 3
there is a driver that needs his/car
repaired? Through a driver 1

4 Do most of the drivers prefer/get Yes 4

specific mechanic
No 2

5. Do you normally get Yes 6

customers/drivers coming to your
garage for the services in the case of No 0
car breakdown?

6. Do you get notified about the Yes Yes = 5

drivers whose vehicles have
encountered breakdown on the No No = 1
remote areas?

7 Is the procedure of getting the Yes 0

remotely locating the driver efficient,
reliable and accurate? No 6

30
 8 Are you aware of any app/tool Yes 0
that can help in connecting
drivers and mechanics? No 6

9 If you had an app that remotely Yes 5

locate the driver and displays the
distance was provided would you No 1
use such an app?

10 Do you think an app provided Yes 5

would help?
No 1

11 Would you recommend such an Strongly recommend 4

app to your friend?
Recommend 2

Not at all 0

4.2.2 Interviews
I interviewed 10 stakeholders who are drivers and mechanics.

Recommendation for a new system interview table.

Number of Respondents Recommending for a new system Not recommending for a new system

10 7 3

Table 2:Recommendation for a new system interview table

Percentage of those who recommend for a new system.

7/10*100=70%

Percentage of those who did not recommended for a new system.

3/10*100=30%

31
 30%

recommending for a new system

Not recommending for new system

70%

Figure 2: Recommendation for a new system interview pie chart

From the interviews, it was noted that:

The current systems used nowadays are prone to shortcomings. Most people cited that
the shortcomings of the current systems make them not comfortable in using them
requesting for a new system to address the shortcomings.

32
 5 CHAPTER 5: SYSTEM DESIGN
5.1 Introduction
A requirement is simply a high-level, abstract statement of a service that a system should
provide, or a constraint on a system. Requirements analysis is the process of developing
software specifications that are intended to communicate the system needs of the users to
the system developers.
Software system requirements are often classified as functional or non-functional
requirements.

5.2 Functional Requirements

It relates to a process the system has to perform. This described the core
functionalities of the system. They included the following:
i. To allow the driver locate nearby mechanics
ii. To allow drivers find the distance between them and the mechanics
iii. To allow the driver find path to mechanics site
iv. To enable the driver rate mechanic

5.3 Non-Functional Requirements

i. Ease of use - The application is easy to use for all type of users.

ii. Understandability- The system is easy to understand by new users from the
very user-friendly interfaces. iii. Availability. The system will work 24 hours
a day making it convenient for security user to access it at any time.
iii. Security - The system enhances data authentication by use of passwords to
protect it from unauthorized users.
iv. Confidentiality - The system ensures confidentiality of users’ information.
v. Reliability - The system ensures minimum meantime to failure, low
probability of unavailability and rate of failure occurrence.

33
 5.4 UML Diagrams
5.4.1 Deployment Diagram

Figure 2:Deployment diagram

34
 5.4.2 Sequence Diagram
Driver and the system

Figure 3:sequence diagram

35
Mechanic and the system

36
 5.4.3 Activity Diagram
Driver and the System
Activity Diagram-Driver 2019/09/02

Invalid

37
Mechanic and System

View Driver

38
5.4.4 Use Diagram

39
CHAPTER 6: SYSTEM IMPLEMENTATION AND TESTING
6.1 Introduction
In this chapter, testing, implementation and deployment activities for the system are
highlighted. System design involves the determination of how to build the system
and its overall architecture to serve as a technical system blueprint. Deployment then
refers to activities that make the hardware and software available for use. Software
Testing on the other hand is a strategy that integrates test case design methods into a
well-planned series of steps that result in the successful construction of software.

6.2 Test Plan

This is a process which involved a series of different kinds of tests performed on the
system and its components.

6.2.1 Unit testing

Involved testing minimal software components and subcomponents or modules such
as the registration, selling products, searching products, purchasing products among
other modules. Each module was tested individually to verify that they function
correctly as per the content. For instance, a module like for locating the mechanic
was tested to see whether it carried out the full process correctly.

Test Test Area Expected Results Expected Results

Unit Testing Every module having The modules worked

Testing individual the capability of appropriately and were able
modules of the running independently to give the correct output
system and give the expected
output

Table 3:Unit testing table

40
 6.2.2 Integration testing
In this stage, different modules of the system were combined together and tested as a
whole. In this process, it verified that the individual components integrated were able
to work together and interact well without any conflicts. It was tested that the
integrated modules were able to meet the stated user needs.

Test Test Area Expected Results Actual Results

Integration Test Modules Different modules in the The modules were able to
Relationships system working together work together and produce
in the expected way the expected results

Table 4: integration testing table

6.2.3 Acceptance testing

In this stage of testing, activities involved taking the final system to the real users of
the system to test the system for themselves. After the testing it was found that the
system had good usability and could be easily understood even by people with little
computing knowledge.

Test Test Area Expected Results Actual Results

Acceptance System’s Mechanics and Drivers Mechanics and Drivers with

Testing acceptability being able to navigate the lowest level of
and usability through the site with education were able to use
minimal effort. the system with no
assistance.

Table 5 :Acceptance testing table

41
 6.3 Test Cases
A test case is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly. This is a
process which involved a series of different kinds of tests performed on the system
and its components. The process of developing test cases can also help find problems
in the requirements or design of an application.

6.3.1 Registration and Login Test Case

This verifies that the user’s login form is working correctly. For it to work, one must
have a valid email and password which is acquired during registration.

Figure 4:registration and login test case

i. Test procedure - Enter the email and password then click the login button.

ii. Test data - email, password.

iii. iii. Expected results - The user logs in on entering correct email and
password.
iv. Actual results - If the user details are correct, the user logs in, otherwise he/she is
denied access to the system during login.

42
 6.3.2 Manage User Accounts Test Case
Verifies that the system allows users to manage their own accounts.

Figure 5:Manage User Accounts Test Case

i. Test procedure - Click on the Accounts Setting button presented on the user
interface to perform the action shown.

ii. Test data - Account details and buttons functionality in response to

performing CRUD operations.
iii. Expected results - User able to view and edit their accounts.
iv. Actual results - Successful reading and updates of user accounts.

43
 6.3.3 Locating Nearest Mechanics Test Case
Once the driver is logged in successfully, he or show is able to locate the nearest mechanic

Figure 6:Manage User Accounts Test Case

44
The driver can call the nearest mechanic and request for the service

45
 6.3.4 Mechanic’s Receive Driver Request Test Case
Once the driver finds the nearest mechanic, he/she can request for the service. The
assigned mechanic can view the location to the driver assigned and his/her contact information.

Figure 7:Driver Request Test Case

46
6.4 Implementation
Front End implementation - It was implemented using Java and XML for the android
part. Back End implementation - The Back-End database was developed using
Firebase Database.

Implementation Strategy-I used the phased changeover strategy which took place in
stages, where implementation of a part of the system was done and ensured that it is
probably working before going to the next. The tools which were used for
development included android studio for developing the android application,
Firebase, visual paradigm for designing the UML diagrams.

In this stage, the agile model proved its importance due to its ability of allowing
addition of new requirements as they were recognized at every stage of development.
The model also helped reduce inherent project risks by breaking a project into smaller
segments and providing more ease-of-change during the development process. I
involved the users as well as my supervisor throughout the process which helped
increase the likelihood of user acceptance of the final implementation product.

6.5 Deployment
Below are the overall operations that were performed during the deployment of the
system.

1. Release - During the course of development, the system prototypes were and
shall continue to be released for user testing and reviews. The database was
hosted on the on-firebase server where the system had access.
2. Installation - Involves both hardware and software installation for the use. I
acquired and installed the required hardware for instance mobile phone and
configured the new system on them.

3. User Training and Orientation - This involved introducing the users willing to
use or learn more about the system, training them on how to get the android
application and use it comfortably.
4. Security - For security purposes, the following were implemented:
a. Password and Email Security
- Used passwords and email for authentication.
47
 5. Installed System - After the finalized Installation of the System, it was checked
to ensure that the new installed system was in the appropriate working server
and environment.
6. Maintenance - I was involved in the monitoring and reviewing of the new
system’s performance and problems. The results of the new system were
compared with existing system to assess performance difference.
7. Evaluation - Upon comparison of the performance and reliability of both
existing and new system, an analysis was conducted to evaluate their
differences and similarities and the service delivery efficiency.
Post Implementation Review Summary - Finally, I wrote a report which identified any
techniques and practices used during the development of the project that worked extremely
well, and which would benefit current and future projects

48
7.0 CHAPTER 7: CONCLUSION AND RECOMMENDATION
7.1 Discussion
In this project a system to link Drivers with the Mechanics has been developed. The
system can handle as may users as possible. For mechanics, they can upload their
service information as one of the objectives and the system is able to capture the
location based on the address of their locations. Drivers can view the location of the
mechanics on the google map and get the get the nearest mechanic and after getting
satisfied they can directly contact the mechanic whereby they pay some small fee. In
either of the cases the mechanic can view the pickup locations for the driver.

7.2 Limitations
i. Challenge on obtaining information - During fact finding, not everyone was
willing to disclose some crucial information and even some were not
confident enough while giving their responses.
ii. High memory requirement for machine while running android studio
development environment.
iii. Only Android devices are supported - The mobile application is only capable
of running on Android devices and not capable of running on IOS or Windows
devices.

7.3 Recommendation
The future requirements for this system are as follows:

i. Incorporate MPESA Payment module.

ii. Having a chat platform for the driver and mechanic where drivers can
interact with mechanic on one to one basis.
7.4 Conclusion
Emechanic System was expected to help drivers locate the nearest mechanic in the case of
car breakdown. It was also expected to allow the mechanic view the driver’s location and
the path to the driver’s car breakdown site. Emechanic system displays mechanic’s location
from the driver’s location via Google Map. It also Enables the drivers to search mechanics
basing on the distance This system was also developed and that it displays the directions

49
between driver and the mechanic via Google Map. Finally, emechanic achieved the
objective of enabling the driver rate the mechanic

50
8.0 REFERENCES
1. Repair, J. (2019). Welcome to J & F Auto Repair. [online] J & F Auto Repair. Available
at: https://jandfauto.com/.
2. openbay.com. (2019). Openbay | Find high-quality automotive service near you. [online]
Available at: https://Openbay.com/.
3. CodeCanyon. (2019). Book Your Mobile Auto Mechanics or Technicians - Auto Connect
App. [online] Available at: https://codecanyon.net/item/mobile-mechanic-app/.
4. Play.google.com. (2019). [online]Available
5. Google’s Consumer Barometer, smartphone uptake in Kenya. (2019). Kenya’s Latest 2016
Mobile & Internet Statistics - Moses Kemibaro - Medium. [online] Available at:
https://medium.com/@moseskemibaro/kenyas-latest-2016-mobile-internet-
statistics103d4e26db9c.
6. at: https://play.google.com/store/apps/details?id=com.engie&hl=en
7. Kemibaro, M., Kemibaro, M., Kemibaro, M., Kemibaro, M., Kemibaro, M., Kemibaro, M.,
Kemibaro, M., Kemibaro, M., Kemibaro, M. and Kemibaro, M. (2019). Kenya's Latest
2016 Mobile & Internet Statistics | Moses Kemibaro. [online] Moses Kemibaro. Available
at: http://moseskemibaro.com/2016/10/01/kenyas-latest-2016-mobile-internet-statistics/.

8. Attri, N. (2016). Estimating the Cost of Traffic Congestion in Nairobi ( Langata ) To the
Kenyan Economy.
9. Daniel, O. C. (2016). Exploring the major causes of road traffic accidents in Nairobi
county.
10. Sarah Onyango, O., & of Nairobi, U. (2014). The role of road transport infrastructure in
enhancing regional integration: the case study of Kenya’s road network.
11. Summary, O. S. (2007). Annex 3.1: 1.1 Kenyan transport sector details. 1–12.
12. Караштин, А. Н., Шлюгаев, Ю. В., & Гуревич, А. В. (2005). КОРОТКОВОЛНОВОЕ
РАДИОИЗЛУЧЕНИЕ МОЛНИИNo Title. Известия Высших Учебных Заведений.
Радиофизика, 48(9), 800–809.

51
8.1 APPENDICES
8.1.1 Resources
To realize the performance of the system, several resources and tools are required. The following
is a list of the required resources. They include;

8.1.1.1 Hardware resources

Resource Size Price Ksh
Computer Laptop 40000
Hard Disk 500GB 7000
External hard disk (backup) 150 GB 1000
Memory 4GB(RAM) 2500

Table 6:Hardware Resources

8.1.1.2 Software resources

Resource Size Price

Operating System Windows 10/Ubuntu 3000
DMBS MYSQL/Firebase 4500
IDE Android Studio 2000
Server 4500

Table 7:Software Resources

52
8.1.2 Gantt chart

DURATION IN
WEEKS
TASK NAME 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PROJECT
IDENTIFICATION

PROPOSAL
WRITING

PROPOSAL
PRESENTATION

DATA
COLLECTION

DATA ANALYSIS

PROJECT DESIGN

IMPLEMENTATION

PROJECT TESTING

DOCUMENTATION

PROJECT
PRESENTATION

Table 8:Gantt chart

53
 8.1.3 Budget
The following is the budget schedule for the proposed system:
UNIT PRICE PER COST (KSH)
ITEM UNIT(KSH)
Laptop 1 40000 40000

External hard disk 1000 1000

MSQL server 1 2000 2000

Proposal printing 3 200 600

Internet for Research 8 1000 8000

Transport 1 1000 1000

Documentation 3 500 1500

printing

Total cost 54100

Table 9:Budget

54
QUESTIONS RESPONSES RESPONDENTS

2. Have you ever encountered Yes Yes = 5

mechanical car breakdown?
No No = 1

2. How do you get assistance? Stop an Incoming Car 4

Online 0

Asked a friend 2

0-3 hours 3
3 How long did it take to get help from 3-5 hours 1
the mechanic?
More than 5 hours 2

4. How far did you did you get help from 0-3 Kilometres 2
the car breakdown site? 3-5 Kilometres 3

5-20 Kilometres 1

More than 20 Km 1

5. Are you aware of any app/tool that can Yes 0

connect you to the mechanic? No 6

6.If an app that displays the nearest Yes Yes = 5

mechanic and distance between you and No No = 1
the mechanic was provided would such
an app be useful? And would you support
and use it?

7 Would recommend such an app/tool to Strongly recommend 3

someone? Recommend 2

55
Least recommend 1

Not at all 0

56
Mechanic

QUESTIONS RESPONSES RESPONDENTS

2. Have you ever been to a car Yes Yes = 5

breakdown site in the
emergency notification from No No = 1
the driver?
2 When did you last visited the 0-3 Months 4
site of car breakdown for the
service? 4-12 Months 0

More than a year 2

Through a friend 2
3. How did you get notified that Phone Call 3
there is a driver that needs his/car
repaired Through a driver 1

4 Do most of the drivers Yes 4

prefer/get specific mechanic
No 2

5. Do you normally get Yes 6

customers/drivers coming to your
garage for the services in the case No 0
of car breakdown?
6. Do you get notified about the Yes Yes = 5
drivers whose vehicles have
encountered breakdown on the No No = 1
remote areas?
7 Is the procedure of getting the Yes 0
remotely locating the driver
efficient, reliable and accurate? No 6

57
12 Are you aware of any app/tool Yes 0
that can help in connecting
drivers and mechanics? No 6

13 If you had an app that Yes 5

remotely locate the driver and
displays the distance was No 1
provided would you use such
an app?

14 Do you think an app provided Yes 5

would help?
No 1

15 Would you recommend such Strongly 4

an app to your friend? recommend 2
Recommend 0
Not at all

58
59
60