state of florida - myflorida.com - the official portal of ...€¦ · state of florida office of...

State of Florida

Office of Financial Regulation

Deferred Presentment Transaction System

Requirements Specification Report

Version: 1.00 (Final)

November 19, 2014

Florida Office of Financial Regulation


Deferred Presentment Transaction System Page 1 of 56

Requirements Specification Report Version: 1.00 (Final)

Table of Contents

BACKGROUND ......................................................................................................................... 3

PURPOSE .................................................................................................................................................... 4 SERVICE DELIVERY MODEL .......................................................................................................................... 4 APPROACH .................................................................................................................................................. 4

DEFINITIONS ............................................................................................................................ 6

DEFERRED PRESENTMENT TRANSACTION SYSTEM ......................................................... 8

DPT BUSINESS PROCESS ............................................................................................................................ 8 DPTS FUNCTIONALITY ............................................................................................................................... 14 DPTS HIGH LEVEL ARCHITECTURE ............................................................................................................ 16 DPTS CONCEPTUAL ARCHITECTURE .......................................................................................................... 17 DPTS TECHNICAL ARCHITECTURE ............................................................................................................. 18

DPTS REQUIREMENTS ...........................................................................................................19

WHAT IS A REQUIREMENT? ........................................................................................................................ 19 WHAT IS A FUNCTIONAL REQUIREMENT? .................................................................................................... 19 WHAT IS A TECHNICAL REQUIREMENT? ....................................................................................................... 19 WHAT IS A REGULATORY REQUIREMENT? ................................................................................................... 19 ROLES BASED SECURITY ........................................................................................................................... 20

DPTS Licensee Role Based Security – Web ....................................................................................................... 20 DPTS Licensee Role Based Security – System Interface ................................................................................... 21 DPTS Licensee Role Based Security – IVR ........................................................................................................ 21 DPTS OFR Role Based Security ......................................................................................................................... 22

SYSTEM SECURITY AND USER ACCESS REQUIREMENTS ................................................................................ 23 AGENCY REQUIRED INVOICING AND BILLING REQUIREMENTS ......................................................................... 23 INVENTORY OF CORRESPONDENCE, FORMS AND REPORTS ......................................................................... 23 SYSTEM INTERFACES. ................................................................................................................................ 23 DATA PROTECTION, BUSINESS CONTINUITY AND DATA RECOVERY REQUIREMENTS ...................................... 23 REQUIREMENTS TRACEABILITY MATRIX ...................................................................................................... 25 ASSUMPTIONS ........................................................................................................................................... 56

List of Figures

Figure 1 – Service Delivery Model.............................................................................................. 4

Figure 2 – DPTS Functionality ..................................................................................................14

Figure 3 – DPTS High Level Architecture ..................................................................................16

Figure 4 – DPTS Conceptual Architecture .................................................................................17

Figure 5 – DPTS Technical Architecture ...................................................................................18

List of Exhibits

Exhibit 1 – Definition of Key Terms ............................................................................................ 6

Exhibit 2 – DPT Business Process ............................................................................................. 8





Exhibit 3 – DPTS Licensee Role Based Security – Web ...........................................................20

Exhibit 4 – DPTS Licensee Role Based Security – System Interface ........................................21

Exhibit 5 – DPTS Licensee Role Based Security – IVR .............................................................21

Exhibit 6 – DPTS OFR Role Based Security .............................................................................22

Exhibit 7 – DPTS Interfaces ......................................................................................................23

Exhibit 8 – Requirements Traceability Matrix ............................................................................25





Background

The Florida Office of Financial Regulation (“OFR”, “Office”) is responsible for licensing and regulating Deferred Presentment Providers (“DPP”, Licensees”) in the State of Florida as per Chapter 560, F.S. Part IV.

A Deferred Presentment Provider is a person who engages in a deferred presentment transaction (“DPT”), which is to provide currency or a payment instrument in exchange for a person's check and agreeing to hold the person's check for a period of time prior to presentment, deposit, or redemption (i.e. “Payday Loan”). Florida law requires that all persons desiring to become a Deferred Presentment Provider must be licensed as a Money Services Business by OFR.

In 2001, the Florida Legislature passed the Deferred Presentment Act ("Act") which modified requirements for regulation of Money Transmitters and DPTs. The Act required OFR to implement the Deferred Presentment Program ("Program"), including a real-time statewide database for use by all licensed DPPs to record and maintain deferred presentment transactions. The legislative intent was to provide for the regulation of DPTs, and to prevent fraud, abuse and other unlawful activity associated with DPTs, in part by:

Providing for sufficient regulatory authority and resources to monitor deferred presentment transactions

Preventing rollovers

Regulating the allowable fees charged in connection with a deferred presentment transaction

OFR elected to source the development, maintenance and day-to-day operations of the Program to a Third Party Administrator (“TPA”), and the system went into production in February 2002. Implementation of the deferred presentment transaction system (“DPTS”) enabled OFR to record and maintain factual information about the industry, characteristics of DPTs, and consumer’s use of this financial product. Over 70 million DPTs have been conducted since the inception of the Program.

The existing contract with the TPA is set to expire on August 27, 2016. The Office is looking to procure a new contract for providing the above system and related services. In order to complete the procurement and implementation of the DPTS, OFR has divided the effort into two phases:

Phase I – Requirements Definition and Procurement Support: OFR initiated this “Requirements Definition and Procurement Support” phase to define the requirements for the Deferred Presentment Transaction System (“DPTS”) and to issue a competitive solicitation to secure the services of an implementation vendor to implement the DPTS system. Upon a determination of the total contract cost for the DPTS and associated services, it may be necessary for the Office to request additional appropriation from the Legislature.

Phase II – Implementation: The implementation phase of the project will begin after awarding a contract to the implementing vendor.





Purpose

The purpose of this Requirements Specification Report (“RSR”) is to capture the regulatory, functional, and technical requirements needed to develop a Scope of Work for the DPTS system.

Service Delivery Model

The Office’s service delivery model as applicable to the DPTS is as follows:

Figure 1 – Service Delivery Model

Approach

The project team used the following approach to gather and document the requirements:

The Project Team reviewed and extracted regulatory requirements from the Florida Statute 560, Part IV.

The Project Team reviewed the approach for developing the RSR with the OFR’s key stakeholders.

The Project Team identified key functional and non-functional components to be discussed in the Requirements Gathering sessions.

The Project Team conducted Requirements Gathering sessions with the OFR’s key stakeholders to identify and document requirements.

The Project Team conducted meetings with Licensees.

The Project Team developed a draft RSR (includes the Requirements Traceability Matrix [RTM]).

The Project Team performed quality assurance review of the RSR to help ensure clarity, consistency, and readability of the requirements.

The OFR’s key stakeholders reviewed the draft RSR and provided feedback.





The Project Team updated the RSR based on OFR’s feedback.

The OFR’s key stakeholders reviewed the updated RSR and provided approval sign-off.





Definitions

The following table (see Exhibit 1 – Definition of Key Terms) provides a list of key terms and their definitions.

Exhibit 1 – Definition of Key Terms

Term Definition

Deferment Period This refers to the number of days a deferred presentment provider agrees to defer depositing, presenting, or redeeming a payment instrument.

Deferred Presentment Provider (DPP)

This refers to a person who is licensed under part II or part III of Chapter 560 and has filed a declaration of intent with the office to engage in deferred presentment transactions as provided under part IV of Chapter 560. Also referred to as “Licensee”.

DPP Teller This refers to an authorized person responsible for conducting deferred presentment transactions on behalf of a licensee. Also referred to as “DPP User”.

Deferred Presentment Transaction (DPT)

This refers to providing currency or a payment instrument in exchange for a drawer’s check and agreeing to hold the check for a deferment period.

Deferred Presentment Transaction System (DPTS)

This refers to the Office administered transactional database authorized by Section 560.404(23), F.S. The system used to record the deferred presentment transactions. Also referred to as “System” and “Database”.

DPTS Contractor This refers to the vendor, which contracted with the Office for the purpose of developing and administering the daily operations of the DPTS. Also referred to as “Contractor”, “Vendor”.

Drawer This refers to a customer who writes a personal check and upon whose account the check is drawn. Also referred to as “Consumer” and “Customer”.

Extension of a Deferred Presentment Transaction

This refers to continuing a deferred presentment transaction past the deferment period by having the drawer pay additional fees and the deferred presentment provider continuing to hold the check for another deferment period.

F.S. This refers to the 2014 Florida Statutes.

Licensee This is a person licensed under Chapter 560. Also referred to as deferred presentment provider, “DPP”, and “Provider”.

