ESBD_371873_1723662539807_Attachment D. Technical Requirements Response Workbook.xlsx
XLSX spreadsheet 62 KB Posted
- Attached to
- Legacy Systems Replacement Project
- Solicitation number
- 452-24-BLC020
- Issued by
- Travis County, Austin City, Texas
About this file
This document is a Technical Requirements Response Workbook for the Texas Department of Licensing and Regulation (TDLR) Replacement of Legacy Licensing Systems Replacement Project. The workbook provides instructions for offerors to complete and submit with their proposal response, indicating how the proposed solution will meet the technical requirements across several categories including general technology, enabling technology, online portal, application security, reporting, and system interfaces. The project seeks a comprehensive, cloud-based licensing and regulatory software solution along with implementation, maintenance, and related services.
The project involves the State of Texas, specifically Travis County and the City of Austin. The solicitation does not specify a response due date, but offerors must comply with all requirements outlined in the workbook and return the completed document in Excel format. The contract term is not explicitly stated. Pricing details, funding information, and incumbent details are not provided in this technical requirements document.
View the file
Other files
Show 40 more
50 files listed here. See the rest on GovTribe.
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
Title Page
| Texas Department of Licensing and Regulation (TDLR) |
| Replacement of Legacy Licensing Systems Replacement Project |
| Attachment D. Technical Requirements Response Workbook |
Instructions
| Texas Department of Licensing and Regulation (TDLR) |
| Replacement of Legacy Licensing Systems Replacement Project |
| Attachment D. Technical Requirements Response Workbook |
| Instructions |
Offeror shall complete and submit this Technical Requirements Response Workbook with the proposal response.
For each requirement, the Offeror should indicate which of the following three options will be used to meet the requirement:
1. Production Configuration, Business Rule Automation, Both, or None (C, A, B, N) - Use this column to indicate that the requirement is met by the proposed solution through (C)onfiguration, (A)utomation, (B)oth, or (N)one. If None is selected, indicate if the requirement can be met with the remaining two options.
2. Product Customization (Y, N) - Use this column to indicate that the proposed solution meets the requirement through product customization and/or custom developed code. Provide additional details on your response in the Explanation or Comments column.
3. Integration with 3rd Party Product (Y, N) - Use this column to indicate that the requirement can only be met through the use and integration with a 3rd party product or solution. Identify the proposed 3rd party product under the Explanation or Comments column.
Note:
1. Offeror must address all requirements included in this Technical Requirements Response Workbook, including those marked as (R)equired or (O)ptional.
2. Offeror must return the document to TDLR in excel format.
XXXX Z1 Appendix B: CAMP Technical Requirements
Page &P
Table of Contents
| Table of Contents |
| Texas Department of Licensing & Regulation (TDLR) |
| Replacement of Legacy Licensing Systems Replacement Project |
| Attachment D. Technical Requirements Response Workbook |
| Category (Tab) | # of Requirements | ||
| Mandatory | Optional | Total | |
| A. General Technology | 26 | 2 | 28 |
| B. Enabling Technology | 12 | 1 | 13 |
| C. Online Portal | 18 | 3 | 21 |
| D. Application Security | 47 | 1 | 48 |
| E. Reporting | 7 | 0 | 7 |
| F. Systems - Interfaces | 3 | 0 | 3 |
| Total | 113 | 7 | 120 |
A. General Technology
| ID | Type | Requirement | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | ||
| A | 1 | Database | The Solution shall utilize a relational database management system (RDBMS) and support Structured Query Language (SQL) capabilities. | M | |||||
| A | 2 | Database | The Solution database shall provide logical separation of configuration tables from data tables. | M | |||||
| A | 3 | Database | The Solution shall support an online data dictionary and table relationships that describe and maintain information on each data element including data element name and type, PII data, description of the data element, and the format of each data element. | M | |||||
| A | 4 | Infrastructure | The Solution shall provide a flexible and scalable solution that is compliant within TDLR technical architecture guidelines (e.g., security, platform, network, web, etc.). | M | |||||
| A | 5 | Infrastructure | The Solution shall run on an industry standard operating system and provide connectivity to the Agency's systems, as necessary. | M | |||||
| A | 6 | Infrastructure | The Solution must be capable of sending and receiving email or integrating with a third-party email service. | ||||||
| (TDLR is open to exploring vendor capabilities regarding this functionality. If necessary, the solution must be able to integrate with third-party solutions like AWS Simple Email Service, Azure Communication Services, etc.) | M | ||||||||
| A | 7 | Infrastructure | The Solution shall be a web-based application with logical and physical separation of the presentation, business logic, and data layers. | M | |||||
| A | 8 | Infrastructure | The Solution shall provide an extensible data model and user interface that is configurable. | M | |||||
| A | 9 | Infrastructure | The Vendor shall install or provide multiple environments to support the development lifecycle which at a minimum includes development, staging, training, and production environments. | M | |||||
| A | 10 | Maintainability | The Solution shall support upgrade capability that allows TDLR to upgrade to the latest version of the vendor’s product without requiring TDLR staff to reconfigure the Solution. | M | |||||
| A | 11 | Maintainability | The Solution shall employ data quality assurance techniques, including but not limited to: input masks, drop down lists with standard responses, application completeness requirements, data validation logic. | M | |||||
| A | 12 | Maintainability | The Solution shall utilize naming conventions and standards, at a minimum, for data elements, entities and tables, programs, report names based on industry standards and guideline. | M | |||||
| A | 13 | Maintainability | The Solution shall support configuration modifications to change functionality and associated business rules (requiring minimal coding). | M | |||||
| A | 14 | Maintainability | The system screens shall be re-configurable, providing the ability to reposition and rename field labels, remove or “turn-off” unused fields, maintain data, and allow the addition of custom-defined fields based on user security profiles. | O | |||||
| A | 15 | Maintainability | The Solution shall provide the ability to configure and manage business data validation rules. | M | |||||
| A | 16 | Maintainability | The Solution configuration shall be managed through a graphical user interface. | M | |||||
| A | 17 | Maintainability | The Solution workflows shall be managed through a business process flow tool. | O | |||||
| A | 18 | Maintainability | The Solution shall provide the ability to identify configuration differences between two environments, and migrate or sync environments (e.g., promote configurations from development to test environments). | M | |||||
| 19 | Performance | The Solution shall track and display system uptime, and transaction response times to demonstrate that the Solution is operating within acceptable levels. | M | ||||||
| A | 20 | Performance | The Solution shall have the ability to support a 99.9% availability — excluding planned maintenance (if a hosted environment is proposed). | M | |||||
| A | 21 | Performance | The Solution shall have the ability to meet the System Recovery Time Objective (RTO) based on NextGen DR Class 4 (no more than 48 hours). This is the maximum time that the Solution can be offline before services are restored to end users. | M | |||||
| A | 22 | Performance | The Solution shall have the ability to meet the Recovery Point Objective (RPO) based on NextGen DR Class 4 (no more than 48 hours). | M | |||||
| A | 23 | Performance | The Solution shall be able to recover transaction information within a 15 minute time interval. | M | |||||
| A | 24 | Performance | The Solution shall be able to support 125 concurrent staff users who will perform ad-hoc real-time reports. | M | |||||
| A | 25 | Performance | The Solution shall be able to support 125 concurrent staff users who will run standard report requests. | M | |||||
| A | 26 | Performance | The Solution shall be able to support 330 concurrent customers accessing the public portal. | M | |||||
| A | 27 | Performance | The Solution shall support an initial staff user base of 426 users with an annual growth rate of 5%. | M | |||||
| A | 28 | Performance | The Solution shall support an initial customer user base of 919,000 active licensure base with an annual growth rate of 3 - 6%. | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | |||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Conversion | |||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 26 | ||||
| Total Optional Requirements | 2 | ||||
| Total Requirements | 28 |
B. Enabling Technology
| ID | Type | Requirement | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | |
| B | 1 | Configuration | The Solution shall use configurable “number schemes” to uniquely and consistently identify data records (e.g., customer, application, etc.) through the process that spans across multiple programs. | M | ||||
| B | 2 | Configuration | The Solution shall be capable of easily adapting the workflow configuration to business needs (e.g., business rules, fee structures) through a change in configuration settings. | M | ||||
| B | 3 | Configuration | The Solution shall provide workflow alerts to staff and applicant based upon process time settings defined by TDLR. | M | ||||
| B | 4 | Configuration | The Solution shall provide configurable processes and rule automation to support the application processing by using a consistent set of rules across the organization that are defined once and shared by both customer and staff portals. The Solution shall also support updating or modifying these rules/processes to meet regulatory or legal changes as necessary. | M | ||||
| B | 5 | Communications | The Solution shall support sending outgoing SMS messages from TDLR to support the Functional Requirements. | M | ||||
| B | 6 | GIS | The Solution shall support GIS capabilities, such as displaying data on a map that is stored in the system | M | ||||
| B | 7 | Electronic Document Management System (EDMS) | The Solution shall have built-in viewers/converters for a wide variety of file types such as, but not limited to Word, Excel, images, PDFs. | M | ||||
| B | 8 | Electronic Document Management System (EDMS) | The Solution shall have the ability to support acceptance of file attachments via the web portal. | M | ||||
| B | 9 | Electronic Document Management System (EDMS) | The Solution shall support records management in accordance with TDLR retention policies | M | ||||
| B | 10 | Electronic Document Management System (EDMS) | The Solution shall support and handle documents with no maximum file size limits. TDLR shall have the ability to define the maximum file size. | O | ||||
| B | 11 | Electronic Document Management System (EDMS) | The Solution shall be able to ingest documents in support of licensing and education processes while providing mechanisms to transfer files necessary for data sharing with industry and other agencies. | M | ||||
| B | 12 | KPI | The Solution shall provide workflow-based metrics to be used in Key Performance Indicators (KPIs). | M | ||||
| B | 13 | KPI | The Solution shall provide configurable dashboards to display KPIs by, at a minimum program, license type, TDLR role or individual, such as licenses approved per day. | M | ||||
| B | 14 | Digital signature | The Solution shall support digital signatures. | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | 0 | ||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 12 | ||||
| Total Optional Requirements | 1 | ||||
| Total Requirements | 13 |
C. Online Portal
| ID | Type | Requirement | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | |
| C | 1 | Configuration | The Solution shall provide out-of-the-box web components that allow TDLR to configure the layout for the web portal. | M | ||||
| C | 2 | Configuration | The Solution shall allow the customer to configure their view and save preferences. | O | ||||
| C | 3 | Configuration | The customer web portal shall support robust search capabilities to locate information or data records quickly. | M | ||||
| C | 4 | Configuration | The Solution shall have online documentation, interactive help, and training materials available for users to assist them in navigating the portal. | M | ||||
| C | 5 | Configuration | The Solution shall provide TDLR-configurable error messages specifying field and error descriptions when business validation rules are not met. | M | ||||
| C | 6 | Configuration | The Solution shall allow users to set display preferences such as language, font size, and colors to improve application usability/accessibility. | O | ||||
| C | 7 | Configuration | The Solution shall support the ability to display system-wide messages throughout the customer web portal without code changes, such as alerting users of planned downtime. | M | ||||
| C | 8 | General | The Solution's Online Portal shall integrate with the TDLR website such that common branding is applied, and instructions and other informational data can be contained on either the TDLR web site, or the system's online portal. | M | ||||
| C | 9 | General | The customer web portal shall be developed employing best practices for web design and development technologies. | M | ||||
| C | 10 | General | The customer web portal shall provide consistent site navigation. | M | ||||
| C | 11 | General | The Solution shall provide spell checking functionality of free-form text fields. | M | ||||
| C | 12 | General | The Solution shall a provide clear navigation path that describes or illustrates where the user is located within the web portal (e.g., breadcrumbs, heading titles, etc.). | M | ||||
| C | 13 | General | The Solution shall utilize AI or wizards to guide users to the appropriate application type for their needs and guide them through the process to complete the application if needed. | M | ||||
| C | 14 | General | The Solution shall provide the ability for the user to perform data entry tasks that minimize the use of a mouse (or pointing) device (e.g., tab sequencing of fields). | M | ||||
| C | 15 | General | The Solution shall provide responsive design to support multiple display form factors (e.g., mobile devices, desktop displays, etc.) | M | ||||
| C | 16 | General | The Solution shall provide the ability to save/exit an application at any point in the application submission process. | M | ||||
| C | 17 | General | The Solution shall provide collaborative web browsing capability that allows staff to review the application as the customer completes it online. | O | ||||
| C | 18 | General | The Solution shall maintain customer web portal configurations and also provide backward compatibility after a product upgrade. | M | ||||
| C | 19 | General | The customer web portal shall support all of the latest (and all versions acceptable to security) desktop and mobile browsers (e.g., Edge, Firefox, Chrome, Safari, etc.). | M | ||||
| C | 20 | General | The customer web portal shall be fully integrated with the license system and not use separate databases or batch synchronizing processes. | M | ||||
| C | 21 | General | The customer web portal shall be ADA WCAG 2.0 and Section 508 compliant. | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | 0 | ||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 18 | ||||
| Total Optional Requirements | 3 | ||||
| Total Requirements | 21 |
D. Application Security
| ID | Type | Requirement | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | |
| D | 1 | Authentication | The Solution shall require user authentication before the user can access certain business functions. | M | ||||
| D | 2 | Authentication | The Solution shall allow users the ability to perform certain business functions including, but not limited to: review statuses, comments, etc. without logging into the system according to TDLR-configured business rules. | M | ||||
| D | 3 | Authentication | The Solution shall be able to authenticate TDLR users via integration with TDLR's active directory | M | ||||
| D | 4 | Authentication | The Solution shall be able to authenticate external users through a system generated username and password, and maintain the user account | M | ||||
| D | 5 | Authentication | The Solution shall be able to authenticate users via integration with the Texas by Texas (TxT) active directory environment. | M | ||||
| D | 6 | Authentication | The Solution shall enforce TDLR password policies. | |||||
| M | ||||||||
| D | 7 | Authentication | The Solution shall utilize Two-Factor Authentication (2FA) for internal users. | M | ||||
| D | 8 | Authentication | The Solution shall not store any user credential information; users must enter credentials each time, or gain access through a Single Sign On (SSO) feature. | M | ||||
| D | 9 | Authentication | The Solution shall support policies and procedures for handling login issues (e.g., automatically inform the customer to reset the password after a certain number of incorrect attempts). | M | ||||
| D | 10 | Authentication | The Solution shall support user profiles that allow users to configure and save their system preferences to their profile (e.g., user information, notification preferences, screen/table views, etc.). | M | ||||
| D | 11 | Authentication | The Solution shall not use "generic" user accounts, such as a superuser account not tied to an individual. | M | ||||
| D | 12 | Configuration | The Solution shall allow data to be classified as sensitive or confidential information. | M | ||||
| D | 13 | Configuration | The Solution shall provide the ability to mask input fields for sensitive or confidential information. | M | ||||
| D | 14 | Error Handling | The Solution shall provide minimal error information in the event of authentication failure (e.g., “login fail” instead of “user not found” or “password incorrect”). | M | ||||
| D | 15 | Error Handling | The Solution shall provide a protective measure to prevent, detect, and log unauthorized attempts to access the system (e.g., # of invalid login attempts). | M | ||||
| D | 16 | Error Handling | The Solution shall minimize exception handling information disclosure in case of an exception. | M | ||||
| D | 17 | Error Handling | The Solution shall return generic error messages to the client, to avoid disclosure of sensitive information. | M | ||||
| D | 18 | Error Handling | The Solution shall provide a graceful error-handling process that does not rely on internal server error handling process (e.g., IIS, Windows OS). | M | ||||
| D | 19 | Error Handling | The Solution shall log all errors that include severity, date/time, error description, and error codes. | M | ||||
| D | 20 | Error Handling | The Solution shall provide the ability to clear all system error logs according to business rules and authorized users. | M | ||||
| D | 21 | Error Handling | The Solution shall provide notifications (e.g., email, text, etc.) to assigned administrators for configurable severity error levels. | O | ||||
| D | 22 | Error Handling | The Solution shall have the ability to prevent, detect, and log unauthorized attempts to access information classified as sensitive or confidential data. | M | ||||
| D | 23 | Auditing | The Solution shall provide configurable audit logging on transactions and activities a user may perform, and must provide that information to Splunk to export the logs via an interface. | M | ||||
| D | 24 | Auditing | The Solution shall track and display user activities, and display an audit trail | M | ||||
| D | 25 | Auditing | The Solution shall maintain an audit log of changes to information contained in records. | M | ||||
| D | 26 | Auditing | The Solution shall, at a minimum, include the following attributes for each audit log record: IP address, user account ID, date/time stamp, event source, device/browser information, the outcome of an event (success or failure), and any other supplemental information related to the event. | M | ||||
| D | 27 | Auditing | The Solution shall provide the ability to send notifications (e.g., email, text) based on configurable audit log activity (e.g., system usage exceeds a certain threshold). | M | ||||
| D | 28 | Auditing | The Solution shall prevent unauthorized modifications or deletions of audit log records. | M | ||||
| D | 29 | Auditing | The Solution shall provide reporting capability to query for audit log records matching specific criteria (e.g., audit logs for a specific user between certain dates). | M | ||||
| D | 30 | Reporting | The Solution shall provide canned reports such as error and exception reports, usage reports, etc. | M | ||||
| D | 31 | Infrastructure | The Solution shall support session management across a web server load balanced environment. | M | ||||
| D | 32 | RBAC | The Solution shall support role-based access control (RBAC) in managing user permissions. | M | ||||
| D | 33 | RBAC | The Solution shall provide granular access control to different types of data records based on the following permissions: |
- Read
- Write
- Modify
| - Delete | M | ||||
| D | 34 | RBAC | The Solution shall support hierarchal user management, i.e., department-specific administrators can manage user groups and user accounts in their purview. | M | |
| D | 35 | RBAC | The Solution shall allow TDLR users to have multiple roles in the system based on the division assigned. | M | |
| D | 36 | RBAC | The customer web portal shall support multiple access authorization levels for different users, user groups, or roles. | M | |
| D | 37 | General | The Solution shall comply with the Texas Cyber Security Framework controls and all applicable state laws. | M | |
| D | 38 | General | The Solution shall ensure database access through security privileges associated with system managed identities. | M | |
| D | 39 | General | The Solution shall not pass session identifiers in plain-text. | M | |
| D | 40 | General | The Solution shall not store any private or sensitive data in the error logs (e.g., passwords). | M | |
| D | 41 | General | The Solution shall encrypt any data classified as sensitive or confidential. | M | |
| D | 42 | General | The Solution shall not store customer financial information. | M | |
| D | 43 | General | The Solution shall not store database connection information, passwords, and any other sensitive credentials in plain text. | M | |
| D | 44 | General | The Solution shall support scanning of files for viruses and malware. | M | |
| D | 45 | General | The Solution shall allow an administrator to disable a user account. | M | |
| D | 46 | General | The customer web portal shall ensure temporary objects are removed from the system, database connections are closed, and memory is released. | M | |
| D | 47 | General | The customer web portal ensures all input parameters are validated (including form fields, query strings, cookies, and HTTP headers). | M | |
| D | 48 | General | The Solution shall support public certificates and pass all data over TLS (minimum of TLS 1.2). | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | 0 | ||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 47 | ||||
| Total Optional Requirements | 1 | ||||
| Total Requirements | 48 |
E. Reporting
| ID | Type | Requirement | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | |
| E | 1 | General | The Solution shall support configurable dashboards that may be used to display analytics for different users or user groups (e.g., customer, field staff, etc.). | M | ||||
| E | 2 | General | The Solution shall provide built-in ad-hoc reporting capabilities (e.g., the ability to run reports within the system with report parameters automatically passed to the report (if applicable)). | M | ||||
| E | 3 | General | The Solution shall allow staff to drill into detailed data by clicking on an application or business license number. | M | ||||
| E | 4 | General | The Solution shall support scheduled reports that are sent to specific users or user groups. Reports shall support multiple formats including PDFs, Excel, Word, CSV, XML, etc. | M | ||||
| E | 5 | General | The Solution shall provide data export functionality to external data sources for all data stored in the system (e.g., export to Excel). | M | ||||
| E | 6 | General | The Solution shall allow TDLR staff to access the database and perform database queries in real time | M | ||||
| E | 7 | General | The Solution shall fully support and integrate with industry standard reporting platforms. | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | 0 | ||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 7 | ||||
| Total Optional Requirements | 0 | ||||
| Total Requirements | 7 |
F. Systems-Interfaces
| ID | Type | Requirement | (I)nterface, (R)eplace, (E)ither | Real-Time or Batch | One-Way or Two-Way | (M)andatory or (O)ptional | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Comments | |
| F | 1 | General | The Solution shall be capable of integrating using standards-based, web services. | M | |||||||
| F | 2 | General | The Solution shall be capable of uploading data sets such as exam results. | M | |||||||
| F | 3 | General | The customer web portal shall provide and support RESTful web services or custom API's that provide secure connection and logging. | M |
| Tab Statistics (hide before publishing) | |||||
| Yes Responses | 0 | 0 | 0 | ||
| No Responses | 0 | 0 | 0 | ||
| Configuration | 0 | ||||
| Business Automation | 0 | ||||
| Both | 0 | ||||
| Total Mandatory Requirements | 3 | ||||
| Total Optional Requirements | 0 | ||||
| Total Requirements | 3 |
File details come from the government source that posted it. Updated .