THE COPPERBELT UNIVERSITY

SCHOOL OF INFORMATION AND COMMUNICATION

TECHNOLOGY

GROUP 3 MEMBERS

MUSONDA NGALANDE (19133342) – COMPUTER SCIENCE

MOONGA KACHINDA (19134103) – COMPUTER ENGINEERING

CHUMA MHANGO (19135090) – COMPUTER ENGINEERING

NIZA SIKAPIZYE (19133298) – COMPUTER SCIENCE

JOHN PUPWE (19134786) – COMPUTER SCIENCE

SYSTEM: POLICY INSURANCE SYSTEM

COURSE: CS 230 – SOFTWARE ENGINEERING

DUE DATE: 15TH MARCH, 2021

LECTURER: DR. MUFUNGULWA G.

i
 DOCUMENT INTRODUCTION
This document focuses on a Policy Insurance Management System. It contains
three parts; Part 1: the Project Proposal, part 2: the Requirements Analysis and part
3: the Software Requirements Specifications Document.

ii
Contents
DOCUMENT INTRODUCTION ......................................................................................... ii
PART ONE: PROJECT PROPOSAL ...................................................................................1
INTRODUCTION .............................................................................................................2
PROBLEM STATEMENT ...............................................................................................2
AIM AND OBECTIVES ...................................................................................................3
PROPOSED SYSTEM ......................................................................................................4
SCOPE OF STUDY ..........................................................................................................4
RATIONALE/MOTIVATION OF STUDY .....................................................................5
PART TWO: REQUIREMENTS ANALYSIS .....................................................................7
INTRODUCTION .............................................................................................................8
A USE CASE DIAGRAM ............................................................................................8
B USE CASE SCENARIOS .........................................................................................8
PART THREE: SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT ..........19
INTRODUCTION ...........................................................................................................20
Purpose ........................................................................................................................20
Document Conventions ...............................................................................................20
Intended Audience and Reading Suggestions .............................................................20
Product Scope ..............................................................................................................21
REFERENCES ....................................................................................................................21
OVERALL DESCRIPTION ...........................................................................................22
Product Perspective .....................................................................................................22
Product Functions ........................................................................................................23
User Classes and Characteristics .................................................................................24
Operating Environment ...............................................................................................25
Design and Implementation Constraints......................................................................26
User Documentation ....................................................................................................26
Assumptions and Dependencies ...................................................................................26
EXTERNAL INTERFACE REQUIREMENTS .............................................................27
User Interfaces .............................................................................................................27
Hardware Interfaces.....................................................................................................28
Software Interfaces ......................................................................................................29
Communications Interfaces .........................................................................................29
OTHER NONFUNCTIONAL REQUIREMENTS .........................................................30
Performance Requirements .........................................................................................30

iii
 Safety Requirements....................................................................................................30
Security Requirements.................................................................................................30
Software Quality Attributes .........................................................................................31
Business Rules.................................................................................................................31

iv
PART ONE: PROJECT PROPOSAL

1
 INTRODUCTION
Policy Insurance Systems are systems that are used to keep and manage all records
related to the insurance policies that an insurance company provides. It includes
managing of details of the types of policy insurance offered, policy holders, and all
other information related to the policy insurance. This is important for tracking the
details of all policy insurances and making sure all changes and/or updates are
audited for transparency and effective management.

Policy Insurance processes basically include activities such as, among others,
payment of premiums, demanding of claims by Policy Holder, updating policy
details, updating policy holder account details, creating of policy holder profiles,
etc. It is crucial for Insurance companies that all these activities are done in a
proper and secure manner. In addition, Insurance companies also need to put high
priority to customer satisfaction as the customers are one of the most important
stakeholders.

The automation of such a system has proven to give significant benefits to those
implementing it. With the recent advancements made by many developing
countries to embrace digitalization, the implementation has become even a lot
easier to undertake due to less constraint from old organizational policies.
Therefore, this gives a better opportunity for Insurance company to enjoy the
benefits that come with using an automated system for their significant activities.

The system proposed in this document offers the services needed by an insurance
company by providing an online platform that automates the several activities that
are involved in policy insurance processes and aims at making these processes as
efficient and secure as possible.

PROBLEM STATEMENT
In the current situation, the policy insurance companies use a manual way of
keeping and managing their records. All related activities are also manual. For
example, if a Policy Holder needs to demand a claim or change details about their

