Appendix 01.pdf

Execution Requirements

Appendix #:

Subject:

Functional Requirements: Execution Requirements

Appendix 01 - Execution Requirements Page 1 of 30

1 Introduction to Execution Requirements

2 Software Development Life Cycle (SDLC) Startup Activities

3 Initial Use Case Analysis and Gap Analysis

4 Release Planning

5 Iterative Requirements Analysis and Design Activities

6 Iterative Development Activities

7 Testing Requirements

8 Data Conversion and Migration

9 Implementation Activities

10 Contractor Logistics

11 Documentation Requirements

See Appendix 15 for a complete list of all abbreviations and acronyms.

Appendix 01 - Execution Requirements Page 2 of 30

1 Introduction to Execution Requirements This document describes SCDMV’s execution requirements for the System.

As part of managing and delivering this project, the Contractor shall address the following items.

1. SDLC Startup Activities

2. Initial Use Case Analysis and Gap Analysis

3. Release Planning

4. Iterative Requirements Analysis and Design Activities

5. Iterative Development Activities

6. Testing Requirements

7. Data Conversion and Migration

8. Implementation Activities

9. Contractor Logistics

Appendix 01 - Execution Requirements Page 3 of 30

2 SDLC Startup Activities The following tasks shall be completed at the beginning of the project, defined in the project schedule, and approved by the SCDMV.

2.1 Contractor’s SDLC Methodology

2.1.1 SDLC Requirement

The Contractor shall propose and execute a SDLC to structure and guide all system development activities. The SDLC shall meet the following requirements:

1. It shall be proven, defined, documented, repeatable, and auditable.

2. It must have been successfully used on a project of similar size, scope, and complexity.

3. It shall be consistent with industry standard methodologies, including ISO/IEC/IEEE 12207.

4. It should adhere to secure software practices such those described in NIST Special Publication 800-218.

2.1.2 Contractor’s SDLC Documentation

The Contractor’s SDLC documentation shall provide the following:

1. Description of the Contractor’s overall SDLC methodology including phases, activities, deliverables, and tools.

2. Deliverable descriptions and content outlines.

3. Proposed Deliverable Acceptance Criteria.

4. Linkage of deliverables (i.e., which deliverables serve as inputs and outputs to other deliverables).

5. Phase exit and entrance criteria.

6. A schedule for when deliverables are expected to be submitted when executing the

SDLC.

7. Description of the SCDMV’s role.

8. Assumptions and constraints.

2.1.3 SDLC Training

After award, the Contractor shall work with the SCDMV to ensure that the Contractor and SCDMV staff are aware of and understand how to execute project activities according to the SDLC methodology and other applied standards.

2.2 System Implementation Plan/High Level Roadmap

The Contractor shall implement the solution in accordance with the approach proposed in response to Attachment A - Response Requirement, Num. 5. SCDMV approval of the approach is required. If SCDMV does not approve the approach, the Contractor shall

Appendix 01 - Execution Requirements Page 4 of 30 draft and submit a new approach at the direction of SCDMV for SCDMV’s consideration.

Once an approach has been approved by SCDMV, the Contractor must implement accordingly. This approach shall include a roadmap that describes the overall process for the phases and iterations of the project. It shall describe SDLC processes, inputs and outputs, artifacts, participant roles, and other information to outline the overall development approach.

SCDMV’s initial assessment suggests of the order of functionality implementation should be as follows:

1. All functionality to support Driver Services, Driver Enforcement, and Financial Operations.

2. All functionality to support Vehicle Services (including Motor Carrier Services), and Business Licensing.

The SCDMV is open to reviewing a different recommended approach.

2.3 SDLC Documentation Tools

The Contractor shall implement a suite of tools to manage SDLC documentation for the project. The approach shall take advantage of integrated tools and functions to ensure traceability between requirement artifacts, design artifacts, source code versions, version changes, and testing-related artifacts.

Within Appendix 01, all references to source code documentation and documenting source code shall include documenting all human readable material including but not limited to programming languages build scripts, testing scripts, test data, configuration files and other materials.

2.4 Version Control Tools

The Contractor shall propose and implement a full suite of tools to manage the software development including requirements tracking, version control, code promotion, and other lifecycle processes as proposed in the implementation approach.

The Contractor shall implement the agreed-upon tools to track the versions of source code and all applicable configuration artifacts. The tools shall sufficiently handle branching and merging to allow for parallel development on different releases or other scopes of work. The Contractor shall define the strategy and plan for branching and merging to support the proposed development processes.

The version control tools, and their usage shall support retrieval of historical releases of the system, sufficient for them to be recreated in isolated environments, along with the supporting artifacts related to those releases.

2.5 Architecture & System Environments

1. Documenting Architecture – The Contractor shall collaborate with State staff to refine the architecture of the solution and implement all necessary system environments to support the complete lifecycle of the project. This includes all cloud hosted components.

Appendix 01 - Execution Requirements Page 5 of 30

