is6155 project student numbers 90079094 114223513 102859661

MBS ISBP IS6155 Database Analysis & Design Group Project

Submitted by: Name Student No.

Jean Donnelly 90079094

Brendan McSweeney 114223513

Tim Walsh 102859661

Submitted to: Dr. Ciara Heavin

Submission Date: 20 November 2014

of 13

Table of Contents

Introduction ................................................................................................................................ 3

The Role of the Systems Analyst ............................................................................................... 4

Use Case Model ......................................................................................................................... 8

Entity Relationship Diagram (ERD) ........................................................................................ 10

Summary .................................................................................................................................. 11

Appendix .................................................................................................................................. 13

of 13

Analysis Report for Online Health Insurance Quoting System

Introduction

The scope of this report was to analyse the user requirements for an Online Health Insurance

Quoting system. The analysis includes:

An evaluation of the role of the Systems Analyst on this project

A description of the business requirements for all actors in a Use Case model

A description of the data used by the application using an Entity Relationship

Diagram (ERD)

This stage of the development of the Online Health Insurance Quoting System deals with the

activities pertaining to the upper end of the Systems Development Life Cycle (SDLC) below.

The first part of this report, outlining the role of the Systems Analyst, relates primarily to the

first four stages above, though some testing and review elements may be involved.

of 13

The second part of this report would be a component of the Requirements Analysis phase of

the SDLC, developing the functional requirements of the system into Use Cases. These Use

Cases encourage user involvement, one of the key factors for project success. Use Cases may

also facilitate the prioritisation of requirements, allowing for the possibility of delivering a

working first version of the system with the highest priority use cases.

The third part of this report reflects a translation of the business requirements into a logical

design for the system. The data requirements are modelled in the ERD.

The Role of the Systems Analyst

The primary role of the System Analyst is that of an interpreter - translating between the non-

technical business representatives and the technical system implementers.

In one direction the System Analyst translates the business needs from the business

representatives into a design of the system that the implementers can then bring to life. In the

other direction the System Analysts explains the technical abilities and limitations of the

system into practical functionality that the business representatives can understand.

The System Analyst often also works as a negotiator to agree compromises between an ideal

"blue-sky vision" desired by the business representatives and the practical reality of what is

achievable due to constraints such as technical, cost, time, scope, etc.

Since the System Analyst is responsible for communication and collaboration between the

business stakeholders and the members of the IT department, he/she should have excellent

interpersonal and communication skills. He/she must display character and ethics as well as

flexibility and adaptability (Whitten and Bentley, 2007). The Systems Analyst’s role as a

facilitator between all stakeholders necessitates a good working knowledge of information

technology and general business knowledge of the relevant sector.

The Systems Analyst must identify the needs of the health insurance company in a systematic

and detailed way, to get an understanding of the real business needs and find the root cause of

any problems. “A key skill needed in this part of the process is the SA’s ability to distil

different messages and needs of project stakeholders into a single, consistent vision.”

(Ambler, 2012).

of 13

In general the System Analyst will take a leading role in the following activities:

1. Preliminary Investigation

2. Problem Analysis

3. Requirements Analysis

4. Logical Design

5. Decision Analysis

(Whitten and Bentley, 2007)

Subsequently the Systems Analyst will also be involved as a participant in the system design.

In these activities the Systems Analyst will:

Ensure that the technical solution meets the business needs

Integrate the technical solution into the business

Online Health Insurance Quoting System

Preliminary Investigation

Preliminary Investigation is usually focused on confirming the merit of the proposed project.

The Systems Analyst may have been involved with the management team in identifying

problems and/or opportunities and establishing the scope of the project. For example, the

scope might include the client has stipulated that ‘a web application will suffice for both

customers and staff’. As the health insurance company has already decided to implement an

Online Health Insurance Quoting System, presumably the need for this system has been

agreed and prioritised, the project has been planned and the Project Charter has been

approved.

Problem Analysis

Similarly, it is presumed that the Systems Analyst has collaborated with the system owners,

users and staff to justify that the problem to be solved is worth solving and will provide a

