S1 2018 Business Analysis: Medigood National Health Insurance Report

This report delivers a comprehensive product analysis of Medigood National Health Insurance, focusing on the implementation of a software system to improve patient management and telehealth consultations. The analysis includes a stakeholder analysis identifying key players and their roles, a product vision document outlining the project's goals and features, an "As-is" process flow diagram illustrating the current business processes, a product backlog prioritizing system requirements using the MoSCoW technique, and use case diagrams and descriptions detailing system interactions. The report also identifies object classes relevant to the system, providing a thorough evaluation of the project's scope and requirements. Desklib offers a variety of similar solved assignments and past papers.

Running head: PRODUCT ANALYSIS REPORT
Product Analysis Report: Medigood National Health Insurance
Name of the Student:
Student ID:
Name of the University:
Author’s note:

1PRODUCT ANALYSIS REPORT
Table of Contents
Task 1.01 Stakeholder Analysis......................................................................................................2
Task 1.02 System/Product Vision Document..................................................................................3
Task 1.03 “As-is” Process Flow Diagram.......................................................................................4
Task 1.04 Product Backlog..............................................................................................................6
MoSCoW Technique.......................................................................................................................6
Task 1.05 Use Case Diagram and Description................................................................................7
Task 1.06 Object Classes Identification........................................................................................15
Bibliography..................................................................................................................................17
Appendix Task A: Project Journal.................................................................................................20

2PRODUCT ANALYSIS REPORT
Task 1.01 Stakeholder Analysis
The stakeholder analysis is done for ensuring that activities of the project would be
implied for listing the development of the operations and alignment of the effective evaluation of
the stakeholders (Jonasson 2016). The project stakeholders would be deployed for forming the
analysis of the supplementary development of the activities. The stakeholders of the project are
customer, supplier, sponsor, end users, help desk, regulators, executives, project team. The
stakeholders of the project would be responsible for user of the software system developed,
provide materials required for the project completion, provide investment to the project team for
doing the project, would utilize the developed project outcome, support and help for the progress
of the project, changes in the project would be modified, would be responsible for taking
effective key decisions in the project, and would have to carry out the operations of the project
and form the achievement of the final deliverable (Hailes 2014). The stakeholder analysis for the
software implementation project along with the patient management system for Medigood
National Health Insurance is given below,
Name Roles Attitudes Authority Power Influence
Customer User of the software system
developed
Neutral Accountable High High
Supplier Provide materials required for
the project completion
Interested Informed Low High
Sponsor Provide investment to the
project team for doing the
project
Highly
Interested
Informed High High

3PRODUCT ANALYSIS REPORT
End Users Would utilize the developed
project outcome
Neutral Accountable High Low
Help Desk Support and help for the
progress of the project
Interested Consulted Low Low
Regulators Changes in the project would
be modified
Uninterested Responsible Low High
Executives Would be responsible for
taking effective key decisions
in the project
Highly
Interested
Accountable High High
Project
team
Would have to carry out the
operations of the project and
form the achievement of the
final deliverable
Interested Responsible Low Low
Task 1.02 System/Product Vision Document
Product Vision Document
Software Implementation in Medigood National Health Insurance
Version: 1.0 Date: 5/4/18
Introduction: The document is developed for listing the product characteristics and description
that would be required for the completion of the project of software for data management in
Medigood National Health Insurance.
Product overview: The implication of the software development for data analysis would be

4PRODUCT ANALYSIS REPORT
aligned for the implication of the effective management of the data along with the patient
management system for Medigood National Health Insurance.
Product Features: The product developed would act as the effective management of the data
implication management. The supply of the effective integration would result in forming the
deployment of the successive management operations. The registering in the system would help
in monitoring the online operations by the Telehealth technology. The use of Telehealth
equipments would also be useful for the modification of the operations development. The
completion of the consultation would result in generation of the payment for both specialist and
family doctor.
Constraints: the qualifying patients must have appointment with the specialist
Documentation Required: System design documentation
Task 1.03 “As-is” Process Flow Diagram
The “As-is” Process Flow Diagram for the operations of Medigood National Health
Insurance would be implied for the alignment of the operations for the development of the
effective software processing in the organization (Jouen et al. 2015). The alignment of the
effective process flow diagram would help in understanding the existing information processing
as shown below,

5PRODUCT ANALYSIS REPORT
Figure 1: “As-is” Process Flow Diagram for Medigood National Health Insurance
(Source: Created by the author in Ms-Visio)
Explanation of information flow from the diagram above: The three main entity of
the “As-is” Process Flow Diagram are Office Administrator or family doctor, medical specialist
consultation, and Patients. The patients would have to initiate the information flow by requesting
for the Medigood health insurance by applying for it (Hau 2015). The office administrator or
family doctor would be responsible for analysing and evaluating whether the patient who have
applied for Medigood National Health Insurance is applicable for the getting the insurance. The
office administrator or family doctor would check the credentials of the patients for the criteria
of over 65, indigenous, and suffering chronic disease. If the patient passes all these credentials,
he or she would be approved for getting the insurance clearance. Else, the process of information
flow would cease and the application or request would be rejected. After approving the patient

