Health Insurance System

Controlled copy
Health Insurance System

Software Requirements Document
V 1.0
Prepared By Reviewed by Approved By

Name Rajeshwar Chary
Role Team member Project Leader/ Team Project Manager/ Team

Leader/ Team Leader
Member
Signature VS
Date 11/13/2014
Project ID: <Project ID. > <SCI.ID. > / Ver: <Ver No.>
Release ID: QTAD-SRDUC.doc / 1.0 / 11.11.2014 C3: Protected

Controlled copy Software Requirements Document
Table of Contents
1.0 Introduction 3
1.1 About this document 3
1.1.1 Purpose & Scope of the document 3
1.1.2 Intended Audience 3
1.2 About the Software System 3
1.2.1 Purpose 3
1.2.2 Scope of the system 4
1.2.3 Exclusions 4
1.2.4 System Perspective 4
1.2.5 System diagram 5
1.2.6 System Environment 5
1.2.7 User Characteristics 5
1.2.8 Impact of the System 6
1.2.9 Assumptions, Risks / Constraints 6
1.2.10 Design Constraints 6
2.0 System Requirements 7
2.1 Functional Requirements 7
2.1.1 Customer Register Module 7
2.1.2 Policy Registration Module 10
2.1.3 Admin Approval/Rejection 14
2.1.4 Edit Requirement 17
User Interface Requirements 18
2.1.5 Claiming policy Requirement 22
2.2 Nonfunctional Requirements 24
2.2.1 UI Requirements: Inn 24
2.2.2 Performance Requirements: Pnn 25
2.2.3 Installation, Deployment & Operational Requirements: Onn 25
2.2.4 Maintainability & Portability Requirements: MPnn 25
2.2.5 Security Requirements Snn: 25
3.0 Requirements / Use Case Summary Table 25
4.0 Make /Buy analysis 26

4.1 Reusable components 26
5.0 Annexure 26
6.0 Change Log 26
Health Insurance System <SCI.ID. > / Ver: <Ver No.>
Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 2 of 28

1.0 Introduction
1.1 About this document

1.1.1 Purpose & Scope of the document
The purpose of the software requirements document is to systematically capture
requirements for the project and the system Health Insurance System to be
developed. Both functional and non-functional requirements of this system are
captured in this document. It also serves as the input for the project scoping
The scope of this document is limited to addressing the requirements from a user,
quality, and non-functional perspective. It is recommended that design aspects are not
added in this document
1.1.2 Intended Audience

Project Team
1.2 About the Software System

The following section will cover aspects related to
Health Insurance System (HIS) policy will provide a cover to you and your family
against sudden medical contingency or bodily injury or Death.
1.2.1 Purpose
HIS is a system used for managing various activities such as customer registration,
Policy payment etc., In order to facilitate various policies to users.
The following are the modules in this proposed system
a) Customer Registration.
b) Policy Registration.
c) Admin Approval/Rejection.
d) Edit User Details and Renew/Edit Policy.
e) Claiming the policy.

1.2.2 Scope of the system

The scope of the system is explained through its modules as follows
Customer Registration Customer should register with his details into the
system before he logs in to the application.
Policy Registration - This module enables user to register the policy.
Admin Approval/Rejection -. This module is to validate the policy details

(i.e.) either approve or reject the policy.
Edit User Details and Renew/Edit Policy : To edit existing User details or
Editing or renew the Policies.
Claiming the policy - User can claim the policy. Admin need to check the
details of correctness and approve or reject accordingly.
Use Case Diagram
1.2.3 Exclusions
1. The system will operate only on the modules discussed above and will not include
any additional functionality.

1.2.4 System Perspective

The HIS is an independent software system developed to manage the activities like
customer registration, policy Registration, etc. using the Java/Dotnet architecture.
1.2.5 System diagram
1.2.6 Architecture diagram
Physical Architecture:
A physical architecture is an arrangement of physical elements, (system elements and
physical interfaces) that provides the designed solution for a product, service, or
enterprise. It is intended to satisfy logical architecture elements and system
requirements. Health Insurance System follows a three layered architecture namely
presentation layer, business logic layer and data access layer.
Presentation Tier is the tier in which the users interact with an application.
Presentation Tier contents Shared UI code, Code Behind and Designers used to
represent information to user.
Business Tier is mainly working as the bridge between Data Tier and
Presentation Tier. All the Data passes through the Business Tier before passing to
the presentation Tier. Business Tier is the sum of Business Logic Layer, Data
Access Layer and Value Object and other components used to add business logic.
Data Tier is basically the server which stores all the applications data. Data tier
contents Database Tables, XML Files and other means of storing Application Data.

