Attachment E - Functional Requirements and Scenarios.pdf

Attachment E: Unified Functional Requirements and Function Scenario Narratives This document outlines Use Case Scenarios, which provide challenge-based tests to evaluate vendor performance on complex, real-world operational needs.

For context, the following table outlines the scale of Portland Public Schools' student transportation operations. All functional requirements must demonstrate the capability to support a large urban school district at this operational volume.

Element Count Details

Students 43391 All current students for PPS. Many live in walk areas and we will still need data on these students for assessing those areas.

Assigned Riders 8287 All the students who ride the bus

ST 941

Students receiving service for specialized programs, including Special Education - curb to curb service.

GT 7346 Students receiving big bus - neighborhood service

Element Count Details

Routes 548 Includes all bus routes as well as up to 250 contracted cabs

Runs 1146 Also known as portions or tiers

ST 177 Routes that provide curb to curb service

GT 121 Routes that provide neighborhood service

Cab up to 250 Contracted routes that often service one student for a long distance

Contractors 13 All contracted companies, does not include district provided service that is also a component of our operation.

Yellow Bus 2 Currently split geographically between First Student and Student Transportation of American

Type 10 6 up to 10 in the future

Motor Coach 5 Contractors rarely used for field trip service

Element Count Details

Drivers 409 Total for the district (excludes cab drivers)

PPS 118 Portland Public Schools District employees

FS 216 First Student

STA 75 Student Transportation of America

Functional Scenario Narratives To ensure our next routing vendor can handle the unique complexities of Portland Public Schools, we must move beyond basic feature lists. The following scenarios are designed as "Challenge Tests" based on our current operational friction points, contractual obligations, and specialized student needs.

The scenarios must be presented in writing with proof of script. These scenarios and the responses to them may also inform the demonstration Tier 2 phase of evaluation.

Scenario 1: Data Integrity & SIS integrations The Challenge: Addressing the "unlocated student" cycle and manual override persistence.

Context: Our current routing system frequently "breaks" student assignments when address data from our Student information System (currently Synergy) includes apartment numbers or unit designations in a format the software doesn't recognize.

Additionally, any manual workarounds applied by the routing team are often overwritten by the nightly data import.

Vendor Task:

● Demonstrate how the system handles non-standard address strings (e.g., "5300 NE Cully Blvd APT 79") without flagging them as unlocated.

● Show the process for "locking" a manual geographic placement so that a nightly sync from the SIS (currently Synergy) updates student attributes (grade, program) but does not revert the validated stop assignment.

● Explain how the system identifies and flags specifically new data errors rather than requiring a manual review of the entire "unlocated" list every morning.

● Demonstrate how you would do this specifically with Synergy SIS.

Scenario 2: Specialized Service & Manual Overrides The Challenge: Managing the "Real-World" vs. "System-Calculated" gap.

Context: For transportation with the added nuance of student accommodations, automated time calculations often fail to account for real-world travel needs. We need the ability to manually adjust stop times without the system "fighting" the user.

Vendor Task:

● Demonstrate the manual override process for a specific trip segment where the user needs to set a hard departure time that differs from the system's calculated ETA. Show how the system integrates that manual change in routing moving forward.

● Demonstrate how the system learns routing system adjustments to suggest changes to other routes that could benefit from that manual change.

● Demonstrate the ability to manually insert a stop time and override existing route pattern.

● Show how equipment changes (adding a wheelchair or safety support) automatically trigger a capacity check and potential student shuffle based on the "lowest impact" priority.

Scenario 3: Modeling and Optimization The Challenge: Modeling large scale system changes for efficiency and cost savings is hard to create with actionable data. These decisions at scale can have impacts well into the millions.

Context: We currently create “sandboxes” to test everything from simple route adjustments to large scale bell time and program shifts. The current system does not have a true optimization tool for analyzing overall efficiencies both at the route/run level or for driver count that directly impact our bottom line.

Vendor Task:

● Show how your software is able to model complex changes with efficiencies at the forefront.

● The model should produce the amount of stops, routing times, and other key data points to best inform decision making. A description of out-of-the-box data analysis vs. customizable options is required (config vs. code).

● Demonstrate how you provide actionable data for detailed analysis. Show the actionable data created from modeling in comparison to current or historical route sets.

● Demonstrate how the system quantifies the budget impact of proposed changes, including potential savings or costs for driver labor, fuel, and overall fleet operational expenses.

● Nice to have: out-of-the-box dashboards and/or customizable dashboards.

Scenario 4: Dynamic Resource Optimization for Specialized Needs The Challenge: Managing fleet capacity when new students with IEPs or specialized accommodation needs are added mid-year, requiring a redistribution of load without increasing the total number of routes.

Context: We often face "density crunches" where adding just a few students with specialized needs creates a cascade effect on existing routes. We need to maintain the current route count (due to driver staffing constraints) while absorbing these students into existing runs without exceeding time or safety limits.

