Case Study

On
LIC(LIFE INSURANCE)

BACHELOR OF TECHNOLOGY in
COMPUTER SCIENCE AND ENGINEERING
By
SINGH PURUSHOTTAM MANOJ

Registration number:11802669
Roll No:A08
Section:K18JC

School of Computer Science and Engineering

Lovely Professional University
Phagwara, Punjab (India)
 DECLARATION STATEMENT

I hereby declare that the case study entitled “LIC (LIFE INSURANCE )”submitted at Lovely
Professional University, Phagwara, Punjab is an authentic work and has not been submitted
elsewhere.

I understand that the work presented herewith is in direct compliance with Lovely Professional
University’s Policy on plagiarism, intellectual property rights, and highest standards of moral and
ethical conduct. Therefore, to the best of my knowledge, the content of this case study represents
authentic and honest effort conducted, in its entirety, by me. I am fully responsible for the contents
of my case study report.

Signature of Candidate

Name of the Candidate

SINGH PURUSHOTTAM MANOJ

ROLL NO. A08

 Objective of the project.....................................................................................
2
1.2.1 General objective ........................................................................................
2
1.2.2 Specific objective ........................................................................................
2
1.3 Scope of the project ..........................................................................................
3
1.3.1 In scope ......................................................................................................
3
1.3.2 .Out scope ...................................................................................................
3
1.3.3 Limitation of the project .............................................................................
3
1.4 Significance and beneficiary of the project ......................................................
3
1.4.1 Significant of the project ............................................................................
3
1.4.2 Target beneficiaries of the system ..............................................................
4
1.5.2 .1 Institution .............................................................................................
4
1.5.2 .2 Developer team ....................................................................................
4
1.5.2 .3 User of the system ...............................................................................
4
1.5 Methodology .....................................................................................................
5
1.5.1 Method of data collection ...........................................................................
5
1.5.2 System development methodology .............................................................
5

Page | 1
 1.5.3 Development tool........................................................................................
5
1.5.3.1 Hardware tools required .......................................................................
5
1.5.3.2 Software tools required.........................................................................
6
1.5.4 System evaluation procedure ......................................................................
6
1.6 Feasibility of the project ...................................................................................
6
1.6.1 Technical feasibility....................................................................................
6
1.6.2 Economic feasibility ..................................................................................
7
1.6.3 Operational feasibility ...............................................................................
7
1.7. 4 Schedule feasibility ....................................................................................
7
1.7.5 Political Feasibility .....................................................................................
8
1.9. Project Schedule ..............................................................................................
8
1.10 Project team management ...............................................................................
8
1.11 Organization of the study ................................................................................
9
CHAPTER TWO
...................................................................................................11
2. Current system
..................................................................................................11
2.1Description of current system .......................................................................11
2.2 Strength in the existing system ....................................................................11

Page | 2
 2.3 Weakness in the Existing system.................................................................11
2.4Business rules ...............................................................................................12
2.5 Expected outcome of the project .................................................................13
CHAPTER THREE
...............................................................................................14
3. Proposed system ...............................................................................................14
3.1 Overview of the proposed system ...............................................................14
3.2Functional requirements ...............................................................................14
3.3 Nonfunctional requirements ........................................................................15
3.4 Hardware Requirement
................................................................................15
3.5 Software Requirement .................................................................................15
3.6. Security and Safety Procedure ....................................................................16
3.2.1 Security Procedure .................................................................................16
3.6.2 Safety Procedure
....................................................................................16
CHAPTER FOUR
..................................................................................................17
4. System Analysis and designing ........................................................................17
4.1 System models .............................................................................................17
4.1.1Scenarios
.................................................................................................17
4.1 .2 Use case diagram ..................................................................................17
4.1.3 Use Case Description ............................................................................20
4.1.4 Class diagram (conceptual modeling) ...................................................31
4.1.5 ER (EER) diagram (conceptual modeling) ...........................................32
4.2.1.1 Normalized table (3rd) .....................................................................33
4.3 Dynamic model ............................................................................................37
4.3.1 Sequence diagram ..................................................................................37

Page | 3
 4.3.2 Activity Diagram ...................................................................................47