Logical Architecture:
The Logical Architecture defines the Processes (the activities and functions) that are required to
provide the required User Services. Many different Processes must work together and share
information to provide a User Service. The Processes can be implemented via software, hardware,
or firmware. The Logical Architecture is independent of technologies and implementations

1.2.7 System Environment

The HIS application will be operated from the client server with parallel processor
support. When a user connects to the Web Server, the Web Server will interact with the
Database after processing the business logic to transfer data to and from a database.
1. Java/J2EE or .NET Framework application deployment.
2. My SQL/SQL server database for data storage
1.2.8 User Characteristics

The application should be user friendly; in such a way that the user would not need any
software and hardware knowledge. The user may be new to the client products having
never used them before.
The types of users likely to use the system are as follows,
1. Client
2. Delivery Assurance Group, Process Engineering group
3. Developers, testers, other associates in the project
1.2.9 Impact of the System

This is a new product which is developed for internal users. Expected impact of the
product is to automate existing manual processes in order to make them more efficient
and cost effective.

1.2.10Assumptions, Risks / Constraints

Assumptions:
1. The processing admin must possess prior knowledge on HIS operations undertaken
offline.
2. The admin should have the details of the policies and customers to be registered
/updated into the system.
Risks:
3. If there is any failure in payment processes, the system should be able to handle
such a financial risk.
1.2.11Design Constraints
1. The policy modules and the customer modules should remain independent, without
affecting Health Insurance System.
2. Application should have single login feature. Login functionality should be the
welcome feature for the application.
3. Only administrator and Customer can access the application with valid credentials.
4. None of the application features can be accessed without login.

2.0 System Requirements
2.1 Functional Requirements

2.1.1 Home Module
Health Insurance System Home Page

Req-2.1.1
Functional Requirements
When the users enter the following link http://localhost:8080/HealthInsuranceSystem in the
browser, Home page appears which will have a short welcome message; a brief introduction to the
purpose of the Health Insurance Process, the user can choose appropriate options.
Under home page, we need below interface.
Home page Interface Requirements
1. Admin
2. User
3. About Us
4. Contact Us
2.1.1.1 Customer Register Page

Health Insurance System Customer - Registration

Req-2.1.1.1
When the User/Customer clicks on the registration link, it should re-direct to registration form and
the HIS user need to fill some of the basic attributes/fields as mentioned below in requirement.
User Name ,Password, First Name, Last Name, Age, Gender (Male or Female) ,Contact Number
E-mail, Address, pin code, City.
At any given point of time, the user can Deselect/Reset all or can go to home page by the clicking
home.
User Interface Requirements

1. Name - Name of the Customer.
2. Password Represents the customer password.
3. Address Represents the Customers Address.
4. City Represents the Customers City.
5. State Represents the Customers State.
6. Country Represents the Customers Country.
7. Pin Code Represents the customers Pin Code.
8. Email Address Represents the customers Email Address.
9. Gender Represents the customers Gender.
10. Contact No Represents the customers Contact Number.
11. Date of Birth Represents the customers Date of Birth.
12. Customer Type Represents the type of customer (Normal or Patient)
13. Customer ID Represents the Generated Customer ID.
14. There should be 2 buttons i.e. Register, reset
Trigger
Customer should register into the system before he logs in to the application
Post Conditions
The system should find weightage of the customer, generate the customer id and stored along
with the customer details.
Success End Condition
On success a message should be displayed Customer Registered successfully
Failed End Condition

The system should throw an error message if one of the validations is wrong. The error
message and error code needs to be identified during design.
The validation and business rules are mentioned in the business rules section.

Steps & Actions

1. System should display all the necessary details.
2. Get all the necessary information.
3. On register or Update the system needs to calculate the weightage based on the customer
type.
4. Identify the priority based on the customer type details as follows
Customer Type Priority
Normal Normal
Patient High
1.
5. Generate the customer ID as follows.

Customer ID= current year (4 digit) +current month (2 digit) +unique number (4 digit).
Example: 2012055001.
6. Store the details into the system
Business Rules & Validations
The name should contain only alphabets and space.
Password should contain at least one lowercase, one uppercase and one digit.
Pin code should be 6 digits.
Contact no should be 10 digits.
Email id should be in a valid format ([email protected]).
Age should not be above 90 years.
All details are mandatory.
Address should not contain special characters other than white space. Blank not allowed
At the time of registration, the following task needs to be done:
Generate the customer number. (Refer above row)
Update the above details automatically into the database along with the customer details.
2.1.2 Policy Registration Module
2.1.2.1 Policy Registration Page

