attachment_1_RFP DOIT 2025-036.xlsx
XLSX spreadsheet 103 KB Posted
- Attached to
- Traffic Data Management System (TDMS)
- Solicitation number
- RFP DOIT 2025-036
- Issued by
- Rockingham County, New Hampshire
About this file
This file is a requirements document containing detailed technical specifications for the New Hampshire Department of Transportation's (NHDOT) Traffic Data Management System (TDMS). The document outlines comprehensive requirements for a commercial off-the-shelf (COTS) web-based solution that will process and report traffic data, including tools for compiling individual vehicle records, 5-minute, 15-minute, hourly, daily, monthly, and year-end processes. The system must accommodate 300 authorized users plus unlimited public access users, support mobile device access, and handle data from a minimum of 8,500 traffic monitoring stations. Key capabilities include processing continuous count data, short-term count data, micromobility count data, volume data, classification data, weigh-in-motion data, speed data, gap data, and length data.
The solution must integrate with ESRI products, comply with FHWA Traffic Monitoring Guide requirements, AASHTO guidelines, and HPMS requirements. The system requires three environments (Development, Test, and Production), must provide data archiving capabilities for 20 years of data, and support storage for 1.5 billion continuous count IVRs and 300 million short count IVRs annually. The document includes extensive requirements around data validation, quality control, reporting capabilities, system administration, and integration with nine Metropolitan Planning Organizations and Regional Planning Commissions. The system must also support importing data from multiple vendor devices including Oriux, Jamar Technologies, Diamond Traffic Products, Quarterhill, Wavetronix, Metrocount USA, CLR Analytics, Leetron Vision, Cubic Transportation Systems, and Miovision Technologies.
View the file
Other files
Show all 47
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
Table B-2.1
| BUSINESS REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| GENERAL APPLICATION REQUIREMENTS | |||||
| B1.1 | The Proposed Solution shall include an automated traffic database for processing and reporting traffic data with a web based application that can provide tools for compiling individual vehicle records (IVR), 5-minute, 15-minute, hourly, daily, monthly, year-end processes, and multi-year analysis. | M | |||
| B1.1.1 | The Proposed Solution shall accommodate concurrent use of the system, including a minimum of 300 Authorized Users and an unlimited number of read-only public access users. | M | |||
| B1.1.2 | The Proposed Solution shall be mobile device-friendly and allow access to the system from the field. | O | |||
| B1.1.3 | The Proposed Solution should be interactive within 10 seconds on mobile networks. | O | |||
| B.1.1.4 | The Proposed Solution shall include an intuitive User Interface (UI) that allows all users to navigate the system easily. The Proposed Solution shall use clear labels, have a logical organization of functions, and provide visual cues to guide users through the application. | M | |||
| B.1.1.5 | The Proposed Solution UI should provide a consistent layout across modules and/or follow-on screens. | E | |||
| B1.2 | The Proposed Solution shall be a commercial, off the shelf (COTS) product with minimal customization and configuration required by this RFP and by NHDOT. | M | |||
| B1.2.1 | The Vendor shall define system baseline functionality of the COTS Proposed Solution and the implementation and customization process. | M | |||
| B1.2.2 | The Vendor shall identify and define optional modules that are available for future implementation. | E | |||
| B1.3 | The Proposed Solution shall be a hosted software solution. | M | |||
| B1.4 | The Proposed Solution shall process and store continuous count data, short-term count data (AKA coverage counts), and micromobility count data including volume, classification, weigh-in-motion, speed, gap, and length data as applicable. | M | |||
| B1.4.1 | The Proposed Solution shall process and store all raw data for short counts, continuous counts, and micromobility counts based on site/location, volume, classification, speed, Weight in Motion (WIM) including individual vehicle records (IVR). | M | |||
| B1.4.2 | The Proposed Solution shall process and store all edited data for short counts, continuous counts, and micromobility counts based on site/location, volume, classification, speed, WIM including IVRs. | M | |||
| B1.5 | The Proposed Solution shall provide tools to analyze, query, access, and utilize traffic data for NHDOT’s internal customers as well as external customers and display the information using mapping interface. | M | |||
| B1.6 | The Proposed Solution must conform to the current edition of FHWA TMG requirements, American Association of State Highway Officials (AASHTO) guidelines for Traffic Data Programs, and FHWA Highway Performance Monitoring System (HPMS). | M | |||
| B1.6.1 | The Proposed Solution shall provide export capabilities to support the current version of FHWA TMAS system, HPMS Manual, and Mechanistic-Empirical Pavement Design Guide. | M | |||
| B1.6.2 | The Proposed Solution shall export to Station Card (S-Card). | M | |||
| B1.6.3 | The Proposed Solution shall export to Volume Card (V-Card). | M | |||
| B1.6.4 | The Proposed Solution shall export to Classification Card (C-Card). | M | |||
| B1.6.5 | The Proposed Solution shall export to Weight Card (W-Card). | M | |||
| B1.6.6 | The Proposed Solution shall shall have the ability to export Individual Vehicle Records (IVR). | M | |||
| B1.7 | The Proposed Solution shall include procedures for manually adding, deleting, and editing data for individual counts and traffic count locations (stations). | M | |||
| B1.8 | The Proposed Solution shall provide database management tools for the storage, modification, importing and extraction of traffic data. | M | |||
| B1.9 | The Proposed Solution shall allow NHDOT to maintain control over data, data quality, processing, calculations and reporting through the data's lifecycle. | M | |||
| B1.10 | The Proposed Solution shall provide a map interface for viewing stations intended for processing and analysis tasks. | M | |||
| B1.11 | The Proposed Solution shall provide a minimum of three environments. | ||||
| M | |||||
| B1.11.1 | The Proposed Solution shall include a Development environment. | M | |||
| B1.11.2 | The Proposed Solution shall include a Test environment. | M | |||
| B1.11.3 | The Proposed Solution shall include a Production (Operations) environment. | M | |||
| B1.12 | The Proposed Solution shall have a public-facing system and an internal-facing system. | M | |||
| B1.12.1 | The Proposed Solution shall have a configurable web-based UI. | M | |||
| B1.12.2 | The public-facing system shall include a Public User Interface and a Partner User Interface. | M | |||
| B1.12.3 | The Proposed Solution Public UI shall be web-based. | M | |||
| B1.12.4 | The Proposed Solution Partner UI shall be web-based. | M | |||
| B1.12.5 | The Proposed Solution Office UI shall be web-based. | M | |||
| B1.12.6 | The Proposed Solution shall have rules-based access controls for a minimum of five (5) access levels. | E | |||
| B1.13 | The Proposed Solution shall support maintenance of raw data and traffic statistics for a minimum of 8,500 traffic monitoring stations | M | |||
| B1.13.1 | The Proposed Solution shall be capable of importing data from a multitude of different devices, manufacturers and data formats. | M | |||
| B1.13.2 | The Proposed Solution shall accept data from the Bureau of Turnpike system software. | E | |||
| B1.13.3 | The Proposed Solution shall support near real-time data feeds. | O | |||
| B1.13.4 | The Proposed Solution shall allow for data within any portion of the system to be shared across all subsystems. | E | |||
| B1.14 | The proposed solution shall comply with the New Hampshire Statewide Information Security Manual (SISM) published by the New Hamsphire Department of Information Technology (NHDoIT), latest edition. | M | |||
| B1.14.1 | The Proposed Solution shall operate at 'Baseline-Plus' per the SISM. | E | |||
| B1.15 | The Proposed Solution shall be configurable to allow the State to control what data is sent to third parties. | M | |||
| B1.16 | The Proposed Solution shall upload data in standard formats as required by the current edition of the FHWA TMG for reporting to the TMAS. | M | |||
| B1.17 | The Proposed Solution shall be an open architecture product that utilizes Application Programming Interfaces (APIs) to integrate and reuse software functionality from existing device and system implementations. | E | |||
| B1.18 | The Proposed Solution shall provide a data exchange service for translation and standardization of TDMS data to external sources. | E | |||
| B1.19 | The Proposed Solution shall provide network redundancy by assuring redundant connections provided by multiple Internet Vendors so that a failure of one Internet connection will not interrupt access to the software application. | E | |||
| B1.20 | The Proposed Solution shall include a baseline database schema of relational databases including an Entity-relationship diagram. | E | |||
| B1.21 | The Vendor’s network architecture must include redundancy of routers and switches in the Data Center. | E | |||
| HARDWARE REQUIREMENTS | |||||
| B2.1 | The Proposed Solution shall utilize only Internet and Industry standards and protocols to support data exchange; it will not require specific hardware. | M | |||
| B2.2 | The Proposed Solution documentation shall identify and define baseline configurations of any network connected devices, including existing and newly implemented devices and equipment. | E |
| SOFTWARE REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| GENERAL SPECIFICATIONS | |||||
| C1.1 | The NHDOT shall maintain ownership of all data provided to and associated with the proposed system. | M | |||
| C1.1.1 | The Proposed Solution shall allow unrestricted access to NHDOT for all data contained within the system at all times | M | |||
| C1.2 | The Proposed Solution shall generate traffic monitoring statistics using the methodologies specified in the following reference documents with the flexiblity to modify as the guidance in the reference documents evolves. | M | |||
| C1.2.1 | The Proposed Solution shall generate traffic monitoring statistics in accordance with the Traffic Monitoring Guide (TMG) (FHWA 2022). | M | |||
| C1.2.2 | The Proposed Solution shall generate traffic monitoring statistics in accordance with the Guide for Traffic Data Programs (AASHTO 2009) | M | |||
| C1.2.3 | The Proposed Solution shall generate traffic monitoring statistics in accordance with the Highway Performance Monitoring System Field Manual (FHWA 2016) | M | |||
| C1.2.4 | The Proposed Solution shall generate traffic monitoring statistics in accordance with the AASHTO Mechanistic-Empirical Pavement Design Guide, 3rd Edition with 2021 Supplement. | M | |||
| C1.3 | The Proposed Solution shall be scalable without requiring data to be archived. | M | |||
| C1.3.1 | The Proposed Solution shall include provisions for archiving at NHDOT's discretion. | E | |||
| C1.4 | The Proposed Solution shall support the collection, analysis, and storage of temporal traffic data for a minimum period of twenty years. | M | |||
| C1.4.1 | The Proposed Solution shall maintain comprehensive logs of data collection activities. This includes recording information such as the data source, collection time, quality metrics, and any relevant events or errors encountered during the collection process. | E | |||
| C1.5 | The Proposed Solution shall allow Authorized Users to export data in a format that the Proposed Solution can later import. This feature is used for backing up data, transferring data between different systems, or for users who want to manipulate the data using 3rd party tools. | E | |||
| C1.6 | The Proposed Solution shall transform incoming metadata and batch information into a standard format that can be managed by the System. | E | |||
| C1.7 | The Proposed Solution shall be able to have configurable data import methods based on device or user group. | E | |||
| C1.8 | The Proposed Solution shall accommodate and schedule data collection from the nine Metropolitan Planning Organization (MPOs) and Regional Planning Commissions (RPCs). See also Requirements F11.1-F11.4. | M | |||
| C1.9 | The Proposed Solution shall accept and process raw data files provided by Partners, including other State Department of Transportations (DOTs). | E | |||
| C1.10 | The Proposed Solution documentation shall include and define baseline configurations of Solution authorizations and Solution email notifications. | M | |||
| C1.11 | The Proposed Solution shall operate on a statewide license, available to NHDOT and all Partner agencies as dictated by NHDOT. | M | |||
| C1.12 | The initial deployment of the Proposed Solution shall operate using the most current software version available from the Vendor. | E | |||
| C1.13 | The Proposed Solution shall support map symbolization with unique symbols. | E | |||
| C1.14 | The Proposed Solution shall support printing or saving reports. | M | |||
| C1.15 | All Proposed Solution software shall be free of malicious code. | M | |||
| C1.16 | The Proposed Solution documentation shall define the Proposed Solution's licensing agreement and baseline usage and availability. | M | |||
| C1.17 | The Proposed Solution documentation shall identify and define baseline NTCIP configurations of the Proposed Solution. | E | |||
| C1.18 | The Proposed Solution documentation shall include baseline configurations of all incoming and outgoing schemas. | E | |||
| APPLICATION SECURITY | |||||
| C2.1 | The Proposed Solution shall support at least five (5) access levels including: | E | |||
| C2.1.1 | Systems Administrator with full rights to all application functions. | ||||
| E | |||||
| C2.1.2 | Data Manager with full rights to all application functions except those reserved to the Systems Administrator(s). | ||||
| E | |||||
| C2.1.3 | Partner with read-write access to upload data. | ||||
| E | |||||
| C2.1.4 | Limited Access with read-only access and ad hoc report generation capabilities. | ||||
| E | |||||
| C2.1.5 | General Access for read-only access. | E | |||
| C2.1.6 | The Proposed Solution shall provide the same functionality according to user permissions, independent of the workstation from which the Authorized User accesses the software. | E | |||
| C2.2 | The Proposed Solution shall validate each command from a user for the proper privileges. | M | |||
| C2.3 | The Proposed Solution shall be configurable to enforce session timeouts when periods of inactivity, as defined in a configuration file, are reached. | E | |||
| SOFTWARE RELEASES AND ENHANCEMENTS | |||||
| C3.1 | The Proposed Solution install utility shall not scrub the database during installation of any new software releases as part of the installation. | E | |||
| C3.2 | The Vendor shall have an equipment driver update program. | E | |||
| C3.2.1 | The Vendor shall provide equipment driver updates according to the update program but not less than weekly. | E | |||
| C3.3 | The Proposed Solution shall not require client side installations to enable functionality and fixes that are implemented from server side installs and updates. | M | |||
| C3.4 | The Proposed Solution shall support contact notification of new versions/releases using email. | E | |||
| C3.5 | The Proposed Solution shall provide a Development environment for system patches and upgrades to be tested prior to roll out to Test and Production. | M | |||
| C3.5.1 | The Proposed Solution Development environment shall duplicate the Production environment to ensure product patches and tests are developed successfully in Development for easy transition to the Production environment. | E | |||
| C3.5.2 | All installations/updates will first be tested in the Development environment prior to being released into Test and then into Production. | E | |||
| C3.6 | The Proposed Solution shall accommodate updates to FWHA requirements through out the term of the contract. | M | |||
| C3.7 | The Vendor shall apply spatial data updates on a regular schedule as outlined in the SLA. | E | |||
| C3.7.1 | The Vendor shall apply LRS data updates automatically on a Annual basis. Changes shall be first applied to the Development environment, then tested in the Testing environment, prior to Production deployment. | E | |||
| DATA STORAGE | |||||
| C4.1 | The Proposed Solution shall have data archiving and report archiving capabilities. | E | |||
| C4.1.1 | All archived data shall be accessible upon request. The Vendor shall have a process for all archived data requests. | E | |||
| C4.1.2 | The Proposed Solution shall provide archiving of all data. | M | |||
| C4.1.3 | The Proposed Solution shall provide an archive service for performance measures. | E | |||
| C4.1.4 | The Proposed Solution shall provide an archive service for analysis and studies. | E | |||
| C4.1.5 | The Proposed Solution shall provide an archive service for planning and operations research. | E | |||
| C4.1.6 | The Proposed Solution shall be configurable to permit Authorized Users to input parameters regarding retention of historical data. | E | |||
| C4.2 | The Proposed Solution shall create and maintain a daily copy of all data in the system. | E | |||
| C4.3 | The Proposed Solution shall be able to upload and store the following | M | |||
| C4.3.1 | Count ID | M | |||
| C4.3.2 | Count GPS location | M | |||
| C4.3.3 | Count Time and Date | M | |||
| C4.3.4 | Count Crew Information | M | |||
| C4.3.5 | Counter Layout | M | |||
| C4.3.6 | Equipment Used to Capture the Count | M | |||
| C4.3.7 | Site Photos | E | |||
| C4.4 | All Count MetaData shall also be available for custom exporting. | E | |||
| C4.5 | The Proposed Solution shall manage data in a single repository with consistent formats. | E | |||
| C4.6 | The Proposed Solution shall support the following URL storage locations: | E | |||
| C4.6.1 | State ArcGIS REST endpoints | E | |||
| C4.6.2 | ArcGIS Online (AGOL) REST endpoints | E | |||
| C4.6.3 | AGOL REST feature layers | E | |||
| C4.6.4 | ArcGIS Enterprise Portal | E | |||
| C4.6.5 | Vendor's GIS services or portals | E | |||
| C4.7 | The Proposed Solution shall provide a standardized timestamp or date/time for data upon import. | E | |||
| C4.8 | The Proposed Solution shall aggregate raw collected traffic data into a maximum of 15 minute binned intervals. | E | |||
| C4.9 | The Proposed Solution shall aggregate 15 minute binned data into summary data for the following information at minimum: | E | |||
| C4.9.1 | Average Daily Traffic | E | |||
| C4.9.2 | Design Hourly Volume (DHV) | E | |||
| C4.9.3 | K Factor | E | |||
| C4.9.4 | D Factor | E | |||
| C4.9.5 | Percent Trucks | E | |||
| C4.9.6 | Average Speed | E | |||
| C4.10 | Binned data shall be sorted into data characteristics, by lane, to include the following characteristics: | E | |||
| C4.10.1 | Directional Volume | E | |||
| C4.10.2 | Classification Counts | E | |||
| C4.10.3 | Speed Data | E | |||
| C4.10.4 | Axle Count | E | |||
| C4.10.5 | Weight | E | |||
| C4.10.6 | Total Volume | E | |||
| C4.11 | The Proposed Solution shall allow Authorized Users the option to upload a minimum of three (3) photos for each permanent count location. | E | |||
| C4.12 | The Proposed Solution shall allow Authorized Users the option to upload a minimum of three (3) PDF documents for each permanent count location. | E | |||
| DATA MANAGEMENT AND QUERY | |||||
| C5.1 | The Proposed Solution shall allow authorized users to export in TMAS acceptable formats, NHDOT formats, FHWA file formats, PDFs, .xlsx & .csv files. | M | |||
| C5.2 | The Proposed Solution shall allow Authorized Users to move selected data between stations. | E | |||
| C5.3 | The Proposed Solution shall allow Authorized Users to create, edit, and purge continuous count site/location inventory information for equipment. | E | |||
| C5.4 | The Proposed Solution shall provide the ability to load and edit multiple file types simultaneously. | E | |||
| C5.5 | The Proposed Solution shall provide the ability to apply edits to all data types simultaneously. | E | |||
| C5.6 | The Proposed Solution shall allow Authorized Users to remove historical counts and recalculate statistics for any affected sites. | E | |||
| C5.7 | The Proposed Solution shall provide an estimated time to complete a query. | E | |||
| C5.7.1 | The estimated time shall include a user response to proceed, to cancel, or to postpone. | E | |||
| C5.7.2 | The estimated time shall be accurate to +/- 15 seconds. | E | |||
| C5.8 | The Proposed Solution shall provide access to raw data in the form of IVRs where available. | E | |||
| C5.9 | The Proposed Solution shall store the Traffic Count Site information using the following fields: | M | |||
| C5.9.1 | Station Identification Number | M | |||
| C5.9.2 | NHDOT District Number (1-6, T) | M | |||
| C5.9.3 | Regional Planning Commission | M | |||
| C5.9.4 | County Name, County FIPS code | M | |||
| C5.9.5 | Municipality Name | M | |||
| C5.9.6 | Municipality Type (County, City, Town, Unincorporated Place) | E | |||
| C5.9.7 | Geocode | E | |||
| C5.9.8 | Route Signing/Prefix (I, US, NH, Tpk) | M | |||
| C5.9.9 | Route Number / Road Number | M | |||
| C5.9.10 | Road Name | M | |||
| C5.9.11 | Begin description | M | |||
| C5.9.12 | End Description | M | |||
| C5.9.13 | Section Length | M | |||
| C5.9.14 | Bridge Identification Number (BIN) | E | |||
| C5.9.15 | Railroad Crossing ID | E | |||
| C5.9.16 | Linear Referencing System (LRS) ID | ||||
| E | |||||
| C5.9.17 | Roadway Functional Classification | M | |||
| C5.9.18 | Seasonal Factor Group (A-E) | M | |||
| C5.9.19 | Axle Factor Group | E | |||
| C5.9.20 | Change Factor Group | E | |||
| C5.9.21 | Number of primary direction lanes | E | |||
| C5.9.22 | Number of non-primary direction lanes | E | |||
| C5.9.23 | Latitude (Decimal Degrees) | M | |||
| C5.9.24 | Longitude (Decimal Degrees) | M | |||
| C5.9.25 | Roadway type | M | |||
| C5.9.26 | One way flag (Y/N) | E | |||
| C5.9.27 | Scheduled for collection flag (Y/N) | E | |||
| C5.9.28 | Active / In-active Site Flag | M | |||
| C5.9.29 | Provide five (5) User Defined Fields | M | |||
| C5.9.30 | Site Notes | M | |||
| C5.9.31 | Count Program or Project ID | E | |||
| C5.9.32 | Count Data Type | M | |||
| C5.9.33 | Equipment Type | E | |||
| C5.9.34 | Count Interval | M | |||
| C5.9.35 | Duration Attributes | E | |||
| C5.10 | The Proposed Solution shall allow fields for station sites to be added or deleted as necessary due to changes in NHDOT procedures. | E | |||
| C5.11 | The Proposed Solution shall maintain and designate retired stations (Stations IDs not currently used for collection but have historical data associated with them). | M | |||
| C5.11.1 | Retired Station IDs shall not be re-used for any new location. | M | |||
| C5.11.2 | Retired Station IDs shall not allow associated attributes to be edited. | E | |||
| C5.12 | The Proposed Solution shall be able to save and retain ad-hoc queries for future use. | E | |||
| C5.13 | The Proposed Solution shall provide the ability to query data from multiple sources by time period. | E | |||
| C5.14 | The Proposed Solution shall make traffic data available for reporting by highway segment. | E | |||
| C5.14.1 | The Proposed Solution shall make volume data available for reporting by highway segment. | E | |||
| C5.14.2 | The Proposed Solution shall make speed data available for reporting by highway segment. | E | |||
| C5.14.3 | The Proposed Solution shall make vehicle classification data available for reporting by highway segment. | E | |||
| C5.14.4 | The Proposed Solution shall make percentage of trucks data available for reporting by highway segment. | E | |||
| C5.15 | The Proposed Solution shall provide for tracking and management of count information and status. | E | |||
| C5.16 | The Proposed Solution shall provide basic query, filtering, on-line analysis, data mining, custom reporting services and functionality. | E | |||
| C5.17 | The Proposed Solution shall support selecting stations using standardized queries for volume, class, speed, weight, and micromobility data (e.g. AADT > 10,000). | E | |||
| APPLICATION REPORTS | |||||
| C6.1 | The Proposed Solution shall allow authorized users to create reports from the system data. Reports shall be repeatable. | M | |||
| C6.1.1 | All collected data, archived data and site information, including volume, class, speed, WIM, micromobility, count metadata, site photos, and tracking information shall be available for reporting. | M | |||
| C6.2 | The Proposed Solution shall output data items to be reported for TMG and TMAS submittals as described in the current versions of the TMG and TMAS documentation. | M | |||
| C6.2.1 | The Proposed Solution shall include report functions to create monthly reports required to meet the FHWA current edition of TMG and TMAS data reporting requirements, including station, volume, classification, and weight. | M | |||
| C6.2.2 | The Proposed Solution shall include report functions to create monthly reports for speed, micromobility, and IVRs. | E | |||
| C6.3 | The Proposed Solution shall ensure that the data collected from intersections is accurately represented and easily interpretable via GIS technologies. | E | |||
| C6.4 | The Proposed Solution shall produce monthly and annual reports for all continuous count stations, WIM and classification stations data in the format specified by the FHWA TMG for reporting to the TMAS. | M | |||
| C6.5 | The Proposed Solution shall provide standard reports for the following: | M | |||
| C6.5.1 | 200 High Hour Report. | M | |||
| C6.5.2 | 200 High Hour Graph. | M | |||
| C6.5.3 | Monthly Factors (Seasonal) | M | |||
| C6.5.4 | Monthly Factors Report. | M | |||
| C6.5.5 | Monthly Factors Graph. | E | |||
| C6.5.6 | Monthly Factors Edit Form. | E | |||
| C6.5.7 | Axle Correction Factors. | E | |||
| C6.5.8 | Axle Correction Edit Form. | E | |||
| C6.5.9 | Continuous Count Station AADT Report. | M | |||
| C6.5.10 | Continuous Count Station AADT Edit Form. | E | |||
| C6.5.11 | AADTs Compare Report. | E | |||
| C6.5.12 | AADTs Calculations Report. | E | |||
| C6.5.13 | AADTs Edit Form. | E | |||
| C6.5.14 | Interstate Form. | E | |||
| C6.5.15 | Interstate Schematic Form (Typical) | E | |||
| C6.6 | The Proposed Solution shall include report functions to recreate reports that are currently in use at NHDOT (see the website) using new system data in PDF format and to allow the ability to download these reports for all Authorized Users. | E | |||
| C6.6.1 | The Proposed Solution shall allow all Authorized Users the ability to download these reports. | E | |||
| C6.6.2 | Traffic Volume Reports – Listed by NHDOT District, RPC, County, Town, and Route Number. | E | |||
| C6.6.3 | Traffic Volume Reports – Listed by Route. | E | |||
| C6.6.4 | Traffic Volume Reports – 200 High Hour Reports. | E | |||
| C6.6.5 | Automatic Traffic Recorder Reports. | E | |||
| C6.6.6 | Traffic Detail Sheets | E | |||
| C6.6.7 | A1: Classification Count Average Weekday Data Report | E | |||
| C6.6.8 | A2: Traffic Count Hourly Report | E | |||
| C6.6.9 | A3: Speed Count Average Weekday Report | E | |||
| C6.6.10 | A4: Daily Speed Report | E | |||
| C6.6.11 | A5: Daily Classification Count Report | E | |||
| C6.7 | The Proposed Solution shall replicate the following NHDOT-Provided sample report formats: | E | |||
| C6.7.1 | Class Distribution Pattern | E | |||
| C6.7.2 | Interstate Extent and Travel By Route Number | E | |||
| C6.7.3 | Extent and Travel By National Highway System | E | |||
| C6.7.4 | Extent and Travel - Statewide Summary | E | |||
| C6.7.5 | Extent and Travel – Urbanized Area Summary | E | |||
| C6.7.6 | Continuous Station Directional Hourly Volume By Month | E | |||
| C6.7.7 | Continuous Station Directional Monthly Averages | E | |||
| C6.7.8 | Continuous Classification Station Monthly Classification Report | E | |||
| C6.7.9 | Vehicle Miles Traveled HPMS Annual Report | E | |||
| C6.7.10 | Volume by Class by Functional System by Region (Percent) | E | |||
| C6.7.11 | Volume by Class by Functional System Statewide (Percent) | E | |||
| C6.7.12 | Weekly Volume Report | E | |||
| C6.7.13 | Ad hoc Report | E | |||
| C6.7.14 | Top 100 High Hourly Volume Report by Station | E | |||
| C6.7.15 | Average Daily Traffic by Day of Week by Month | E | |||
| C6.8 | The Proposed Solution shall be able to produce output files using standard MS Office and Adobe file (.docx, .xlsx, .csv, .txt, .pdf). The output files shall be editable and web-publish ready. | E | |||
| C6.9 | The Proposed Solution shall allow for reports to be created by batch, or group, of stations. | E | |||
| C6.10 | The solution shall be able to generate batch, or group acceptance letters. | E | |||
| C6.11 | The Proposed Solution shall allow reports to be run by batch, or group, of stations while creating separate reports for each station. | E | |||
| C6.12 | The Proposed Solution shall allow multiple reports to be run on a station or group of stations, while creating separate reports for each station. | E | |||
| C6.13 | The Proposed Solution shall allow reports to be selected by days, months, or years as appropriate for the type of reports. | M | |||
| C6.14 | The Proposed Solution shall create a system to set reports to run automatically on a schedule. | O | |||
| C6.15 | The Proposed Solution shall restrict saving of reports to only approved data. | E | |||
| C6.16 | The Proposed Solution shall allow reports to be accessible through a report portal as well as mapping interface. | E | |||
| C6.17 | The Proposed Solution should permit Authorized Users to create custom reports. For instance, the solution will be capable of calculating AADT based on 24-hour daily volumes for highway sections, which are influenced by factors from a proximate Continuous Count or a set of Continuous Counts. Other examples include historical comparisons of Design Hour Volume as a percentage of AADT, along with a range of factors for adjusting peak hour and average daily data to align with the peak month. | E | |||
| C6.18 | The Proposed Solution shall include Ad Hoc reporting functions so that data can be extracted directly from the database and exported to a format convenient to use in Excel, SQL, ArcGIS (Oracle). | E | |||
| C6.19 | The Proposed Solution must export a “Station Header” file as a .csv with one record for each Station ID. | M | |||
| C6.20 | The Proposed Solution shall provide Turning Movement Diagrams. | E | |||
| C6.21 | The Proposed Solution shall produce reports of Turning Movement Data. | E | |||
| APPLICATION COMPATIBILTY | |||||
| C7.1 | The Proposed Solution shall include a baseline Interface Control Document (ICD) that clearly defines the externally exposed interface(s). | E | |||
| C7.2 | The Proposed System shall interface with New Hampshire State networks as required. | M | |||
| C7.2.1 | The Proposed System shall interface with New Hampshire State networks to provide secure remote access for full system functionality from any remote location using secure hypertext transfer protocols (HTTPS). | E | |||
| C7.3 | The Proposed Solution shall be compatible with the latest version of Microsoft Windows Operating System in use at NHDOT. | M | |||
| C7.3.1 | The Proposed Solution shall be compatible with the latest version of Microsoft Office, including Word and Excel file formats. | M | |||
| C7.3.2 | The Proposed Solution shall be compatible with the latest version of Adobe Acrobat and shall support Portable Document Files (PDFs). | M | |||
| C7.4 | The Proposed Solution shall integrate with ESRI products. | M | |||
| TESTING REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| APPLICATION SECURITY TESTING | |||||
| D1.1 | All security requirements of the system shall be tested, documented, and accepted prior to moving the system onto the NHDOT network. | M | |||
| D1.2 | In the development or maintenance of any code, the Vendor shall ensure that all software is independently verified and validated. | M | |||
| D1.3 | The Vendor shall be responsible for providing documentation of security testing, as appropriate. | M | |||
| D1.4 | The Vendor shall provide evidence that supports the fact that identification and authentication testing is conducted annually. | M | |||
| D1.5 | The Vendor shall test for encryption to verify support for the encoding of data for security purposes and for the ability to access the data in a decrypted format from required tools. | M | |||
| D1.6 | The Vendor shall test and harden web applications to prevent critical application security flaws. | M | |||
| STANDARD TESTING | |||||
| D2.1 | The Proposed Solution shall provide a Test environment for system patches and upgrades to be tested prior to roll out to Production. | M | |||
| D2.2 | The Proposed Solution Test environment shall duplicate the Production environment to ensure product patches and tests work in the Test environment to ensure easy transition to the Production environment. | M | |||
| SYSTEMS INTEGRATION TESTING | |||||
| D3.1 | The Vendor shall conduct testing to verify the Proposed System has been integrated in accordance with the requirements. | M | |||
| D3.1.1 | The Vendor shall test the User Management feature to verify support of the administration of computer, application and network accounts within an organization. | M | |||
| D3.1.2 | The Vendor shall test Role/Privilege Management to verify support of the granting of abilities to users or groups of users of a computer, application or network. | M | |||
| D3.1.3 | The Vendor shall test Audit Trail Capture and Analysis to verify support of the identification and monitoring of activities within an application or system. | M | |||
| D3.1.4 | The Vendor shall test Input Validation to ensure all system applications are protected from buffer overflow, cross-site scripting, SQL injection, and unauthorized access of files and/or directories on the server. | M |
| HOSTING-CLOUD REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| OPERATIONS | |||||
| E1.1 | The Proposed Solution UI shall function using the lastest versions of all commonly used web browsers including Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari. | M | |||
| E1.1.1 | The Proposed Solution software shall be launched and operated natively within a web browser and shall not utilize any third party remote web access or web application delivery to achieve or simulate the web application. | M | |||
| E1.1.2 | The Proposed Solution shall be accessible by remote users from any Internet connected device that uses a supported web browser to provide a secure connection for the entire system. The read-only functionality shall be free for Internet users. | M | |||
| E1.1.3 | The Proposed Solution shall reside in a Virtual Server environment. | M | |||
| E1.1.4 | The Proposed Solution shall utilize current Internet and industry standards and protocols for sharing data. | M | |||
| E1.1.5 | The Proposed Solution data exchange shall be agnostic to platform and software. | M | |||
| E1.2 | The Proposed Solution shall reference or import and host network data to use in locating data collection devices. | E | |||
| E1.3 | The Vendor shall verify that hosting services provide fire detection and suppression systems as well as physical and infrastructure security of the hosting facility. All environmental support equipment of the Vendor website hosting facility, including power conditioning, HVAC, UPS, and generator must be deemed acceptable by the State. | M | |||
| DISASTER RECOVERY/INCIDENT MANAGEMENT | |||||
| E2.1 | The Vendor shall manage daily backups and operation restoration. | E | |||
| E2.2 | Data shall be encrypted in the Operation environment and backed up. | E | |||
| SERVICE LEVEL AGREEMENT | |||||
| E3.1 | The Vendor shall meet or exceed the software quality requirements. | M | |||
| E3.2 | The Vendor shall maintain system quality by meeting the following: | M | |||
| E3.2.1 | Monitoring: Regularly track system performance and heatlh. | M | |||
| E3.2.2 | Updates: apply software and updates in a timely manner. | M | |||
| E3.2.3 | Testing. Perform routine tests to detect vulnerabilities. | M | |||
| E3.2.4 | Backup: store data backups consistently to prevent data loss. | M | |||
| E3.2.5 | Training: Educate users on best practices. | M | |||
| E3.2.6 | Securtiy: Implement protective measures against threats. | M | |||
| E3.2.7 | Feedback: Gather user input for continuous improvement. | M | |||
| E3.2.8 | Documentation: Update system procedures and guidelines. | M | |||
| E3.3 | If the Proposed Solution fails to meet system quality requirements, the Vendor shall credit the State's account in an amount based on the following formula: (Total Contract Price/365) x Number of Days System Quality Requirement is Not Met. Continued violations may lead to contract termination and potential legal action. | M | |||
| E3.4 | The Proposed Solution shall not exceed maximum processing time for generating queries. | E | |||
| E3.4.1 | Simple Queries shall have 5 seconds of maximum processing time. | E | |||
| E3.4.2 | Complex queries shall have 1 minute of maximum processing time. | E | |||
| E3.4.3 | Batch or heavy analytical processes shall have a notification of processing time not to exceed 10 minutes. | E | |||
| E3.5 | The Proposed Solution shall not exceed maximum processing time for generating reports. | E | |||
| E3.5.1 | For the Proposed Solution, the maximum processing time for generating standard reports should not exceed 5 seconds for real-time data needs. For more complex, detailed reports, processing should be completed within 60 seconds. Any analytical or yearly summary reports requiring data aggregation from extensive periods should be generated within 10 minutes. | E | |||
| E3.5.2 | If the Proposed Solution fails to meet the maximum processing time for generating standard reports, the Vendor shall credit the State's account in an amount based on the following formula: (Total Contract Price/365) x Number of Reported Occasions that Maximum Processing Time is Exceeded. Continued non-compliance may lead to renegotiation of service terms or potential contract termination. | E | |||
| E3.6 | The Proposed Solution map and core mapping functions shall have an uptime of 99.99% of the time on a montly basis, exclusive of regularly scheduled maintenance windows. | M | |||
| E3.6.1 | All Proposed Solution map data (basemap, map services, and feature layers) shall load to its full resolution within 10 seconds of startup. | E | |||
| E3.7 | The Proposed Solution shall typically make traffic data available for reporting within 5 minutes of startup. | E | |||
| E3.8 | Open help tickets shall be responded to expeditiously, based on the time frames provided for the ticket priority rating. | M | |||
| E3.8.1 | Critical Issues: These should be responded to within 1 hour or less, as they often pertain to system outages or major disruptions. | E | |||
| E3.8.2 | High-Priority Issues: These should be addressed within 4 hours, concerning significant problems that aren't fully system-impacting. | E | |||
| E3.8.3 | Medium-Priority Issues: A response within 12 hours is suitable, relating to problems that impact a subset of users or non-essential system features. | E | |||
| E3.8.4 | Low-Priority Issues: These should be addressed within 48 hours and often pertain to minor bugs, general inquiries, or feature requests. | E | |||
| E3.8.5 | The Vendor shall maintain a record of the activities related to repair or maintenance activities performed for the States and shall report these activities on a quarterly basis. | M | |||
| E3.8.6 | Server and mapping function up-time shall be included in the quarterly activity report. | E | |||
| E3.8.7 | All change requests implemented, including operating system patches shall be included in the quarterly activity report. | E | |||
| E3.8.8 | All critical outages reported including actual issue and resolution shall be included in the quarterly activity report. | E | |||
| E3.8.9 | The number of deficiencies reported by class with initial response time as well as time to close shall be included in the quarterly activity report. | E | |||
| E3.8.10 | The Proposed Solution data shall be displayed on the website no less than 1 hour after verification without loss of data. | E | |||
| E3.8.11 | For the Proposed Solution enhancements and upgrades that the Vendor performs during the Maintenance Period as defined in RFP DOT 2024-02, the Vendor shall treat NHDOT as a "Most Favored Customer" with respect to the provisions and pricing for said software enhancements and upgrades. The term "Most Favored Customer" shall mean that the Vendor represents and attests that all of the prices and other terms being provided hereunder are, and for the term of the Maintenance Period, shall be equal to or better than the terms for similar TDMS systems being offered by the Vendor to any other customers. | E | |||
| E3.8.12 | If during the term of the Maintenance Period, the Vendor enters into a similar TDMS agreement with any other customer providing such customer with more favorable terms, the Vendor shall provide notice to NHDOT within 30 days of such agreement, and provide said provisions and pricing to NHDOT as they become available. Upon NHDOT's approval of such terms, the TDMS Contract shall be amended, and such terms shall take effect on the effective date of the Vendor's agreement with the other customer. Any NHDOT authorized changes to the software shall be supported by updates to all TDMS documents. | E | |||
| SUPPORT & MAINTENANCE REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| SUPPORT & MAINTENANCE REQUIREMENTS | |||||
| J1.1 | The Vendor shall have a ticket-based help system (or functional equivalent). | E | |||
| J1.2 | For all maintenance service calls, the Vendor shall collect and maintain the following information: | E | |||
| J1.2.1 | Nature of the Deficiency | E | |||
| J1.2.2 | Current status of the Deficiency | E | |||
| J1.2.3 | Action Plans with Dates and Times | E | |||
| J1.2.4 | Expected and Actual Completion Time | E | |||
| J1.2.5 | Deficiency Resolution information | E | |||
| J1.2.6 | Resolved by | E | |||
| J1.2.7 | Identified by | E | |||
| J1.2.8 | Work Order Number or other ID reference number | E | |||
| J1.3 | The Vendor shall identify and troubleshoot potentially large-scale system failures or deficiencies by collecting the following information: | E | |||
| J1.3.1 | Mean Time between Reported Deficiencies | E | |||
| J1.3.2 | Diagnosis of the Root Cause of the Problem | E | |||
| J1.3.3 | Identification of Repeat Calls or Repeat Software Problems | E | |||
| J1.4 | The Proposed Solution shall have a Help page with search capabilities. | E | |||
| J1.5 | The Vendor shall have on-call technical support that shall be accessible to all Authorized Users to address system related queries, concerns or issues. | M | |||
| J1.6 | The Vendor shall have a helpline or dedicated support channel with clear operational hours accessible to all Authorized Users. | M |
| TRAINING | ||||||
| State Requirements | Vendor | |||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments | |
| INITIAL ROLL OUT TRAINING | ||||||
| K1.1 | The Vendor shall provide the State with all necessary training to operate the Proposed Solution. | M | ||||
| K1.2 | The Proposed Solution shall include Vendor-provided training to Authorized Users in the operations, support and maintenance of the Proposed Solution and system data. | M | ||||
| K1.3 | Initial Rollout Training for each user level shall be completed prior to Final System Acceptance of the Proposed Solution. | E | ||||
| K1.4 | The Initial Roll Out Training shall include all typical activities that may be assigned to each Authorized User level. | M | ||||
| K1.5 | The Initial Roll Out Training shall include in-person instruction with hard copy materials and conducted at an NHDOT Facility in New Hampshire. Facility scheduling shall be coordinated with the NHDOT Project Manager. | M | ||||
| K1.6 | The Vendor shall provide qualified instructor(s), as approved by NHDOT, for the in-person instruction. | M | ||||
| K1.7 | The Initial Roll Out Training shall include a minimum of eight (8) sessions of not more than 20 people per session. There shall be at least four sessions for Limited Access users, two sessions for Partner users, one session for Data Manager users, and one session for Systems Administrator users. | E | ||||
| K1.8 | Each session of the Initial Roll Out Training for Limited Access and Partner users shall last no longer than 8 hours, spread across one or two days. | E | ||||
| K1.9 | Each session of the Initial Roll Out Training for Data Manager and Systems Administrator users shall last no longer than 20 hours, spread across at least three days. | E | ||||
| K1.10 | The Initial Roll Out Training Program shall be responsible for training users in all typical daily, monthly, or annual tasks such that a user at each access level, as defined by NHDOT, can perform tasks without additional assistance. | M | ||||
| K1.11 | Additional Initial Roll Out Training beyond the in-person instruction shall include any additional commonly accepted training methodologies or platforms, including but not limited to: Instructor led online training, training videos, In-product help information and resources, In-program support (chat), Available self-paced web training by job task and user role. | E | ||||
| K1.12 | The Initial Roll Out Training Program shall begin not later than 30 days following the end of Operational Testing and all sessions shall be completed within 120 days following the end of Operational Testing. | E | ||||
| K1.13 | The Initial Roll Out Training shall be completed prior to NHDOT users needing to operate the Proposed Solution to submit any HPMS materials to FHWA. | E | ||||
| K1.14 | The Initial Roll Out Training shall include a module for each of the nine RPCs to ensure optimal utilization and comprehension of the system's functionalitities. | M | ||||
| TRAINING DOCUMENTATION | ||||||
| K2.1 | The Vendor shall develop and submit training documentation for approval, to include course outlines, samples of all training aids, user manuals, training materials and resumes of individuals who will conduct the training. | M | ||||
| K2.2 | The Vendor shall develop and provide all necessary user manuals, training materials, displays, class notes, visual aids, and other instructional materials as required for their training program. This requirement applies to the Initial Roll Out Training as well as the On-Going support training for the life of the Contract. | M | ||||
| K2.3 | The Vendor shall provide training documentation by user role to accommodate various levels of access and responsibilities. | E | ||||
| K2.4 | The Vendor shall produce Software Training digital videos that cover the basic Public functions of the Proposed Solution software. Training videos shall be available 24/7 from a source external to the Proposed Solution (for example, YouTube videos). | E | ||||
| K2.5 | The Vendor shall produce Software Training digital videos that cover the basic Partner functions of the Proposed Solution software.Training videos shall be available 24/7 from a source external to the Proposed Solution (for example, YouTube videos). | E | ||||
| K2.6 | The Vendor training documentation shall be detailed such that a user can learn or refresh training without additional assistance. | M | ||||
| K2.7 | The Vendor's training documentation shall include, but is not limited to, the following materials: | M | ||||
| K2.7.1 | Hard Copies and PDF copies of Training Manuals, class notes, and other visual aids. | E | ||||
| K2.7.2 | Training Websites | E | ||||
| K2.7.3 | Self Paced Learning Modules | E | ||||
| K2.7.4 | Built-in help files | M | ||||
| ON-GOING SUPPORT TRAINING | ||||||
| K3.1 | The Vendor shall provide on-going system support training to system users annually. | O | ||||
| K3.2 | The on-going training program shall include in-person instruction with hard copy materials and conducted at an NHDOT Facility in New Hampshire. Facility scheduling shall be coordinated with the NHDOT Project Manager. | O | ||||
| K3.3 | The Vendor shall provide qualified instructor(s), as approved by NHDOT, for the in-person instruction. | M | ||||
| K3.4 | The on-going training program shall provide sufficient training for each Authorized User level. | O | ||||
| K3.5 | On-going support training shall accommodate new hire training, task specific training, new functionality training and refresher training. | O | ||||
| K3.6 | The on-going training program shall include all typical activities that may be assigned to each Authorized User level. | O | ||||
| K3.7 | The on-going training program shall include at least five (5) sessions of not more than 20 people per session. There shall be at least two sessions for Limited Access users, two sessions for Partner users, and one joint session for Data Manager and Systems Administrator users. | O | ||||
| K3.8 | Each session of the on-going training program for Limited Access and Partner users shall last no longer than 6 hours. | O | ||||
| K3.9 | Each session of the on-going training program for Data Manager and Systems Administrator users shall last no longer than 12 hours, spread across at two days. | O | ||||
| K3.10 | The Vendor shall provide the State with all necessary training resulting from upgrades, modifications, and changes to the Proposed Solution. | M | ||||
| K3.10.1 | The Vendor shall provide enhanced on-call technical support accessible to all Authorized Users to address questions and issues resulting from all upgrades, modifications and changes. | M | ||||
| PROJECT MANAGEMENT | ||||||
| State Requirements | Vendor | |||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments | |
| PROJECT MANAGEMENT | ||||||
| L1.1 | The Vendor's documentation shall include the baseline Interface Control Documentation. | E | ||||
| L1.2 | The Vendor shall create change management documentation and procedures. | E | ||||
| L1.3 | The Vendor shall provide a documented procedure for the backup and restoring process. | E | ||||
| L1.4 | The Vendor shall document adequate disaster recovery procedures. | E | ||||
| L1.5 | The Vendor shall be responsible for equipment, labor, and/or services necessary to setup and maintain the internet connectivity to support access to the Proposed Solution. | E | ||||
| L1.5.1 | The Vendor shall operate hosting Services on a network offering adequate performance to meet the business requirements for the Proposed Solution. | E | ||||
| L1.5.2 | The Vendor will guide the State with possible solutions to resolve issues to maintain a fully functioning, hosted Proposed Solution. | E | ||||
| L1.6 | The Vendor shall continuously monitor software logs. | E | ||||
| L1.6.1 | The Vendor shall monitor system logs. | E | ||||
| L1.6.2 | The Vendor shall monitor security logs. | E | ||||
| L1.6.3 | The Vendor shall monitor application logs. | E | ||||
| L1.7 | The Vendor shall support the State in negotiating the terms of use of purchased third party/privately collected data. | O | ||||
| L1.8 | The Vendor shall manage the databases and services on all servers located at the Vendor's facility. | E | ||||
| L1.9 | The Vendor shall install and update all server patches, updates, and other utilities within 60 days of release from the manufacturer. | M | ||||
| L1.10 | The Vendor shall provide the State with a private and secure FTP site to be used by the State for uploading and downloading files. | E | ||||
| L1.11 | The Proposed Solution webpages shall contain their own unique URL for sharing on social media. | E | ||||
| L1.12 | The Proposed Solution shall provide a control screen for Authorized Users to manage alerts (Alert Manager). | E | ||||
| L1.13.1 | The Proposed Solution shall populate alerts generated by validity checks in the flags. | E | ||||
| L1.13.2 | The Proposed Solution shall maintain lists of all currently active flags and all closed flags. | E | ||||
| L1.13.3 | The Proposed Solution shall permit Authorized Users to close multiple alerts in one action. | E | ||||
| L1.13.4 | The Proposed Solution shall allow alerts to be optionally configurable to automatically cancel when the conditions that generated it are no longer met. | E | ||||
| L1.14 | The Vendor documentation shall include descriptions of how authorization shall be administered within the Proposed Solution. | E | ||||
| L1.15 | The Proposed Solution shall provide reference documentation for upgrades including release notes and known bugs. | E | ||||
| L1.15.1 | The Proposed Solution shall provide version upgrade utilities to install core and module updates to the system software. | E | ||||
| L1.15.2 | The Proposed Solution shall provide the ability to revert to the previous update/version in the event of an update causing issues within the software system. | M | ||||
| L1.16 | The Vendor shall give five (5) business days prior notification to the State's Project Manager of all scheduled system changes and updates performed by the Vendor | E | ||||
| L1.17 | The Proposed Solution shall support NHDOT's contracts with the nine RPCs and any other future Partners for the collection of short-term trafic counts. | M | ||||
| PROJECT CLOSE-OUT | ||||||
| L2.1 | The Vendor shall provide a detailed Close-Out and Transition Plan that outlines the steps and timeline for transferring data, knowledge, and responsibilities to NHDOT or any designated successor. The transition plan shall be submitted by the Vendor and approved by NHDOT prior to the completion of User Acceptance testing. NHDOT may require subsequent updates to the Transition Plan in the event of a contract extension. | M | ||||
| L2.1.1 | Close-out procedures may include data transfer, system decommissioning, documentation, and other necessary tasks agreed upon between NHDOT and the Vendor. | E | ||||
| L2.1.2 | The Vendor shall ensure the confidentiality and security of all data during the transfer and migration processes. | M | ||||
| L2.1.3 | Data shall be transferred in a manner that complies with relevant data protection laws and regulations in force at the time of termination. | M | ||||
| L2.2 | If during the life of the contract, NHDOT chooses to transition to a new system, upon notification in writing, the Vendor shall enact the Transition Plan to provide NHDOT with required data and information as part of the transition while continuing to maintain and support the current system to ensure uninterrupted service through the termination date. | M | ||||
| L2.2.1 | Upon the termination or expiration of the contract, the Vendor shall provide NHDOT with a complete copy of all data stored in the software database. | M | ||||
| L2.2.2 | Data transfer shall be in a standard, agreed-upon format, ensuring compatibility with potential future systems or software platforms. | M |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .