Replacement PMS (R-PMS) Requirements Master Requirement Model Element

        R-PMS System Must, Should, is Desired to

                all requirements contained by this Master Requirement

Requirement Priority

M=Mandatory, E=Expected, D=Desirable

General System Requirements defined by State of Kansas and Kansas Department of Transportation

The solution shall maintain compliance with Kansas Statutes, Rules and Regulations of KDOT, Kansas Department of Administration and Kansas IT Executive Council (ITEC) as described or referenced in the Request for Proposal and its attachments.

The solution must compute the necessary funding requirements given current pavement conditions, deterioration models, action costs and post action models, constraints on work types, economic assumptions, and desired pavement conditions at specific periods (at least 12 years) including the possibility of variable inputs and output for each year in the analysis.

The solution must accommodate pavement conditions (both current and desired) as defined by KDOT both in terms of the components (roughness, rutting, cracking, structural assessment, friction, ...) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits).

Note that this requirement also will apply under 2.2 (funding programs), 3.1 (1R Projects), and 3.2 (3R Projects)

The solution is expected to accommodate grouping and naming pavement condition sets to facilitate easy selection of the different condition combinations (Fed PM, KDOT surface only, KDOT surface +structure, ....).

The solution must accommodate pavement condition deterioration models (and post-action models) as defined by KDOT both in terms of the form (from linear deterministic to potentially Markov stochastic) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits, family, system ). 

The solution is expected to accommodate grouping and naming pavement deterioration model sets to facilitate easy selection of the different model combinations (RM only, historic derived, Delphi fit, ....).

The solution must accommodate action categories and specific action feasibility and unit costs as defined by KDOT recognizing variability based on location, prior pavement condition, user costs, and Agency costs.

The solution is expected to accommodate grouping and naming pavement action sets to facilitate easy selection of the different action combinations (light, robust, ....).

The solution must accommodate constraints on work types (and some actions) as defined by KDOT possibly including limits on dollars by work types and/or limits on miles (or area) by work types (and some actions - e.g. no more than x miles of Chip Seals recommended in a year due to chip supply limits).

The solution is expected to accommodate grouping and naming work type (and some action) constraint sets to facilitate easy selection of the different constraint combinations (RM%, Light%, Medium%, Heavy% with max Chips Seals of 200 miles ).

The solution must accommodate the time value of money as defined by KDOT which typically follows UMB Circular 94 and includes both an appropriate inflation designation and an interest rate to compute a discount rate that is consistent with long-term investment in infrastructure.

The solution must compute the future pavement conditions given current pavement conditions, deterioration models, action costs and post action models, constraints on work types, economic assumptions, and anticipated funding at specific periods (at least 12 years). NOTE: The requirements under 2.1.x also apply under 2.2 but now for Funding Program Analysis. 

The solution must accommodate pavement conditions (both current and desired) as defined by KDOT both in terms of the components (roughness, rutting, cracking, structural assessment, friction, ...) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits).

Note that this requirement also will apply under 2.2 (funding programs), 3.1 (1R Projects), and 3.2 (3R Projects)

The solution is expected to accommodate grouping and naming pavement condition sets to facilitate easy selection of the different condition combinations (Fed PM, KDOT surface only, KDOT surface +structure, ....).

The solution must accommodate pavement condition deterioration models (and post-action models) as defined by KDOT both in terms of the form (from linear deterministic to potentially Markov stochastic) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits, family, system ). 

The solution is expected to accommodate grouping and naming pavement deterioration model sets to facilitate easy selection of the different model combinations (RM only, historic derived, Delphi fit, ....).

The solution must accommodate action categories and specific action feasibility and unit costs as defined by KDOT recognizing variability based on location, prior pavement condition, user costs, and Agency costs.

The solution is expected to accommodate grouping and naming pavement action sets to facilitate easy selection of the different action combinations (light, robust, ....).

The solution must accommodate constraints on work types (and some actions) as defined by KDOT possibly including limits on dollars by work types and/or limits on miles (or area) by work types (and some actions - e.g. no more than x miles of Chip Seals recommended in a year due to chip supply limits).

The solution is expected to accommodate grouping and naming work type (and some action) constraint sets to facilitate easy selection of the different constraint combinations (RM%, Light%, Medium%, Heavy% with max Chips Seals of 200 miles ).

