Business Requirement Document
Corporate (Group) Health
Insurance Underwriting
Business Requirement Document_______________________________________1
1. Module Overview____________________________________________________________________1
2. Use Case Details_____________________________________________________________________1
Use Case ID:_______________________________________________________________________1
Screen / UI Requirements:________________________________________________________1
Business Rules_____________________________________________________________________2
Assumptions, Dependencies & Open Points_____________________________________2
Notes for Learners:________________________________________________________________2
Business Requirement Document
1. Module Overview
Module Name: Under Writing and Decision Flow.
Purpose: Show proposals and allow manual review to reach
final decision.
Scope: Maintains transparency across assessment and audit
steps.
High-Level Objectives:
2. Use Case Details
Use Case ID: 01
Use Case Name: Star Employee Login (Page 1)
Actors: Employee, Risk Evaluator, Audit.
Description: Each login navigates and provides respective data
for under writing.
Preconditions: They need to be the employee of the Star
Health Insurance.
Post conditions / Expected Outcome: Navigates them to their
respective dashboard for under writing review and
assessment.
Screen / UI Requirements:
Screen Name: Star Employee Login
pg. 1
Business Requirement Document
Purpose / Description: To make sure each employee has their
own role to for assessing the proposals and to store who
accessed which proposal with date and timestamp.
Fields / Elements:
Field Type Mandator Validation Comment
Name y s
Employee Page Yes Navigation
Login Page from main
page.
Employee Integer Yes Checks for
Id the correct
input type
Employee String Yes Checks for
Name the correct
input type
Role of the Selection Yes Checks if
Employee Box the role is
selected.
Login Button Yes It should
navigate to
respective
page
based on
role.
Business Rules
Validations:
If employee login is selected in main page it should
navigate to this page.
The employee id should be filled only in Integer.
The employee name should be filled only in String.
The employee role must be selected.
Constraints:
The employee id and employee name and employee
role must be present in the employee database to
proceed with login.
pg. 2
Business Requirement Document
Conditional Logic:
If either employee id or employee name or employee
role is not matching the data employee database
then it pops a message mismatch data.
If all the fields are not matching the data from the
employee data then it pops invalid data.
If all the data is matching it should navigate to
respective pages based on role of the employee.
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: Depends on the data from employee database.
Open Points / Questions:
Use Case ID: 02
Use Case Name: Employee Dashboard (Page 2)
Actors: Employee.
Description: In this page it contains all the proposals from the
database which are marked as under review.
Preconditions: Proposals data which have the status of under
review from the proposals database.
Post conditions / Expected Outcome: Navigates to under writer
dashboard.
Screen / UI Requirements:
Screen Name: Employee Dashboard
Purpose / Description: In this page it contains all the proposals
from the database which are marked as submitted.
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Proposal Box Yes It should
contain
proposal id
and company
name.
View Button Yes It should
navigate to
pg. 3
Business Requirement Document
the proposal
page.
Business Rules.
Validation:
The proposal box should contain proposal id and
company name.
Conditional Logic:
When view is pressed it should navigate to the
proposal page.
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: Proposals from the database marked as
submitted.
Open Points / Questions:
Use Case ID: 03
Use Case Name: Proposal Page (Page 3).
Actors: Employee.
Description: In this page the employee can view the full details
of the proposal to manually assess the proposal in real-time.
Preconditions: Proposal data from the proposal database.
Post conditions / Expected Outcome: Updates the status of the
proposal.
Screen / UI Requirements:
Screen Name: Proposal Page
Purpose / Description: This page is to generate the under
writing review of the proposal (Approved / Referred (under
review) / Rejected).
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Proposal ID Integer Yes It should not be
null
Company String Yes It should not be
pg. 4
Business Requirement Document
Name null.
Employee Integer Yes It should not be
ID null
Employee Integer Yes It should not be
Age null
Employee Char Yes It should not be
Gender null
Dependent Integer Yes It should not be
Count null
Risk Status String Yes It should contain
only Normal, Risk
and High-Risk.
Remarks / Text Box Optional NA
Negotiatio
n
Status Check Box Yes It should be
selected
Update Button Yes It should update
the status of the
proposal.
Business Rules
Validation:
Proposal id, Company name, Employee id, Employee
age, Employee gender and dependent as not null.
The risk status should only contain Normal, Risk and
High-Risk.
Conditional Logic: (Conditions apply based on module 3)
If the risk status if “Normal” or “Risk” it can be
approved and update the status of the proposal in
database.
If the risk status is “High-Risk” then it will add
“Yes” to “Referred” column in the proposal
database.
pg. 5
Business Requirement Document
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: It depends on the conditions form module 3 and
obtains the proposal data from the proposal database.
Open Points / Questions:
Use Case ID: 04
Use Case Name: Manual Risk Assessment Dashboard (Page 4)
Actors: Risk Evaluator
Description: This page contains only referred proposals.
Preconditions: Proposal should have “Yes” in referred column.
Post conditions / Expected Outcome: Navigates to Risk
Evaluator Review page.
Screen / UI Requirements:
Screen Name: Manual Risk Assessment Dashboard
Purpose / Description: This page contains only referred
proposals.
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Referred Box Yes It should contain
Proposal proposal id and
company name.
View Button Yes It should navigate
to the risk
evaluator review.
Business Rules
Validation:
The proposal box should contain proposal id and
company name.
Conditional Logic:
When view is pressed it should navigate to the Risk
Evaluator Review page.
Assumptions, Dependencies & Open Points
Assumptions:
pg. 6
Business Requirement Document
Dependencies: Depends on the referred column in database.
Open Points / Questions:
Use Case ID: 05
Use Case Name: Risk Evaluator Review (Page 5)
Actors: Risk Evaluator
Description: In this page the risk evaluator can view the full
details of the proposal to manually assess the proposal in real-
time.
Preconditions: Proposal should have “Yes” in referred column.
Post conditions / Expected Outcome: The database audit
review column should be marked as “Yes” and along with loss
ratio impact, claim history and premium adjustments.
Screen / UI Requirements:
Screen Name: Manual Risk Assessment Dashboard
Purpose / Description: In this page the risk evaluator can view
the full details of the proposal to manually assess the proposal
in real-time.
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Proposal ID Integer Yes It should not be
null
Company String Yes It should not be
Name null.
Employee Integer Yes It should not be
ID null
Employee Integer Yes It should not be
Age null
Employee Char Yes It should not be
Gender null
pg. 7
Business Requirement Document
Dependent Integer Yes It should not be
Count null
Risk Status String Yes It should contain
only Normal, Risk
and High-Risk.
Loss Ratio Percentage Yes The loss ratio is
calculated in
module 3.
Claim Total count Yes Claim history
history of claims. count only in
integer.
Premium Double Yes Provide in double
requested
Premium Double Yes Provide in double
allotted
Remarks / Text Box Yes It should be filled.
Negotiatio
ns
Submit Button Yes Update the audit
column to “Yes”.
Business Rules
Validation:
Proposal id, Company name, Employee id, Employee
age, Employee gender and dependent as not null.
The risk status should only contain Normal, Risk and
High-Risk.
Loss ratio is calculated in module 3.
Claim history count is only stored in integer.
Premium requested and allotted is stored in double.
Conditional Logic: (Conditions apply based on module 3)
Loss ratio, premium requested, premium allotted
and claim history count must be obtained.
Submit should update the audit column to “Yes”.
pg. 8
Business Requirement Document
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: Depends on the conditions from module 3.
Open Points / Questions:
Use Case ID: 06
Use Case Name: Audit Dashboard (Page 6)
Actors: Audit
Description: This page contains only proposals which are
marked for audit review.
Preconditions: Proposal should have “Yes” in audit column.
Post conditions / Expected Outcome: It should navigate to
Audit review page.
Screen / UI Requirements:
Screen Name: Audit Dashboard
Purpose / Description: This page contains only proposals which
are marked for audit review.
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Audit Box Yes It should contain
Review proposal id,
Proposals company name
and marked for
audit review.
View Button Yes It should navigate
to the audit
review page.
Business Rules
Validation:
The proposal box should contain proposal id,
company name and marked for audit review.
Conditional Logic:
When view is pressed it should navigate to the audit
review page.
pg. 9
Business Requirement Document
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: Depends on the referred column in database.
Open Points / Questions:
Use Case ID: 07
Use Case Name: Audit Verdict (Page 7)
Actors: Audit
Description: In this page the audit will review the proposals
based on the details of claim history, premium allotted,
premium requested and loss ratio along with remarks /
negotiations provided by the manual risk evaluator and it is
recorded real-time.
Preconditions: Proposal should have “Yes” in audit column.
Post conditions / Expected Outcome: Final status of the
proposals (Approved / Rejected)
Screen / UI Requirements:
Screen Name: Audit Review
Purpose / Description: In this page the audit can view the full
details of the proposal to manually assess the proposal in real-
time based on the data provided by the risk evaluator.
Fields / Elements:
Field Type Mandator Validation Commen
Name y ts
Proposal ID Integer Yes It should not be
null
Company String Yes It should not be
Name null.
Employee Integer Yes It should not be
ID null
Employee Integer Yes It should not be
Age null
pg. 10
Business Requirement Document
Employee Char Yes It should not be
Gender null
Dependent Integer Yes It should not be
Count null
Risk Status String Yes It should contain
only Normal, Risk
and High-Risk.
Loss Ratio Percentage Yes The loss ratio is
calculated in
module 3.
Claim Total count Yes Claim history
history of claims. count only in
integer.
Premium Double Yes Provide in double
requested
Premium Double Yes Provide in double
allotted
Remarks / Data Yes Remarks /
Negotiatio Negotiations from
n manual risk
evaluator.
Status Check Box Yes Select Approved /
Rejected.
Audit Text Box When When reject
Remarks reject the proposal is
proposal checked audit
needs to add a
remark on why it
got rejected.
Submit Button Yes Update the status
of the proposal
(Approved /
pg. 11
Business Requirement Document
Rejected)
Business Rules
Validation:
Proposal id, Company name, Employee id, Employee
age, Employee gender and dependent as not null.
The risk status should only contain Normal, Risk and
High-Risk.
Loss ratio is calculated in module 3.
Claim history count is only stored in integer.
Premium requested and allotted is stored in double.
Review of Remarks / Negotiations.
When audit rejects the proposal they should add the
remarks for the rejection.
Constraints:
The audit should review all the data and make the
decision of the proposal.
Conditional Logic:
Submit update the status of the proposal to
Approved / Rejected in the database.
Assumptions, Dependencies & Open Points
Assumptions:
Dependencies: Depends on the data provided by the risk
evaluator.
Open Points / Questions:
pg. 12