[Product] Business Requirement Document

Clarity
Plan Management Portal
Business Requirements Document

Version 20190613.#
[Product] Business Requirement Document

Confidentiality
© Copyright 2019 Softheon Inc. All rights reserved.

Trademarks
Softheon and Softheon logo are trademarks of Softheon Inc. Trademarks and trade names owned
by third-parties may be referred to herein and are the exclusive property of the respective owners.

Confidentiality
The content of this document is confidential and the property of Softheon; this document may not
be copied or disclosed without the written consent of Softheon.

This Document is valid as of its publication date, please be aware that industry standards and
regulations change and improve rapidly and Softheon is not responsible for updating or
reissuing this Document as such changes occur.

ii

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Version and Approvals

UTORS
Version Date Summary of Change Completed by Reviewed by
1 Initial document Softheon

This document has been approved as the official Business Requirements Document for [Product]
and accurately reflects the current understanding of business requirements. Following approval of
this document, requirement changes will be governed by the project’s change management
process, including impact analysis, appropriate reviews, and approvals.

Approver Name Project Role Signature/Electronic Date

Approval

iii

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Table of Contents
Confidentiality .................................................................................................................................................................... ii

Version and Approvals .................................................................................................................................................... iii

Details ....................................................................................................................................................................................1

Resources .............................................................................................................................................................................1

Glossary of Terms .............................................................................................................................................................. 2

Overview .............................................................................................................................................................................. 2

Background ........................................................................................................................................................................................ 2

Purpose ................................................................................................................................................................................................ 2

Policy and Technical Requirements .............................................................................................................................. 3

Summary ............................................................................................................................................................................................. 3

Policy Requirements ........................................................................................................................................................................ 3

Technical Requirements ................................................................................................................................................................. 4

Project Overview................................................................................................................................................................ 4

Project Scope ..................................................................................................................................................................................... 4

In Scope Functionality..................................................................................................................................................................... 4

Project Dependencies ..................................................................................................................................................................... 4

Stakeholders....................................................................................................................................................................................... 5

Key Assumptions and Constraints ................................................................................................................................ 5

Critical Success Factors ................................................................................................................................................................... 5

Assumptions.................................................................................................................................................................................. 6

Constraints ..................................................................................................................................................................................... 6

Risks ................................................................................................................................................................................................. 6

Use Case Diagram ............................................................................................................................................................. 7

Use Cases ............................................................................................................................................................................. 8

Scenarios ............................................................................................................................................................................................. 8

References ......................................................................................................................................................................... 10

Appendix ........................................................................................................................................................................... 10

iv

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Details
Project Name Plan Management Portal

Project Type PMP

Project Start Date 06/10/19

Project End Date TBD

Project Sponsor (The initial requestor and source of requirements)

Primary Driver Primary company working to drive the project forward (e.g. Softheon)

Secondary Driver Secondary groups involved in delivering the solution (e.g. Project Sponsor)

Division Softheon Division (e.g. Broker Solutions, Government Solutions)

Project Manager/Dept Project Sponsor lead department/point of contact

Resources
Name Role Contact

<Identify all internal/ <Identify Role of stakeholder> <Identify contact information, if

external stakeholders applicable. Usually email address>
and resources
involved in gathering
requirements>

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Glossary of Terms
Term/Acronym Definition

PMP Plan Management Portal

CMS Center for Medicare and Medicaid Services

SSO Single Sign On

DB Database

Overview
Background
The Plan Management Portal will be used as a platform for carriers to log onto and upload any
plan information documents that they need the client-facing side to see. In addition to uploading
documents, they will be able to manage and edit these documents if need be, as well as view any
existing documents that have been previously uploaded by the carrier. One of the most prominent
pain points of the current platform is that if carriers want to make changes to these documents,
they are required to download a Microsoft Excel template that obtains all of the information
regarding their plans and benefits, manually edit it, then convert it to an XML file and send it to
CMS for verification that the information is valid. This process is clearly very manual and through
this new iteration, we would like to automate it. Once this process is automated, this will mitigate
the issues that both carriers and Softheon developers have. Because this product will empower
carriers to manage their own documents and have authority over what content/information is
being put out, this will ensure that clients of these agents will be receiving the most
updated/accurate information regarding their plans on the shopping portal. Overall, the experience
for carriers and clients will be improved immensely through PMP.