6PRODUCT ANALYSIS REPORT
for getting the Medigood insurance, the office administrator or family doctor would check with
the medical specialist consultation if they would be available for meeting and examining the
patient. The specialist’s time table and appointment list would be evaluated for finding out the
possible day for meeting with the patient (Valacich, George and Hoffer 2014). The office
administrator or family doctor would ensure that a date feasible for both patient and specialist
and convey the appropriate time table to both of them. The specialist and the patient would get
the meeting time and date and the process would be stopped.
Task 1.04 Product Backlog
User User Story
Business Analyst As a business analyst, I want the implication of the software tools so that the
software would help in easing the business of the Medigood insurance
Customer As a customer, I want the user manual for the software tool so that I would
be able to utilize the system comfortably
Sponsor As a sponsor, I want the detailed report of the cost expended so that I would
be able to calculate the net profit from the project
Executives As an executive, I want the proper implication of the products and services
so that the organization would achieve smart profit from the system.
Project team As a project team, I want the completion of the project so that the project
team would get the benefit of final deliverable.
MoSCoW Technique
Must have: Feasible software design

7PRODUCT ANALYSIS REPORT
Should Have: Security of operations
Could Have: Cloud Conputing
Won’t Have: Tangible data storage
Task 1.05 Use Case Diagram and Description
The use case is developed for successfully aligning with the development of the effective
operations for the alignment of the improved operation development (Gonen 2014). The
implication of the use case diagram would help in realization of the actor and the successful
development of the process development for the operations. The implication of the successive
development model would help in easing the information processing and execution of the
processes for the organization of Medigood National Health Insurance. The following is the use
case diagram for the existing system at the organization,

8PRODUCT ANALYSIS REPORT
Figure 2: Use Case Diagram for Medigood National Health Insurance
(Source: Created by the author in Ms-Visio)
Use Case #0005101
Use Case Name: Check if patient is applicable for insurance
Scenario: The scenario has depicted the use of the information flow for
knowing whether the patient would be applicable for the inclusion of
the operation for the deployment of the effective operations. The
scenario would show that the office administrator or family doctor
would check if the patient who has applied for getting the Medigood
is applicable for getting the support on medical insurance. The office

9PRODUCT ANALYSIS REPORT
administrator or family doctor would check if the patient is over 65,
indigenous, and suffering chronic disease. The checking would be
initiated from the submitted information and various health records.
Triggering Event: Patient applying for Medigood Health Insurance and the existence of
the information of the patient
Brief Description: The office administrator or family doctor would be responsible for
analysing and evaluating whether the patient who have applied for
Medigood National Health Insurance is applicable for the getting the
insurance. The office administrator or family doctor would check the
credentials of the patients for the criteria of over 65, indigenous, and
suffering chronic disease.
Actors: Patient, office administrator or family doctor
Stakeholders: Patient, Medigood National Health Insurance, office administrator or
family doctor
Preconditions: Patient had applied for the Medigood Insurance
Post conditions: Patient would be either approved for getting Medigood Insurance or
Rejected from getting Medigood Insurance
Flow of Activities: Patient’s report  Office Administrator or Family Doctor  Health
Database  Office Administrator or Family Doctor  Patient
Exception Patient would not be validated for getting the Medigood Insurance

10PRODUCT ANALYSIS REPORT
Conditions:
Use Case #0005102
Use Case Name: Search for suitable medical specialist
Scenario: The scenario would depict the searching of a medical specialist by the
office administrator or family doctor. The patient who have applied
for the Medigood Health Insurance would be cross checked for the
feasibility of the getting the approval of the insurance. The office
administrator or family doctor would then check for any specialist for
the patient.
Triggering Event: Approval of the patient for getting Medigood and All criteria of over
65, indigenous, and suffering chronic disease are met.
Brief Description: If the patient passes all these credentials, he or she would be approved
for getting the insurance clearance. After approving the patient for
getting the Medigood insurance, the office administrator or family
doctor would check with the medical specialist consultation if they
would be available for meeting and examining the patient. The
specialist’s time table and appointment list would be evaluated for
finding out the possible day for meeting with the patient.
Actors: office administrator or family doctor
Stakeholders: medical specialist, Medigood National Health Insurance, office