2
account at the company, or if they have to pay their premium, they have to go to
the Insurance company to have all this done for them. This means that if there are
several customers doing these activities on a particular day, they have to wait as
others are attended to. This wastes time which is a valuable resource that can be
allocated to other activities to increase overall productivity.

Furthermore, the current system poses many more issues such as wastage of
physical space used up by the paper records, lack of ease of access to these records
and also risk of losing this information in case of a disaster such as fire or a
security breach or just misplacement of the files while manually handling them.

Another issue is the need for backing up these records in the most efficient way
possible. With the manual paper-based system, backing up each and every record
means using up more physical space and consumption of a significant amount of
time.

All these issues mentioned above show how inefficient and unsecure the manual
system is. However, all these are problems that an automated system can solve. By
having all records stored and managed at a logical, centralized and secure location
(a database) in virtual form away from the working environment of the users, the
efficiency and security of the Management system is improved significantly. A
system such as this also helps improve issues such as time consumption as many
activities are automated; this includes payment of premium, creating and
management of customer accounts, etc. These activities, when automated, save a
lot of time by removing the need of physical interaction between the customer and
Insurance company agents.

AIM AND OBECTIVES

The basic aim of this system is to provide a more efficient and secure way for
insurance companies to manage their policy insurance records and activities. It
looks to automate many processes in order to curb the problems stated in the

3
problem statement above. To accomplish this, the system is set with the following
objective:

1. Provide a secure and easily accessible place for storing all information
2. Provide an easy-to-use interface for the customer to view and manage their
account and profile
3. To provide a backup for all records to ensure availability of information at
all times
4. To provide an interface for Insurance company to create and manage
accounts without physically engaging with the customers
5. To provide a secure way of accessing details of accounts of Policy Holders.
6. To provide a way for customer/Policy Holders to pay their premium and
demand their claims
7. To provide an easy way for customers/Policy Holders to lodge complaints

PROPOSED SYSTEM
The proposed system is the Online Policy Insurance Management System.

This is going to be an online web-application which will allow for users to securely
login to the system to access all the services that the system automates and then
logout when they are done.

SCOPE OF STUDY
This project will be a web-based system for a Vehicle Policy Insurance Company.
It will provide fast and available services for the Policy Holders, Agents and
Administrator users of the system.

In the scope of the system, it will include the following:

4
- It will encompass Vehicle Policy Insurance. Other types of insurances are
therefore, out of scope of this project.

- The system will only be limited to already existing Policy Holders of the
System. Ability to self-register will therefore, be out of scope of the system (New
Policy Holders will be register at the insurance company in person and then added
to the system thereafter)

Limitation that led to the narrowing of the scope include:

- Limited time schedule for the project did not allow for a broader scope

- Insufficient data/information to support a broader scope. The project

members did not have enough data about other insurance types and therefore,
limited it to one type.

The benefits that the system brings forth primarily include the following:

- More secure way of storing information

- Reduced cost and time consumption

- Speed up in operational times

- Improved transparency

- Reduces the risk of data loss

- Relieves physical space used by paper records

- Staff gains new technological knowledge

See also (Ahmed, 2016) for scope on similar project.

RATIONALE/MOTIVATION OF STUDY
The motivation of undertaking this study came from the realization of how much
time and funds were spend on maintaining the manual system. The researchers
understood that the implementation of such a system would alleviate problems that
insurance companies using the manual system face. In addition to this, the

5
researchers were motivated by the global movement towards digitalization and
therefore wanted to be part of the movement.

Another motivation came from the realization of how much income they could
generate by building such a system that can be used by many Insurance companies.

6
PART TWO: REQUIREMENTS
ANALYSIS

7
 INTRODUCTION
This chapter looks at the Requirements Analysis of the project. In particular, it
focuses more on the use cases and use case scenarios of each use case. As such it
also includes the use case diagram of the system.

A USE CASE DIAGRAM

B USE CASE SCENARIOS

1. Login

8
 1.1 Introduction:

This use case describes how a user logs into the Insurance Policy System.

1.2 Actors: (i) Policy Holder

