Table of Contents

Table of content...1 List of figures...2 List of tables.3 1. Introduction.4 1.1 Purpose..4 2. Overall Description..........................................................................................................7 After the client entered to a insurance policy if client wants to add or remove some ....9 covers from the policy front end officer use this function to perform that task. ..............9 Commission Handling involve the calculating the commission, the Central Finance Brokering system expected from the underwriters............................................................10 3. External Interface Requirements....................................................................................14 4System Features...............................................................................................................21 6.Appendices .....................................................................................................................42

List of Figures
Figure 2.1:Major components of the system ....08 Figure 2.3: Use case diagram for actors.11 Figure 3.1: Login screen .......14 Figure 3.2: Login screen with error message.....14 Figure 3.3: Company profile screen ..................................................................................15 Figure 3.4: Client main frame screen.. ..15 Figure 3.5: Vehicle main frame screen .....16 Figure 3.6: Under writer main frame screen .........16 Figure 3.7: Quotation screen..17 Figure 3.8: Policy closure .17 Figure 3.9: Invoice screen .18 Figure 3.10: Policy.....................18 Figure 3.11: Active policy ....19 1

Figure 3.12: Update certificate .....19 Figure 4.2.1: Main use case...23 Figure 4.2.2: Create and search client24 Figure 4.2.3: Quotation handling ..24 Figure 4.2.4: Policy handling ....25 Figure 4.2.5: Credit/Debit instruction ...26 Figure 4.2.6: Commission .............................................................................................26 Figure 4.2.7: Payments..27 Figure 4.2.8: User account management....27

List of Tables
Table 4.1.1:Use case diagram identifier...21 Table 4.1.2: Use case scenario identifier.. .......................................................22 Table 4.2.1: Create personal client................................................28 Table 4.2.2: Create cooperate client .. ..........................................................................28 Table 4.2.3: Search client .............................................................................29 Table 4.2.4: Create quotation ...........................................................................................29 Table 4.2.5: Search quotation............................................................................................30 Table 4.2.6 Search policies................................................................................................30 Table 4.2.7: Create policy.................................................................................................31 Table 4.2.8: Update certificate..........................................................................................31 Table 4.2.9: Print cover note.............................................................................................32 Table 4.2.10: Create invoice......................................................................................32 Table 4.2.11: Create debit instructions..............................................33 2

Table 4.2.12: Search debit instruction with debit instruction number..............................33 Table 4.2.13: Allocate debit note..34 Table 4.2.14: Create credit instructions.. .........................................................34 Table 4.2.15: Search credit instructions with credit instructions date..............................35 Table 4.2.16: Search credit instructions with credit instructions number.........................35 Table 4.2.17: Allocate credit note. ...................................................................................36 Table 4.2.18: Enter cheque detail .........................................................................36 Table 4.2.19: Search commission cheque ........................................................................37 Table 4.2.20: Commission allocation................................................................................37 Table 4.2.21: Endosment...................................................................................................38 Table 4.2.22: Create policy renewal..........................................................38 Table 4.2.23: Policy closure..............................................................................................39 Table 4.2.24: Print relevant document..............................................................................39 Table 4.2.25: Search invoice..............................................................................................40 Table 4.2.26: Create under writer payment.......................................................................40 Table 4.2.27: Create sub agent payment ..........................................41 Table 4.2.28: User validation........................41

1. Introduction 1.1 Purpose

The purpose of this document is to define all the requirements that the Insurance Brokering System for the Central Finance Insurance Brokers PLC, which is now being developed. This document describes the issues of the current manual system and what are the solutions that we provide to come up with those issues. Our main target is providing a better solution for this problem. By preparing Software Requirement Specification we hope to present it to our client and see whether our solution is sufficient for his requirement and what are the changes there should be. As benefit of writing this document we expect Reduce the development effort, provide a basis for estimating cost and schedules and enhance what this product going to do.

This software is named Insurance Brokering System for Central Finance Insurance Brokers PLC and its release version is 1.0.

1.2 Document Conventions

Descriptions provided under the main topics which create the contents of the software requirements specification are written using the font type Times New Roman in size 12 and line spacing for main text is 1.5. Bolded headings and the sub headings are also in same font and font size is 14. All pages except the cover page are numbered, and the number is appeared on the lower right hand corner of the page. It is numbered every image and data table and refer them according to the main text using the numbers.

1.3 Intended Audience

