STATE OF FLORIDA OFFICE OF FINANCIAL REGULATION ATTACHMENT - B. Statement of Work. Deferred Presentment Transaction System

STATE OF FLORIDA OFFICE OF FINANCIAL REGULATION ATTACHMENT - B Statement of Work Deferred Presentment Transaction System

Table of Contents 1 Overview and Project Purpose... 3 1.1 Background and Current State Analysis... 3 1.2 Overview of Current Environment... 4 1.3 Overview of Future Environment... 5 1.4 Objectives... 10 2 Definitions and Acronyms... 11 3 Scope of Work... 15 3.1 In Scope... 15 3.2 Out of Scope... 32 3.3 Requirements... 32 3.4 Standards and Specifications... 33 4 Deliverables and Schedule... 34 4.1 Deliverables... 34 4.2 Deliverables Format... 41 4.3 Project Schedule... 41 4.4 Acceptance Criteria... 42 4.5 Inspection and Acceptance... 42 5 Responsibilities and Staffing... 42 5.1 Contractor Responsibilities... 42 5.2 DIS Responsibilities... 42 5.3 OFR Responsibilities... 42 5.4 Location of Work... 43 5.5 Project Roles... 43 Page 2 of 44

1 Overview and Project Purpose The Florida Office of Financial Regulation (OFR or Office) within the Department of Financial Services (DFS or the Department) is issuing this Invitation to Negotiate (ITN) to obtain the services described in this Statement of Work (SOW) which outlines the tasks required for the Contractor to provide information technology (IT) services. This SOW defines the scope and requirements to procure implementation services for a new real time, on-line Deferred Presentment Transactions System (DPTS). This SOW will enable the Office to comply with legislation which requires the development and maintenance of a Deferred Presentment Transaction System. This Scope of Work is to be read in conjunction with the proposed Contract (see Attachment A) and the Invitation to Negotiate, and not to the exclusion of any terms articulated in the proposed Contract, Invitation to Negotiate, and not within this Scope of Work. 1.1 Background and Current State Analysis The Florida Office of Financial Regulation 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. Page 3 of 44

1.2 Overview of Current Environment In December of 2001, OFR contracted with a Third Party Administrator (TPA) to develop, implement, and manage the day-to-day business operations of the FLADPP. In February of 2002 the FLADPP went live, with the TPA overseeing the day-to-day operations of the system as well as accounting and call center operations. The TPA hosts and maintains the system, provides training and technical assistance to the industry participants, invoices and collects from more than 150 registered DPP s operating from more than 1,350 store locations on a weekly basis, and provides call center support to DPPs and customers. 1.2.1 Current Systems and Applications FLADPP is currently operational 24 hours per day, 7 days per week, 365 days a year with the exception of scheduled down-time for system maintenance. The system interfaces with OFR licensing systems via a nightly update of licensing records to ensure that only DPPs licensed to do business in Florida are allowed access to the system. Specific characteristics of the FLADPP in its current state include: Approximately 7,000 active DPP system users operate from approximately 1,350 active DPP locations statewide. Approximately 2.9 million customers. Approximately 7.5 million transactions were registered between Fiscal Year 2013 14. Secure web-based access (HTTPS). DPP Customer Call Center operations are available 6 days per week from 9am-6pm (Monday through Friday) and 10am to 3pm on Saturdays. Approximately 42,000 calls are handled annually. 24/7 Telephone support (Help Desk) for DPP employees who use the system. 24/7 Database availability monitoring. System Availability exceeding 99%, including scheduled maintenance. Off-site Disaster Recovery. Redundant Operations Centers (Jacksonville, FL and Tempe, AZ). Redundant, off-site data centers. Redundant Interactive Voice Response (IVR) systems. Dedicated application servers (web, database and reporting). Page 4 of 44

1.3 Overview of Future Environment 1.3.1 Service Delivery Model The Office s service delivery model as applicable to the DPTS is as follows: Figure 1 Service Delivery Model 1.3.2 DPTS Functionality The following diagram (see Figure 2 DPTS Functionality) depicts the functionality of the DPTS system for the Licensees and the OFR. Page 5 of 44

DPTS - OFR System Interface Transaction History OFR Data Analytics & Alerts Compliance Reporting Customer Transactions DPP Transactions OFR Regulatory Enforcement and Licensing System (REAL) Dashboards Search Interface Configuration Access Management Reports Licensee Transaction Management New Amend Close Cancel DPTS - Licensee Access Management Manage Administrator Accounts Manage Supervisor Accounts Manage User Accounts Information Services Search System Interfaces Social Security Number (SSN) Validation DPTS Web Service Interface Configuration Reports 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). Page 6 of 44

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. 1.3.3 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. Page 7 of 44

DPP TRANSMISSION VENDOR OFR OTHER ENTITIES WEB DPTS REAL SSN Deferred Presentment Providers (DPPs, Licensees) IVR System Interface OFR Users Figure 3 DPTS High Level Architecture 1.3.4 DPTS Conceptual Architecture The DPTS Conceptual Architecture diagram (see Figure 4 DPTS Conceptual Architecture) depicts a potential conceptual architecture for the DPTS system. Page 8 of 44

Figure 4 DPTS Conceptual Architecture Page 9 of 44

1.3.5 DPTS Technical Architecture The DPTS Technical Architecture diagram (see Figure 5 DPTS Technical Architecture) depicts a potential technical architecture concept for the DPTS system. Web Services DEVICES CLIENT TIER Authentication Licensee Sys Interface Browser Telephone Browser PRESENTATION TIER Presentation Logic Processing Session State Management BUSINESS TIER Business Logic Data Access Objects Interface Logic Data Exchange Web Services Analytics / Alerts DATA TIER DPTS Production Database DPTS Reporting Database EXTERNAL SYSTEMS SSN REAL OFR Figure 5 DPTS Technical Architecture 1.4 Objectives The objectives for this project are 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. Phase II - Implementation is the focus of this SOW. Phase I is being completed. Page 10 of 44

2 Definitions and Acronyms The following terms used in this document are defined herein. Term Project Management Terms Acceptance criteria Change Contract Contract Manager Contractor Deliverable DIS or Division or Division of Information Systems Milestone Objectives Office or OFR Project Management Office Definition Pre-defined performance requirements and essential conditions that project deliverables are measured against before they are considered complete and acceptable. The criteria must be relevant, measurable and specific. A change in the scope of the project. See also: Scope. The contract that will be awarded to the successful proposer under this competitive solicitation. Person designated as the main Office point of contact for all issues related to the Services performed under this SOW. This person is the single point of contact for the Contractor and is the only person authorized to make or approve any changes in the requirements of the SOW. Vendor that is selected for the project. A product or service that satisfies one or more objectives of the project. Deliverables must be tangible, measurable and verifiable outcomes of work that meet pre-determined standards for acceptance that must be accepted in writing before payment. Examples of deliverables include project documentation, systems, system prototypes, facilities, training and customer support. A division within the Department of Financial Services that provides technological support for operations. A key event during the project management process selected for its importance in the judging of a project. Examples are the completion of a phase, completion of a major deliverable, or completion of an activity (such as a group of tasks or processes). Define the end results to be achieved by the project. Describe them in terms that are observable, measurable, that indicate a timeline for attaining them, and the acceptable level of performance for each goal. Refers to the Office of Financial Regulation. A unit within the Division of Information Systems that provides support for agency technology projects; Also known as PMO. Page 11 of 44

Term Requirements Scope Standards State Data (aka DFS Data) Specifications Task Vendor Business Terms Business Day(s) Calendar Day(s) Definition Conditions or capabilities to which a system or service must conform. Requirements can be derived from documented user needs or from a contract, standards, or specifications. Describes at a high level what will and will not be included as part of the project. Scope defines the project s overall boundaries and provides a common understanding of the project for the stakeholders and the project team. It is further defined by the requirements, deliverables, schedule and supporting information contained in this SOW. Documents that stipulate minimum levels of performance and quality for goods and services, and optimal conditions and procedures for operation. Any data or information of or concerning the State or the Department that is provided to or obtained by the Contractor or Contractor personnel in connection with the negotiation and execution of the Contract or the performance of the Contractor s obligations under the Contract, including any such data and information that either (is) is created, generated, collected or processed by Contractor Personnel in the performance of the Contractor s obligations under the Contract, including data processing input and output, performance measurements, asset information, reports, third party service and product Contracts, and the Contractor s charges to the Department, or (ii) resides in or is accessed through the Department s operating environment or the Contractor s Service delivery infrastructure; as well as any data and information derived from the foregoing. Concise statements of requirements for materials, products or services that are to be used by industry or a government agency. A cohesive, individual unit of work that is part of the total work needed to accomplish a project. The entity that submits materials to the Office in accordance with the solicitation instructions, or other entity responding to the solicitation associated with this SOW. This may also be referred to as Respondent, Bidder, and Proposer. The solicitation response may be referred to as Reply, Bid or Response. Monday through Friday, inclusive, excluding State-observed holidays. Monday through Sunday, except that if the last day counted falls on a weekend or State-observed holiday, the due date shall be the next Business Day thereafter. Page 12 of 44

Term Cashing Deferment Period Deferred Presentment Provider (DPP) Deferred Presentment Transaction (DPT) Deferred Presentment Transaction System (DPTS) DFS Definition Providing currency for payment instruments except for traveler s checks. See F.S. 560.103 (5). This refers to the number of days a deferred presentment provider agrees to defer depositing, presenting, or redeeming a payment instrument. 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. 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. 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. The State of Florida Department of Financial Services. DPP Teller DPTS DPTS Contractor Drawer Extension of a Deferred Presentment Transaction Fiscal Year F.S. This refers to an authorized person responsible for conducting deferred presentment transactions on behalf of a licensee. Also referred to as DPP User. The Deferred Presentment Transactions System which the Office is procuring. 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. 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. 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. The State of Florida Fiscal Year period beginning July 1 and ending June 30. This refers to the 2014 Florida Statutes. Page 13 of 44

Term Licensee Location Mobile Location Office Definition This is a person licensed under Chapter 560. Also referred to as deferred presentment provider, DPP, and Provider. This refers to a branch office, or mobile location whose business activity is regulated under Chapter 560. This refers to the VIN number of the automobile from which a licensee operates a mobile location. This refers to the Office of Financial Regulation. Payment Instrument Performance Measures Person Personal Identification Information (PII) Physical Location Rollover A check, draft, warrant, money order, travelers check, electronic instrument, or other instrument, payment of money, or monetary value whether or not negotiable. The term does not include an instrument that is redeemable by the issuer in merchandise or service, a credit card voucher, or a letter of credit. See F.S. 560.103 (25). The required minimum acceptable level of service to be performed by the Contractor and the criteria the Office will use to evaluate the successful completion of each deliverable and/or service. 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. 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. This refers to the physical address of the DPP s primary business location or branch office. 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. Page 14 of 44

Term SLA Termination Uptime Technical Terms POS system RPO RTO Definition A Service-level Agreement and is part of a service contract where a service is formally defined. 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. This refers to the time during which the DPTS is in operation. 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. 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. This is the Recovery Time Objective and is the target time set for resumption of product, service or activity delivery after an incident. 3 Scope of Work 3.1 In Scope The scope of work for this project may generally be described as providing a technical solution and supporting services that will enable the Office to meet the stated program objectives. This Statement of Work ( SOW ) describes the functionality and features to be provided by the DPTS. It also describes the services to be provided by the Contractor to support the DPTS throughout the project lifecycle including implementation services, project management services, and operation and support requirements. The requirements stated herein are intended to inform proposers of the minimum expectations of the Office, but proposers may clarify and expand on the requirements. In addition, the Project Schedule submitted by the proposer will present the proposed project timeline for approval. The resulting contract will reflect the contractual terms and conditions agreed upon between the Office and the Contractor, including the project timeline and scope of services. The Office of Financial Regulation has planned a phased implementation approach for the Deferred Presentment Transactions System solution per the Project s System Development Life Cycle (SDLC). Page 15 of 44

The table below summarizes each phase of the SDLC. Phase Phase One: Initiate and Plan Phase Two: Define Phase Three: Design Phase Four: Develop Phase Five: System Test Phase Six: Implement and Train Phase Seven: Maintain Summary The objective of this phase is for the Contractor and the Office to create the overarching planning documentation for the Project. The Contractor shall submit the core planning deliverables. The objective of this phase is for the Contractor to validate and elaborate the requirements provided in the Requirements Specification Report (RSR) with key project stakeholders in order to generate specific, detailed functional and technical requirements. The objective of this phase is to create a visual representation of the system to be built. This phase transforms the detailed, defined requirements into complete, detailed functional specifications. Technical specifications are also created to illustrate the necessary infrastructure to support the system architecture. The objective of this phase is to convert the deliverables of the Design phase into a complete information system as specified in the Requirements Traceability Matrix. The objective of this phase is to prove that the new system satisfies the detailed requirements as specified in the Define phase. The objective of this phase is to deploy the system to all users and to ensure that they are trained on all functional and technical areas of the DPTS solution. The objective of this phase is to ensure that the system continues to work as specified and to maintain the system. The scope is further defined within the remainder of this section as well as Section 4 Deliverables and Schedule and Section 5 Responsibilities and Staffing. Page 16 of 44