(ii) Agent
(iii) Administrator
1.3 Pre-conditions: None
1.4 Post-conditions: The use case is successful if the actor is logged into the
system, if not the system state is unchanged.
1.5 Basic flow: This use case begins when the actor wants to login to the
Insurance Policy System.
i. System requests that the actor enter his/her username and password.
ii. The actor enters his username and password.
iii. System authenticates the username and password, and is if the correct
allows the actor to log into the system.
1.6 Alternate flows:
1.6.1 Invalid username and password
If the actor enters an invalid username and/or password, the system
displays an error message. The actor can choose to either return to the
beginning of the basic flow, click forgot password or cancel the login, at
that point the use case ends.
1.7 Special Requirements: None
1.8 Use case relationships: None

2. Register new Policy Holder

2.1 Introduction: This use case allows the creation of an account for a person
to register for policy with the company by adding all of his/her
information.
2.2 Actors: (i) Agent
(ii) Administrator
2.3 Pre-conditions: Actor must be logged in to the system.
2.4 Post-conditions: The new member must have their information entered
and their new P.H account created successfully.
2.5 Basic flow: The use case begins when the actor wants to create a new
Policy holder account.
i. The actor selects register new insurance policy account.

9
 ii. The system displays the registration page.
iii. The actor inputs the new member’s information.
iv. The system validates the form input,
v. The system stores the information and display successful message.
2.6 Alternate flows:
2.6.1 Wrong information is entered
If the actor enters incorrect information for example payment account
details, the system will display an error message and the actor may correct
the information or cancel the operation, at that point the use case ends.
2.7 Special Requirements: None
2.8 Use case relationships: None
3. Process cash payment
3.1 Introduction: This use case allows the policy holder to pay the premium in
cash directly to the agent.
3.2 Actors: Agent
3.3 Pre-conditions: Agent must be logged in the system and the Policy holder
must be recorded in the system.
3.4 Post-conditions: The payment is successful and the record is updated.
3.5 Basic flow: The use case starts when the policy holder wants to pay the
premium directly in cash to the agent.
i. The agent selects process cash payment.
ii. The agent enters the policy holder’s information.
iii. After the payment is recorded, an update is made to the policy
holder’s account.
3.6 Alternate flows:
3.6.1 Policy Holder not found
If in the basic flow, the information of the policy holder is not found, the
system displays an error message and the agent may enter other
information or terminate the process. At this point the use case ends.
3.7 Special Requirements: None
3.8 Use case relationships: None
4. Manage existing member account
4.1 Introduction: This use case allows the actor to maintain details in the
account of an already existing P.H. This includes editing account details,
changing policy and adding new vehicle to policy.
4.2 Actors: (i) Agent

10
 (ii) Policy holder
4.3 Pre-conditions: Actor must be logged in to the system and Policy Holder
account opened.
4.4 Post-conditions: If the use case is successful, account information is
edited, policy is changed or a new vehicle is added to the policy.
Otherwise, the system state remains unchanged.
4.5 Basic flow: Starts when the actor wishes to edit account information/
change policy/ add new vehicle to policy.
i. The actor opens account details and specifies the function they
want to perform (edit account information/ change policy/ add
new vehicle to policy).
ii. One of the sub flows will execute after the actor selects the option.
▪ If actor selects “update account information”, “update account
information” sub flow will be executed.
▪ If actor selects “change policy”, “change policy” sub flow will be
executed.
▪ If actor selects “add new vehicle”, “add new vehicle” information
sub flow will be executed.

4.5.1 Update account information

i. The system displays the Policy Holder’s account information

ii. The actor selects the information they wish to modify and enters
the new details
iii. The system saves the new information to the database and
displays successful message and at that point the use case ends

4.5.2 Change policy

i. The actor selects policy details and the system displays the
policies the Policy Holder is subscribed to
ii. The actor selects change policy and the system displays the
available policy that can be subscribed to
iii. The actor selects the policy they wish to subscribe to and the
system prompts the actor to confirm policy change.
iv. The actor confirms the change and the system updates the change.
v. A successful message is displayed and the use case ends.

11
 4.5.3 Add new vehicle

