Appendix G - Technical Business Requirements Rev. 1.xlsx
XLSX spreadsheet 42 KB Posted
- Solicitation number
- RFP26006341
- Issued by
- Providence County, Rhode Island
About this file
This is Appendix G of a technical business requirements document for the Rhode Island Department of Revenue, Division of Motor Vehicles credentialing system replacement project (RFP26006341). The document provides a structured spreadsheet framework for vendor responses regarding system capabilities across multiple functional areas including system-wide requirements, commercial licensing, seed-to-sale tracking, registration, and home grow tags. Vendors must complete response columns indicating whether their commercial off-the-shelf (COTS) software meets, is configurable to meet, or requires tools, external customization, or core changes to satisfy each requirement. Responses must be submitted in Excel format to the Rhode Island Department of Administration, Division of Purchases. The vendor question and answer submission period opens February 5, 2026 at 10:15 AM EST and closes February 18, 2026 at 2:00 PM EST, with all proposals due electronically through Ocean State Procures no later than March 5, 2026 at 11:00 AM EST. The initial contract period commences approximately July 1, 2026 and runs for four years including the implementation phase, with optional renewal periods of up to four additional 12-month terms contingent upon vendor performance and fund availability.
The requirements document establishes critical, high, medium, and low priority specifications across security, performance, integration, and support categories. Critical requirements include FedRamp ATO Moderate certification, NIST 800-53 compliance, encryption standards (FIPS 140-2), user and role-based security controls, data retention and audit logging capabilities, and facial recognition functionality with 1:N and 1:R matching capabilities for driver's license and identification card issuance. Vendors must identify estimated levels of effort (small, medium, or large) for any customizations required and provide detailed comments explaining their responses. The system must support image and signature capture, secure card production compliant with AAMVA and REAL ID Act standards, mobile workstations, real-time data transmission, voter registration and organ donor registration capture, and performance standards not exceeding five seconds per transaction. Vendors must demonstrate ADA compliance with WCAG 2.1 standards, provide comprehensive training through train-the-trainer models, maintain rigorous quality assurance and user acceptance testing in non-production environments, and offer ongoing maintenance and support throughout the contract term with defined service level agreements.
View the file
Other files
Show all 15
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Appendix G - DMV Credentialing Detailed Business and Technical Requirements |
| IMPORTANT: Delete this text and type your Vendor / Company Name here on the Bidder Instruction Page |
| SUMMARY & INSTRUCTIONS: |
| The requirements have been set up in a form for bidder response. |
| The text in this document may not include formatting such as the indented bullet lists, but the text is the same. |
| Most of this spreadsheet file has been protected. Portions for your response have been left available for editing |
| This response must be submitted to Rhode Island Department of Administration, Division of Purchases in Excel |
| although you may print your responses to include as a hard copy in the proposal. |
| There are multiple tabs containing requirements in this spreadsheet which require response. |
| Click on any section link below to jump to that tab. |
| System-Wide Requirements |
| Commercial Licensing Requirements |
| Seed-to-Sale Requirements |
| Registration Requirements |
| Home Grow Tags Requirements |
| Response Constraints |
| Responses are limited to those defined in the document Glossary. |
| Glossary |
| 1) RESPONSE |
| Please complete the RESPONSE column for each requirement row on each of the spreadsheet tabs listed |
| For most Business Requirements we are asking you to indicate if your COTS software meets or can be configured to meet the requirement. |
| Click on the cell to the right of each requirement's text and select a RESPONSE from the drop down list. |
| The list of possible responses to select from and their definitions is listed on the Glossary Tab |
| The available responses are different for Business and Technical requirements. |
| Please read the definitions of the responses carefully and select the best answer for each requirement. |
| 2) LEVEL OF EFFORT |
| If you select TOOL, EXTERNAL or CORE as the response, also select an estimated level of effort. |
| Read the definitions of the levels of effort carefully on the Glossary tab. |
| In the appropriate column, select the level of EFFORT that you believe will be required to meet the |
| 3) NOTES / COMMENTS |
| At the bottom of each tab's list of requirements there are 10 rows on which you can make comments related to the requirements in that section. Please specify the requirement number(s) being commented upon. |
| If you select TOOL as the response to a requirement, please identify the recommended tool(s) here in the |
Sternick, Jennifer (DOA): Sternick, Jennifer (DOA):
There appears to be some verbiage missing?
Sternick, Jennifer (DOA): Sternick, Jennifer (DOA): Verbiage missing?
| There is a limited amount of space available for comments. You can widen the row heights if needed. |
| A text explanation of the response to every business requirement is not required. Use discretion when making explanatory notes. |
| Please add only important comments which clarify or add significant information to the response. |
| On the technical requirements tab there is a column available for comments on each requirement row. |
| Please see the Response definitions in the Glossary to determine what to put in the comments column for technical requirements. |
Glossary
| Business Requirements Response RFP Language / Glossary Description | RFP Language / Glossary | Description |
| CONFIGURABLE | Configurable | Requirement functionality is considered to be configurable if the process is driven by data stored in tables and it can be created and modified through a structured user interface by entering information to discrete fields and selecting options via radio buttons, check boxes, and drop down lists. Configurable also includes standard reports available through the system or readily built within the COTS system. |
| TOOL | Tool Integration | Requirement functionality would be met by using an external tool which can be readily integrated with the COTS application via an exposed interface, or native database functionality such as triggers may be used to satisfy this requirement, or a report that would be built using a reporting tool outside the system but which references system data. |
| EXTERNAL | External Custom Code | In order to meet this requirement a pre or post process piece of custom code must be written and run outside the COTS software. Data required by the process is readily available through an exposed application programming interface and/or the output of the external process can be readily consumed by the COTS application. The custom code would be maintained & supported by the author or user of the code. |
| CORE | Core Change | In order to meet this requirement the COTS Software Publisher would develop or edit the proprietary COTS source software code within the COTS product to meet this functional requirement. The code would be maintained either as an integrated part of the core COTS application or as a known branch to the core application code. |
| NOT MET | Not Met | This requirement can not be met by the COTS application product. |
| Security & Data Integrity Response RFP Language / Glossary Description | RFP Language / Glossary | Description |
| MET | Met / Meets | The software product as provided meets the requirement or installation can be |
configured in such a way as to meet the requirement. If there are multiple choices offered in the requirement or various ways the requirement can be met, please indicate in the comments which standard is adhered to or how the COTS product meets the requirement.
| PARTIAL | Partially Meets | The software product partially meets this requirement. Specify in the comments column what part of this technical requirement is not met by the software product as provided. |
| CORE | Core Change | In order to meet this requirement the COTS Software Publisher would develop or edit the proprietary COTS source software code within the COTS product to meet this functional requirement. The code would be maintained either as an integrated part of the core COTS application or as a known branch to the core application code. If the core change is on a known technical development roadmap, state that in the comments, tell us the estimated timeline, and provide a copy of the technical development roadmap document if you have one. |
| NA | Not Applicable | The COTS product does not utilize this technology and therefore does not need to meet this standard. This choice is only acceptable where an "if" statement is included in the requirement. |
| UNKNOWN | Unknown | The bidder is unable to determine if the COTS product meets this requirement or not. Please state in the comments why you chose this response. |
| NOT MET | Not Met | This requirement is not be met by the COTS application product. |
| LEVEL OF EFFORT DESCRIPTION | DESCRIPTION |
| SMALL | A single resource could accomplish the customization work in a |
time period measured in days.
| MEDIUM | Multiple resources working together could accomplish the customization work in a period measured in weeks. |
| LARGE | A team of resources could accomplish the customization work in a period measured in months. |
RI Specific Terms Definition Definition
| Priority Description | Description |
| CRITICAL | Mission critical requirement within the scope of the project, reflecting core functionality of the proposed solution. These requirements represent the minimum viable solution or at least functionality that is among the primary goals of this implementation. |
| HIGH | Important requirement within the scope of the project, reflecting functionality that is required in order to successfully deliver the proposed solution. |
| MEDIUM | Requirement that may represent desired "to-be" functionality that does not impact the minimum viable solution. |
| LOW | Requirement that may represent desired "to-be" functionality in later phases of the project, or represent anciliary business needs. |
System-Wide Requirements
| General System-Wide Requirements | ||||||
| Requirement Group | ID | Requirement Detail | Priority | Response | Effort | Notes/Comments |
| Administration | 1 | Ability of State and contractor staff to receive automated email or SMS alerts related to platform performance or security issues. | High | |||
| Administration | 2 | System requires non-SSO State users to change passwords at regular intervals. | High | |||
| Data and Reporting | 3 | The contractor must allow the State of Rhode Island access to the raw data for reporting purposes, such as via a coalesced database view exposed through a secure ODBC connection for use with a reporting tool or secured, RESTful web service interface. The contractor must provide a detailed “data dictionary,” and schema overview so the State can efficiently query the solution. | Critical | |||
| Environments | 4 | The system and any change to it are deployed using an automated Continuous Integration/Continuous Delivery pipeline. | Medium | |||
| Environments | 5 | The system allows the maintenance of multiple environments, such as Development, Testing or UAT, and Production. | High | |||
| Environments | 6 | The system has a production copy or near-copy dedicated training environment. | High | |||
| Implementation | 7 | All configuration, customization or code developed as part of the system must be documented in accordance with industry standards. | High | |||
| Implementation | 8 | Vendor provides tools to support implementation and testing of the system (e.g., Jira, Confluence, etc.). | Critical | |||
| Implementation | 9 | The system is developed using modern version control technologies (Git, e.g.) for all development branches, configuration changes, etc. | Low | |||
| Integration | 10 | System has open, well-documented APIs that allow the state to integrate it with legacy applications, third party solutions, or services from other cloud service providers in the market. | Critical | |||
| Integration | 11 | Allows Single-Sign On to the State's Office 365 infrastructure. | Low | |||
| Performance | 12 | The system should have high reliability and should be down a minimal amount of time for scheduled maintenance. [Need to define high reliability in % and transactions times measured by RUM. | Critical | |||
| Security | 13 | FedRamp ATO Moderate for hosting and/or application platform. | Critical | |||
| Security | 14 | The solution must offer user- and role-based security so that the system administrator can precisely control access permissions to solution features and transactions. | Critical | |||
| Security | 15 | Hosting infrastructure and application configuration risk management must be provably aligned with NIST 800-53. |
| https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final | Critical | |||
| Security | 16 | Ability to blacklist and whitelist IP addresses based on geolocation or preapproved lists. | High | |
| Security | 17 | Ability for system administrators to deactivate public or State users at any time without modifying any data with which they may be associated in the system. | Critical | |
| Security | 18 | Ability to support encryption of data at rest. | Critical | |
| Security | 19 | Ability to support encryption of data during transport. | Critical | |
| Security | 20 | System uses encryption that is in compliance with FIPS 140-2 standards. | Critical | |
| Security | 21 | While inputs must be validated throughout for business accuracy, the solution should be well-tested against malicious attacks such as SQL Injections, etc. | Critical | |
| Security | 22 | All Solution data will be retained for records retention periods set by the Departments, and will be backed up, co-located and replicated to be in compliance with State and Federal requirements. | Critical | |
| Security | 23 | Solution must retain a history of all network and application accesses including a history of all transactions performed while the user was logged on. This information must be retained for a minimum of 2 years unless otherwise specified by RI law, regulations, policy and/or standards. | Critical | |
| Security | 24 | Records all data updates, along with the data changed and the user who made the update, in an audit log accessible via a graphical user interface.. | Critical | |
| Support and Training | 25 | Role-based user manuals and release notes are available online. | Medium | |
| Support and Training | 26 | Vendor provides in person and online training, and system has built-in as well as on-demand interactive training, curriculum, and modules. | High | |
| Support and Training | 27 | User support forums or discussion groups are available. | Low | |
| Usability | 28 | Ability to spell check data entries in fields. | Medium |
Credentialing
| Credentialing | ||||||
| Requirement Group | ID | Requirement Detail | Priority | Response | Effort | Notes/Comments |
| Environment | 1 | UAT and Production environments must be provided | High | |||
| Environment | 2 | Solution must be able to perform no longer than 5 seconds per transaction | High | |||
| Environment | 3 | Any installations on local machines should be completed by vendor. | ||||
| High | ||||||
| Environment | 4 | Software versions used by the vendor should be within manufacturer support. | Critical | |||
| Functional | 6 | The solution must provide image capture and signature capture | Critical | |||
| Functional | 7 | Solution must provide secure production and mailing of DL/ID cards from a central facility. The vendor(s) must be able to meet both standard and expedited production requests while securing their facility and card production against unauthorized access and natural disasters. The vendor(s) will produce various DL/ID card types in compliance with American Association of Motor Vehicles Administrators (AAMVA) and REAL ID Act of 2005 (Real ID or Real ID Act) standards and implement quality assurance measures to ensure the timely production of all requests. | Critical | |||
| Functional | 8 | The solution will be required to include facial recognition identification matches (1:N and 1:R), ability to maintain an exclusion and exception list, access control features, robust search capabilities, and reporting functionalities. | Critical | |||
| Functional | 9 | The solution will be required to provide mobile workstations for branch office and off-site locations. | Critical | |||
| Functional | 10 | The solution must be able to capture voter registration, organ donor registration. | Critical | |||
| Functional | 11 | The solution must be able to transmit data real time from various machines. | Critical | |||
| Support and Training | 12 | The vendor must provide both “train-the-trainer” and direct modes of training services to RI DMV staff, AAA and other partners through the life of the contract. The training plan will encompass content for all vendor solutions, incorporate industry best practices, and be specifically tailored to the RI DMV. | High | |||
| Support and Training | 13 | The vendor must adhere to rigorous quality assurance and user acceptance testing processes prior to deploying a solution for production use. These services will be conducted within a non-production environment that is created and maintained by the vendor. | High | |||
| Support and Training | 14 | The vendor must provide solution maintenance and support for any processes relating to DL/ID issuance through the life of the contract. The vendor’s ability to efficiently intake and responsively address system performance and hardware issues will meet the service level agreements | High | |||
| Support and Training | 15 | The vendor must be ADA compliant in accordance with the World Wide Web Consortium’s Web Content Authoring Guidelines, version 2.1, level A and AA Guidelines (WCAG 2.1 Standards) and all of the State’s IT Accessibility Policies and RI DMV Accessibility Standards. | High | |||
| Support and Training | 16 | The vendor must provide access to electronic troubleshooting ticketing system. | Med |
File details come from the government source that posted it. Updated .