Health Insurance System Policy Registration Page

Req-2.1.2.1
After the user log in and click the policy registration link, it should re-direct to policy registration form
where the user needs to fill some of the basic attributes/fields.
Any given point of time, the user can deselect all or can go to home page by the clicking home.

1. Insurance Name - Insurance name should be filled
2. Policy amount - Policy amount to be entered by the user
3. Policy duration - Policy duration to be entered by the user
4. Premium type - Premium type to be entered by the user
5. Policy start date -Policy start date to be entered by the user
6. Discount -Enter the Discount percentage
7. Premium Amount Enter policy Premium amount
8. Maturity Date - Enter the Maturity Date
Trigger
Users triggers the functionality once he/she register his details in the system.
Pre-Conditions / Assumptions
The admin should have the details of all the client policies existing in the system.
The user should login with his credentials (Customer Id/password)
Post Conditions
The premium, discount amount and maturity date of the policy will be calculated and stored
along with the client policy details.

On success, a message should be displayed Policy Registered successfully and in same page
should be shown with Policy No, Premium Amount, and Maturity Date
The system should throw an error message if one of the validations fails. The error message
and error code needs to be identified during design.
The validation and business rules are mentioned in the business rules section.

Steps & Actions

1. System should display all the necessary fields in the screen.
2. The minimum age for the policy holder should be greater than to Zero.
3. System should calculate the premium based on the policy amount and discount.
Discount can be considered based on weightage, and maturity date based on duration.
4. System should store the policy details into the system.
5. Identify the Insurance ID based on the policy amount and term/duration details as
follows:
INS_Type INS_NAME
PHC_001 Physical condition
ACC_002 Accident related
OCC_003 Occupational related
ERC_004 Environment related
LSC_005 Life style related
TRC_006 Travel related

6. Identify the discount Weightage of the policy based on the policy term/duration as
follows:
INS_Type POL_AMOUNT DURATION

PHC_001 300000 15
PHC_001 500000 20
ACC_002 300000 15
ACC_002 500000 20
OCC_003 200000 15
OCC_003 400000 20
ERC_004 200000 10
ERC_004 400000 20
LSC_005 300000 15
LSC_005 500000 25
TRC_006 300000 15
TRC_006 500000 25

7. The premium amount will be calculated based on the policys amount, weightage and
premium type.
PREMIUM_TYPE WEIGHTAGE PERCENTAGE

HY W1 1%
Y W1 2%
HY W2 2%
Y W2 4%
HY W3 3%
Y W3 5%
(HY Half Yearly, Y- Yearly )
For Quarterly (Q) paid premium the weightage percentage is always constant at 0%.
8. Calculation the Premium Amount
Find the weightage percentage and Premium Type : Premium Type(Y=1, HY=2 and Q=0)
Discount amount= ((policy amount /duration) / Premium Type) * weightage percentage
Premium Amount = Policy Amount - Discount Amount
9. The maturity date calculated based on the duration of policy.
Calculate the Maturity Date
Find out the duration of policy
Maturity Date = System Date+ Duration

Business Rules & Validations:
All fields are mandatory.

The policy id should be automatically generated by the system and it should be 4 digits long.
Policy amount should be coming from respective table for the selected policy name.
Policy maturity date should not be less than or same system date.
During the registration following tasks needs to be done:
o Retrieve the duration based on amount.

o Retrieve the weightage based on duration.
o Discount will be calculated based on Weightage Percentage.
o Premium Amount will be calculated.
o Maturity Date will be calculated.
2.1.3 Admin Approval/Rejection
2.1.3.1 Approval Page

Health Insurance System Admin Approval Page
Req-2.1.3.1
Admin logs into the system and views all the policies which are yet to be approved.

9. Approve Button and Reject Button.
Trigger
Admin triggers the functionality when he logs into the system and views all the policies
which are yet to be approved.
User should register a policy and policy id should be generated for him.

Post Conditions
The Admin should validate the policy details and approve the policy.

On success, a message should be displayed policy approved successfully

message and error code needs to be identified during design. The validation and business
rules are mentioned in the business rules section.
Steps & Actions

1. Admin should select from the existing policies present in the system.
2. Complete information details of the selected policy should be displayed.
3. If the displayed data is valid then admin will approve the policy.
Business Rules & Validations