i. The actor selects policy details and the vehicles the policy
currently insures.
ii. The actor selects add new vehicle.
iii. The system displays the vehicle form and prompts the actor to
enter the new vehicle information.
iv. The vehicle information is verified and the system updates the
new vehicle to the policy.
v. A successful message is displayed and the use case ends
4.6 Alternate flows:
4.6.1 Update cancelled
If in the update information sub flow, the actor decides not to edit the
information, the update is cancelled and the basic flow maybe restarted or
stopped with the information remaining unchanged at this point the use
case ends.
4.6.2 Premium payment not made
If in the add new vehicle and change policy sub flow the premium has not
been paid, the system will prompt the actor to make payment first before
changes can be made and the actor may begin the premium payment basic
flow or cancel the operation and at this point the use case ends.
4.6.3 Policy does not support
If in the add new vehicle sub flow, the current policy does not support
adding new vehicles the system will display an error message and the
actor maybe prompted to start the change policy sub flow.
4.7 Special Requirements: None
4.8 Use case relationships: None
5. Manage online payment
5.1 Introduction: This use case allows the policy holder to pay the premium
online either automatically or manually.
5.2 Actors: Policy Holder
5.3 Pre-conditions: Agent must be logged in the system and the Policy holder
must have opened their payment options.
5.4 Post-conditions: The payment is successful and the record is updated.
5.5 Basic flow: The use case starts when the policy holder wants to manage
their online payment by setting up automatic deduction or make manual
payments online.

12
 i. The Policy Holder opens payment options and selects set up
automatic deduction or make manual payments online.
ii. One of the sub flows will execute after the actor selects the option.
▪ If actor selects “set up automatic deduction”, “automatic
deduction” sub flow will be executed.
▪ If actor selects “make online manual payment”, “online manual
payment” sub flow will be executed.

5.5.1 Set up automatic deduction

i. The system prompts the user to give out the back account details.
ii. The Policy Holder fills in the information and the system verifies
the information with the bank system.
iii. The system deducts money from the account at the set up date and
notifies the user of the payment made.
iv. The payment is updated in the database and the use case ends
here.

5.5.2 Manual online payment

i. The Policy Holder selects make payment and the system display
the payment form
ii. The Policy Holder fills in the form with the prompted bank
account information and the system prompts the user to confirm
payment
iii. The Policy Holder confirms payment and the system verifies the
information
iv. The payment is recorded in the database and a successful message
is displayed and at this point the use case ends
5.6 Alternate flows:
5.6.1 Cannot verify bank account information
If in both the sub flows the bank account information cannot be verified,
an error message is displayed. The Policy Holder may enter different information
or cancel the operation and the use case ends here.
5.6.2 Insufficient funds in bank account
If in both the sub flows the bank account does not have enough funds for
the premium payment the Policy Holder is notified and the system may

13
 wait until money is made available in the bank account and then the two
sub flows maybe restarted. At this point the use case ends.
5.6.1 Cancel automatic deduction
If in both the automatic deduction sub flow, the Policy Holder wishes to
not to have automatic deduction, the payment method is modified and
he/she may begin the manual online payment sub flow and the use case
ends.
5.7 Special Requirements: None
5.8 Use case relationships: None
6. Manage all user accounts

6.1 Introduction: This use case allows the Administrator to maintain all user
accounts. This includes adding/ updating/ deleting user accounts.
6.2 Actors: Administrator
6.3 Pre-conditions: Administrator must be logged into the system.
6.4 Post-conditions: If the use case is successful a user account is
added/updated/ deleted from the system. Otherwise, the system state is
unchanged.
6.5 Basic flow: The use case starts when the Administrator wishes to add/
update/ delete a user account.
i. The administrator requests to view all user accounts and the
system displays the user accounts on the system.
ii. The administrator specifies the function to be performed either
add/update/ delete user account.
iii. The system will execute one of the sub flows after getting the
information.
▪ If Administrator selects “add new user account”, the “add
new user account” sub flow will be executed.
▪ If Administrator selects “update user account”, the “add new
user account” sub flow will be executed
▪ If Administrator selects “update user account”, the “add new
user account” sub flow will be executed.

6.5.1 Add new user account

i. The administrator selects the account type (Agent/ Policy Holder)

14
 ii. The system requests the administrator to input the required
information depending on account type
iii. The administrator inputs the information and the system prompts
the administrator to confirm the given information
iv. The administrator confirms the information and a successful
message is displayed.
v. System records the new account information and the use case
ends.

6.5.2 Update user account

i. The administrator searches for the actor he/she wishes to update and
the system retrieves and displays the account information.
ii. The administrator makes the desired changes to the account
information.
iii. After changes, the system updates the account with the changed
information and the use case ends.

6.5.3 Delete user account