return on investment. It is expected that system improvement objectives have been

documented.

Requirements Analysis

The Systems Analyst must identify the needs of the health insurance company in a systematic

and detailed way, to get an understanding of the real business needs and find the root cause of

any problems. Clearly identifying the needs of the organisation requires an understanding of

the current Irish health insurance industry, the competition therein and consumer trends and

of 13

preferences. The Systems Analyst will become knowledgeable about the particular practices

and processes in the company and the wide range of health insurance plans they offer. He/she

needs to acknowledge statutory regulations in the market and be informed of issues in the

market that may affect the health insurance company and consumers. For example, the Health

Insurance (Amendment) Bill 2014 gives insurers discretion to charge discounted premiums

for young adults aged between 18-20 from 9th May 2015 (www.hia.ie).

In a new business domain it is often necessary for Systems Analysts to learn to grasp key

terminology. This may be captured in a glossary or domain model. Key terminology in the

health insurance industry would not be overly technical in nature and is readily available. A

glossary or domain model would still be critical as the Systems Analyst needs to be confident

when discussing terminology with stakeholders in the requirements discovery stage and also

when translating requirements to developers.

The Systems Analyst will seek to understand what the new system must do while ignoring

technically how the system will do it.

The Systems Analyst will gather requirements from the two main sets of users: internal staff

and external customers. He/she must work with all stakeholders across the organisation to

gather as much information as possible so that all available knowledge and needs are

incorporated into the solution. Multiple fact-finding methods would be suitable for this

purpose in the health insurance company. The Systems Analyst may formulate carefully

worded questionnaires and conduct interviews with the health insurance company staff.

Taking a sample of staff that includes personnel of different ranks within the organisation is

appropriate. For staff (customer service agents and their managers) the Systems Analyst will

probably facilitate a requirements gathering workshop with representatives. Sampling of

existing documentation, site visits and observation of the work environment may also be

suitable.

For the customers, the Systems Analyst faces the challenge that these users are outside of the

organisation and it can be difficult to get substantial interaction with them. He/she will

probably use research (e.g. review of similar web applications used by competitors),

interviews, questionnaires, etc. and may also consider engaging a small group of

representative customers, e.g. a focus group.

The Systems Analyst will then develop the functional requirements into Use Cases (e.g. log

in, get health insurance quote, maintain contact details, etc.). These use cases encourage user

involvement, one of the key factors for project success. Prioritisation of the requirements will

allow for the possibility of delivering a working first version of the system with the highest

http://www.hia.ie/

of 13

priority use cases. For example, the representatives might decide that for customers getting a

quote is a top priority and allowing logging in to store a quote and update contact details are

lower priorities that can Wait for subsequent releases. The prioritised requirements will be

documented in the Business Requirements Statement or Requirements Definition Document,

which will be approved by the internal and external representatives.

Logical Design

The Systems Analyst will translate the business requirements for the Online Health Insurance

Quoting System into a logical design for the system, including a process model (e.g. Data

Flows) and a data model (e.g. Entity Relationship Diagram).

Decision Analysis

The System Analyst will work with other project team members to recommend a technical

system solution. Candidate solutions will be identified, analysed and compared. Based on the

comparison one or more recommended solutions will be chosen and the System Proposal will

be delivered.

Implementation of the Project

Having gathered the requirements in a comprehensive manner the online quotation system is

ready for the development process. “At this stage the systems analyst role typically shifts

from an active one to a reactive one.” (Ambler, 2012). After the development of the Online

Health Insurance Quoting System, the Systems Analyst may facilitate the execution of the

system test and communicate any issues between members of the project team.

Finally, the Systems Analyst will be involved in a review and feedback forum with the

stakeholders to ensure that all of the requirements established in the initial phases of the

project development have been fulfilled by the system.

of 13

Use Case Model


Customer

Customer Service Agent

Log In

Get quote

Store Quote

Submit Claim

Maintain Contact Details

AttachDocument

Maintain HealthInsurance Data

Maintain PolicyDetails

Change ClaimStatus

View Document

Choose PolicyType

includes

includes

includes

includes