Location This refers to a branch office, or mobile location whose business activity is regulated under Chapter 560.

Mobile Location This refers to the VIN number of the automobile from which a licensee operates a mobile location.





Term Definition

Office This refers to the Office of Financial Regulation.

Person This refers to an individual, partnership, association, trust, corporation, limited liability company, or other group, however organized, but does not include a public agency or instrumentality thereof.

Personal Identification Information (PII)

This refers to a customer’s name that, alone or together with any of the following information, may be used to identify that specific customer:

(a) Customer’s signature.

(b) Photograph, digital image, or other likeness of the customer.

(c) Unique biometric data, such as the customer’s thumbprint or fingerprint, voice print, retina or iris image, or other unique physical representation of the customer.

Physical Location This refers to the physical address of the DPP’s primary business location or branch office.

POS system This refers to a Point of Sale system used by DPPs to process and store deferred presentment transactions. This is an internal system owned and maintained by a DPP.

Rollover This refers to the termination or extension of a deferred presentment agreement by the payment of an additional fee and the continued holding of the check, or the substitution of a new check by the drawer pursuant to a new deferred presentment agreement.

RPO This is the Recovery Point Objective and is the point to which information used by an activity must be restored to enable the activity to operate on resumption.

RTO This is the Recovery Time Objective and is the target time set for resumption of product, service or activity delivery after an incident.

SLA This is a Service-level Agreement and is a part of a service contract where a service is formally defined.

Termination This refers to the termination of a deferred presentment agreement. The check that is the basis for the agreement is redeemed by the drawer by payment in full in cash, or is deposited and the deferred presentment provider has evidence that such check has cleared. Verification of sufficient funds in the drawer’s account by the deferred presentment provider is not sufficient evidence to deem that the deferred deposit transaction is terminated.

Uptime This refers to the time during which the DPTS is in operation.






The purpose of this Deferred Presentment Transaction System is to:

Prevent the practice of rollover transactions;

Prevent simultaneous deferred presentment transactions with multiple providers by an individual drawer; and

Prevent a new deferred presentment transaction by a drawer within 24 hours of the termination of a prior transaction.

DPT Business Process

The following provides a process flow and process narrative associated with a deferred presentment transaction:

Exhibit 2 – DPT Business Process

Process Name Conduct Deferred Presentment Transaction

Process Trigger A potential DPP Customer wants to enter into a new Deferred Presentment Agreement.

Pre-conditions DPP user is logged into the Deferred Presentment Transaction System via the website.






Process Flow Diagram

(DPTS Website)

StartStart

Enter Drawer’s

Identification Number

Enter Drawer’s

Identification Number

Eligible?Eligible?Ineligible

Notice

Ineligible

Notice

Enter DPT DetailsEnter DPT Details

DPT

Confirmation

DPT

Confirmation

EndEnd

Eligibility Re-

validated?

Eligibility Re-

validated?

Ineligible

Notice

Ineligible

Notice

Validate Drawer’s ID

& Determine

Eligibility

No

Yes

Re-validate Eligibility

Yes

No






Basic Flow Narrative

(using DPTS Website)

1. The DPP User enters and submits the Customer’s Identity Number (i.e. Social Security Number (SSN), Individual Tax Identification Number (ITIN) or Alien Registration Number (ARN) to the DPTS system.

2. The DPTS system checks the Customer’s identification number against the DPTS database and determines if the customer is eligible for a new Deferred Presentment Transaction (DPT) (i.e. initial eligibility).

Optional processing - The DPTS system may also validate the SSN (e.g. against the SSN death list index, basic constructs of an SSN, SSN issued within the last 5 years, SSN has not been issued by the SSA, and other checks) to assist in fraud prevention. The DPP User has an ability to override the system’s optional processing results and continue with the transaction.

If the customer is eligible, the DPTS system displays the new transaction webpage.

If the customer is not eligible, the DPTS system displays a message indicating the reason for ineligibility. The message can be printed by the DPP User for delivery to the Customer.

3. The DPP User enters and submits the Customer details and transaction details, including but not limited to:

First Name

Last Name

Middle Name

Address ( Street Address, City, State, Zip, Country)

Telephone Number

Driver’s License Information (Number, Expiration Date, State)

Date of Birth

Deferred Presentment Agreement Date

Deferred Presentment Due Date

Deferred Presentment Advance Amount

Verification Fee

Transaction Fee

Guarantee Instrument Type (e.g. Check)

Guarantee Instrument Reference Number

4. The DPTS system:

Re-validates the eligibility.

If the customer is eligible, the DPTS system displays the transaction






success webpage with the transaction confirmation details. The message can be printed by the DPP User for delivery to the Customer.

If the customer is not eligible, the DPTS system displays a message indicating the reason for ineligibility. The message can be printed by the DPP User.

5. Basic Flow Ends.

Basic Flow

(using DPP Point of Sale system and DPTS Web Service system interface)

The DPP User is performing Basic Flow steps 1 and 3 within the DPP Point of Sale (DPP POS) system and the DPP POS system is interfacing with the DPTS in real time.

The DPTS system processing remains the same as Basic Flow steps 2 and 4.

Basic Flow

(using DPTS Interactive Voice Response (IVR) system)

The DPP User accesses the IVR System using a User ID and Password.

The DPP User has an ability to perform three functions using the IVR system:

1. Determine Eligibility The DPP User enters and submits the Customer’s SSN or ITIN.

The system checks the Customer’s SSN or ITIN against the DPTS database and determines if the customer is eligible for a new Deferred Presentment Transaction.

2. Open a Temporary Transaction

The DPP User enters and submits the Customer’s SSN or ITIN.

The system checks the Customer’s SSN or ITIN against the DPTS database and determines if the customer is eligible for a new Deferred Presentment Transaction.

If the customer is eligible, the system provides a temporary transaction number.

If the customer is not eligible, the DPTS system provides a message to the DPP User indicating the ineligibility of the customer.

Post Processing – If the customer is eligible, the temporary transaction number is used by the DPP User to enter into a DPT Agreement with the customer. The transaction details shall be entered into the DPTS system website or via the DPTS Web Service using the temporary transaction number as a reference within 24 of the DPP regaining access to the DPTS. No further eligibility processing is performed by the system for such transactions.

3. Close a Transaction

The DPP User enters and submits the Transaction Number for the






DPT to be closed.

The system verifies the transaction number.

o If the transaction number is valid, the system prompts the DPP User to enter the transaction information, including but

not limited to: Close date

Close time

Payment method

Deposit date

o If the transaction number is invalid, the system prompts the DPP User to re-enter the transaction number.

The system closes the transaction and provides a confirmation message.

Alternate Flow 1 Narrative

(Amend / Update, Close, Cancel DPP Transaction)

The DPP User has the ability to change customer information and transaction information.

The DPP user may search using the customer information (SSN, ITIN, or ARN) or using the transaction information (i.e. Transaction Number)

1. The DPTS system returns the unique customer or transaction record. 2. The DPP User updates the customer information (Name, Address, Driver’s

License information). The Customer ID (SSN, ITIN, or ARN) cannot be updated. The existing transaction should be closed and a new transaction should be created if the Customer ID needs to be updated.

3. The DPP User updates the transaction information (all transaction data except the system generated transaction number are editable). This step could also be used to update the status of the DPT (i.e. close, pending etc.).

4. The system returns a confirmation message indicating the update. 5. Alternate Flow Ends.

Business Rules The following core business rules apply to all transactions:

1. The system shall prevent a customer from having more than one open transaction at any given time in the system (with that DPP or any DPP).

2. The system shall prevent a customer from opening a new transaction within 24 hours of closing a previous transaction.

3. The system shall reject a transaction where the currency provided to the consumer exceeds $500.

4. The system shall reject a transaction that exceeds $555.00 including fees (transaction, verification fees).

5. The system shall reject a verification fee that exceeds $5.00. 6. The system shall reject a transaction fee that exceeds 10% of the currency or

payment instrument provided to the consumer. 7. The system shall reject a DPT agreement term in excess of 31 days or less






than 7 days. 8. Transactions can be cancelled within 24 hours of opening and the customer

shall be immediately eligible for another transaction.

See Exhibit 8 – Requirements Traceability Matrix for all business rules and data validation rules.





DPTS Functionality

The following diagram (see Figure 2 – DPTS Functionality) depicts the functionality of the DPTS system for the Licensees and the OFR.

OF

RL

ice

ns

ee

DPTS - Licensee

Transaction

Management

New

Amend

Close

Access Management

Manage Administrator

Accounts

Manage User Accounts

Information Services

Search

Reports

System Interfaces

DPTS Web Service

Interface Configuration

DPTS - OFR

Compliance Reporting

Dashboards

Access Management

Data Analytics & Alerts

Transaction History

Customer Transactions

DPP Transactions

Manage Supervisor

Accounts

System Interface

Social Security Number

(SSN) Validation

Interface Configuration

OFR Regulatory

Enforcement and

Licensing System

(REAL)

Search

Reports

Cancel

Figure 2 – DPTS Functionality

The core functionality of the DPTS system from an OFR user perspective is:

The ability to view transaction history by customer, DPP, and by geographical location(s) etc.

The ability to perform advanced data searches and retrieve transaction information (e.g. across DPPs, Customers, timelines, geographical location(s)).





The ability to generate and view pre-configured (i.e. canned) reports for viewing transactions and for compliance reporting.

The ability to generate and view ad-hoc reports for viewing transactions and for compliance reporting.

The ability to generate and view dashboards with synthesized data.

The ability to perform OFR related user administration activities.

The ability to execute advanced data analytics and receive system generated alerts based on user configured parameters (e.g. ineligible transactions, unusual volume).

An interface with the Florida Office of Financial Regulation Regulatory Enforcement and Licensing System (REAL) to validate if the DPP has an active license and to update and keep current the status of a license.

The ability to meet record retention requirements of the Office.

The ability to monitor invoicing and outstanding balances of Licensees.

The core functionality of the DPTS system from a Licensee user perspective is:

The ability to determine eligibility of a potential customer for a DPP transaction through a web portal.

The ability to submit, amend, close, and cancel transactions through a web portal.

The ability to perform data searches and retrieve transaction information.

The ability to generate and view pre-configured (i.e. canned) reports for viewing transactions.

The ability to perform Licensee related user administration activities.

The ability to determine eligibility of a potential customer for a DPP transaction through a web service (i.e. a system interface between the Licensee Point of Sale device and the DPTS system).

The ability to submit, amend, close, and cancel transactions through a web service (i.e. a system interface between the Licensee Point of Sale device and the DPTS system).

The ability to validate the Customer’s SSN or ITIN.

The ability to determine eligibility of a potential customer for a DPP transaction through an Interactive Voice Response (“IVR”) system.

The ability to open temporary transactions and close transactions through an IVR system.

The ability to view and pay invoices using the DPTS.





DPTS High Level Architecture

The DPTS High Level Architecture diagram (see Figure 3 – DPTS High Level Architecture) depicts a potential high level architecture concept for the DPTS system.

Figure 3 – DPTS High Level Architecture

VENDOR OTHER ENTITIESOFRDPP

TRANSMISSION

WEB

System

Interface

REAL SSN

Deferred Presentment Providers

(DPPs, Licensees)

DPTS

OFR Users

IVR





DPTS Conceptual Architecture

The DPTS Conceptual Architecture diagram (see Figure 4 – DPTS Conceptual Architecture) depicts a potential conceptual architecture for the DPTS system.

Figure 4 – DPTS Conceptual Architecture

Public Internet

DPTS

Reporting

Database

DPTS

Production

Database

EX

TE

RN

AL S

YS

TE

MS

SSN

DPP BUSINESS MODULES

Transaction

ManagementData Analytics /

AlertsData Exchange

Interface

Management

Web Services

Licensee Profile

Management

REPORTING

Dashboards

Reporting

Licensee OFR

DPP USER INTERFACE

DPTS

Contractor Network

Public Internet

REAL





DPTS Technical Architecture

The DPTS Technical Architecture diagram (see Figure 5 – DPTS Technical Architecture) depicts a potential technical architecture concept for the DPTS system.

Figure 5 – DPTS Technical Architecture

Web Services

DEVICES CLIENT

TIER

Browser

Sys

Interface

PR

ES

EN

TA

TIO

N T

IER

Se

ss

ion

Sta

te

Ma

na

ge

me

nt

Pre

se

nta

tio

n L

og

ic

Pro

ce

ss

ing

BU

SIN

ES

S T

IER

Business Logic

Data Access Objects

Authentication

Interface Logic

Data Exchange Web

Services

Analytics / Alerts

DA

TA

TIE

R

DPTS

Reporting

Database

DPTS

Production

Database

EX

TE

RN

AL S

YS

TE

MS

SSN

REAL

Licensee

OFR

Browser

Telephone





DPTS Requirements

The following definitions are from International Standards Organization (ISO)/ Institute of Electrical and Electronics Engineers (IEEE) ISO/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering specification.

What is a Requirement?

A requirement is defined as a statement which translates or expresses a need and its associated constraints and conditions.

For example: Need – We need transparency into the Deferred Presentment Providers operations of transactions.

Requirement – The solution shall provide the ability for a Deferred Presentment Provider to transmit transactional information to the DPTS.

What is a Functional Requirement?

Functional requirements describe the system or system element functions or tasks to be performed.

For example: The solution shall provide the ability to query the transactions entered by the licensee.

What is a Technical Requirement?

Technical requirements are requirements under which the system is required to operate or exist or system properties. They define how a system is supposed to be.

For example: The solution shall encrypt transmissions of data between systems.

What is a Regulatory Requirement?

Regulatory requirements are legal and compliance oriented requirements that are prescribed by statute, law, rule or local ordinances that the system must meet in order to enable its users and owners to comply with the law.

For example: The system shall comply with the Americans with Disabilities Act.





Roles Based Security

The DPTS system is expected to include configurable role based security for the Licensees and the OFR users.

DPTS Licensee Role Based Security – Web

The following table provides the various types of users from a Licensee perspective and their corresponding security access. The security access noted below is limited to a DPP and visibility into another DPP’s operations is restricted.

Exhibit 3 – DPTS Licensee Role Based Security – Web

Function Administrator Supervisor User

Create User Profile Yes (All) No No

Modify User Profile Yes (All) Yes (Self & User) Yes (Self)

Reset Passwords Yes (All) Yes (Self & User) Yes (Self)

Inactivate User Profile Yes (All) Yes (User only, Not Self) No

Logically Delete User Profile Yes (All) No No

Submit Transaction Yes Yes Yes

Query Transaction Yes (All) Yes (All) Yes (All)

View Transaction Yes (All) Yes (All) Yes (All)

Amend Transaction Yes (All) Yes (All) Yes (All)

Close Transaction Yes (All) Yes (All) Yes (All)

Cancel Transaction (Admin Close)

Yes (All) Yes (All) No

Delete Transaction No No No

View Reports Yes (All) Yes (Selected) No

View Billing Yes (All) No No

The system shall provide for five (5) administrator accounts and unlimited supervisor and user accounts for each DPP.





DPTS Licensee Role Based Security – System Interface

The following table provides the role based access details for transactions performed using the system interface.

Exhibit 4 – DPTS Licensee Role Based Security – System Interface

Function DPP POS System

Create User Profile No

Modify User Profile No

Reset Passwords No

Inactivate User Profile No

Logically Delete User Profile No

Submit Transaction Yes

Query Transaction No

View Transaction No

Amend Transaction Yes (All)

Close Transaction Yes (All)

Cancel Transaction (Admin Close) Yes (All)

Delete Transaction No

DPTS Licensee Role Based Security – IVR

The following table provides the role based access details for transactions performed using the Interactive Voice Response (IVR) system.

Exhibit 5 – DPTS Licensee Role Based Security – IVR


Create User Profile No No No

Modify User Profile No No No

Reset Passwords No No No

Inactivate User Profile No No No

Logically Delete User Profile No No No

Submit Transaction (obtain Temporary Transaction Number)

Yes Yes Yes

Query Transaction No No No






Amend Transaction No No No

Close Transaction Yes Yes Yes


No No No

Delete Transaction No No No

View Reports No No No

View Billing No No No

DPTS OFR Role Based Security

The following table provides the various types of users from an OFR perspective and their corresponding security access:

Exhibit 6 – DPTS OFR Role Based Security

Function Administrator User

Create User Profile Yes (All) No

Modify User Profile Yes (All) Yes (Self)

Reset Passwords Yes (All) Yes (Self)

Inactivate User Profile Yes (All) No

Logically Delete User Profile Yes (All) No

Submit Transaction No No

Query Transactions Yes (All) Yes (All)

View Transactions Yes (All) Yes (All)

Amend Transaction No No

Close Transaction No No


No No

Delete Transaction No No

Generate Reports Yes Yes

Configure Alerts Yes Yes





System security and user access requirements

The system security and user access requirements for the DPTS system are documented in the requirements traceability matrix (see Exhibit 8 – Requirements Traceability Matrix, Requirement Sub Type = “Security” and “User Administration”).

Agency required invoicing and billing requirements

The Agency required invoicing and billing requirements for the DPTS system are documented in the requirements traceability matrix (see Exhibit 8 – Requirements Traceability Matrix, Requirement Sub Type = “Back Office”).

Inventory of Correspondence, Forms and Reports

The Agency required reporting requirements for the DPTS system are documented in the requirements traceability matrix (see Exhibit 8 – Requirements Traceability Matrix, Requirement Sub Type = “Reports”).

System Interfaces.

The DPTS system interfaces are documented below in Exhibit 7 – DPTS Interfaces:

Exhibit 7 – DPTS Interfaces

Interface Agency Purpose

Regulatory Enforcement and Licensing (REAL) System


To validate if the Licensee has an Active license and provide a current status of a license.

Social Security Number

Social Security Validation To validate if the social security number provided by the customer is a valid number.

Additional specific interface requirements are documented in the Requirements Traceability Matrix (see Exhibit 8 – Requirements Traceability Matrix, Requirement Sub Type = “Interface”)

Data Protection, Business Continuity and Data Recovery requirements

The data housed within DPTS is considered to be Personal Information.

According to F.S. 501.171 (1) (g)1.“Personal Information” means either of the following:

a. An individual’s first name or first initial and last name in combination with any one or more of the following data elements for that individual:

(I) A social security number;

(II) A driver license or identification card number, passport number, military identification number, or other similar number issued on a government document used to verify identity;





(III) A financial account number or credit or debit card number, in combination with any required security code, access code, or password that is necessary to permit access to an individual’s financial account;

(IV) Any information regarding an individual’s medical history, mental or physical condition, or medical treatment or diagnosis by a health care professional; or

(V) An individual’s health insurance policy number or subscriber identification number and any unique identifier used by a health insurer to identify the individual.

b. A user name or e-mail address, in combination with a password or security question and answer that would permit access to an online account.

2. The term does not include information about an individual that has been made publicly available by a federal, state, or local governmental entity. The term also does not include information that is encrypted, secured, or modified by any other method or technology that removes elements that personally identify an individual or that otherwise renders the information unusable.

The data protection, business continuity, and data recovery requirements for the DPTS system are documented in the requirements traceability matrix (see Exhibit 8 – Requirements Traceability Matrix, Requirement Sub Type = “Security” and “Availability”)





Requirements Traceability Matrix

The following table provides a requirements traceability matrix for the DPTS:

Req ID – A unique identifier for the requirement

DPTS System Area – Identifies the area of the system to which the requirement applies (i.e. Licensee –Web, Licensee – System Interface, OFR – Web, DPTS – Core, ALL)

Requirement Type – Identifies the type of requirement (i.e. Regulatory, Functional, Technical)

Requirements Sub-type – Identifies the sub type of requirement (e.g. Security, Usability)

Requirement Description – Provides a description of the requirement

Exhibit 8 – Requirements Traceability Matrix

Req ID DPTS System Area

Requirement Type

Requirement Sub-type

Requirement Description

1 All Functional Advanced Search The system shall provide the ability to query all fields in the database.

2 All Functional Advanced Search The system shall provide an ability to perform Boolean searching.

3 All Functional Advanced Search The system shall provide an ability to perform truncation searching.

4 All Functional Advanced Search The system shall provide the users with an ability to export retrieved transactions into a file (e.g. xls, csv, ASCII, pdf) with no limit on the number of transactions.






Requirement Type



5 All Functional Business Rules The system must perform the following data validations in accordance with the business rules, including but not limited to: - Required fields that are blank, or empty, or null - Required fields that contain invalid values including invalid special characters - Required fields that contain invalid entry length (i.e. validate SSN field is 9 numbers long) - Alphabetic fields with numeric characters - Numeric fields with alphabetic characters - Incomplete fields such as SSN, date of birth, and phone numbers - Date fields to contain valid dates (in a given / pre-determined date range)

6 All Functional Reports The system shall include a web-based reporting module accessible by both authorized DPP users and OFR users.

7 All Functional Reports The reporting module shall include all reports outlined below. These reports shall be available for authorized system users to generate upon demand. • DPTS Contractor SLA Reports to OFR o Program Management Monthly Report o Florida Trends in Deferred Presentment

8 All Functional Reports The system shall provide the ability for users to manipulate report parameters in order to limit the information returned (i.e. limiting by status or date range) and sort data dynamically (i.e. by clicking column headers).

9 All Functional Reports Reports shall be run from a dedicated report data mart.

10 All Functional Reports The system shall provide the ability to export any report to a PDF file that is formatted to the user's choice of page size.

11 All Functional Reports The system shall provide users the ability to export report data in a format that can be imported into standard word processing, spreadsheet, database, and statistical tools (such as Microsoft Word, Excel, and Access).

12 All Functional Reports All reports shall have the capability to include pictorial representations of data (e.g. graphs, pie charts, bubble charts, etc.)






Requirement Type



13 All Functional Transaction Management

The system shall flag and provide an alert to a specified user for duplicate transactions.


The system shall flag and provide alerts to a specified user for consumers who have more than one transaction that is not in closed status.


The business rules enforced by the system shall be consistent between the various access channels of the system (i.e. Licensee Web, Licensee System Interface, and Licensee IVR).

16 All Functional Usability The system shall support English and Spanish languages.

17 All Functional Usability The system shall provide a means to facilitate rapid data entry for large volume or high-speed data entry requirements. This includes the ability to use the keyboard to progress through fields on the screen.

18 All Functional Usability The system shall provide the user with a capability to "drill down" from summary information to supporting detail information where appropriate.

19 All Functional User Administration

The system shall include a common, relational database with real-time access through the Internet for OFR and licensed DPPs to validate the eligibility of every customer to legally conduct a DPT.


The system shall establish the following user roles: (1) OFR Administrator (2) OFR User (3) DPP Administrator (4) DPP Supervisor (5) DPP User


A DPP's customers shall not have access to the system.


The system shall be web based and accessible by any user with Internet access and the appropriate security credentials (username & password).






Requirement Type




Once a password has expired, the system shall provide the user (with a final warning) one more login attempt to change their password.


The system shall allow administrators (OFR, DPP, and DPTS Contractor) to reset passwords without knowing the existing password.


The system shall provide the ability for the DPTS Contractor administrator to log out users when necessary to perform maintenance or other activities that require users to leave the system. This functionality shall only be used during scheduled down-time and with OFR permission.


The system shall provide the ability to limit log-on of user IDs to one workstation at a time. If such functionality is enforced and the user attempts to log onto a workstation while already logged on another, provides a message that the user ID is already in use.


The system shall issue an alert to and lock the end-user account and notify the System Administrator (OFR, DPP, and DPTS Contractor) after a specified number of unauthorized log on attempts.


The system shall provide the ability to deactivate user logon IDs after system administrator (OFR, DPP, DPTS Contractor) defined time of inactivity (days/weeks).


The system must provide the ability to deactivate and archive a former user account.


The system shall restrict access and will be available only to those DPPs identified by OFR as eligible to conduct business in the State.


The Contractor shall create at least five OFR Administrator accounts for users designated by OFR. The designated users shall have the ability to administer all user accounts for OFR.






Requirement Type




The Contractor shall create five DPP Administrator accounts for each DPP as designated by the primary DPP contact. The designated user shall administer user accounts for all of their locations.


The Contractor and licensee administrators shall be responsible for maintaining (resetting forgotten passwords) or deactivating Administrator accounts for any DPP. The Contractor and OFR administrators shall be responsible for maintaining (resetting forgotten passwords) or deactivating Administrator accounts for OFR.

34 Financial Management

Functional Back Office The DPTS transaction fee shall be $1.00 per transaction. A DPP shall be assessed this fee for each transaction after 24 hours of registering and recording the transaction on the database (i.e. Status = Open).


Functional Back Office A DPP shall not be assessed the $1.00 for each transaction if a DPP user cancels a DPT within 24 hours of the transaction opening.


Functional Back Office One DPT includes all steps in the customer loan process from opening to closing.


Functional Back Office The system shall provide an ability to generate invoices to DPPs for DPT transactions conducted during a specific period of time.


Functional Back Office On behalf of OFR, the DPTS Contractor shall electronically submit an invoice to the DPP for its transaction fees at least five (5) days before payment is due. The DPTS Contractor shall submit such invoices for payment to the DPP every seven (7) days.


Functional Back Office The system shall provide the DPTS Contractor with an ability to track and reconcile payments made by DPPs to DPTS contractor against the invoices submitted by DPTS contractor.






Requirement Type




Functional Back Office The system shall provide the OFR and DPTS Contractor with an ability to track and reconcile payments made to OFR by the DPTS contractor, against the invoices made and payments received from the DPPs. Three way reconciliation as follows: 1. Amount billed to DPP by the DPTS Contractor. 2. Amount received from DPP paid to the DPTS Contractor. 3. Amount paid to OFR by the DPTS Contractor.


Functional Back Office The system shall retain copies of the invoices submitted to the DPPs.

42 Licensee IVR

Functional Transaction Management

The DPTS shall provide an IVR System that is fully integrated with the DPTS to check eligibility, open a temporary transaction, and close transactions. See exhibit titled: "DPTS Licensee Role Based Security – IVR".

43 Licensee IVR

Functional Usability The IVR system shall require Licensees to perform no more than 4 steps for opening temporary transactions and closing transactions.

44 Licensee IVR

Functional Usability The IVR system shall not have any wait time or queuing of calls for opening temporary transactions and closing transactions.

45 Licensee System Interface


The DPTS shall provide a licensee system interface (web service) to perform the DPP transactions using the Licensee's Point of Sale system (instead of the DPTS Licensee Web Portal) and export such transactions in real time to the DPTS using the system interface (web service). See exhibits titled: "DPTS Licensee Role Based Security – System Interface".

46 Licensee Web

Functional Advanced Search The system shall allow DPPs to search for a customer’s information and transaction history using at least one (1) of the following criteria: (1) Customer Social Security Number (2) Individual Taxpayer Identification Number (3) Customer Alien Registration Number (4) Transaction Number






Requirement Type



47 Licensee Web

Functional Availability In the event that the database is unavailable and that all alternative methods for registering a transaction and receiving a transaction authorization number are also unavailable, the Contractor shall generate written authorization, in the form of email or fax, to all eligible DPPs to conduct transactions during the specified period of system unavailability with consent from the OFR. (Refer to Rule 69V-560.909 3(a) F.A.C.)

48 Licensee Web

Functional Business Rules The system shall provide the ability to perform an initial eligibility check using the customer’s Social Security Number (SSN) / Individual Taxpayer Identification Number (ITIN) or their Alien Registration Number (ARN).

49 Licensee Web

Functional Business Rules The system's response to a customer eligibility check shall be limited to the eligibility determination and the reason for such determination (i.e. SSN, ITIN, ARN shall not be displayed back on screen).

50 Licensee Web

Functional Business Rules The system shall validate the Social Security Number before the customer's eligibility is determined.

51 Licensee Web

Functional Business Rules The system shall prevent a user from opening a new transaction for any person having an outstanding DPT with that or any other DPP.

52 Licensee Web

Functional Business Rules The system shall prevent a user from opening a new transaction for any person having a previous DPT with that or any other DPP that has been terminated within the preceding 24 hours.

53 Licensee Web

Functional Business Rules The system shall automatically perform a second eligibility check prior to opening a new transaction. (i.e. Once all of the required information has been submitted to the database, the database will re-verify the eligibility search. If the drawer's eligibility is confirmed, the DPT will be recorded as open, assigned a transaction authorization number, and the transaction authorization number will be provided onscreen communicated to the DPP user as evidence that the transaction has been authorized by the database.)






Requirement Type



54 Licensee Web

Functional Business Rules The system shall assign a unique transaction authorization number to each new transaction.

55 Licensee Web

Functional Business Rules The system shall reject a transaction where the currency provided to the consumer exceeds $500.

56 Licensee Web

Functional Business Rules The system shall reject a transaction where the aggregate of the currency provided, verification fee, and transaction fee exceeds $555.00.

57 Licensee Web

Functional Business Rules The system shall reject a verification fee that exceeds $5.00.

58 Licensee Web

Functional Business Rules The system shall reject a transaction fee that exceeds 10% of the currency or payment instrument provided to the drawer.

59 Licensee Web

Functional Business Rules The system shall reject a DPT agreement term in excess of 31 days or less than 7 days.

60 Licensee Web

Functional Business Rules The system shall allow a user to extend the term of a DPT agreement by 60 days.

61 Licensee Web

Functional Business Rules The system shall provide the transaction authorization number to the DPP user onscreen as evidence that the transaction has been authorized.

62 Licensee Web

Functional Business Rules The system shall automatically assign a status of “Open” to a new transaction.

63 Licensee Web

Functional Business Rules The system shall automatically close the transaction after 14 days, if the DPP has updated the transaction status to "pending-clearing" and no further action has been taken by the provider to update the database.

64 Licensee Web

Functional Business Rules If a drawer cancels the transaction, the drawer should be eligible immediately to enter into another transaction.






Requirement Type



65 Licensee Web

Functional Reports The reporting module shall include all reports outlined below. These reports shall be available for authorized system users to generate upon demand. • DPP Transaction Reports – Licensees o Transaction Report (by status) o Transactions Closed by Auto Close o Transactions Scheduled for Auto Close o View Current Invoices o View Current Disputed Transactions o View Closed Disputed Transactions o View All Invoices o DPP Customer Report

66 Licensee Web

Functional Reports The system shall provide the ability for DPPs to view, print and download on-line reports regarding transactions with their customers.

67 Licensee Web

Functional Reports The system shall provide the ability for DPPs to view, print and download on-line reports regarding billing and invoicing for the DPP by which they are employed.

68 Licensee Web


The system shall provide the ability for DPPs to open a new transaction for an eligible customer by entering the required customer and transaction information.

69 Licensee Web


The system shall allow a temporary transaction to be canceled within 24 hours.

70 Licensee Web


The system shall provide the ability for DPPs to update the status of transactions with the following statuses: (1) Open (2) Pending – Grace Period (3) Pending - Non Sufficient Funds (NSF) (4) Pending - Clearing (5) Pending – Bad Debt (6) Closed






Requirement Type



71 Licensee Web


The system shall allow the DPP to close their completed transaction. In order to close a completed transaction, the system shall require the DPP user to enter the date and time that a transaction was completed as well as the payment method.

72 Licensee Web


In addition to the date and time entered by a DPP user upon closing a transaction, the system shall record the system date and timestamp of the closing.

73 Licensee Web


Prior to processing a new transaction, the system shall prompt the user to indicate whether it is a current transaction or one that was conducted during a time of system unavailability.

74 Licensee Web


The system shall provide the ability for DPP users to amend customer or transaction information as necessary and enter free-form comments regarding a transaction.

75 Licensee Web


The DPP shall have access to the following information for declined transactions: (1) All information regarding previously transacted business with that DPP, if any (2) If not an existing customer of the DPP, the DPP shall only have access to the name of the customer and an indication that there is either an open transaction or a transaction which was closed within the preceding 24 hours for that customer.

76 Licensee Web


In the event that a transaction is declined, the system shall generate a letter to be printed by the DPP user and given to the customer. The letter shall explain the reason for the denial and provide a toll free number to contact the DPTS Contractor.

77 Licensee Web


If during a period of system unavailability a loan is made that should have been rejected, the system should accept the transaction information entered by a DPP user once the system is available, and the system shall generate a report to OFR listing such transactions.






Requirement Type



78 Licensee Web


The system shall cancel the transaction fee against the DPP if a transaction is cancelled by a DPP user within 24 hours of the transaction opening.

79 Licensee Web


The types of payments issued to the drawer shall include: Cash, Check, Stored Value Card, and ACH Credit.

80 Licensee Web

Functional User Administration

The system shall implement the role based security and functions outlined in the Requirements Specification Report accompanying this document. See exhibits titled: 1. DPTS Licensee Role Based Security – Web 2. DPTS Licensee Role Based Security – System Interface 3. DPTS Licensee Role Based Security – IVR 4. DPTS OFR Role Based Security

81 Licensee Web


The system shall receive (from the OFR REAL Interface) and assign a status of “Restricted Provider” to any DPP that is determined ineligible to conduct business in the State.

82 Licensee Web


The system shall not allow DPPs with a status of "Restricted Provider" to open new DPTs.

83 Licensee Web


The system shall allow DPPs with a status of "Restricted Provider" to update or close existing DPTs.

84 Licensee Web


The system shall automatically remove a "Restricted Provider" status designation of the DPP 8:00 a.m. EST one business day after resolution of the issue that caused the restriction (determined and based only on the information contained within the licensee file received from OFR).

85 Licensee Web


Every primary business location of a DPP and every branch office location of which the OFR has been notified shall be permitted to register transactions on the database.

86 OFR Web Functional Advanced Search The system shall provide the user with an ability to drill down into the query results to be able to view a transaction.






Requirement Type



87 OFR Web Functional Analytics The system shall provide the OFR user with an ability to configure dashboards (for OFR senior management and OFR users) without requiring assistance from the DPTS contractor.

88 OFR Web Functional Analytics The system shall provide the OFR user with an ability to configure parameters using any direct field or combination of fields and / or derived fields (e.g. total # of transactions for a Drawer) within the DPTS database that would generate alerts to the OFR user (e.g. Unusual volume, geographical location(s), date ranges, Drawer, DPP, etc.) without requiring assistance from the DPTS contractor.






Requirement Type



89 OFR Web Functional Reports The reporting module shall include all reports outlined below. These reports shall be available for authorized system users to generate upon demand. • DPP Transaction Reports – OFR o Accounting Reports § Delinquent Invoices § Service Fee Invoice § Service Fee Invoice to Transaction Details o Examiner Reports § Backdated Close by DPP § Backdated Close by Region § Customer History § Customer Special Status Report § Customers with Multiple Transactions by Region and DPP § Customers with Multiple Transactions With Same DPP § DB Load Transaction Summary § Declined Customer Eligibility Checks by DPP § Declined Customer Eligibility Checks by Region § Delayed Auto Close by DPP § Delayed Auto Close by Region § DPP Access Report § DPP Listing by Region § DPT Details § DPT History § Reopen Transactions by DPP § Reopen Transactions by Region § SSN Compare Report § SSN Conflict Report § Temporary DPTs by Region






Requirement Type



90 OFR Web Functional Reports The system shall provide detailed revenue information concerning the collection of transaction fees to OFR via on-line reports.

91 OFR Web Functional Reports The system shall provide the ability for OFR users to set up any existing report as a recurring report subscription that will be e-mailed by the system to any recipient based on the predefined terms and schedule.

92 OFR Web Functional Reports The system shall provide the ability for OFR users to edit and delete a report subscription.

93 OFR Web Functional Reports The system shall provide the OFR user with an ability to generate reports on all transactions (with no limit on number of transactions).

94 OFR Web Functional Reports The system shall provide the OFR user with an ability to generate adhoc reports.

95 OFR Web Functional Reports The system shall provide the OFR user with an ability to set-up standard reports that can be generated by users.

96 OFR Web Functional Reports The system shall provide the OFR user with an ability to make changes to standard reports or create new reports without requiring assistance from the DPTS contractor.

97 OFR Web Functional Reports The system shall provide the ability to accurately and timely report fee balances, and providers that are delinquent in their payment of the fees (aging reports)

98 All Regulatory Program The system and the DPTS Contractor shall comply with Part IV Chapter 560 F.S.

99 All Regulatory Program The system and the DPTS Contractor shall comply with Rule 69V-560.707 - 913 F.A.C. as it relates to the system.

100 All Technical Architecture The system shall recover database data up to the last committed transaction following a system failure.

101 All Technical Architecture The system architecture must be scalable and allow for the addition of users and storage of data while maintaining established performance levels.

102 All Technical Architecture The system shall perform at response times as outlined in a Service Level Agreement.






Requirement Type



103 All Technical Architecture The system shall have defined data standards and utilize consistent data schema, data element, data class, field lengths, data tables and view naming conventions.

104 All Technical Architecture The system shall include dedicated web application servers, dedicated database servers, and dedicated reports servers.

105 All Technical Architecture The system architecture shall be consistent and reliable.

106 All Technical Architecture The system architecture shall be based on and consistent with standard architecture, design, and implementation patterns that are fully supported by Microsoft .NET Framework.

107 All Technical Architecture The system architecture shall provide a consistent model for data access and the data model must be abstracted and hidden from the business logic.

108 All Technical Architecture Established naming standards must be followed for all database objects, scripts, and development tool objects.

109 All Technical Architecture Effective database design must be utilized to meet OFR requirements for system performance, security, history, auditability, and real-time comprehensive data access.

110 All Technical Architecture Reporting functionality must utilize a separate near real-time (up to 24 hours) database (e.g. data warehouse) to avoid negatively impacting system response times. This will be used for business intelligence, reporting, and ad-hoc queries.

111 All Technical Architecture The application database shall be easily adaptable to changes in the content and format of licensing data received from OFR’s licensing system.

112 All Technical Architecture The system shall implement check constraints whenever the database column should contain one of a list of pre-defined values.






Requirement Type



113 All Technical Architecture The system shall be architected and designed for at least 1,000 concurrent (i.e. number of users submitting a transaction at the same time) external web users at the time it is implemented, and this number shall be increased as the number of active DPP users increases. (External users include DPP users and OFR users. Number of DPTS Contractor users to be determined by the Contractor.)

114 All Technical Architecture The system shall provide sufficient capacity to accommodate all existing legacy data in the current DPTS as of the system implementation date.

115 All Technical Architecture The system shall have the capacity to perform 1,500,000 monthly transactions at agreed upon performance levels and accommodate an average transaction volume increase of 1% per month.

116 All Technical Architecture The system shall have the capacity to store 4,000,000 unique consumer records with an average monthly increase of 20%, plus a 50% reserve.

117 All Technical Architecture The system shall use SSL (Secured Socket Layer) for all communication that is within a user's session between login and logoff.

118 All Technical Architecture The system shall provide virus protection on all potential sources of input files.

119 All Technical Architecture The system shall apply data validations, to ensure data integrity and minimize data entry errors.

120 All Technical Architecture The system shall provide notification and reporting of errors, problems, unsuccessful processes, etc.

121 All Technical Architecture The model-view-controller pattern shall be flexible for further specializations of this pattern such as page controller and front controller to achieve increased performance.

122 All Technical Architecture The system architecture design shall utilize established naming standards for all database objects, scripts, and development tool objects.

123 All Technical Architecture The system architecture for the Licensee System Interface shall support 500 concurrent users.






Requirement Type



124 All Technical Architecture The system architecture shall support distribution on separate physical tiers of the Web service interface code from the service implementation code.

125 All Technical Architecture The system architecture shall be clearly documented and maintained through the life of the system (e.g., commented source code, class diagrams, process flows, entity relationship models, etc.)

126 All Technical Architecture The system architecture shall be designed to include tools for monitoring performance and reliability.

127 All Technical Architecture The system architecture shall be extensible to current and future trends in technology.

128 All Technical Architecture The system architecture shall enforce structured framework for code deployment and change control.

129 All Technical Architecture The system architecture shall ensure a separate and distinct production environment (PROD) where changes are applied via automated tools.

130 All Technical Architecture The system architecture shall ensure that audit information (e.g., user login, date of transaction, type of transaction) is stored for each transaction.

131 All Technical Architecture The system architecture shall ensure that planned hardware maintenance for DPP is performed without impacting normal operations.

132 All Technical Architecture The system architecture shall ensure the QA environment emulates the production environment (PROD).

133 All Technical Architecture The system architecture shall include a development environment for coding and unit testing.

134 All Technical Architecture The system architecture shall include a quality assurance (QA) environment where data load testing, stress testing and user-acceptance testing is performed.

135 All Technical Architecture The system architecture shall include a system testing environment for integration and system testing.






Requirement Type



136 All Technical Architecture The system architecture shall provide for more user capacity by adding additional hardware/Database servers/network infrastructure and by making configuration changes.

137 All Technical Architecture The system architecture shall support 100 concurrent OFR users ((i.e. number of users performing the same system function at the same time).

138 All Technical Architecture The system architecture shall support the need for reporting and decision support functionality without negatively impacting system response times.

139 All Technical Architecture The system architecture shall utilize consistent user controls across the entire system.

140 All Technical Architecture The system shall allow for additional interfaces to be added or existing interfaces to be removed without negatively impacting the layers.

141 All Technical Architecture The system shall accommodate temporal maintenance of parameters.

142 All Technical Architecture The system shall allow data to be backed up to a remote site periodically.

143 All Technical Architecture The system shall allow for 20% annual growth for five years in all system capacity requirements.

144 All Technical Architecture The system shall be based on a layered-system architecture where each layer of the architecture interacts with other layers through well-defined interfaces.

145 All Technical Architecture The system shall be designed so that business rules are abstracted into common component(s).

146 All Technical Architecture The system shall be designed without hard coding any parameter values that can be expected to change.

147 All Technical Architecture The system shall enforce unique columns by defining unique indexes on those columns.

148 All Technical Architecture The system shall facilitate a mechanism to deploy alternative implementations of a layer without significant disruption to other layers.






Requirement Type



149 All Technical Architecture The system shall implement check constraints whenever the database column should contain one of a list of predefined values.

150 All Technical Architecture The system shall implement database integrity constraints to manage referential integrity.

151 All Technical Architecture The system shall implement primary keys by using sequentially increasing numbers.

152 All Technical Architecture The system shall maintain information necessary to determine whether or not service level expectations are being met.

153 All Technical Architecture The system shall make use of deploy time configuration options available using the deployment platform targeted during design.

154 All Technical Architecture The system shall not use a cascade delete feature for any foreign key relationships.

155 All Technical Architecture The system shall provide an administration module and tools to perform the application system maintenance tasks (e.g. security management, patching, upgrade, tuning, etc.) and data management (e.g. purge, archive, data validity check etc.)

156 All Technical Architecture The system shall provide an architecture that allows for standards based load balancing.

157 All Technical Architecture The system shall provide APIs for .NET/C# or Java.

158 All Technical Architecture The system shall provide functionality designed to prevent duplicate entry of users.

159 All Technical Architecture The system shall provide standards based tools for building executables and code libraries.

160 All Technical Architecture The system shall provide the ability to change parameter values (while maintaining audit trail) through a system administration user interface.

161 All Technical Architecture The system shall provide virus protection on all layers of the architecture.






Requirement Type



162 All Technical Architecture The system shall return a view consisting of multiple records when the search criteria do not match one unique record in database.

163 All Technical Architecture The system shall support modular architecture where functional modules can be added or removed as needed.

164 All Technical Architecture The system shall support the last five previous and the latest versions of the following web browsers: Internet Explorer, Mozilla Firefox, Google Chrome, and Safari. A "version" in this aspect is defined as a major release (e.g. Internet Explorer 6,7,8,9).

165 All Technical Architecture The system shall support the following WINTEL Desktop technology: Preferred - Microsoft Windows 7.x (and later) Acceptable - Microsoft Windows XP (and later)

166 All Technical Architecture The system shall support the model-view-controller pattern.

167 All Technical Architecture The system shall utilize an n-tier thin client architecture using web browser technology.

168 All Technical Auditing All system errors shall be documented in a single centralized document or data store, with information including, but not limited to: Error identifier/message, Session ID, User ID, IP Address, Date/Time and Object(s) where error occurred, resolution provided.

169 All Technical Auditing All code shall contain appropriate error trapping and handling procedures. Appropriate errors shall be logged into a database with the following information: Error identifier/message, Session ID, User ID, IP Address, Date/Time and Object(s) where error occurred.

170 All Technical Auditing Changes to source code within the system architecture shall be documented, maintained, and controlled by using a source code management tool.

171 All Technical Auditing The system shall provide data history to achieve auditability and controls and to aid in problem troubleshooting.






Requirement Type



172 All Technical Auditing The system shall provide capabilities to automatically report security audit information including but not limited to the capabilities to report audit information by user and to report audit information by record.

173 All Technical Auditing The system shall provide the capability to collect security audit information, including but not limited to Security Administrator actions, user logins and logouts, and tracking the access of each user to each object, including but not limited to displays, fields within displays, forms, and reports.

174 All Technical Auditing The system shall provide the capability to generate security audit information reports for each user on randomly selected records as well as the capability to view all the details for any user.

175 All Technical Auditing The system shall provide the capability to retain security audit information for N years, where N's initial value is 10 and is specified in a configurable business rule changeable only by users assigned to the Security Administrator role.

176 All Technical Auditing The system shall capture 'before' and 'after' values of all information as it changes.

177 All Technical Auditing The system shall capture the user ID making the change and the date time of the change.

178 All Technical Auditing The system shall have at least four levels of severity codes used in logging messages.

179 All Technical Auditing The system shall provide standards based logging.

180 All Technical Auditing The system shall provide the OFR user with an ability to access audit trail information.

181 All Technical Availability Heavy application usage during peak times must not affect system response times to the point of negatively impacting productivity of system users.

182 All Technical Availability Query, reporting, and decision-support functionality must not affect system response times to the point of negatively impacting productivity of system users.






Requirement Type



183 All Technical Availability The system shall provide standards based server failover management for application server(s) and database server(s).

184 All Technical Availability The system shall support centralized process scheduling mechanisms.

185 All Technical Availability Equipment availability shall equal to or exceed 99.99%. Equipment availability shall be calculated as follows: UT * 100%/UT + DT where: - UT (Up Time) is defined as the time the equipment is available to and staffed by the customer for productive work (i.e., the time the equipment is processing customer programs or awaiting the processing of such programs, but excluding Preventive Maintenance and Down Time); and - DT (Down Time) is defined as the time the equipment could have been processing customer programs but is being repaired or is awaiting repairs, or is awaiting changes to its control program(s) (excluding any time the Vendor must wait for the equipment to be released by the customer for repair).

186 All Technical Availability The system shall provide warnings to users and operators of impending problems such as running out of storage space, length of time to accomplish substantive tasks, loss of network access, and other such conditions.

187 All Technical Availability The system operations procedures shall include recovery procedures for all the backups taken.

188 All Technical Availability The system operations procedures shall include schedules and procedures of full backup, hot backup and backup retention period strategy. The backups shall include databases as well as other key files to be identified during design.

189 All Technical Availability The system shall be available 24/7/365 except during scheduled downtimes.

190 All Technical Availability The system shall be available and accessible 99.9 percent of the time.

191 All Technical Availability The system shall implement a database that can be used in a fault tolerant configuration.






Requirement Type



192 All Technical Availability The system shall recover database data up to the last committed transaction following a system failure.

193 All Technical Availability The system shall recover database data up to the last committed transaction in the event of a system failure.

194 All Technical Availability The system shall support load balancing to ensure that peak times do not affect expected system response times.

195 All Technical Availability The system shall provide full and incremental data backup and recovery capabilities.

196 All Technical Availability The system shall support, when recovery from the backup is being performed, restoration of data and services on a priority basis, such that priority data are accessible while the recovery is completed.

197 All Technical Availability The system shall ensure that no data (zero data loss) is lost through the service in any event.

198 All Technical Availability The system shall include tools for system backups and restores (e.g., data backup, system configuration backup).

199 All Technical Availability The system shall in the event of loss of service have a Recovery Time Objective (RTO) no greater than 2 hours.

200 All Technical Availability The system shall in the event of loss of service have a Recovery Point Objective (RPO) no greater than 1 hour.

201 All Technical Availability The system shall provide a monthly system statistics report generated using independent, real-time, and online service monitoring tools (e.g. Manage Engine, HP Service Manager) to demonstrate that the Service Level Agreement (e.g. availability requirements, response time requirements) is met. The monthly system statistics report shall be provided for all system components.






Requirement Type



202 All Technical Interface The system shall provide an automated interface with the OFR REAL system to receive and process licensee status updates within the DPTS system. Note: Licensee status from REAL system will need to be translated into a DPTS licensee status equivalent by the DPTS system during the interface process.

203 All Technical Interface The system shall generate an automated confirmation response to the daily REAL licensee status file and send it via email to designated OFR staff if the process is unsuccessful.

204 All Technical Interface The system shall provide a standard interface (web service) to enable DPPs to develop automated interfaces with their existing systems and processes (to avoid duplication of effort and encourage compliance on the part of the DPPs).

205 All Technical Interface The system must provide data validation for all data imported from any source based on configurable business rules for what data validations to perform for each data source.

206 All Technical Interface The system must invalidate records for failure of required field validation in accordance with configurable business rules.

207 All Technical Interface When a data import record fails validation, the system must record which record failed and why it failed.

208 All Technical Interface Upon user request, the system shall provide a report of records that failed data validation on import including, but not limited to, a record identifier and the reason data failed.

209 All Technical Interface The system shall monitor data imports and associated schedules from all external sources and shall notify an appropriate user or system operator when an expected data transmission has not occurred.

210 All Technical Interface The system shall utilize web services (Service Oriented Architecture) for external interfaces.






Requirement Type



211 All Technical Interface Web Services shall be implemented using standard Internet protocols such as Hypertext Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP) to exchange information.

212 All Technical Interface The system shall provide the ability to maintain external system information for interfaces (e.g., connection strings, file paths).

213 All Technical Interface The system shall provide the ability to report on interface transmissions (e.g., total number of records loaded, date of interface transmission, amount of time to execute the interface transmission, errors, and failures).

214 All Technical Interface The system shall provide the ability to restart an interface transmission from a specific point (e.g., restart at failed record, restart from beginning).

215 All Technical Interface The system shall associate information received via interface with the line-of-business record which generated the information request.

216 All Technical Interface The system shall support File Transfer Protocol (FTP), File Transfer Protocol Secure (FTPS), Secure Shell File Transfer Protocol (SSH FTP) for import and export of information.

217 All Technical Organization The system shall have an ability to designate licensee and OFR users as belonging to one of the hierarchy levels.

218 All Technical Organization The system shall implement a flexible hierarchical and geographic organization model representing licensees and OFR users.

219 All Technical Organization The system shall implement capability to set up unlimited number of organizational levels and reporting structures for licensees and OFR users.

220 All Technical Security The system shall not allow co-mingling of data (i.e. between DPPs and with other States)

221 All Technical Security Any information regarding any person's transactional history is confidential pursuant to Section 560.4041, F.S., and shall not be released to the public.

222 All Technical Security The system and DPTS Contractor shall ensure security of the application and data.






Requirement Type



223 All Technical Security The system shall be designed such that data integrity is protected from tampering, forgery, or accidental changes.

224 All Technical Security The system shall include a Privacy and Security Policy as agreed upon by OFR.

225 All Technical Security The system must ensure confidentiality as an element of security that makes information available only to authorized entities. Data should be digitally secure with access restrictions to protect confidential information.

226 All Technical Security The system must provide a security role mechanism to limit access to objects, including but not limited to displays, fields within displays, forms, and reports, to users with sufficient system privileges to see the information or perform the operation.

227 All Technical Security The system shall undergo regular traffic monitoring, internal network monitoring (including activity logs) and external security penetration audits at intervals specified in the Security Plan and agreed to by OFR.

228 All Technical Security The system shall ensure that reports accessed comply with the user's security profile and not display data that would violate that profile.

229 All Technical Security The system shall provide the capability to restrict access by an individual user ID (or identified group of user Ids) and password.

230 All Technical Security The system shall require each User ID to be at least seven characters.

231 All Technical Security The system shall require users to define a password with a minimum length of eight (8) alphanumeric characters. The password should be masked so that it is not viewed when entered. The password shall include 1 alpha, 1 number, 1 lower, 1 upper case letter and 1 special character.

232 All Technical Security The system shall provide the ability to establish a parameter-driven timeframe for which password will expire if not changed.






Requirement Type



233 All Technical Security If a workstation of which a user has logged into the system is left unattended for the established time frame, the system shall automatically terminate the user's session and log the user out of the system. This automated logout shall require the user to re-enter their log-in credentials before continuing.

234 All Technical Security The system menus shall not display application module, function, and screen options for which the user does not have access.

235 All Technical Security The system shall suspend all user access when a user ID is terminated.

236 All Technical Security All DPTS transaction information shall be confidential and shall remain the property of OFR.

237 All Technical Security The system shall utilize data encryption methods appropriate for both financial and confidential information.

238 All Technical Security The system shall ensure the use of sufficient levels of access control to allow "power users" to have more control over the data to make corrections and to "backout" processes, etc., while maintaining data integrity and avoiding the need for manual production "data fixes".

239 All Technical Security The role based security shall be implemented at all levels of the system (e.g. module, function, web page, widget, data field etc.)

240 All Technical Security The system shall enforce the security requirements as per the DFS Enterprise Security Policy.

241 All Technical Security The system shall have ability to authenticate users using LDAP, Active Directory or database lookup.

242 All Technical Security The system shall implement a role based security model for all users and provide an ability to generate reports of user assigned system roles for access review purposes.

243 All Technical Security The system shall not allow direct access to databases from any components that are not in the restricted (Application) zone.






Requirement Type



244 All Technical Security The system shall not store a user password in clear text. If needed an MD5 (or stronger) hash algorithm shall be used unless the password policy expressly states otherwise.

245 All Technical Security The system shall not transmit PII data in clear text as part of the URL or any other communication.

246 All Technical Security The system shall use firewalls to segregate system resources within secure zones.

247 All Technical Security The system shall use SSL (Secured Socket Layer) for all communication that is within a user's session between login and logoff.

248 All Technical Security The user interface shall adhere to SSL (i.e., data in transit for establishing an encrypted link between a server and a client.

249 All Technical Security The system shall enforce the Principle of Least Privilege for security (i.e. .No access by default and permissions as required).

250 All Technical Security The system shall support Secure Shell (SSH).

251 All Technical Security The system shall support IP Protocol Security extension (IPSec).

252 All Technical Security The system shall support at a minimum 256-bit cryptography.

253 All Technical Security The system shall encrypt data transmission information (e.g., URLs, query strings, connection strings).

254 All Technical Security PII data shall be encrypted in all layers of the system.

255 All Technical Security The system shall maintain the integrity and confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.

256 All Technical Security The system shall prevent unauthorized information transfer.

257 All Technical Security The system shall protect the integrity and confidentiality of transmitted information.

258 All Technical Security The system shall protect the integrity and confidentiality of information at rest.






Requirement Type



259 All Technical Security The system shall ensure transactions and messages are accurately received as they were sent and information is not altered.

260 All Technical Security The system shall monitor and control communications at the external boundary of the system and at key internal boundaries within the system.

261 All Technical Security The system shall route all access through a dedicated, managed interface for purposes of access control and auditing.

262 All Technical Security The system shall prevent discovery of specific system components (or devices) composing a managed interface.

263 All Technical Security The system shall implement host-based boundary protection mechanisms for servers and workstations.

264 All Technical Security The system and hosting organization shall comply with NIST Special Publication 800-53 - Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations.

265 All Technical Security The system shall comply with the Florida Accessible Electronic and Information Technology Act.

266 All Technical Security The system shall record unsuccessful logon attempts and retain such information for a defined period of time.

267 All Technical Usability The multiple records view shall allow paging through the list of available records.

268 All Technical Usability The multiple records view shall display enough information in order for a user to make a selection.

269 All Technical Usability The system shall comply with the Americans with Disabilities Act and Section 508 of the Rehabilitation Act of 1973. (See 36 CFR Part 1194 based on Section 508 of the Rehabilitation Act Amendments, 29 USC Sec.794.)

270 All Technical Usability The system shall provide an application response time (not counting network delay) of 2 seconds or less for licensee web portal transactions.

271 All Technical Usability The system shall provide an application response time (not counting network delay) of 2 seconds or less for OFR user key fields based searches.






Requirement Type



272 All Technical Usability The system shall provide an application response time (not counting network delay) of 3 seconds or less for licensee web portal transactions searches.

273 All Technical Usability The system shall provide descriptive error messages using non-technical terms to the users.

274 All Technical Usability The system shall provide online help for each process and each data field.

275 All Technical Usability The online help shall be specific to the user role.

276 All Technical Usability The system shall provide online help that includes step by step instructions for each process and for each user role for each DPP functional area (i.e. licensee-web, licensee - system interface, Licensee - IVR, OFR).

277 All Technical Usability The system shall provide online help that includes access to the OFR policy and procedures manual.

278 All Technical Usability The online help shall be easily navigable across an entire set of information.

279 All Technical Usability The system shall provide context sensitive help as part of the online help.

280 All Technical Usability The system shall provide online help that provides users a search capability which includes easy access to a search.

281 All Technical Usability The search capability of the online help shall include search by keyword.

282 All Technical Usability The search capability shall span all the information in the online help.

283 All Technical Usability The system must provide online help that allows the user to print a single help topic or an entire document.

284 All Technical Usability The system shall provide an ability to post training modules (e.g. videos) and associated procedure documents to the corresponding web portal (i.e. Licensee Web, OFR)

285 All Technical Usability The system user interface shall be consistent across web pages and modules.

286 All Technical Usability The user interface design shall be intuitive, easy to use, and consistent and adhere to current practices in human interaction with software.






Requirement Type



287 All Technical Usability The system user interface shall utilize standard print object from the browser.

288 All Technical Usability The system shall be accessible from a mobile device.





Assumptions

The project team made the following assumptions while creating the RSR.

The future state conceptual system architecture and future state technical system architecture presented in this document are not intended to be a final representation of the architecture. The final architectures will be developed by the selected DPTS implementation contractor during the functional and technical design phases of the project based on the technologies, hardware and software products proposed by the system integration vendor.

The selected DPTS implementation contractor will validate and refine the system requirements.

state of florida - myflorida.com - the official portal of ...€¦ · state of florida office of...

Documents