1. 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
2. Page 2 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
3. Page 3 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.
4. Page 4 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).
5. Page 5 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
6. Page 6 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
7. Page 7 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.
8. Page 8 of 13
Use Case Model
Online Health Insurance Quoting System
Customer
Customer Service Agent
Log In
Get quote
Store Quote
Submit Claim
Maintain
Contact Details
Attach
Document
Maintain Health
Insurance Data
Maintain Policy
Details
Change Claim
Status
View Document
Choose Policy
Type
includes
includes
includes
includes
includes
extends extends
Amend Policy
includes
Renew Policy
Make Payment
includes
extends
9. Page 9 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.
11. Page 11 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.
12. Page 12 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
13. Page 13 of 13
Appendix I: Initial Use Case
Online Health Insurance Quoting
System
Customer
Customer Service Agent
Log In
Get quote
Store Quote
Submit Claim
Maintain
Contact Details
Attach
Document
Maintain Health
Insurance Data
Maintain Policy
Details
Change Claim
Status
View Document