The solution must accommodate the time value of money as defined by KDOT which typically follows UMB Circular 94 and includes both an appropriate inflation designation and an interest rate to compute a discount rate that is consistent with long-term investment in infrastructure.

The solution must generate candidate projects with scopes for "3R" projects given current pavement conditions, deterioration models, action costs and post action models, constraints on work types (including existing layer factors that influence practical work types and structural evaluation influences), economic assumptions, and desired pavement conditions at specific periods (at least 5 years) including the possibility of variable inputs and output for each year in the analysis. NOTE: The requirements under 2.1.x also apply under 3.2 but now for "3R" Project Recommendation Process.

The solution must accommodate pavement conditions (both current and desired) as defined by KDOT both in terms of the components (roughness, rutting, cracking, structural assessment, friction, ...) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits).

Note that this requirement also will apply under 2.2 (funding programs), 3.1 (1R Projects), and 3.2 (3R Projects)

The solution is expected to accommodate grouping and naming pavement condition sets to facilitate easy selection of the different condition combinations (Fed PM, KDOT surface only, KDOT surface +structure, ....).

The solution is expected to accommodate grouping and naming pavement deterioration model sets to facilitate easy selection of the different model combinations (RM only, historic derived, Delphi fit, ....).

The solution must accommodate action categories and specific action feasibility and unit costs as defined by KDOT recognizing variability based on location, prior pavement condition, user costs, and Agency costs.

The solution is expected to accommodate grouping and naming pavement action sets to facilitate easy selection of the different action combinations (light, robust, ....).

The solution must accommodate constraints on work types (and some actions) as defined by KDOT possibly including limits on dollars by work types and/or limits on miles (or area) by work types (and some actions - e.g. no more than x miles of Chip Seals recommended in a year due to chip supply limits).

The solution is expected to accommodate grouping and naming work type (and some action) constraint sets to facilitate easy selection of the different constraint combinations (RM%, Light%, Medium%, Heavy% with max Chips Seals of 200 miles ).

The solution must accommodate the time value of money as defined by KDOT which typically follows UMB Circular 94 and includes both an appropriate inflation designation and an interest rate to compute a discount rate that is consistent with long-term investment in infrastructure.

The solution must generate candidate projects with scopes for "3R" projects given current pavement conditions, deterioration models, action costs and post action models, constraints on work types (including existing layer factors that influence practical work types and structural evaluation influences), economic assumptions, and desired pavement conditions at specific periods (at least 5 years) including the possibility of variable inputs and output for each year in the analysis. NOTE: The requirements under 2.1.x also apply under 3.2 but now for "3R" Project Recommendation Process.

The system must accommodate pavement conditions (both current and desired) as defined by KDOT

both in terms of the components (roughness, rutting, cracking, structural assessment, friction, ...) and

aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits) 

The system is expected to accommodate grouping and naming pavement condition sets

to facilitate easy selection of the different condition combinations

(Fed PM, KDOT surface only, KDOT surface +structure, ....)

The system must accommodate pavement condition deterioration models (and post-action models)

as defined by KDOT both in terms of the form (from linear deterministic to potentially Markov stochastic) and

aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits, family, system ) 

The system is expected to accommodate grouping and naming pavement deterioration model sets

to facilitate easy selection of the different model combinations (RM only, historic derived, Delphi fit, ....)

The system is expected to accommodate grouping and naming pavement action sets

to facilitate easy selection of the different action combinations (light, robust, ....)

The system must accommodate constraints on work types (and some actions) as defined by KDOT

possibly including limits on dollars by work types and/or limits on miles (or area) by work types

(and some actions - e.g. no more than x miles of Chip Seals recommended in a year due to chip supply limits)

The system is expected to accommodate grouping and naming work type (and some action)

constraint sets to facilitate easy selection of the different constraint combinations

(RM%, Light%, Medium%, Heavy% with max Chips Seals of 200 miles )

The system must accommodate the time value of money as defined by KDOT

which typically follows UMB Circular 94 and includes both an appropriate inflation designation

and an interest rate to compute a discount rate that is consistent with long-term investment in infrastructure

The solution must produce and provide relevant data (Roughness, Rutting, Equivalent Transverse Cracking, Equivalent Joint Distress, Equivalent Faulting, and Remaining Life) in the requested format to feed the Priority Formula.

The solution must generate the remaining pavement life based on the pavement condition data, deterioration models, and Priority Formula selected segmentation (the current process is a Monte Carlo Simulation methodology).

