SoftCell
Cell Phone-enabled Transit Information System Requirements Specification
Version <1.0>
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
Revision History
Date 29/Jan/2008 31/Jan/2008 31/Jan/2008 31/Jan/2008 31/Jan/2008 31/Jan/2008 31/Jan/2008 31/Jan/2008 1/Feb/2008 1/Feb/2008 Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Initial Drafting Refinement of Sections 1 and 2 Refinement of Reliability Requirements Refinement of Definitions Drafting and Refinement of External Interfaces and Maintainability Refinement of Performance Requirements Refinement of Functional Requirements Refinement of Usability Requirements Formatting Final changes made Description All All Ryan Downing Steve Csomany Novy Dhillon Scott Small Anna Cox and Brendan Asselstine Duncan Penfold-Brown All All Author
Confidential
UVic, 2008
ii
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
Table of Contents
1. Introduction 1.1 1.2 1.3 1.4 1.5 2. Purpose Scope Definitions, Acronyms and Abbreviations References Overview 1 1 1 1 2 2 3 3 3 3 4 4 4 4 4 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 UVic, 2008 iii
Functionality 2.1 2.2 2.3 Product Perspective Product Functions User Characteristics
3.
Specific requirements 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces Functional Requirements General Advertising Mapping Queries Listing Performance Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Usability Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Requirement 5 Requirement 6 Requirement 7 Maintainability Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Requirement 5 Reliability Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Requirement 5
Confidential
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
Requirements Specification
1.
1.1
Introduction
Purpose This document describes the software requirements for a cellular public transit scheduling system. This document is intended for the administrating company who is the client in charge of maintaining the system, and for the developing company.
1.2
Scope The function of the software is to calculate and display transit routing information based on route schedules for the Greater Victoria Regional Transit System.
1.3
Definitions, Acronyms and Abbreviations • Cellular Device A handheld device which can make and receive mobile calls, run applications, and access the internet. This includes all modern cellphones and so-called "smartphones" which have access to a mobile data network provided by the cellular service provider. The system will run on these devices. Cellular Service Provider This is a company responsible for providing access to a wireless communications network for cellular devices. The company's clients are those users with cellular devices. The company will be responsible for any charges due to data access; we are not concerned with their system or implementation. Any information about the provider is outside the scope of the system as the system does not interact with the provider. Database The data for the transit schedule and the advertiser information will be stored in a database. We are not concerned with how the database works. The system will only need to interface with the database to retrieve information relevant to trip planning. Locations Departure and Arrival locations must be only street addresses or cities. Businesses are separate and cannot be used as these types of locations. Transit Route A predefined route for the transit vehicle. Each transit vehicle is assigned a set route for a given time frame and follows that route at times determined by the transit schedule. We assume that routes are managed by the Greater Victoria Regional Transit System but may be changed due to external factors. Transit Schedule A predefined set of times that transit vehicles will travel and the routes they will take. This will be maintained by the Greater Victoria Regional Transit System. The system stores this information and relies on it to calculate routing. The schedule may be changed due to external factors such as the availability of transit vehicles but for the purposes of the system it is assumed that it will remain the same. UVic, 2008 1
•
•
•
•
•
Confidential
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
1.4
References Downing, R., “Elicitation Notes.” Meeting Minutes, SoftCell, 2008. Penfold-Brown, D., “Elicitation Notes.” Meeting Minutes, SoftCell, 2008. Toscano, S., “Elicitation Notes.” Meeting Minutes, Bus-On-The-Go, 2008. Wynja, J. et al., “Cell Phone-enabled Transit Information System.” Request For Proposal, Bus-On-The-Go, 2008.
1.5
Overview The document will contain definitions of terms used within the system. Section 2 contains a description of the software as it would be used on a cellular device. Section 3 contains a description of the functional and non-functional requirements within the system, and external factors the system interacts with.
Confidential
UVic, 2008
2
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
2.
2.1
Functionality
Product Perspective The system will work on a cellular device and receive periodic updates from a database. The updates will consist of transit and advertisement information. The device will store all information needed to compute routes. The system will have an interface accessible via the cellular device.
2.2
Product Functions The system should hold scheduling information and all mapping for the region. The system will also store all routing computation information for use when a user starts the system. This will all be stored in the cellular device itself. A user of the system will input their current location and their intended destination. The system will display options for the best available routes to the destination. These will be based on time of arrival or departure, the time the trip will take and the number of transfers needed for each routing option. The user may choose one of these options and be given a map view or list view showing instructions for their chosen routing option. The system will also display advertisements of local businesses registered with the system; these ads will be accessible via the interface and provide more information about the businesses. The system will be available as a download for the cellular device. The system will be free to download and use; any charges would be those imposed by the cellular provider.
2.3
User Characteristics Users will interact with the system via a cellular device from arbitrary locations using an easy to understand interface.
Confidential
UVic, 2008
3
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
3.
3.1 3.1.1
Specific requirements
External Interface Requirements User Interfaces The system will provide interfaces similar to the following for interaction with the user. The system interface must be easily readable for the user. The following is an example of separate screens within the system. Information View Input Screen
Map View
List View
3.1.2
Hardware Interfaces The system will be manageable from the basic functions of the cellular device. There is no other hardware the system interfaces with.
3.1.3
Software Interfaces The network on which the system operates will provide interfaces to transit and advertiser databases. The detail of this is beyond the scope of this document.
Confidential
UVic, 2008
4
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
3.1.4
Communications Interfaces The system will communicate over the internet to update itself. This connectivity is a combination of the cellular device and the cellular network.
3.2 3.2.1
Functional Requirements General
3.2.1.1 The user shall be able to switch between Map and List view of a returned query. 3.2.1.2 All views within the application shall provide the user with the option to exit the system at any time. 3.2.2 Advertising
3.2.2.1 The Map interface will display icons for points where an advertising business exists on the map. 3.2.3 Mapping
3.2.3.1 The Map interface will be scrollable. That is you can pan across the displayed map. 3.2.3.2 The Map interface will have three viewing levels
1. Micro - Shows one square block - Shows street names - Bus stops - Bus route highlighted - Ad icons on business locations 2. Medium - Shows 5-10 blocks - Shows ad icons on business locations - Shows bus stops - Shows street names - bus route is highlighted 3. Macro - Shows entire route - Can be split into 3 screens - Ads are optional
3.2.4
Queries
3.2.4.1 Queries in the system must be specified by departure and arrival location. Queries in the system can also be specified by:
- Departure Time - Arrival Time - Bus Number - Date
Confidential
UVic, 2008
5
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
Users may only specify departure or arrival time, not both. If the exact departure and arrival locations entered by the user are not available, the closest approximations shall be used. Proximity is calculated by distance. 3.2.4.2 A successful query by the user shall result in a Listing view of the transit routes that are closest to the user’s search request. 3.2.4.3 If a query returns no results the user must be notified. 3.2.5 Listing
- Arrival or Departure time according to the user’s request - Length of time to complete trip - Number of transfers between transit vehicles
3.2.5.1 Routes shall be listed according to the following priority information.
3.2.5.2 Users shall be able to select a route option in the list view. This will display the map view of the selected route. 3.2.5.3 The Listing page shall display
- Possible Buses - Possible Routes - Bus Times
3.3 3.3.1
Performance Requirements The system shall take no longer than ten seconds from the time it is launched to make itself ready for user interaction. This does not include time required to download and apply any necessary updates. The system shall take no longer than five seconds from the time a query has been submitted to display the resulting routing information. The system shall take no longer than two seconds to redraw the map when the zoom level has been changed. The system shall take no longer than two seconds to redraw the map when scrolling. On average this time will be considerably less as only the portion of the map that is scrolled will need to be redrawn.
3.3.2 3.3.3 3.3.4
3.4 3.4.1 3.4.2 3.4.3 3.4.4
Usability Requirements The system shall be operable via cellular device number and text entry specific to the cellular device on which it is installed. The system shall display all information in a legible format and size, in accordance with other cellular device applications. The system shall not use pop-up advertisements or advertisements that cover more than 5 percent of the application screen. All windows of the system shall include menus with options and help entries in order to increase UVic, 2008 6
Confidential
Requirements Specification Cell Phone-enabled Transit Information System
Version: <1.0> Date: <01/Feb/2008>
the ease of learning and understanding the system. 3.4.5 3.4.6 3.4.7 3.4.8 The system shall use color-coded map entries and route information to ensure ease of use and readability. The system shall present a query form similar to query forms in existing, common applications in order to increase ease of use. The system shall present a way of specifying a preference for transit vehicles that are Handicap Accessible, or have places for storage of bicycles during the journey. The system's map view shall be similar to existing, common systems of the same nature (such as Google maps or MapQuest) in order to increase ease of use and understanding.
3.5 3.5.1 3.5.2 3.5.3
Maintainability Requirements Advertisement information should be updatable through single file download/upload to/from cellular device Transit route information should be updatable through single file download/upload to/from cellular device Information update failure
3.5.3.1 In the event of an update transfer failure the system should notify the user and attempt to retransfer or resume the transfer. 3.5.3.2 In the event of an update corruption the system should notify the user and attempt to retrieve the newest update files from the system. 3.5.4 The system should track last update version date, as set on the update server and specified in the files, for the transit route information and advertisement information. This version date can be compared against the version on the server to retrieve the newest update files. Application software update
3.5.5
3.5.5.1 The application will be updated to fix bugs or provide new functionality through installing of the new version over the old version. 3.5.5.2 The advertisement and transit information files will not be overwritten with the update; however, when the new version starts a check for updated information will be performed.
3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5
Reliability Requirements The system should be able to provide service regardless of local cellular coverage. The system should never permanently halt the normal functioning of the hosting cellular device. The system should provide correct geographical information on transit routes. The system should provide temporal information on transit routes accurate to within 5 minutes. Upon changes to transit information, the system should provide these changes to the applications within 24 hours or upon the next use of the application, whichever is longer.
Confidential
UVic, 2008
7