GENERAL SYSTEM CHARACTERISTICS The software should be a true Windows Client/Server program. The software should be currently installed and operational under any Microsoft supported Windows operating system. The system should be capable of operating across a network. The system should operate on Windows and Novell networks, as selected by the user, and correctly support multiple simultaneous users. The vendor should indicate any extra charges for network installation and/or support for networked systems and any extra charge for each workstation. The system runs in a windows environment, meaning several windows can be open at the same time. Such as multiple student windows, multiple route windows, and stop window all open at the same time. The system should not require the use of unique plug-ins for browsers. Every user must have an individual username and password. The system must provide specific user level access, such as No Access, Read Only or Full Access to specific functionality throughout the program. The system must track changes to information by users and report interactively the date and individual making the changes. Updated routing reports must be made available for just those routes that have changed. The system provides record locking for handling attempts by two or more users to update the same record at the same time, but still allows any number of additional users to access the same record concurrently as Read Only. The system must be capable of handling the current district population, as well as growth. The system must be capable of user updates, such that the district can maintain all facets of the system without vendor intervention (students, map, software, etc). The vendor will explain any tasks that do or should require vendor assistance and the cost for that assistance. 1
If the system is available with modules, the vendor shall indicate the modules that meet the specifications and note whether or not they are currently available in the proposed version. All modules necessary to meet the specifications should be included in the system price. The system should present users options in understandable English phrases without the use of codes and jargon. The system is SIF CERTIFIED. The system should be integrated so that data entered in one section of the system immediately becomes available to all other parts of the system in order to preserve system integrity without having to run maintenance tasks. If maintenance tasks are required for this to occur, the vendor will explain the various tasks in detail. The system should provide a series of automatic checks to assist the user in maintaining an accurate and complete system. The system should display and print the inaccurate/incomplete data and then indicate the steps to be taken to create accurate and complete data. All items in the drop down lists in the system should be user defined. THE ELECTRONIC MAP The vendor shall supply an electronic map of the school district, accurately representing the streets required by the district for its transportation needs including any geographic area outside the district where buses travel. Any data preparation required of the district to prepare the map will be clearly delineated. The district should have all of the tools and training necessary to update the map without vendor intervention. The user must be able to add streets, assign address ranges, change street names, and set speed limits without vendor involvement. The map and all map functions should always be available and displayed regardless of what other windows are open in the system. 2
All map editing, routing, and redistricting functions must be performed on the same map screen. The map shall have the capability of displaying the following map features: street names, schools, transfer locations, depots, bus stops, house locations, hazardous roads, road blocks, one-ways, height and weight restrictions, turn restrictions, landmarks, water bodies, parks, and railroads in user defined font size and colors. The system shall have the ability to display bus stop locations by school, grade, race, and any user defined criteria. The user shall have the ability to display bus stops that are routed or not routed independently of each other. The system shall have the ability to display house locations by school, grade, race, walker, rider, and any user defined criteria. The system should have the ability to display information about map features such as address ranges and street name, bus stop description, address of house, name of school or depot, etc. The system shall have the ability to list boundaries, stops and routes applicable to a specific address, intersection, or point on the map. The user shall be able to easily update mapping information (such as adding or editing house numbers, adding or editing streets, adding or editing bus stops) for the current student or route record without closing these windows. The system allows for seamless map modifications to other users no need to run separate utility to update map changes. The map should have a scale. The map should display dynamic latitude and longitude coordinates. The system offers Google satellite where the user can see street level and aerial views. The system must support alpha-numeric student ID. STUDENT DATA CAPABILITIES The system should allow an unlimited number of addresses for each student. 3
The system should accommodate a minimum of five (5) pickup and drop off locations for each student in the database. Each day should accommodate different schools, bus stops, and vehicles for students for each day of the week, morning and afternoon. Students can be assigned to bus stops either manually or automatically. The system must allow the user to select an area of the map to move students in single or batch mode from one bus stop, school or vehicle to another. The system automatically identifies transportation eligibility based on user defined distance to school parameters, student s address, and/or attendance boundary location. The assignment of the student to a bus stop should recognize district walk-to-stop policies. The system should display a list of all potential stops that are within the district walk-to-stop policies for that student. The system should display the distance from the student s house to all nearby stops. If a student is added and receives a bus stop currently serviced by a bus, the student should automatically receive the routing information for the correct bus, pickup time, and drop off time. The system should automatically assign transfer buses to students needing to ride multiple buses to get to school. The system should automatically display an overloaded route warning when the user is overloading a vehicle based on ambulatory and wheel chair capacities, accounting for Aides assigned to the route. The system will accommodate multiple transfer buses for both AM and PM runs. The system will accommodate medical information, physician information, and special needs for each student. The system will accommodate assigning a second school to a student and routing to and from the assigned second school. 4
The system must allow for students who are transported out of district. The system should report accurate home to school distances for all students. The system should have a way to automatically assign students as walkers based on the district s walk-to-school policies. The system should allow the user to manually override system parameters on a student by student basis for assigning a student as a rider or walker. The system should allow the user to select a user defined bus type for each student. Each student should have an entrance and exit date that is automatically generated/updated when a student enrolls or withdraws. Student records should become inactive when a student withdraws, not deleted. Student historical routing information shall not be deleted, but retained for accurate historical transportation accounting. The system must have the ability to track and print student discipline actions from year to year. The system must allow the user to print a postcard with student s routing information from the student screen for that student. The system must provide for the automatic rollover of students from one year to the next including automatic assignment to new school and routes. The user should have the choice of retaining or purging outgoing 12th graders as part of the rollover. GEOCODING STUDENT DATA The system should be capable of automatically matching students, by address, to the electronic map (geocoding) in both individual and batch mode. The system should provide an error list of all students failing the location process. 5
The system must distinguish between two identical addresses (the same number and same named street in two different parts of the district). The system should be able to accurately geocode students living at such addresses automatically. The system should allow for manual locating of students who cannot be automatically located on the map. IMPORT/EXPORT CAPABILITIES FOR STUDENT DATA The system should be capable of ODBC links to other software that is ODBC compatible. The system should store data in industry standard structures that are available to third party programs, such as word processors, report writers, etc. The system must support periodic downloads from the current student management information system. The vendor is required to process and verify the conversion of the first download, and to provide the district with the means to perform future imports without vendor intervention. The vendor must indicate any cost associated with the functionality. The system should have functionality to compare import student addresses with the system addresses. The user shall have the ability to accept/not accept the new addresses for each student. The system will provide validation checks of the data being imported for accuracy. The system will provide a report of all import changes that occur for each student. The system should be capable of dealing with adds, changes, and deletes as a subset of the entire student import, rather than require the entire student database to be imported each time. The system should be capable of exporting data in ASCII format to other applications, including routing information (AM bus, time, stop description; PM bus, time, stop description) The system will support file download automation, whereby a file is created out of the routing system which can then be automatically set up to upload each night into the student management system without user intervention. The file would consist of key data such as student name, stop description, stop time and bus number. 6
ROUTING/STOP FUNCTIONS The system should create bus stop names automatically, and allow the user to create user-defined names for stops in the system. When assigning students to stops, the system must provide a list of closest routes, showing the number of students assigned, bus capacity and distance to the new stop. The system should allow for the creation of door-to-door house stops. The system is able to designate a stop as special education or private house stop, which prevents other students from using that stop. The system must identify special needs stops assigned to a route. The system permits creation of corner and address specific bus stops through a graphical process. Stops should only be entered once for each unique location regardless of the school assignment of the students at the stop. The system should allow for user defined maximum student counts for each stop. The system provides automatic stop and route assignments, taking into consideration, walk distance rules, hazardous roads, student address location and school student is attending. The system must provide security such that only students assigned to the school(s) associated with a unique stop can be assigned to that stop. When relocating a stop graphically, all information associated with that stop moves with the stop. For example, if you move Stop A from one location on the road to another location, all students and routes assigned to that stop move to the new location and route driving directions are updated to reflect the new location. The system should be capable of transporting mixed sets of students, such as multiple schools, on the same set of buses. The system should be capable of accommodating variations in routes on different days of the week. 7
The system allows the user to copy a morning route to an afternoon route with the option to reverse the stop order and directions. The system must provide the option to optimize the order of stops assigned to a route. The system has the ability to graphically display routes, runs, schools, students, depots, transfer locations and student stops. The system should allow the user to save and easily access route information and student stop assignments for any user-selected day within the school year. The user should be able to create what-if scenarios without interfering with the existing routing and allow for multiple what-if scenarios and a way to easily review each. The system permits identification of unused and/or unassigned (to a run or student) stops. The system must be capable of providing shortest path routing by incorporating road blocks, one-ways, height and weight restrictions, and turn restrictions globally defined by the users. All route times must be automatically calculated using over-theroad distances with speed and loading delay factors taken into account. The system allows the user to override system generated stop times on each route without effecting the times on other routes. The cumulative miles along the route must be automatically calculated based on actual over-the-road paths. The left / right turn directions must be automatically calculated based on the actual path of the route. The system must allow the user to manually modify the driving directions that cannot be overwritten by the automatically calculated driving directions. The system must have an easy way to manually modify the path of a route and add / remove stops from the route. The times, miles and driving directions should be automatically updated as the user modifies the path. 8
The system must allow the user to create and edit transfer routes with students needing to be transferred automatically assigned to the route. The system must allow the user to designate a different color for each route and display multiple routes on the map screen simultaneously by school, bus, driver, and time of day. The routing screen must display both a graphic representation and a text representation of the route on the same screen. The graphic map should be the interface to the route development and editing process. The number of students at each stop and the total number of students on the route should be automatically calculated as the user adds or removes stops from the route. The system must graphically display unrouted stops with the number of students unrouted at each stop simultaneously with the routing screen. The user should be able to display the names of students at any stop on the route, and be able to open a student record from the routing screen, make changes in that student record, and have them immediately effective upon return to routing. The system must allow the user to display the student s direction of travel to their assigned stop. The system must allow the user to get a list of zones that apply to a specific location on the map. The system must allow the user to get a list of routes, stops, and stop times by school and school type that apply to a specific location on the map. Routes that are created or edited should update the data in the student record automatically. The system should allow the user to assign single or multiple aides to a route. Routing reports should be available for printing without having to leave the routing screen. ROUTING REPORTS 9
All routing reports should have the ability to print for the current day or any archived user-selected day within the school year. The system should create the following route reports: bus schedules (stop description, time, cumulative mileage, and miles with students and miles without students listed for each trip), passenger lists (with student names, address, phone number, school grade, user defined note), driving directions (left/right turn directions with names of students). The system should allow for the printing of route reports for all buses or a particular subset. The system shall be capable of printing color route maps with driving directions for the drivers, including a visual representation of the route. 10
DRIVER DATA CAPABILITIES The system must be able to track data on drivers including name, addresses (home and mailing), phone numbers (home and cell), email, employment (hire date, birth date, salary, termination date), license (number and expiration date), recertification date, and background checks. The system must allow the user to create customized lists of violations, testing, and absences to be tracked and printed for each driver. The system must have the capability of alerting the user when driver licenses, bus licenses, driver physicals, contractor contracts and driver recertifications are about to expire within a designated number of days. REPORTS The system should have a custom report generator in addition to built in reports. The custom report generator must have multi-level sort / filter capability and the ability to save reports to user defined report names for later retrieval. The system should allow the user to easily export any report data to third party programs such as Excel or Microsoft Word so that letters, labels, etc. can be made with the programs. The system should allow the user to generate reports in Adobe.pdf format. The system should allow the user to generate user defined postcards to be printed by school, grade, zip code, and selected students. Postcards must contain student bus information such as bus number, stop time, and stop description both AM and PM. Transfer information must also be printed for transfer students. The system should be capable of printing color maps with routes, street names, bus stops, houses, zones, landmarks etc. displayed. The system should be capable of calculating route cost reports based on daily fuel and annual overhead costs. The system must have a report of students that are living in hazardous areas located inside the normal walk zone of a school (using district policy for walk-to-school distances). 11
The system must have driver reports that list all violations, testing, and absences in date order. The system must have student incident reports (by student or by driver) in date order. ZONE ANALYSIS The system allows the creation of user-defined attendance zones, walk zones, rider zones, or other areas. The zone analysis component must work with the same map and student data records as the bus routing component. The system must have flexible, easy to use drawing and editing tools for zones. The user must be able to select the zone color and zone description. The system must allow for zones to be hidden or displayed, at user discretion. The system will be immediately capable of counting students located inside a newly drawn zone. The user must have the ability to print color maps of selected zones. ZONE ANALYSIS REPORTS The system shall be capable of printing color maps of zones. The system must have reports of students within a selected zone, such as a count by school by grade, names and addresses of the students, etc. The system should provide a summary report that lists the count by school by grade for all schools selected schools in a single report. The system should print a report of all students inside a zone. The system should be able to print a report of all addresses within a zone. The system should be able to print a report of all bus stops within a zone. The system should be able to print a report of all streets with house number ranges within a zone. 12
INSTALLATION The vendor will indicate the timeline for implementation of the software in the district. This timeline should reasonably reflect the time required for vendor to prepare the GIS map, convert data and routes, training, and tasks the district will be responsible for in order to get the system operational. The vendor will describe in detail each task required by the vendor to convert DISTRICT to their system and the time required for each task. The vendor will describe in detail each task required by DISTRICT to become fully operational and the estimated time required for each task. TRAINING On-site training shall be provided. All costs associated with the training shall be identified including travel time and expenses. Training must be provided to all district transportation staff and anyone else the district requires. The vendor shall describe the training program, number of days, data used, and hardware used. The training will be on-site at DISTRICT. District staff must understand the system, not in a purely technical sense, but personally in the way the system relates to them and how they interact with it. The vendor will describe the steps by which these training goals will be accomplished. The vendor must provide a copy of a user guide for the system. The user guide should be written in style appropriate for novice computer users. CUSTOMER SUPPORT AND SOFTWARE UPGRADES The vendor shall describe in detail their annual support program and cost for the district. The vendor shall identify types of support and programs made available during the last five years that were not covered by the annual fee and give their associated cost to districts. The vendor should indicate the availability of a toll free number for support calls, and any fees associated with either the toll free number or modem support. 13
The vendor shall indicate the average response time for support calls. The vendor shall indicate the hours their support staff is available for service. The vendor shall indicate the frequency of software updates. The system must have a comprehensive help system within the program that incorporates all topics and information from the user s manual. REFERENCES AND COMPANY BACKGROUND The vendor will indicate the number of years the firm has been in business, and the number of years the firm has supplied routing and planning software. The vendor will provide at least four references that can testify to the quality of the company's support staff and procedures. HARDWARE REQUIREMENTS The vendor will indicate the hardware that will be best suited for the district's solution. This should include type of computers, with RAM and hard disk size requirements, any networking capabilities desired, and the printers required/recommended. Any other hardware or software necessary for the system to operate must be described. SYSTEM PRICING The vendor shall indicate the proposed modules that meet this set of specifications, and the price for each, as well as the total software cost. The vendor shall indicate the price for proposed services, and the specifics of what those services are. Specifically, the vendor shall highlight necessary implementation services that are not provided in the proposal to the district. The vendor shall indicate the annual fee for the recommended system, and whether or not such a fee is required to continue to use the software in the future. The vendor shall indicate the annual fee for customer support and software upgrades 14