You are on page 1of 21

lOMoARcPSD|39659544

Software Requirement
Specification

For

<Crop Insurance Management


System>

Prepared by <Ayush Kumar>>

<Lovely Professional University>

<Reg No:-12308392>

<Submitted To:-Manish Kumar


Sharma >
Table of Contents
Table of Contents...........................................................................................................................ii
1. Introduction..............................................................................................................................1
1. Purpose...........................................................................................................................................1
2. Document Conventions...................................................................................................................1
3. Intended Audience and Reading Suggestions..................................................................................1
4. Definitions, acronyms, abbreviations..............................................................................................1
5. Scope.............................................................................................................................................. 2
6. References......................................................................................................................................2
2. Overall Description..................................................................................................................2
1. Product Perspective.........................................................................................................................2
2. Product Features.............................................................................................................................3
3. User Classes and Characteristics.....................................................................................................3
4. Operating Environment...................................................................................................................4
5. Design and Implementation Constraints.........................................................................................4
2.7 Assumptions and Dependencies......................................................................................................4
3. System Features.......................................................................................................................4
1. System Feature 1.............................................................................................................................5
2. System Feature 2.............................................................................................................................5
3. System Feature 3.............................................................................................................................6
4. System Feature 4.............................................................................................................................7
5. System Feature 5.............................................................................................................................7
6. System Feature 6.............................................................................................................................7
7. System Feature 7.............................................................................................................................8
8. System Feature 8.............................................................................................................................8
9. System Feature 9.............................................................................................................................8
10. System Feature 10...........................................................................................................................9
4. External Interface Requirements...........................................................................................9
1. User Interfaces................................................................................................................................9
2. Hardware Interfaces........................................................................................................................9
3. Software Interfaces.........................................................................................................................9
5. Other Nonfunctional Requirements.......................................................................................9
1. Performance Requirements...........................................................................................................10
2. Safety Requirements.....................................................................................................................10
3. Security Requirements..................................................................................................................10
4. Software Quality Attributes..........................................................................................................10
6. Other Requirements..............................................................................................................10

Revision History
Name Date Reason For Changes Version
Shubham Garad 24/09/17 Creation 1

ii
Abstract
Crop insurance is purchased by agricultural producers, including
farmers, ranchers ,and others to protect themselves against either
the loss of their crops due to natural disasters , such as hail,
drought, and floods, or the loss of revenue due to declines
in the prices of agricultural commodities. The two general categorie
s of crop insurance are called crop-yield insurance and crop-
revenue insurance.
In existing system manual procedure is followed where records are
used to maintain data which is a time taking process and require
more man power and calculating commissions dues..etc are done
manually . In present system there is no need of human
interference in calculating any details. Total work is done using
management system which will save time and less paper work and
even human resource.

MODULE DESCRIPTION Number of Modules


after careful analysis the system has been identified to have the
following modules!
1. CEO
2.Manager
3.agent.
4.Customer
1. CEO module
2. The CEO is the super user of the system. The CEO is responsible
for defining the policies, policy
terms and conditions, policy amounts, establishing the different
branches, registration of the branch managers. CEO will also get
information about policy details, branch details, manager
details, agents details, customers details, customers policy
details
2. Manager module:
Manager is responsible for all activities at a specific branch.
manager appoints agents and interacts with customers.
manager can get data about customer policies, dues and
payment details. manager can also get agent details and
commission information. manager can generate
various reports.
3. Agent module:
agents are employees of the insurance company who interact
with potential customers and offer the necessary details, agents
typically act as a liaison between customers and company .
agents are entitled for commission for each policy they sell. &
sing the system an agent can find customer's policies details,
customer’s personal details, commission collected, reports,
available policy details, concerned manager details and agent
personal details.
4.Customer module:
"ach customer must register with the system before one can
avail the services. Customers can seek information regarding
policies, register new policies, make online payments etc.
NTRODUCTION
Crop insurance
is purchased by agricultural producers, including farmers,
ranchers, and others to protect the themselves against either the
loss of their crops due to natural disasters, such as hail,
drought, and floods, or the loss of revenue due to declines in the
prices of agricultural commodities . The two general categories of
crop insurance are called crop-yield insurance and crop-revenue
insurance
•Crop-yield insurance: There are two main classes of crop-yield
insurance:

Crop-hail insurance is generally available from private insurers


because hail is a narrow peril that occurs in a limited place and its
accumulated losses tend not to overwhelm the capital reserves
of private insurers..

Multiperil crop insurance (MPCI): Coverage in this type of insurance