Vendor Task:

● Demonstrate the "cascade impact" analysis: When adding new students with specific accommodation needs (e.g., wheelchair lifts, specialized monitors), show how the system suggests the most efficient redistribution across multiple affected routes.

● Show "optimization constraints": Demonstrate how to force the system to prioritize maintaining the current number of routes while shifting stops, rather than simply creating a new route.

● Validate Capacity vs. Accommodations: Show how the system handles the conflict between "per-seat" capacity and "space-per-accommodation" needs (e.g., how many standard seats a wheelchair takes up) to ensure real-world safety compliance.

Scenario 5: End-to-End Special Education Routing Workflow The Challenge: Bridging the communication gap between IEP development and operational routing implementation to ensure no specialized request is lost.

Context: Currently, there is a lack of visibility between the initial accommodation request (e.g., a new IEP requirement) and the actual route assignment. We need a unified workflow that tracks a student's transportation status from the initial submission to the final "Active" route deployment.

Vendor Task:

● Demonstrate the "Lifecycle Visibility": Show how the system tracks a new transportation requirement through the stages of "Pending," "In-Review," and "Implemented."

● Show the "Safety Validation": Demonstrate how the system prevents a route assignment that fails to match the student's required equipment (e.g., ensuring a lift-equipped vehicle is assigned for a student with mobility needs).

● Demonstrate the "Notification Workflow": Once a route is assigned, show how the system automatically triggers an update to the school, driver and parent portals, confirming that the requested accommodations are in place for the first day of service.

Scenario 6: Contingent Network Data & Hazard Zone Definition The Challenge: Automating hazard zone classification using complex, contingent network data and conditional logic.

Context: Our definition of a "Hazard Zone" is dynamic, derived from conditional logic applied to our underlying road network. To maintain safety compliance, the system must automatically ingest and process network attributes (speed limits, sidewalk existence, lane counts, high-crash history, and crossing controls) to designate zones. We need the system to apply the following logical rulesets to define these zones automatically:

● Walking: Restricted if speed limit > 20 mph, or if the road is in a High Crash Network AND no sidewalk is present.

● Crossing: Restricted if speed limit > 20 mph AND no crossing controls (signal/crosswalk) are present.

● Crossing: Restricted if speed limit > 25 AND (the street is 2+ lanes AND no 4-way stop/signal/crosswalk) OR (the street is > 2 lanes AND no signal/crosswalk) are present.

● Crossing: Restricted if the road is part of a High Crash Network AND (the street is 2+ lanes AND no 4-way stop/signal/crosswalk) OR (the street is > 2 lanes AND no signal/crosswalk) are present.

● Crossing: Restricted if the road is 4+ lanes in a High Crash Network (Exception: Crossings in school zones with crosswalk and traffic controls present).

Vendor Task:

● Demonstrate how the system ingests "contingent network data" and translates the logic above into automated, geofenced hazard zones.

● Show how the system recalculates these zones dynamically when underlying network data (e.g., speed limit updates, new crossing control installations) is refreshed.

● Provide a workflow for auditing how a specific road segment was classified, showing the underlying data variables that triggered the restriction.

● Show how this impacts stop assignment at the student level

Scenario 7: Hazard Zone Analysis & Reporting The Challenge: Establishing hazard zones within the walking boundary using road network restrictions and accurately reporting mileage for state compliance.

Context: We need to define walking boundaries while identifying specific "Hazard Zone" where walking is deemed unsafe due to road conditions or infrastructure. We must be able to isolate and calculate total miles traveled within these specific zones for mandatory state reporting purposes.

Vendor Task:

● Demonstrate how to define "Hazard Zones" (e.g., high-traffic intersections, construction areas, or specific infrastructure) as polygon layers or road segment restrictions within the walking boundary.

● Show the system's reporting capabilities: How can we automatically calculate and export the total mileage students are transported specifically within these defined hazard zones?

● Provide evidence of how the system handles boundary overlaps and ensures accurate mileage tracking when a route partially traverses a hazard zone.

● Demonstrate how to differentiate in reporting between routes that are merely passing through a hazard zone and routes that are actively servicing students (making stops) within that zone.

● Demonstrate how to analyze and flag students who reside within the defined Hazard Zone as a persistent, reportable attribute to support analysis.

Scenario 8: GIS Integration, Data Alignment, and External Exchange The Challenge: Ensuring the routing system matches the district official GIS infrastructure records while maintaining seamless data exchange with external mapping platforms.

Context: We maintain detailed GIS layers for school zones, emergency management infrastructure, and recent road network changes. Often, the routing software operates on a separate, generic map provider, leading to discrepancies where the routing system doesn’t show new subdivisions or pedestrian infrastructure that our GIS department has already mapped. Additionally, we need the ability to share our routing data, such as calculated hazard zones and stop locations, back to emergency management and GIS departments to ensure district-wide collaboration.