Purpose
The purpose of the Plan Management Portal is to diminish the manual processes that carriers and
backend Softheon services are required to perform when these agents need to upload or make
edits to already existing plan information. As mentioned in the Background, the current platform
includes a very manual process. Carriers must download an Microsoft Excel template that contains
the information on their plans/benefits and make edits onto the excel sheet. After they have made
these changes they must convert the contents from the excel sheet into XML file and send it over
to CMS. After CMS confirms that the information that was changed on the document is valid, they
will send it to Softheon and have the changes be pushed for the client-facing side to view. The
primary objective of this portal is to automate this process. Additionally, to increase productivity

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

and make the portal even more efficient, the next step would be to allow both carriers and CMS
representatives to work concurrently on the same platform so the verification process can be
streamlined. Then PMP could also have a progress indicator to know what step CMS is in terms of
verification and when everything if finalized on CMS’ end, carriers can get notified. Also, the
repository feature

Policy and Technical Requirements

Summary
The Plan Management Portal consists of the following properties: SSO system that is used for
carriers to log in and get access to the platform, a home page that has a dashboard that presents
the carrier with the various pages they can navigate to, and an account settings/profile tab. For the
dashboard, the different pages that the carrier can go to basically outlines the various
functionalities of this portal. The first page would be the “Upload Documents” page where carriers
can select necessary files either from their computer, google drive, dropbox, etc. to upload to the
PMP. Another page would be the “View Documents” page that carriers can go to to look at all of
the documents they have uploaded. Finally, the last page that carriers will go to is the
“Manage/Edit Documents” page. This page will showcase all of the various files the carrier has put
on the portal and give them the ability to edit any of the given files. In terms of managing these
files, agents will be able to delete any of the documents they have uploaded on this page. Also,
there will be a repository that will hold all iterations of each document in case the carrier wants to
revert back to an older version of the document or reference it at some point.

Policy Requirements
<These are non-technical requirements that must be followed for the project. They could affect
project features and availability and should be kept in mind continuously once product
development is underway. Requirements may be displayed as a table or split into sub-section with
additional details as desired. Possible policy requirements could include: legal requirements;
contract requirements; limitations on the system; availability of resources; accessibility; security;
etc.>

Example: The BRD should be written in English. The document should be spell-checked before review.
The document should be communicated via email or direct transfer between the stakeholders. One
author should be the main owner of the document in order to track updates and changes. The final
document should be approved by representatives of all stakeholders in order to be approved.

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Technical Requirements
The primary technical requirements for the PMP would be to create a backend system that
automates the current manual processes. For example, the process of importing files would need
to be automated. Additionally, providing the carriers with a UI similar to that of Softheon Web
where they can make changes to their plan information would effectively improve the user
experience. Once these edits are made, the information on the portal should be connected to our
backend system and have the database for the carrier save all of the information that was
uploaded. The DB should be updated routinely so any changes that carriers make can be updated
on our end as well. Also a set of rules would need to be created to determine what edits carriers
can make onto these documents. We would need to confirm the file type that would be acceptable
by CMS.

Project Overview
Project Scope
Having carriers upload files themselves onto our portal and view all of them in one platform would
be phase 1 of this project.

In Scope Functionality

Requirements Details:
SSO User authentication that gives access to portal;
forgot username/password feature here
Dashboard Quick access to the various pages the carrier
can go to – uploads, manage/edit, view,
repository
Account Settings tab Navigates carrier to their account profile and
details; carriers can make changes to their
password here;
Upload Docs page Carriers can browse through their computer,
google drive, dropbox, etc. to choose a file to
upload

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

View Docs page Once carriers upload doc, they can view their
submission here; date and time of submission
should be present here
Manage/Edit Docs page Docs can be deleted here; carriers can make
edits to docs;
Save changes Under the Manage/Edit docs page, carriers can
save any changes they made to their
documents
Submit document After they finish editing the document and
have saved all new changes, they will be able
to submit the document and the newest
version of the document will now be present in
the portal
Repository A repo that contains all iterations of each
document will be present in the home page
dashboard. Carriers can revert back to a
previous iteration if needed. Date and time of
each version will be present

