attachment_2_RFP DOS 2026-02.xlsx

Instructions

Criticality Column:

(M) Indicates a requirement that is "Mandatory". The State considers it to be of such great importance that it must be met in order for the proposal to be accepted. If the proposer believes that there is something about their proposal that either obviates the need for this requirement or makes it of less importance this must be explained within the comments. The State retains the right to accept a proposal if the need of the requirement is reduced or eliminated by another feature of the proposal.

(P) Indicates a requirement which is "Preferred". This requirement is considered by the State to be of great usefulness but the lack of this feature is not considered serious enough to disqualify the proposal.

(O) Indicates a requirement which is "Optional". This requirement is considered by the State to be one which useful or potentially useful but not a central feature of the Project.

Delivery Method Column:

Complete the delivery method using a Standard, Future, Custom, or Not Available/Not Proposing (as defined below) that indicates how the requirement will be delivered.

Standard - Feature/Function is included in the proposed system and available in the current software release.

Future - Feature/Function will be available in a future release. (Provide anticipated delivery date, version, and service release in the comment area.)

Custom - Feature/Function can be provided with custom modifications. (Respondent must provide estimated hours and average billing rate or flat cost for the software modification in the comment area. These cost estimates should add up to the total cost for software modifications found in the cost summary table in Section X of the RFP).

Not Available/Not Proposing - Feature/Function has not been proposed by the Vendor. (Provide brief description of why this functionality was not proposed.)

Comments Column:

For all Delivery Method responses vendors must provide a brief explanation of how the requirement will be met. Free form text can be entered into this column.

Requirements

• SELECT field(s) or attribute(s), in conjunction with aggregate functions of attribute(s)

• FROM any given data table(s) - crash tables and non-crash tables

• WHERE specified attribute(s) have a specified value or range of values selected by the user

• ORDERED BY specified attribute(s) in ascending or descending order

• GROUPED BY specified attribute(s)

• Having the result of the aggregate function satisfy some criteria Examples of Pre-built toolboxes:

• "Summarize crashes" grouped by the attribute "crash type" for the entire roadway network, excluding crashes at intersections; "Summarize crashes" could mean summing total number of crashes over x-number of years, calculating average crash frequency (#crashes per 100-million vehicle miles of travel) for roadway segments over x-number of years, or calculating average crash rate (#crashes per 10-million entering vehicle) for roadway intersections over x-number of years

• Above example but only for crashes located at intersections

• Above example but only for a paticular route system designation (e.g. U.S. Highway) or only for roadways with a specified number of lanes

• Select the top x% of y-mile long sections of roadway (excluding intersections) in the entire network with the highest Annual Crash Rate

• Find crash clusters or hot-spots within a user-specified segment length along a roadway(s), capable of specifying either a floating window that slides along a route at a given increment or specifying a fixed window

• Find crashes within a specified radius around a designated feature type such as rail at-grade crossings for the entire roadway network or subsets of the network Manual SQL Command-Line option - user-supplied SQL statements:

• the ability to graphically select roadway locations/areas for analysis via graphical circular-radius selection tool or "polygon" selection tool

• CCTV Snapshots and Camera Status

• DMS Messages

• Environment Sensor Data (Road temperature, precipitation, etc.)

• Incidents (hard braking, road construction, etc.)

• Lane Closures

• Network Information (Travel Times and Roadways)

• Travel Conditions

• Travel Times

• Traffic Incidents

The following vulnerability remediation timeframe applies for Internet-accessible systems:

1. Critical: Immediately upon availability of patch.

2. High vulnerabilities: 15 calendar days from vulnerability publication date.

3. Medium vulnerabilities: 30 calendar days from vulnerability publication date.

4. Low vulnerabilities: 90 calendar days from vulnerability publication date.

o Class A Deficiency - Software - Critical, does not allow System to operate, no work around, demands immediate action; Written Documentation - missing significant portions of information or unitelligible to State; Non-Software - Services were inadequate and require re-performance of the Service.

o Class B Deficiency - Software - important, does not stop operation and/or there is a workaround and user can perform tasks; Written Documentation - portions of information are missing but not enough to make the document unitelligible; Non-Software - Services were deficient, require reworking, but do not require re-performance of the Service.

a. Class A Deficiencies - The vendor shall have available to the State on-call telephone assistance, with issue tracking available to the State, eight (8) hours per day and five (5) days a week with an email / telephone response within two (2) hours of request; or the vendor shall provide support onsite or with remote diagnostic services within four (4) business hours of a request;