Unity University

College of Engineering, Technology and Computational Science

Department of Computer Science and MIS

Insurance Management System

Final project document

Submitted to the department of Computer Science and MIS in partial

fulfillment of the requirements for the degree of Bachelor Science in Computer
Science

By
Name ID No.
1. Biruk Fisseha UU71554R
2. Abenezer Mesfin UU70276R
3. Amanuel Girma UU70282R
4. Eyob Awoke UU71819R
5. Melaku Abebe UU65225R
6. Haileeyesus Elias UU71530R

Advisor: Fikru Amanuel

September 1 2021
 Insurance Management System
Final project document

Submitted to the department of Computer Science and MIS in partial fulfillment

of the requirements for the degree of Bachelor Science in Computer Science

By
Name ID No.
1. Biruk Fisseha UU71554R
2. Abenezer Mesfin UU70276R
3. Amanuel Girma UU70282R
4. Eyob Awoke UU71819R
5. Melaku Abebe UU65225R
6. Haileeyesus Elias UU71530R

Advisor: Fikru Amanuel _________________

Examiner: _________________
Abstract

Our system is web and app-based Insurant management system, that will help to facilitate the overall service
that is given by insurance companies. This digital insurance management system can be used for both the
insurance companies and clients. Our system enables clients to register and manage their profile either from
their pc or mobile phone.
Insurance management system project is implemented in html php css and python platform using flutter as backend
application. Main aim of this project is to develop an online application for insurance company to atomize work
procedure, using this system both the insurance company and clients will get a smooth environment for their needs
and services.

In existing system manual procedure is followed where records are used to maintain data which is a time taking
process and require more man power and calculating commissions dues etc. are done manually.

In present system there is no need of a full-time human interference, humans are needed partially. Total work is done
using management system except first time registration which will save time and less paper work and even human
resource.
Acknowledgement
First and for most, we would like to express my special and heartfelt gratitude to God for allowing us to be a part of
this graduating class and be able to present our work. We would like to express our deep gratitude for our advisors, Fikru
Amanuel, for their unreserved support on the development of this project. We would like to also acknowledge our families
for their continuous support that enabled us to work diligently and without fail. We would like to acknowledge our school
mates and friends who helped us in their own ways.
List of Tables
Table 1.7: schedule ---------------------------------------------------------------------------------------8

Table 2.2: Work Breakdown Dictionary -------------------------------------------------------------11

Table 2.2.1: Work Breakdown Team Management -------------------------------------------------15

Table 2.2.2: work breakdown structure (WBS)-----------------------------------------------------16

Table 2.3.1: Human Resource Planning --------------------------------------------------------------17-18

Table 2.3.2: Material planning Equipment and S.W Financial Plan ---------------------------19
Table 2.3.3: Software Requirements -------------------------- ----------------------------------------19
Table 2.3.4: Services -----------------------------------------------------------------------------------20

Table 2.4.1: Human Resource Financial Plan-----------------------------------------------------------20

Table 2.4.2: Material Equipment and S.W Financial Plan ----------------------------------------28

Table 2.4.3: Total Project Budget -----------------------------------------------------------------------28
Table 2.7.1: risk items table ------------------------------------------------------------------------------39

Table 3.5.1.2: use case documentation ---------------------------------------------------------------49

List of figures

Figure 3.4.1.1: Use Case Diagram for the New System ------------------------------------------------------ 42

Figure 3.4.2.1: essential UI prototype ----------------- --------------------------------------------------------- 50

Figure 3.4.2.1: Front page------------------------------------------------------------------------------------------- 50

Figure 3.4.2.2: Login page ------------------------------------------------------------------------------------------- 50

Figure 3.4.2.3: Website UI prototype----------------------------------------------------------------------------- 52

Figure 3.4.2.4: Website client page ------------------------------------------------------------------------------- 52

Figure 3.4.2.5: Website Login page ------------------------------------------------------------------------------- 53

Figure 3.4.2.6: Client home page ---------------------------------------------------------------------------------- 54

Figure 3.4.3: User interface flow diagram ----------------------------------------------------------------------- 55

Figure 3.5.1.1: Use case diagram -----------------------------------------------------------------------------------58

Figure 3.5.2: sequence Diagram ----------------------------------------------------------------------------------- 66-76

Figure 3.5.3: Activity Diagram -------------------------------------------------------------------------------------- 77-95

Contents
Insurance Management System ..................................................................................................................................................... 1
Insurance Management System ..................................................................................................................................................... 2
Chapter 1 - Introduction.............................................................................................................................................................. 1
1.1 Background Information ....................................................................................................................................................... 1
1.2 Statement of the Problem .................................................................................................................................................... 2
1.3 Objectives ............................................................................................................................................................................. 2
1.4 Scope of the Project .............................................................................................................................................................. 2
1.5 Tools and Methodologies ..................................................................................................................................................... 3
1.6 Beneficiaries .......................................................................................................................................................................... 7
1.7 Schedule ................................................................................................................................................................................ 8
Chapter 2 - Project Management................................................................................................................................................ 9
2.1 Introduction .......................................................................................................................................................................... 9
2.2.1: work breakdown structure (WBS) ................................................................................................................................. 16
2.3 Resource Planning............................................................................................................................................................... 17
2.4 Financial Planning ............................................................................................................................................................... 20
2.5 Team Organization .............................................................................................................................................................. 21
2.6 Process Model ..................................................................................................................................................................... 22
2.7 Risk MMM Plan ................................................................................................................................................................... 23
Chapter 3 - System Analysis ...................................................................................................................................................... 30
3.1 Introduction ........................................................................................................................................................................ 30
3.2 Current System Overview ................................................................................................................................................... 35
3.3 Proposed System Overview ................................................................................................................................................ 38
3.3.1 Functional requirements.............................................................................................................................................. 38
3.3.2 Non-functional requirements ...................................................................................................................................... 40
3.4 System Models Requirement Determination ..................................................................................................................... 41
3.4.1 Essential Use Case Modeling ....................................................................................................................................... 42
3.4.2 Essential UI Prototype .................................................................................................................................................. 49
3.4.3 User Interface Flow Diagram ....................................................................................................................................... 54
3.4.4 Supplementary Specifications...................................................................................................................................... 54
Chapter 4 - System Design ............................................................................................................................................................ 92
4.1 Introduction ........................................................................................................................................................................ 92
 4.2 Design Goals........................................................................................................................................................................ 93
4.3 Design Trade offs ................................................................................................................................................................ 93
4.4 Subsystem Decomposition.................................................................................................................................................. 94
4.5 Design Phase Models .......................................................................................................................................................... 95
4.5.1 Class Modeling ............................................................................................................................................................. 95
4.5.2 Persistent Model .......................................................................................................................................................... 96
4.5.3 User Interface Design................................................................................................................................................... 98
4.5.4 Deployment Diagram ................................................................................................................................................. 107
4.5.5 Network Design .......................................................................................................................................................... 108
Chapter 5: Implementation and Testing ..................................................................................................................................... 109
5.1 Introduction ....................................................................................................................................................................... 109
5.2 Sample Code...................................................................................................................................................................... 109
Web Application...................................................................................................................................................................... 109
Chapter 6 Conclusion and Recommendation ......................................................................................................................... 112
6.1 Conclusion ......................................................................................................................................................................... 112
6.2 Recommendation.............................................................................................................................................................. 112
Reference……………………………………………………………………………………………………………………………………………………………………….114

List of abbreviation…………………………………………………………………………………………………………………………………………………………115
Chapter 1 - Introduction
1.1 Background Information
The theory of insuring an item that is possessed has always been engraved in society. Since before roman
time “law recognized the insurance contract in which an article of agreement was drawn up and funds were
deposited with a money changer…” This practice then stemmed throughout time and diversified its reach to
encompass a multitude of sectors. From Ancient Rome to England, the United States and many more the
forming of contractual agreement to insure goods, products and property is still practiced to this day.

The goal of insurance management is the objective of insurance is to financially guard against
unpredictable life occurrences. In short, when you buy an insurance policy, you make monthly payments, called
premiums, to purchase protection from monetary repercussions related to things like accidents, illness or even
death.” The business aspect of insurance management takes into consideration the loss from insuring and works
on building assets in other companies.

This tactic will develop the company’s portfolio and stature.

The history of insurance management in Ethiopia stems from the first insurance company in Ethiopia
called The Imperial Insurance Company (1). ‘’The emergence of insurance business in Ethiopia was closely
linked to expatriates and foreign insurance companies Those foreign insurance companies were operating in
the country thought their agents. In addition, expatriates and foreign companies operating in Ethiopia
Participated actively in establishment of the first domestic insurance company.” (1)

The insurance management industry has changed over time and in this day of technological advancement,
the changes that have been introduced the beginning has since are night and day. With the same business model
in mind, insurance companies generate revenue in two ways: Charging premiums in exchange for insurance
coverage, then reinvesting those premiums into other interest-generating assets”, and with the development of
technology, considering moor’s law which “is the observation that the number of transistors in a dense
integrated circuit (IC) doubles about every two years. Moore's law is an observation and projection of a
historical trend. Rather than a law of physics, it is an empirical relationship linked to gains from experience in
production”, the ability to connect and commercialize connectivity has only become more efficient and diverse.
Due to this development, the business of management, specifically insurance management has become a
thriving business. (2)

The efficiencies due to technological development and availability introduced a new wave of possibilities
that can be exploited for the benefit of any company that decides to embrace the new path towards profit. In
the Ethiopian market, there are improvements that can be made available in accordance to the law and norms

1|Page
of the businesses at work in Ethiopia at this moment. To this end the goal of this proposal is to develop the
infrastructure of the business activities from the perspective of the consumer and the clerk for the best and
most efficient use of the advantages acquired from the technological advancement of the day.

1.2 Statement of the Problem

The current state of technological development has brought about vast increases in connectivity due to
networking and communication. In the insurance management business, the methodology of the
documentation in the insurance management system has always been a hands-on approach with first gathering
the information necessary from the customer, documenting the items received, and payment received in cash
from the customer, after the receipt is issued, the customer receives the documentation to show proof of
insurance purchase and finishes the transaction.

This system was designed with the intent of presenting a welcoming figure to show that the organization
can be trusted. That the possessions of the customer are being insured by a trust worthy body; so, to speak.
The problem lies with the inefficient use of the technology available today. Our team will use this to our
advantage to develop and deploy a system that will be presentable, reliable and efficient.

1.3 Objectives
1.3.1 General Objective
General objective of the project is to design and implement Digital Insurance management system
1.3.2 Specific Objectives
Developing a graphical user interface for the use of clerks in their work
• For connecting to a server that will manage the registered users in terms of new
registrations, already registered users and canceling of registration.
• For managing the subscriptions of the users in regards to status, premium values, and
renewals h. For managing pre-registrations for inspection

1.4 Scope of the Project

The scope of our project is parameterized in two aspects. The first being the clerk, or the manager of the
insurance management system and their interaction with the system. The responsibilities of the clerk is to
receive and validate the information of pre-registered clients, register new clients, renew client purchases,
verify purchase documents, check available insurance policies, check available quotes on available insurances,
and cancel registration of clients in the instance that the client chooses. The responsibilities of the manager
include, all of the previously aforementioned, and admin privileges that allow for client information review,
review the work of the clerk, accommodate changes to the client’s information with at the client’s request. The
client will be able to register, delete, check status of insurance, check quotes on specific insurance policies,
change account information, check available insurance policies and find information about and apply for

2|Page
 insurances available at the company. To accommodate these, we will be developing a graphical user interface
as a front end with Java and Firebase as a primary database and SQL as a backup database in the back end for
the management body of the company. The client will be able to use a website and mobile application
developed for Android and IOS for their convenience. The team will not be developing a method of payment
for the clients purchases. The available payment methods, which are through direct deposit at a bank or direct
payment at the clerk’s desk of the company.

1.5 Tools and Methodologies