The solution is expected to generate vertical curvature stopping site distances in a format that can be passed to the Priority Formula.

The solution is expected to allow the user to change attributes to pass to the Priority Formula and use different segmentations (tenth mile, nominally 1-mile pavement management segments, ...) to meet Priority Formula needs.

The system is expected to accommodate expansion with capabilities such as ramps, individual lanes, shoulders, sidewalks, ...

and the ability to expand also includes the need to have condition, modeling, actions, costs, ... capabilities as well

[note on lanes: the current pavement management system uses the field lane throughout where

        0 means the road is undivided,

        1 is for West Bound,

        2 is NB,

        3 is EB, and

        4 is WB,

 at some point KDOT will need to reconsider what lanes means and determine how they will be coded]

The solution must flow and track the process while generating the pavement components of the Highway Performance Monitoring System as the data is collected, processed, summarized, and submitted to Transportation Planning for the annual submittals.

The solution must generate the HPMS mandated pavement data items (Roughness, Rutting, Faulting, and Percent Cracking) using 0.1 mile aggregation and following all other HPMS edicts and provide that data to KDOT Transportation Planning. NOTE: this data pass could be a very simple interface or workflow.

The solution must perform or accommodate a conflation process to align the data following the KDOT PMS Centerline LRS to the Transportation Planning Carriageway LRS using GPS data before aggregating the data to 0.1 mile segments. NOTE: this process may take place within the data collection processing activity, but if it does not occur there, then it must be addressed before data is generated for Transportation Planning.

The solution is expected to be able to generate the HPMS Report Card using the compiled but not yet submitted measured KDOT pavement condition data.

The solution must annually generate and provide the HPMS mandated pavement data for the Interstate in time for KDOT Transportation Planning to meet their April 15 submittal deadline.

The solution must annually generate and provide the HPMS mandated pavement data for the Non-Interstate in time for KDOT Transportation Planning to meet their June 15 submittal deadline.

The solution must annually generate and provide the HPMS mandated pavement data for the Non-state samples in time for KDOT Transportation Planning to meet their June 15 submittal deadline.

The solution must flow and track the process to generate the pavement components of the KDOT Performance Measures Dashboard related to predicted pavement condition annually. 

The solution must complete an analysis that processes the inputs like those described under requirements 2 and 3 to generate the predicted pavement condition as defined by KDOT to perform this function annually [note that the "future" conditions in these cases might be only a function of deterioration and already scheduled projects.] and provide that data to the KDOT Performance Measures Dashboard. NOTE: this data pass could be a very simple interface or workflow.

The solution must flow and track the process to generate the pavement components of the KDOT Performance Measures Dashboard related to measured pavement condition annually.

The solution must generate the KDOT defined pavement performance measures (some form of Percent of System in Good/Poor Condition - currently following HPMS with additional Transverse Cracking and Joint Distress variables) using nominally 1 mile segmentation and provide that data to the KDOT Performance Measures Dashboard. NOTE: this data pass could be a very simple interface or workflow.

Support KDOT Asset Management processes (TAMP)

The solution must flow and track the process to generate the pavement components of the TAMP as the data is collected, processed, summarized, and submitted to Transportation Planning for the biannual updates [like the Performance Measures under requirement 4, this requirement has a predicted piece and a measured piece (currently HPMS report card)].

The solution must complete an analysis that processes the inputs like those described in sections 2 and 3 to generate the predicted pavement condition as defined by KDOT to provide scenarios on different weightings for work type funding and gaps between desired programs and actual budgets over a 12 year horizon each time that the Transportation Asset Management Plan is updated.

The solution must accommodate pavement conditions (both current and desired) as defined by KDOT both in terms of the components (roughness, rutting, cracking, structural assessment, friction, ...) and aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits). Note that this requirement also will apply under 2.2 (funding programs), 3.1 (1R Projects), and 3.2 (3R Projects).

The system is expected to accommodate grouping and naming pavement condition sets

to facilitate easy selection of the different condition combinations

(Fed PM, KDOT surface only, KDOT surface +structure, ....)

The system must accommodate pavement condition deterioration models (and post-action models)

as defined by KDOT both in terms of the form (from linear deterministic to potentially Markov stochastic) and

aggregation (points, 1/200th mile linear, 10th mile linear, nominally 1 mile segmented, project limits, family, system ) 

The system is expected to accommodate grouping and naming pavement deterioration model sets

