SRS Claims Management System

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 9

1

Claims Management System


Software Requirement Specification
Content
Section 1 – Introduction...................................................................................2

1.1 Purpose of the Document.......................................................................2


1.2 Scope of the Document..........................................................................2
1.3 Need and significance of the project....................................................2
1.3.1 Proposed Solution................................................................................3
1.4 Definitions, Acronyms and Abbreviations............................................3
1.5 References...............................................................................................3
1.6 Revision History......................................................................................3
1.7 Contact Information................................................................................3
1.8 Overview of the Document.....................................................................3

Section 2 – General Description......................................................................4

2.1 User Personas and Characteristics.......................................................4


2.2 Project Perspective.................................................................................4
2.3 Overview of the Functional Requirement.............................................4
2.4 Overview of Data Requirement..............................................................5
2.5 General Constraints, Assumptions, Dependencies and Guidelines. 6
2.6 User View of Project Use........................................................................5

Section 3 – Specific Requirements.................................................................6

3.1 External Interface Requirements...........................................................6


3.2 Detailed Description of Functional requirement:.................................6
3.3 Performance Requirements...................................................................7
3.3.1 Speed and latency requirements........................................................8
3.3.2 Considerations for speed....................................................................8
3.3.3 Safety critical requirements................................................................9
3.3.4 Reliability and Availability requirements...........................................9
3.3.5 Robustness Requirements..................................................................8
3.3.6 Capacity Requirements.......................................................................9
3.3.7 Scalability Requirements.....................................................................9
3.4 Quality Attributes....................................................................................9
3.5 Other Requirements..............................................................................10
2

Section 1 – Introduction

1.1 Purpose of the Document

The Software Requirements Specification (SRS) is the first step in the


requirement analysis process. The SRS lists the requirements of a particular
software system, including functional, performance, and security requirements.
The SRS also provides usage scenarios from a user, an operational and an
administrative perspective.

The purpose of this SRS document is to provide a detailed overview of


our software project, its parameters and goals. This document describes the
projects target audience and its user interface, hardware and software
requirements. It defines how our client, team and audience see the project and
its functionality.

1.2 Scope of the Document

The scope of the document describes project requirements definition


efforts, the requirements elicitation team including users, customers, system
engineers and developers.
This section also provide details on any constraints that were placed upon
the requirements elicitation process, such as schedules, cost, or the software
engineering environment used to develop those requirements. This will provide
the brief description of the project.

1.3 Need and significance of the project

The newly developed project is on claims in a factory, office and workplaces


and termed their project as “Claims Management System”. The proposed
software concern for anyone is not to waste time and get what they are searching
for in a quick and efficient manner. This project deals with claims of money for
the workers in a particular concern.

This project involves the Workers, Database admin, Site admin and Finance
admin in a particular concern for claims management.
3

The Scope of this project is to enter, edit, search, view and delete the
details of the information’s about claims in a concern.

1.3.1 Proposed Solution

 The newly proposed solution is a “Claims Reimbursement System” based


on ASP.NET for the Administrator and users in a particular concern.

1.4 Definitions, Acronyms and Abbreviations

ASP.NET Active Server Page Dot Net


HTTP Hyper Text Transfer Protocol

1.5 References

??????????????????

1.6 Revision History


?????

1.7 Contact Information

??????

1.8 Overview of the Document

The remainder of this document consists of two main sections, section two
and three; which provides general descriptions, including characteristics of the
users of this project, the project’s hardware, the functional and data requirements
of the project.

Section two will be most interest to our customer and potential users, it
contain a broad view of the project and other information that may be interest.
Section three is the target towards those designing and implementing our project,
4

it contains a strict enumeration of our requirements, a detailed account of our


approach to building the project, and so on. Section 3 gives the specific
requirements of the project. This also discusses the detailed description of the
functional requirements.

Section 2 – General Description

2.1 User Personas and Characteristics

In this section the fictional users are Employees, Database admin, Site
admin and Finance admin.

The characteristic of employees is to enter, edit, search and view the


details of their claims in the company. The characteristic of database admin is to
view the claims of the employees, process the claims and send to the finance
department in the concern. The characteristic of site admin is to enter, edit, view
and delete the information about the claims given by the employees. The
characteristic of the finance admin is to accept or reject the claims, issue the
reports and prepare pay slip if claim is accepted and given to employees.

2.2 Project Perspective

In this section, we mention how the project is related to one another software and
hardware:
 If the project is stand-alone, give the relationship to the other projects.
 If the project is part of the larger project, then identify its interface to the
other project.
 Identify the project’s external interfaces with its environment.
 If the project uses existing hardware and software, describe the hardware
and software.
 If the project needs new hardware, give a detailed explanation of the
hardware.

Monitors : 800 x 600 minimum resolutions at 256 colors minimum