1.5.1 Data Collection Methodologies
Due to the specific nature of our project, the team decided on these data collection methodologies to
employ for the means of gathering information relevant to our task. These methods we will acquire will allow
us to better understand the process and procedure taken from the people working in insurance companies. We
will understand their methods, working structure, habits and tendencies. These methods will give the team
information in regards to their thought process, the business practices and accurate insight in to the
improvements we are able to deploy to counter any inefficiencies we can observe.

1. Interviews: will allow us to gauge the day-to-day processes that take place with the regards to the
working environment of an insurance company.
2. Observations: will allow us to understand the flow of information from the customer to the clerk
and the direct correspondence.

From these we can deduce the information that is required from the customer, understand the requirement
of the clerk in the management of his duties, study the market of insurance in regards to focusing our attention
to the vital
aspects of said company.

1.5.2 System Development Methodology

Object Oriented System Analysis and Design

Object-oriented (O-O) analysis and design is an approach that is intended to facilitate the development of systems that must
change rapidly in response to dynamic business environments what object-oriented systems analysis and design is, how it
differs from the structured approach of the SDLC, and when it may be appropriate to use an object-oriented approach.

3|Page
Object-oriented techniques are thought to work well in situations in which complicated information systems are undergoing
continuous maintenance, adaptation, and redesign. Object-oriented approaches use the industry standard for modeling object-
oriented systems, called the unified modeling language (UML), to break down a system into a use case model.

Object-oriented programming differs from traditional procedural programming by examining objects that are part of a
system. Each object is a computer representation of some actual thing or event. Objects may be customers, items, orders, and
so on. Objects are represented by and grouped into classes that are optimal for reuse and maintainability. A class defines the
set of shared attributes and behaviors found in each object in the class.

The phases in UML are similar to those in the SDLC. Since those two methods share rigid and exacting modeling, they
happen in a slower, more deliberate pace than the phases of agile modeling. The analyst goes through problem and
identification phases, an analysis phase, and a design phase as shown in the figure below. Although much of the specifics are
discussed in Chapters 2 and 10, the following steps give a brief description of the UML process.

1. Define the use case model.

In this phase the analyst identifies the actors and the major events initiated by the actors. Often the analyst will
start by drawing a diagram with stick figures representing the actors and arrows showing how the actors relate.
This is called a use case diagram and it represents the standard flow of events in the system. Then an analyst
typically writes up a use case scenario, which describes in words the steps that are normally performed.
2. During the systems analysis phase, begin drawing UML diagrams.
In the second phase, the analyst will draw Activity Diagrams, which illustrate all the major activities in the use
case. In addition, the analyst will create one or more sequence diagrams for each use case, which show the
sequence of activities and their timing. This is an opportunity to go back and review the use cases, rethink them,
and modify them if necessary.
3. Continuing in the analysis phase, develop class diagrams.
The nouns in the use cases are objects that can potentially be grouped into classes. For example, every
automobile is an object that shares characteristics with other automobiles. Together they make up a class.
4. Still in the analysis phase, draw state chart diagrams.
The class diagrams are used to draw state chart diagrams, which help in understanding complex processes that
cannot be fully derived by the sequence diagrams. The state chart diagrams are extremely useful in modifying
class diagrams, so the iterative process of UML modeling continues.

4|Page
5. Begin systems design by modifying the UML diagrams. Then complete the specifications.
Systems design means modifying the existing system and that implies modifying the diagrams drawn in the
previous phase.
These diagrams can be used to derive classes, their attributes, and methods (methods are simply operations).
The analyst will need to write class specifications for each class including the attributes, methods, and their
descriptions. They will also develop methods specifications that detail the input and output requirements for the
method, along with a detailed description of the internal processing of the method.
6. Develop and document the system.
UML is, of course, a modeling language. An analyst may create wonderful models, but if the system isn’t
developed there is not much point in building models. Documentation is critical. The more complete the
information you provide the development team through documentation and UML diagrams, the faster the
development and the more solid the final production system.

1.5.3 Development Tools

WordPress (reference time only) , Html , Php

WordPress (WP, WordPress.org) is a free and open-source content management system (CMS) written in PHP
and paired with a MySQL or MariaDB database. Features include a plugin architecture and a template system,
referred to within WordPress as Themes. WordPress was originally created as a blog-publishing system but has
evolved to support other web content types including more traditional mailing lists and forums, media galleries,
membership sites, learning management systems (LMS) and online stores. WordPress is used by more than
40.5% of the top 10 million websites as of March 2021, WordPress is one of the most popular content
management system solutions in use. WordPress has also been used for other application domains, such as
pervasive display systems (PDS). As it is a common thing in the world most of websites in the world uses html
and php at least once.

Dart - Dart is a client-optimized programming language for apps on multiple platforms.

It is developed by Google and is used to build mobile, desktop, serve, and we applications. Dart is a n
object-oriented, class-based, garbage collected language with C-style syntax. Dart can compile to either native code
or JavaScript. It supports interfaces, abstract classes, reified generics and type interference.
Dart is the programming language used to code Flutter apps. Dart is another product by Google and released
version 2.1, before Flutter, in November. Dart is not only used for mobile app development but is a programming
language. Approved as a standard by ECMA (ECMA-408), it’s used to build just about anything on the web,

5|Page
servers, desktop and of course, mobile applications. Dart, when used in web applications, is transpired to
JavaScript so it runs on all web browsers. The Dart installation comes with a VM as well to run the .dart files
from a command-line interface. The Dart files used in Flutter apps are compiled and packaged into a binary file
(.apk or .ipa) and uploaded to app stores.

Flutter - Flutter is an open-source UI software development kit created by Google.

It is used to develop applications for Android, iOS, Linux, Mac Windows, Google fuchsia, and the web from
a single codebase. The first version of
Flutter was knowing as codename “Sky”, and ran on the Android operating System. It was unveiled at the 2015
Dart developer summit, with he stated intent of being able to render consistently at 120 frames per second.
During the keynote of Google developer Days in Shanghai, Google announced Flutter Release preview 2, which
is the last big release from Flutter 1.0. on December 4, 2018, Flutter 1.0 was released at the Flutter Live event,
denoting the first “stable” version of the Framework.

Firebase - Firebase is a platform developed by Google for creating mobile and web applications.
It was originally an independent company founded in 2011. In 2014, Google acquired the platform and
it is now their flagship offering for app development. The Firebase platform has 18 products split into three
groups: Develop, Quality, and Grow. Firebase Realtime Database
The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in
real time to every connected client. When you build cross-platform apps with our iOS, Android, and JavaScript
SDKs, all of your clients share one Realtime Database instance and automatically receive updates with the
newest data.
• Realtime: Instead of typical HTTP requests, the Firebase Realtime Database uses data
synchronization— every time data changes, any connected device receives that update within
milliseconds. Provide collaborative and immersive experiences without thinking about
networking code.
• Offline: Firebase apps remain responsive even when offline because the Firebase Realtime
Database SDK persists your data to disk. Once connectivity is reestablished, the client device
receives any changes it missed, synchronizing it with the current server state.

6|Page
 • Accessible from client devices: The Firebase Realtime Database can be accessed directly from
a mobile device or web browser; there’s no need for an application server. Security and data
validation are available through the Firebase Realtime Database Security Rules, expression-
based rules that are executed when data is read or written.
• Scale across multiple databases: With Firebase Realtime Database on the Blaze pricing plan,
you can support your app's data needs at scale by splitting your data across multiple database
instances in the same Firebase project. Streamline authentication with Firebase Authentication
on your project and authenticate users across your database instances. Control access to the data
in each database with custom Firebase Realtime Database Rules for each database instance.

SQL SERVER
SQL server is a client/server relational database management system (RDBMS) that uses transact-SQL
to send request between a client and SQL server. SQL server can work with thousands of client application
simultaneously. The server has features to prevent the logical problems that occur if a user tries to read or
modify data currently being used by others. While SQL server is designed to work as a server in a client/server
network. It is also capable of working as a standalone database directly on the client. The scalability and ease
of-use features of SQL server allows it to work efficiently on a client without consuming numerous resources.
SQl server efficiently allocated the available resources, such as memory, network bandwidth and disk I/O,
among the multiple users.
Visio
Microsoft Visio (formerly Microsoft Office Visio) is a diagramming and vector graphics application and
is part of the Microsoft Office family. The product was first introduced in 1992, made by the Shapeware
Corporation. It was acquired by Microsoft in 2000.

1.6 Beneficiaries
The beneficiaries of this project include but not limited to insurance companies, managers, clerks, and
customers of the insurance industry. Companies that is willing and able to expand into this technological
advancement are able to with a few modifications to their work structure.

7|Page
1.7 Schedule
Schedule

8|Page
Chapter 2 - Project Management
2.1 Introduction

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope
and resources. And a project is unique in that it is not a routine operation, but a specific set of operations
designed to accomplish a singular goal. So a project team often includes people who don’t usually work
together – sometimes from different organizations and across multiple geographies. The development of
software for an improved business process, the construction of a building or bridge, the relief effort after a
natural disaster, the expansion of sales into a new geographic market — all are projects. And all must be
expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.
Project management, then, is the application of knowledge, skills, tools, and techniques to project activities
to meet the project requirements. Project management processes fall into five groups initiating, planning,
executing, monitoring, controlling, and closing. Project management knowledge draws on ten areas
integration, scope, time, cost, quality, procurement, human resources, communications, risk management,
stakeholder management. Project management is the process of leading the work of a team to achieve goals
and meet success criteria at a specified time. The primary challenge of project management is to achieve all
of the project goals within the given constraints. This information is usually described in project
documentation, created at the beginning of the development process. The primary constraints are scope,
time, budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to
meet pre-defined objectives.
The objective of project management is to produce a complete project which complies with the client's
objectives. In many cases the objective of project management is also to shape or reform the client's brief to
feasibly address the client's objectives. Once the client's objectives are clearly established, they should
influence all decisions made by other people involved in the project – for example project managers,
designers, contractors and subcontractors. Ill-defined or too tightly prescribed project management
objectives are detrimental to decision making.
A project is a temporary endeavor designed to produce a unique product, service, or result with a defined
beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to
meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary

9|Page
nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent,
or semipermanent functional activities to produce products or services. In practice, the management of such
distinct production approaches requires the development of distinct technical skills and management
strategies. All management is concerned with these, of course. But project management brings a unique
focus shaped by the goals, resources and schedule of each project. The value of that focus is proved by the
rapid, worldwide growth of project management.

2.2 Project Planning

WBS
Work Breakdown Outline

• 1.0 Insurance Management System

• 1.1 Client
• 1.1.1 Website
• 1.1.1.1 Account
• 1.1.1.1.1 new registration
• 1.1.1.1.2 change account information
• 1.1.1.1.3 delete account
• 1.1.1.1.4 view account information
• 1.1.1.2 Insurance
• 1.1.1.2.1 apply for insurance
• 1.1.1.2.2 check on available insurance policies
• 1.1.1.2.3 check quotes on specific insurances
• 1.1.1.2.4 check status of insurance
• 1.1.2 Application
• 1.1.2.1 Account
• 1.1.2.1.1 new registration
• 1.1.2.1.2 change account information
• 1.1.2.2 Insurance

10 | P a g e
 • 1.1.2.2.1 check on available insurance policies
• 1.1.2.2.2 check quotes on specific insurances
• 1.1.2.2.3 check status of insurance
• 1.2 Clerk/Manager
• 1.2.1 GUI

• 1.2.1.1 Client’s Information

• 1.2.1.1.1 Registration client information
• 1.2.1.1.2 Delete client information
• 1.2.1.1.3 Review client information
• 1.2.1.1.4 Change client information
• 1.2.1.2 Insurance
• 1.2.1.2.1 Receive and validate Insurance applications
• 1.2.1.2.2 renew client purchases
• 1.2.1.2.3 verify purchase documents
• 1.2.1.2.4 check available insurance policies
• 1.2.1.2.5 check available quotes on available insurances • 1.2.1.2.6 check
status of insurance

2.2 Work Breakdown Dictionary

Level Code Name Description