i. The administrator searches for the actor he/she wishes to update and
the system retrieves and displays the account information.
ii. The administrator selects delete account and the system prompts the
user to confirm deletion.
iii. The administrator confirms the deletion
iv. The system removes the account with the changed information and
the use case ends.
6.6 Alternate flows:
6.6.1 User account not found
If in the update or delete account sub flows the requested user account is
not found, the system displays an error message and the agent may enter
other information or cancel the operation. At this point the use case ends.
6.6.2 Update/Delete cancelled
If in the update or delete account sub flows the administrator decides not
to update or delete the account, the operation is cancelled and the basic
flow maybe be restarted or terminated. At this point the use case ends.
6.6.1 Account already exist

15
 If in add new user account sub flow some or all the information entered is
the same as another account, the system displays an error message and the
agent may enter other information or cancel the operation. At this point
the use case ends.
6.7 Special Requirements: None
6.8 Use case relationships: None
7. View system logs
7.1 Introduction: This use case allows the administrator to view system logs
including all the changes made.
7.2 Actors: Administrator
7.3 Pre-conditions: Administrator must be logged in to the system.
7.4 Post-conditions: The administrator views all the system logs.
7.5 Basic flow: The use case starts when the administrator wants to view all
the changes made to the system.
i. The administrator selects view system logs
ii. The system retrieves the system logs
iii. Displays the information and the use case ends.

7.6 Alternate flows:

7.6.1 No changes made recently

If in the basic flow the no changes have been made to the system, an error
message is displayed and the administrator may view last changes made or
cancel the operation. At this point the use case ends.
7.7 Special Requirements: None
7.8 Use case relationships: None
8. Make policy claim
8.1 Introduction: This use case allows the policy holder to make a policy
claim.
8.2 Actors: Policy Holder
8.3 Pre-conditions: Policy Holder must be logged in the system and have
made premium payments for their policy.
8.4 Post-conditions: The policy claim is successfully made and is waiting for
approval.
8.5 Basic flow: The use case starts when the policy holder wants to make a
policy claim.
i. The policy holder selects policy claim.

16
 ii. The system requests the policy holder to select the loss incurred.
iii. The policy holder selects the required loss under their policy and
the mode of payment of losses.
iv. The system requests the policy holder to submit documents to
support the request for payment of losses.
v. Successful message is displayed and policy holder awaits
approval.
vi. The system notifies the policy holder that their claim is approved
and a payment of losses will be made.
vii. The payment of losses is made according to the mode of payment
selected at this point the use case ends.
8.6 Alternate flows:
8.6.1 Policy claim not approved
If in the basic flow the policy claim is not approved, the policy holder is
notified and the policy holder may restart the basic flow with other
documents. At this point the use case ends.
8.7 Special Requirements: None
8.8 Use case relationships: None
9. Approve policy claim
9.1 Introduction: This use case allows the Administrator to approve a policy
claim.
9.2 Actors: Administrator
9.3 Pre-conditions: The policy holder must have made a policy claim. The
administrator must be logged in to the system and notified of a policy
claim made by the Policy Holder.
9.4 Post-conditions: The policy claim is approved by the administrator and a
payment of losses is made.
9.5 Basic flow: The use case starts when the policy holder makes a policy
claim and the administrator is notified.
i. The system notifies the administrator of s policy claim made by a
policy holder.
ii. The administrator requests the attached documents to support the
policy claim.
iii. The system retrieves the documents sent by the policy holder to
support the claim.

17
 iv. The administrator selects approve payment of losses and amount
to be payed and the information is updated.
v. The system notifies the policy holder of the approval of his/her
policy claim.
vi. The payment of losses is made according to the mode of payment
chosen and the use case ends.
8.6 Alternate flows:
8.6.1 Policy claim not approved
If in the basic flow the administrator does not approve the policy claim,
the system notifies the policy holder and if a new policy claim is made the
administrator restarts the basic flow. At this point the use case ends.
8.7 Special Requirements: None
8.8 Use case relationships: None

18
 PART THREE: SOFTWARE
REQUIREMENT SPECIFICATION
DOCUMENT

19
 INTRODUCTION

Purpose

This SRS document specifies the requirement of the Policy Insurance Management
System outlining in detail the services it provides to the user and it’s
developmental and operational constraints. It covers the system as a whole and not
only a part of it or any of its subsystems alone. The Policy Insurance Management
system provides automated insurance services. It includes the policy holder, agent
and the administrator. The online system provides interface to relieve some of the
processes to the policy holder, agent and administrator. It is a web-based
application implemented for managing policy and policy holder details through
agents to the administrator.