4.2.3 State chart diagram
................................................................................52
4.2.4 Component Modeling
............................................................................55 4.2.5 Deployment
modeling ...........................................................................56
4.2.6 Architecture of the system .....................................................................57
4.2.6.1 Subsystem decomposition ...............................................................58
4.2.7 User interface (navigational phase and screen markups) ......................60
4.2.8 User interface design .............................................................................61
References
................................................................................................................64
List of figure Figure 1 use case diagram ................................................ Error! Bookmark not defined.
Figure 2 class diagram (conceptual modeling) ........................................................................................... 34
Figure 3 ER diagram.................................................................................................................................. 35
Figure 4 login sequence diagram ............................................................................................................... 40
Figure 5 Insured registration sequence diagram ......................................................................................... 41
Figure 6 update insured sequence diagram ................................................................................................ 42
Figure 7 Record payment sequence diagram ............................................................................................ 43
Figure 8 renew insurance sequence diagram ............................................................................................. 44
Figure 9 post notice sequence diagram ...................................................................................................... 45
Figure 10 generate report sequence diagram .............................................................................................. 46
Figure 11 delete insured sequence diagram ................................................................................................ 47
Figure 12 view accident sequence diagram ............................................................................................... 48
Figure 13 create account sequence diagram ............................................................................................... 49
Figure 14 login activity diagram................................................................................................................ 50
Figure 15 registration activity diagram ...................................................................................................... 51
Figure 16 update insured activity diagram ................................................................................................. 51
Figure 17 record payment activity diagram ................................................................................................ 51
Figure 18 generate report activity diagram ................................................................................................ 52
Figure 19 delete insured activity diagram................................................................................................... 52
Figure 20 view accident activity diagram ................................................................................................... 53
Figure 21 Create account activity diagram ................................................................................................. 53
Figure 22 post notice activity diagram ...................................................................................................... 54
Figure 23 login state chart diagram ........................................................................................................... 55

Page | 4
Figure 24 Register insured state chart diagram .......................................................................................... 56
Figure 25 Update insured state chart diagram ............................................................................................ 56
Figure 26 delete insured state chart diagram .............................................................................................. 57
Figure 27 post notice state chart diagram .................................................................................................. 57
Figure 28 Component diageram ................................................................................................................. 58
Figure 29 deployment diagram .................................................................................................................. 59
Figure 30 architecture of the system diagram ............................................................................................ 59
Figure 31 subsystem decomposition diagram ............................................................................................. 62
Figure 32 navigational phase and screen markups diagram ....................................................................... 63
Figure 33 home page user interface ........................................................................................................... 64
Figure 34 create account user interface ..................................................................................................... 65
Figure 35 login user interface ..................................................................................................................... 65
Figure 36 insured registration user interface .............................................................................................. 65
Figure 37 feedback user interface .............................................................................................................. 66

List of table
Table 1 cost estimation ................................................................................................................... 7
Table 2 project eschedule ................................................................................................................
8
Table 3 login use case description ...............................................................................................
20
Table 4 insured registration use case description ......................................................................... 21
Table 5 payment record use case description ............................................................................... 22
Table 6 update insured use case description .................................................................................
23
Table 7 generate report use case description ............................................................................... 24
Table 8 post notice use case description .......................................................................................
25
Table 9 delete insured use case description .................................................................................
26
Table 10 generate report use case description .............................................................................. 27
Table 11 renew insurance ............................................................................................................ 28
Table 12 create account ............................................................................................................... 29
Table 13 view accident ................................................................................................................ 30
Abbreviations

Page | 5
  CD---------------------- Compact Disk
 DVD---------------- digital versatile disk
 MS SQL------------------Microsoft structural query language
 MS word------------ -Microsoft Word
 NIC--------------------Network Interface Card
 OOSAD--------------- Object Oriented system analysis and Design

 PC------------------personal computer
 RAM------------------Random Access Memory
 UML------------------Unified Modeling Language
 Xampp-------------- cross-platform, Apache, MySQL, PHP and Perl

CHAPTER ONE
1. Introduction
Insurance system is one of the important organization in the world that are becoming more spread
from time to time. Insurance system is a system in which one makes agreement to pay money to a
company and the company pays back if an accident or injury happens to the members of the
organization. The one that pays money to the company is called insured and the one that pays back
if an accident or injury happens is insurer. In other words, insured pays money to insurer. The
insured receives a contract or insurance policy which details the conditions and circumstances
under which the insured will be financially compensated. Insurance involves pooling funds from
many insured entities to pay for the losses that some may incur. The insured entities are therefore
protected from risk for a fee, with the fee or premium being dependent upon the frequency and
severity of the event occurring on the members of the organization .There are different types of
insurances given by companies such as life insurance, health insurance, auto or vehicle insurance
etc. For example, in auto insurance it will typically cover both the property risk (damage or theft
to the vehicle) and liability risk legal claims arising from an accident.

Page | 6
 1.2 Statement of problem
Life Insurance have many problems because it perform its operations manually. Due to this
reason the institution face too many problems. More specific problems are listed as follows:

- To search data from the manually recorded take more time and difficult.
- Less availability.
- Less secure (data can be accessed by unauthorized users or agents).
- It require higher cost.
- Difficult to handle error and input data is not validated.
- Data duplication: the same data gets repeated over and over since the workers find
it hard to keep track of the documents, information and transactions
- Inconsistency of data: there will be unavailability for future use, since data might
get misplaced during manual filing. So data won’t be preserved properly for future
use.
- Files cannot be shared easily in the institution.

1.3 Objective of the project

1.3.1 General objective
To develop computerized (automated) ion Insurance System

1.3.2 Specific objective

Specific objectives are objectives that used to achieve specified general objective. The following
are specific objectives.