Insurance Name, Policy Amount, Premium amount, discount amount and maturity date cant
be empty.
Calculated Premium amount shouldnt be greater than policy amount.
Maturity date cant be less than policy start date.
If the above conditions are met then Admin will approve the policy and status to be shown
approved.
2.1.3.2 Admin Rejection Page:

Health Insurance System Admin Rejection Page
Req-2.1.3.2
Fraud and misrepresentation can increase in insurance premiums and at Health Insurance System we
are passionate about protecting our customers. By validating Health insurance policies, we know we
are providing you the fairest price for your insurance, and that information we hold is correct.
If Admin find the Health Insurance Policy details are incomplete or wrong information then it
will be rejected by Admin.
Health Insurance System requirement differs from person to person from various factors this is
why there are various plans that clients can avail.


9. Approve Button and Reject Button.
User should select a policy and policy id should be generated for him.
Post Condition
The Admin should validate the policy details and Reject the policy.

On success, a message should be displayed Policy Rejected

The system should throw an error message if one of the validations is wrong. The error message
and error code needs to be identified during design. The validation and business rules are
mentioned in the business rules section.
Steps & Actions
Complete information details of entered policy no should be displayed. If the displayed data is not valid
then admin will reject the policy.
Reasons for Admin rejecting the policy

If Insurance Name, Policy Amount, Premium amount, discount amount and maturity date are empty
then admin can reject the policy.
If Calculated Premium amount is greater than policy amount then admin can reject the policy.
If Maturity date is less than policy start date then admin can reject the policy.
Example :
Policy_Id 1002
Physical
Ins_Name
condition
Policy_Amount 300000
Policy_Duration 15
Premium_type HF
Discount 0
Premium_amoun
300000
t
Policy_StarDate 6/10/2014
Policy_Maturity
6/10/2014
Date
Status Rejected
Note: Here Maturity date is equal to policy start Date. So the policy was rejected by admin

2.1.4 Edit Requirement
2.1.4.1 Edit User details Page

Health Insurance System Edit User Details Page
Req-2.1.4.1
After the user log in User should be able edit his own details.
For completing the edit user details the following parameters needed to be updated:
1. Password The Customer should enter the password

2. Email-ID Represent the customer Email-ID.
3. Phone No Represent the customer phone number.
4. Name Customer should enter his name.
The User should have already entered his details and logged into the system
Post Conditions
The User can edit his name or email-id or contact no or password and save the details.
On success a message should be displayed details have been saved successfully

Steps & Actions
Once the user login into the system display an edit option.
If the user clicks edit button, name, email-id, contact no, password fields should be
editable.
Update these editable details into the system
2.1.4.2 Edit Policy Page

Health Insurance System Edit Policy Page
Req-2.1.4.2

User can only Edit the policy which is in pending status .User should not be able to edit the policies
which are approved / rejected.
The following fields can be editable.
Policy Amount - Represent the policy Amount
Policy type - Represent the policy type.
Weightage Represent the duration of policy.
Trigger
Administrator triggers the functionality once he/she receives the details of the Customer.
The User should have existing registered policy.
Post Conditions
The premium of the customer will be calculated and stored in the system.
On success a message should be displayed Policy Updated Successfully

Steps & Actions
System should display all the necessary fields in the screen.
Premium amount should be calculated automatically (based on the policy amount and discount and
weightage) after alerting the premium_type and submitting the data in the system.
System needs to store the altered policy details into the system.
1. Identify the Insurance id based on the policy amount and duration details as follows:
2. Identify the discount Weightage of the policy based on the duration as follows:
DURATION DISCOUNT_WEIGHTAGE
15 W1
20 W2
25 W3

3. The premium amount calculation logic is as follows. The premium amount will be
calculated based on the policys amount, weightage and premium type
PREMIUM_TYPE WEIGHTAGE PERCENTAGE

HY W1 1%
Y W1 2%
HY W2 2%
Y W2 4%
HY W3 3%
Y W3 5%
HY Half Yearly, Y- Yearly
4. For Quarterly (Q) Paid premium the weightage percentage is always constant at 0%
Calculation of Premium Amount
5. Find the weightage percentage and Premium Type
Discount amount= ((policy amount/duration) / Premium Type) * weightage percentage
Premium Amount = Policy Amount - Discount Amount