1 1.0 Insurance Management System Overall Insurance Management

2 1.1 Client All the Customers of the company

3 1.1.1 Website A website developed for the client’s purposes to

view any and all information about the
insurance company and the client’s information
given to the insurance company

4 1.1.1.1 Account The Information of the client

11 | P a g e
5 1.1.1.1.1 New registration Any new registrations for clients containing their
personal information.

5 1.1.1.1.2 Change account information Enables the changing of information about the
client

5 1.1.1.1.3 Delete account Enables the termination of the account of the

customer

4 1.1.1.2 Insurance The overall information about the insurance

company pertaining to the

5 1.1.1.2.1 Apply for insurance Enables the application of insurances available

for purchase by the client

5 1.1.1.2.2 Check on Available insurance Enables clients to find out about the availability
policies of insurance policies

5 1.1.1.2.3 Check on quotes on specific Enables clients to find out about the premiums of
insurances insurances with the client’s specific information

5 1.1.1.2.4 Check on status of insurance Enables clients to view their insurance purchases
to check for validity, and renewal times as well
as the purchased policy

3 1.1.2 Application An Application developed for the client’s

purposes to view any and all information about

the insurance company and the client’s

information given to the insurance company

4 1.1.2.1 Account The overall information about the client that is

stored on the database of the insurance
company

12 | P a g e
5 1.1.2.1.1 New registration Any new registrations for clients containing
their personal information.

5 1.1.2.1.2 Change account information Enables the changing of information about the
client

4 1.1.2.2 Insurance The overall policies and services of the

insurance company

5 1.1.2.2.1 Check on available insurance Enables clients to find out about the availability
policies of insurance policies

5 1.1.2.2.2 Check quotes on specific Enables clients to find out about the premiums
insurances of insurances with the client’s specific
information

5 1.1.2.2.3 Check on status of insurance Enables clients to view their insurance

purchases to check for validity, and renewal
times as well as the purchased policy

2 1.2 Clerk/Manager Management Body of the Insurance Company

3 1.2.1 GUI Graphical User Interface used by the

management body

4 1.2.1.1 Client’s Information Overall information about the client

5 1.2.1.1.1 Registration of client Registration of the overall information of the

information client

5 1.2.1.1.2 Delete client information Delete the account and information about the
client

5 1.2.1.1.3 Review client information Review the account and information about the
client

13 | P a g e
5 1.2.1.1.4 Change client information Change the account and information about the
client

4 1.2.1.2 Insurance The overall policies and services of the

insurance company

5 1.2.1.2.1 Receive and validate insurance Review and confirm the validity of any
applications information applied to the company by the
client

5 1.2.1.2.2 Renew client Purchases Renew the purchases of the client with any
updates on premiums.

5 1.2.1.2.3 Verify purchase documents Review and confirm the validity of any
purchases made by the client

5 1.2.1.2.4 Check available insurance Enables management body to find out about the
policies availability of insurance policies

5 1.2.1.2.5 Check available quotes on Enables management body to find out about the
insurances premiums of insurances with the client’s
specific information

5 1.2.1.2.6 check status of insurance Enables management body to view their

insurance purchases to check for validity, and
renewal times as well as the purchased policy

14 | P a g e
Weeks Week 1 Week 2 Week 3 Week 4
Months
1st Introduction of Understanding Requirement Study of Project related website and
Month Definition – Project Definition – Gathering– collecting related Da
All Team members All Team members All Team members – All Team member

2nd Analysis of Website, Dart and Website, dart, and Layout designing
Month project SQL SQLcontrols, design - Haileyesus El
requirements – All fundamentals development - Biruk Fisseha
Team members learning – All learning
Team members – All Team members
3rd Data Flow diagram Activity Use-case diagram Class diagram preparation
Month preparation diagram preparation - Eyob Awoke
- Eyob Awoke preparation - - Eyob Awoke - Abenezer
- Abenezer Eyob - Abenezer Mesfin
Mesfin Awoke Mesfin
- Melaku Abebe - Abenezer - Melaku Abebe
- Amanuel Mesfin
Girma - Amanuel Girma

4th Data dictionary object oriented State transition Project GUI preparation
Month preparation diagram preparation diagram -Biruk Fisseha
- Biruk Fisseha - Biruk Fisseha - Biruk Fisseha -Eyob Awoke
- Eyob Awoke - Eyob Awoke - Eyob Awoke -Haileyesus Eli

2.2.1 Work breakdown team management

15 | P a g e
2.2.1: work breakdown structure (WBS)

16 | P a g e
2.3 Resource Planning
Resource planning is the major foundational infrastructure for a efficient and successful project.
The resources used consist of human resources and material resources, each individually important but
bring about a better outcome together.

2.3.1 Human Resource Planning

C Human Resource Planning
Profession Count Qualification Responsibilities

Project Manager 1 • BSc. In Computer Science • Understand WBS and

• Clear understanding of Java, delegate tasks
MySQL, Android Studio,
• Manage and organize
JavaScript, HTML, CSS,
resources
Flutter, Firebase, WordPress
• Manage Finance
• Experience in Management and
• Preparation of Project Plan
Leadership

Application 2 • BSc. In Computer Science • Develop Android and iPhone

Developer • Android Studio, Firebase, Flutter, Application in accordance to
MySQL
the project deliverables
• Identifying coding errors and
fixing them

17 | P a g e
Website 2 • BSc. In Computer Science • Identifying coding errors and
Developer • Proficient in JavaScript, CSS, fixing them
Firebase, WordPress, HTML,
• Develop a website in
MySQL accordance to the project
deliverables

GUI Developer 1 • BSc in Computer Science • Develop a graphical user

• Proficient in Java, MySQL, interface in accordance to the
Firebase project deliverables

• Identifying coding errors and

fixing them

Database 2 • BSc. in Computer Science • Create and manage the

database of the project in
Management • Knowledge in Firebase and
two formats, Firebase and
MySQL databases MySQL.

• Test database inputs and

outputs

System Tester 2 • Knowledge of System Testing • Test and find bugs in the
scope of testing criteria

Requirement 2 • BSc. In Computer Science • Collect the necessary

Analyst • Communication skills information from sources
• Proficient in data collection

Total 7
Professionals

18 | P a g e
2.3.2 Material Planning, Equipment, and Software Financial Plan
Hardware Requirements
Item Quantity Specification | Minimum Requirements Justification

Laptop 7 • Processor Core i5 • Write and Test Code

• Ram 8Gb • Prepare Documentation
• OS Windows 64bit
• 500Gb HDD

Mobile 7 • Android Studio 7.0 • To Deploy and test mobile

Device • IOS 11.0 application

Stationary - • Paper • Collect information

• Laminator • Present information
• Pen

Flash 3 • 32Gb • Share information to relevant

Drive parties

2.3.3: Software Requirements

Software Specification Justification

MS-Word, MS-Visio, MS-2016 and above Use for documenting and

MS-Project presenting the project in detail
for analysis

Browser Google Chrome Data collection, developing

website, testing website

Android Studio Android Studio V:3.5 Development and testing of

Android and iPhone
Application

19 | P a g e
 MySQL or Oracle MySQL 8.0 or Oracle 18c. Database management

Table 2.3.4: Services

Service Amount Specification Justification

Internet Access 7 Minimum speed Used for

500KB/s communication,

information and data

collection, and testing

Transportation - Transportation for the Provides transportation

project team members services for team
to and from members to and from
communal meeting communal meeting
places places

2.4 Financial Planning

Financial planning is the process of determining project costs and developing a budget. Good
financial planning has many benefits, including estimating profit, reducing financial risk, and planning for
unexpected costs.
2.4.1 Human Resource Financial Plan
Role Count Duration needed (Weeks) Salary per Week (Birr) Total Salary (Birr)

Project Manager 1 40 7,500 300,000

Requirement 2 4 4000 16,000
Analyst
Programmer 4 30 5,000 150,000
Database 2 6 3,000 18,000
manager

20 | P a g e
 System tester 2 2 2,500 5,000
TOTAL 7 40 489,000

2.4.2 Material, Equipment and Software Financial Plan

Item Quant. Price (Birr) Non-recurrent Price(Birr) Recurrent Total Price (Birr)
Laptop 7 25,000 - 175,000
USB drive 4 500 - 2,000
Internet Service 7 700 1,510 15,470
Transportation 7 - 600 4,200
Android Studio 2 - - -
MySQL 2 - - -
MS office Online 7 - - -

NetBeans 4 - - -
TOTAL 25 26,200 2,110 196,670

2.4.3 Total Project Budget

Names Expense
Human Resource Financial Plan 489,900

Material, Equipment and Software Financial Plan 196,670

Total 686,570

2.5 Team Organization

In flat organizations, the number of people directly supervised by each manager is large, and the
number of people in the chain of command above each person is small. A manager in a flat organization
possesses more responsibility than a manager in a tall organization because there is a greater number
of individuals immediately below them who are dependent on direction, help, and support. Moreover,
managers in a flat organization rely less on guidance from superiors because the number of superiors
above the manager is limited.
An organization with self-managing teams who organize their own work without the need for a
middle manager or supervisor above the team may meet or closely approximate this model. While a

21 | P a g e
manager in self managing teams determines the overall purpose or goal of the team, the team is at
liberty to manage the methods by which to achieve that goal. This can cause conflict with people whose
career path expectations include a promotion, which may not be available within the organization due
to its flat structure. However, alternative "horizontal" career paths may be available, such as
developing greater expertise in a role or mastery of a craft, and/or receiving pay raises for loyalty.
An absence of middle managers does not preclude the adoption and retention of mandatory work
procedures, including quality assurance procedures. However, due to the fact that significant
responsibilities are given to the team members themselves, if a team collectively arrives at the view
that the procedures it is following are outdated, or could be improved, it may be able to change them.
Such changes may, in some cases, require the approval of executive management and/or customers
(consider, for example, a digital agency producing bespoke websites for corporate clients). If executive
management is not involved in the decision, or merely rubberstamps it, this might be an example of
consensus decision-making or workplace democracy at the level of a team - or group of teams, if
multiple teams are involved in the decision.
This structure is generally possible only in smaller organizations or individual units within larger
organizations. Having reached a critical size, organizations can retain a streamlined structure but
cannot keep a completely flat manager-to-staff relationship without affecting productivity. Certain
financial responsibilities may also require a more conventional structure. A company would not have
to give a raise or promotion, based on service length but on greater productivity. Also eliminating
certain departments from the payroll means saving money. Some companies theorize that flat
organizations become more traditionally hierarchical when they begin to be geared towards
productivity. The flat organization model promotes employee involvement through decentralized
decision-making processes. By elevating the level of responsibility of baseline employees and
eliminating layers of middle management, comments and feedback reach all personnel involved in
decisions more quickly. Expected response to customer feedback becomes more rapid.

2.6 Process Model

The Waterfall model is a sequential model that divides software development into pre-defined
phases. Each phase must be completed before the next phase can begin with no overlap between the

22 | P a g e
phases. Each phase is designed for performing specific activity during the SDLC phase. Our project
will use waterfall process model. We choose this process model because all the work will be done
sequentially providing clear view of work completed while keeping track of dependencies. It also
simplifies control over the project since it requires clear milestone to be defined at the end of each
phase, so progress and success can also be checked comparing the stated milestone with our
deliverables. To explain more directly from our project perspective the reason behind why we choose
waterfall process model is because of our project Requirements. Requirements in our project are not
changing frequently and we decide to do our project by this way “Before the next phase of
development, each phase must be completed”.
Software process models often represent a networked sequence of activities, objects,
transformations, and events that embody strategies for accomplishing software evolution. Such models
can be used to develop more precise and formalized descriptions of software life cycle activities.

2.7 Risk MMM Plan

2.7.1 Risk table
Risk Risk Name Risk Type Possibility Effect
ID

R1 Inaccurate time estimation Schedule Medium Critical

Mitigation Plan • Adjust the schedule when changes are introduced.

• Reschedule the program.

Monitoring Plan • Work overtime to reduce risk.

• Minimize the scope changes introduced to the project.

Contingency Plan • Add additional employees to meet the deadline.

• Negotiate with customers about getting an extension.

R2 Loose control over Schedule Medium Critical

resources.

23 | P a g e
 Mitigation Plan • Strictly follow a schedule and highly minimize resource
loose.

Monitoring Plan • Increase reusability of resource and adjust resource

estimation

Contingency Plan
• Raising new fund for purchasing loose resource
R3 Unexpected project scope Schedule Low Critical
expansion.

Mitigation Plan • Limit the functional and geographic scope of the project.

Monitoring Plan • Identify basic functional requirement and avoid other

functional requirement which are out of scope.

Contingency Plan
• Redefine the scope or adjust if we can
R4 Inaccurate budget Budget Medium Critical
estimation.

Mitigation Plan • Study the current market and adjust the budget when
a new change is appearing.

• Strictly follow the budget plan and reduce extra

expenditure

Monitoring Plan • Restructure the budget plan.

• Minimize expenditure.
Contingency Plan
• Negotiate with customer and adjust the project fund.
R5 Project scope expansion Budget Medium Critical

Mitigation Plan • Control project scope expansion

Monitoring Plan • Adjust the budget plan according to the new scope •
Use open source software.

24 | P a g e
 Contingency Plan • Negotiate with customer and adjust the project fund
R6 Currency fluctuation Budget High Critical

Mitigation Plan • investing in things that do not depreciate

Monitoring Plan
Contingency Plan
• Adjust budget plan and find additional fund from
sponsors.
• increasing assets and minimizing liabilities
• Prepare additional budget
• having annually increasing interest rate

R7 Theft and fraud. Operational High Critical

Mitigation Plan • Know your employees. Be alert to key indicators of

potential theft

Monitoring Plan • By having a good security system.

Contingency Plan
• Having a security system and keeping a good record.
R8 Lack of communications. Operational Medium Medium

Mitigation Plan • Creating an environment where individuals in the group

can communicate well.

Monitoring Plan • Clearly identify and announce the responsibility of each

team member

Contingency Plan • Reorganizing the team to have good communication

• Select new methods of engaging the team with their
leaders in hopes to improve morale and communication.

R9 Failure to address priority Operational High Critical

conflicts.

Mitigation Plan • Giving Priority for issues that require more attention

25 | P a g e
 Monitoring Plan • Update the priority of activities
Contingency Plan
• Allocate resource to address changes that need
priority

R10 Lack of team management. Operational Medium Critical

Mitigation Plan • having a good manager and having a good chain of

command

Monitoring Plan
• Prepare team member meeting schedule and follow it
Contingency Plan
• Replace team leader with mature leadership

R11 Data management. Operational Medium Medium

Mitigation Plan
• creating a good data recovery
Monitoring Plan • recording data management problems
Contingency Plan • Creating a manageable and easily accessible data
storage.
• having a backup.

R12 Continuous changing Technical High Catastrophic

requirement.

Mitigation Plan • Follow the prepared resource plan.

• Communicate with stakeholders on the requirements
they desire first.

• Make minor adjustments without changing the

requirements

26 | P a g e
 Monitoring Plan • Allocate resource to address changes that need priority

Contingency Plan • Update the resource plan and rise additional fund for
resource purchase

R13 Design risk. Technical High Critical

Mitigation Plan • Thoroughly collect requirements

• secure signed approvals on the design.
• Coming up with a friendly and easily useable design.

Monitoring Plan • removing unnecessary part of the design.

• testing and checking whether the designed program
or system is working.

Contingency Plan • return to the skeleton design and develop branches of

improvement from there.

• Decrease output and find the underlying issue.

R14 Data infrastructure failure. Technical High Catastrophic

Mitigation Plan
• keeping system up to date.
Monitoring Plan
• Regularly repairing parts of the system and design.
Contingency Plan • having a backup machine. For example, a backup
server.

R15 Change of law or policy. Programmatic Medium Medium

Mitigation Plan • Adjust to changes in context of severity and increase

strain on identifying policy and law changes that
affect the program.

27 | P a g e
 Monitoring Plan • Study and identify policy and regulations that affect our
project and prepare resolution method

Contingency Plan • Negotiate with government about policies and

regulations that affect our project.

R16 Market crush or loss of Programmatic Medium Critical

economy.

Mitigation Plan • by limiting liabilities and avoiding low return

investments.

• Study the market in every month and update the

budget plan.

Monitoring Plan • holding on to precious assets and acquiring more

precious assets.

Contingency Plan
• experimenting with ways of generating revenue.
R17 Global pandemic Programmatic low Low

Mitigation Plan
• by adapting to the demand of the circumstance.
Monitoring Plan
• Prepare and Save extra budget
Contingency Plan • Ask the customer to invest additionally
• Find sponsors or loan

2.7.2 RMM Plan

Schedule Risk: is the likelihood of failing to meet schedule plans and the effect of that failure.

- Inaccurate time estimation.

- Loose control over resources.
- Unexpected project scope expansion.

Budget Risk: is the potential for the estimates or assumptions built into a budget to turn out to be inaccurate.

28 | P a g e
 - Inaccurate budget estimation.
- Project scope expansion. - Currency fluctuation.

Operational Risk: is the risk of loss from inadequate or failed internal processes.

- Theft and fraud.

- Lack of communications.
- Failure to address priority conflicts.
- Lack of team management. - Data management.

Technical Risk: is the risk associated with the failure of the design or the function of the system.

- Continuous changing requirement.

- Design risk.
- Data Infrastructure failure

Programmatic Risk: is risk associated with action or inaction from outside the control of the program. This are beyond
the limits of the program.

- Change of law or policy.

- Market crush or loss of economy.
- Global pandemic.

29 | P a g e
Chapter 3 - System Analysis
3.1 Introduction

Insurance development always follows the changes takes place in the political, technological,
legal, economic and social aspects of the society. All changes have significant impact on its
development. (3)
World Vision Ethiopia (2014) stipulated the Ethiopian financial sector in the rural area consists
of formal, semi-formal and informal financial service providers. Formal providers include commercial
banks and MFIs while semi-formal providers are saving and credit cooperatives. (3) Informal providers
consist of social groups that provide savings and lending functions, private money lenders, friends and
relatives as well as trade partners. Modern institutionalized financial service provision in Ethiopia has
very short history. For long the people had been getting financial services through informal means,
Iqqubs, Iddirs and Mahbers are classic examples of informal financial service providers in which
people joined neighborhood or affinity group in order to save and access borrowings through a pool of
funds and to cover emergent needs of finance. Even though their role in the urban areas is declining
such institutions have pivotal role in the life of rural community. Axco (2017) reported that insurance
in its modern form was first started in Ethiopia as far back as 1905 when the bank of Abyssinia which
was owned by the bank of Egypt began to transact insurance as an agent of a foreign insurance
company began to underwrite fire and marine insurance policy. In 1923, the Swiss insurer Balois set
up a Branch office in Addis Ababa and soon followed by other foreign companies working on an
agency basis. During the Italian occupation from 1936 to 1941 only Italian insurance companies
operated in the country. When Italians left, insurance companies from other European countries are
restarted to operate insurance activities in Ethiopia. Belay (2001) described that as per the survey
conducted in 1954 by the Ministry of Commerce and Industry, Insurance activities was being taking
out by 18 foreign insurance companies’ branches or agents and one domestic insurance company called
Imperial Insurance established in 1951. The insurance market was governed like any commercial

30 | P a g e
goods and a service by Civil Code 1960 from the year1950s up to 1960s insurance companies has
increased to 33. The numbers of local companies were established reaching a total of 13 in number.
Belay (2001) further, asserts that due to mal practice of the insurance companies, for the second time
other study was conducted by the Addis Ababa Chamber of Commerce in 1967. The study found that
there were 306 foreign insurance branches and agents and 10 domestic companies in Ethiopia. (1) Still,
it was administered by the provision of Ethiopian commercial code, 1960 except the marine insurance
by marine code of Ethiopia. The minimum capital requirement was 12,500
Ethiopian dollars. In 1970 promulgation of proclamation no 281/1970 was issued to control
and regulate the insurance business in Ethiopia. It was peculiar in that it created an Insurance Council
and an Insurance. (1)
Controller’s office to ensure the soundness of the sector. Hailmichael (2011) also disclosed that
insurance market in Ethiopia was not regulated until 1960.The first proclamation was enacted in 1970
as a result of which foreign companies were prohibited directly or indirectly from transacting insurance
business in Ethiopia based on this some companies converted to domestic companies in line with the
requirement of the law. Surprisingly, some of the nationalized companies were accepting business
from other foreign countries, accepted business from Australia and was liable to pay its share of the
famous Darwin Claims.
Pursuant to the proclamation of 1970, regulation number 383/1971 was issued by the Ministry
of Commerce, Trade and Tourism on matters which help to create conductive insurance market. The
controller of insurance license for 15 domestic insurance companies, 36 agents, 7 brokers, 3 actuaries
and 11 assessors has been licensed in accordance with the provision of the proclamation immediately in
the year after the issuance of the law (Hailu, 2007). (1)

In 1975 all insurers were nationalized by the communist government and the Ethiopian insurance
corporation (EIC) was formed and the communist government was overthrown in 1991. In 1994 new
monetary and banking proclamation no 83/1994 was issued to supervise banks and insurance but
allowed for local insurers only. Axco (2017) described the communist government was overthrown in
1991and in 1994 legislation allows private insurance companies to be formed and compete with state
owned Ethiopian Insurance

31 | P a g e
 Corporation, but foreign shareholders were barred. The logic behind the prohibition was that
the local industry was weak and needed time to build up its capital reserves; rapid opening of the
market would expose Ethiopian companies to domination by financially much stronger foreign
insurers. The most recent legal basis for the insurance industry in Ethiopia is proclamation number
746/2012, which was issued on 22 August, 2012 and directive SIB/34/2013 issued to set up a
Supervisory organ for Insurance Business and come in to force affective from 15 April, 2013. Hence
minimum paid up capital requirement become to birr 60 million for non-life and 15 million for life and
75 million for both Life and Nonlife for insurers. And local insurers are required with minimum
subscribed capital requirement of birr 2 billion of which 50% of the subscribed is paid up capital. The
local Reinsurance establishment directive no SIB/44/2016 issued by the national bank of Ethiopia
(Belay, 2001).
In Ethiopia there are 17 insurance companies, 9 of them are composite insurance means
transacting both general insurance and long-term insurance). (1) out of the 17 insurance companies
one is state owned and 16 is private owned insurance companies, while eight of them are transacting
general insurance business. The total assets reached 11.3 billion, total capital reached 2.97 billion and
Gross premium 6.99 billion. The number of branch offices has reached 424 showing a 13% growth
over last year same period. Moreover, over 1,950 insurance sales agents, 53 insurance brokers, 97 loss
assessors and two surveyors are operating in the market. There are two reinsurance companies in
Ethiopia these are Africa-Re and Ethion-Re. Moreover, we are also micro insurance companies
established to provide to the low-level income societies. Micro insurance service is entitled to provide
by insurance companies and by micro finance banks (NBE, 2016).
As can be discussed EIC (2016) Strategic management report, 94.82% of Gross Written
premium is contributed from non-life insurance products. (4) The remaining 5.18% is contributed from
life insurance products. Out of 45 Non-life insurance products in the market 54.31% GWP is
contributed from Motor class of Business only. The remaining 40.51% GWP is contributed from the
remaining 44 non-life insurance products. In 2016, 2.61% and 4.21% of GWP is contributed from
workmen’s compensation and from Aviation class of Business respectively. Workmen’s compensation
is the lowest contribution to the production next to aviation .79.44% production is derived from 5 (five)

32 | P a g e
non-life (motor, marine, fire, W.C and aviation) products, 20.55% derived from other 50 (fifty) non-
Life products. As can be articulated in NBE (2016) retention ratio is 76% in non-life and 87% life this
means out of the total premium earned 76% is retained by the primary insurer 24% is ceded
(transferred) to reinsurance companies. Regarding life 87% is retained by primary insurer 23% is ceded
(transferred) to reinsurance companies. While an average loss ratio is 69% and 51% in non-life and
life insurance respectively.
The performance of insurance sector can be universally assessed with reference to two
parameters; insurance penetration and insurance density. Insurance penetration explains the growth of
premium with the growth of the gross domestic product in the economy. It is measured as ratio of
premium to GDP of premium with the growth. Insurance density is known as per capita premium and
measured as ratio of premium to total population. As evidence shows that 0.5% is the market
penetration; this is very low level as compared with Kenya market 3.5% market penetration, with 45
million populations. Increasing awareness is a condition precedent to penetration of insurance.
Distribution is the key development of insurance and achieving penetration. Increasing awareness is a
condition precedent to penetration of insurance. Distribution is the key development of insurance and
achieving penetration.
According to Africa-Re (2015) Africa’s insurance and reinsurance markets, with the exception
of South Africa, Namibia and Mauritius are likely to remain relatively underdeveloped for many years
to come, although are growing rapidly. (4) Sustainable economic growth has seen poverty reduce,
increasing the potential customer base for insurance. Nevertheless, even among Africa’s 18 largest
countries’ economy, poverty is still a major obstacle to a more rapid insurance market development.
In eight of these countries more than 10% of the population has to live on less than US$ 1 per day.
Currently there are nine African countries that have more registered mobile money accounts than bank
accounts according to Africa- re (2015) total premiums from the seven biggest markets (South
Africa, Morocco, Nigeria, Egypt, Kenya, Algeria and Angola) accounted for 90 % of Africa’s
insurance volume in 2013.In all African countries with the exception of South Africa, Namibia and
Mauritius, the non-life market is bigger than the life sector. According to Africa-Re, 2015, in the past

33 | P a g e
five years Nigeria and Kenya were by far the fastest growing insurance markets in Africa with annual
average growth rates well above 15%.
Out of the 18 largest African countries Ethiopia, Nigeria and Sudan are equally the lowest
insurance penetration level next to DR Congo and Libya that is 0.5%, 0.4% and 0.3% respectively As
evidence shown in the above table 41.51% African insurance market penetration share level is
accounted to only one country which is South Africa and the remaining 58.49 % insurance penetration
share level is accounted to other seventeen largest
African countries. Out of the 18 largest African countries, 18% of insurance penetration level is
accounted to Eastern African (Tanzania (0.9%, Zambia (1.4%), Sudan (0.5%), Ethiopia (0.5%), Kenya
(3.1%) and Uganda (0.6%) countries.
Moreover, of the six largest eastern African countries the highest market penetration level is
Kenya that is 3.1% of GDP and the lowest penetration level is 0.5% of GDP Ethiopia and Sudan. In
other words 51.6% portion of the eastern African region penetration level is accounted to Kenya. The
remaining 48.4% portion of the insurance penetration level is to other five largest eastern African
countries. The African comparison of penetration level evidenced that the insurance penetration in
Ethiopia which stands at 0.5% this is highly below the African average of 1.8 % in 2012. Insurance
density in Ethiopia is the least next to DR Congo in the selected African countries (Africa-Re, 2015).
The same discussion on Africa-Re (2015) Ethiopia with GDP (USD 48bn), an average of 89
million population, with GDP/Capita (USD 542), insurance market penetration and insurance density
level, 0.5% and 3 in 2013, is positioned at a very low level as, compared with Kenya with GDP (USD$
45bbn) an average of 44 million populations with GDP/capita (USD 1’016). Insurance market
penetration and insurance density level 3.5% and 35 respectively. Besides of this, East African region
comparison of insurance penetration level showed that insurance penetration level in Ethiopia which
stands 0.5 % is well lower than the region’s average penetration level of 1.08%. In East African region
the lowest insurance penetration level 0.5% are registered in Ethiopia, Sudan, and Eritrea each. The
lowest insurance density registered in Uganda, Ethiopia and Eritrea as birr four, three, and three in
number respectively.

34 | P a g e
As it can be observed from the above historical development, after the market liberalization in
Ethiopia, the number of insurance companies have been growing, Nonlife insurance segment of the
market also growing. However, the insurance sector contribution to the Ethiopian economy and
insurance consumption per capita is very low. This low level of insurance penetration is caused partly
because of the insurance sector itself. This low level of the insurance consumption may also be caused
due to the lack of understanding by the policy makers, low level of insurance awareness, low level of
insurance product savings and investment are among the most critical factors that have affected the
market penetration of the insurance market.

3.2 Current System Overview

Statutorily, insurance act classified insurance business in to two: Life insurance business and non-life
(general insurance) business:
Life insurance can be classified in to the following main ones:
1. Whole life
2. Term insurance
3. Endowment life insurance
4. Annuities.
Non-life can be classified in to
1. Property insurance
2. Liability insurance
3. Surety insurance
Life Assurance
a) Whole life, this type of product provides coverage against death of lifetime the sum of the
policy to the beneficiary of the life assured.
b) Endowment life assurance, this is comprising both term life and saving element which
comprises non-profit endowment is called term and with profit-Endowment. Endowment
insurance has a large savings element in that it guaranteed if the insured survives the term to

35 | P a g e
 pay the benefits at the end of the end of the selected term of years and at the same time making
the benefits available for his dependents if the assured died.
c) Term life, this type of life insurance product provides insurance coverage against death within
the specified period of time, the sum amount specified in the policy to the beneficiary, and
nothing being paid in case of survival.
d) An annuity, an annuity is a contract whereby the assured, receives a guaranteed income, usually
for the remainder of his life after retirement from his job. The main purpose of life annuity is
to provide a lifetime income that cannot be outlived to an individual.

General insurance

a) Fire insurance, this policy is designed to indemnify to the insured’s own buildings and their
contents (household goods and personal effects) with in this building against loss or damage
due to fire, lighting, thieves, escape of water from tanks or pipes, oil leakages from fixed
heating systems, storm, flood, riot, or malicious acts, explosion, impact by aircraft or vehicles
or animals, falling trees, subsidence and earth quake Downey (1991). The main object of fir
insurance is to reinstate or replace property damaged or destroyed or to compensate an insured
person for such person so that he is placed in the same financial position after a loss as he
occupied immodestly before it and the insured can be also compensated for the interruption of
business loss of profits due the specified risks if purchased for additional cover by paying
additional premium, the additional cover is called consequential loss.
b) Motor vehicle insurance: This policy has developed into an important form of contract arising
from its compulsory nature and increasing public demand for coverage .it provides indemnity
against loss of, or damage to or arising out of or in connection with the use of motor vehicle
including third party risks. The nature of the protection afforded here, permits development of
three different types of the motor insurance market as; third party only policy, third party, fire
and theft policy, and comprehensive. Third party covers limited amount only for damages for
third party persons and property only, if the insured is legally liable for that fault
Comprehensive, covers for third party damage and indemnified for own vehicle too. If the

36 | P a g e
 purpose of the vehicle is uses for commercial purpose the cover can be extended for the cargo,
passengers if the motor vehicle is busses.
c) Marin and aviation insurance: this type of insurance the difference is transport on sea and on
air, similar risks are faced both for aviation transport and faced by marine transport. Therefore,
insurance product is developed to provide coverage for marine and aviation hull, container and
cargo against loss or damage due to the risks such as loss of ships, collision, and fire due to
internal and external perils specified in the specific policy.
d) Engineering Insurance: under engineering insurance includes property or business income
protection against physical damage by all risks of loss except for those specifically excluded,
cover for contractors’ plant and equipment of cover are contractors all risk (CAR), Erection all
risk (EAR) and machinery break down (MB) and Boilers& pressure plant. Engineering policies
can also cover industrial all risks such as a multiline package policy which can include fire,
marine and liability.
e) Liability insurance provides coverage for bodily injury or property damage arising out of the
insured’s ownership, maintenance, or use of the insured himself. There are different types of
liability insurance classifies depends on the nature of the business nature such as product
liability provides coverage any loss of third party or purchaser of the product due to the inherent
risk of the product. Professional liability insurance product can be covered any loss arises due
the professional negligence. Public liability insurance coverage to any public damage or injury
arises due the insured own property defect.
f) Surety policy (bond): insurance Bond is not an indemnity insurance it is contact of guarantee.
A main object of contract of guarantee is to enable a person to obtain an employment, or a loan,
or some goods or services on credit. Contract of guarantee is to perform the promise, or
discharge the liability, of third person in case of default. Bond insurances are mainly given to
cover frailer of contractual agreement made between two
or more parties. In surety there are three parties the surety or guarantor’ is the insurer and the
‘creditor’ is the contractor to whom the guarantee is given and the ‘principal debtor’ is the

37 | P a g e
 principal who will be entitled to be compensated in case of the default of the performance of
the project.

3.3 Proposed System Overview

The previous system explained in part the issues that hinder the effective and efficient workflow,
customer engagement and new customers walking in the door. The proposed system meets the
customer where they are always active.
3.3.1 Functional requirements
a) System shall allow registration of clients. The system shall ask for the client’s email address,
mobile phone and other information needed to create account and shall register the user. At the
end of the registration the system shall send confirmation code to the provided email.
Implementing the system to sending verification code to the provided email. Is not dependent
with other requirements
b) System shall allow registration of clerks. At the admin dashboard registration system must
be built to create accounts for the clerks and clerks. System will implement access limitation
for the clerk’s account. Is dependent on logging in of the Default System Admin.
c) System shall allow registration of Admins. At the default admin dashboard, the registration
system will allow for the creation of new admin accounts, each pertaining to the individual
company and their oversight capabilities. The system will not implement no access limitations
for the admin account. The system is dependent on the logging in of the Default System Admin.
d) System shall send email to client for email confirmation. At time of registration of client,
clerks and admins, a confirmation code must be sent from to the system by email which is used
by the end users to log in to their account. From a technical perspective sending an email will
automatically occur from the system. Is dependent on (a, b, and c) as a requirement.
e) System shall allow the login of clients, clerks and System Admin. The system will allow the
logging in of users with their credentials. The client will have no mandatory 2 factor
authentications, unless specifically enabled by the user during registration or in the settings at

38 | P a g e
 a later time. The clerks and admins will have mandatory 2 factor authentication. This is
dependent on (a, b, and c).
f) System shall display all available insurances. The system will display the available
insurances for purchase as well as previously purchased insurances. The website and
application will directly send queries to the database and collect information regarding the
previously purchased insurances. The other information is on a static.
g) System shall allow client to request a quote. The client will be able to receive a quote on the
product they would like to insure. This will allow them the information regarding the price of
premiums. This will be made available through the database query. If they request a direct
consultation, contact information will be provided. This service is not dependent on any
requirement.
h) System shall allow the system admin to search records in the system. At any given time,
the system shall allow the system admin to search for records of the clerk. The admin will filter
and retrieve the record of the clerk. This is not dependent on any requirement.
i) System shall calculate total payment. If and or when the client makes a purchase, the system
will save and display the total cost and payment made by the customer. The system will make
available for clients and clerks the pertinent information. It is dependent on (a, b, and e).
j) System shall send a summary of purchase report to the client. Once the transaction has
been completed, the system will send a receipt to the client’s email address. This system is
dependent on (a, b, and f).
k) Proof of purchase will be saved to the database and the clients account will be updated.
After the transaction is complete, the system will send a query to the database to save the
information of the client and in doing so the account of the client will be updated. This system
is dependent on (a and g).
l) System shall allow the system admin to set the price of available insurances for purchase.
The system will give access privileges to the admin to set the prices of premiums. The prices
will be saved on the database ready for any queries. This is not dependent on any requirement.

39 | P a g e
 m) System shall allow client to view the clients profile. After successfully logging in to the
system, the system shall display client’s profile and allow client to edit the profile. The system
will load and update the client’s data on the database. Is dependent on (a).
n) System shall allow clerks to view and update his/her profile. After successfully logging in
to the system, the system shall display system admin’s profile on the web app and also allow
him/her to update profile.