- Study the existing system and identifying the problems under the existing system.
- Requirement analysis of the existing system with respect to functional and nonfunctional
requirement.
- Design new system based on the requirement analysis of the existing system.
- Implementing the new system.

- Testing the system using different testing methodology.

Page | 7
 - Deploying the system the system after the system is tested.
- Maintain and update the system when needed.
1.4 Scope of the project
. The project is enable fast and available service for the insured of the Insurance.

1.4.1. In scope
- This project can do the following insurance types.
▪ insurance.
▪ Fire and lightning insurance.

1.4.2 .Out scope

- The project can’t do the following insurance types. ▪ Life insurance.
▪ Medical insurance.

1.4.3 Limitation of the project

Our project have the following limitations:-

- Shortage of data: there is no enough information about other insurance types. Because of
this we cannot include other types of insurance.
- Shortage of time: We have shortage of time to complete the project in one semester. This
enforces our project team to minimize the project scope.

1.5 Significance and beneficiary of the project

1.5.1 Significant of the project

➢ Reduced costs & time consumption.
➢ Speed up the operation ➢ Avoiding data loss.
➢ Increase security
➢ Add new knowledge.
➢ Increase competency
1.5.2 Target beneficiaries of the system
- The following bodies that will get benefit from the proposed system.

1.5.2 .1 Institution

Page | 8
 ➢ Speed up the business operation.
➢ Increase competency.
➢ Control customer’s records.

1.5.2 .2 Developer team

➢ Add new knowledge.
➢ Get problem solving skill.

1.5.2 .3 User of the system

➢ Save their time and Reduce workloads.
➢ Easily access customers’ information from organized database.
➢ Reduce data redundancy
➢ Reduce complexity

1.6 Methodology
1.6.1 Method of data collection
There are different methods of data collection methods. From those we used the following
methods respectively to collect data from the organization.

❖ Direct Observation: use this method to get the right information about the

organization and also understand by viewing how the existing system works.

Page | 9
 ❖ Interview: through interviewing the manager and another employee of the

organization and we get enough and reliable data which is important to do the project.
❖ Document analysis: we analyzing the manual resources of the organization how the
current system operates.

1.6.2 System development methodology

There are different types of software development methodologies from this we used:-

• Object oriented system analysis and design methodology: Is software development

methodology by building self-contained modules or objects. This methodology have the
following futures increased reusability, increased extensibility, proved quality, and
reduced maintenance burden and managed complexity .due to this we select OOSAD
methodology.
• Software development model: we use is iterative model because in iterative model you
can iterate back if error are occurs in one phase and we can return back to other phase to
fix errors at any phase of the project life cycle.

1.6.3 Development tool

1.6.3.1 Hardware tools required

Personal computer (PC): almost all tasks of our project are performed on
computer.

Flash disk: required for data movement to store & transfer data from one PC
to another PC.
Disks (CD, DVD): necessary for the movement, backup and recovery
mechanism of relevant data.

Paper and pen: for writing all necessary documentations associated with the
project.

1.6.3.2 Software tools required

Windows 8.1 Operating system: will be used for the system since it is readily

available in laboratories.

Page | 10
 Firefox, chrome browsers: -since our system is web based, it is very

necessary requirement.

Microsoft office Word 2013:-for documenting the corresponding deliverables

associated with the project

Edraw max 6.8: -for designing Unified Modeling Language (UML)

diagrams.

Xampp Server: - to test the system.

1.6.4 System evaluation procedure
There are different types of evaluation procedures used for testing a system. This evaluation are
relevant for is the system is go on the specified user requirement and perform all expected function
as well as to find the system gape. For our project we will use different evaluation procedures from
which.
Unit testing - individual components are tested independently. Components may be functions or
objects or coherent groupings of these entities. This used for testing each component of system
and best for finding system failure.
System testing -testing of the system as a whole. Testing of emergent properties is particularly
important.
1.7 Feasibility of the project
Feasibility study is used to investigate the proposed system in multiple dimensions. It is used to
indicate whether the system is feasible or not.

1.7.1 Technical feasibility

Technical feasibility is the measure of practicality of the specific technical support and the
availability of technical resources and expertise to use the system. The proposed system can be
easily maintained and repaired without requiring high Experts or technical supports, because the
system will be installed in adaptable technology’s and the employee of the organization have
some knowledge about technology by providing training and help how to use the system and can
use the system easily . So the system is technically feasible.

1.7.2. Economic feasibility

Page | 11
 Economic feasibility is the process of identifying the financial benefits and costs associated with
the project being developed. So the project is economically feasible because the project reduce
the cost of the resources. But Economic Feasibility is expressed as cost- benefit analysis.

Costs- our system use new technology and have centralized database cannot need more
resources. It require minimum amount of cost. The estimate cost of resources that we use to
Develop this project.
Types of costs Tool name Quantity Unit price (in Total price (in Birr)
Birr)
Hardware costs Computer 1 8000 8000
Flash(8 GB) 1 180 180
Paper 1 packet 100 100

