health’r’us’insurance’ software’architecture’document’ · health r us insurance...

Health R Us Insurance Software Architecture Document

Version 3.0

Health R Us Insurance Version: 3.0 Software Architecture Document Date: 12/21/15

Confidencial ©SUNY Fredonia, 2016 Pág. 2 de 16

Revision History Date Version Description Author

12/05/2015 1.0 First Version xxx

12/10/2015 2.0 Requirements review xxx

12/21/2015 3.0 Design review xxx



Table of Contents 1. INTRODUCTION 4

1.1 Biographies 4 1.2 Motivation 4 1.3 Goals 4 1.4 Stakeholders 4 1.5 Business Process Description 4 1.6 Process Flow Preview 5

2. REQUIREMENTS ENGINEERING 5 2.1 Plan for requirements Elicitation 5 2.2 Functional Requirements 6 2.3 Non-functional Requirements 10 2.4 Use Cases 12

3. DESIGN AND IMPLEMENTATION 13 3.1 Tasks 13 3.2 Use Case Diagram 14 3.3 Class Diagram 15

4. VALIDATION 15 4.1 Test Plan 15 4.2 Features to test 15 4.3 Test Cases 15 4.4 Testing Schedule 16

5. CONCLUSION 16



Software Architecture Document

1. INTRODUCTION

1.1 Biographies

xxx - Domain Expert Pharmacy operations manager focusing on claims processing management and system for 12 years.

xxx - Lead Software Engineer The leader for the software project with 13 years’ experience working on projects for the healthcare industry

xxx - Domain Expert/Engineer An engineer and vendor with 7 years’ experience developing and helping those working in the

health care field with their software.

1.2 Motivation

The issue this software is aimed at resolving is the high amount of confusion and lack of transparency

when applying for and obtaining insurance coverage through current conventional means. The FredCares-a-

Lot wants to offer a system that the agents and customers can communicate and check their information.

Also all the information about plans and prices should be displayed to the customers or potential customers.

1.3 Goals

The goal of this software is to ease the frustration of researching and purchasing competitively priced

insurance plans. It is aimed to make this process more understandable for the customer and the agents

involved in selling the plans creating a software that can help and make things easier to the agent and

customer.

1.4 Stakeholders

The system proposed evolves different actors and interactions, the main stakeholders that we

identified are:

• Customer

• Employees

o Managers

o Agents

• Guests

1.5 Business Process Description

The ideal for this software is to make the services it provides clear to understand and completely

transparent. This means that when the customers use the web based solution they can find every last bit of



information they need about the plans that are available to them. In addition, the agents using the client to

help a customer choose a plan or resolve a claim have full access to view all pricing options and what the

plans cover. Additionally, looking forward a mobile app will be developed to aid customers on the go

check their plans efficiently.

1.6 Process Flow Preview

Our requirements engineering and elicitation is based heavily on the needs of the user. As such our

primary method of gaining our requirements will be with the use of interviews with the agents using the

application and a sampling of potential users of the website. These interviews will consist of both open and

closed interviews so as to get the best possible range of functionality needed for the user.

Design of the system will be taken in steps in an agile approach. Some key points to make note of are

the creation of the database and its management system, the agent application, and the website. Then in the

near future the release of the mobile app and the continuing evolution of all of these applications.

Lastly validation will be primarily spent in the hands of the user as that is who we must ensure the

software meets the needs of. System testing will be brief so as to ensure security and functionality. After

that we will scale up the user testing at a fast pace to ensure as large a sample size as we can from both the

view of the customer and agent.

2. REQUIREMENTS ENGINEERING

2.1 Plan for requirements Elicitation

Considering all our main stakeholders (Agents, managers and costumers) we decided to use open

interviews as the main approach to come up with the requirements. Open interview is the best way to

discover the requirements when the team doesn’t know exactly how the process works and when the

number of stakeholders is relatively high. To mitigate the presence of conflicts between requirements the

interviews happened with all stakeholders together, the answers was discussed as a group and some of the

conflicts was resolved during this process.

After finishing the requirements discovery activity, we classified and created an organization

between the requirements. This classification was made by the priority value (1 to 5) that is calculated

using customer satisfaction (1 to 5) and customer dissatisfaction (1 to 5).