Vendor Task:

● Demonstrate the ability to ingest and overlay external GIS shapefiles or web services (e.g., WMS/WFS) directly into the routing interface.

● Show how the system can utilize district-provided GIS layers as a data source for network restrictions, overriding generic map data when conflicts occur.

● Explain the synchronization process: How often does the system check for updates to these external GIS layers, and how does it handle data schema mismatches (e.g., coordinate system differences)?

● Demonstrate the ability to export road network data, routing data, hazard zones, and stop locations to external mapping systems and GIS services, ensuring compatibility with standard geospatial formats (e.g., GeoJSON, KML, Shapefiles).

Scenario 9: Driver Feedback Loop & Real-Time Adjustment The Challenge: Closing the loop between operational reality on the road and routing plans by enabling systematic driver feedback and manual time adjustments.

Context: Drivers are the experts on the ground, yet they often lack a formal mechanism to report timing discrepancies or stop safety issues. When feedback is provided (often via phone or email), it is disconnected from the routing software, leading to a "silo" where the system remains inaccurate. We need a way for drivers to submit feedback that links directly to a route or stop record for the routing team to act upon, and subsequently, a clean workflow for planners to review, adjust, and update the schedule.

Vendor Task:

● Demonstrate a mobile or integrated "Driver Input" interface where a driver can flag a specific stop or route segment as having a timing or safety issue.

● Show how this feedback is routed into the planning software and presented to the routing team as a pending "Request for Review" task.

● Demonstrate the workflow for a planner to validate the feedback (e.g., using GPS data to verify the timing issue), apply the change, and automatically communicate the update back to the driver's manifest.

Scenario 10: Dataset Management & Effective Date Cycles The Challenge: Maintaining operational stability while modeling complex seasonal transitions, bulk data updates, and future-dated changes without requiring full-database replication or manual, day-of-change overrides.

Context: Our routing operations require a system that supports multiple independent datasets that can be activated or deactivated separately. We need the ability to model complex seasonal transitions and bulk data updates—such as new IEP accommodation requirements or full student roster updates—in separate datasets without impacting current fleet operations. Furthermore, we require granular 'Effective Date' management, allowing updates to occur at the student, route, or map level on specific dates without modifying unrelated data. This ensures seamless transitions between operational periods (e.g., Summer School to Fall Start) and precise control over when changes take effect.

Vendor Task:

● Demonstrate the independent dataset architecture: Show how planners can model data for large-scale changes in a separate dataset and then activate or deactivate it without impacting current operations, avoiding the need for parallel databases.

● Demonstrate Granular Effective Date Management: Show how the system allows scheduling updates at the student, route, or map level for a future effective date. Prove that the system can apply these changes automatically on the specified date while leaving all non-updated data in its original, active state.

● Show the IEP data isolation workflow: Demonstrate importing a bulk file of new IEP accommodation requirements into a separate dataset to model the impact on routes, ensuring these changes are kept separate from the active environment until validated and approved.

● Demonstrate Change Tracking: Show how the system tracks 'pending' versus 'active' configurations, allowing planners to preview the impact of future-dated changes before they go live.

Scenario 11: Dynamic Student Address & Custody Management The Challenge: Accommodating complex student residency patterns, including dual-household custody and time-of-day specific stop assignments, without manual weekly routing overrides.

Context: A significant portion of our student population requires transportation to or from different addresses based on a recurring schedule—such as alternating weeks between parents or different morning/afternoon locations. Our routing system must support multiple active addresses per student and automatically assign the correct route based on the calendar day and time of service.

Vendor Task:

● Demonstrate how the system handles recurring, schedule-based address assignments (e.g., alternating weeks or AM/PM split addresses) and how it maintains routing accuracy and manifests for these students automatically.

● Demonstrate how driver manifests and paperwork clearly reflect these scheduled address variances, ensuring drivers are aware of the correct stop location based on the specific day or time.

Scenario 12: Bell Time & Tiered Routing Analysis The Challenge: Modeling system-wide bell time shifts while simultaneously managing the complexity of tiered routing (daisy-chaining runs).

Context: Our district relies on a tiered routing structure where buses perform multiple runs (e.g., High School, then Middle School, then Elementary). When we adjust a bell time at one school, it creates a ripple effect across all tiered runs. We need a way to model how a bell time change at a specific school impacts the entire chain of routes, driver availability, and total fleet requirements.

Vendor Task:

● Demonstrate the ability to perform a "Bell Time Impact Study" by adjusting the start/end times of a specific school.

● Show how the system recalculates the cascading impact on subsequent tiered runs (e.g., if a High School starts earlier, how does it affect the "tier 2" middle school run?).

● Demonstrate the system's capacity to optimize the schedule to accommodate these shifts while maintaining the current number of drivers and buses.

● Show how the model highlights "deadhead" time and idle time as a result of the bell time shifts, providing data to justify efficiency gains or losses.