Printing and binding 3(copies) 100 300

Software costs Xampp server 1 Free Free
Microsoft office 20013 1 Free Free
Notepad++ 1 Free Free
Windows 8.1 OS 1 Free Free
Requirement analysis 200
Total 10080

Table 1 cost estimation

1.7.3. Operational feasibility

The system perform all operations to achieve the specified objective, User friendly and
interactive with the environment and the system will perform all operation that the organization
runs. And it will not have any difficulty or procedures to perform the operation of the system.
So the project is operational feasible.

1.7. 4 Schedule feasibility

The system after development may give efficient and effective services in short period of time.
And also the tasks may be scheduled for effective use of the system. The project will be finish at
the schedule time. So the project is Schedule feasible

1.7.5 Political Feasibility

Page | 12
 The project built without violating rules and regulations of the governments as well as the
organization. The system being built is for the sake of service of the organization, so that the project
is legally feasible.

1.9. Project Schedule

Task name month oct2015 Nov2015 Dec2015 Jan2016 Feb201 Mar2016 Api2016 Jun2016
6
week 3 4 1 2 34 1 2 34 1 2 34 1 2 34 123 4 12 3 4 1 2
Project proposal

Requirement
analysis

Design
Implementation
Testing

Table 2 project schedule

1.10 Project team management

Each part of tasks of the project will be delivered by collaborating with each of the group
members. Each group members has their own responsibility to complete the project successfully.

1.11 Organization of the study

Our project study organized from project contents that performed in each chapter of the project
and the purpose of this to show activists and its sequences in each chapter. Activates are shown
below.

Chapter one: this chapter deals about identification of problems in the existing system by
gathering information from the organization.

Determine objective: based on the identified problem we design the general objective and
specific objective of the project to be achieved.
Page | 13
Determine Scope of the project: we set the project coverage area and what the project do with
three perspectives, in scope, out scope, limitation of the project.

Set methodology of the project: we determine the methodology that we are used for the project
this are, data collection method, development tools and evaluation procedures for our project.

Determine the feasibility of the project: we set project feasibility with different perspectives and
criteria. We determine technical feasibility, operation feasibility, economic feasibility, political
feasibility of the project.

Determine significance of the project: we describe the significance that the system provide after
finishing.

Chapter two: this chapter deals about description of the current system: we dealing about current
system and the strength of existing system as well as the weakness of the existing system .we
identify the business rule that the existing system follow. Next to this we set the expected
outcome of our project after finishing.

Chapter three: this chapter deals about we explain what the proposed system is and identify
functional requirement, nonfunctional requirement, hardware requirement and software that the
proposed system is to do. Determine security and safety procedures for our project.

Chapter four: this chapter deals about we define system analysis and design for our projects
using system designing model and we use UML modeling system. Designed our system with two
model these model. The first is system model in this model we define and design our project
scenarios, use case diagram, and use case description, class diagram, (EER) diagram and

normalization of table. Second we design our dynamic model of our system and
this includes sequence diagram, activity diagram, component diagram, and
deployment diagram, architecture of the system, subsystem decomposition, and
user interface of the project. This is our project organization study until chapter
four.

Page | 14
 CHAPTER TWO
2. Current system
2.1 Description of current system
Wolikite Branch Ethiopian Insurance in is one of the institution in Ethiopia. This institution
perform many operations and the aim is giving guarantees for the insured of the organization .the
organization have many types of insurance .The functions performed in the organization are
manage events occurred in the insured, renew information, and handle payment. The institution
revises its policies regularly and produces new policies based on the country’s current economic
development and the demand of customers. The organization have seven employees this
employees have its own responsibility and the institution provide insurance for objects insured
value is less than or equals to one million birr. The major property and liability insurance services
given by the institution are, fire and lighting insurance, money insurance, auto insurance.
2.2 Strength in the existing system
Even if the existing system have its own weakness it have its own strength. The following are the strength.

- The existing system is politically feasible.

- Organizational structure.
- Better for people who cannot get internet and computer access.
- Business rule of the existing system are good.
- More number of employee work on the existing system.

2.3 Weakness in the Existing system

The existing system have many problems .we classified the problem as follow.

➢ Inputs
✓ Data is not accurately captured if it contains errors.
✓ Input data is not validated.
➢ Outputs
✓ Sometimes lack necessary and relevant information.
✓ Sometimes Information is not in a useful format.
✓ Information is not timely to its subsequent use.
➢ Stored Data
✓ Data is not flexible –not easy to meet new information needs from stored data.
✓ Data is not accessible easily.