Project Dependencies
Stakeholders
<List the stakeholders of the project. According to the Project Management Institute (PMI), the
term project stakeholder refers to, "an individual, group, or organization, who may affect, be
affected by, or perceive itself to be affected by a decision, activity, or outcome of a project" (Project
Management Institute, 2013). This may be duplicated from the Primary Sponsor, Primary Driver,
and Secondary Driver, but could include additional stakeholders.>

Example: The following comprises the internal and external stakeholders whose requirements are
represented by this document:

1. <ClientShortName>
2. Softheon

Key Assumptions and Constraints

Critical Success Factors
<This is a list of business factors that are necessary for project completion.>

Example: The following factors have been identified as being critical to the success of this Project:

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

1. The author will have the support and time to write the BRD
2. The author is given in a timely manner any information required for the business
requirements

Assumptions
<List the main assumptions made for this project. Can be a list or a table. The section is optional,
supplements the critical success factors.>

Example:

1. The author of the document knows English.

2. The author has access to Microsoft Word or another word processor.
Constraints
<List the main constraints made for this project. Can be a list or a table. The section is optional,
supplements the critical success factors.>

Example:

1. The document will not contain secure or technical information.

2. The document will not describe technical details about how the product should work, only
what it is expected to do.

Risks
<List the risks or unknowns related to this project. Can be a list or a table. The section is optional,
supplements the critical success factors.>

Example:

1. Not all information may be available upon initial requirements gathering.

2. Stakeholders may leave the project or be replaced during the project and will need to be
familiar with these requirements.

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Use Case Diagram

Carrier log View home

onto PMP page
Carrier
Dashboard that
shows different
pages the carrier
can access

Upload
Manage/
Documents View Repository
Edit
Documents
Documents

Carrier manually Carrier can view all

uploads plan info file iterations of docs and
here Carrier can manage/
Carrier can view all revert to previous
make changes to
existing uploads here versions here
existing uploads here

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

Use Cases
<Instructions for completing the Use Case Narrative are included below. These should match the Use Case diagram above.>

Instructions:

ID Number – Give each use case a unique numeric identifier, in the hierarchical form: X.Y. Related use cases can be grouped in the hierarchy.
Functional requirements can be traced back to a labeled Use Case.

Scenario – State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system.
Include an action verb and a noun. Some examples: Login; Shop for Plans; Submit Enrollment; Validate Data; etc.

Scenario Description – Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of
actions and the outcome of executing the Use Case. Include the actor (the person or entity that will perform the use case).

Scenarios
<Include the scenarios in the table below. Additional Scenario sections can be created depending on the complexity of the proposal. Scenarios
may be grouped into sections depending on complexity.>

ID
Scenario Scenario Description
Number

1 Uploading files 1. Navigate to “Upload Docs” page on PMP

2. Select method of upload – from computer, google drive,
dropbox, etc
3. Submit upload

2 Viewing uploaded files
1. Navigate to “View Uploads” file to look at any previously
uploaded documents
2. After you upload documents via the “Upload Docs” page, you
can confirm that the file has been uploaded by going to the
“View Uploads” page

Softheon. Confidential, do not distribute.

[Product] Business Requirement Document

ID
Scenario Scenario Description
Number

3 Manage/Edit Uploads 1. You can delete any uploads on this page

2. If you want to make changes to any existing documents that
have been uploaded to the portal, you can do it on this page
3. When you make edits, there will be a save changes button
4. After you are done editing, you can submit the d

4 Repository 1. Can view all iterations of any uploaded documents carrires

have put on the portal
2. If need be, carriers can revert back to a previous version of
an upload

Softheon. Confidential, do not distribute.

Insert title

References
<Include links to online resources or references used to create the information in this proposal.
Optional.>

Example:

1. Softheon Product Documentation

Appendix
<Optional section with additional information related to the proposal that does not fit in the
sections above. May include supplemental information that is useful to have but would otherwise
bloat the sections above. Should be split into different sections for different topics.>

10

Softheon. Confidential, do not distribute.