RFP 7254.1_Attachment F_Technical_Requirements.xlsx
XLSX spreadsheet 91 KB Posted
- Attached to
- Transportation Routing System
- Solicitation number
- BPM058275
- Issued by
- Montgomery County, Robinwood CDP, Maryland
About this file
This is a Technical Requirements document (Attachment F) for Montgomery County Public Schools (MCPS) in Maryland, which is seeking a comprehensive transportation routing system solution to replace its existing routing platform. The RFP solicits qualified vendors to provide a system that will serve as the primary record for student transportation routing across the district. The document establishes detailed technical specifications and system requirements that the proposed solution must meet to be considered for award. The technical requirements encompass functional capabilities, system performance standards, integration requirements, and operational specifications necessary to support the district's transportation routing operations.
The technical requirements document outlines mandatory system functionalities including routing optimization, real-time tracking capabilities, driver and student management modules, GPS integration, mobile application support, and reporting and analytics features. The solution must demonstrate compatibility with existing district infrastructure and comply with data security and privacy standards applicable to educational institutions. Performance requirements specify system reliability, uptime guarantees, response times, and scalability to accommodate the district's student population and transportation fleet. The document establishes technical standards for system architecture, database requirements, user interfaces, and technical support provisions that prospective vendors must address in their proposals to demonstrate compliance and capability to deliver a solution meeting MCPS operational needs.
View the file
Other files
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
Technical Requirements
| RFP 7254.1 | |
| Attachment F | |
| Technical Requirements |
| Montgomery County Public Schools | Division of Transportation Services | |||||
| Appendix B - Technical Requirements | RFP [RFP Number], Transportation Routing Software | |||||
| ID | Category | Requirement Description | Priority | Offeror Response | Offeror Comments / Reference |
| Routing - General Functionality | |||||
| REQ-001 | Routing - General Functionality | The system must be able to analyze non-eligibility zones that establish walk zones for each school based on district criteria. | High | ||
| REQ-002 | Routing - General Functionality | Field trip management functions and browser-based functions to process field trip requests must be included in the software package. | Low | ||
| REQ-003a | Routing - General Functionality | The system must support creation and maintenance of special needs routing. | High | ||
| REQ-003b | Routing - General Functionality | The system must support creation and maintenance of vocational routing. | High | ||
| REQ-003c | Routing - General Functionality | The system must support creation and maintenance of out-of-district routing. | High | ||
| REQ-003d | Routing - General Functionality | The system must support creation and maintenance of multiple-school drop-off routing. | High | ||
| REQ-003e | Routing - General Functionality | The system must support creation and maintenance of McKinney-Vento (homeless) student routing. | High | ||
| REQ-004 | Routing - General Functionality | The system must support routing of mainstream students (e.g., home to reg ed school, reg ed school to sped school midday, sped school to home). | High | ||
| REQ-005a | Routing - General Functionality | The system must support "pairing" of schools so that students can be routed in association with paired schools. | High | ||
| REQ-005b | Routing - General Functionality | The system must support ride-throughs, allowing a student to be assigned to an existing route as a ride-through without the route's assigned school treating the student as one of its own. | High | ||
| REQ-006 | Routing - General Functionality | Access rights must be defined by user roles, with each member inheriting the rights of the assigned role(s). The system must include a depot-level permission that lets depots manage and change General Education routes (including Pre-K) without interrupting the routers' workflow, while protecting Special Education routes. | High | ||
| REQ-007 | Routing - General Functionality | The system must provide fine-grain control over functional elements such that users may be granted view, edit, and/or print abilities independently. | High | ||
| REQ-008 | Routing - General Functionality | The system must provide function-level security for the map so some users can view, some can edit features, and others have full administrative access. | High | ||
| REQ-009 | Routing - General Functionality | The routing system must be capable of running what-if scenarios (e.g., bell time changes, bus capacity changes). | High | ||
| REQ-010 | Routing - General Functionality | Software must support printing and PDF export of maps (single map, selected portions of a map, or batch) on a variety of printer and plotter types. | High | ||
| REQ-011 | Routing - General Functionality | Software must accommodate students' 9-digit unique student ID, an additional family/household ID to identify family and household members, and a 7-digit Synergy Adult ID (to be verified with Synergy developers). | High | ||
| Routing - Map Functionality | |||||
| REQ-012 | Routing - Map Functionality | The user must be able to manually edit or write directions to fit actual roads on route. | High | ||
| REQ-013 | Routing - Map Functionality | The system must allow multiple users to view and edit bus routes simultaneously with user-based security controlling map edits. | High | ||
| REQ-014 | Routing - Map Functionality | The user must be able to see all transportation-eligible students (assigned and unassigned), including students who qualify for transportation due to hazardous-zone residency. Walk-distance eligibility must be configurable as a rule by school level (e.g., Elementary 1 mile, Middle 1.5 miles, High 2 miles). | High | ||
| REQ-015 | Routing - Map Functionality | Software must provide an editable tool listing seating capacity of each bus and must alert the user and prevent the user from proceeding whenever a vehicle exceeds prescribed seats or equipment limits (e.g., wheelchair slots, child restraints). The system must allow definition of every bus type and its capacity, including wheelchair positions, wheelchair riders seated in seats, and the number of other staff on board. | High | ||
| REQ-016 | Routing - Map Functionality | Software must provide a tool that allows users to see available buses across all depots for the specific route being reviewed (fleet-wide coordination), with a data connection to TIMS to manually pull fleet data. | High | ||
| REQ-017 | Routing - Map Functionality | User must be able to click on an existing part of a route and then click on another point, and the software must re-route accordingly. | Medium | ||
| REQ-018 | Routing - Map Functionality | The system must visually indicate which students are assigned to each stop, showing user-defined boundary. | High | ||
| REQ-019 | Routing - Map Functionality | The system must have point-and-click distance measurement to determine walk-to-stop distance or distance between stops. | High | ||
| REQ-020 | Routing - Map Functionality | Software must include an automation option to run route optimization along definable criteria (e.g., reduce number of routes, reduce loads, reduce time, or reduce miles), with the ability to revert back to manual route assignment if desired. | High | ||
| REQ-021 | Routing - Map Functionality | User must be able to manually change speeds, stop times, and load times to adjust actual minutes between stops when system calculations are deemed incorrect. The system should also be able to communicate with Samsara to use GPS traffic patterns for more precise pickup and drop-off times. | High | ||
| REQ-022a | Routing - Map Functionality | When automation is on, the system must assign new students to the nearest stop as they move into the stop's area (automated ranging). | High | ||
| REQ-022b | Routing - Map Functionality | The system must alert the user when ridership exceeds designated load limits. | Low | ||
| REQ-023 | Routing - Map Functionality | System should provide a calendar capable of maintaining district-wide standard school year and summer school transportation schedules, including holidays and early-out days for each school. | High | ||
| REQ-024 | Routing - Map Functionality | The system must allow different schedules on different days for individual schools (e.g., early release on Wednesdays, different professional days or spring breaks for non-public schools). | High | ||
| REQ-025 | Routing - Map Functionality | System must allow early-release days for non-publics (e.g., Foundation 2nd and 4th Wednesday early dismissals). | High | ||
| REQ-026 | Routing - Map Functionality | Stop times, speeds, and directions must be adjustable manually per route; adjustments must not be system-wide changes that affect all routes. | High | ||
| REQ-027 | Routing - Map Functionality | The user must be able to see all students on a route at the same time, not one at a time. | High | ||
| REQ-028 | Routing - Map Functionality | User must be able to see all routes and stops servicing a school or program at once. | High | ||
| REQ-029 | Routing - Map Functionality | Route records must be automatically stamped with the user name and time of change, providing a route-level audit log that allows users to review the change history of a route. | High | ||
| REQ-030 | Routing - Map Functionality | The system must allow the user to manage bulk street and address edits in-house without vendor intervention. | High | ||
| REQ-031 | Routing - Map Functionality | The system must have redistricting and boundary-planning functionality for manipulating school attendance zones. | High | ||
| REQ-032 | Routing - Map Functionality | The user must be able to add or modify street addresses/house numbers as needed. | High | ||
| REQ-033 | Routing - Map Functionality | Permit user edits to boundaries when necessary. | High | ||
| REQ-034 | Routing - Map Functionality | The user must be able to accommodate new streets and/or housing developments not yet on commercial maps. | High | ||
| REQ-035 | Routing - Map Functionality | Allow for multiple routing including current year routing and upcoming year routing. | High | ||
| REQ-036 | Routing - Map Functionality | Make the user aware of any conflicts between a student's special needs requirements and the equipment, bus, or route assigned. | High | ||
| REQ-037 | Routing - Map Functionality | The system must provide a method to update enrollment transactions to the bus routing system through a data connection between Synergy (Student Information System) and the routing system. | High | ||
| REQ-038 | Routing - Map Functionality | User must be able to copy, reverse, or mirror routes via toolbar options to produce a new AM/PM counterpart in one step and accommodate needs and changes. | High | ||
| REQ-039 | Routing - Map Functionality | Software must allow notes at the bus stop level, including importing document files. | High | ||
| REQ-040 | Routing - Map Functionality | Student information (e.g., behavioral protocols) must follow the student as they move routes and schools. | High | ||
| REQ-041 | Routing - Map Functionality | Bus stops must be placed logically relative to the centerline, at the correct corner, not on the centerline itself. | High | ||
| REQ-042 | Routing - Map Functionality | Bus stops must be coded as right-hand only, left-hand only, or cross-street pick-up/drop-off, and automatic route designs must respond to the right-hand, left-hand, or cross-street coding. | High | ||
| REQ-043 | Routing - Map Functionality | The system must allow multiple addresses for a student (e.g., home, daycare) with different pick-up and drop-off on the same or different days. | High | ||
| REQ-044 | Routing - Map Functionality | The system must support overlapping midday trip times on different days of the week for buses that service different schools on different days. | High | ||
| REQ-045 | Routing - Map Functionality | For streets deemed unsafe or poor access (courts, dead ends), the system must be able to automatically route all stops to the nearest safe corner. | High | ||
| REQ-046 | Routing - Map Functionality | The system must support dual bus assignments for students who use multiple buses due to shuttling, custody arrangements, or daycare situations. | High | ||
| REQ-047 | Routing - Map Functionality | The system must allow routing of A-schedule and B-schedule students (e.g., A-day students Mon/Tue, B-day students Thu/Fri). | Medium | ||
| Geographic Information System (GIS) Mapping | |||||
| REQ-048 | Geographic Information System (GIS) Mapping | The system must encode map streets so that students assigned to stops are automatically prevented from walking across hazardous roads to reach a bus stop, even if that stop is closer to their home. | High | ||
| REQ-049 | Geographic Information System (GIS) Mapping | Roads must be encoded to prevent walkers from crossing or walking depending on hazard level and grade level (e.g., safe for high school, not for K-5). | High | ||
| REQ-050 | Geographic Information System (GIS) Mapping | The system must encode transportation data such as one-way streets, travel speeds, no-travel roads, bridges, railroad crossings, and restricted roads. | High | ||
| REQ-051 | Geographic Information System (GIS) Mapping | The system must encode travel-restricted streets and turn restrictions that can restrict larger vehicles yet allow smaller ones, applied automatically so operators cannot make mistakes. | High | ||
| REQ-052 | Geographic Information System (GIS) Mapping | The system must maintain compatibility with the ArcGIS platform. | High | ||
| REQ-053 | Geographic Information System (GIS) Mapping | The system must provide surrounding county maps (DMV area) to accommodate out-of-area students, with the ability to generate reporting on out-of-county students. | High | ||
| REQ-054 | Geographic Information System (GIS) Mapping | The system must provide a Google Earth overlay or other similar satellite-based mapping. | Medium | ||
| REQ-055 | Geographic Information System (GIS) Mapping | Centerlines and addresses (maintained in ESRI format by Montgomery County Government) must be loadable into the route map by MCPS staff without vendor intervention, other than for general support questions. | High | ||
| Implementations, Customer Support, and Training | |||||
| REQ-056 | Implementations, Customer Support, and Training | Vendor must provide maintenance and support throughout software implementation and continued support after implementation while annual maintenance is current. | High | ||
| REQ-057 | Implementations, Customer Support, and Training | Vendor must manage the process of software conversion, including converting all necessary data from existing/legacy systems and providing test conversions to ensure accurate outputs. | High | ||
| REQ-058 | Implementations, Customer Support, and Training | Vendor must provide software training to core operational staff responsible for route creation and distributable training material for other groups (e.g., school-based staff). | High | ||
| REQ-059 | Implementations, Customer Support, and Training | Vendor must train MCPS staff on live and operational data. | High | ||
| REQ-060 | Implementations, Customer Support, and Training | Vendor must provide additional web-based training. | High | ||
| REQ-061 | Implementations, Customer Support, and Training | Vendor should be able to provide additional training upon request. | High | ||
| REQ-062 | Implementations, Customer Support, and Training | Vendor must provide an electronic user manual for users and a technical version for IT staff, including documentation of the database and map database objects/structure. | High | ||
| REQ-063 | Implementations, Customer Support, and Training | Vendor must submit a description of their training plan. | High | ||
| REQ-064a | Implementations, Customer Support, and Training | The routing system must integrate with Synergy Student Information System and/or Active Directory via manual import/export, API, custom or prefab connectors, with scheduled automation for data refresh. | High | ||
| REQ-064b | Implementations, Customer Support, and Training | The routing system must provide an API for data integrations and for in-house reporting and dashboard creation. | High | ||
| REQ-065 | Implementations, Customer Support, and Training | The system must integrate with FASTER Web (Fleet Management). | High | ||
| REQ-066 | Implementations, Customer Support, and Training | The system must integrate with the Transportation Information Module (TIMS). | High | ||
| REQ-067 | Implementations, Customer Support, and Training | System must link employee information with their route. | Medium | ||
| REQ-068 | Implementations, Customer Support, and Training | The bus route field must allow for at least 5 characters. | High | ||
| REQ-069 | Implementations, Customer Support, and Training | Software must accommodate a vehicle's unique VIN number. | Medium | ||
| REQ-070 | Implementations, Customer Support, and Training | Vehicle capacity limits must be embedded in vehicle information and alert the router to possible overload. | High | ||
| REQ-071 | Implementations, Customer Support, and Training | Routing software must pair with GPS software (such as Samsara) for vehicle tracking. | High | ||
| REQ-072 | Implementations, Customer Support, and Training | Software must check planned routes against actual routes. | High | ||
| REQ-073 | Implementations, Customer Support, and Training | Software must support the ability for users to create custom reports and dashboards. | High | ||
| REQ-074 | Implementations, Customer Support, and Training | Software must include informational websites for the public (to find a student's regular bus and bus stop) and for school-based staff (to generate a student list by bus). | High | ||
| REQ-075 | Implementations, Customer Support, and Training | The system must output data to our Synergy student information system to allow transportation data about each student to appear on the parent portal of Synergy. | High | ||
| REQ-076 | Implementations, Customer Support, and Training | The system preferably meets WCAG standards and is ADA compliant. | Low | ||
| REQ-077 | Implementations, Customer Support, and Training | System must allow parents to discover appropriate routing information by entering an address and grade (parent portal), and must be able to provide that data to ParentVUE. | High | ||
| REQ-078 | Implementations, Customer Support, and Training | System must allow school staff to look up and view routing information by entering an address and grade (school portal). | High | ||
| REQ-079 | Implementations, Customer Support, and Training | System must provide an option to display a map with icons for student home, stop, and school (school portal). | Medium | ||
| REQ-080 | Implementations, Customer Support, and Training | System must provide the ability to search for and print stop lists and rosters at each school building, through the browser (school portal). | High | ||
| REQ-081 | Implementations, Customer Support, and Training | System must provide printable student lists with transportation information from the browser (school portal). | High | ||
| REQ-082 | Implementations, Customer Support, and Training | Software must accommodate a school's unique 6-digit school code assigned by the State of Maryland. | High | ||
| REQ-083 | Implementations, Customer Support, and Training | Vendor must provide a dedicated project manager named in the proposal as a main point of contact throughout implementation. | High | ||
| REQ-084 | Implementations, Customer Support, and Training | Customer service calls must be returned within two hours and/or before 2:00 pm EST on the day the call was placed. | High | ||
| REQ-085 | Implementations, Customer Support, and Training | Vendor must provide extended service during the weeks before and after startup each year or during scheduled redistricting effort. | High | ||
| REQ-086 | Implementations, Customer Support, and Training | Vendor must provide upgrades to purchased software and licenses at no additional charge, including all future releases and bug fixes. | High | ||
| REQ-087 | Implementations, Customer Support, and Training | Vendor must provide unlimited refresher training and new employee user orientation (online format minimum). | High | ||
| REQ-146 | Implementations, Customer Support, and Training | Alerts for Route Changes for TIMS group. | Medium | ||
| REQ-152 | Implementations, Customer Support, and Training | System shoudl be able to share data with Synergy, Transportation Imformation System (TIMS), Faster vehicle management system, TOM Field Trip Management database. | High | ||
| System Reporting Capabilities / Data | |||||
| REQ-088 | System Reporting Capabilities / Data | The user must be able to define, sort, sub-sort, and save data as required based on specific queries. | High | ||
| REQ-089 | System Reporting Capabilities / Data | Software must provide cloud-based, on-premises, and/or hybrid hosting options with encryption at all layers, using current TLS standards (TLS 1.2 or higher), to safeguard data at rest and in transit. | High | ||
| REQ-090 | System Reporting Capabilities / Data | All data, and specifically Personally Identifiable Information (PII), must be encrypted at rest and in transit, and comply with FERPA requirements. | High | ||
| REQ-091 | System Reporting Capabilities / Data | Software must have audit capabilities to verify time and identity of individual data access, views, edits, additions, and deletions. | High | ||
| REQ-092 | System Reporting Capabilities / Data | The system must generate the following reports with the same information as current MCPS reports: Bus Summary, Bus Detail, Parent Letter (editable for Extended School Year (ESY) and Current School Year (CSY)), Student Record, Route Detail/Summary, Trip Detail/Summary, Special Education Arrival & Departure Schedules, General Education Arrival & Departure Schedules, Magnet Arrival & Departure Schedules, Manifest with blank load count and odometer reading, Student Lists with census info. | High | ||
| REQ-093 | System Reporting Capabilities / Data | Reports for buses must include route #, vehicle ID, Transportation Cluster Manager (TCM)/Bus Route Supervisor (BRS), Router, Driver/Attendant, parking space #, and revised date/saved date in addition to student and stop information. | High | ||
| REQ-094 | System Reporting Capabilities / Data | User must be able to generate reports from the map screen without switching to a separate application. | High | ||
| REQ-095 | System Reporting Capabilities / Data | User must be able to print reports directly to the printer without first generating a PDF. | High | ||
| REQ-096 | System Reporting Capabilities / Data | System must support generating a student record by name or student ID (not only by student ID). | High | ||
| REQ-097 | System Reporting Capabilities / Data | Student record must include city and state in the student address. | High | ||
| REQ-098 | System Reporting Capabilities / Data | Parent Letters must include city and state. | High | ||
| REQ-099 | System Reporting Capabilities / Data | Parent Letters must be generatable by student name, student ID, and/or program (not only by school, route, or effective date). | High | ||
| REQ-100 | System Reporting Capabilities / Data | System must handle and schedule multiple middays on different days for the same bus/route, including middays that are for the same bus on different days at the same time (e.g., Germantown ES School Community Based Program (SCBP) shuttle on Tuesdays, Gibbs ES speech on Wednesdays, Longview shuttle on Thursdays). | High | ||
| REQ-101 | System Reporting Capabilities / Data | System must allow removal of a stop without requiring the user to enter a reason each time (while routing is in progress). | High | ||
| REQ-102 | System Reporting Capabilities / Data | Student records must print detailed comments and full names (no truncation). | High | ||
| REQ-103 | System Reporting Capabilities / Data | For students routed to and from the same home address, printed student records must show the address as both pick-up and drop-off (not blank for drop-off). | High | ||
| REQ-104 | System Reporting Capabilities / Data | System must be able to generate arrival and departure schedules by program (Special Education, General Education, Magnet, midday Preschool Education Programs (PEPs)), not only by school. | High | ||
| REQ-105 | System Reporting Capabilities / Data | System must generate student records in under one minute for a typical record. | High | ||
| REQ-145 | System Reporting Capabilities / Data | Customize the Run sheet. | High | ||
| REQ-147 | System Reporting Capabilities / Data | Keep routing history of each student. History should restoreable until the student is 21 | High | ||
| REQ-160 | System Reporting Capabilities / Data | The system shall provide the ability to easily export all reporting data for further analysis or archiving purposes. | |||
| REQ-161 | System Reporting Capabilities / Data | The system shall provide Real-time system status monitoring and reporting capabilities | |||
| REQ-162 | System Reporting Capabilities / Data | The system shall provide comprehensive reporting and analytics tools to allow Ad-Hoc reports to be generated for viewing and downloading | |||
| Field Trip | |||||
| REQ-106 | Field Trip | Field trip software must be calendar-based and integrated into the routing software. | Medium | ||
| REQ-107 | Field Trip | Calendar must allow users to create blackout dates for holidays, testing, school-specific closures, and similar events based on school bus availability. | Medium | ||
| REQ-108 | Field Trip | Software must provide complete service invoices and access to customized field trip request forms and approval paths. | Medium | ||
| REQ-109 | Field Trip | Software must provide an electronic invoice payable directly to the MCPS accounting department. | Medium | ||
| REQ-110 | Field Trip | Software must be able to obtain historical records of the field trip approval process, track status of any bus trip, and monitor changes, stamping each change with date, time, and name of processor. | Medium | ||
| REQ-111 | Field Trip | Software must support automated driver rotation to assign field trips based on availability, seniority, or alphabetical order, and produce sign-up forms when drivers pick trips. | Medium | ||
| REQ-112 | Field Trip | Users must be able to view field trip GPS information within the field trip software or in a centralized tracking site, identifying the vehicle as being on a field trip. | Medium | ||
| REQ-113 | Field Trip | System must provide a color-coordinated dispatch calendar that displays conflicting bus schedules, elicits coverage, and monitors bus driver service hours. | Medium | ||
| REQ-114 | Field Trip | Trip scheduling software must assist schools with daily bus and driver coverage, including detailed route and field trip check-in information for administrators. | Medium | ||
| REQ-115 | Field Trip | System must send field trip itineraries with integrated turn-by-turn directions to the bus-mounted tablet for each bus driver. | Low | ||
| REQ-116 | Field Trip | Software must provide the user the ability to track all field trip costs in a centralized place with the ability to run reports and export data to Excel and other data-collection platforms. | Medium | ||
| REQ-117 | Field Trip | Software must interface the billing component with Oracle Cloud Business Hub for direct invoicing to schools through accounts receivable and also interface with Business Hub general ledger to create journal vouchers charging specific GL accounts (driven by field trip codes entered by schools/departments). | Medium | ||
| REQ-118 | Field Trip | System must include workflow approval to principals, directors, or other assigned staff based on requests before they reach the Field Trip office. | Medium | ||
| REQ-119 | Field Trip | System must have a map function for determining mileage and hours of a trip request to calculate field trip cost. | Medium | ||
| Parent App | |||||
| REQ-120 | Parent App | Provide a secure public app ('Parent App') to find the status, location, and anticipated arrival of their child's bus. | High | ||
| REQ-121 | Parent App | The Parent App must use onboard GPS data to provide bus location and estimated time of arrival (ETA). | High | ||
| REQ-122 | Parent App | The Parent App must provide depot contact information (e.g., phone number, Transportation Cluster Manager (TCM), Depot Manager (DM), special needs office) directly in the viewing screen for ease of communication. | Medium | ||
| GPS | |||||
| REQ-123 | GPS | Vendor must explain how their routing software integrates with GPS (offers a GPS solution, works with other GPS vendors, or both) and provide an example/explanation of best practices for routing and GPS implementation. | High | ||
| REQ-124 | GPS | GPS must include data points such as speed, door open, stop arm deployment, hard stop, and historical breadcrumbs. | High | ||
| REQ-125 | GPS | GPS must feed anticipated arrival to schools through a school-facing app or webpage that displays ETAs, so staff can proactively anticipate late buses and communicate; the arrival board only posts buses for routes to that school. | Medium | ||
| REQ-126 | GPS | GPS must review route data and provide a planned-vs-actual report/screen for routers to view. | High | ||
| Student Medicaid Tracking | |||||
| REQ-127 | Student Medicaid Tracking | Provide a mechanism to collect and track student transportation Medicaid-reimbursable services on a daily basis. | Medium | ||
| REQ-128 | Student Medicaid Tracking | Data must be available to be downloaded in PDF or Excel format. | Medium | ||
| Bus Mounted Tablet | |||||
| REQ-129 | Bus Mounted Tablet | All routing and field trip routes must be remotely sent to bus tablets nightly. | Medium | ||
| REQ-130 | Bus Mounted Tablet | Student information stored in routing software must be displayed on the tablet (e.g., behavioral protocols, allergies). | High | ||
| REQ-131 | Bus Mounted Tablet | In-bus units must assist drivers by displaying route and stops with audible turn-by-turn directions to eliminate paper route sheets. | High | ||
| REQ-144 | Bus Mounted Tablet | Ability to output turn by turn directions to bus based mobile devices for driver directions. | High | ||
| Student Tracking | |||||
| REQ-132 | Student Tracking | In-bus GPS units must include the capability to track students. | High | ||
| REQ-133 | Student Tracking | The system must utilize various log-on/off technologies, including the bus-mounted tablet. | High | ||
| REQ-134 | Student Tracking | Generate reports that show various student ridership data. | High | ||
| REQ-135 | Student Tracking | Ridership data must be incorporated in the routing, parent application, and field trip modules. | High | ||
| REQ-136 | Removed | ||||
| Data Conversion and Migration | |||||
| REQ-137 | Data Conversion and Migration | The conversion from the current MapNet system must support a blackout period during conversion, with the ability to run a report identifying any changes made during the blackout so they can be applied post-conversion. | High | ||
| REQ-138 | Data Conversion and Migration | The system must support search on a street name (not just corner stop or address). | High | ||
| Geocoding and Address Handling | |||||
| REQ-139 | Geocoding and Address Handling | The system must allow notations on stops (e.g., temp stop until through road completed) with edit notes directly on a route segment. | High | ||
| REQ-140 | Geocoding and Address Handling | When searching for an address on the map, the location pin must remain while the user searches for another address (persistent pins). | High | ||
| Reporting | |||||
| REQ-141 | Reporting | Must be able to generate reports on distance specific stops (McKinney-Vento, daycare, etc) add to a route as a deviation. | High | ||
| Dispatch and Depot Communications | |||||
| REQ-142 | Dispatch and Depot Communications | Dispatch module that would allow Dispatchers to adjust routes for different scenarios. | High | ||
| REQ-143 | Dispatch and Depot Communications | Messaging system for depots to get updates and changes. | |||
| Data Ownership, Security, and Privacy | |||||
| REQ-148 | Data Ownership, Security, and Privacy | MCPS will own all data generated that pertains to Routes, Students, Buses, Schools, addresses and Maps, etc. The data will be availble for MCPS Custom exports for MCPS uses and reporting and will be made availabe to MCPS if the contract is terminated for the purposed of converting to another product. | High | ||
| REQ-159 | Data Ownership, Security, and Privacy | The vendor must provide a current SOC 2 Type 2 report to verify the effectiveness of their security controls and commitment to data integrity and confidentiality over a sustained period. | High | ||
| REQ-163 | Data Ownership, Security, and Privacy | The system shall comply with all federal, state, and local privacy laws regarding the capture, viewing, storage, and archival of data | High | ||
| REQ-164 | Data Ownership, Security, and Privacy | The system owner shall have the ability to execute regular security assessments and vulnerability testing | High | ||
| REQ-165 | Data Ownership, Security, and Privacy | The vendor shall provide Disaster recovery and business continuity plans | High | ||
| REQ-166 | Data Ownership, Security, and Privacy | The system shall provide the ability to enforce MultiFactor Authentication (MFA) for greater security | High | ||
| REQ-167 | Data Ownership, Security, and Privacy | The system should support Single Sign On (SSO) for MCPS personnel | High | ||
| REQ-168 | Data Ownership, Security, and Privacy | The system shall provide Data storage and transmission must be secure and encrypted both in transit and at rest. | High | ||
| REQ-169 | Data Ownership, Security, and Privacy | The vendor shall provide disclosure of how/where MCPS data will be securely stored, including but not limited to the hosting and access to data | High | ||
| REQ-170 | Data Ownership, Security, and Privacy | The vendor must commit to not selling, sharing, or using student data for any purpose other than providing the educational service outlined in the contract. | High | ||
| REQ-171 | Data Ownership, Security, and Privacy | The vendor must ensure that the tool only collects the data that is essential for its functionality | High | ||
| Hosting, Security, and Service Levels | |||||
| REQ-150 | Hosting, Security, and Service Levels | The vendor must provide a Service Level Agreement (SLA) for the hosted/production routing service that includes, at minimum: (1) Availability — guaranteed uptime of at least 99.9% measured monthly (approximately 43 minutes of allowable downtime per month), with 99.95% targeted during peak operational periods, defined as the route-creation period of June through September (Monday–Friday) and, for dispatch-related functions, the morning rush during the school year; "available" means the service is both accessible and functionally operational for all critical features. (2) Scheduled maintenance — performed within defined, pre-announced maintenance windows (minimum 5 business days' notice) and excluded from downtime calculations. (3) Support response and resolution by severity: Severity 1 (system down / critical function unusable, no workaround) — response within 1 hour and continuous effort to resolution (4-hour target); Severity 2 (major function impaired) — response within 4 business hours, resolution target 1 business day; Severity 3 (minor issue / workaround available) — response within 1 business day, resolution in a future release. (4) Support coverage — defined business-hours coverage with emergency/after-hours escalation, including extended coverage during start-up and redistricting periods. (5) Remedies — escalating service credits applied against fees when committed levels are missed (tiered by breach severity), claimable within 30 days, with sustained or material breach constituting grounds for termination. (6) Monitoring and reporting — real-time status/availability reporting and a monthly SLA performance report. (7) Data protection — defined backup frequency and recovery objectives (RPO/RTO) plus a disaster recovery/business continuity commitment. | High | ||
| REQ-151 | Hosting, Security, and Service Levels | SQL Server is prefered. | High | ||
| REQ-153 | Hosting, Security, and Service Levels | 15 users /300 web users | Medium | ||
| Artificial Intelligence Transparency and Governance | |||||
| REQ-154 | Artificial Intelligence Transparency and Governance | Does the product use Artificial Intelligence? | High | ||
| REQ-155 | Artificial Intelligence Transparency and Governance | Vendor details what data AI is trained on and what data is being collected by AI | High | ||
| REQ-156 | Artificial Intelligence Transparency and Governance | Vendor details the accuracy of the AI system and how errors are reviewed and corrected | High | ||
| REQ-157 | Artificial Intelligence Transparency and Governance | Vendor details how AI system addresses student privacy concerns | High | ||
| REQ-158 | Artificial Intelligence Transparency and Governance | Vendor's responses align with district’s acceptable use, data privacy, and academic integrity policies. | High |
Instructions Instructions: Offerors shall respond to every requirements listed by selecting one response from the drop-down in the "Offeror Response" column (Comply, Comply with Exception, Future Release, or Does Not Comply) and providing a brief explanation, product feature name, or document reference in the "Offeror Comments / Reference" column. "Comply" means the capability exists today in the proposed release. "Comply with Exception" and "Future Release" responses must be fully explained, including the target availability date for any future capability. Priority reflects MCPS operational need and is informational; all requirements are subject to evaluation.
File details come from the government source that posted it. Updated .