Page | 15
➢ Costs (Budget of the office)
✓ Stationary cost is increasing.
➢ Service
✓ The existing system is not that easy and it is uncomfortable to use.
✓ The system is not easy to coordinate.
➢ Security and Controls
✓ Input data is not adequately edited.
✓ Ethics are branched on data or information – refers to data or information getting to unauthorized
people.
✓ Redundantly stored data is inconsistent in different files.
✓ Data privacy regulations or guidelines can be violated.
✓ Processing errors are occurring by people.
➢ Efficiency
Performance (Response time): the response time is less.
2.4 Business rules
-Business rules that the existing system follow.

BR1: New insured fill the registration form correctly and fill all the required information.

BR2: The insured renew annually their policy and the not renew the insurance the insurer exclude
the insured from the insurance and not accountable if any accident face. .

BR3: The insured register its object.

BR4: Insured pay the premium value of the object and insured not pay this not approved or not provide
any service from the insurer until the premium value played.

BR5: Insured must report accident immediately.

BR6: Insured who cannot renew his insurance policy is dismissed from the insurer.

BR7: Insurer check accidents of insured: the insurer immediately check the accident and provide needed
support to the insurer.

BR8: Insurer pay the value of object when accident is happen.

BR9: Insurer notify insured to renew their policy.

2.5 Expected outcome of the project

Page | 16
The outcome of this project is generate good web based system that perform all expected Functions
with minimum resource, time and higher performance.

2.6Alternative solution

As we justifies above that the existing system have many problems. So the alternative solution to
reduce this problem replace the existing manual system to web based system this is the alternative
solution that we take to improve the existing system.

CHAPTER THREE
3. Proposed system
3.1 Overview of the proposed system
The existing system has its own problem and drawbacks. So that, the project team tries to develop
a system which is better than the existing system in terms of time and cost efficiency. The team
tire to make the existing system that improve system performance .The proposed system is
capable of provides high security of data, capability of organizing all information in a single
client-server system, easy way of recording and accessing items information by its well organized

Page | 17
user-friendly interface. Generally the proposed system will improve the performance of the
existing system and reduce this problems, time wastage, Bring data security, data inconsistency,
Poor quality service delivery, and reduces wastage of paper.

3.2 Functional requirements

Functional requirements drive the application architecture of a system. Functional requirements are
the intended behaviors of the system. This behavior may be expressed as services, tasks or
functions that the system is required to perform. The functional requirements that the proposed
system Perform.

- Registration of the new insured

- Payment management
- Generating report
- Delete report
- View report
- Post notice
- Delete notice
- Renew insurance
- Update insured
- Manage accidents.
- View notice - Manage accounts.
- Manage accidents.
3.3 Nonfunctional requirements

Non-functional requirement is a requirement that describes about how the system will do the
functional requirements. It describes performance, maintainability, security, usability,
availability, accuracy, and reliability of proposed system.

Performance: The proposed system perform its operations within a minimum amount of time and the
user gets the expected result within a few seconds and the system is effective.
Accessibility: The system can be accessible based on the accessible privilege or based on autontication.
Accuracy: proposed system will reduce error because all operation can be check correctly and validate
that whatever information is coming from the data base and input to the database.
Maintenance: our system can be easy maintainable and updateable, if the system get any failure.

Page | 18
Extensibility: - Adding features and carry-forward of customizations at next major version upgrade
along with the business re-engineering is possible.
Backup and recovery: to reduce data loss and other risks there shall be a frequent and full back up
mechanism to avoid any information loss and inconsistency using copy of the system to restore
when hard ware and software failure occur.
Resource: the proposed system cannot use more resources as current system because it have centralized
data base management system.

3.4 Hardware Requirement

-The hardware requirement that we use for developing this project are. o
Personal computer (PC).
o Intel(R) core™i3, CPU 2GHz and more than this is possible.
o RAM: 2GB and above possible.
o Disks (CD, DVD) drivers. o 250GB Hard-disk and above. o Printer: required for printing the
documents of the project.

3.5 Software Requirement

The software requirement that we use for developing this project are. o
32 or 64 bit Windows 8.1 Operating system

o Firefox, chrome browsers: -since our system is web based, it is very necessary requirement and it

use for front end.

o Microsoft office Word 2013:-for documenting the corresponding deliverables associated with the
project

o Edraw max 6.8: -for designing Unified Modeling Language (UML) diagrams.

o Xampp Server: - To test the system will be running.

3.6. Security and Safety Procedure

3.6.1 Security Procedure
In order to make the system secure from an authorized access and modification, the system uses a
login account to differentiate among the different users of the system on the organization side.
This enables the system to verify who has logged in using the correct logging account provided
and display the right form associated with that user. The security service provided by the system
will maintain the security, confidentiality and integrity of the system. Users will have their own

Page | 19
autontication based on user name and password. Through which they could gain access to the
system.
3.6.2 Safety Procedure
To make our project safer from different risks and attacks we use different safety mechanism .so the
following safety mechanism.
We use backup for our project files using External Hard Disk and Flash Disk, if suddenly the computer
that contain the file is damaged.
We duplicate the same folder that contains our project into many folder in different drives. We
use antivirus that protect from attacks