The system will load and update the clerk’s data on database. Is dependent on (b).
o) System shall allow clerk to view real-time purchased insurances of the clients. The system
will give the privilege to the clerks to view the purchased insurances of the clients. The clients
may request assistance therefore this is necessary. The database will load the pertinent
information about the client. This is dependent on (b).
p) System shall allow System Admin to view real-time purchased insurances of the clients.
The system will give the privilege to the Admin to view the purchased insurances of the clients.
The clients may request assistance therefore this is necessary. The database will load the
pertinent information about the client. This is dependent on (c).
q) System shall allow system admin to generate summary report. At any given time, the
system shall allow the clerk to generate summary report about the client’s purchases as well as
the viewed insurances of customers to view which type of available insurance is getting more
attention. The clerks filter and retrieve the data from database. Is not dependent on any
requirement.
r) The system shall regurgitate the 3rd party liability price points to the end user. At any
given time, the system shall allow the customer, clerk and admin to view the 3rd party liability
prices for their usage. The client, clerk and admin will choose their preferred choice of vehicle
and its purpose. This will allow the system to display the relevant information. The system is
dependent on (a, b, and c).
s) The system shall display estimated the premium prices of a product. This purpose of this is
to give a rough estimate

3.3.2 Non-functional requirements

40 | P a g e
 a) Security: The secure system shall implement log in and logout mechanisms to maintain the
security and identify the role of the person who is currently logging in.
b) Availability: The system should be accessible 24 hours a day, 7 days a week as dependent on
the servers being up and running correctly.
c) Portability: The system should allow users to access it from any location with both their
mobile device and through their computers.
d) Error handling: The system helps in maintaining normal flow of program execution by
anticipating, detecting and resolving application and communication errors.
e) User friendly: The system is easy to use and understand, user interfaces are not complex rather
they are straightforward, and the interface is well organized.
f) Response time: The system requires minimum time to react to given input, to process input
provided and to produce desired output.

3.4 System Models Requirement Determination

3.4.1 Essential Use Case Modeling

41 | P a g e
3.4.1.1 Use Case Diagram

Registe
r

Logi
n

Cler
Request k
Clien quote
t