3.1.1 Project Phases: System Development Life Cycle The Contractor s System Development Life Cycle shall conform to the high-level project schedule and the specific SDLC phases as outlined below. Associated Phase Gate deliverables for each SDLC phase are also outlined and must be satisfied prior to entering the subsequent phase gate. 3.1.1.1 Phase One: Initiate and Plan The objective of this phase is for the Contractor and the Office to create the overarching documentation for the Project. The Contractor shall submit the core planning deliverables as defined in Section 4 Deliverables and Schedule. The Contractor shall develop a Project Management Plan as part of the methodology and approach to the Project. The Contractor shall follow project management methodologies consistent with the Project Management Institute (PMI) project management methodologies stated in the Project Management Body of Knowledge (PMBOK). In this task the Contractor shall detail the SDLC approach and methodology for initiating, planning, defining, designing, developing, testing, training, implementing and maintaining the DPTS solution. The Office and the Contractor shall work together during Project Initiation and Planning Phase to develop and refine the Project Management Plan (PMP) based on the project approach and schedule. The Project Management Plan shall include the following sections: 1. Project Roles and Responsibilities 2. Project Schedule - a separate schedule prepared using Microsoft Project 3. Communication Management 4. Document Management 5. Schedule Management 6. Quality Management 7. Issue Management 8. Scope Management 9. Risk Management 10. Resource Management and Staffing 11. Configuration Management 12. Knowledge Management 13. Phase Gate Review and Acceptance Process 14. Phase Gate Approval Criteria 15. Project Change Control Management 16. Information Security 17. Conflict Resolution All sections, identified above, shall be delivered during the Planning Phase in an initial overall Project Management Plan as a baseline document. The PMP will be clarified, revised, expanded, and maintained throughout the project and submitted to the Office for review during phase gate reviews and other contractually specified review points. The Contractor shall provide status reports on a weekly basis listing all approved project estimates along with the current status and estimated completion dates of such project. Project status reports should at a minimum contain: overall project completion status (%), percentage complete of each milestone activity, key activities completed in Page 17 of 44

the previous period, key activities to be completed in the upcoming period, deliverable submission status, risk log, issue log, and updated detailed project schedule. The Contractor shall utilize the Project Management procedures and templates to manage any changes to the scope of the project. Changes that impact cost shall be made only by contract amendment and approved by both parties. Other significant changes may require a contract amendment i.e., schedule, deliverables, milestones, etc. If the Contractor fails to so notify and obtain approval from OFR before commencing performance of activities relating to changes in the scope of the project, such activities shall be considered to be performed gratuitously by the Contractor, and the Contractor shall not have any right thereafter to assert any claim for additional compensation or time for the performance of such activities. The Contractor shall utilize the PMO project management procedures and templates, or the equivalent, to manage quality. Proposer will be expected to submit a Quality Management Plan and perform quality assurance reviews of Deliverables prior to submission, in accordance with that plan. The Project Schedule is a key component that will be leveraged throughout the project. The following shall be included in the Project Schedule: A Microsoft Project 2007(or newer) schedule that details tasks and activities that shall be performed during the engagement to at least Work Breakdown Structure (WBS) level 4. The project schedule shall be maintained on at least a weekly basis. The project schedule shall reflect non-working time of project team members (i.e., weekends, holidays). At a minimum, the schedule shall include firm task durations (estimated durations should be limited), task start and finish dates, baseline start and finish dates, task predecessors and successors, and resources. Note that the agreed upon project schedule between the Office and the Contractor during contract negotiations shall not be changed except upon written approval by the Office. The Contractor shall conduct a Project Initiation meeting at a location selected by the Office and at a date and time mutually agreed upon by the Office and the Contractor. The Project Initiation meeting shall be attended by the Office Project Team and the Contractor Project Team. The purpose of the meeting shall be to review the PMP (and Project Schedule) and the format of the deliverables associated with the Project SDLC. The Contractor shall conduct one or more additional Project Initiation meetings as deemed necessary by the Office. Note that the PMP and Project Schedule should be provided at least three (3) business days in advance of this meeting. The Project Initiation meeting activities shall include: Understanding of the project objectives and scope. Identification of the roles and responsibilities of the project stakeholders, including the Office Project Team, Contractor Project Team, DIS staff (e.g., Change Management, Environment Support Teams, Help Desk, Maintenance Support Manager, Technical Support staff), and any other key project team members. Review the PMP. Review of the project schedule, phases and associated deliverables. Page 18 of 44

Understanding of the project performance measurements and critical success factors. Identification of key stakeholders that will serve as the point of contact to review and validate information at all agreed upon project phases. Overview of the process to manage all phases of the project, including the elements of the PMP, such as communications management, risk management, issue management, etc. Any other topic as deemed appropriate by the Office. Any decisions or agreements from the Project Initiation meeting(s) shall be documented by the Contractor and submitted to the Office project team for review and acceptance. In addition, the Contractor shall document meeting minutes to include all key decisions and action items from all meetings conducted with the Office and any other external parties during the project duration. The Contractor s responsibilities during the Initiate and Plan phase shall include: 1) Facilitating the Project Initiation meeting. 2) Designating staff members to serve as part of the planning process. 3) Working with Office staff to establish the necessary technical environments. 4) Preparing the planning deliverables. 5) Revising deliverables as a result of the review and approval process. 6) Conducting weekly Status Meetings (to be held throughout the project duration). 7) Creating and updating the Project Schedule and weekly status report. 8) Establishing bi-weekly Steering Committee meetings (to be held throughout the project duration). The OFR s responsibilities during the Initiate and Plan phase shall include: 1) Participating in project planning activities and identify responsibilities of Office staff. 2) Participating in plan development by providing technical information and guidance. 3) Reviewing and approving all planning deliverables. 4) Supplying hardware, software, and infrastructure for which the Office is responsible. 5) Coordinate participation of DFS-DIS and other stakeholders in planned activities, as needed. The DFS-DIS responsibilities during the Initiate and Plan phase shall include: 1) Participating in project planning activities and identify responsibilities of Office staff. 2) Provide Security Awareness Training for the Contractor s personnel who will be assigned to this project. Initiate and Plan Phase Gate. The following deliverables are tied to this Phase Gate: Project Management Plan Project Initiation and Status Meeting(s) Weekly Project Status Report Project Steering Committee Meeting(s) Page 19 of 44

3.1.1.2 Phase Two: Define The objective of this phase is for the Contractor to validate and elaborate the requirements provided in the Requirements Response Matrix (RRM) - Attachment D - Requirements Response Matrix with key project stakeholders in order to generate specific, detailed functional and technical requirements. The Contractor shall validate and refine the requirements identified in this SOW and in the RRM to generate specific, low level requirements (i.e., Functional, Technical, and Regulatory) to produce a Requirements Traceability Matrix (RTM). The Contractor shall propose a methodology that generates lower level requirements through working sessions with the Office. The working sessions shall be Joint Application Development (JAD) or other Office approved requirements generation methodology proposed by the Contractor. The Contractor shall propose a methodology that enables the participation of key external stakeholders as identified by the Office. The Office expects that a minimum of three (3) JAD sessions shall be held that include a discussion of each requirement in the RRM and a confirmation of the Contractor s ability to meet each requirement. The Contractor s requirements validation responsibilities shall include: 1) Providing a defined methodology to validate and maintain requirements including process that will be utilized in conducting requirements validation sessions. 2) Providing a proposed schedule of requirements sessions that will be conducted and the expected knowledge base of the Office and other stakeholder participants. 3) Ensuring that the Contractor s functional and technical experts are on-site during the requirements validation sessions to address and answer any questions. 4) Providing an agenda for each requirements validation sessions. 5) Conducting and documenting requirements validation sessions. The outcome of each requirements validation session should be submitted no later than two (2) business days following completion of the session. 6) Preparing the requirements validation deliverable as stated in Section 4 Deliverables and Schedule. The Contractor shall propose a Deployment Strategy for delivering the DPTS solution. The Deployment Strategy shall also include the interface definitions to external systems (i.e., REAL solution, SSN validation database, and DPP Point of Sale devices). The Contractor s interface definition responsibilities shall include: 1) Providing documentation on interfaces specifying purpose, format, content, frequency and processing for each interface transaction. 2) Providing meeting minutes of each interface session, including issues addressed and decisions made, to the Office s Project Manager within three (3) business days upon conclusion of the interface meeting. 3) Providing the deliverables as identified in Section 4 Deliverables and Schedule. 4) Revising deliverables as a result of the review and approval process. The OFR s responsibilities during the Define phase shall include: Page 20 of 44

1) Participating in planned activities (i.e., JAD sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. 4) Coordinating the participation of key external stakeholders, as needed. 5) Coordinating participation of DFS-DIS in planned activities, as needed. Define Phase Gate. The following deliverables are tied to this Phase Gate: Requirements Traceability Matrix JAD Sessions and Associated Documentation 3.1.1.3 Phase Three: Design The objective of the Design phase is to create a visual representation of the system to be built. This phase transforms the detailed, defined requirements into complete, detailed functional specifications that document each form, screen, and report in the system. Technical specifications are also created to illustrate the necessary infrastructure to support the system architecture. The Contractor shall generate a conceptual system design (i.e., Functional Design Document) describing how the DPTS solution will enable the functional requirements specified in the RTM. The Functional Design Document (FDD) shall include, but not be limited to, data models and process models and must include both graphic and narrative representation for each form, report, interface and enhancement. All business rules and workflows shall be documented in detail. The Contractor shall specify User Interface standards and provide a prototype illustrating the functionality of the DPTS solution. Components of the FDD include: 1. User Interface Standards - Defines usability standards for the DPTS user interface. Browser based standards should be browser agnostic and the DPTS user interface should run on current browser releases. 2. Application Development Standards: The purpose of this document is to define standards and best practices for developing web-based application software in order to present a consistent look and feel to the applications. 3. Prototype - Illustrates the navigation of the forms and demonstrates the UI standards that are incorporated into the solution. 4. Reporting templates - Layouts and definitions of pre-defined reports. The Contractor may propose alternatives to any of the components noted above, but any alternative must be clearly justified and have the prior approval of the Office. The Contractor shall develop a Data Conversion and Migration Plan that describes the data conversion and migration environment, sources, rules, conversion and migration process, controls, backup and rollback processes, and validation procedures. The Contractor shall map all existing databases to the new database design model before construction or customizations begin. The Contractor shall perform a thorough data analysis of the values contained in all current database Page 21 of 44

tables and fields in order to ensure complete and correct mapping has been done, since some data fields may have been used differently at different points in time. The Contractor s responsibilities during the Design phase include: 1) Supporting the Office with developing the User Interface standards. 2) Creating and refining the database design. 3) Conducting a walk-through of the deliverables. 4) Revising deliverables as a result of the review and approval process. The OFR s responsibilities during the Design phase shall include: 1) Participating in planned activities (e.g., Design sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. 4) Coordinating participation of DFS-DIS in planned activities, as necessary. Design Phase Gate. The following deliverables are tied to this Phase Gate: Functional Design Document Updated Requirements Traceability Matrix Data Conversion and Migration Plan 3.1.1.4 Phase Four: Develop The objective of this phase is to convert the deliverables of the Design phase into a complete information system as specified. The Contractor s installation and configuration efforts will be guided by the outputs of the Initiate and Plan, Define, and Design phases. The Contractor shall follow industry standard software and business application development methodologies and practices for environment setup, coding, unit testing, and code promotion to other environments. 3.1.1.5 Phase Five: System Test The objective of this phase is to prove that the new system satisfies the detailed requirements as specified in the Define phase. The Contractor shall test the proposed DPTS in accordance with established software development practices to include: System Integration Testing to evaluate the assembled system and confirm that the DPTS operates as expected including all system security and user profiles and ensuring that functional and interface objectives are met; Performance Testing/Stress Testing to simulate the system to the limits of its requirements and beyond those limits to confirm graceful failure including COTS packages Page 22 of 44

and to confirm satisfaction of performance requirements in a simulated test environment; and User Acceptance Testing to evaluate the overall functionality of the DPTS system components against the Requirements Specification Report and the Requirements Traceability Matrix. The Contractor shall conduct all system integration testing and support the user acceptance testing planned, and executed, by the Office with actual data provided by the Office. The Contractor shall generate all required test documentation (e.g., System Integration Test Results and User Acceptance Test Plans and Cases). During test planning, the Contractor shall update the Requirements Traceability Matrix to reflect the relationship between requirements and planned acceptance tests. The Contractor will submit the final Test Plan twenty (20) days prior to any testing. The detailed Test Plan will become the basis for verifying that the system meets all requirements, and operates as documented and intended. The Test Plan must be in sufficient detail to serve as a basis for acceptance or rejection of specific system components based on the results of testing. The Contractor shall record, track, and manage all problems and issues identified during testing workstreams (i.e., System, End-to-End, Interface, Performance/Stress, User Acceptance, and Regression). The Contractor shall troubleshoot all test result anomalies to determine the source of the problem. If necessary, the Contractor shall update test plan, test cases, and test scripts, and shall modify and re-test the DPTS solution. Following any software change or test script change made during the acceptance testing period, the Contractor shall perform a regression analysis of tests already executed to determine which test results may have been affected by the change and need to be re-executed. The Contractor shall lead the Office in executing User Acceptance Testing (UAT) to demonstrate that all requirements are met, and shall provide the Office documentation to report the outcomes of the User Acceptance Testing. The Contractor and Office will collaborate to ensure that the UAT process supports the Office s ability to identify additional tests cases during the UAT workstream to ensure that the acceptance test cases are thorough and complete. The Contractor shall work with the Office to develop test cases, test scripts, test data and test files for all test cases including any added by the Office. The Contractor shall confirm that User Acceptance Tests have been planned for all requirements by tracing the requirements to the planned acceptance test cases and scripts. The Contractor will submit test cases / scripts to the Office ten (10) days prior to actual testing. The Contractor s responsibilities during the System Test phase shall include: 1) Implementing a defect tracking and reporting method. 2) Documenting, analyzing and classifying all reported problems. 3) Updating the Requirements Traceability Matrix to reflect the relationship between requirements and planned tests. 4) Working with Office staff to establish the test environments. Page 23 of 44

5) Configuring the DPTS to the most current production version of all underlying software, tools, and databases, unless the Office agrees to an exception. 6) Creating test data and test files needed for initial testing as well as for re-testing, if applicable. 7) Supporting system integration tests. Each module must be tested when it is completed. The compatibility of all modules for the entire system must be tested when all modules have been completed. 8) Correcting problems, repeating system integration testing until expected results are obtained. 9) Providing documentation for all test results for each set of tests performed. 10) Supporting the development of all User Acceptance Test deliverables. 11) Establishing the application in the Acceptance Test environment. 12) Supplying training needed for testing. 13) Developing acceptance test plan, test scenarios, test cases and generating test result logs. 14) Conducting Performance/Stress Testing as a part of overall testing in an environment that simulates the production environment. The OFR s responsibilities during the System Test phase shall include: 1) Participating in planned activities (e.g., Review Test Cases, Execute Scripts, Provide Feedback, etc.) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. System Test Phase Gate. The following deliverables are tied to this Phase Gate: Test Plan (user acceptance testing) Test Cases (user acceptance testing) Test Results (system integration testing, user acceptance testing) Updated Requirements Traceability Matrix (after system integration and user acceptance testing) 3.1.1.6 Phase Six: Implement and Train The main objective of this phase is to deploy the system to all users. Activities in this phase will include training of all end users on the system as appropriate (e.g. functional or end user, technical, system administration, help desk). The objective is also to ensure that all appropriate user documentation is prepared to guide users on how to navigate the installed DPTS solution. 3.1.1.6.1 Implement The Contractor shall initialize the entire system including setup of initial internal user accounts and privileges. The Contractor shall develop and submit an Implementation Plan sixty (60) days prior to the golive date that, at a minimum, addresses identification of the steps leading up to the rollout, system availability to users, pilot deployment, a strategy to rollback in case of major issues encountered during the rollout, and a Final Acceptance Report for each planned release in the approved project schedule. If the plan includes equipment or services provided by a subcontractor, the Contractor shall Page 24 of 44

