Acorn Software
Bus Tracking System Software Requirements Specification
Version 1.0 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0 Revision History Date Version Description Author February 2nd, 2005 0.8 Trip Planning Requirements Ryan Nordman February 2nd, 2005 0.8 Kiosk User Interface Requirements Daniel Beck February 2nd, 2005 0.8 Network and Technical Requirements Paul McMahon February 2nd, 2005 0.8 Introduction and Overall Description Christopher Hanlon February 2nd, 2005 0.8 Phone System Requirements Calvin Shen February 2nd, 2005 0.8 Data Collection Requirements Craig Stuart February 2nd, 2005 0.9 User Characteristics Paul McMahon February 2nd, 2005 0.9 Usability Requirements Daniel Beck February 2nd, 2005 0.9 Various System Descriptions Craig Stuart, Paul McMahon, Calvin Shen February 2nd, 2005 0.91 Editing and rewrites Ryan Nordman, Christopher Hanlon February 3rd, 2005 1.0 Final edit based on Luis’ feedback Ryan Nordman
Confidential Acorn Software, 2006 ii Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0 Table of Contents
1. Introduction 1 1.1 Purpose 1 1.2 Scope 1 1.3 Definitions, Acronyms and Abbreviations 1 1.4 Overview 1
2. Overall Description 1 2.1.1 Product perspective 1 2.1.2 Product features 2 2.1.3 User Characteristics 2 2.1.4 Constraints 2 2.1.5 Assumptions and dependency 2
3. Specific Requirements 2 3.1 Functionality 2 3.1.1 Requirements for Kiosk 2 3.1.2 Requirements for Internet Website 4 3.1.3 Requirements for On-board Bus System 6 3.1.4 Requirements for Head Office 6 3.1.5 Requirements for Phone System 7 3.2 Usability 7 3.3 Reliability 7 3.4 Performance 8 3.4.1 Performance Requirement One 8 3.4.2 Performance Requirement Two 8 3.4.3 Performance Requirement Three 8 3.4.4 Performance Requirement Four 8 3.5 Supportability 8 3.6 Design Constraints 8 3.6.1 Design Constraint 1 8 3.7 Online User Documentation and Help System Requirements 8 3.8 Purchased Components 8 3.9 Interfaces 9 3.9.1 User Interfaces 9 3.9.2 Hardware Interfaces 9 3.9.3 Software Interfaces 9 3.9.4 Communications Interfaces 9 3.10 Licensing Requirements 9 3.11 Legal, Copyright and Other Notices 9 3.12 Supporting Information 9
Confidential Acorn Software, 2006 iii Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0 Software Requirements Specification 1. Introduction
1.1 Purpose This document describes the software requirements of a bus tracking system. It is intended for the designer, developer, and maintainer of the bus tracking system. These requirements were created in response to a request for proposals from Metro Link for a bus tracking system.
1.2 Scope The bus tracking system is intended to assisting passengers with route planning, inform passengers of delayed busses, improve inter-bus transfers by informing bus drivers of connecting busses that are running behind schedule, help transit management produce accurate schedules, and help transit management allocate resources more efficiently.
1.3 Definitions, Acronyms and Abbreviations GPS (Global Position System): A system of satellites, computers, and receivers for determining the position of a receiver on Earth. csv: Comma Separated Variable. A file format used to exchange information between disparate applications Total Trip Time: The time it will take the traveler to go from the start position to their destination, including all time spent walking to bus stops, waiting for buses and riding on buses. Start position: The geographic location where the traveler begins their trip. In the system it is described as a street address or intersection of two streets. Destination: The geographic location where the traveler completes their trip. In the system it is described as a street address or intersection of two streets. Automated Voice: An automatic recorded voice message service provides instructions to guide users of the bus system with route information. Kiosk: A secure, independent stand with a computer and display screen that users can interact with through a touch screen. They are located in high traffic areas. Overlay: A semi-transparent graphic displayed in the same position as another graphic, usually used to provide additional information to the user.
1.4 Overview The remainder of the document is organized as follows: section two provides a general description of the bus tracking system and section three provides detailed functionality, reliability, usability, and performance requirements for the public kiosks, trip planning system, management oriented reporting system, and the driver oriented information consoles.
2. Overall Description
1.4.1 Product perspective The bus tracking system is made up of the following seven components: A server that hosts bus route information, current bus locations, and historical bus location data;
Confidential Acorn Software, 2006 1 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
A GPS-enabled system located on each bus that will send bus location information to the bus information server; A reporting system that allows transit management to investigate bus delays, and bus usage patterns; A console onboard each bus that receives data from the bus information server and displays notices to drivers; A telephone schedule system; A web based trip planning system; And a set of kiosks at bus stops that allow potential passengers access the trip planning system.
1.4.2 Product features The bus tracking system has the following features: 1. Provide passengers with an easy to use method of planning trips 2. Provide passengers with quick access to information on arrival times of the next bus 3. Provide passengers with access to complete schedule information for any specific route 4. Present bus drivers with information on status of connecting busses. 5. Provide data for Metro Link’s administrative staff on bus ridership and schedule performance. 6. Provide Metro Link administrative staff with up to the minute positional data of all active buses in the city.
1.4.3 User Characteristics
2.1 Passengers Passengers want to know when the next bus will arrive at the stop. They will be interested in easily planning a route by phone, web, or a kiosk. It is especially important that kiosks be easy to use, as users may not speak English, or be familiar with the city.
2.2 Bus drivers Bus drivers need to know the bus schedule and the estimated time of arrival of connecting busses. As the drivers will be driving when using the system, it is important to minimize interaction with the system.
2.3 Head Office Personnel at head office need to gather statistical information to assist in decisions about designing routes. This information should be updated often, to allow for fast reactions to changing conditions.
Confidential Acorn Software, 2006 2 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
1.4.4 Constraints
1.4.5 Assumptions and dependency 3. Specific Requirements
1.5 Functionality
1.5.1 Requirements for Kiosk Kiosks will be located at major bus stops around the city. They will consist of a secure, independent stand built around a computer and touch screen. Users will interact with the kiosk through the touch screen and will have access to a number of functions. The user can request the numbers and names of all busses passing the stop, the arrival time of the next bus at the current location, the daily schedule for a given route and see a real time map of current bus locations. Users will also have the ability to utilize the route planning function of the kiosk to help them to plan a trip from one location to another.
3.1 Inactivity After 30 seconds of inactivity, kiosk screen should return to default screen so that a newly arriving user will not be confused.
3.2 Information Display on Start Screen Default kiosk screen will list names and numbers of all buses passing stop and their estimated arrival times in order to provide useful information to passengers quickly.
3.3 Arrival Time of Next Bus Description: In order to provide the next bus feature, users should be able to find out when their next bus is coming. Input: User selects their route number/title Processing: Kiosk connects to central server and looks up how long the next bus will take to arrive. Output: The time the next bus will arrive is displayed on screen along with a list of future arrival times.
3.4 Route Information Description: In order to give the users access to route information through the kiosk, users should be able to see information about a specific bus route Input: User selects their route number/title Processing: Kiosk looks up information about the bus route Output: A map of the route and list of stops is displayed on the screen
3.5 Schedule Information Description: In order to give the users access to bus schedule information through the kiosk, a bus schedule, listing expected arrival times at the current location for any day of the week should be available for the bus chosen. Input: User selects a day of week. Processing: Software searches for entries of all buses that day. Output: A list of times that the bus will arrive at current stop on the chosen day is displayed.
Confidential Acorn Software, 2006 3 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
3.6 Initializing Trip Planning Mode Description: Users should be able to plan a trip using the kiosk Input: User selects the option to plan a trip Processing: Initialize trip planning mode Output: Initial trip planning screen is displayed on kiosk
3.7 Trip Planning Information Description: In order to give the users access to bus schedule information through the kiosk, if a user enters their destination on the map screen, a list of busses and connections is then displayed Input: User selects their desired destination from a map screen Processing: Kiosk computes the best route to take and what connections are necessary. Output: A list, ordered by departure time, of necessary buses and stops is displayed on the screen
3.8 Bus Proximity Display Description: In order to give the users access to bus information through the kiosk. After selecting the real time bus map function, a map of all buses in a 1km radius of the kiosk should be displayed. Input: User selects real time bus map function. Processing: System loads map with bus location overlay utility Output: Kiosk displays map of 1km radius around current location, numbered buses are displayed in overlay of map.
1.5.2 Requirements for Internet Website Through the website, users will be able to easily plan trips and view route schedules. The trips planned through the system should be efficient (as determined by user selectable metrics). Route schedules for both current and future schedules will be available. Current schedules will reflect the bus’s actual position.
3.9 Initializing Trip Planning Mode Description: In order to implement the trip planning feature through the website, users should be able to plan a trip using the MetroLink web site Input: Users selects the option to plan a trip on the website Processing: Initialize the trip planning mode Output: The initial trip planning webpage is displayed on the user’s web browser
3.10 Information Prompts for Trip Planning Description: Initial Trip Planning screen: Users are prompted to specify their departure time, arrival time, start position, and destination Input: Users enter their departure time, arrival time, start position and destination into fields on the webpage. Start position and destination can be entered as a major intersection or a specific street address. Processing: The system processes the start position and destination to confirm they are valid. Output: System accepts or rejects the input start position and/or destination as valid locations
Confidential Acorn Software, 2006 4 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
3.11 Handling Invalid Data for Trip Planning Description: The user enters an invalid location into the start position or destination fields Input: Incomprehensible or invalid location information Processing: System looks up similar street names or addresses Output: Same page is redisplayed with a message next to the field(s) were the invalid location(s) were entered. The message informs the user that their input was invalid and presents the suggestions.
3.12 Processing Trip Planning Data Description: The user enters a valid location into the start position and destination fields Input: Valid location information Processing: The system computes two possible trips from the start position to the destination and stores the results in a list. First it computes the route that involves the shortest total trip time. Second it computes the route that involves the least distance required to walk. Note that these two trips may be identical. Output: The system prepares the results for output to the user’s web browser.
3.13 Trip Planning Route Summary Description: Two unique trip possibilities are ready Input: Two unique trips have been computed that will take the user from their start location to their destination. Processing: The two trips are summarized by concatenating the trip numbers together and displaying the walking distance and total trip time. Output: The two trip summaries are displayed on the user’s web browser and they can select which trip they prefer.
3.14 Format of Trip Planning Route Output Description: The user selects one of the two trip possibilities, or both trips were identical Input: A table of trip data with each row containing a bus trip or walking instructions Processing: The trip data is put into a readable list and sorted by departure time. Each row in the list contains the following: o If it is walking instructions: . Departure time . Start position . Destination . Arrival time . Distance walked o If it is a bus trip . Bus departure time . Bus departure location
Confidential Acorn Software, 2006 5 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
. Bus number . Bus route title . Arrival time . Trip time Output: The list is displayed on the user’s web browser
1.5.3 Requirements for On-board Bus System The onboard bus system will consist of four major components: a cellular uplink, a GPS unit, a bus card reader/money counting unit will accept the payments for passenger fares. The touch screen will provide an interface to the bus system for the bus driver. Drivers will use the screen to view the arrival times for their bus and for any connecting busses.
3.15 GPS System Description: In order to implement the feature that allows for central tracking of bus positions, GPS positional data for each bus should be sent to the central server. Input: Positional data is calculated using the GPS receiver located on each bus. Processing: The positional data is transferred over the network to the central server. Output: The central server receives the data and is able to keep track of the position of each bus.
3.16 Passenger Volume Data Description: In order for usage statistics to be created, passenger volume data needs to be collected from busses and sent to the central server. Input: The number of passengers who board the bus at each stop will be automatically recorded and saved. Processing: Data regarding the number of passengers boarding the bus at each stop along the route will be sent over the network to the head office. After it is collected, the data will be purged from the bus’s computer. Output: The head office receives the volume data for analysis.
3.17 Schedule Information Description: To allow drivers to stay on schedule, drivers should be able to view the schedule for their route. Input: The driver requests that an up-to-date schedule for his route be displayed on his screen. Processing: The schedule information will be sent over the network from the central server. Output: The schedule for the bus route will be displayed on the driver’s screen.
1.5.4 Requirements for Head Office Head office is where the central server is located. Data from active buses is all routed to the central server and collected for later use. Operators at head office can access live bus information, communicate with drivers and provide support.
3.18 Traffic Disruptions Description: In order to keep bus drivers informed about traffic disruptions such as accidents or construction delays, head office should be able to send information to bus drivers.
Confidential Acorn Software, 2006 6 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
Input: Head office will receive information about a traffic accident or a construction delay which will require a route change. Processing: Information about the disruption will be sent over the network, along with an alternate route for the driver to take. Output: The information about the disruption and the route change will be sent to the desired bus.
3.19 Passenger Volume Data Description: In order to generate usage statistics, head office should be able to receive and process passenger volume data. Input: Raw passenger volume data from busses. Processing: Passenger volume data is stored for later analysis.
3.20 GPS Data Description: In order to detect violations of transit policy, head office should be able to receive and process live GPS bus data. Input: GPS data from busses currently in service. Processing: GPS data is stored for later use.
1.5.5 Requirements for Phone System The Phone system will be an automated voice system which provides users the schedule for any bus route. With automated voice, users can access the schedule of buses easily and quickly by any phone device. In order to use the service, users call the system and follow the automated voice instructions to access the bus schedule of their choice.
3.21 Phone System Description: In order to provide schedules for requested routes and stops, Users should be able to request the schedule for any bus route. Input: User selects route number, direction of travel, and desired stop. Processing: The system looks up the bus route. Output: Automated voice tells user departure times based on input information.
1.6 Usability
1.6.1 Kiosks When using a kiosk, it should take fewer than 3 minutes to become familiar with the system. Finding the time of a next bus to arrive to the present stop on a specific route from the kiosk should take fewer than 15 seconds. Viewing any other scheduling information, including the route planner via the kiosk should take less than 1 minute.
1.6.2 On-Board Bus System Bus drivers would require approximately 25 minutes of training to become adept at using their on board display systems.
Confidential Acorn Software, 2006 7 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
1.6.3 Website and Telephone System The web-based system and the automated telephone route information system should take fewer than 3 minutes to become familiar with the system. For a user that is familiar with the system, it should take less than 1.5 minutes to view or hear scheduling information.
1.7 Reliability The bus tracking system must respond to 99% of user requests within 3 seconds of the request. The bus tracking system’s location information for each bus must be less than 5 minutes old 99.9% of the time. The bus tracking system’s location information for major busses must be less than 2 minutes old 80% of the time for major bus routes. The bus tracking system may have a maximum four periods of planned downtime between 3:00AM and 5:00AM per year. These periods must take place on Monday, Tuesday or Wednesday nights.
1.8 Performance
1.8.1 Position Reporting Times Description: Each bus will report its position to head office every 30 seconds.
1.8.2 Reporting Times For Other Data Description: Each bus will report non-positional statistics to head office every hour.
1.8.3 Bus Connection Data Description: When a bus is within an estimated 30 seconds of a connecting bus, it will receive the connecting busses’ estimated time of arrival every 15 seconds.
1.8.4 Maximum Bus Limit The system will support at most 1000 active busses.
1.9 Supportability
1.10 Design Constraints
1.10.1 Design Constraint 1 The website must be accessible using the following operating systems: Windows Mac (Pre - OS X) Linux and browsers: IE5+ NS4+ Mozilla Firefox Opera Safari
Confidential Acorn Software, 2006 8 Bus Tracking System Version: 1.0 Software Requirements Specification Date: February 2, 2006 BTS SRS 1.0
1.11 Online User Documentation and Help System Requirements The kiosk, web site and phone system should be designed in such a way that additional help documentation is not required.
1.12 Purchased Components To be determined.
1.13 Interfaces
1.13.1 User Interfaces
3.22 Physical Design of Kiosk The kiosk will be 4 feet high with a head that can rotate on the horizontal axis to be accessible to people of all heights. The following is an example of a possible look of the kiosk.
1.13.2 Hardware Interfaces Each bus will contain the following hardware interfaces: a bus card reader and money counting unit a cellular uplink a GPS unit a touch screen Each kiosk will contain the following hardware interfaces: a touch screen a networked computer
1.13.3 Software Interfaces Statistics collected will be provided in csv format to allow for easy integration with existing analysis tools.
1.13.4 Communications Interfaces All communication between busses, head office, and kiosks will be performed over the internet.
1.14 Licensing Requirements None.
1.15 Legal, Copyright and Other Notices This document is a fictional requirements specification. All ideas and text are property of the members of Acorn Software.
1.16 Supporting Information None.
Confidential Acorn Software, 2006 9