CHAPTER FOUR
4. System Analysis and designing
4.1 System models
4.1.1Scenarios
-The following are describe scenario of how the user use the systems to perform operations.

Scenario name: login

Participant actor Mr. Taddess

Mr. Taddess as user if he wants to login to the system first run the system then the system display
home page next Mr. Taddess click login link from home page. After that the system display
login form then Mr. Taddess fill login form and click login button and home page is display
next Mr. Taddess perform his authenticated operation and logout.

Scenario name: insured registration

Participant actor Mr. Edalew, Mr. Demeke.

Mr. Edalew as insured and Mr. Demeke as operation officer participate in the registration
process. To register for the first time. First run the system and click registration link in the
system home page, the system display the registration form then fill correctly and click
registration button if the data is incorrect the system display error message else registration is
success.
Page | 20
 4.1 .2 Use case diagram
Use Cases: A use case is an interaction between users and a system. What operation the user do in
the system. Use case diagrams are used for capturing functional requirements of the system.It is
the functionality of the system or the service provided by the system. The following show list of
use case and who can interact with the use case (actors).

Use Case Interact

Register insured Insured, operation officer

Login Admin ,Insured, operation officer, casher
Delete insured operation officer
update insured operation officer
Generate report Casher
Post notice Operation officer

Login Insured, casher, admin, Operation officer

Renew insurance Insured
Delete notice Operation officer
Report accident Insured
Register payment Casher
Update payment Casher
View accident Admin
Create account Admin
Delete account Admin
Update account Operation officer, admin, insured and casher
View notice Insured
Delete notice Operation officer

Page | 21
Figure 1 use case diagram

4.1.3 Use Case Description

It describes use case diagram and it contain use case Id, use case name, use case description, basic
course of action, alternative solution.

Page | 22
Use Case Id UC 01

Use case name Login

Description Allow the user enter to the system and perform operation in the system

Actor Admin, casher, and insured, operation officer.

Pre-condition The user must have valid username and password in the system

Basic course of action Actor Action System response

step1.the user click the login link step 2.the system display the login form
that contains user name and password Step
Step 3. The user fill the valid user
name and password. 4. the system verify user name and
password
Step 5. the system display user page step
6.usecase end

Alternative course action If user name and password incorrect

A.1 The system display invalid user name and password.
A.2 The user back to step 3 of basic course of action.
Post condition The login success and go to user page.

Table 3 login use case description

Use Case Id UC02

Use case name Register Insured

Page | 23
Description The insured register his/her information to become member of the institution (insurer)
to get service.

Actor Insured, operation officer

Basic course of action Actor Action System Response

Step 1. The insured or operation Officer Step 2. The system display the registration
click the register link. page.
Step 3. The insured or operation officer Step 4.The system validate the form input
fill the form and submit. Step 5. The system store the information
and display successful message.
Step 6. Use case end.

Alternative course If the form in puts are incorrect

action A.1 the system display error message.
A.2 The insured or operation officer back to step 3 of basic course of action.

Post condition The insured is register successfully.

Table 4 insured registration use case description

Use Case Id UC03

Use Case Name Payment Record

Description The insured pay the premium value of the object for the insurer.

Page | 24
 Actor Casher.

Pre-condition The insured is recorded in the data base.

Basic course of Actor Action System response

action
Step 1. Casher login to the system. Step 2. The system display home
page.
Step 3. The casher click pay link
step 4 the system display pay form
step.5 casher fill the form Step 6. the system verify the form step
7.the system add the information in to
Database.
step 8.Use case end

Alternative course If payment form input is incorrect

action A.1 The system informs the casher to reenter the input form.
A.2 The casher back step 5 of basic course of action.
Post condition The payment is success and the insured is approved.

Table 5 payment record use case description

Use case Id UC04

Use case name Update Insured

Description Allow the operation officers to update the information of insured.

Actor Operation officer.

Pre-condition The information is available in the data base.

Page | 25
 Basic course of action Actor Action System response

Step1.the operation officer login Step 2.the system display home page
to the system. step4. the system display update form
Step 6 the system display the
Step 3. Operation officer click
information
on update link.
Step 8. The system store update
Step 5. Search the update information to the data base.
information using ID step 9.usecase end
Step7. Fill the update data and
submit.

Alternative course If the update information is not found

action A.1 The system display error message
A.2 The operation officer back to step 5 of basic course of action.
Post condition The information is updated.

Table 6 update insured use case description

Use Case Id UC05

Use case Name Generate Report
Description Generating of report for the administrator how many insured are pay their
premium value and insured report accidents when occurred.

Actor Casher, insured

Precondition Request report from the administrator.

Basic course of action Actor Action System response

Page | 26
 Step 1.The casher and insured login Step 2.The system display the home page
to the system Step 4.The system display the form
Step 3. The casher and insured Step 6. display successful message Step
click the report link. Step 5. fill the 7. End of use case.
form and click submit

Post condition Report is generated successfully.

