Credit Implement in to GetPaid

Project #:
Business Requirements Document (BRD) Template

Prepared by: Ibrahim Mohammed

Prepared for:
Date Submitted:

Project Sponsor:
Client Acceptor:
Project Manager: Michelle Hanner

Document Number:
Security Classification:
Version: 8.6.2

Last Updated:
Creation Date:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Table of Contents

TABLE OF CONTENTS ............................................................................................................................. 2

1. INTRODUCTION............................................................................................................................... 4
1.1. DOCUMENT PURPOSE ................................................................................................................... 4
1.2. INTENDED AUDIENCE ............................................................ERROR! BOOKMARK NOT DEFINED.
1.3. PROJECT BACKGROUND ............................................................................................................... 4
1.4. PURPOSE OF THE BUSINESS REQUIREMENTS ................................................................................ 4
1.5. BUSINESS GOALS/OBJECTIVES TO BE ACHIEVED .......................................................................... 5
1.6. BENEFITS/RATIONALE .................................................................................................................. 5
1.7. STAKEHOLDERS ........................................................................................................................... 5
1.8. DEPENDENCIES ON EXISTING SYSTEMS ......................................................................................... 6
1.9. REFERENCES ................................................................................................................................ 6
1.10. ASSUMPTIONS .............................................................................................................................. 6
2. REQUIREMENTS SCOPE ............................................................................................................... 6
2.1. IN SCOPE ...................................................................................................................................... 6
2.2. OUT OF SCOPE .............................................................................................................................. 7
3. FUNCTIONAL REQUIREMENTS .................................................................................................. 7
3.1. ACTOR PROFILES SPECIFICATION ................................................................................................. 8
3.2. ESSENTIAL USE CASE DIAGRAM .................................................................................................. 9
3.3. ESSENTIAL USE CASE SPECIFICATIONS ........................................................................................ 9
3.4. FUNCTION HIERARCHY DIAGRAM ...............................................................................................10
3.5. FUNCTION DEFINITION REPORT ..................................................................................................10
3.6. BUSINESS RULES .........................................................................................................................10
4. DATA REQUIREMENTS ................................................................................................................12
4.1. DATA ARCHITECTURE .................................................................................................................12
4.1.1. Domain Class Diagram .........................................................................................................12
4.1.2. Entity Relationship Diagram .................................................................................................12
4.2. DATA VOLUMES ..........................................................................................................................13
4.3. DATA CONVERSION.....................................................................................................................13
4.4. DATA RETENTION AND ARCHIVING ............................................................................................13
4.5. FOI/PRIVACY IMPLICATIONS ......................................................................................................13
4.6. DATA DEFINITION REPORTS ........................................................................................................14
4.6.1. Domain Class Definition Report............................................................................................14
4.6.2. Entity Definition Report .........................................................................................................15
5. NON-FUNCTIONAL REQUIREMENTS .......................................................................................16
5.1. SECURITY REQUIREMENTS ..........................................................................................................16
5.1.1. Authentication........................................................................................................................16
5.1.2. Authorization and Access Controls........................................................................................17
5.1.3. Information Security Classification and labelling .................................................................17
5.2. AVAILABILITY REQUIREMENTS ...................................................................................................17
5.3. USABILITY REQUIREMENTS.........................................................................................................18
5.4. SYSTEM HELP REQUIREMENTS ....................................................................................................18
5.5. PERFORMANCE REQUIREMENTS ..................................................................................................19
5.6. SCALABILITY REQUIREMENTS .....................................................................................................19
5.6.1. User Scalability .....................................................................................................................19
5.6.2. Application Scalability...........................................................................................................19

Last revised: Page 2 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

6. INTERFACE REQUIREMENTS ....................................................................................................20

6.1. USER INTERFACE REQUIREMENTS ...............................................................................................20
6.2. SYSTEM INTERFACE REQUIREMENTS ..........................................................................................20
7. BUSINESS GLOSSARY .................................................... ERROR! BOOKMARK NOT DEFINED.
REVISION LOG .........................................................................................................................................21
APPENDICES .............................................................................................................................................21
APPROVAL .................................................................................................................................................22

Last revised: Page 3 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

1. Introduction