11PRODUCT ANALYSIS REPORT
administrator or family doctor
Preconditions: Search for the appropriate medical specialist consultation would be
initiated by the office administrator or family doctor
Post conditions: Appropriate Medical Specialist Consultation would be founded for
the patient
Flow of Activities: Office administrator or family doctor  database of health records 
record of medical specialist  office administrator or family doctor
Exception
Conditions:
Patient would not be validated for getting the Medigood Insurance
Use Case #0005103
Use Case Name: Meeting time is fixed and Patients consults with specialist
Scenario: The scenario would depict office administrator or family doctor
checking and going through the appointment list and time schedule of
the specialist. The office administrator or family doctor would have to
ensure that the approval of the patient for the Medigood would help in
easing the patient by aligning a meeting between the specialist and
patient.
Triggering Event: Approval of the patient for getting Medigood and Specialist is
available for the patient
Brief Description: The specialist’s time table and appointment list would be evaluated

12PRODUCT ANALYSIS REPORT
for finding out the possible day for meeting with the patient. The
specialist’s time table and appointment list would be evaluated for
finding out the possible day for meeting with the patient. The office
administrator or family doctor would ensure that a date feasible for
both patient and specialist and convey the appropriate time table to
both of them.
Actors: office administrator or family doctor, medical specialist
Stakeholders: Patient, Medigood National Health Insurance, office administrator or
family doctor, medical specialist
Preconditions: Appropriate Medical Specialist Consultation would be founded for
the patient
Post conditions: Scheduling of the time and date for meeting the patients and specialist
would be narrowed down
Flow of Activities: office administrator or family doctor  medical specialist  office
administrator or family doctor
Exception
Conditions:
medical specialist would deny the due to tight schedule for meeting
the patient
Use Case #0005104
Use Case Name: Apply for Medigoods Health Insurance
Scenario: The scenario would depict the patient applying for getting the

13PRODUCT ANALYSIS REPORT
Medigood Insurance from the organization. The patient would go
through a deal for submitting the application for getting the insurance
along with the details of his or her medical history.
Triggering Event: Inclusion of the Medigood Insurance by National Health Insurance
and patient having prior information on the method of application for
insurance
Brief Description: The Medigood Insurance would be brought about by the National
Health Insurance and it would allow the patients for getting medical
insurance for the visit of the specialist doctor to them. The main
criteria for the applying for Medigood insurance are the criteria of
over 65, indigenous, and suffering chronic disease. The application
would be dependent on the alignment of the effective operations.
Actors: patient
Stakeholders: Patient, Medigood National Health Insurance
Preconditions: Patient would have knowledge for applying for the Medigood health
insurance
Post conditions: office administrator or family doctor would analyse and evaluate the
credentials of the patient who have applied for Medigood Insurance
Flow of Activities: Medigood
National Health Insurance  Patient  office administrator or family

14PRODUCT ANALYSIS REPORT
doctor
Exception
Conditions:
Patient would have no knowledge for applying for the Medigood
health insurance and hence he or she would not apply for it
Use Case #0005105
Use Case Name: Check if specialist/patient is okay with meeting time
Scenario: The office administrator or family doctor would have to check
whether the date and time fixed for the meeting between the patient
and specialist would be feasible for both of them. The specialist’s
time table and appointment list would be evaluated for finding out the
possible day for meeting with the patient.
Triggering Event: medical specialist would be available for checking the patient and the
patient had cleared the cross examination of the application
Brief Description: After approving the patient for getting the Medigood insurance, the
office administrator or family doctor would check with the medical
specialist consultation if they would be available for meeting and
examining the patient. The specialist’s time table and appointment list
would be evaluated for finding out the possible day for meeting with
the patient. The office administrator or family doctor would ensure
that a date feasible for both patient and specialist and convey the
appropriate time table to both of them.
Actors: office administrator or family doctor, patient, medical specialist

15PRODUCT ANALYSIS REPORT
Stakeholders: Patient, Medigood National Health Insurance, office administrator or
family doctor, medical specialist
Preconditions: Scheduling of the time and date for meeting the patients and specialist
would be narrowed down
Post conditions: Fixed time and date would be selected for meeting the patients and
specialist by confirming from both of them
Flow of Activities: office administrator or family doctor  patient  medical specialist
Exception
Conditions:
Either Patient or Specialist or both would deny the date and time of
meeting
Task 1.06 Object Classes Identification
Class Name with attributes are given below,
Patient (Patient_ID [PK], Patient_Name, Patient_Address, Patient_healthrecords)
Doctor (Doctor_ID [PK], Doctor_Name, Doctor_Address, Doctor_bankdetails)
Specialist (Specialist_ID [PK], Specialist_Name, Specialist_Address, Specialist_bankdetails)
Office Adminsitrator (Office Adminsitrator_ID [PK], Office Adminsitrator_Name, Office
Adminsitrator_Address, Office Adminsitrator_bankdetails)