1. Edit Policy
a. The policy Number cant be Left Blank.
2. Edit Customer Policy
a. Policy Number should be accepted and need to check in the system.
b. Insurance ID should not be editable in the system.
c. Issue Date should not be editable and must be populated automatically.
d. Premium Type is editable and based on selected Premium Type policy amount has
to be calculated and saved into the system.
2.1.4.3 Renew Policy Page:

Health Insurance System Renew Policy Page
Req-2.1.4.3
User can Renew the policy if policy maturity date is about to expire i.e. less than 15 days from the
current date. Then user can renew the policy.

1. Policy id The Customer should enter the policy id

2. Insurance Type- Represent the Unique number of the insurance.
3. Policy Renew Date - The customer should enter the Renew Date
4. Policy Amount- Represent the amount a client id opted for the policy.
5. Duration- Represent the time duration of the policy to be counted as matured.
6. Premium Type Represent premium type details.
Trigger
User can Renew the policy if it policy maturity date is about to expire i.e. less than 15 days
from the current date.
User should have a policy approved by admin.
Post Conditions
User policy should be renewed and should be pending for approval from admin.

On success a message should be displayed Renewed successfully

Steps and Actions
This should capture the following fields

Policy No-The Policy Number Of The client.
Renew Policy: The policy No cant be Left Blank.

Renew Customer Policy: Policy No should be accepted and need to check in the system. If it is
valid policy No then user can be able to renew the respective policy.
2.1.5 Claiming policy Requirement
2.1.5.1 Put a Claim Page

Health Insurance System Put A Claim Page
Req-2.1.5.1

User requests for claiming a policy, and then Admin verifies all the details and
approves/Rejects the claim.
Trigger
A user triggers the functionality once he/she decide to a claim policy.
The user should have a policy which has been approved by the Admin.
Post Conditions
The claim amount will be calculated and stored into System

On success a message should be displayed Claim Requested successfully


Steps & Actions:

1. System should display all the necessary fields in the screen.
2. Checking the Health risk Scenarios.
3. Check the Death Certificate is available
4. On clicking claim the system needs to calculate the claim based on the Bonus and Type
of Death
5. Calculating the Claim Amount, Retrieve the Amount
I. If type of Death is Natural Whatever the claim policy we opted the total amount
will come
II. If type of Death is Accidental The amount will be double of opted Claim
III. If type of Death is Occupational related. The amount will be double of opted Claim
IV. If type of Death is Environment related. The amount will be double of opted Claim
V. If type of Death is Life style related. The amount will be double of opted Claim
VI. If type of Death is Travel related.The amount will be double of opted Claim
Type Of Claim POL_AMOUNT Amount

Death 300000 300000
Accidental 300000 600000
Occupational 500000 1000000
Environment 500000 1000000
Life style 600000 1200000
Travel 600000 1200000
6. Calculation of Bonus:
We need to get the date when actually he bought the policy
Based on The date calculate how many years old the policy is and store in variable no of
_years;
Then Bonus is
Bonus=no_of_years*(amount * 0.01)
Claim_amount=Retrieve the amount+Bonus;
All Fields are mandatory except police Verification Document

Death certificate is always Required
If Accidental Death Case Police Verification Document is required
If Occupational, Environment, Lifestyle & Travel police verification document is required.

2.1.5.2 Claim Approve/Reject Module

Health Insurance System Claim Approve/Reject Module
Req-2.1.5.2
User requests for claiming a policy, and then Admin verifies all the details and approves/Rejects the
claim.
Once user submits the claim admin approves/Reject the claim.
1. Name The Customer should enter the name.

2. Policy NoPolicy number of the customer.
3. Claim Type Represents with Natural Death,
4. Accidental Death, Occupational, Environment, Lifestyle & Travel
5. Death Certificate: Represents Death Certificate is there or not
6. Police Verification Document Represents Document is there
Trigger
Admin triggers the functionality once he/she decide to an Approve/Reject a claim.
The user should have a policy which has been approved by the Admin and opted for a claim.
Post Conditions
The admin will approve/Reject the claim based on claim amount requested by the user.
Success End Condition: On success a message should be displayed Claim Approved/Rejected
successfully
Steps and Actions
1. Admin calculates the claim amount and verifies with claim amount requested by the user if
both are same he will approve the claim or else rejects the claim.
2.2 Nonfunctional Requirements

2.2.1 UI Requirements: Inn
1. The front end should be user-friendly and pleasant
2. Any error message or exception displayed to the user should be user-readable (and
not technical)

3. All entered values should be validated