includes

extends extends

Amend Policyincludes

Renew Policy

Make Payment

includes

extends

of 13

Use Case Diagram Assumptions

Assumption 1: A customer needs to choose a policy type in order to get a quote.

Assumption 2: A customer needs to get a quote in order to store a quote.

Assumption 3: A customer needs to be logged in to submit a claim.

Assumption 4: A customer needs to be logged in to maintain his/her contact details.

Assumption 5: Having logged in, a customer can amend his/her policy details using this

Online Quoting System.

Assumption 6: A customer needs to be logged in to amend his/her policy.

Assumption 7: A customer can renew his/her policy using this Online Quoting System.

Assumption 8: A customer needs to be logged in to renew his/her policy.

of 13

Entity Relationship Diagram (ERD)

Customer

PK CustID

CustFirstName CustLastName CustAddress CustDateofBirth CustPassword

FamilyMember

PK FamMembID

FamMemFirstName FamMemLastName FamMemDateofBirthFK1 PolicyID

Quote

PK QuoteID

QuoteDate QuotePriceFK1 CustIDFK2 PolicyTypeID

Policy

PK PolicyID

PolicyStartDate PolicyEndDateFK1 PolicyTypeIDFK2 CustID

PolicyType

PK PolicyTypeID

PolicyTypeName PolicyExcess

CustomerServiceAgent

PK CustServAgentID

CustServAgentFirstName CustServAgentLastName

Claim

PK ClaimID

ClaimDate ClaimStatusFK1 PolicyID


Document

PK DocumentID

DocReceivedDate DocumentFK1 ClaimLineID

ClaimAmendment

PK,FK1 CustServAgentIDPK,FK2 ClaimID

ClaimAmendDate ClaimAmendDesc ClaimIDCustServAgentID

PolicyAmendment

PK,FK1 CustServAgentIDPK,FK2 PolicyID

PolicyAmendDate PolicyAmendDesc

Benefit

PK BenefitID

BenefitType BenefitLimitClaim BenefitLimitYearFK1 PolicyID

ClaimLine

PK ClaimLineID

FK1 ClaimID

of 13

ERD Assumptions

Assumption 1: All health insurance policies, current and past, are kept in the policy entity.

Assumption 2: In addition to Policy Excess and Policy Type, other health information

related to the health insurance policy is Benefit Type (i.e. private hospital,

public hospital, physiotherapy, GP visits, etc.), Benefit Limit per Claim (i.e.

the amount the customer can claim per visit. E.g. Max. €30 can be claimed

per GP visit which cost €50) and Benefit Limit per Year (i.e. the amount the

customer can claim for each benefit per year. E.g. Maximum 7 GP visits per

member per year).

Assumption 3: A customer who has not logged in is allocated a temporary customer record

which is discarded unless the customer creates an account.

Assumption 4: Documents submitted in support of health insurance claims are stored in the

database, e.g. as Binary Large Objects.

Assumption 5: The Online Health Insurance Quoting System is solely for quoting purposes

and would not include the processing of health insurance claims.

Assumption 6: The Policy Excess is set by Policy Type, rather than on individual policies.

Summary

It is envisaged that the Systems Analyst, working with other project team members, will use

the Use Case model and the ERD provided in this report to recommend a technical system

solution for the development of the Online Health Insurance Quoting System. Candidate

solutions will be identified and compared. Based on the comparison, the optimal solution will

be chosen and brought forward to design and implementation of the new development.

of 13

References

Ambler, S. (2012) ‘Disciplined Agile Delivery: A Practitioners Guide to Agile Software

Delivery in the Enterprise’, IBM Press

Whitten, J.L. and Bentley, L.D. (2007) ‘System Analysis and Design Methods’, 7th ed. New

York, NY: McGraw-Hill/Irwin

www.hia.ie

of 13

Appendix I: Initial Use Case


Customer

Customer Service Agent

Log In

Get quote

Store Quote

Submit Claim

Maintain Contact Details

AttachDocument

Maintain HealthInsurance Data

Maintain PolicyDetails

Change ClaimStatus

View Document