be fully responsible (as prime contractor) for the delivery of the entire system. If the Contractor recommends a phased approach, the Implementation Plan must also describe how functionality included in phases subsequent to the first phase will be implemented. The Implementation Plan will include a Checklist of tasks for the Go-Live. The Checklist will be reviewed and updated at periodic intervals (at a minimum weekly) leading up to the deployment. The Contractor shall develop Data Conversion and Migration Scripts which are the exact programs and automated scripts necessary to execute the approved Data Conversion and Migration Plan. The scripts will guide the Extract-Transform-Load processes required to seed the DPTS database with the data from all legacy systems and data stores addressed in the Data Conversion and Migration Plan. The Contractor shall develop/update the Disaster Recovery Manual which shall outline the procedures to successfully recover the DPTS. The Contractor s staff shall be present at the implementation site during the go-live of the system. The Contractor s responsibilities during the Implement phase shall include: 1) Supporting the Office with developing the Operational Readiness Plan. 2) Deploying the proposed DPTS solution (i.e. hardware and software installations). 3) Providing on-site support during the implementation. 4) Performing roll-back procedures, if required. 5) Developing/updating the Disaster Recovery Manual. 6) Performing a post-implementation Recovery test (to be included in the project schedule) to recovery all components of the production application. 7) Performing a successful Recovery Test and preparing an updated Disaster Recovery Manual, which are required for final acceptance of the system. For applications hosted by the Contractor, the recovery test will be performed by Contractor and monitored by DFS/Office personnel. The Office s responsibilities during the Implement phase shall include: 1) Review and approve the installation and implementation deliverables. 2) Assist the Contractor in planning, coordination and execution of hardware and software installations. 3) Coordinate participation of DFS-DIS in planned activities, as needed. The DFS-DIS responsibilities during the Implement phase shall include: 1) Participating in planned activities as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule. 4) DIS personnel in DFS will determine if the Disaster Recovery test is successful or needs to be corrected and repeated prior to final acceptance. Page 25 of 44

3.1.1.6.2 Train The Contractor shall present a method to train the user population defined below that balances effectiveness with expense. The Contractor shall provide a Customized Training Plan that will ensure that all the DPTS end users have access to the knowledge and skills necessary to effectively employ the DPTS solution and supporting technology. The Contractor shall provide the Office with Customized Training Material for the operation and support of the DPTS solution. The Contractor s training material shall be in electronic form, i.e. in the form of an online user help, and the Contractor shall continually update the training material where changes to the solution s method of operation have occurred. The training material shall be provided in a format that allows the Office to conduct train-the-trainer sessions after the Contractor s training responsibilities have expired, which shall include training modules (e.g. videos) and associated procedure documents for all end users of the DPTS solution. The training material shall be used to train each category of DPTS user. In collaboration with the Office, the Contractor shall train, or provide a mechanism to train, all the DPTS users including, but not limited to OFR internal users, DPPs, etc. The Contractor shall provide at a minimum five (5) training sessions with OFR internal users using the train-the-trainer methodology. The training shall be conducted at the OFR offices in Tallahassee. The Contractor shall provide at a minimum five (5) training sessions with DPPs utilizing webinars and computer-based training (CBT). All training materials shall be provided in an electronic and editable format. OFR has the right to use and/or modify the training materials as needed. The Contractor s responsibilities during the Train phase shall include: 1) Providing a detailed Training Plan that is submitted to the Office for review and approval. 2) Developing a Training Schedule provided to the Office by the Contractor. The trainers provided by the Contractor must track attendance and class completion and provide status information to the Office. If any classes must be rescheduled, the Contractor shall attempt to reschedule staff as agreed upon with the Office, and provide reports to the Office. 3) Provides for knowledge transfer to DIS staff to maintain the system. 4) Provide for knowledge transfer to DIS Tier 1 staff. 5) Developing training with a plan for continuing education and software application updates, including a train-the-trainer activity for on-boarding new hires. 6) Conducting training in Tallahassee for all DPTS internal end users (about 75 users). 7) Conducting training across the industry to include all DPTS end users (about 7,000 users). 8) Providing both structured and on-the-job training for system administrators, system operators, support resources so they are prepared to transition into these roles when necessary. 9) The Contractor shall provide training to Customer Call Center/Help Desk staff to ensure they are well versed in the rules governing DPTs and the Privacy and Security Policy of the system. 10) Ensuring training is aimed at skill acquisition and helping end users become self-sufficient in the use of the DPTS solution. Training shall be designed, prepared and presented to address issues and topics relating to OFR s use of the database, including but not limited to; queries, report generation and distribution. The Contractor will provide a general overview of the proposed system, its functions, capabilities, limitations, components, physical layout and Page 26 of 44