is not limited to must one rises usually multi-peril crop insurance
others hail’ excessive rain and drought in a combined package.
sometimes additional rises such as insect or bacteria-related
diseases are also offered. The problem with the multi-peril crop
insurance is the possibility of a large scale event. such an event can
cause significant losses beyond the insurers financial
capacity. To make this class of insurance' the perils are often
bundled together in a single policy' called a multi-peril crop
insurance (MIPC) policy.
•Crop-revenue insurance: Crop-yield times the crop price gives
the crop-revenues. based on farmer’s revenues' crop-revenue
insurance is based on deviation from the mean revenue Crop-
revenue insurance covers the decline in price that occurs
during the crop’s growing season. !t does not cover declines
that may occur from one growing season to another
OVERVIEW OF THE
PROJECT
SYSTEM DESCRIPTION:
The proposed system is for masing easier to manage po
licy holder details' agent details' policy details' claimant
details and payment details. of
this will be developed for managing the insurance man
agement system. The overall system is control through
the main menu. The main menu contains / parts.
1. Policy Schemes.
2.Agent Login, Customer Login.
3..CEO or Administrator Login.
4.Manager login
5.About us./.Contact us.
POLICY SCHEMES:-
Various policy schemes are:-
1.Crop-yield insurance:-
2.Crop-revenue insurance:-
AGENT LOGIN
The agent login form lines to-
1.Basic agent information line contact details and
address which will be shown in customer insurance
information window.
2.0ll the information related to insurances which he has
made to his clients,
Commission received by him for each insurance made b
y him respectively.
3.Option to create a new policy to any existing new
client.
4. option to edit the contact information of its client.
Use case Diagram:

Crop
5.Option to delete a policy of any client in case of
policy lapse.

CUSTOMER LOGIN:-
The form contains the agent information line-
1.Personal information re8uired by insurance
agency.
2.Next premium due of respective insurances
by the client along with maturity date' agent
info etc.

ADMINISTRATOR LOGIN:-
0dministrator has rights to-
1.Create new agent.
2. Edit agent’s information and its commission
percentage.
3. Delete an agent’s database and all its policies
respectively.
4.Create / update/ Delete New policy.
5.Create / update / Delete New branch.
6.Create / update/ Delete 9ew branch Manager.
7.Accept new policy holder and his claims request.

ABOUT US:-
it contains information about the organization’s
history and its achievements.
CONTACT US:-
It contains the contact details of the organization’s
various branches located in different parts of a
country.
REPORTS:
•Sales report
• Claimant information report
• Agent information report
• Client information report
1. Functional Requirements

For documenting the functional requirements, the set of functionalities supported by the system are
to be specified. A function can be specified by identifying the state at which the data is to be input to
the system, its input data domain, the output data domain, and the type of processing to be carried
on the input data to obtain the output data.

Basically the management parts are the functional requirements which are uploading details, search
topic, edit option and user registration
1. Requirements of the Crop insurance

Functional requirement 1: Subscribe

Description: The system shall provide a registration page

Input: Email id of the customer.

Output: “Thanks for subscribing” message.

Functional requirement 2: Uploading Item

Description: Uploading function can be done by the user who has registered on the website. When
the user uploads an item and if it is a news item or forum is determined and edited by the
administrators or editors and then it is displayed on the home page. A registered user can also add
comment on other news as well.

R2.1: Select upload option.

Input: Select upload item option.

Output: User will be prompted to enter the upload type.

R2.2: Select the type of item.

Input: Users opt from one of the following


R1.2.1 News item
R1.2.2 Forum item

R1.2.3 Comment item

Output: User will be prompted to enter item details according to the above item.

5
l

R2.3: Check to display

Input: Check whether the item is visible for the masses.

Output: We will be prompted to display item.

R2.4: Display the item

Input: Edit the news item.

Output: The item is displayed on the screen.

Processing: It is controlled by the editor and which checks whether the uploaded item is fit for the
mass or not if it is then it display on screen if not then it is edited to make it visible for the mass
then display on the screen of the website.

Functional requirement 3: Search topic

Description: Search function does not require any authentication from its user so any user can
perform this function. If a user searches for a news item then the news will be displayed on the
screen if it related to the search topic.

R3.1: Select search option

Input: Search option.

Output: User will be prompted to enter the search topic.

R3.2: Check for the search topic


Input: Checks for the search topic related item.

Output: We will be prompted to display the items.

R3.3 Display the item

Input: Enter topic related to item.

Output: Display the item.

Processing: It checks for any item related to the search topic and displays it on the screen and if
there is no item related to the topic is present then it will pop as no related item.

6
Functional requirement 4: Edit topic

Description: Edit function can be done by only administrator or editor. Any uploaded item is
examined and edited by administrator so it can be allowed to display to mass.

Input: Edit option.

Output: User will prompted to edit the uploaded item.

Functional requirement 5: User registration

Description: Registration is allowed to the users who are not registered yet (unregistered users) and
completion of this function they can also upload items.

R5.1: Select register option

Input: Register option.

Output: User will prompted to write a user name, email id, and password.

R5.2: Check for validity

Input: Checks whether any other registered users have same information.

Output: We will be prompted to register successfully if it has different information or else its
rejected.

Processing: It checks if the information submitted about the new user is similar to any other
registered user if yes it rejects the user information if no then new user will be registered
successfully.

Functional requirement 6: Verification

Description: The content uploaded by registered user is verified by publisher.

R6.1: Content is OK

Input: Cross checks the news or article uploaded by any other registered users.

Output: If the information through content is ok then publish it.

7
R6.2: Content is not OK

Input: Cross checks the news or article uploaded by any other registered users.

Output: If the information through content is not ok then reject it and apologize to
user.

Functional requirement 7: Login

Description: Login to user account.

R7.1: Login Successful

Input: username and password created while signup.

Output: Enter into the user account.

Process: Cross check the login credentials with the database.

R7.2: Login Unsuccessful

Input: invalid username or password.

Output: Display error massage and suggest to try again.

Process: Cross check the login credentials with the database.

Functional requirement 8:

Input: Select the news categories.

Output: Display the news from the selected category.

Process: Show loading message.

Functional requirement 9: Follow us

Input: Request the user to follow on various social networking sites or ignore.

Output: If accepted then display thank you message.

8
Non-Functional Requirements
Non-functional requirements for a crop insurance
management system are critical aspects that describe how
the system should behave, perform, and be designed. These
requirements are not directly related to specific
functionalities but focus on the overall system attributes and
qualities. Here are key non-functional requirements for a
crop insurance management system:

1.Reliability: The system should be reliable and available at


all times, especially during critical periods such as harvest
seasons or claim submissions. It should have mechanisms to
handle failures gracefully and recover quickly.

2.Scalability: The system should be able to handle a varying


number of users, policies, and claims efficiently. It should
scale up or down based on demand without compromising
performance.

3.Performance: The system must perform efficiently, with


acceptable response times for tasks such as policy creation,
claims processing, and report generation. Performance
metrics should be defined and regularly monitored.

4.Security: The system should ensure data privacy, integrity,


and confidentiality. It should comply with relevant
regulations and use encryption techniques to protect
sensitive information.
1.Usability: The system should be user-friendly and intuitive,
catering to different types of users including farmers,
insurance agents, and administrators. The interface should
be accessible and easy to navigate.

2.Interoperability: The system should integrate with external


systems such as weather databases, satellite imagery
services, and payment gateways. It should support standard
data exchange formats.

3.Maintainability: The system should be easy to maintain


and update. It should use modular design principles, clear
documentation, and logging mechanisms for debugging and
troubleshooting.

4.Compliance: The 1system should comply with regulatory


requirements related to insurance operations, data
protection, and agricultural practices. Regular audits and
checks should be conducted to ensure compliance.

5.Backup and Recovery: There should be robust backup and


recovery mechanisms in place to safeguard data against loss
or corruption. Regular backups should be performed and
tested.

6.Auditability: The system should maintain audit logs of all


critical transactions and activities for traceability and
accountability. These logs should be tamper-proof and
accessible only to authorized personnel.

7.Localization and Internationalization: The system should


support multiple languages, currencies, and regional settings
to cater to farmers and stakeholders from diverse
backgrounds.
1.Performance Under Stress: The system should be tested for
performance under stress conditions, such as high concurrent user
loads or unexpected spikes in data volume.

By defining and incorporating these non-functional requirements


into the crop insurance management system, you can ensure that
it not only meets the functional needs of users but also delivers a
robust, secure, and scalable platform for managing crop insurance
operations effectively.
Data Flow Diagram:
CONVERTING DIAGRAM INTO TABLES
1.Converting strong entity type
1. Each entity type becomes a table
2.Each single valued attribute becomes a column
3.Derived attributes are ignored
4.Composite attributes are represented by components
5.Multi-valued attributes are represented by a separate table
6.Key attributes of the entity type is the primary key

2.Converting Relationship
1.Relationships are based on cardinalities and degree of the relation
m:n.

3.Relationship Converted
1.Policy holder and policy have m:n cardinality which results
in conversion of the relation ?insured by into a table named as
insurance. The insurance table has ph_key and
pol_key from policy holder table and policy table respectively 'as its
composite primary key.
2.Also policy and agent table have m:n cardinality resulting
in conversion of relation sales' into a table named as sales.
The table sales has ph_key and pol_key from policyholder
table and policy table respectively 'as its composite primary
key and agent key from agent table as a foreign key

You might also like