Table 7 generate report use case description

Use Case Id UC06

Use case Name Post Notice

Description Post notifications for the insured to provide information from the insurer.

Actor Operation officer

Pre-condition The operation officer have notice to be post.

Basic course of action Actor Action System response

Page | 27
 Step 1.the Operation officer login to the Step 2.the system display home
system. page of the system
Step 4. the system display page
Step 3. The Operation officer click post link.
Step 6. The system upload the file
Step 5 the Operation officer fill the upload and return success message.
file
Step 7.Use case end

Post condition Post is success.

Table 8 post notice use case description

Use Case Id UC07

Use Case Name Delete insured

Description It Allows operation officer delete insured if the insurance is finished.

Actor operation officer
Pre-condition The insured is stored in the data base
Actor action System response

Page | 28
Basic course of
action: Step1.the operation officer login to the Step2.The system displays the home page
system
Step3.The operation officer click the delete Step4.The system display delete form
link Step6.The system deleted the insured from
Step5.the operation officer fill the delete database.
form Step7. The system displays confirm message.
Step8. The use case ends
Alternative course If the selected insured is not available.
action A.1. The system displays error message.
A.2. Go to step5 to select the insured again.

Post condition The insured is deleted from the database and not member of insurance

Table 9 delete insured use case description

Use Case Id UC 08

Use Case Name Report Accident

Description The insured can report the accident after the accident is takes place on his/her
Owen insurance type object occurs.

Page | 29
 Actor Insured

Pre-condition The insured is member of the insurer.

Basic course of action Actor action System response

Step1. the insured login to the Step 2. the system display the home page
system Step 4. the system display the form
Step3. Click the report Step 6. the system save to the database and
accident link. display the successful message
Step 5. the insured fill the form Step 7.use case end
and submit

Post condition The report is generated. And view by authorized user

Table 10 generate report use case description

Use Case ID UC09

Use case Name Renew Insurance

Description The insured will renewed his/her insurance with in interval of time.
Actor Operation officer

Page | 30
Pre-condition The insured pay the annual premium value of their object value
Basic course of Actor action System response
action

Step 1. the Operation officer Step 2. The system display the homepage
login to system Step 4. the system display the form
Step 3.the Operation officer Step 5. the system save to the database and display
click the renewed link the successful message Step 7.use case end

Step 6 .the Operation officer fill

and submit

Alternative course If the renewed input data is not correct.

action A.1 The system informs the operation officer to reenter the correct data.
A.2 Operation officer back step 6 of basic course of action.
Post condition the insurance of the insured is renewed

Table 11 renew insurance

Use Case Id UC010

Use Case Name Create Account

Description It describes the process of creating a new account for the user.

Actor Administrator

Pre-Condition Administrator login to the system.

Page | 31
 Basic course of action Actor Action System Response
Step 1. The Administrator click Step 2. The system displays the
create account link. registration form.
Step 3. Administrator fill the Step 4.System validate entered data.
registration form and submit. Step5. The system save in to data base
display success message.
Step 6. Use case end.

Alternative Action If the input data is not correct.

A.1 the system notify invalid input message.
A.2 the administrator back to step 3 of basic course of action.
Post condition Account is created successfully.
Table 12 create account

Use Case Id UC011

Use Case Name View Accident

Description Administrator can view accident occurred in different time as needed.

Actor Administrator

Pre-condition Accidents must store in database.

Page | 32
 Basic course of action Actor Action System Response
Step. The administrator login to the Step 2.The system display the
system. homepage
Step 3.the Administrator Clicks Step 4.The system display all
the view link. accidents
Step 5. use case end
Post condition The Administrator view the accident on time.

Table 13 view accident

4.1.4 Class diagram (conceptual modeling)

Page | 33
Figure 2 class diagram (conceptual modeling)

4.1.5 ER (EER) diagram (conceptual modeling)

Page | 34
Figure 3 ER diagram

4.1.5.1 Normalized table (3rd)

Tables
Insurance

Page | 35
 Insurance type Description
Insured
Client ID Name Sex Address Contact person Insurance type
Object
Object Id Object Name Object type Insured value Year

Payment
Payment id Amount Date
Accident
Accident Id Type Reason Location Date

Policy
Policy No Branch Address Premium value

Report
Report Id Report type Description Date

1st normal form for the above table

- Eliminating multivalued attribute
- Identify primary key attribute
Insurance
Insurance type Description

Insured

Object
Object Id Object Name Object type Insured value Year

Accident
Accident Id Type Reason Location Date
Policy

Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type
Policy No Branch country Region zone city Keble Premium value

Page | 36
 Report
Report Id Report type Description Date
2nd normal form
- Avoid partial dependency
Insurance
Insurance type Description

Insured

Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type
Object
Object Id Object Name Object type Insured value Year

Accident
Accident Id Type Reason Location Date
Policy

Policy Branch country Region zone Policy

city NoKeblePremium value
No

Report