Document Conventions
The conventions used in this document include the fonts and font styles and their
significance when used.
This whole document uses the font “Times New Roman” in font size 12 for paragraphs
and:
- Capitalized Words (font size-18) for Headings
- Bold words (font size – 14) for Sub-headings
- Bold Italic words for emphasis on the words or phrases

All detailed requirements in this document will inherit from higher-level requirements
stated prior to the detailed requirements.

Intended Audience and Reading Suggestions

This document is strictly intended for the project manager of this project and also the
project writers. It is therefore not intended to be used for contract negotiations by
stakeholder nor for developers to use in developing the proposed system.

This SRS is part of a larger document containing the introduction to the whole document,
followed by three main parts. The recommended way of reading this document is to first
read the brief introduction to the whole document to decide which part of the document is

20
of interest and then heading to the table of content to find the reference to the part. This
SRS is found on PART THREE and all its content follows thereafter.

Product Scope
The project develops a Policy Insurance Management System for an Insurance company
secure and efficient management Policy insurance details and for fast and available
services for the policy holder, the agent and the insurance company itself. The Software
covers for Vehicle insurance only and is for use by Policy holders already insured by the
insurance company. The system allows the policy holders to maintain the insurance policy,
online payment for policy premium. Agents also are part of the system. They act as a
mediator between the policy holder and the insurance system with respect to the policy
being provided. The system also includes an administrator who is part of the insurance
company. The three mentioned will be the only types of users within the system.

The scope of this project is given in more detail in SCOPE OF STUDY section of PART
ONE of this document.

REFERENCES
Ahmed, J., 2016. Final Project Insurance Management. [Online]
Available at: https://www.scribd.com/document/338415727/Final-Project-Insurance-
Management-System-2
[Accessed 5 March 2021].
Cambridge University Press, P., 2021. Premium. [Online]
Available at: https://dictionary.cambridge.org/amp/english/premium
[Accessed 10 March 2021].
Kagan, J., 2020. Insurance. [Online]
Available at: https://www.investopedia.com/terms/i/insurance.asp
Moqups, 2021. MoqUps. [Online]
Available at: https://app.moqups.com/ERgA2CJoPL/edit/page/aa9df7b72
[Accessed 11 March 2021].
Mustoe, L., 2020. What is PCI. [Online]
Available at: https://digitalguardian.com/blog/what-pci-compliance
Online Visual Paradigm, V., 2021. Visual Paradigm Online Tool. [Online]
Available at: https://online.visual-paradigm.com/
Sommerville, I., 2011. Sosftware Engineering. Massachusetts: Pearson Education.
Spreedly, 2021. Payment Orchestration Platform. [Online]
Available at: https://www.spreedly.com/

21
Webster, M., 2021. Policy. [Online]
Available at: https://www.merriam-webster.com/dictionary/policy

OVERALL DESCRIPTION

Product Perspective
The product specified in this document is a system replacing an old existing system in
order to improve the efficiency and security of the activities involved in the processes of
Policy Insurance. The System being replaced is the manual paper-based system of keeping
and managing the details of the policies offered and the policy holders.

The Online Policy Insurance also interfaces with external systems such as the bank
payment system with which the policy holders’ bank accounts are registered with. This
interface is accomplished by using the debit/credit card Payment Gateway API. The
system users are also considered external systems.

22
Below is a context diagram for the proposed system.

Diagram drawn using (Online Visual Paradigm, 2021)

Product Functions
To accomplish its purpose, the system will perform the following functions for each user
of the system:

The Policy Holder will be able to:

- login (the system authenticates user login details against the database, i.e.
username and password)
- view policy details
- manage account details
- make policy claim
- pay premium
- logout

The Agent will be able to:

23
 - login (the system authenticates user login details against the database, i.e.
username and password)
- view policy details
- manage account details
- register new Policy Holder
- manage existing Policy holder account
- view account details
- logout

The admin will be able to:

- login (the system authenticates user login details against the database, i.e.
username and password)
- manage user accounts
- approve policy claim
- view system logs
- view policy details
- view account details
- update policy details
- logout

Use case model of the system is available in the A USE CASE DIAGRAM
section of PART TWO of this document.

User Classes and Characteristics

The system will generally have three user classes namely: Policy Holder, Agent
and Administrator.
The Policy Holder
The Policy Holder is basically the clients of the insurance company; these will be
the people insured by the Insurance company (the insurer).
The Agent
The agent user is basically the mediator between the insurance company and the
Policy Holder. Most transactions such as registration of new Policy holders,
queries from Policy holders, complaints, responses of queries from insurance
company, etc., are mediated by the agent.

24
The Administrator
The administrator will basically be the user from the insurance company. This user
will have privileges that the insurance company normally has such as, updating
policy details, approve policy claims (after investigation by insurance company),
view system logs (for audit purposes) etc.
The Policy Holder is basically treated as the most important user of the system as
the system aimed at providing better services to the insured. Therefore, their
satisfaction is of high priority.
However, the agent and administrator are anticipated to be the most frequent users
of the system.

Operating Environment
Since the system is a web application, it will be made to operate in the following
operational environment:

Operation System : Windows 2003

Web Server : IIS 6.0(Internet Information Server)
Framework : ASP.NET 2.x frame work enabled
Database : SQL Server 2000/2005
Minimum Space : 1GB (including Database space) and may
grow depends on the Customer information

Browser: Any HTML 4.0 or prior version compliant browser with a Minimum
Screen resolution of 800X600 pixels.
JavaScript : JavaScript should be enabled in the browser

The system will be hosted on online servers with the following minimum
requirements:
Processor : Pentium III
Speed : 1.0 GHz
Memory : 256MB RAM
Hard Disk : 40GB Hard disk with minimum 4GB
free space
Interface : Mouse, Keyboard

25
On client side any hardware that can run a web browser.

Design and Implementation Constraints

The constraints faced by the developers during design and implementation include:
- The tight schedule for the project limited the options that the developers had since
they had to adhere to development schedule
- Some browsers have limited support for the technologies used by the developers
such as JavaScript and database to be used. The developers had to work to support
these browsers.
- The policies that the insurance companies had in place limited the tools that the
developers could use in design and implementation of the product
- The budget limited the number of developers that could be employed to build the
system posed a constraint
- The design conventions and standards that were to be followed in developing the
system limited the options and capabilities of the designers and developers since
they had to conform to the required guidelines and procedures

User Documentation
The system will be deployed with a couple of documentation intended to help the
users in different cases. The documentations will include:
- User manuals for agent and admin users
- User manual for policy holder which will be given to them upon creation of
a policy holder account.
- Online manual in the help section of the system in case the user
- User guide on the system interface

Assumptions and Dependencies

One assumption is that the system is used on a computer with enough performance
ability, the use of an up-to-date internet browser connected to the internet
throughout the usage of the system. If the computer does not have enough
performance to support the system, the system may not work as intended. This
could cause performance and usability issues for the user.

26
Another assumption is that the system is compatible on user machine. The user
must complete a training session to be able to use the system.

Another assumption is that every browser supports the web application and runs on
a variety of PC’s and other clients.

The performance of the system depends on these assumptions to a significant

degree.

EXTERNAL INTERFACE REQUIREMENTS

User Interfaces
1. Login Screen
1) username text field
i) Input for the username to access the User profile.
2) User password text field
i) Input for the password to access the User profile.
ii) The password is hidden from the user typing.

3) Login Button
i) Verifies credentials and logs user into the application, showing the home
screen below (prompts the system to authenticate the user).
4) Remember Me Checkbox

27
 i) Saves the user login credentials so that user is automatically logged in
during their next session.

2. Home Screen
1) Dashboard

Diagram drawn using (Moqups, 2021)

Hardware Interfaces

28
The backend of the system will need to interface with the web-server on which the system
will be hosted. This is where the database will sit and all the necessary data that is
uploaded and retrieved to and from it will be stored on the hard disks on the server.

Software Used for backend and frontend

JavaScript, HTML, CSS, PHP and SQL.

The frontend of the web-application will run on the JavaScript, HTML and CSS. The
HTML will form the skeleton of the site while the CSS will style the site and its layout.
The JavaScript will enhance interactivity of the system such as controlling the
responsiveness of the system on any device and browser. The PHP programming language
is used for all the backend programming for the web application. The web server should be
able to support version 7.0.0. of PHP programming language or later.

The client device should support CSS 3.0 or later, HTML version 3.0 or later and native
JavaScript (not any frameworks will be used)

MySQL Database
This will be used to organize and manage the system’s database. The data that it will hold
include users’ details and credentials, and insurance policy details.