Memory : 256 MB Ram
I/O : Optical mouse and 105-key keyboard (Multimedia)
GHz : 2.8 Ghz processor
OS : Windows XP
HDD : 40 GB
ASP.NET : Active Server Pages Dot Net Front End
Database : SQL Server 2000(Microsoft)
Server : IIS (Tool)
5

2.3 Overview of the Functional Requirement

Provide a short description of the functions to be performed by the


software, i.e. what the project should do. This description must be in a form
understandable to the user, operator, and clients. The detailed requirements in
specifications are left to section 3.2 in the document. If you number the
Functional Requirements in a systematic manner, it will be easier to refer to them
in section 3.2 of the SRS, in the design document, you will write later, and in the
testing document (also to be written later). This should not be design-oriented, a
common mistake.

2.4 Overview of Data Requirement

In this section, we mention the input ant output function of this project.
The data input by the user will include simple mouse clicks on buttons to perform
required actions, and keystrokes for entering correct numerical and alphabets
according to the phrases. Shortcut key and Accelerator key functionality should
be incorporated wherever applicable.

2.5 General Constraints, Assumptions, Dependencies and


Guidelines:

General Guidelines that are imposed upon the implementation of the project,
modify the following as required for this project:

 The project must be web-based.


 The project must be stored in such a way that allows the clients to access
it easily.
 The project must have a user-friendly interface that is simple enough for
third graders to understand.
 Response time for loading the project should take no longer than five
minutes.
 This project is used for the network of more number of users.
 A general knowledge of basic computer skills is required to use the
project.
6

2.6 User View of Project Use

This section will provide a user’s eye-view of the project. If the personas
are defined in section 2.1, it should be used here in order to make the
descriptions concrete. This describes the settings, gives sketches (if possible) to
show the possible appearance of the screen at several points in the program,
gives sample of data that is stored, or output, and gives scenarios that
demonstrate the project in operation.

Section 3 – Specific Requirements

3.1 External Interface Requirements

In this section we include:

 Operator/User interface characteristics from the human factors point of


view.
 Characteristics required by the interface between the project and each of
the hardware components.
 Interfaces with the other software components or projects, including other
systems, utility software or third party software, databases and operating
systems.

3.2 Detailed Description of Functional requirement:

This section should be customized to reflect the particular needs of the


project.

Functional components are:

 Purpose/ description of the functional requirement.


 Inputs.
 Which inputs
 In what form/ format will inputs arrive
 From what sources input will be derived, legal domains of each input
element.
 Processing
7

 Describes the outcome rather than the implementation


 Include any validity checks on the data, exact timing of each
operations (if needed), how to handle unexpected or abnormal
situations.
 Outputs
 The form
 The shape
 Destination
 And volume of output
 Output timing
 Range of parameters in the output
 Unit measure of the output
 Process by which of output is stored or destroyed
 Process for handling the error message produced as output.

Overview of functional requirements:

 Online Claims Management System is a client – server solution for


various category of users based on ASP Dot Net technology.
 The implantation enables HTTP protocol.
 The server application must be designed under ASP Dot Net and it
is based on IIS technology. It handles the request from the users
over HTTP and deals with real estate business. In order to satisfy
user’s request.

Online process:

In this process the request compared to the server, which validates


these particular user identity. If the USER NAME and PASSWORD
combination provided from online Claims management systems are valid
when uses successfully and login’s and in the response a particular user will
be returned until the user log out from the application.

3.3 Performance Requirements

 Number of connection to the system should be one.


 Number of simultaneous users depending upon the work stations
 Response time as expected
 Number of files
8

 Size of files and tables


 Number of transactions per interval

3.3.1 Speed and latency requirements

This section will provide details about amount of time available to


complete specified task. This often refers to response times and they can also
refer to the project’s ability to fit into indented environment.

3.3.2 Considerations for speed

There is a wide variation in the importance of different types of speed


requirements.

3.3.3 Safety critical requirements

This section is needed to understand and highlight potential damage that


could occur when using a project within the expected operational environment.

3.3.4 Reliability and Availability requirements

This section quantifies the necessary reliability of the project. This is


usually expressed as the allowable time between failures or the total allowable
failure rate. It also quantifies the expected availability of the project.

3.3.5 Robustness Requirements

This section will provide the details about the ability of the project to
continue to function under abnormal circumstances.

3.3.6 Capacity Requirements


9

This section specifies the volume that the project must be able to deal with
the numbers of data stored by the project. This section is needed to ensure that
the project is capable of processing expected volumes.

3.3.7 Scalability Requirements

This specifies expected increase in size that the project must be able to
handle.

3.4 Quality Attributes

These are the quality attributes in a project

 It should be reliable
 It should be portable
 It should be having easy usability
 It should be efficient
 It should be maintainable
 It should be Re-Usable

3.5 Other Requirements

According to clients’ request the requirements can be changed or added. If


there are no other requirements, then write “None at this time” rather than leaving
this section blank.

You might also like