4. The UI screens are designed with any theme color along with the logo of the
company.
5. Exceptions should not be shown on console.
6. No debug message should come on console.
7. All the errors and exceptions should be logged to log file.
8. Log file path should be configurable.
9. Database connections should be configurable.
10. It should not be hard coded.
11. Requirements involving UI features should be taken care in console accordingly
2.2.2 Performance Requirements: Pnn

1. All front-end pages should be served up in less than 5 seconds post click when up to
1000 users are on the application concurrently.
2. Since its a financial operations application, transactions should be safe and fast.
2.2.3 Installation, Deployment & Operational Requirements:

Onn
1. Application Java and J2EE deployment with My SQL database or SQL Server
database for persistence
Or
Application .NET Framework deployment with SQL Server database for persistence
2. This system must be up 24X7
2.2.4 Maintainability & Portability Requirements: MPnn

1. If the allocated memory space for the existing application needs to be increased then
it should be possible without any impact to performance
2.2.5 Security Requirements Snn:

1. No unauthorized users should be able to log on to the system
2. User Id/Login Id should have combination of letter and numeric values, none of the
special characters are allowed (#,@,$,%,&).
3. Validate the user id/login id and password, accordingly to the user it will redirect to
the appropriate page.
3.0 Requirements / Use Case Summary Table
Business Software Short Requirem Priority Complexity Requireme Remarks

Requirem Requiremen ent

ent ID ts ID Description Provider nt type

(Originat
or)
BR001 SR001 Customer Client High Medium UI screen -

Registration &
backend
processi
ng
BR002 SR002 Policy Client Medium Medium UI screen -
Registration &
backend
processi
ng
BR003 SR003 Admin Client High Medium UI screen -
Approval/Re &
jection. backend
processi
ng
BR004 SR004 Edit User Client Medium Medium UI screen -
Details and &
Renew/Edit backend
Policy. processi
ng
BR005 SR005 Claiming Client High High UI screen -
the policy &
backend
processi
ng
4.0 Make /Buy analysis
4.1 Reusable components

The HIS can be made reusable as such to handle various Health Insurance Policies.
5.0 Annexure
NA

6.0 Change Log

Please note that this table needs to be maintained even if a Configuration Management
tool is used.
Version Changes made

Number
V1.0 First version developed by Rajeshwar Chary V on Nov 22 2014.
V1.1 <If the change details are not explicitly documented in the table below,
reference should be provided here>
Page Changed Effectiv Changes effected

no by e date
V1.2 <If the change details are not explicitly documented in the table below,
reference should be provided here>
Page Changed Effectiv Changes effected

no by e date

Health Insurance System - SRD

Uploaded by

Copyright:

Available Formats

Health Insurance System - SRD

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Health Insurance System - SRD

Uploaded by

Copyright:

Available Formats

Controlled copy

Prepared By Reviewed by Approved By

Role Team member Project Leader/ Team Project Manager/ Team

Release ID: QTAD-SRDUC.doc / 1.0 / 11.11.2014 C3: Protected

4.0 Make /Buy analysis 26

6.0 Change Log 26

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 2 of 28

1.1 About this document

1.1.2 Intended Audience

1.2 About the Software System

The following are the modules in this proposed system

d) Edit User Details and Renew/Edit Policy.

e) Claiming the policy.

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 3 of 28

1.2.2 Scope of the system

Policy Registration - This module enables user to register the policy.

Admin Approval/Rejection -. This module is to validate the policy details

Use Case Diagram

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 4 of 28

1.2.4 System Perspective

1.2.5 System diagram

1.2.6 Architecture diagram

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 5 of 28

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 6 of 28

1.2.7 System Environment

1.2.8 User Characteristics

The types of users likely to use the system are as follows,

2. Delivery Assurance Group, Process Engineering group

3. Developers, testers, other associates in the project

1.2.9 Impact of the System

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 7 of 28

1.2.10Assumptions, Risks / Constraints

4. None of the application features can be accessed without login.

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 8 of 28

2.0 System Requirements

2.1 Functional Requirements

Health Insurance System Home Page

2.1.1.1 Customer Register Page

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 9 of 28

User Interface Requirements

Failed End Condition

Health Insurance System <SCI.ID. > / Ver: <Ver No.>

Release ID: QTAD-SRDUC.doc / 1.0 / C3: Protected Page 10 of 28

Steps & Actions

Customer Type Priority

5. Generate the customer ID as follows.

2.1.2 Policy Registration Module

2.1.2.1 Policy Registration Page

Health Insurance System <SCI.ID. > / Ver: <Ver No.>