Software Interfaces
The frontend part of the system will need to interface with the user’s web browser
(the client) which will interface with the client’s Operating system in order to
handle all inputs and outputs required and any processing needed to be done by the
client before sending data to the webserver. It will run efficiently with the
minimum requirements stated. The PC will need to be connected to the internet all
times during the user of the system. The keyboard, mouse, keypad and/or screen of
the client will be used by the user to interact with the system (all inputs handled by
the Operating System to the web browser). The user can use the already supported
browser shortcut commands plus more that will be included in the user manual for
easy navigation of the system.

The Frontend will also need to interface with the database. This will be done
through PHP which will collect input from the HTML in frontend and then query

29
the database with it. The system will update the database and provide a relevant
response to the user thereafter.

The Policy Insurance System will also interface with the banking systems through
a CPI (Mustoe, 2020) compliant payment gateway API such as (Spreedly, 2021)
during payments for premium and receipt of claim by Policy holder. The system
will send out payment details for the payment to be processed and the status of the
payment process will be received by the system which then update the database.

Communications Interfaces
The system will include forms in which the user will enter data needed to be sent to
the database. It will also include emails sent to users for important notifications.
The system will implement this communication via a network (the internet),
therefore, will the HTTPS communication protocol for all transactions between the
server and the client. The FTP will be used, for example when updating the system
with new functionality.

OTHER NONFUNCTIONAL REQUIREMENTS

Performance Requirements
The following performance requirements should be maintained in the project:
- Each page in the site needs to load in a reasonable amount of time (in 5
seconds or less).
- Latest web techniques like Caching should be implemented to speed up the
loading of dynamic pages. This will also improve on the number of
simultaneous users, as connections are freed faster.
-
Constraints for performance may include limits in system feature support by client
devices used to access the system and also lack of knowledge on how to use the
system by the user.

30
Safety Requirements
The safety of the records and information managed by the system is the only safety
concern. To ensure no loss of this data is incurred, the system should provide a secure
backup of all information on a different server in case the current server fails or is
damaged.
The system does not pose any threat to physiological safety, therefore, health measures
were not considered in developing this system.

Security Requirements
For the Online Policy Insurance Management System, security is a high priority
requirement. The system should provide for access of respective data to authorized
users only. All the necessary steps were taken to provide security to the site by
following and implementing the latest security technology. The data of all members
is proprietary data of the Client’s Organization and its members (The Insurance
Company and Policy Holders)

Software Quality Attributes

The following quality attributes should be maintained in the software system.

Maintainability

The system shall be built in a way that it will be easily maintainable and adaptable
to new organizational needs. It will be easy to fix faults without disturbing the
functionality of other system component or the system as a whole

Availability

The site should be accessible to as many users as possible at any time the users
wish to access. They should also be able to access it on as many device web
browsers as possible.

Reliability

The system shall respond to service request in the manner that is expected at all
times. Since the reliability of the system largely depends on the web server it will
be hosted on, and also on LOGIN mechanisms, the technologies used to implement
them shall be the best that can possibly be implemented.

31
Business Rules
- Administrators will be able to approve policy claims provided that policy
holder meet the required threshold conditions.
- Agents will be able to manage policy holder account provided the policy
holder is insured.
- The administrator may make changes to other user account if that user
requests that he does so on their behalf

APPENDIX: GLOSSARY

Acronyms

SRS- Software requirements specification

PCI – Payment Card Industry
HTML- Hypertext Markup Language
HTTP- Hypertext Transfer protocol
CSS- Cascaded style sheets
FTP- File transfer protocol
HTTPS- Hypertext Transfer Protocol secure
PHP- Hypertext Preprocessor
ASP- Application Service Provider
GB- Gigabyte
SPI- Service Provider Interface
SQL- Structured Query Language
GUI- Graphic User Interface

Definitions
- Requirements - requirements for a system are the descriptions of what the
system should do—the services that it provides and the constraints on its
operation (Sommerville, 2011)

32
- Insurance - Insurance is a contract, represented by a policy, in which an
individual or entity receives financial protection or reimbursement against
losses from an insurance company (Kagan, 2020)
- Policy - a definite course or method of action selected from among
alternatives and in light of given conditions to guide and determine present
and future decisions. (Webster, 2021)
- Premium – The amount paid for a contract of insurance (Cambridge
University Press, 2021)
- System – A set of interrelated components working together to achieve a
common goal or objective

33