View
Profile
`

Set
Price

Generate
Report

Filter
Data

Logou
t

System
Admin

42 | P a g e
3.4.1.2 Use Case Documentation
Registering client
Name
Identifier UC-001
Description Registering a new client
Actor client
Pre-condition None
Post condition The client will be registered in the system
Basic Course of Action:
1. Client open the app.
2. New client will be welcomed using “PUI001: start”.
3. Client will start the operation using “PUI001: start”.
4. Client provide basic information using “PUI003: signup”.
5. System verify the validity of provided information.
6. Client press next button using “PUI003: signup”.
7. Client will be asked the verification code from phone number using “PUI004: verify”.
8. Client provide verification code using “PUI004: verify”.
9. The system verifies the verification code. 10. Client will be asked the verification code
from email using “PU1005: verify” 11.
Client will provide verification code using “PU1005: verify” 12.
The system verifies the verification code.
13. Client will see terms and policy using “CUI001: terms and policy”.
14. Client check the “I agree to terms and policy” box using “PUI003: signup”.
15. Client will be welcomed to the system using “PUI005: welcome”.
Alternative Course of Action A: Data validation fails
1. The system determines the data in invalid.
2. The system informs the client to enter valid data.
3. The use cases resume at step 4 of the basic course of action.
Alternative Course of Action B: Verification code is invalid 12 The
1. system determines verification code is invalid.
2. The use cases resume at step 10 of the basic course of action.
register client essential use case documentation

Name Registering clerks

Identifier UC-002
Description Registering a new clerk’s that can manage the system

43 | P a g e
 Actor System Administrator
Pre- Condition None
Post Condition The new clerk will be registered in the system
Basic Course of Action
1. The system promotes for username and password.
2. System admin will provide user name and password using “AWUI001: Login”.
3. The system verifies the credential provided
4. The System Admin will send a link to new Clerks and Admins
5. The system admin will navigate to Generate Link.
6. Clerk or Admin navigates to the link and registers information
7. System checks the validity of credential.
8. System creates the account.
Alternative Course of Action A: Incorrect credentials
1. The system determines the credential is invalid.
2. The system informs the system admin the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
Alternative Course of Action B: Incorrect clerk information
1. The system determines the information is invalid.
2. The system informs the system admin the provided credential in invalid.
3. The use cases resume at step 6 of the basic course of action.

register clerk essential use case documentation

Name Client login

Identifier UC-003
Description Verifying the client’s identity to allow login to the system
Actor Client
Pre-condition Client must have an account
Post condition Client will login to the system
Basic Course of Action
1. System asks the client for credential using “PUI002: sign in”.
2. Client provide credentials.
3. System verifies the provided credential.
4. System redirect the client to home map with the API configured using “PUI006: home”.
Alternative Course of Action A: Incorrect credentials
1. The system determines the credential is invalid.
2. The system informs the client the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
client login essential use case documentation

44 | P a g e
Name Clerk login
Identifier UC-004
Description Verifying clerk’s identity to allow login
Actor Clerks
Pre-condition Clerk must have an account
Post condition Clerk will login to the system
Basic Course of Action
1. System promotes for username and password using “OWUI001: login”.
2. Clerk will provide user name and password.
3. system verifies the credential provided and prompts a code.
4. System redirect the clerk to dashboard using “OWUI002: dashboard”.
Alternative Course of Action A: Incorrect clerk credentials
4 The system determines the credential is invalid.
5 The system informs the clerk the credential in invalid.
6 The use cases resume at step 1 of the basic course of action.
clerk login essential use case documentation

Name System administrator login

Identifier UC-010
Description Verifying System administrator’s identity to allow login
Actor System administrator
Pre-condition System administrator must have an account
Post condition System administrator will login to the system
Basic Course of Action
1. System promotes for username and password using “OWUI001: login”.
2. Admin will provide user name and password.
3. system verifies the credential provided and prompts a code.
4. System redirect the clerk to dashboard using “OWUI002: dashboard”.
Alternative Course of Action A: Incorrect clerk credentials
1. The system determines the credential is invalid.
2. The system informs the System administrator the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
Table 3.5 admin login essential use case documentation

Name Logout
Identifier UC-011

45 | P a g e
Description Logging out user that has logged in previously
Actor Admin, Clerk, Client
Pre-condition Actors must login
Post condition Actors will logout of the system
Basic Course of Action
1. The actor will navigate to setting.
2. Actor chose to logout.
3. The system verifies the logout request
4. The system destroys session and cookies started.
5. System redirect the actor to login.
Alternative Course of Action A: logout request fail 1.
The system determines the request is canceled.
2. The actor will be redirected to home.
logout essential use case documentation

Name Calculate payment

Identifier UC-018
Description Calculate the total payment
Actor Clerk
Pre-condition Insurance quote requested
Post condition Total payment will be sent to client’s app and database
Basic Course of Action
1. System asks the client for credential using “PUI002: sign in”.
2. Client provide credentials.
3. System verifies the provided credential.
4. Client selects an insurance type using “PUI006: Insurance options.”
5. Client shares credentials necessary for accurate payment calculation “PU1006”
6. Client confirms order using “PUI007: conform order”.
7. System displays the total payment “PU1006”.
8. System send confirmation through email with a total payment.

46 | P a g e
Alternative Course of Action A: Incorrect credentials
1. The system determines the credential is invalid.
2. The system informs the client the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
calculate payment essential use case documentation

Name View profile

Identifier UC-021
Description Viewing profile from mobile phone.
Actor Client, Clerk
Pre-condition Client must have an account
Post condition Profile will be displayed for the client
Basic Course of Action
1. System asks the client for credential using “PUI002: sign in”.
2. Client provide credentials.
3. System verifies the provided credential.
4. System loads to the map with the API configured using “PUI006: home map”.
5. Client goes to navigation menu using “CUI004: navigation menu”.
6. Client views profile using “PUI011: profile”.
Alternative Course of Action A: Incorrect credentials
1. The system determines the credential is invalid.
2. The system informs the client the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
client view profile essential use case documentation

Name Edit profile

Identifier UC-028
Description Editing profile from web application.

47 | P a g e
Actor Clerk, Admin, Client
Pre-condition Logged in Account
Post condition Profile will be edited from the web application
Basic Course of Action
1. The system promotes for username and password using “OWUI001: login”.
2. Clerk will provide user name and password.
3. The system verifies the credential provided.
4. System loads map using “OWUI002: dashboard”.
5. The clerk will navigate to setting from dash board.
6. System display profile information of clerk using “OWUI004: profile”.
7. Clerk write changes to profile using “OWUI004: profile” 8. System update the change
made in the database.
Alternative Course of Action A: Incorrect clerk credentials
1. The system determines the credential is invalid.
2. The system informs the clerk the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
clerk edit profile essential use case documentation

Name Generate report

Identifier UC-030
Description The system will filter data from both real-time and database and
generate report for the managers.
Actor Clerk, Admin
Pre-condition Logged in account
Post condition Report will be generated
Basic Course of Action
1. The system promotes for username and password using “OWUI001: login”.
2. Clerk will provide user name and password.
3. The system verifies the credential provided
4. The clerk will navigate to filter from dash board.
5. Clerk select criteria to filter using “OWUI003: filter”.
Alternative Course of Action A: Incorrect credentials
1. The system determines the credential is invalid.
2. The system informs the clerk the credential in invalid.
3. The use cases resume at step 1 of the basic course of action.
generate report essential use case documentation

48 | P a g e
 3.4.2 Essential UI Prototype
3.4.2.1 Client Mobile Application UI Prototype

Fig 3.4.2.1 Front Page Fig 3.4.2.2 Login page

49 | P a g e
50 | P a g e
3.4.2.3 Website UI Prototype

Fig 3.4.2.3 Website UI Prototype

Fig 3.4.2.4 client page

51 | P a g e
Fig 3.4.2.5 login page

52 | P a g e
Fig 3.4.2.6 client home page

53 | P a g e
3.4.3 User Interface Flow Diagram

3.4.4 Supplementary Specifications

3.4.4.1 Business Rules
a) ID: BR001 Name: Insurance Against Damages
Description: Insurance against damages or Property Insurance protects the insured
from the loss caused by damage or destruction of physical property. This category of
insurance covers losses caused by an accident or negligence that damages one’s
personal property. For example damage to one’s vehicle as a result of a collision.
b) ID: BR002 Name: Insurance of Persons
Description: Insurance of Persons means that such persons are indemnified against any
risks arising from the death or injury to persons. Injury may also mean an illness that
prevents the insured person (or policy holder) from functioning fully.

54 | P a g e
 c) ID: BR003 Name: Insurance of Liability for Damages
Description: Article 685 of the commercial code states “the insurer who insured a
liability for damages shall not pay compensation until a claim is made against the
insured person with a view to amicable or judicial settlement” Here if one person is
insured against liability for damages, their party who claims to be injured by this person
must appear to pay the insurance. Some employers may insure their employees against
liability for damages they caused.

3.4.4.2 Constraints

Every project is constrained in different ways, often by its scope, time, and cost goals.
To create a successful project, a project manager must consider constraint and balance its goals.
The basic constraint in our project are the following:

1. Internet access: Cheetah ambulance is a real time ambulance service, it needs fast and
continues internet access. According to our country network this may be a challenge for this
project.

2. Scope: Change in geographical or functional scope in the project requires extra financial and
other resource. So, the project manager must control the scope change.
3. Cost: Financial cost is one of fundamental element in project success. The project may require
additional cost in case of scope change, increment of resource price and time change. The
project sponsor and project manager must be controlling the cost constraint.

4. Resource: The tools, equipment, software, materials and team members that will be used
during project works are considered as a project resource. The availability of required resource
is mandatory to complete the project on the schedule. Therefore, the project manager must
manage the resource constraint.

5. Time: Every task and process takes time. Our project is a year scheduled. So, to complete the
project in the schedule time the project manager must be control the project

55 | P a g e
3.4.4.3 Change Case
a) Online payment becomes available
The system will automatically insure renewals without input from client.
The system will prompt the client before the transaction is complete, and
only if the client chooses to stop this transaction will be terminated.
b) System integration with vehicle inspection and bolo renewal services.
The system’s integration with the countries inspection and bolo renewal
services will significantly decrease the time wasted during this season of
work. The total time spent on the act of renewing vehicle inspection and
bolo renewal services depends on the sole least efficient factor, humans. The
average time spent on this act is 3 – 5 hours depending on your locality and
working speed of the service renewing officers at each location, which are
4. The vehicle inspection area, road fund payment office, printing and copy
office, finally bolo renewal office. Once this efficiency draining factor is
removed, the transaction process will be from vehicle inspection to online
payment to bolo service office to pick up vehicle bolo.
c) System integration with postal service
The system will send 3rd party coverage papers to the post of the client and
the insurance transaction will become fully automated. The postal service
will send the client a tracking ping when the insurance papers arrive.

56 | P a g e
 3.5 System Models – Analysis
3.5.1 System Use case Modeling

Register

Login

Clerk
Request quote
Client

View Profile

Set Price

Generate Report

Filter Data

Logout

System Admin

3.5.1.1 Use Case Diagram

57 | P a g e
3.5.1.2 Use Case Documentation
Registering client
Name
Identifier UC-001
Description Registering a new client
Actor client
Pre-condition None
Post condition The client will be registered in the system
Basic Course of Action:
16. Client open the app.
17. New client will be welcomed using “PUI001: start”. 18. Client will
start the operation using “PUI001: start”.
19. Client provide basic information using “PUI003: signup”.
20. System verify the validity of provided information.
21. Client press next button using “PUI003: signup”.
22. Client will be asked the verification code from phone number using “PUI004: verify”.
23. Client provide verification code using “PUI004: verify”.
24. The system verifies the verification code.
25. Client will be asked the verification code from email using “PU1005: verify”
26. Client will provide verification code using “PU1005: verify”
27. The system verifies the verification code.
28. Client will see terms and policy using “CUI001: terms and policy”.
29. Client check the “I agree to terms and policy” box using “PUI003: signup”.
30. Client will be welcomed to the system using “PUI005: welcome”.
Alternative Course of Action A: Data validation fails
4. The system determines the data in invalid.
5. The system informs the client to enter valid data.
6. The use cases resume at step 4 of the basic course of action.
Alternative Course of Action B: Verification code is invalid 12 The
1. system determines verification code is invalid.
2. The use cases resume at step 10 of the basic course of action.

58 | P a g e
 Table 3.1 register client essential use case documentation

Name Registering clerks

Identifier UC-002
Description Registering a new clerk’s that can manage the system
Actor System Administrator
Pre- Condition None
Post Condition The new clerk will be registered in the system
Basic Course of Action
3. The system promotes for username and password.
4. System admin will provide user name and password using “AWUI001: Login”.

9. The system verifies the credential provided

10. The System Admin will send a link to new Clerks and Admins
11. The system admin will navigate to Generate Link.
12. Clerk or Admin navigates to the link and registers information
13. System checks the validity of credential.
14. System creates the account.

59 | P a g e
Alternative Course of Action A: Incorrect credentials
4. The system determines the credential is invalid.
5. The system informs the system admin the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.
Alternative Course of Action B: Incorrect clerk information
4. The system determines the information is invalid.
5. The system informs the system admin the provided credential in invalid.
6. The use cases resume at step 6 of the basic course of action.

Table 3.2 register clerk essential use case documentation

Name Client login

Identifier UC-003
Description Verifying the client’s identity to allow login to the system
Actor Client
Pre-condition Client must have an account
Post condition Client will login to the system
Basic Course of Action
5. System asks the client for credential using “PUI002: sign in”.
6. Client provide credentials.
7. System verifies the provided credential.
8. System redirect the client to home map with the API configured using “PUI006: home”.
Alternative Course of Action A: Incorrect credentials
4. The system determines the credential is invalid.
5. The system informs the client the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.
Table 3.3 client login essential use case documentation

Name Clerk login

Identifier UC-004
Description Verifying clerk’s identity to allow login
Actor Clerks
Pre-condition Clerk must have an account
Post condition Clerk will login to the system
Basic Course of Action
5. System promotes for username and password using “OWUI001: login”.
6. Clerk will provide user name and password.
7. system verifies the credential provided and prompts a code.
8. System redirect the clerk to dashboard using “OWUI002: dashboard”.

60 | P a g e
Alternative Course of Action A: Incorrect clerk credentials 7 The
system determines the credential is invalid.
8 The system informs the clerk the credential in invalid.
9 The use cases resume at step 1 of the basic course of action.
Table 3.4 clerk login essential use case documentation

Name System administrator login

Identifier UC-010
Description Verifying System administrator’s identity to allow login
Actor System administrator
Pre-condition System administrator must have an account
Post condition System administrator will login to the system
Basic Course of Action
5. System promotes for username and password using “OWUI001: login”.
6. Admin will provide user name and password.
7. system verifies the credential provided and prompts a code.
8. System redirect the clerk to dashboard using “OWUI002: dashboard”.
Alternative Course of Action A: Incorrect clerk credentials
4. The system determines the credential is invalid.
5. The system informs the System administrator the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.
Table 3.5 admin login essential use case documentation

Name Logout
Identifier UC-011
Description Logging out user that has logged in previously
Actor Admin, Clerk, Client
Pre-condition Actors must login
Post condition Actors will logout of the system
Basic Course of Action
6. The actor will navigate to setting.
7. Actor chose to logout.
8. The system verifies the logout request
9. The system destroys session and cookies started.
10. System redirect the actor to login.

61 | P a g e
Alternative Course of Action A: logout request fail 3.
The system determines the request is canceled.
4. The actor will be redirected to home.
Table 3.6 logout essential use case documentation

Name Calculate payment

Identifier UC-018
Description Calculate the total payment
Actor Clerk
Pre-condition Insurance quote requested
Post condition Total payment will be sent to client’s app and database
Basic Course of Action
9. System asks the client for credential using “PUI002: sign in”.
10. Client provide credentials.
11. System verifies the provided credential.
12. Client selects an insurance type using “PUI006: Insurance options.”
13. Client shares credentials necessary for accurate payment calculation “PU1006”
14. Client confirms order using “PUI007: conform order”.
15. System displays the total payment “PU1006”.
16. System send confirmation through email with a total payment.
Alternative Course of Action A: Incorrect credentials
4. The system determines the credential is invalid.
5. The system informs the client the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.
Table 3.7 calculate payment essential use case documentation

Name View profile

Identifier UC-021
Description Viewing profile from mobile phone.
Actor Client, Clerk
Pre-condition Client must have an account
Post condition Profile will be displayed for the client

62 | P a g e
Basic Course of Action
7. System asks the client for credential using “PUI002: sign in”.
8. Client provide credentials.
9. System verifies the provided credential.
10. System loads to the map with the API configured using “PUI006: home map”.
11. Client goes to navigation menu using “CUI004: navigation menu”.
12. Client views profile using “PUI011: profile”.
Alternative Course of Action A: Incorrect credentials
4. The system determines the credential is invalid.
5. The system informs the client the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.
Table 3.8 client view profile essential use case documentation

Name Edit profile

Identifier UC-028
Description Editing profile from web application.
Actor Clerk, Admin, Client
Pre-condition Logged in Account
Post condition Profile will be edited from the web application
Basic Course of Action
9. The system promotes for username and password using “OWUI001: login”.
10. Clerk will provide user name and password.
11. The system verifies the credential provided.
12. System loads map using “OWUI002: dashboard”.
13. The clerk will navigate to setting from dash board.
14. System display profile information of clerk using “OWUI004: profile”.
15. Clerk write changes to profile using “OWUI004: profile” 16. System update the change
made in the database.
Alternative Course of Action A: Incorrect clerk credentials
4. The system determines the credential is invalid.
5. The system informs the clerk the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.

63 | P a g e
 Table 3.9 clerk edit profile essential use case documentation

Name Generate report

Identifier UC-030
Description The system will filter data from both real-time and database and
generate report for the managers.
Actor Clerk, Admin
Pre-condition Logged in account
Post condition Report will be generated
Basic Course of Action
6. The system promotes for username and password using “OWUI001: login”.
7. Clerk will provide user name and password.
8. The system verifies the credential provided
9. The clerk will navigate to filter from dash board.
10. Clerk select criteria to filter using “OWUI003: filter”.
Alternative Course of Action A: Incorrect credentials
4. The system determines the credential is invalid.
5. The system informs the clerk the credential in invalid.
6. The use cases resume at step 1 of the basic course of action.

64 | P a g e
3.5.2 Sequence Diagram

1. Client Registration

65 | P a g e
2. Clerk Registration

66 | P a g e
3. Admin Registration

67 | P a g e
4. Login

68 | P a g e
5. Logout

69 | P a g e
6. View

70 | P a g e
7. Edit Profile

71 | P a g e
8. Quote

72 | P a g e
9. Claim registration

73 | P a g e
10. Claim View

74 | P a g e
11. Remove Client/Admin

75 | P a g e
3.5.3 Activity Diagram

1. Client Registration

76 | P a g e
.

2. Clerk Registration

77 | P a g e
3. Admin Registration

78 | P a g e
4. Login

79 | P a g e
5. Logout

80 | P a g e
6. View and Edit Profile

81 | P a g e
7. Generate Report

82 | P a g e
8. Get a Quote (Client)

83 | P a g e
9. Delete Client account

84 | P a g e
10. Claim registration (Client)

85 | P a g e
11.Claim registration (Clerk/Admin)

86 | P a g e
12. Claim View

87 | P a g e
13.View Client Information

88 | P a g e
14. View Clerk Information

89 | P a g e
15. Give quote (Clerk / Admin)

90 | P a g e
16. Remove clerk

91 | P a g e
Chapter 4 - System Design
4.1 Introduction
System design is the process of defining elements of system like modules, architecture,
component and their interfaces and data for the system based on the specified requirement. It is the
process of defining, developing and designing system which satisfies the specific needs and
requirement of a business or organization.
A systemic approach is required for a coherent and well-running system. Bottom-Up or
TopDown approach is required to take into account all related variables of the system. A designer
uses the modelling languages to express the information and knowledge in a structure of system
that is defined by a consistent set of rules and definitions. The designs can be defined in graphical
or textual modelling languages. Some of the examples of graphical modelling languages are
A. Unified Modelling Language (UML): To describe software both structurally and behaviorally with
graphical notation.
B. Flowchart: A schematic or stepwise representation of an algorithm.
C. Business Process Modelling Notation (BPMN): Used for Process Modelling language.
D. Systems Modelling Language (SysML): Used for systems engineering.
Design methods:
A. Architectural design: To describes the views, models, behavior, and structure of the system.
B. Logical design: To represent the data flow, inputs and outputs of the system. Example: ER
Diagrams (Entity Relationship Diagrams).
C. Physical design: Defined as a) How users add information to the system and how the system
represents information back to the user. b) How the data is modelled and stored within the
system.
D. How data moves through the system, how data is validated, secured and/or transformed as
it flows through and out of the system. Or System design can be described as a phase that

92 | P a g e
 bridges the gap between problem domain and the existing system in a manageable way.
These will identify qualities that the system must focus on, so that design decisions can be
based on a specific set of criteria. In our documentation we have used UML the modelling
languages to express the information and knowledge in a structure of our system.
4.2 Design Goals
Design goals are targets for design work. These are typically agreed up on by stakeholders
as the criteria for comparing design alternatives and evaluating design outcomes.
The following are our design goals.

A. Delivery time: The system will be completed and delivered on the agreed date with agreed
requirements
B. Customer need: Meeting our patients need to get fast ambulance service.
C. Performance: Fast patient request processing and response providing time.
D. Portability: The mobile app runs on all version of android mobile devices.
E. Productivity: Our system targets to increase productivity of
a. Patients by improving the traditional ambulance requesting method.
b. officers by improving ambulance managing and tracking system.
F. Functionality: Our system will address all requirements we agreed up on the beginning of this system.
G. Learnability: Our goal is to design system that is easy to learn and use for novice users.
H. Fit to Purpose: The system is designed to address the issues mentioned in the statement of problem
without any unnecessary addition to quality.

4.3 Design Trade offs

A. Delivery time vs. functionality
If we could not market our product promptly, we will launch with main functionalities.
Thereafter, we will gradually add up further functionalities.
B. Performance vs portability

93 | P a g e
 If we could not implement all the performance requirement on all versions of
targeted devices, first we will work on addressing the preferred device versions then we will
gradually adopt on the rest versions.
C. Security vs. functionality
We will always make sure the functionalities we will be introducing in our system
wouldn’t distort the security or create a hole in the system.

4.4 Subsystem Decomposition

94 | P a g e
4.5 Design Phase Models
4.5.1 Class Modeling

<<User>> <<Clerk>> <<Admin>>

-name:string -name:string -name:string

-age:int -age:int -age:int

-sex:int -sex:int -sex:int

-userName:string -dateofbirth:string -dateofbirth:string

-password:string -userName:string -userName:string

-user_ID:varchar -password:string -password:string

-JobTitle:string -JobTitle:string
+ updateProfile ()
-Emp_ID:varchar -Man_ID:varchar
+ login()
+ claimRequest () + login() +updateProfile ()

+ quoteRequest () + updateProfile () +login()

+ logout () + quoteValidation () +quoteRequest ()

+ claimRequest () +quoteValidation ()
+ quoteRequest () +claimRequest ()
+ claimValidation() +claimValidation()
+ logout() +accountLinkgen()
+removeAccount ()
+logout ()

<<Claim>>

<<Quote>> -carRegID:int
-policeReport:varBinary(n)
-nameofCar:string
-carRepairEstimate:date
-importedyear:int
-driversLiscence:varBinary(Max)
-damagePremium:int
+claimValidationRequest ()
-locationofinport:string
-ageofCar:date

+ quoteValidationRequest ()

95 | P a g e
4.5.2 Persistent Model
4.5.2.1 Mapping Class Diagram to Relation
I) user (fname, lname, gname, age, sex, user_ID, phone_number, user_email, car_Reg)
II) clerk (Emp_gname, Emp_fname, Emp_lname, Emp_age, Emp_sex, Emp_dob, Emp_jobtitle,
EMP_id, Emp_email, Emp_phone, Emp_profile_photo,
Emp_public_ID_Photo, Emp_HomeNo, Emp_Woreda,
Emp_emergency_contact_name, Emp_emergency_contact_number)
III) Admin (Emp_fname, Emp_lname, Emp_age, Emp_sex, Emp_dob, Emp_jobtitle, MAN_id,
EMP_id, Emp_email, Emp_phone, Emp_profile_photo, Emp_public_ID_Photo,
Emp_HomeNo, Emp_Woreda,
Emp_emergency_contact_name, Emp_emergency_contact_number,)
IV) Employee_login( EMP_id, MAN_id, Enc_Password) V) User_Login (user_id,
Enc_Passowrd)
VI) Quote (cartype, Y_import, own_Damage, claim_bonus, discount, liability, Y_car, car_RegNo,
Car_ChassisNo)
VII) Claim (Car_ChassisNo, CarRegNo, policeReport, Car_Repair_Estimate,
drivers_liscence_ID)

4.5.2.2 Normalization
I) user (fname, lname, gname, age, sex, user_ID, phone_number, user_email, car_Reg)

1NF: No multivalued attribute

2NF: No partial dependency
3NF: No transitive dependency

II) clerk (Emp_gname, Emp_fname, Emp_lname, Emp_age, Emp_sex, Emp_dob, Emp_jobtitle,

EMP_id, Emp_email, Emp_phone, Emp_profile_photo,

96 | P a g e
 Emp_public_ID_Photo, Emp_HomeNo, Emp_Woreda,
Emp_emergency_contact_name, Emp_emergency_contact_number)
1NF: No multivalued attribute
2NF: No partial dependency
3NF: No transitive dependency

III) Admin (Emp_fname, Emp_lname, Emp_age, Emp_sex, Emp_dob, Emp_jobtitle, MAN_id,

EMP_id, Emp_email, Emp_phone, Emp_profile_photo, Emp_public_ID_Photo,
Emp_HomeNo, Emp_Woreda,
Emp_emergency_contact_name, Emp_emergency_contact_number,)
1NF: No multivalued attribute
2NF: No partial dependency
3NF: No transitive dependency

IV) Employee_login( EMP_id, MAN_id, Enc_Password)

1NF: No multivalued attribute
2NF: No partial dependency
3NF: No transitive dependency

V) User_login( User_id, Enc_Password)

1NF: No multivalued attribute
2NF: No partial dependency
3NF: No transitive dependency

VI) Quote (cartype, Y_import, own_Damage, claim_bonus, discount, liability, Y_car, car_RegNo,
Car_ChassisNo)
1NF: No multivalued attribute
2NF: No partial dependency
3NF: No transitive dependency

VII) Claim (Car_ChassisNo, CarRegNo, policeReport, Car_Repair_Estimate,

drivers_liscence_ID)
1NF: No multivalued attribute
2NF: No partial dependency

97 | P a g e
 3NF: No transitive dependency

4.5.3 User Interface Design Mobile Application

Fig 3.1 Front Page Fig 3.2 Login Page

98 | P a g e
99 | P a g e
100 | P a g e
Website Design

Fig 3.1 Website Landing page

101 | P a g e
Fig 3.2 Website client Sign up Page

102 | P a g e
Fig 3.3 Login Page

Fig 3.4 Client Home Page

103 | P a g e
Fig 3.13 Clerk Claims list

104 | P a g e
Fig 3.14 Client Claims list

Fig 3.15 About Page

105 | P a g e
Fig 3.16 Not Signed in Contact us Page

Fig 3.17 Signed in Contact us Page

106 | P a g e
4.5.4 Deployment Diagram

107 | P a g e
4.5.5 Network Design

108 | P a g e
 Chapter 5: Implementation and Testing
5.1 Introduction
For the best optimal use of the code, we developed two sets applicable systems. These systems have been
developed with the intention of allowing the user to have an experience that will encourage said user to be a
repeat customer. With the ability to interact with the insurance purchases, get notified when their purchases are
about expire, and get quotes on items they wish to insure allows for a direct easy to use and compelling experience.

5.2 Sample Code

Web Application
Sample code for the employee to register a client
<?php

$conn = mysqli_connect("localhost","root","","final"); if(!$conn){ die('Could not connect: '.mysqli_connect_error());

$query="select * from users";

$data=mysqli_query($conn, $query);

$total=mysqli_num_rows($data);

?>

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="UTF-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="../css/adminform.css">

<link rel="stylesheet" href="../css/all.css">

<title>EMPLOYEE form</title> </head>

<body>

<div class="container">

109 | P a g e
<div class="title">CUSTOMER REGISTRATION</div>

<form action="#" method="post">

<div class="employee-detail">

<div class="input-box">

<span class="details">First Name</span>

<input type="text" placeholder="First Name" name="fname" required>

</div>

<div class="input-box">

<span class="details">Last Name</span>

<input type="text" placeholder="Last Name" name="lname" required>

</div>

<div class="input-box">

<span class="details">User Name</span>

<input type="text" placeholder="User Name" name="uname" required>

</div>

<div class="input-box">

<span class="details">Email</span>

<input type="text" placeholder="Enter Email" name="email" required>

</div>

<div class="input-box">

<span class="details">Password</span>

<input type="password" placeholder="Enter Password" name="password" required>

</div>

<div class="input-box">

<span class="details">Confirm Password</span>

<input type="password" placeholder="Confirm Password" name="cpassword" required>

</div>

110 | P a g e
 <div class="input-box">

<span class="details">Address</span>

LOG OUT

<?php
session_start();
if(isset($_SESSION['aname'])){
session_destroy();
echo "<script>location.href='login.php'</script>"; }

else{
echo "<script>location.href='login.php'</script>";
}
if(isset($_SESSION['uname'])){
session_destroy();
echo "<script>location.href='login.php'</script>"; }

else{
echo "<script>location.href='login.php'</script>";
}
if(isset($_SESSION['ename'])){
session_destroy();
echo "<script>location.href='login.php'</script>"; }

else{
echo "<script>location.href='login.php'</script>";
}

?>

111 | P a g e
Chapter 6 Conclusion and Recommendation
6.1 Conclusion
we believed to be the best implementation of insurance management. We focused on the user’s experience. The
system was developed to have the user experience well enough for a second, third and even more visits to the
website and mobile application.

With this in mind we developed a means in which the user can find the necessary information they require with
as little hindrance as possible. The website was developed with feedback from multiple end users of both websites
and insurances. The need we found and tried our utmost to quench was for the insurance information of new
purchases, renewals and documentation regarding these items be clearly displayed.

The system will allow users who are joining for the first time to view the available purchasable items and
direct by their input to find the quotes given by any given insurance company that chooses to incorporate our
system with theirs. A user that is a continuous user will no longer have to rummage through their drawers to find
their previous insurance items. They already have all they need to renew their purchases, if they choose so, via
mobile banking which is becoming readily available as we speak, they will be able to. The user can visit stores for
purchases related to the quotes they received from the system.

Overall, the users experience is the top goal for the development system. We have strived to achieve that
and have developed two methods for this outcome.

6.2 Recommendation
There are four recommendations that need to be addressed for the gap that we have found in the insurance management
field.

we have is the reviewing, rectifying and finalization of the project. Firstly, by reviewing the project, the
stakeholders will understand the basis of our work and the reasoning behind the developed project. Secondly by
rectifying the project, the stakeholder will directly state the areas in which the project needs to be improved. If
the project requires extra work, the stakeholders will direct the team to add or remove aspects of the project that
are not favorable for the Implementation of the project. Lastly, finalizing the project takes into consideration the
previous factors and gets approval for the implementation of the project.

stakeholders to the project such as the insurance company, banks, user, road fund, and transport authority.
These stakeholders will receive information regarding the purchase of the client. This information will give them
the go ahead in regards to getting things ready for the client in their respective sections. For example, when a
client uses a banking system to pay for an insurance, the company, upon verification of payment, will make ready
the items for the client to put on their car. The road fund will send notification for the user that their road fund is
due and provide methods of payment and the amount required (The road fund authority has already implemented
banking payment method). The transport authority will acknowledge these purchases and make ready the items

112 | P a g e
ready for purchase. The communication between these stakeholders will make more efficient the structure and
make ready all requirements.

sensitize the population and implement a means of directing users to use this system for benefits such as
monetary benefits…etc. This will allow the users to be sensitized to non-paper-based system that will inevitably
help the world in the long run. Users who want to have a clear understanding of the insurance policies they have
purchased will have a clear understanding of what they have purchased and this will encourage all those will use
this system to use this more and more.

promote the website and mobile application to end users through the launching of the project and through
media. The media will be the top advertising platform for the availability of the system. The media will encourage
people to use this item more and more. The launching of this project will guide users to take a first-hand approach
to their purchases and this, we believe, will be a selling point for advertising.

113 | P a g e
REFERENCE

1, Temesgen Aziza, 2012. Challenges and Opportunities of Insurance Business in Ethiopia

2, https://www.britannica.com/topic/insurance/Historical-development-of-insurance
3, https://work.chron.com/insurance-objectives-23793.html
4, https://www.investopedia.com/ask/answers/052015/what-main-business-modelinsurancecompanies.asp

114 | P a g e
List of abbreviation
OO - - Objected Oriented

SDLC - - System Design Life Cycle

UML - - Unified Modeling Language

CMS - - Content Management System

LMS - - Learning Management System

PDS - - Pervasive Display Systems

GUI - - Graphical User Interface

EIC - - Ethiopian Insurance Corporation

115 | P a g e
116 | P a g e