1.1. Document Purpose

The purpose of this document is to describe business requirements of an Application

completely, accurately and unambiguously in Technology-independent manner. All
attempts have been made in using mostly business terminology and business language
while describing the requirements in this document. Very minimal and commonly
understood Technical terminology is used. Use case / Designer approach is used in
modeling the business requirements in this document.

1.2. Project Background (AS IS)

The Credit Department needs a solution for their credit review process that is more
streamlined and flexible than their current solution.

In order to keep up with the current workload and expected growth, it is critical for the
credit review process and solution to be intuitive and efficient with a centralized scoring
model and simple document management capabilities.

The current solution used for the credit review process requires the business users to have
to have knowledge of the Oracle customer hierarchy structure in order to create the credit
review at the right level. If the business users make a mistake, it causes an error in the
system which then has to be researched by a Business Analyst and/or a developer.

While the issue is being researched, the credit review process is halted for that request
until it is resolved or it is done outside the system. At times this requires a new request to
be entered in the system. These delays in the credit review process restrict the ability of
the Credit Department to respond in a timely manner. It also incurs additional cost in
having to maintain an IT support staff to research, maintain the solution or provide any
needed enhancements to correct the issue.

1.3. Purpose of the Business Requirements

The purpose of the Business Requirements.

Business requirements for major enhancements from share point location to Get
Paid.

Business requirements for Get Paid Credit configuration.

Last revised: Page 4 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

1.4. Business Goals/Objectives to be achieved ( TO BE )

1. Usability System should be user friendly and efficient allowing the credit
request to be processed in a timely manner

2. Email notification Should be able to notify the related parties to perform an

action or that an action was taken. It should not generate any unnecessary email
traffic

3. Ability to track Support Nomination responses (Marine only) Commercial

Support members should be able to respond and their response tracked

4. Ability to track Credit Committee responses The Credit Committee members

should be able to respond to a credit request and their response tracked.

5. Integration with the IDashboard.

6. Integration with the MDM (Master Data Management)

7. Integration with CRM.

1.5. Benefits/Rationale

The major benefits to be achieved with the implementation of the Business Requirements.

1. Increase efficiency with a credit and collections management solution that embeds
automation and workflow across collections, dispute resolution, credit risk
management and cash application.

2. Drive collection prioritization with the power of FIS predictive metrics risk,
scoring solution, which is embedded into GET PAID.

3. Deploy the solution on premise, in a secure private cloud environment or via

secure SaaS delivery

1.6. Stakeholders

Last revised: Page 5 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

1.7. Dependencies on existing systems

1.8. References

1.9. Assumptions

2. Requirements Scope

2.1. In Scope

Last revised: Page 6 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

2.2. Out of Scope

3. Functional Requirements

The enhancements needed for SharePoint can be broken down as follows:

1. Support Nomination (Marine only)
a. Add workflow to send email to the Commercial Support Nomination
group members when a new request/record is added to SharePoint.
b. Enhance workflow notification to read distribution list values from a
SharePoint list(s)
c. If the record is approved, create a new record in the CRF List
SharePoint site and copy the relevant data fields to the CRF List record.
d. Add user security based on the members entered in the different list stated
in line b. For example Brokers should only be able to create new
records but not see responses entered by Commercial Support Nomination
members.
2. CRF List
a. Marine Enhance workflow notification to read distribution list values
from a SharePoint list(s)
b. Aviation Create / copy new SharePoint list using the Marine CRF list as
the template
c. Land Create / copy new SharePoint list using the Marine CRF list as the
template
3. Enhancements Pending Approval
a. Aviation & Land Create a screen that can be used by the sales
representative to enter in a new credit request
b. Once the record is entered create a new record on the respective (Aviation
or Land) CRF List
c. Marine Modify existing workflows to read data from the corresponding
list. Currently the data is hard coded into the workflow processes
d. Create lists to capture data that will be used by the workflow process in
order to make it easier for the business users to manage / maintain the
data. This data is currently hard coded in the workflow processes:

Last revised: Page 7 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

i. Brokers / Sales representatives for each business segment (i.e.

Aviation, Land and Marine)
ii. Credit Managers / Analyst for each business segment (i.e.
Aviation, Land and Marine)
iii. Commercial Support Nomination group members
iv. Support nomination rules
v. Credit Committee members for each business segment (i.e.
Aviation, Land and Marine)

3.1. Actor Profiles Specification

Last revised: Page 8 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Actor Name Actor Type Access Type needed Comments

3.2. Essential Use Case Diagram

3.3. Essential Use Case Specifications

Last revised: Page 9 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Use Case Id : ##

Use Case Name

Description

Actors

Business Rules
Basic Flow Alternate Flows

Non-Functional Requirements

Pre-Conditions

Post-Conditions

Extension Points Extension Condition Extending Use Case

List of <<included>> use cases List of <<extended>> use cases List of inherited from
(parent) use cases

3.4. Function Hierarchy Diagram

3.5. Function Definition Report

3.6. Business Rules

Last revised: Page 10 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Last revised: Page 11 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Business Rule Name Rule Description Rule Source

Rule Id
- Policy manual
- Strategic decisions
- Contractual obligations
- Subject matter experts
- Other Sources (mention
the sources)

4. Data Requirements

4.1. Data Architecture

4.1.1. Domain Class Diagram

4.1.2. Entity Relationship Diagram

Last revised: Page 12 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

4.2. Data Volumes

4.3. Data Conversion

4.4. Data Retention and Archiving

4.5. FOI/Privacy Implications

Non-sensitive

Protected A;

Protected B:

Protected C:

Conceptual Class / Entity Name Data Sensitivity Level

(Non-sensitive,
Protected A,
Protected B,
Protected C)

Last revised: Page 13 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

4.6. Data Definition Reports

4.6.1. Domain Class Definition Report

Last revised: Page 14 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Class Name

Class Description

Initial Data Volume (approx.)

Annual Data growth rate (in approx. %)

Attributes (fields) of the class Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :

4.6.2. Entity Definition Report

Last revised: Page 15 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Entity Name

Entity Description

Initial Data Volume (approx.)

Annual Data growth rate (in approx. %)

Attributes (fields) of the Entity Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :
Name :

Description :

5. Non-Functional requirements

5.1. Security Requirements

5.1.1. Authentication

Use Case / Business Function Transaction type triggered

Name (Level 0 : Anonymous,
Level 1 : Pseudonymous,
Level 2 : Identified,
Level 3 : Verified)

Last revised: Page 16 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

5.1.2. Authorization and Access Controls

Actor / Business Unit Conceptual Class / Type of Access Control

Name Business Entity Name needed on the Conceptual
Class / Business Entity :

C Create
R Read
U Update
D Delete

5.1.3. Information Security Classification and labelling

5.2. Availability Requirements

Last revised: Page 17 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Use Case / Business Function Availability Requirements

Name - Regular work hours
- 24x7
- Any other (please describe)

5.3. Usability Requirements

5.4. System Help Requirements

Last revised: Page 18 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Use Case / Business Function Help Requirements

Name - Field level (online)
- Screen level (online)
- Help Printing Options
- Operations Manual (Offline)
- Any other (please describe)

5.5. Performance Requirements

Use Case Name / Business Performance Requirements

Function Name / Transaction (response time)
description (in seconds or minutes)

5.6. Scalability Requirements

5.6.1. User Scalability

5.6.2. Application Scalability

Last revised: Page 19 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

6. Interface Requirements

6.1. User Interface Requirements

6.2. System Interface Requirements

Last revised: Page 20 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Revision Log

Date Version Change Reference Reviewed by

[date]

Appendices

Last revised: Page 21 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Approval
This document has been approved as the official Business Requirements Document for the Project
Name project.
Following approval of this document, changes will be governed by the projects change
management process, including impact analysis, appropriate reviews and approvals, under the
general control of the Master Project Plan and according to Project Support Office policy.

Prepared Signature Date

by

Author's
Name
[Title]
[Organizat
ion]
Approve Signature Date
d by

[Client
Acceptor
s Name]
[Title]
[Organizat
ion]

Last revised: Page 22 of 23

Security Classification:
AS-IS and TO-BE CREDIT IMPLEMENT TO GET PAID

Last revised: Page 23 of 23

Security Classification: