Chicago Run Virtual Marathon Requirements Document

IEEE/ANSI 830-1993 Standard

1. Introduction
a. Purpose The purpose of this requirements document is to specify the complete functional and nonfunctional requirements of the Chicago Run Virtual Marathon Project. b. Scope of the Project The scope of this project deals with the design, implementation, and testing of a Virtual Marathon that will interface with the existing database (database.chicagorun.org) and the existing website (ChicagoRun.org). This Virtual Marathon will be tailored to the unique needs of the end-user, the children who participate in Chicago Run. c. Definitions, Acronyms, Abbreviations There are a number of terms, abbreviations, and ideas that need to be defined. For the purposes of this project, a virtual marathon is a static route that is 26.2 miles in length. The term static refers to something that is constant and exhibits no change. View-only or read-only refers to content that can be read or viewed, but not altered. Points, or landmarks, refer to specific locations which students will interact with in their virtual marathon. These points will be landmarks in the Chicago-land area and will be defined by Chicago Run. Incentives are prizes and commendations that children will receive as part of the achievements set up by Chicago Run. Pop-ups refer to the on-screen pictures that will be displayed based on landmarks and incentives. d. References This project would not be possible without resources and references. Alicia Gonzalez is the Executive Director of Chicago Run and is the primary liaison for the project. Nate Rosenthal is the Program Coordinator for Chicago Run and serves as the liaison for technical issues. Chris McAvoy is the PSC Listens liaison for Chicago Run and the contact for issues related to the existing site, as well interactions with that site. In addition to these individuals, a number of websites were provided by Chicago Run as references for design, content, or user interaction. These sites are: JustRun (http://www.justrun.org/site5.aspx), Map My Run (http://www.mapmyrun.com/), Running Map (http://www.runningmap.com/), USA Track & Field (http://www.usatf.org/routes/), Running Routes (http://www.walkjogrun.net/), Run (http://www.run.com/), and Ronald (http://www.ronald.com/). e. Project Team The project team is composed of students from DePaul University. The team consists of: Ben Dahl (Project Manager), Joseph Booker (Ruby on Rails Programmer), Brian Gerber (Google API Programmer), Fernando Barajas (Manual Engineer), and Matthew Seman (Manual Engineer). f. Overview of this Document The remainder of the document addresses the following project items. First, the perspective of the project is defined. Next, the functions of the project are clarified. After this, user groups and characteristics are discussed. Constraints, assumptions, and dependencies are also addressed. Finally, the specific functional and non-functional requirements are addressed.

Chicago Run Virtual Marathon Requirements Document

Page 1

Chicago Run Virtual Marathon Requirements Document

2. General Description
a. Product Perspective Chicago Run has an existing website and an existing database which serves their general needs. The website allows them to maintain a web presence and market. The database allows the teachers to track student progress when they run. The Chicago Run Virtual Marathon Project will satisfy the needs of the program's primary beneficiary, the children. This project will create a virtual marathon in which children will be able to log in to view their progress, landmarks, and incentives. b. Product Functions The product must provide a variety of functions. There will be five static routes at launch (Chicago Marathon, North, East, South, and West), with the ability for the product to expand to accodomate additional routes. The Chicago Marathon will be the default route for all students at time of launch. After a student has completed this route, the product will change to the next route in the route list. Students will have individual accounts (user names and passwords), which they will use to access the product. These accounts must be the same accounts that teachers apply students progress to. These accounts must not be able to modify, append, or delete existing information. Students must be able to interact with the product to track progress, view incentives, and view landmarks. The product must be user-supportable and function with existing Chicago Run hardware, software, and other resources. c. User Characteristics There will be three primary user groups of the product: teacher(s), administrator(s), and student(s). Teachers are college-educated, of varying ethnicity, familiar with the Chicago Run program, and have some experience with computers. They have access to, or use, a computer outside of school. These users are well acquainted with the policies and procedures of Chicago Run and their existing technology. These users are responsible for the logging of student progress within the Chicago Run database. The teachers must have the ability to log-in to the site with their existing Chicago Run credentials. They must be able to modify and add student information, run progress, and data as they did on the existing site. The Administrators may be Chicago Run personnel or appointed site-administrators by Chicago Run. These users are college-educated, of varying ethnicity, and have an extensive knowledge of technology, computers, and the Internet. These users possess an above average knowledge of Chicago Run, as well the goals of the program as a whole. Administrators must have all the same privileges as teachers. They must also have the ability to modify, add, and/or delete: incentives, routes, and landmarks. Students are children within the Chicago Public School system. They are of varying ethnicity, of modest means, and generally do not have a computer at home. These users have some access to computers, but their experience is limited. Information must be presented to these users in a very simple, intuitive, child-friendly way. Students must be able to log-in to the site with their Chicago Run account. They must be able to interact with the map and view additional information about landmarks, incentives, and their progress.

Chicago Run Virtual Marathon Requirements Document

Page 2

Chicago Run Virtual Marathon Requirements Document

d. General Constraints With the development of this product, there are a number of constraints that must be taken into account. All student information must be kept confidential. The product has an eight-week development cycle. The product must be complete by June 8, 2009. The product must be developed in the languages of the existing products (RubyOnRails). The site must function in both Internet Explorer and Firefox. e. Assumptions and Dependencies The requirements here assume that parsing information from the existing Chicago Run database to the Google Maps API is possible. This system assumes that there has been no development or coding issues with existing Chicago Run sites or infrastructure. This system also assumes that children have expressed interest in this type of interface.

3. Specific Requirements
a. FUNCTIONAL REQUIREMENTS a. Business rules i. Application must use existing user credentials b. Processes supporting the goals/objectives of the project i. Access Chicago Run systems (database, website, servers) ii. Provide visual map interface to display user progress iii. Access database for user information display iv. Display pop-up windows based on user location 1. Landmarks 2. Incentives v. Provide five static routes for runners, defined by Chicago Run 1. Chicago Marathon route 2. North route 3. South route 4. East route 5. West route vi. Application must be expandable to allow for future routes to be added vii. Application must be able to be administered by existing personnel. b. NON-FUNCTIONAL REQUIREMENTS a. Training i. Chicago Run Employees ii. PSC Group, LLC iii. Site Administrators (Performed by Chicago Run) b. Cutover i. Parallel - System is new, developed in concert with existing system c. Data Conversion i. Parallel - System is new, developed in concert with existing system

Chicago Run Virtual Marathon Requirements Document

Page 3

Chicago Run Virtual Marathon Requirements Document

d. Usability i. Prototype ii. Heuristic evaluation e. Implementation i. Direct f. Design i. Site needs to be visually exciting ii. Site must use Chicago Run color scheme iii. Site must be child friendly c. INTERFACE REQUIREMENTS a. Interface with Chicago Run database b. Interface with Chicago Run website c. Interface with Chicago Run servers

4. Appendices

5. Index

Chicago Run Virtual Marathon Requirements Document

Page 4