Client First Last sex Contact person country Region zone city Keble Mobile Insurance
ID name name number type
Report Id Report type Description Date
3rd normal form

- Avoid transitive property Insurance

Insurance type Description

Insured

Object

Object Id Object Name Object type Yeartype

Object Insured value

Page | 37
 Accident
Accident Id Type Reason Location Date

Policy

Policy No Branch country Region zone Policy

city NoKeble
Premium value

Report
Report Id Report type Description Date

Foreign key primary key relationship (Mapping table)

Insurance

Page | 38
 Report
Report Id Report type Description Date

4.2 Dynamic model

4.2.1 Sequence diagram
Sequence diagram showing the sequence of interactions among objects and used to represent or
model the flow of messages, events and actions between the objects or components of a system.
Sequence Diagrams are also used primarily to design, document and validate the architecture and

Page | 39
interfaces of the system by describing the sequence of actions that need to be performed to complete
a task or scenario.

Figure 4 login sequence diagram

Page | 40
Figure 5 Insured registration sequence diagram

Page | 41
Figure 6 update insured sequence diagram

Page | 42
Figure 7 Record payment sequence diagram

Page | 43
Figure 8 renew insurance sequence diagram

Page | 44
Figure 9 post notice sequence diagram

Page | 45
Figure 10 generate report sequence diagram

Page | 46
Figure 11 delete insured sequence diagram

Page | 47
Figure 12 view accident sequence diagram

Page | 48
Figure 13 create account sequence diagram

4.2.2 Activity Diagram

Page | 49
Figure 14 login activity diagram

Page | 50
Figure 15 registration activity diagram

Figure 16 update insured activity diagram

Figure 17 record payment activity diagram

Page | 51
Figure 18 generate report activity diagram

Figure 19 delete insured activity diagram

Page | 52
Figure 20 view accident activity diagram

Figure 21 Create account activity diagram

Page | 53
Figure 22 post notice activity diagram

4.2.3 State chart diagram

Page | 54
Figure 23 login state chart diagram

Page | 55
Figure 24 Register insured state chart diagram

Figure 25 Update insured state chart diagram

Page | 56
Figure 26 delete insured state chart diagram

Figure 27 post notice state chart diagram

4.2.4 Component Modeling

In this modeling components of the system will be wired showing that there is relation among components,
this in some extent shows which components or objects will be accessed by whom.

Page | 57
Figure 28 Component diageram

4.2.5 Deployment modeling

Deployment modeling used to show the hardware of the system, the software that is installed in the
hardware and also the middleware that is used to connect the different machines to one and other.
It also shows how the software and the hardware components work together.

Page | 58
Figure 29 deployment diagram

4.2.6 Architecture of the system

Figure 30 architecture of the system diagram

Page | 59
4.2.6.1 Subsystem decomposition
Subsystem decompositions will help reduce the complexity of the system. The sub systems that we
take the classes that our system contain and the operation performed in the class. The following
are sub systems

• Insured management sub system: this subsystem used for managing insured information and have
the following operations.
 Register new insured
 Delete insured  Update insured
 Approved insured
 View insured
• Report management sub system: This subsystem allows for managing information and perform
this operation.
 Generate report
 Approve report
 Delete report
 View report
• Manage account subsystem: in this subsystem managing of information regard to account and
perform.
 Create account
 Delete account
 Update account

Page | 60
• Payment management sub system: in this sub system manage information of payments and
perform.
 Record payment
 Calculate payment
 Update payment
• Accident management sub system: this sub system holds information of accidents.
 Register accident
 View accident

• Notice Managing sub system: this sub system handles information of notice and perform.
 Post notice
 View notice
 Delete notice
• Database Connection Subsystem: this subsystem used for established connection between
business class and database management system.
• Insurance management subsystem: this sub system handles information of insurance and
perform.
 Add insurance
 View insurance
 Delete insurance

Page | 61
Figure 31 subsystem decomposition diagram

4.2.7 User interface (navigational phase and screen markups)

Page | 62
Figure 32 navigational phase and screen markups diagram

4.2.8 User interface design

Page | 63
Figure 33 home page user interface

Page | 64
Figure 34 create account user interface

Figure 35 login user interface

Figure 36 insured registration user interface

Page | 65
Figure 37 feedback user interface

References
[1] C. Curescu, Object Oriented Analysis and Design andSoftware Development Process, England: Addison-
Wesley., 2006.

Page | 66
[2] D. Bell, "futhers," IBM, 04 septamber 2003. [Online]. Available: http://www.uml.org. [Accessed 06 january
2008].

[3] S. L. John Wiley, Object-Oriented Analysis and Design, England: London W1T 4LP, 1998.

[4] O. M. Group, "Tutorialspoint," January 1997. [Online]. Available: http://www.tutorialspoint.com/uml.

[Accessed 10 january 2008].

[5] Mr.Ahmmed, Interviewee, Current system operation and problems. [Interview]. 20 october 2008.

Page | 67