2. Environment Implementation and Management – The Contractor shall develop and submit for approval all planning documents related to the design and implementation of system environments. Detailed procedures and tools for automating environment setup, replication, testing, administration, and management shall be developed. This includes:

a. Promoting and moving software and configurations between environments.

b. Data loading and scrubbing.

3. Configuration propagation, including reverse configuration transfers (e.g., from production to pre-production) for testing deployment configurations.

4. Development, implementation, and use of operational policies and procedures within the environments.

5. Development and implementation of the SDLC governance structure to ensure consistency in operations throughout the project.

6. Data Loading – The Contractor shall create procedures and tools to support the creation and loading of non-production data for testing and training purposes. This includes periodically refreshing data across all environments, data masking, data migration, and data scrubbing.

7. Legacy Environment Connectivity – The new system development, testing, and Q/A environments shall be connected to and synchronized with legacy systems as necessary to support development, testing, training, and production activities.

8. Sizing – Each of the new system environments shall be appropriately sized for its intended purpose. The Contractor shall develop a plan to ensure performance and User Acceptance Testing (UAT) occurs in an environment that accurately represents the new production system.

9. Environment-Specific Tools – Each environment may have specific requirements, such as tools installed for debugging or external service integration. The Contractor shall implement all necessary tools and technologies for each environment.

10. Maintenance – The Contractor shall maintain all vendor system environments, including database instances. The SCDMV will not provide resources for day-to-day support or administration of these environments.

11. Environment Management – The Contractor shall manage environment scheduling and usage. Responsibilities include data preparation, external system connectivity, data refresh, change documentation, and maintaining environments for use by both Contractor and SCDMV resources, including testers and trainers.

12. Activity Tracking – The Contractor shall develop audit processes for logging events in each environment to document activity, including all accesses or attempts to access a system, including the identity of each user and device:

a. Logoff activities,

b. Activities that might modify, bypass, or negate IT security safeguards,

c. Security-relevant actions associated with processing SCDMV data,

d. User generation of reports and extracts containing SCDMV data,

e. Any interaction with SCDMV data through an application, Appendix 01 - Execution Requirements Page 6 of 30

f. Password changes,

g. Creation or modification of groups,

h. Privileged user actions,

i. Access to the system,

j. Creating and deleting files,

k. Change of permissions or privileges,

l. Command line changes and queries,

m. Changes made to an application or database,

n. System and data interactions,

o. Opening and/or closing of files, and

p. Program execution activities.

13. Specific Environments – The Contractor shall provide separate environments to support:

a. Development.

b. System Testing.

c. Training.

d. UAT.

e. Staging and Conversion.

f. Production.

g. Others as necessary to support project and operational needs.

14. Each environment shall have separate database tables and operate independently to ensure no cross-environment contamination or system contention. Additional environments shall be established as required to meet the Release Plan or upon request through an approved Change Order.

15. The Contractor may propose a revised system environment plan for approval by the SCDMV, provided it better meets the project’s needs.

2.6 Requirements Traceability Matrix

The Contractor shall implement an automated tool to develop and maintain a Requirements Traceability Matrix (RTM). This RTM shall:

1. Document the source and definition of all requirements.

2. Enable the project team to trace requirements throughout the project lifecycle.

3. Ensure all requirements are defined, addressed, tested, and implemented.

The RTM shall be updated and maintained consistently throughout the duration of the project to reflect any changes or additions to requirements.

Appendix 01 - Execution Requirements Page 7 of 30

2.7 Capacity Analysis Plan

At project initiation, the Contractor shall develop and document a Capacity Analysis Plan. This plan will outline the process for determining detailed infrastructure requirements to meet the sizing and performance needs of the Modernized System in both production and non-production environments. The plan shall include the creation of a Capacity Analysis to confirm the breadth, specifications, and sizing of the proposed technical solution. The Capacity Analysis Plan shall be:

1. Developed during project startup.

2. Reviewed and revised after every major release to ensure ongoing alignment with project needs.

3. Equipped with sufficient elasticity capability for scaling the solution to efficiently consume increased capacity as demand on the system grows over time.

2.8 Tool and Approach Validation

The Contractor shall collaborate with the State to validate all technical approaches and tools that will be essential to the success of the project. This validation task will be adjusted as necessary based on the Contractor’s proposed technical approach and selected tools.

Appendix 01 - Execution Requirements Page 8 of 30

3 Initial Use Case Analysis and Gap Analysis The Contractor shall collaborate with the SCDMV to develop a comprehensive set of use cases and associated models that apply directly to SCDMV’s core business functions.

These deliverables will illustrate the Contractor’s understanding of the SCDMV system requirements and operations. The resulting artifacts will align all stakeholders on the project’s scope and core functionality.

For the purpose of these requirements in this section, the following terms are defined:

1. Existing functionality – The capabilities and features that exist in the product or components being proposed by the Contractor for the SCDMV modernized system before the product or components have been updated, tailored, configured, or modified for the SCDMV.

2. Proposed solution – The products and components being proposed by the Contractor that will be updated, tailored, configured, or modified to meet the requirements identified in this RFP and use cases including business rules and other definitions.

The Contractor shall perform a thorough Gap Analysis in partnership with the SCDMV.

This gap analysis will:

1. Compare and identify gaps in the existing functionality of the proposed solution, that must be addressed to satisfy the requirements outlined in this RFP and defined through the Use Case Analysis, including business rules and other definitions.

2. Address key functional areas, system architecture, information architecture, and system security planning.

3. The findings from the Gap Analysis will inform project planning discussions, including:

a. SCDMV system functionality

b. Implementation strategies

c. Release planning.

Artifacts produced during the Gap Analysis will serve as a foundation for planning but will not restrict or define the final scope of the project, as additional use cases and requirements will be developed throughout the project lifecycle.

During the startup phase of the project, the Contractor shall provide recommendations for tailoring this task to align with their proposed approach while maximizing value and relevance to the SCDMV’s objectives.

3.1 Business Use Cases

The Contractor shall build Business Use Cases and other artifacts necessary to facilitate the analysis, based upon existing artifacts. These use cases are expected to build upon the process information and requirements presented in this RFP and leverage any workflows and processes information collected by the SCDMV in preparation for the project.

Appendix 01 - Execution Requirements Page 9 of 30

Adapting Business Processes – The SCDMV is expecting that current business processes will be adapted to the functionality of the proposed solution in areas where the proposed solution has functionality that has been developed and proven for similar operations. The SCDMV will be the final decision maker on business processes.

3.2 Gap Analysis

The Contractor shall prepare a Gap Analysis that includes an approach for documenting observations and differences between the proposed system and the system described in this solicitation. The approach shall include, but not be limited to, describing how the degree of required change will be quantified or categorized. The approach shall describe how the analysis will be organized, how sessions will be conducted, what participation is required, and how results and conclusions will be reviewed with the SCDMV. The Contractor shall obtain approval from the SCDMV for the approach to documenting observations and differences and this approach shall be used by the Contractor consistently for all gap analyses.

The Gap Analysis shall address functional and non-functional requirements.

Legacy System Evolution – It is SCDMV’s goal to minimize changes to the current/legacy systems as the Modernized System is being planned and implemented but legacy systems will continue to evolve over the procurement processes and as the project begins. The Contractor shall work with the SCDMV to identify new functionality not included in this RFP that will need to be incorporated into the project.

3.3 Demonstration Environment

The Contractor shall prepare an un-customized version of the software for SCDMV to explore functionality and features provided by the Contractor’s software as the Demonstration Environment to be used for Gap Analysis. The Demonstration Environment shall have sample data, documentation on sample data and available transactions, and shall be available to State staff in a limited capacity.

Appendix 01 - Execution Requirements Page 10 of 30

4 Release Planning

4.1 Release Management Plan

The Contractor shall work with the SCDMV to develop a Release Plan. The Release Plan will describe how the Modernized System will be divided into multiple releases and the order in which those releases will be deployed. Each release shall be described in terms of functionality, dependencies on other releases, and approach to data conversion and synchronization.

The SCDMV expects that the initial release will address architectural requirements fundamental to the overall design of the system and the other functional releases. Each release may be divided into smaller sub-releases. The purpose of the sub-release is to create a manageable unit of work for the Contractor and the SCDMV resources.

The Contractor shall implement a system development/system configuration process that is iterative and consistent with a proven methodology approved by the SCDMV for this project.

4.2 Iterative SDLC for Each Release or Sub-Release

The Contractor shall present, gain approval from the SCDMV, and follow a proven methodology that iteratively collaborates with the SCDMV to review and refine requirements, prototype components of the solution, refine and test those components and then prepare for deployment.

Appendix 01 - Execution Requirements Page 11 of 30

5 Iterative Requirements Analysis and Design Activities The Contractor must develop, present for approval, and follow an iterative approach for reviewing all business functions and developing requirements and system designs collaboratively with the SCDMV staff. The Contractor shall recommend how this task can be tailored to best align with its approach and have maximum value.

Design Sessions with Staff – The State requires that the Contractor utilize design sessions, as a complement to any approach, to engage the participation of SCDMV staff throughout the project as necessary. Facilitated design sessions and interviews shall be conducted by the Contractor in order to fully understand and document the Modernized System’s functional and technical requirements.

Complete Analysis and Design to Fully Define All Parts of the System – The Contractor shall analyze all information provided by the SCDMV, obtain additional information, and begin to collaboratively create and document the solution for the new system. This high-level solution shall guide all subsequent activities required in this RFP. The solution as it continues to be refined shall address all system requirements including the integration with other systems.

Consistent Functionality – The sessions shall define a common design approach to ensure consistent implementation of functionality across the system. The State requires that business transactions conducted by SCDMV staff will execute with a consistent workflow and design.

5.1 Analysis and Design Sessions

The Contractor shall fully document the resulting requirements and designs using the appropriate design artifact templates. The Contractor shall obtain approval from the SCDMV for each resulting design artifact.

Analysis and design sessions will address:

1. Design of each system function and transaction

2. Functional/Non-Functional Scope of each system function and transaction

3. User Interface Design and Standards for SCDMV and Business Partner Users

4. User Interface Design and Standards for Public Web-based Customers/Users

5. Transaction Logs and Audit Requirements

6. Identity Management, Authentication, and Role Based Access Control

7. Security Approach

8. Database and Data Model

9. Conceptual and Logical Information Model

10. Infrastructure and foundation components (such as rules technology, workflow technology, report writers, and other applicable technology)

11. Document Management

12. Configurability

13. Reporting and Analysis

Appendix 01 - Execution Requirements Page 12 of 30

14. Auditing and Fraud Scenarios

The Contractor shall develop a complete list of topics to be covered in the requirements analysis and design sessions.

5.2 Experienced Facilitators

The Contractor shall provide experienced facilitators who understand:

1. The vision of the new SCDMV system

2. SCDMV requirements

3. Driver’s licensing and motor vehicle operations

The facilitators are expected to work with the users to merge SCDMV requirements with the Contractor’s proposed solution and develop a complete and comprehensive set of requirements and a documented design, including a user interface design that meets the SCDMV’s needs.

Appendix 01 - Execution Requirements Page 13 of 30

6 Iterative Development Activities The Contractor must develop, present for approval, and follow an iterative approach for developing and implementing the configuration of the system and any custom development. This approach must be integrated with the Analysis and Design Activities and be collaborative with the SCDMV’s staff. The Contractor shall recommend how this task can be tailored to best align with its approach and have maximum value.

The development activities of the project will include the setup and configuration of system components and programming. The SCDMV Subject Matter Experts (SMEs) will assist the Contractor during these activities to ensure that business requirements are understood and clear. During this project activity, the Contractor shall define and trace all requirements and business rules for the new system and ensure they are met.

6.1 Testing of Components

The Contractor shall plan, perform, and report on all activities required for Unit Testing.

Additional requirements are found in the next section describing test activities.

Appendix 01 - Execution Requirements Page 14 of 30

7 Testing Requirements The Contractor shall plan, prepare, document, and perform the following tests for each production release:

1. Unit Testing

2. System and Integration Testing

3. Vulnerability/Penetration Testing

4. Performance Testing (Volume and Stress)

5. User Acceptance Testing (UAT)

The Contractor will perform all testing required by AAMVA and the Federal Government including AAMVA Structured Testing.

The Contractor shall support the preparation and execution of UAT testing with the SCDMV team.

7.1 Contractor Testing Deliverables

The Contractor must provide the following testing deliverables:

1. Test plan prior to each Release – this must be approved by SCDMV before testing begins.

2. Test environment(s), data and scripts for each test.

3. Test reports including defects and results.

4. Execution of all tests.

5. Vulnerability test recommendations.

6. AAMVA structured test artifacts and test execution.

7. UAT preparation and facilitation and documentation (Results, defects).

8. Certification that the release is ready for production.

7.2 Required Testing Activities

For each testing effort, the Contractor shall:

1. Use testing environments such as Development, System Test, UAT, etc.

2. Use the agreed-upon Defect Tracking Tool.

3. Document all test scripts in the Requirement Traceability Matrix or similar tool.

4. Identify data needed for testing. The SCDMV and the Contractor shall mask all data for testing. The Contractor must provide a mechanism to refresh data for each environment and build/test cycle.

5. Use ETL (Extract, Transform, Load) Tools to load data for this testing.

6. Use Automated Testing tools for regression testing where possible/feasible and/or Manual scripts to conduct these tests.

7. Include compatibility testing with legacy systems to verify co-existence requirements (ex: field length limits).

Appendix 01 - Execution Requirements Page 15 of 30

8. Document the results, highlight deficiencies, and the approach and schedule for fixing the deficiencies.

7.3 Tests to be Conducted by the Contractor

7.3.1 Unit Testing

The Contractor shall conduct unit testing on all components that are configured or developed. The Contractor shall develop Unit Test plans, execute the testing in an appropriate environment, and report in writing on all tests and results. Test plans must be shared with and agreed to by SCDMV.

7.3.2 System and Integration Testing

The Contractor shall conduct system and integration tests to demonstrate the successful operation of the System. The Contractor shall demonstrate that the new solution is fully usable, functioning, processing data correctly, and working as designed.

System Test will focus on testing the entire system without integration to external systems. External systems will be represented by stub interfaces or leverage other approaches as appropriate and approved by the SCDMV.

Integration Testing shall include the approach and scripts used for System Test and incorporate those necessary to test the integration of the Modernized System with external systems. These external systems include those managed by the federal government, AAMVA, and the SCDMV that need to exchange data with the system.

As any module of the new system becomes ready, each shall undergo a system test cycle. The compatibility and continued reliability of existing modules shall be regression tested when new modules are released.

The Contractor’s system test responsibilities include but are not limited to:

1. Functional testing, i.e., “black box” testing (the tester only knows the inputs and what the expected outcomes should be, and not how the program arrives at those outputs).

2. Structural testing, i.e., “white box” testing (the tester knows what the program is supposed to do, and the tests are designed to fully exercise the internal components of the system).

3. Testing of unexpected messages, transactions, and abnormal conditions.

4. Hardware and software fault testing that introduces faults into physical hardware and software.

5. Reliability testing that identifies and tests the ability to endure hazards, including vulnerability to attack and hacking.

6. Additional scenario/process variation testing that links together and invokes sequences of test cases.

Appendix 01 - Execution Requirements Page 16 of 30

7. Manual and automated Regression testing, which is the repetitive testing of an application’s major features to ensure that changes have not introduced new defects into the system.

8. Integrated testing of all system modules.

9. Installation testing, that validates that the application will install and operate properly on the servers.

System Testing shall verify the following:

1. All functions and capabilities of the system.

2. Installation of software.

3. Conversion of data.

4. System, data, and application security.

5. Backup and recovery operations.

6. Accuracy and general performance.

7. Accuracy of documentation, manuals, and training materials.

8. Response time and overall system performance.

By the end of the System Test phase, the Contractor shall demonstrate that all known defects have been fixed, consistent with the approach agreed upon.

7.3.3 Vulnerability Testing

The Contractor must run security scans and other necessary tests for every component prior to being deployed. The Contractor must conduct all scans and tests and confirm the approach with the SCDMV. The Contractor shall run all tests with guidance from the SCDMV staff. The Contractor shall interpret all results and review them with the SCDMV and present recommendations to the SCDMV to address any security concerns.

7.3.4 Performance Testing

The Contractor must execute performance tests to demonstrate the solution meets performance requirements under expected user loads. The test will use peak volumes and test for higher-than-expected volumes and increasing activity levels.

The Contractor must lead the preparation and execution of a Performance Test plan that includes the use of system and network monitoring software, and system load simulation software. The Contractor must work with the SCDMV to develop/document the appropriate combinations of transactions and transaction levels to test the system.

The Performance Tests shall test:

1. Response time

2. Resource utilization

3. Overall system performance

4. Query expense evaluation

Appendix 01 - Execution Requirements Page 17 of 30

7.4 UAT Test Requirements

The Contractor must provide support to the SCDMV for User Acceptance Testing. This support includes the preparation of the testing environment, preparation of test data, management and support of testing tools and defect tracking system, and support tracking and documenting any defects or concerns.

The Contractor shall train SCDMV staff who participate in the testing effort and use the test tools. Staff training shall include usage of the System as well as usage of the testing tools and processes.

The SCDMV will lead the definition and execution of UAT which will be the final acceptance process by the SCDMV for the new system.

The Contractor must provide for automated data aging to allow testing of transactions with date sensitivity.

For User Acceptance Testing, the Contractor shall provide the following services:

1. Use the Testing Environment established in the Set-up activities or create an additional environment for this testing.

2. Provide training to the SCDMV team on the solution and test tools.

3. Meet with the SCDMV UAT Team prior to UAT to review proposed cycles, test scripts, and available data.

4. Provide existing test scripts from system, performance, and penetration testing to the SCDMV UAT Team.

5. Provide access to the Requirements Traceability Matrix for the SCDMV UAT Team to add additional test scripts.

6. Identify data needed for testing. The SCDMV and the Contractor shall mask all data for testing.

7. Support UAT by refreshing databases, etc.

8. Use ETL Tools to load data for this testing.

9. Provide the SCDMV UAT team with Release notes, identifying functions/capabilities fixed since the last cycle as well as new features/functionality introduced.

10. The SCDMV UAT Team will document the UAT results in the agreed upon bug tracking tool. The SCDMV UAT Team and Contractor will classify and prioritize these bugs.

11. Define a schedule for fixing the bugs and a cycle for retesting the bugs.

12. The number of UAT cycles will depend on the phase, number/type of bugs found during previous UAT cycles and build process.

7.5 Testing Environments

The Contractor shall set up separate system environments for test activities and shall be able to create additional environments as required.

The Contractor shall be responsible for the testing environment, refreshing the data and the state of the environment for testing.

Appendix 01 - Execution Requirements Page 18 of 30

The Contractor shall create/update automated regression testing capabilities/scripts to test existing system components, where possible/feasible, when new components are developed and prepared for deployment.

7.6 Defect Management

The Contractor must provide a defect tracking system to track all system problems.

Tools such as Microsoft Excel are not considered acceptable as a tracking tool for a project of this size.

The Contractor must provide a mechanism for tracking expected versus actual test results, tracking all errors, problems and resolutions. The Contractor shall obtain approval from the SCDMV for all reports and tracking/reporting processes.

The Contractor and the SCDMV must work together to document the definition of defect classifications such as low, medium, high and critical/blocking. All defects found during a test phase shall be classified. All defects classified as medium, high or critical/blocking shall be fixed and satisfactorily tested prior to completion of the phase or entering into a new phase. The SCDMV has the final determination of which defects, of any classification, must be fixed prior to production and may include “low” defects such as spelling mistakes on public facing screens.

7.7 Use Automated Testing Tools

The Contractor shall utilize automated testing tools and provide the documented processes to support the testing phases and shall provide the testing tools and licenses for the project. The testing tools, processes, and environments shall be documented and turned over to the SCDMV at the end of the project.

Any license or right to use the testing tools shall be transferred to the SCDMV for support of the system at the end of the contract. The Contractor shall provide training to SCDMV staff so that they may participate productively in the testing process.

7.8 AAMVA Structured Testing

The Contractor must facilitate and execute the preparation, performance, and documentation of all required AAMVA structured tests until AAMVA approval is achieved for each production release.

Appendix 01 - Execution Requirements Page 19 of 30

8 Data Conversion and Migration The Contractor shall work with SCDMV staff to plan and execute legacy data migration, conversion, and synchronization to the Modernized System. The SCDMV has identified multiple legacy data sources as depicted and summarized below.

1. Microsoft SQL Server

2. Oracle

3. File System Content

4. Microsoft Excel files

5. MS Access databases

6. Scanned Document Files

These data sources shall be analyzed, and all necessary sources shall be migrated to the new Modernized System as required to satisfy the business and technical requirements of this RFP and the SCDMV’s needs. Based on the Contractor’s release plan, some or all of the legacy databases shall be synchronized with the Modernized System to ensure concurrent operation of legacy systems and the Modernized System with no loss of data or risk of stale data being accessed or used for transaction processing or reporting.

Develop Plan – The Contractor shall develop data migration, data conversion, and data synchronization plans that outline the strategy and timing for these critical activities.

These plans shall identify risks, risk mitigation, and recovery procedures in the event of a migration, conversion, or data synchronization failure. The Contractor shall submit the data migration, data conversion, and data synchronization plans, and any substantive updates to these plans, to the SCDMV for review and approval.

Execute Data Migration (including conversion and synchronization) Plan – The Contractor shall design, build and execute the legacy data migration, data conversion, and data synchronization solutions necessary to execute their proposed system deployment strategy. The solution shall address synchronization of file system content with database pointers as required to properly migrate all data sources required.

State Assistance and Collaboration – The Contractor will be assisted by the State with data mapping, identification of legacy data to be migrated, and conversion of that data from the legacy data sources to the Modernized System.

Need for Flexibility – The State expects the data strategy and solution will be influenced by the architecture of the legacy applications, the architecture of the new system, and the deployment strategy.

Included in Master Schedule – Timelines for data conversion and related activities shall be specifically identified in the Contractor’s Master Project Schedule.

Appendix 01 - Execution Requirements Page 20 of 30

8.1 Current SCDMV Data Stores & Architecture

The preceding diagram depicts the high-level view of current legacy SCDMV system and data stores. This data landscape will change with each major release deployment; thus, it shall be considered within the Contractor’s proposed data migration, data conversion, data synchronization, and interface strategy.

As seen in the diagram above – the major systems include:

1. Phoenix System – Oracle database

2. Phoenix System – SQL Server Database

3. Scanned Documents

4. Celtic System

8.2 Unstructured Content/Document Management

The Contractor shall work with State staff to ensure that unstructured content is migrated to the Modernized System. The Contractor and the State will collaborate to finalize the approach for document migration and storage. The approach will include the State’s existing Document Management System (currently PowerDMS, AS Doc2/Hitachi HCPAWE platform, OnBase System, and Kofax System), or a system provided by the Contractor as part of the proposed solution. For all the items below, the SCDMV will determine with the Contractor the strategy for conversion, Driver License Photos and Signature Images – These images will either remain in their current repository which is managed by the SCDMV’s photo capture and card production vendor or will be migrated to the new system.

Identity Documents – These documents are stored in the SCDMV’s system and will remain in their current system or will be migrated to the new system.

Appendix 01 - Execution Requirements Page 21 of 30

Transaction Documents – These documents are supporting documents associated with vehicle titles, registrations, and liens or with driver service transactions, and they must be migrated over into the Modernized System.

The Contractor must configure the corresponding non-production environments with Enterprise Content Management (ECM) access and prepare those environments with appropriate data (both structured and unstructured).

8.3 SCDMV Data Preparation Activities

The SCDMV will document SCDMV’s current operational data, including inventory, analysis and documentation of data stored in legacy systems. The SCDMV is working with its legacy system staff and subject matter experts to develop documentation of the current operational data, including entity and attribute level names and definitions, constraints, validation rules, and relationships.

The SCDMV will identify data quality issues in the legacy data, document any issues, and identify methods to resolve those issues. To the extent possible, the SCDMV will resolve data quality issues.

The SCDMV expects the results of this effort will benefit the Contractor’s analysis and planning work. All results of this effort, including documentation, analyses, code, and databases, will be made available to the Contractor.

8.4 Legacy System Change

The data conversion and migration plan shall minimize risk to the stability of the legacy systems. The Contractor shall take appropriate actions to minimize changes to legacy systems. The Contractor shall obtain approval from the SCDMV’s legacy systems staff for any proposed change that could impact the legacy systems. The Contractor shall work with the SCDMV’s legacy system staff to design, develop, or deploy any required changes to legacy systems.

The data conversion and migration plan shall not require legacy system downtime in excess of the time allotted for standard system maintenance.

8.5 Data Conversion, Migration and Synchronization Specifications

The detailed specifications for any and all data conversion, migration, and synchronization activities will be created and approved by SCDMV before any of these activities are performed against production data environments. These specifications at a minimum will include these details:

1. Source – Source Location (e.g., System/File/Database Table).

2. Source Data Element – Source Data Element Identifier (e.g., DOB).

3. Destination – Target Location (e.g., Database Table).

4. Target Data Element – Target Data Element Identifier (e.g., Member ID).

5. Transformation/ Cleansing Rules – Describe data transformation that is to occur, including any data cleansing.

6. Notes – Describe any timing constraints or anything unique about the conversion.

Appendix 01 - Execution Requirements Page 22 of 30

8.6 Tools and Procedures

The Contractor shall provide or develop the tools and procedures to do additional data analysis, conversion, and migration.

8.7 Data Synchronization

The SCDMV anticipates that the phased deployment strategy for Modernized Systems will require parallel operation of the legacy and new systems, and that some method of data synchronization will therefore be required to enable continued operation of business functions not yet migrated to the new system.

Data Synchronization Solution – The Contractor shall identify, design, develop, and implement a data synchronization solution, as required, to support parallel operation of the legacy and new systems consistent with the deployment strategy. Working with SCDMV staff, the Contractor shall ensure continued operation of business functions between legacy systems, to include real time or near real time data synchronization if required.

8.8 Data Quality

The Contractor is responsible for legacy data conversion into the new system, including validating data quality and, to the extent possible, resolving data quality issues. If any data quality issues cannot be resolved, the Contractor shall document such instances and submit options for the SCDMV’s consideration.

The data conversion and migration plan shall anticipate that some data records will not be convertible programmatically. The Contractor shall provide or develop any tools or user interfaces allowing SCDMV staff to manually complete or reconcile those records on a case-by-case basis. In this plan the contractor shall, at a minimum:

1. General Strategy – Describe the strategy to be used to ensure data quality before and after all data conversions.

2. Data Quality Approach – Describe the approach to data scrubbing and quality assessment of data before they are moved to the new or converted system.

3. Data Validation – Describe the manual and/or automated controls and methods to be used to validate the conversion and to ensure that all data intended for conversion have been converted.

4. Error Detection – Describe the process for data error detection and correction, and the process for resolving anomalies.

5. Conversion Tracking – Audit, history and roll-back capability for all identified data quality problems.

6. Data Quality Categorization – Identify the types of data quality problems that may occur, including but not limited to the following considerations:

a. data type redefinitions (e.g., alphas in dates and numbers, embedded information in codes and intelligent keys, implied content);

b. garbled content (e.g., multiple uses for a single field, freeform text values, corrupted data, un-initialized data);

Appendix 01 - Execution Requirements Page 23 of 30

c. invalid record relationships (e.g., broken chains in set relationships, orphan records (on natural key), mismatched keys (set vs. natural key));

d. invalid content (e.g., values out of defined range, code fields not on a valid list of values or lookup table, blank fields (optionality), inconsistent use of defaults);

e. context changes (e.g., import of external data, historic changes to operational parameters (system upgrades), synchronization timing of duplicated de-normalized data); and

f. behavior issues (e.g., variations in actual data from planned constraints of size, data type, validation rules, and relationships).

8.9 Conversion Testing

The Contractor shall ensure data conversions are validated and reviewed by the SCDMV’s subject matter experts.

8.10 Location and Governing Policies

1. All Systems Must Be Secure – Any system that processes or is loaded with production data must be fully secured, encrypted, and protected as if it were in production prior to accessing production data.

2. SCDMV Must Approve All Transfers – The transfer of production data from a production system or other SCDMV data repository to any new system must have SCDMV approval before the transfer occurs.

3. DPPA – The SCDMV and the Contractor shall comply with the Driver Privacy Protection Act (DPPA) and applicable security policies.

Appendix 01 - Execution Requirements Page 24 of 30

9 Implementation Activities The Contractor shall develop and execute an Implementation Plan to ensure that all system capabilities are implemented over a rollout period and with an approach to be defined by the Contractor and the SCDMV. The SCDMV will not accept the system for consideration for production use until successful completion of all implementation tasks are confirmed by the Contractor and the SCDMV.

Legacy System and Training Tasks – Implementation plans shall address any necessary action for the current SCDMV systems to facilitate final data conversion. The Implementation plans shall also address training and be aligned with the project’s training plans.

Rollback Plan – The Contractor shall work with the SCDMV to develop and document a rollback plan. The rollback plan shall identify implementation failure scenarios that could require roll-back to the legacy systems. The rollback plan shall document the incident reporting, recovery and stabilization activities required to roll back to the legacy system as well as the criteria for SCDMV approval to allow the Contractor to restart the implementation activities.

Implementation Requirements – As part of the implementation activities the Contractor shall perform data conversion and migration from the legacy system to the new Modernized System, monitor system operations, manage and operate the Modernized System and develop or update the following:

1. Complete System – includes all code – modules, components, and libraries – kept in the production version of the data repository.

2. System Documentation – includes all technical documentation delivered during the project (e.g. the SDD and the User Guide).

3. System Performance Reports – provides an update on system performance as the release is moved into production.

4. Implementation Notice – formally requests approval for system changes made during the Implementation Phase.

5. Readiness Document – consolidates summary information regarding the current status of the system and the project and provides decision makers with the information necessary to make a “Go/No Go” decision. It shall include a checklist listing all work products, User Acceptance Test (UAT) results, other indicators of success measures and deliverable acceptance.

6. Version Description Document – primary configuration control document used to track and control versions of software released to the operational environment. It also summarizes features and contents for the software build and identifies and describes the version of software delivered.

7. Implementation Plan – describes the approach, resources, and all aspects of the rollout.

8. Rollback Plan – describes the scenarios and failure points that will require a rollback to the legacy systems along with any recovery actions required to ensure data integrity.

Appendix 01 - Execution Requirements Page 25 of 30

9. Post-Implementation Review Report – summarizes the assessment of Implementation activities at the end of the Implementation Phase.

Appendix 01 - Execution Requirements Page 26 of 30

10 Contractor Logistics The SCDMV requires that certain project work such as design sessions and project reviews shall be performed at the SCDMV site in the greater Columbia, South Carolina area. This on-site work includes providing ongoing knowledge transfer to the SCDMV’s technical staff during design sessions, status meetings, etc. The Contractor shall locate key staff positions on-site for the duration of the project when they are active on the project. Certain staff, with SCDMV approval, may be located off-site, however the SCDMV requires the team to have frequent communication and interaction with the SCDMV staff and their on-site counterpart. The entire SCDMV-Contractor project team must be working together on coordinated tasks. If off-site work is proposed, the Contractor shall implement a team structure where all activities are represented on-site though a portion of the activities are completed off-site.

The SCDMV will provide:

1. Workspace in in the greater Columbia area for onsite staff

2. Work surfaces (desks, cubicles, tables, etc.)

3. Network-shared printers

4. Access to state systems, as determined by SCDMV.

The SCDMV will not provide physical computer workstations (except for secure SCDMV workstations as necessary)

The Contractor shall provide licenses for:

1. Development tools with appropriate storage and backup.

2. Virus Protection and Security Software for Contractor’s physical workstations attached to the SCDMV’s virtual desktop infrastructure.

3. Other software needed for project activities.

The Contractor shall provide:

1. Software – All development and project management software and tools, with appropriate licenses for the new system’s applications for all the developers' PC workstations, including the SCDMV staff. This software and installation instructions shall be provided to the SCDMV for installation on SCDMV hardware.

2. Peripherals – Personal printers and other personal hardware (e.g. scanners, supplemental storage) for contractor workstations, subject to State security policy.

The contractor shall obtain approval from the SCDMV prior to attaching any peripherals including storage devices to SCDMV workstations.

3. Developer Workstations – Personal computers and displays, as required for all Contractor’s staff, and sufficient to support the required development software/tools, with appropriate licenses for the operating system(s). The SCDMV will work with the Contractor to develop a workstation configuration for developers and on-site project staff. All on-site workstations must adhere to the State’s security and technical requirements.

Appendix 01 - Execution Requirements Page 27 of 30

11 Documentation Requirements

11.1 Overview

Documentation shall be reviewed and validated for completeness and accuracy as part of the Contractor’s SDLC. The Contractor shall obtain approval from the State for the format of all documentation. It shall be consistent with State and SCDMV standards and industry standards or agreed upon templates.

11.2 SDLC Design Documentation

The following represents minimum requirements for the system design documentation.

11.2.1 Introduction

Overview of the components being described referencing the conceptual design and additional information useful in understanding the solution.

11.2.2 Module List

Complete list of physical modules as appropriate to development language, including name and function.

11.2.3 Module Design and Specifications

For all modules or technical elements, the following, and other appropriate information, shall be described:

1. Name and description

2. Function

3. Inputs, protocols and layouts

4. Outputs, protocols and layouts

5. Process specifications

6. Physical location and related implementation information such as…