Amended SDDOT_HPMS_Requirements_24RFP11610.xlsx
XLSX spreadsheet 46 KB Posted
- Solicitation number
- 24RFP11610
- Issued by
- Harding County, South Dakota
About this file
This is a requirements checklist file related to a South Dakota Department of Transportation (SDDOT) RFP for a Highway Performance Monitoring System (HPMS) Management Software. The software must be configured to connect with SDDOT's existing systems including Roadway Information System, Non-State Trunk Road Inventory, Sample Section Database, dTims pavement management software, and BrM bridge inventory. The system must be operational by December 31st, 2025, for the 2026 HPMS annual preparation period. Key deliverables include system integration plans, test plans, training sessions (two initial online sessions and two follow-up sessions in years 2 and 3), training manuals, and operational support.
The requirements specify that the software must be capable of producing FHWA-compliant reports for both State Trunk and NSTRI roads, pass all business rules and validation checks, and create uploadable files for FHWA's HPMS portal. The vendor must provide single sign-on (SSO) integration with South Dakota's identity management service using OAuth 2.0 protocol. Technical requirements include system hosting specifications, data access protocols, interface capabilities, and the provision of detailed solution diagrams showing system integration and data flow. The file does not specify pricing terms, set-asides, or funding requirements.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| SDDOT_HPMS_Data_specifications_24RFP11610.xlsx | XLSX spreadsheet | |
| RFP Document.pdf | ||
| SDDOT_HPMS_Costs_24RFP11610.xlsx | XLSX spreadsheet | |
| SDDOT_HPMS_Vendor_Questions_24RFP11610.docx | DOCX document | |
| Response to Offeror Questions document.pdf | ||
| CSDDOT_HPMS_Requirements_24RFP11610 (002).xlsx | XLSX spreadsheet | |
| RFP Document.pdf | ||
| SDDOT_HPMS_Vendor_Questions_24RFP11610.docx | DOCX document | |
| SDDOT_HPMS_Data_specifications_24RFP11610.xlsx | XLSX spreadsheet | |
| SDDOT_HPMS_Costs_24RFP11610.xlsx | XLSX spreadsheet |
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
RFP Requirement Checklist
| How to use this document | ||
| Use this list to indicate whether your firm can meet the requirements. This does not replace the narrative portion of the RFP. It is intended to be a quick checklist. Comments are optional and should be brief. Detailed responses should be part of the narrative. | ||
| Vendor Response | vendor Comments |
(If any)
| 3.1 General Requirements |
| 3.1.1 Configure the HPMS Management Software to connect and maintain connections to the SDDOT Roadway Information System (RIS), Non-State Trunk Road Inventory (NSTRI), Sample Section Database, dTims pavement management software, and BrM bridge inventory to pull data automatically when requested by users. |
3.1.2 The Offeror should clearly define if their proposed solution will be hosted by them or by the State of South Dakota.
3.1.3 Deliver and Configure the HPMS Management Software for operational use during the HPMS annual preparation period for 2026. Which means we want installed and functional by December 31st, 2025.
| 3.1.4 Implement the HPMS Management Software and provide operational and software support. The Offeror will be responsible for the operations of the software, and resolving issues in the system when needed. |
| 3.1.5 Provide Annual Support to modify configurations of the HPMS Management Software, as needed, to reflect changes in the FHWA HPMS reporting process, requirements, software validations and will provide consulting support to SDDOT HPMS staff to support them using the software to complete HPMS submittals; |
3.1.6 Provide Training and Operations Support for the HPMS Management Software.
| 3.2.1 The Offeror response will demonstrate that they can produce reports acceptable to FHWA. | |
| 3.2.1.1 Ability to pass all business rules and data validation checks, and data items and formats required now and, in the future, (currently HPMS version 9.0). | |
| 3.2.1.2 | Create a file that can be uploaded to FHWA’s HPMS portal. |
| 3.2.1.3 | Produce this for both State Trunk and NSTRI roads. |
| 3.2.1.4 If the system does not have the existing reports, they should show what capabilities their system has to allow SDDOT to create reports as needed. | |
| 3.2.1.5 To produce these reports the Offeror system will need to be able to provide an on-demand API connection to these current data sources maintained by SDDOT. |
Roadway Information System (RIS) Non-State Trunk Road Inventory (NSTRI) Sample Section Database dTims pavement management software (Deighton) BrM bridge inventory (AASHTOWare)
3.2.1.6 Deliverable: Sample Report
Sample report(s) that demonstrates full compatibility with FHWA for both State Trunk and NSTRI roads
3.2.1.7 Deliverable: System Integration
A description of how you will integrate with existing data sources. This should be in the form of both
| 3.2.1.7.1 A high-level diagram of how your system works with other systems data sources. | |
| 3.2.1.7.2 A technical description of how you will create, operate, and maintain | |
| 3.2.2.1 | Deliverable: Plan for setting up HPMS Management Software: |
For the proposal, the Offeror should provide a detailed plan with timeline for
| 3.2.2.1.1 Discovery | |
| 3.2.2.1.2 | Creating data connections |
| 3.2.2.1.3 | Launching a test environment creating the Fully functioning/operational HPMS Management Software, as determined by the State, in-use by SDDOT users and pulling data from external systems for at least 14 consecutive days without fail. |
| 3.2.2 | Plan for HPMS Management Software delivery, configuration of interfaces to external systems, and demonstration of ability to generate HPMS data. |
| 3.2.2.1 Deliverable: Plan for setting up HPMS Management Software: |
For the proposal, the Offeror should provide a detailed plan with timeline for
| 3.2.2.1.1 Discovery |
| 3.2.2.1.2 Creating data connections |
| 3.2.2.1.3 Launching a test environment creating the Fully functioning/operational HPMS Management Software, as determined by the State, in-use by SDDOT users and pulling data from external systems for at least 14 consecutive days without fail. |
| 3.2.2.2 Deliverable: Test Plan (or Test Plan Implementation): | |
| As part of the response outline your | |
| 3.2.2.2.1 Test Plan/Cases/Scripts, Consultation (On-site if requested) | |
| 3.2.2.2.1 Walkthrough/Virtual Session (if applicable). | |
| 3.2.3 Training | |
| 3.2.3.1 | Deliverable: Initial Training: |
The proposal should outline a plan for conducting two, on-line Training Sessions as part of implementation.
3.2.3.2 Deliverable: Follow-Up Training:
Conduct two, on-line Training Sessions during year 2 and 3 of the contract. One per year.
3.2.3.3 Deliverable: Training Manual:
Deliver two (2) electronic MS Word copies, describing the core functionality of the system, how to use it, and the key function and roles required to operate.
3.2.3.4 Deliverable: User’s Manual:
Deliver two (2) electronic MS Word copies, describing the core functionality of the system, how to use it, and the key function and roles required to operate.
| 3.2.4 HPMS Management Software Operations, Technical Support and Software Maintenance |
| 3.2.4.1 Be responsible for performing all operations of the system, maintaining regular back-ups, and any database administration needed, perform back-ups of the system data, and deliver backups to SDDOT at a regular planned cycle to be agreed during system development. |
| 3.2.4.2 Be responsible for annually updating the HPMS software validation checks to mirror the FHWA HPMS software as listed in the system requirements |
The proposal should include a narrative describing how you will meet this deliverable.
3.2.4.3 Deliverable: Operations Support:
Explain plan for maintenance and technical support for duration of contract, including software supports and upgrades.
3.3 Hosting and Data Access Requirements
If no data is stored with in the vendor system respond to 3.3.1 and 3.3.2 with N/A
| 3.3.1 The contract doubles as an agreement for the State to own the data tables and is able to manipulate data, run reports as needed, pull code tables, access raw data, and develop dashboards as needed |
| 3.3.2 The Offeror shall describe the process by which the State can access data housed within the proposed solution for ingestion into a state data repository, encompassing available methodologies (e.g., flat file, API), data formatting, frequency of updates, and any inherent constraints. Additionally, provide a high-level architecture diagram, as part of the Solution Diagram, elucidating the proposed solution's data provision mechanism. |
| 3.4 Single Sign-On Requirements |
| 3.4.1 As part of the State’s Identity and Access Management (IAM) strategy, the proposed solution will need to integrate with the State of South Dakota’s standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles. |
| 3.4.2 The SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users. Microsoft’s official documentation on the identity provider the State has implemented can be found https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 and https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc for state employees, businesses, partners, providers, etc. (Azure Active Directory). |
| 3.4.3 is not a deliverable |
| 3.4.4 Onboarding/Provisioning Users |
The offeror must describe how new users are onboarded/provisioned in the system using an external identity provider and provide an Identity/SSO/Login Design Document.
| 3.5 Interfaces and Integration |
| 3.5.1 The offeror must describe how the system can adapt to business necessary interfaces using widely adopted open APIs and standards. Additionally, SDDOT expects that the offeror will make available/expose software services and publish documentation for those software services that would enable third party developers to interface other business applications. A detailed description of system capability must be included in the proposal. |
| 3.6 Solution Diagram |
| 3.6.1 The offeror must provide a solution diagram providing specific details of how the entire solution will meet the requirements of the RFP. This will include integration with the State’s infrastructure, existing systems that will integrate with the proposed solution, how data would flow between systems, the technology stack of the solution including any dependencies, and include, but not be limited to, user onboarding/provision and SSO. |
Sheet1
3.2.1.7 Deliverable: System Integration
A description of how you will integrate with existing data sources. This should be in the form of both
| 3.2.1.7.1 A high-level diagram of how your system works with other systems data sources. |
| 3.2.1.7.2 A technical description of how you will create, operate, and maintain |
3.2.2.1 Deliverable: Plan for setting up HPMS Management Software:
For the proposal, the Offeror should provide a detailed plan with timeline for
| 3.2.2.1.1 Discovery | |
| 3.2.2.1.2 | Creating data connections |
| 3.2.2.1.3 | Launching a test environment creating the Fully functioning/operational HPMS Management Software, as determined by the State, in-use by SDDOT users and pulling data from external systems for at least 14 consecutive days without fail. |
File details come from the government source that posted it. Updated .