This document is intend for developers, testers, document writers and the users who going to operate this system.

Developers The developers are the main users of this SRS document. They can gather information about functional requirements and non functional requirements, Software and Hardware requirements. Tester Testers are important as well as Developers. They must have knowledge about input, output and processes. Because they are the people who check the developing system have

the capability to satisfy customer requirements. The responsible of successful output depends on the testers. Document Writers Document writers have to do all the documentations in well define way because srs acts as the legal document between client and the system developers. Document writers have to prepare manual which supports users to operate the system and this document will be a reference when preparing final report. The users There are sections that user can get a clear view of the system, its benefits and this software satisfies their requirements.

1.4 Project Information

This software mainly focused on Insurance Brokering System for Central Finance Private Limited Company city office. Insurance Brokering allows customer to find Insurance according to his or her budget and requirement. Currently they do everything relevant to this subject by manually. So our main goal is develop software for overcome drawbacks of current manual system. The proposed system will automate the key tasks of their business. Such as client registration, calculate commission, policy handling etc. Also it includes a database management system which helps efficient data storing updating and retrieving .As a specific feature we have introduced a document printing function to print all the output documents of the system automatically.

There are some benefits belong to the automated system are shown below. Eliminates paper work to a large extent Reduce man power requirement. Can handle client data efficiently

The main objective of developing such a system is efficient, accurate, effective system for accomplish their targets. Rather than that increase productivity, lower the cost and time saving are the other objectives of developing software.

1.5 References
Bradley L.Jones, 2004.SAMS teach yourself The C# Language, 2nd ed. Delhi: Person Education (Singapore)Private Limited. James Foxall, 2006.Microsoft Visual C# 2005, 1st ed. Delhi:Springe Private Limited. Robert K.Wysucki.et al, 2005.Effective Project Management, 1st ed.New York:John Wiley And Sons.Inc,p.148-149. Kim Heldman, 2004.Project Management Professional Study Guide, 1st ed. Delhi:Sybex Company Limited,p.119-130. Kathy Schalbe, 2007.InformationTechnology Project Management, 4th ed. Delhi:Thomson Course Technology,p.135-282. 6

Herbert Shildt, 2006.The Complete Reference C#2.0,2nd ed.Delhi:TATA McGRRW-Hill Publishing Company Limited. Andrew Troelson,C# And The.NET Platform,2nd ed. Delhi :Pearson Education (Singapore) Private Limited.

Robert J.Obery, 2002.Introduction To C# Using.NET,1st ed. Delhi:Pearson Education (Singapore) Private Limited. Deitel,H.M.et al,2005.C# How To Program,1st ed. Delhi :Pearson Education (Singapore) Private Limited.

2. Overall Description 2.1 Product Perspective

The proposed system is mainly focused on CFIB officer at the central Finance Insurance Brokering PLC city office. Currently they are using a manual system to handle records of client detail, transaction detail, policy detail, quotation details. It is very essential to have a proper system to store and retrieve data efficiently, effectively and accurately. By storing these detail in an automated system CFIB officer can maintain, update and retrieve data. It helps them to give fast and accurate service to the client. Not only has that it increased productivity.

Administrator

CFIB Officer

CFIB

System

Final Reports

Users

Figure 2.1 Main Components of the System

2.2 Product functions

This proposed system has following functions 1. Create and search client. Creating client is the first step client involves with the system and search client is the way that the information views of existing client. 2. Create, validate renewal and search policies. Create and search policies, search the policies for the given conditions and create policy suitable for the client. Create policy means the client is enrolled to the policy. When validating check whether all provided information are in the required format . After policy period expired then renew the policy according the agreement with underwriters. 8

3.

Create and search quotation. Using this function Front End Officer can search template quotation which can fulfill the client requirement. If does not exist required type of quotation the Front End Officer create new quotation which equal to the client requirements.

4.

Create and search invoice. Invoice will create automatically according to the quotation and policy. This include the premium details which client should pay and to be paid.

5.

Create and search debit instruction. When user creates a new policy from the system, System has to inform to underwriter for debit the company account for relevant policy till they settle the policy. This case will describe how debit instruction creating from the system. Underwriter will create a Credit/Debit Note according to given instruction by the Insurance broker (CFIB) and send it backs.

. 6. Print relevant documents Using this function print all relevant documents such as quotation, policies etc.. 7. Update Certificate After the client entered to a insurance policy if client wants to add or remove some covers from the policy front end officer use this function to perform that task. 8. Commission Handling

Commission Handling involve the calculating the commission, the Central Finance Brokering system expected from the underwriters. This also involves the calculating of the commission for sub agents.

9. Underwriter Transaction Handling CFIB will settle the underwriter after an agreement period between CFIB and the underwriter. CFIB will create a batch for settlement. That batch will include the pending Debit and Credit Notes received by particular underwriter.

10

2.3User Classes and Characteristics

Front-End Officer

CFIB Officer

Adminstrator

Figure 2.3 Use case diagrams for Actors Mainly three actors can be identified as the users of this system. Administrator is the most privileged user of the system. He is the person who is responsible for all the activities in the system. Also he is responsible for creating user accounts and access levels. CFIB officer is in the next privilege level. He is the person who handles transactions confirmation with customer and underwriters. Front End Officers are directly deal with the customers, help them to select a policy, issue policy, renew the policy, handle payment, etc.

11

2.4 Operating Environment

Hardware Platform Processor: Intel/AMD 1GHz x86 or x64 processor Memory: 1GB of system memory. Hard disk: 40GB for each client machine 160GB for the server. Fast Ethernet Switch (minimum 12 ports) Software Platform Operating System: Microsoft Windows XP (for each client machine) Microsoft Windows Server 2003 Microsoft .NET Framework 3.5 Microsoft SQL Server 2005

2.5 Design and Implementation Constraints

1. Since they use computers for store small amount of data (only client detail) ,but calculate every transaction detail manually. They have computers which has more memory with better infrastructure. So our intention is to implement software which accomplish their functions in CFIB service, through automated system and which can be run on the current infrastructure. 2. Every function has separate interface. This interface allows print, save, add, close and search. It is allow achieving many tasks at single interface. 3. The developers expect to use SQL server to create database. Because it has many components and the database of this system is too large which store different data. 4. Software is developing on Object Oriented technology, so that the efficiency of the software will be increased.

12

2.6 Project Documentation

The SRS followed the format supplied by the ITP lecturer in charge. It contains all the function. When delivering the system to the client team expects to hand over the Final report of the CFIB system.

2.7 User Documentation

Central Finance Insurance Brokering system is very user friendly system that provided automated facilities to its users. The idea of the providing user manual to the users is giving assistances and to support to achieving their targets. User manual for the system is just about important as the system itself. The length of the user manual is depending on the involvedness of the system. Users will appreciate manuals with easy to find, brief information with enough detail to prevent confusion. To write an effective manual one must think systematically, understand the process thoroughly and be able to describe it clearly step by step. Installation process of the software is done by the IT team of the Central Finance Insurance Brokering Unit. We provide to user a User Guide Tour video, explaining all the steps walking the user through the system training how system works, benefits of the system etc

13

3. External Interface Requirements 3.1 User Interfaces

1st screen shot Login Screen

Figure 3.1 Login Screen

2nd Screen shot - prompt a window when login is incorrect

Figure 3.2 Login Screen with error message

14

3rd Screen shot Company Profile

Figure 3.3 Company Profile Screen 4th Screen shot- Client Main Frame

Figure 3.4 Client Main Frame

15

5th Screen Shot Vehicle Main Frame

Figure 3.5 Vehicle Main Frame 6th Screen Shot Underwriter Main Frame

Figure 3.6 Underwriter Main Frame 16

7th

Screen shot Quotation

Figure 3.7 Quotation Screen

8th Screen shot Policy Closure

Figure 3.8 Policy Closure

17

9th Screen shot Invoice

Figure 3.9 Invoice Screen 10th Screen shot Policy

Figure 3.10 Policy Screen 18

11th Screen Shot Active Policy

Figure 3.11 Active Policy 12th Screen shot Update Certificate

Figure 3.11 Update Certificate

19

3.2Hardware Interfaces
A fast Ethernet switch with twelve ports which can be used to minimum 10 users.

3.3Software Interfaces
The software has to connect to a Microsoft SQL Server 2005 database running on a server machine in the Intranet through a Fast Ethernet Switch.

3.4Communications Interfaces
There is an Intranet as a communication Interface.

20

4 System Features
4.1 Use case Identifier 4.1.1 Use case diagram Identifier

User Type Front End Officer

Package Client Information System Quotation Handling System Policy Information System Credit/Debit Transaction System Payment Handling System Commission Calculating System

Use case number 1 2 3 4 5 6 7

Use case diagram Create And Search client Quotation Handling Policy Handling Credit/Debit Instructions Payments Commission User account management

CFIB Officer

Administrator

Table 4.1.1 Use case diagram Identifier

21

4.1.2

Use Case Scenario Identifier Package Create And Search client Use case Use case scenario number 1 Create personal client 2 3 4 5 6 7 8 9 10 21 22 23 24 25 11 12 13 14 15 16 Create cooperate client Search client Create quotation Search quotation Search policies Create Policy Update Certificate Print Cover Note Create Invoice Create Policy Renewal Policy Closure Print Relevant Documents Search invoice Create Debit Instructions Search Debit Instructions With Debit Instruction Number Allocate Debit Note Create Credit Instructions Search Credit Instructions With Credit Instruction Number Search Credit Instructions with Credit Instructions Date Allocate Credit Note Enter cheque details Search Commission Cheque Commission Allocation Create Underwriter Payments Create Sub Agent Payments User validation

User Type Front End Officer

Quotation Handling Policy Handling

Credit/Debit Instructions

CFIB Officer

Payments

Administrator

User account management

17 18 19 20 26 27 28

Table 4.1.2 Use Case Scenario Identifier

22

4.2 Functional Requirements 4.2.1 Use case diagrams

Figure 4.2.1 Main Use Case 23

Create & search client

<<include>>

Figure 4.2.2 Create & search client Quotation handling

<<include>>

Figure 4.2.3 Quotation handling 24

<<include>> Policy handling

<<include>>

<<include>>

Figure 4.2.4 Policy handling

25

Credit/Debit instructions

Figure 4.2.5 Credit/Debit instructions Commission

Figure 4.2.6 Commission 26

Payments

<<include>>

<<include>> Figure 4.2.7 Payments User account management

Figure 4.2.8 User account management 27

4.2.2 Use Case Scenarios

Use Case Scenario 1: CREATE PERSONAL CLIENT Use Case Field Use Case Description Use Case ID 01 Use Case Name Create personal client Primary Actor(s) Front End Officer Pre Condition To complete this process valid client information should submit. Submitted client should not in the system. Flow of Events 1. The use case begins when system prompts a form to enter personal client details. 2. User should enter details to these mandatory fields initials, 3. surname, ID number and address. 4. The system validates personal client details. 5. The use case ends when the system save client records along with a registration number. Exceptions 3. A Mandatory fields are blank the system prompts an error message to refill the blanks. 3. B The NIC number is invalid system prompts the user to retype the NIC number. Table 4.2.1 create personal client Use Case Scenario 2 : CREATE CO-OPERATE CLIENT Use Case Field Use Case Description Use Case ID 02 Use Case Name Create cooperate client Primary Actor(s) Front End Officer Pre Condition Flow of Events To complete this process valid client information should submit. Submitted client should not in the system. 1. The use case begins when system prompts a form to enter cooperate client details. 2. User should enter details to these mandatory fields company name, company registration number and address. 3. The system validate cooperate client details. 4. The use case ends when the system save client records along with a registration number. 3. A Mandatory fields are blank the system prompts an error message to refill the blanks.

Exceptions

Table 4.2.2 create co-operate client Use Case Scenario 3: SEARCH CLIENT Use Case Field Use Case Description Use Case ID 03 Use Case Name Search client 28

Primary Actor(s) Pre Condition Flow of Events

Front End Officer To get client details existing client information should submit. 1. Use case starts when system prompts to enter available search fields such as client name company registration number(cooperate clients ) or surname , NIC number(personal clients ) 2. User enters data to search key fields. 3. Use case ends when matching records are shown. 2. A When all Search key fields are empty system prompts to re-enter data to relevant fields. 3. A When matching records are not found system displays Client not exists. Table 4.2.3 search client

Exceptions

Use Case Scenario 4 : CREATE QUOTATION Use Case Field Use Case Description Use Case ID 04 Use Case Name Create quotation Primary Actor(s) Front End Officer Pre Condition Quotation should valid to print or save Flow of Events 1. Use case begins when system prompts quotation entry screen. 2. User enters quotation number, client, some insured vehicle number, vehicle type, underwriter and underwriter code (all are mandatory fields). 3. System validates the quotation. 4. Based on some insured or adding or removing covers system calculate premium according to a predefined formula. 5. After doing all the changes system prints the quotation. 6. Quotations are saved in the system and use case ends. Exceptions 3. A For empty mandatory fields system prompts an error message refill empty fields. 6. A Quotations are saved temporary only for 15-30 days. To remove overdue quotations user has to run a separate function. Table 4.2.4 create quotation Use Case Scenario 5 : SEARCH QUOTATION Use Case Field Use Case Description Use Case ID 05 Use Case Name Search quotation Primary Actor(s) Front End Officer Pre Condition To search the quotation existing quotation sequence no should submit 29

Flow of Events

Exceptions

To search the quotation from client , given client should exist in the system and quotation also exists for given client 1. Use case starts when system prompts user to enter the quotation sequence number. 2. User enters quotation sequence number to the system. 3. System search for relevant quotation. 4. Display existing quotation information and use case ends. 3. A When quotation sequence number is not provided for search, system prompts an error Enter quotation sequence number 3. B System prompts no such quotation exists when quotation sequence number is invalid and use case ends. Table 4.2.5 search quotation

Use Case Scenario 6 : SEARCH POLICIES Use Case Field Use Case Description Use Case ID 06 Use Case Name Search policies Primary Actor(s) Front End Officer Pre Condition To get policy details or check whether policy exists have to identify from which filed user going to create policy. Have to submit existing related fields with policy. Flow of Events 1. Use case starts when system prompts user to enter existing information to search policy. 2. User enter certificate number, client code, cover note number, debit note number (unique fields),business type, underwriter ,issued date ,expired date etc. 3. System display existing information according to given details and use case ends. Exceptions 2. A When all Search key fields are empty system prompts to re-enter data to relevant fields. 2. B When providing information other than to unique fields it provides multiple search result. Table 4.2.6 search policy Use Case Scenario 7: CREATE POLICY Use Case Field Use Case Description Use Case ID 07 Use Case Name Create Policy Primary Actor(s) Front End Officer Pre Condition To create a policy client should exists. To create a policy quotation should exists. Flow of Events 1. Use case starts when system prompts user to enter quotation 30

Exceptions

number. 2. User enters quotation number. 3. When quotation number provides all quotation information automatically takes to the policy interface. 4. User has to enter required policy information such as policy number, premium, policy fee etc. 5. System validates policy information. 6. System creates policy and use case ends. 4. A For businesses from sub agent user has to provide sub agent number to the system. 5. B For empty fields system prompts an error message re-enter data to relevant fields. 5.a When policy information are invalid system prompts an error message enter valid information Table 4.2.7 create policy

Use Case Scenario 8: UPDATE CERTIFICATE Use Case Field Use Case Description Use Case ID 08 Use Case Name Update Certificate Primary Actor(s) Front End Officer Pre Condition To update the certificate search policy should exist. Flow of Events 1. Use case starts when user moves to search policy interface and search the policy. 2. User selects the relevant policy. 3. User Moves to update certificate interface. 4. User enter certificate no, policy no, issue date, issue time and expire date. 5. Then user validates policy details information. 6. Update the certificate and use case ends. Exceptions 5. A When details provided to update policy is invalid system prompts an error message enter valid information 5. B For empty fields system prompts an error message re-enter data to relevant fields. Table 4.2.8 update certificate Use Case Scenario 9: PRINT COVER NOTE Use Case Field Use Case ID Use Case Name Primary Actor(s) Pre Condition Use Case Description 09 Print Cover Note Front End Officer Policy should create before creating a cover note. 31

Flow of Events

1. Use case starts when client comes to the create cover note interface 2. System auto created cover note no, policy sequence no, issue date and time (should be the current system date and time), expire date (Can be after 15 or 30 days from issue date user has to enter), issued user (current system user) to create a cover note. 3. After creating the cover note system prompts a message to user ask for print. 4. Save cover note number with policy details and use case ends. Table 4.2.9 print cover note

Exceptions

Use Case Scenario 10: CREATE INVOICE Use Case Field Use Case ID Use Case Name Primary Actor(s) Pre Condition Flow of Events Use Case Description 10 Create Invoice Front End Officer To create an invoice, policy should select (Invoice creates only for selected policy). 1. Use case begins when user moves to search policy interface and search the policy. 2. After selecting a policy user moves to invoice create interface. 3. The system automatically creates the invoice with premium and other details. 4. Print the invoice ,save it and use case ends Table 4.2.10 create invoice

Exceptions

Use Case Scenario 11: CREATE DEBIT INSTRUCTIONS Use Case Field Use Case Description Use Case ID 11 Use Case Nam Create Debit Instructions Primary Actor(s) Front End Officer Pre Condition Cover note should generate before generating a debit instruction. Flow of Events 1. Use case starts when the system created a new policy. 32

2. System gets policy details such as policy sequence number, underwriter, gross premium etc. 3. System search cover note number according to the policy sequence number. 4. Use case ends when the system creates debit instructions with policy details cover note number and current date. Exceptions Table 4.2.11 create debit instructions

Use Case Scenario 12: SEARCH DEBIT INSTRUCTIONS WITH DEBIT INSTRUCTION NUMBER Use Case Field Use Case Description Use Case ID 12 Use Case Name Search Debit Instructions With Debit Instruction Number Primary Actor(s) Front End Officer Pre Condition Cover note should generate before generating a debit instruction. Flow of Events 1. Use case starts when the system displays an interface to search debit instructions. 2. User enters debit instruction number. 3. System search for that number. 4. System displays the particular instruction details Exceptions 3. A For invalid debit instruction numbers system prompts an error message Invalid debit instruction number Table 4.2.12 search debit instructions with debit instruction number

Use Case Scenario 13: ALLOCATE DEBIT NOTE Use Case Description Use Case Field Use Case ID 13 Use Case Name Allocate Debit Note Primary Actor(s) Front End Officer

33

Pre Condition Flow of Events

Relevant debit instruction should exist. 1. Use case starts when the system displays an interface to allocate the debit note. 2. User selects the relevant instruction number. 3. System gets the underwriter from instruction details. 4. System displays a window to enter debit note number and date. 5. User enters debit note number and date. 6. System gets the system date and creates a new record to allocate debit note and display the message Debit note allocated successfully and use case ends. Table 4.2.13 Allocate Debit Note

Exceptions

Use Case Scenario 14: CREATE CREDIT INSTRUCTIONS Use Case Field Use Case Description Use Case ID Use Case Name Primary Actor(s) Pre Condition Flow of Events 14 Create Credit Instructions Front End Officer Relevant credit instruction should exist. 1. Use case starts when the system created a new policy. 2. System gets policy details such as policy sequence number, underwriter, gross premium etc. 3. System search cover note number according to the policy sequence number. 4. Use case ends when the system creates credit instructions with policy details cover note number and current date. Table 4.2.14 create credit instructions Use Case Scenario 15: SEARCH CREDIT INSTRUCTIONS WITH CREDIT INSTRUCTIONS DATE Use Case Field Use Case Description Use Case ID 16 Use Case Name Search Credit Instructions with Credit Instructions Date Primary Actor(s) Front End Officer Pre Condition User should submit the credit instruction date for search. 34

Exceptions

Flow of Events

Exceptions

1. Use case starts when the system displays an interface to search credit instructions. 2. User enters credit instruction date. 3. System search for that date. 4. System will display a list of instructions, which created on the particular date. 5. User selects the relevant instruction from the list and the use case ends. 3.A When matching records are not found for the given date system displays No credit instructions created for the day Table 4.2.15 search credit instructions with credit instructions date

Use Case Scenario 16: SEARCH CREDIT INSTRUCTIONS WITH CREDIT INSTRUCTIONS DATE Use Case Field Use Case Description Use Case ID Use Case Name Primary Actor(s) Pre Condition Main Success Scenario 16 Search Credit Instructions with Credit Instructions Date Front End Officer User should submit the credit instruction date for search. 1. Use case starts when the system displays an interface to search credit instructions. 2. User enters credit instruction date. 3. System search for that date. 4. System will display a list of instructions, which created on the particular date. 5. User selects the relevant instruction from the list and the use case ends. Exceptions 3.A When matching records are not found for the given date system displays No credit instructions created for the day

Table 4.2.16 search credit instructions with credit instructions date Use Case Scenario 17: ALLOCATE CREDIT NOTE Use Case Field Use Case Description Use Case ID Use Case Name Primary Actor(s) Pre Condition 17 Allocate Credit Note Front End Officer Relevant credit instruction should exist. 35

Flow of Events

1. Use case starts when the system display an interface to allocate the credit note. 2. User selects the relevant instruction number. 3. System gets the underwriter from instruction details. 4. System displays a window to enter credit note number and date. 5. User enters credit note number and date. 6. System gets the system date and creates a new record to allocate debit note and display the message Credit note allocated successfully and use case ends. Table 4.2.17allocate credit note

Exceptions

Use Case Scenario 18: ENTER CHEQUE DETAILS Use Case Field Use Case Description Use Case ID 18 Use Case Name Enter cheque details Primary Actor(s) Pre Condition Flow of Events CFIB Officer Under writers has sent a cheque to settle commission 1. Use case starts when the system displays an interface to enter cheque details. 2. User enters underwriter name, underwriter code, cheque number, received date and amount. 3. Then user validates entered details and save them. 4. Use case ends then. 2.A When the given fields are not filled system prompts an error Refill the empty fields 2. B When user enters underwriter code system should search and suggest that underwriter name. When the number is wrong system prompts an error.Invalid Underwriter number Table 4.2.18 Enter cheque details

Exceptions

Use Case Scenario 19: SEARCH COMMISSION CHEQUE Use Case Field Use Case Description Use Case ID 19 Use Case Name Search Commission Cheque Primary Actor(s) CFIB Officer Pre Condition Cheque no should submit or select Flow of Events 1. Use case starts when system display a window to enter cheque 36

number. 2. User enters the cheque number. 3. System searches cheque number. 4. Cheque found system gets cheque information such as the amount and receive date and use case ends. 4.a When Cheque number not found the system displays the message Cheque No is invalid.

Exceptions

Table 4.2.19 search commission cheque Use Case Scenario 20: COMMISSION ALLOCATION Use Case Field Use Case Description Use Case ID 20 Use Case Name Commission Allocation Primary Actor(s) CFIB Officer Pre Condition Policies should exist Total of commission for each policy should equal to commission cheque amount. Flow of Events 1. Use case starts when user moves to commission allocation interface. 2. System prompts to enter cheque number and it gets cheque details automatically. 3. Then user enters commission allocating policy numbers. System searches the policy value then. 4. When user command to calculate commission, System get the summation of policies and calculate commission based on total value of policies. 5. System matches the total of commission with the cheque amount. 6. Amount tallies system updates the commission and use case ends. Exceptions 2. A When Cheque number not found the system displays the message Cheque No is invalid. 3. A When policy does not exist system will display a message Policy No is invalid. 5. A Amount not tallies system will displays a message Total of policy commissions not equal to cheque amount. Table 4.2.20 commission allocation Use Case Scenario 21: ENDORSEMENT Use Case Field Use Case Description Use Case ID 20 Use Case Name Endorsement Primary Actor(s) Front End Officer Pre Condition Policy should exist for enter the endorsement. Covers in endorsement should match with covers, which can be adding 37

Main Success Scenario

to policy type. 1. First step of endorsement is search and select the relevant policy. 2. Then move to endorsement screen. System would display existing covers of the selected policy. 3. Also it should display covers, which does not appear current policy but can be added to relevant policy. 4. After adding, removing or both, user will create the endorsement. 1. A Search details may be incorrect. Then system prompts an error Invalid details Table 4.2.21 Endorsement

Exceptions

Use Case Scenario 22: CREATE POLICY RENEWAL Use Case Field Use Case Description Use Case ID 22 Use Case Name Create Policy Renewal Primary Actor(s) Front End Officer Pre Condition Policy should exist for renewing a policy. Main Success Scenario 1. User enters or selects the relevant policy. 2. System checks the collection manager approval. 3. Then system will create a debit instruction and renew the policy. Exceptions 2. A When not approved, system gives a message Not an approved contract by the collection manager. and Use case ends. Table 4.2.22 Create Policy Renewal

Use Case Scenario 23: POLICY CLOSURE Use Case Field Use Case Description Use Case ID 23 Use Case Name Policy Closure 38

Primary Actor(s) Pre Condition

Front End Officer Policy should exist for closure. User should confirm to close.

Main Success Scenario

1. Use case begins when user search and select the relevant policy. 2. User closes the selected policy. 3. System displays the message Are you sure you want to close this policy? 4. Then system will close the selected policy. 4. A system will terminate the use case when answer is NO. Table 4.2.23 Policy Closure

Exceptions

Use Case Scenario 24: PRINT RELEVANT DOCUMENTS Use Case Field Use Case Description Use Case ID 24 Use Case Name Print Relevant Documents Primary Actor(s) Front End Officer Pre Condition Document formats are saved in the system Main Success Scenario 1. Use case begins when user enters to the document printing interface. 2. User selects relevant document and enter data. 3. System prints the selected document and use case ends. Exceptions Table 4.2.24 Print Relevant Documents

Use Case Scenario 25: SEARCH INVOICE Use Case Field Use Case Description Use Case ID 25 Use Case Name Search invoice Primary Actor(s) Front End Officer 39

Pre Condition Main Success Scenario

Existing invoice should enter. 1. User enters the invoice no. 2. System search invoice no in invoices and get the invoice information.

Exceptions

2. A System prompts the message invalid invoice no when invoice number is not matching Table 4.2.25 Search invoice

Use Case Scenario 26: CREATE UNDERWRITER PAYMENTS Use Case Field Use Case Description Use Case ID 26 Use Case Name Create Underwriter Payments Primary Actor(s) CFIB Officer Pre Condition Commissions are calculated and deducted separately Main Success Scenario 1. User enters the date range and the underwriter for settlement. 2. System displays the list of outstanding Debit and Credit Notes for given period and underwriter. 3. User selects the Debit and Credit Notes, which was going to settle from this batch. 4. Then system will create the underwriter payment batch and displays a message Batch generated successfully. 5. System displays a confirmation message to print. If user responded it with yes system will print the batch. Exceptions Table 4.2.26 Create Underwriter Payments

Use Case Scenario 27: CREATE SUB AGENT PAYMENTS Use Case Field Use Case Description Use Case ID 27 Use Case Name Create Sub Agent Payments Primary Actor(s) CFIB Officer Pre Condition 40

Main Success Scenario

1. User enters the date range of going to settle, Sub-agent and the status. 2. System search sub-agent. 3. System search the policies for the date range, belongs to subagent and search whether underwriter commission received. 4. System calculates the sub-agent commission for each and every policy. 5. User select the policies from the list which going to settle. 6. User creates the batch of sub-agent commission and displays a message Batch generated successfully. 7. System displays a confirmation message to print and use case ends. 2. A When sub agent not found system displays a message Sub-Agent is invalid. Table 4.2.27 Create Underwriter Payments

Exceptions

Use Case Scenario 28: USER VALIDATION Use Case Field Use Case Description Use Case ID 28 Use Case Name User validation Primary Actor(s) CFIB Officer Pre Condition All users have valid login accounts Main Success Scenario 1. Use case begins when system provides user to enter user name and the pass word. 2. User enters user name and password. 3. System validate given information. 4. Use case ends when user logged in to the system. Exceptions 3.A Pass word incorrect system prompts Pass word is not valid 3.B User name incorrect and system prompts User name is not valid Table 4.2.28 User validation

5. Non Functional Requirements 5.1 Performance Requirements

41

The system should be able to support multiple user access and must have the capability to handle all the users who have logged on to the system simultaneously. The system need to support approximately 10 users at a time.

5.3 Security Requirements

Every user is given an initial password and that should be changed soon after the first login. Every password should have a minimum of 8 characters, which uses the combination of different types of characters. First Password is given by administrator

6. Appendices
6.1 Appendix A: Terminology

42

CFIB - Central Finance Insurance Broking PLC Private Limited Company OTS - On the Spot ARI - After repair inspection SLIIT - Sri Lanka Institute of Information Technology DFD - Data Flow Diagrams GUI - Graphical User Interface SQL - structured Query Language AGM Assistant General Manager SRS - Software Requirements Specification

6.2 Appendix B:Glossary Activity diagrams - A diagram that shows the flow from activity to activity. 43

Actor - An entity (a system or a person) that initiates a use case and / or benefits from a use case. Class -A category of group of things that have similar attributes and common behaviors. A class is a template for creating objects. Class diagrams - A diagram that shows a set of classes , interfaces and collaborations and their relationships. Client process - A running application program on a local site that request service from a running application program on a remote site Data Base - A collection of data stored in a standardized format,designed to be shared by multiple users. Package - A general purpose mechanism for organizing in to groups. Scenario - A specific sequence of actions that illustrates behavior. Server - A running application program (process)on a remote site that gives services to clients. Switch - A device connecting multiple communication lines together. Use case - A collection of scenarios of system use. A use case describe how a system looks to its users. Use case diagram - A diagram that shows a set of use cases and actors and their relationship. User Interface - The interface between the user and the application.

44