With all requirements already classified we used VOLERE cards to the specification activity. In

the VOLERE cards we could represent all the necessary information about the requirements, the

explanation of each field of the card is in the Figure 1.



Figure 1 - VOLERE card

2.2 Functional Requirements Requirement #: 01 Requirement Type: Functional Event/BUC/PUC#:

Description: Requires login to access the system. (Use Identification number and initial system generated password,

ask user to change after first login)

Rationale: Security and accountability reasons

Originator: Customer, Agents and Managers

Fit Criterion: When the system is opened the login screen should appear at first.

Customer satisfaction: 5 Customer Dissatisfaction: 5

Priority: 5 Conflict: None

Dependency: None.

Supporting Materials: User identification policies



Requirement #: 02 Requirement Type: Functional Event/BUC/PUC#:

Description: View personal information.

Rationale: Allow the users check their information

Originator: Customer and Agents

Fit Criterion: Customer and agents should be able to see the follow information about customers: Full name,

Insurance identification number, Policy outline, Pricing medical/prescription needs What is covered by the policy,

Coverage for family



Dependency:

Supporting Materials: Forms of customer’s information.


Description: Ability to update all personal information for self and family.

Rationale: Allow the user manages his own information.

Originator: Customer, Agents and managers.

Fit Criterion: When seeing customer’s personal information allow an edit mode



Dependency: None.

Supporting Materials: None

Requirement #: 04 Requirement Type: Functional Event/BUC/PUC#: 01

Description: Check agent’s info.

Rationale: The customer can see the agent’s info anytime he needs.

Originator: Customer

Fit Criterion: The customer should be able to see the follow information: Name, Phone number, Availability/hours.





Dependency: None.

Supporting Materials: Employees records


Description: Check new medical business.

Rationale: Medical business may change.

Originator: Managers

Fit Criterion: Managers should be able to see the follow information: Specificity (Pharmacy, hospital, MD,

Specialist) procedure pricing, Location, Members potentially impacted, Office phone number


Priority: 5 Conflict: None.

Dependency: None.

Supporting Materials: None.

Requirement #: 06 Requirement Type: Functional Event/BUC/PUC#: 02

Description: Check personal commissions.

Rationale: The agents can see their commissions using the system.

Originator: Agents

Fit Criterion: Agents should be able to see the follow information: Number of policies sold, rate of commission per

policy.



Dependency: None.

Supporting Materials: Forms????


Description: Gives access to agent utilities.

Rationale: The agent needs to have access to the utilities


Fit Criterion: The agent has access to the utilities





Dependency: None.

Supporting Materials: None.


Description: Update policy prices.

Rationale: The price of the policies can change.


Fit Criterion: Managers should be able to update the policies prices.



Dependency: None.



Description: Guests have to access without security requirements.

Rationale: Guests needs to be able to check prices and plans information.


Fit Criterion: The guests can check plan information and prices.


Priority: 2 Conflict: #1

Dependency: None.



Description: Plan pricing displayed for guests.

Rationale: Guests should be able to see the plan prices.

Originator: Guests.

Fit Criterion: Guest should be able to see the follow information: Cost per month, Pricing for procedure/medication

with that policy.





Dependency: None.

Supporting Materials:

2.3 Non-functional Requirements Requirement #: 11 Requirement Type: Non-Functional Event/BUC/PUC#:

Description: The system should delivery an answer no longer than 5 seconds.

Rationale: The system needs to be fast and delivery responses in an acceptable amount of time.

Originator: Managers, Customers, Agents.

Fit Criterion: All the functions should not take more than 5 seconds to run.



Dependency: None.


Requirement #: 12 Requirement Type: Non-Functional Event/BUC/PUC#:

Description: The employee’s software should be able to run in computers with 512 megabytes of main memory.

Rationale: The system will run in old computers.

Originator: Managers, Agents and guests.

Fit Criterion: All the system functions should run in a computer with 512 megabytes following the requirement

number 11.



Dependency: None.



Description: The background color must be light blue.

Rationale: match the company colors.

Originator: Managers.

Fit Criterion: The system background must be light blue in all windows.





Dependency: None.



Description: The system must run in Windows 7 platform.

Rationale: Windows is the OS used in the company.