to facilitate easy selection of the different model combinations (RM only, historic derived, Delphi fit, ....)

The system is expected to accommodate grouping and naming pavement action sets

to facilitate easy selection of the different action combinations (light, robust, ....)

The system must accommodate constraints on work types (and some actions) as defined by KDOT

possibly including limits on dollars by work types and/or limits on miles (or area) by work types

(and some actions - e.g. no more than x miles of Chip Seals recommended in a year due to chip supply limits)

The system is expected to accommodate grouping and naming work type (and some action)

constraint sets to facilitate easy selection of the different constraint combinations

(RM%, Light%, Medium%, Heavy% with max Chips Seals of 200 miles )

The system must accommodate the time value of money as defined by KDOT

which typically follows UMB Circular 94 and includes both an appropriate inflation designation

and an interest rate to compute a discount rate that is consistent with long-term investment in infrastructure

integrate with KDOT highway inventory systems

The vendor must work with KDOT to develop a new interface between KDOT's Inventory System (KHUB) and the PMS noting that PMS uses a Centerline Network with a defined county-based LRSm and the Inventory system uses a carriageway county-based LRSm. This interface should allow the PMS to read data from KHUB for reference matching.

The vendor must work with KDOT to develop a new interface between KDOT's Inventory System (KHUB) and the PMS noting that PMS uses a Centerline Network with a defined county-based LRSm and the Inventory system uses a carriageway county-based LRSm. This interface should allow the PMS to read data from KHUB for reference matching.

The solution must preserve the existing functionality of the interface between KDOT's Inventory System (KHUB) and the PMS. This read/write interface allows data to pass from the KHUB to PMS to check/update inventory items (traffic, NHS, maintenance responsibility, pavement type, lane widths, shoulder type, shoulder width, etc.).

The system is desired to use the K-Hub interface to "automagically"

append new pavement condition data from PMS to the K-Hub environment

in KDOT Transportation Planning

[this push is for whatever pavement data K-Hub wants to store and

 whatever is needed to be passed through that environment to get to the

 Priority Formula Application which is part of requirement 3]

Integrate with KDOT GIS tools (or provide comparable imbedded tools)

The solution must provide GIS tools to meet the remaining requirements under number 7 or interface in such a way with the KDOT implementation of ArcGIS or ArcGIS online called KanPlan that it can perform these functions.

The solution is desired to show the different LRS networks together so differences may be visualized.

The solution must be able to show through GIS where data needs to be collected in the current cycle based on the data collection needs for KDOT project selection, performance monitoring, TAMP and other (pavement design, research, or others with needs).

The solution is desired to show through GIS where data has been processed and entered into the appropriate data table(s).

The solution must be able to show current attribute data (pavement type, pavement width, traffic, maintenance responsibility, NHS status, Action history, Scheduled projects, ...) using GIS mapping tools.

The solution must be able to show current condition data (roughness, rutting, faulting, ..., transverse cracking, cross slope, texture, joint distress, structural measures, friction measures, ...) using GIS mapping tools.

The solution is desired to show current condition data compared to data from a prior year (deltas) using GIS mapping tools.

The solution is expected to show future, predicted (modeled) condition data using GIS mapping tools.

The solution is expected to show current condition data compared to data from a prediction (residuals) using GIS mapping tools.