16PRODUCT ANALYSIS REPORT
Payment (Payment_ID [PK], Payment_Invoice, Payment_Amount, Payment_Date)

17PRODUCT ANALYSIS REPORT
Bibliography
Borén, S., Nurhadi, L., Ny, H., Robèrt, K.H., Broman, G. and Trygg, L., 2017. A strategic
approach to sustainable transport system development–part 2: the case of a vision for electric
vehicle systems in southeast Sweden. Journal of Cleaner Production, 140, pp.62-71.
Dennis, A., Wixom, B.H. and Tegarden, D., 2015. Systems analysis and design: An object-
oriented approach with UML. John wiley & sons.
Fleming, Q.W. and Koppelman, J.M., 2016, December. Earned value project management.
Project Management Institute.
Gönen, T., 2014. Electrical Power Transmission System Engineering: Analysis and Design. CRC
Press.
Gupta, A.K., 2017. Response spectrum method in seismic analysis and design of structures.
Routledge.
Hailes, J., 2014. Business Analysis Based on BABOK® Guide Version 2–A Pocket Guide. Van
Haren.
Harrison, F. and Lock, D., 2017. Advanced project management: a structured approach.
Routledge.
Hau, C.C. ed., 2015. Handbook of pattern recognition and computer vision. World Scientific.
Hosseinichimeh, N., Kim, H., Ebrahimvandi, A., Iams, J. and Andersen, D., 2017. A Stakeholder
Analysis of Infant Mortality in Ohio: Key Behaviors and Their Formulations.
Jonasson, H., 2016. Determining Project Requirements: Mastering the BABOK® and the
CBAP® Exam. Auerbach Publications.

18PRODUCT ANALYSIS REPORT
Jouen, A.L., Ellmore, T.M., Madden, C.J., Pallier, C., Dominey, P.F. and Ventre-Dominey, J.,
2015. Beyond the word and image: characteristics of a common meaning system for language
and vision revealed by functional and structural imaging. NeuroImage, 106, pp.72-85.
Kan, T., Nguyen, T.D., White, J.C., Malhan, R.K. and Mi, C.C., 2017. A new integration method
for an electric vehicle wireless charging system using LCC compensation topology: analysis and
design. IEEE Transactions on Power Electronics, 32(2), pp.1638-1650.
Kerzner, H. and Kerzner, H.R., 2017. Project management: a systems approach to planning,
scheduling, and controlling. John Wiley & Sons.
Missonier, S. and Loufrani-Fedida, S., 2014. Stakeholder analysis and engagement in projects:
From stakeholder relational perspective to stakeholder relational ontology. International Journal
of Project Management, 32(7), pp.1108-1122.
Moon, S., Kim, B.C., Cho, S.Y., Ahn, C.H. and Moon, G.W., 2014. Analysis and design of a
wireless power transfer system with an intermediate coil for high efficiency. IEEE Transactions
on Industrial Electronics, 61(11), pp.5861-5870.
Phillips, C.L., Nagle, H.T. and Chakrabortty, A., 2015. Digital Control System Analysis &
Design. Pearson Prentice Hall.
Satzinger, J.W., Jackson, R.B. and Burd, S.D., 2014. Systems analysis and design in a changing
world. 7th Edition. Cengage learning.
Schwalbe, K., 2015. Information technology project management. Cengage Learning.
Valacich, J., George, J. and Hoffer, J., 2014. Essentials of systems analysis and design. Prentice
Hall Press.

19PRODUCT ANALYSIS REPORT
Wieschowski, S., Silva, D.S. and Strech, D., 2016. Animal Study Registries: results from a
stakeholder analysis on potential strengths, weaknesses, facilitators, and barriers. PLoS biology,
14(11), p.e2000391.

20PRODUCT ANALYSIS REPORT
Appendix Task A: Project Journal
Numbe
r
Date Activity Explanation Status
1 <<please
fill date>>
Selection of the case
study
A proper case study was selected for
making the assignment
Completed
2 <<please
fill date>>
Development of
stakeholder analysis
The project stakeholders would be
deployed for forming the analysis of the
supplementary development of the
activities.
Completed
3 <<please
fill date>>
Procurement of
system vision
document
A product vision document was made for
analysing the description, overview, and
features of the product developed
Completed
4 <<please
fill date>>
As-is flow diagram
development
The development of the as-is diagram
would be done while considering the final
operations of the case study
Completed
5 <<please
fill date>>
Developing product
backlog
A product backlog would list the key
requirements from the perspectives of each
of the users.
Completed
6 <<please
fill date>>
Use Case
Development
A use case was developed for the project
along with the descriptions and
with diagrams
Completed