Fit Criterion: All system modules should run in a Windows 7 machine.



Dependency: None.



Description: Back up of the system information in five different computers

Rationale: Security reasons


Fit Criterion: All the system data should be stored in 5 different computer



Dependency: None.



Description: The connections to the server should use an https connection

Rationale: Security reasons


Fit Criterion: Just https connections





Dependency: None.


2.4 Use Cases

Use case 01: Check Agent Info

Actors: Customer

Description: The customer can check information about his agent, information can be: Name, Phone

number, Availability/hours.

Pre conditions: An agent should be assigned to the customer.

Events:

1. The customer logs on the system

2. Customer clicks in “Agent” tab

3. Customer select “Agent Information”

4. The agent’s information shows up

What can go wrong:

1. Login on fails

2. There isn’t an agent assigned to the customer

3. There is no information about the agent

Other activities: The agent may be logged on the system and update his personal information System state on completion: Customer is logged on and the information about his agent is being displayed.

Use case 01: Check Agent Info

Actors: Agent



Description: The agent can check information about his commissions. Agents should be able to see the

follow information: Number of policies sold, rate of commission per policy.

Pre conditions: Agent already sold at least 1 policy.

Events:

1. The agent logs on the system.

2. Agent clicks on “reports” tab.

3. Agent selects “My commissions”

4. The values of commissions show up.

What can go wrong:

1. Login on fails

2. There isn’t commission for this agent

Other activities: The agent can choose to print a pdf of the results. System state on completion: Agent is logged on and the information about his commissions is being displayed.

3. DESIGN AND IMPLEMENTATION

3.1 Tasks

Database Creation

Using the models and design decisions of our system, a database must be created to store and

manage information about the employees, customers, pricing of medical procedures and medications.

Interfaces between employee’s software and the database, and between the website and the database must

be developed too.

Employee’s Software

The employee’s software is the part of system that will be used by agents and managers. They

should be able to view, add and modify information about themselves, customers, pricing, payment, and

medical procedures. The software will be developed using the requirements and design models.

Website Development

The website will be a way that the customers see information about the company and their

insurance plans, contact the employees and view their insurance information. Our focus is to make it easy

to use.

Testing

In this task we have to make sure that the database, the employee’s software and the website work

properly. Our tests are focused in customer testing and use of their data.

Implantation



The implantation is the final task of the software development, here we have to integrate the

system to the real environment in the company.

3.2 Use Case Diagram



3.3 Class Diagram

4. VALIDATION

4.1 Test Plan

Testing will primarily need to be in the hands of the users. The team will be able to do initial testing

to ensure the product is working as intended. However, until we put this software in the hands of the agents

using it and beta test the website and security with sufficient would be customers we will not have an

adequate amount of testing done. Specifically, we should like to do the following testing: unit, component,

system, release, and user.

4.2 Features to test

All functional requirements must be tested. Specifically, important tasks to ensure are login security

and the ability of all parties to be able to check on and update their information.

Our primary non-functional requirement to focus on is the adherence to all HIPAA (Health Insurance

Portability and Accountability Act) regulations regarding the protection of private health information.

4.3 Test Cases

Partition testing will be used to test functionality of many key parts of the application and



website. This will look into consistency of the many moving parts it has. Naturally we will have to ensure

that it works with all acceptable values but we will test certain things with unnatural values as well (e.g.,

improper login credentials, out of range values on pricing, claims processing anomalies).

4.4 Testing Schedule

• Week 1

o Unit/Component/System testing

• Week 2-3

o Release testing

o Scenario

• Week 4-5

o User testing

o Alpha/Beta

• Week 6

o Acceptance testing

5. CONCLUSION

Moving forward with this project we have a very good outlook for the continuing evolution of our

software. Because this partnership will remain intact between the software team and the company moving

forward it should be a consistent process for improving our software. We will remain focused on taking

customer input and suggestions as well as those from the agents to continually improve their

experience. Additionally, we will ensure a team is in place to produce and maintain the mobile application

as well as being able to access as many platforms as possible for the ease of the user. It is our goal to

continually make this process as convenient and efficient as possible for the user while providing any and

all information they could want or need.

health’r’us’insurance’ software’architecture’document’ · health r us insurance...

Documents