The solution must be able to show analysis recommendations and output (candidate projects for 1R, heavy preservation, or 3R; crack seal candidates; "friction candidates; structural analysis assessments; ...) using GIS mapping tools.

The solution is desired to provide mark up and feedback options on the maps or through associated forms indicating which candidates are accepted, and any routes that were not candidates that are being recommended anyway.

The solution must provide or accommodate typical GIS functions such as allowing the user to select common features for mapping, provide for filtering, provide selection, ....

Integrate with KDOT historic pavement condition data

The solution must develop an interface or data conversion process to allow users of the system access to historic pavement condition data. There are about 50 GB of data in existing tables. 

The solution is desired to interface or incorporate a data conversion process with historic pavement core data (location, date, bound thickness by layer with approximate unbound lengths, condition by layer). Currently KDOT does not have this data in electronic form, but an effort may be made by KDOT to back populate a table with this data and then include it in the solution. 

The solution is desired to develop an interface or data conversion process to allow users of the system to access to formatted csv "reports" like those created by Mandli RVW [this is just the means to get LCMS and profile data from the collection system into the PMS]. For each year (2013-2022) this would include about 15 data elements. Reports are run at three different aggregations, so a frames report would have about 2.5 million records. A tenths report would have about 120,000 records, and a segments report would have about 12,000 records. For the non-State HPMS, frames reports would be about 80,000 records with 15 fields, 4,000 and 15 for tenths, and about 300 and 15 for HPMS segments.

The solution must develop an interface or data conversion process to allow users of the system to access FWD data [this data currently resides in an Oracle database table]. The data structure is much different than the surface data, so it has its own requirement. For each year (1998-2022) this would include about 25 data elements. This is point data with typical yearly record counts around 40,000. It is more likely to be around 20,000 additional records per year moving forward.

The solution is desired to interface or incorporate a data conversion process for Traffic Speed Deflectometer data [this data currently resides in Oracle database tables and represents about 1500 miles of single time collection. The data is typically at 100 records per mile and 160 data elements]. We expect to continue to collect around 250 miles of this data in future years.

The solution must interface or incorporate a data conversion process for Joint Distress Collection data [this data currently resides in PostgreSQL database tables]. These tables are relatively small with about 250 records and 10 fields in 3 different tables.

The solution must interface or incorporate a data conversion process for Surface Friction (SKID) data.

The solution must interface or incorporate a data conversion process for Surface Friction (SKID) actual skid location data [this data currently resides in an Oracle database table]. For each year (1992-2022) this would include about 27 data elements. This is point data with typical yearly record counts around 5,000. 

The solution must interface or incorporate a data conversion process for Surface Friction (SKID) expanded data that was inferred based on the point data and surface history [this data currently resides in an Oracle database table]. For each year (2000-2022 - and some records from before 2000) this would include about 8 data elements. This is nominally 1 mile segment data with typical yearly record counts around 5,000. 

The solution is desired to interface or incorporate a data conversion process for Continuous Surface Friction (SCRIM) data [this data currently resides in a Oracle database tables and represents 1 collection cycle and about 1000 miles].

The solution must interface or incorporate a data conversion process for historic flexible pavement surface condition data (date collected, rutting, transverse cracking, fatigue cracking, block cracking, ...) [this data currently resides in an Oracle database table]. For each year (1986-2022) this would include about 23 data elements. This is nominally 1 mile segment data with typical yearly record counts around 10,000. In addition to the summary data in the tables described above, there are specific tables for transverse cracking. These tables contain about 1.5 million records per year with 21 columns for 2013 to 2022 years coverage. A summary statistic table for segments has 12000 records per year and 8 columns also for the period 2013 to 2022.

The solution must interface or incorporate a data conversion process for historic rigid pavement surface condition data (date collected, faulting, joint distress, ...) [this data currently resides in an Oracle database table]. For each year (1986-2022) this would include about 23 data elements. This is nominally 1 mile segment data with typical yearly record counts around 1,500.

The solution must interface or incorporate a data conversion process for historic ride quality data (left wheel path International Roughness Index, right wheel path IRI, "rough IRIL" - meaning worst tenth in nominally 1-mile segment, "rough IRIR", date collected, ...) [this data currently resides in an Oracle database table]. For each year (1986-2022) this would include about 16 data elements. This is nominally 1 mile segment data with typical yearly record counts around 12,000. 

The solution must interface or incorporate a data conversion process for historic HPMS data. These tables mimic the ride, rigid, and flexible tables but are for locations that KDOT does not maintain but must be reported for HPMS. [this data currently resides in Oracle database tables]. For each year (1996-2022) this would include about 30 unique data elements with about 300 records per year.

The solution must interface or incorporate a data conversion process for remaining pavement life data (these data reflect simulated estimates of remaining life of each pavement segment computed each year) [this data currently resides in an Oracle database table]. For each year (1986-2022) this would include 6 data elements. This is nominally 1 mile segment data with typical yearly record counts around 12,000. 

The solution is desired to interface or incorporate a data conversion process for Mean Texture Depth (MTD) data from the collection system into the PMS. For each year (currently only 2014-2015) this includes 15 data elements and about 2.5 million records per year. 

The solution must interface or incorporate a data conversion process for combined pavement condition (CSTATE) data (these data reflect the pavement surface data converted to distress states along with info about planned and last actions for each year) [this data currently resides in an Oracle database table]. For each year (1986-2022) this would include 19 data elements. This is nominally 1 mile segment data with typical yearly record counts around 12,000. 

The solution must interface or incorporate a data conversion process for aggregated and summarized action history and planned work data (ACTHIST) [this data currently resides in an Oracle database table]. This data is current (not historic in the sense of many years). It is aggregated so that routes with the same action history are aggregated together. this would include 30 data elements and about 2000 records. Each year this table gets updated and replaces the prior data.

Integrate with KDOT (and other typical) pavement condition systems

The solution is expected to interface with KDOT and other typical pavement condition collection systems (Mandli implementation of SD-type profiler, LCMS I, LCMS II; KDOT specific Joint Distress (WhiPavSur); KDOT SKID; TSD; KDOT cores; KDOT Transverse Cracking; lcms cross slope; lcms texture; SCRIM, .... Each of these systems is further defined in the Glossary) as the means to incorporate data collected in the future more directly into the system.

The solution is expected to help make the collection, processing, loading, and analyzing processes comprehensive and well managed from beginning to end.

The solution is expected to use the networks and collection rules to help determine and document with lists and/or maps where [specific types of] data are needed in the next collection cycle.

The solution is desired to use the networks and collection tracking to determine and document with lists and/or maps where [specific types] of data have/still need to be collected.

The solution is desired to follow KDOT specified quality checks for each data collection activity and must provide relevant documentation (ex: DQMP is a federal report) of these checks.

The system must be capable of tagging each record with GPS coordinates (lat/long) and

use these coordinates to manage all translations between Networks and with the GIS systems.

The solution shall preserve the existing functionality of the interface between the PMS and NCV. This interface sends PMS pavement image and condition (video log with pavement data) and all the necessary data to feed it that currently comes from stored images and many tables of data to NCV.

Integrate with KDOT project management systems

The solution is expected to interface with the KDOT project management system (WinCPMS) as the means to incorporate project information (scheduled and let projects, locations, scopes, schedule, costs, and project number) into the system.

The solution shall preserve the existing functionality of the interface between the Completed Rehab Form (CRF) web app and the PMS. This interface passes data from the CRF web app to PMS and helps track which projects are expected for completion in the calendar year and then to get the actual location, scope, open to unrestricted traffic date, mix, layer thickness rumble strip, and shoulder information about the project into the system.

The solution is expected to provide workflow notification or a tracking tool to alert Transportation Planning when each Completed Rehab Form is submitted so the KHUB process for extracting and updating inventory information changed by the project can be completed.

Generate, distribute, retain, reports as needed

Maintain interfaces with systems to obtain and provide relevant interchange of data

System much be configurable to allow for best meeting requirements and to allow for future modifications

The solution must allow for configurations that allow KDOT to tailor the system to best meet our needs and to allow for future modifications [a configuration draft document is being developed by KDOT and will be available early in the implementation stage of the project].

The solution is desired to be accessible at least for appropriate field information for mobile devices and tablets.

The solution is desired to be able to incorporate analysis and reporting tools (PowerBI, Crystal Reports, Tableau, ...).

Support development and integration of forms for gathering input from users

Support workflow to help streamline processes and keep users informed of progress and relevant tasks

The solution must provide workflows to help streamline processes and keep users informed of progress and relevant tasks as described under other specific requirements [a list of sample workflows is provided in the Workflows Tab].

Provide and meet KDOT and PMS Technical Architectural Requirements

If the solution includes a client installation, the solution shall be able to run in Windows 10 OS or a later version and/or in a Windows 10/11 compatible browser or higher version (see Browser Capability below) for a web-based system. 

The solution shall be compatible with KDOT's computing environment which includes, but is not limited to: Microsoft Office 365 SP 1 (64-bit), MS Office 2016 & Microsoft Outlook Exchange 365 & InfoPath 2013 , and Sophos Antivirus. NOTE: Only applies for client based solution.

The solution shall be compatible with the minimum listed or higher versions of the following browsers: Microsoft Edge 106, Firefox 56, Safari, and Chrome 61. (Chrome preferred)

The solution shall utilize Web Services for data exchanges between Applications following a Service Oriented Architecture (SOA) model.

The solution shall utilize API for data exchanges between Applications following a Service Oriented Architecture (SOA) model.

The solution shall utilize Oracle 19 or newer or SQL Server 2016 or newer along with SQL Server Management Studio v19.1 or newer for managing the SQL Server. (Oracle preferred) NOTE: Only applies to client hosted solution.

Any local solution shall utilize Microsoft Windows Server 2019 or higher, or whichever is most appropriate at the time of award. NOTE: Only applies to client hosted solution.

The solution shall utilize a high-performance, high-bandwidth network to meet its communication requirement. 

The solution shall be deployed in a secured cloud infrastructure. NOTE: Only applies to vendor hosted solution. 

The selected solution responder shall provide software, tools, web services, sample code, interface control documents (ICD) or other schemas in sufficient detail to enable KDOT to integrate future technologies, including but not limited to AVL, GPS or RFID systems.

The selected solution responder shall provide electronic user documentation. The documentation should be sufficient that users can perform the regular functions to produce the desired reports, appropriately input (individually or in bulk) relevant data and parameters, efficiently interface with other systems to exchange data, and manage the various processes related to running a PMS. 

Specification of the KDOT PMS security requirements for the R-PMS system.

The solution shall allow users to log in to the system using their Active Directory account information. It shall also support SAML2, Oauth and other modern SSO authentication methods.

The system shall have a W3C and 508 Compliant Interface.

The system shall comply with State of Kansas standards for accessibility by people with disabilities as outlined the State of Kansas Web Accessibility Requirements. Refer to the following website for more information: https://ebit.ks.gov/itec/resources/policies/policy-1210

The system shall have the ability to load user list via encrypted file batch process or through encrypted services 

The solution shall support multiple user authorization levels, each with a unique set of activities that can be performed by the users. 

The solution shall be able to define several user groups. 

The solution shall allow nested user groups, i.e., one user group may be member or subset of another user group. 

The solution shall be able to provide different security access for each user group. 

The solution shall be able to assign each user account to a default user group. 

The solution shall have the ability to configure access, menus, and window views based on user group. 

The solution shall restrict access by role to protect against fraud and error. This includes transaction and data set protection. Users should only be able to access screens or fields to which they have been granted access rights. 

Application will use non-administrative accounts to access the database.

System must support changing default passwords or disabling of default local accounts (root, admin, sa).

The revealing of session tokens in URL parameters or error messages is prohibited.

Applications must provide the ability to manually log off of the application.

Sessions will time out and terminates a connection after a period of 30 minutes of inactivity or at the end of a session.

The system shall automatically time out after user defined time of inactivity. Inactivity is defined as no user interaction with the system

The solution shall provide security authentication and authorization mechanisms including but not limited to an authentication framework that secures both web based access and web services, a web service authentication utilizing same authentication scheme, but extended for web services etc. 

The solution shall keep a log of information related to the processes attempted to violate the security protocol including but not limited to the Denial of Service (DOS) attacks, repeated failed log-ins, attempts to insert malicious code, cross-scripting attempts etc. of The solution. The information of such a security violating process that need to be stored shall be defined in The solution design document. 

The solution shall automatically block IP addresses of the processes that attempt to violate the solution security protocol including but not limited to the Denial of Service (DOS) attacks, repeated failed log-ins, attempts to insert malicious code, cross-scripting attempts etc. 

The system shall use a SHA2 256 bit or better encryption algorithm.

The system shall automatically time out after user defined time of inactivity. Inactivity is defined as no user interaction with the system.

System data shall be housed in the continental United States. All KDOT data should be segregated from other customer data to prevent unspecified actions towards these other customers adversely affecting KDOT data

The system shall keep a log of all changes made to data within the system. The log should contain who made the change, the date the change was made, and a brief description of what was changed. This log should be designed for efficiency so that batch operations are not negatively impacted by the logging function.

For a hosted system, the vendor shall supply KDOT with its backup and disaster recovery policies and procedures. These procedures should provide an efficient data protection and recovery plan that would quickly recover system data. 

If KDOT determines self or third-party hosting is the appropriate solution, the vendor shall provide details of hardware required to operate the system. These details should include but are not limited to the number of servers the role of each (DB, IIS, application, backup), server type (physical, virtual), and storage type as well as any other hardware or other environmental requirements for the proposed solution (RAM, processing power, etc.)

If KDOT determines self or third-party hosting is the appropriate solution, the vendor shall provide an estimate of costs required to purchase, install, and configure the required hardware per SYH-1 above. 

The system needs to allow for users to import data by manual entry or through uploads that check the data validity, but don't require users to suspend application integrity checks or toggle table dependencies each time.