Project Home Page    Documentation    Download     Developer Information    CS435 Homepage    Forum    Issue Tracker

CS435 Traffic Simulator Requirements

1. Introduction

The goal of this project is to build a software simulation of traffic, which will be based on M. Treiber's MOBIL lane-changing model and IDM driver model. The project will include varying levels of intersections, traffic laws, and lanes (i.e. more than two). In addition, it will feature different maps and a driver model selection for the user to choose from.

The system will present the user(s) with an interface that allows them to choose settings of the simulation such as velocity and traffic flow. The system will adhere to a realistic array of scientific laws to manifest a realistic simulation. The system will also allow the user multiple views of the simulation and to change settings as the current simulation is running. Users of this product are assumed to have a reasonable familiarity with computers, but not necessarily with any particular platform or window manager. They are also assumed to understand basic concepts of driving (as anyone who has viewed traffic would), although they probably will not know the details of the scientific basis on which driving occurs.

1.1 About This Document

This document is intended to be read by the software development team members, managers and the client and/or the client's representative. This is a new project; therefore, there is no summary of previous versions. In this document, we describe the overall product and three milestones which the customer has specified. We then lay out all the requirements for the whole system, indicating the appropriate milestone(s) for each. Use cases are located in a separate document. The goal of this document is to provide the system developers with both the user requirements and a detailed specification of the system requirements for each milestone of the software product.

Each section of the requirements addresses a different aspect of the system. Requirements use a standard schema, which has ID, name, description, importance, and planned delivery milestone. Requirements are numbered by section. Priorities are: 1: very critical, 2: critical, 3: very useful, 4: useful, 5: would love to have, 6: nice to have, 7-10: varying degrees of wishlist (based on assestment of probability). Requirements with priorities 1-4 are necessary for successful completion of the project.

1.2 Changes to this Document

• 1.0.1: Added fast-forward and rewind requirements.

2. Scope and Overall Structure

Functionality will be added to the system in 5 phases, called milestones. The design and documentation thereof will be set up by the first milestone. The second milestone will add the basic GUI and simulation of basic vehicle behavior, such as stopping. The third milestone will add simple intersections, a more advanced GUI, and multiple lanes. The forth milestone will add intersections with stoplights, advanced multiple lanes, improved simulation, and increased robustness of performance. The fifth milestone will add either artificial intelligence, more enhanced simulation, or advanced driver model options. The decision for the functionality implemented in the fifth milestone will be left to the developers.

At each milestone, all functionality from the previous milestones should be preserved. The planned deadlines for completion of each milestore are as follows:

• Milestone 1, 2/25/05
• Milestone 2, 3/23/05
• Milestone 3, 4/4/05
• Milestone 4, 4/20/05
• Milestone 5, 4/27/05

More information regarding the scheduling requirements can be found in the development roadmap: http://www.cs.wm.edu/~coppit/csci435-spring2005/project/roadmap.php.

3. Project Development Requirements

This section outlines describes requirements outlined by the client, including tools and documentation.

3.1 Tools

This section outlines various tools we will be using including the software language, code commenting, graphics package, build system, testing tools, source control, and IDE. It describes which tools will be used in each milestone.

3.2 Documentation

This section outlines the various documentation requirements at each milestone.

4. Functional Requirements

In this section the functional requirements are outlined for the graphical user interface and simulation.

4.1 User Interface

This section outlines the functional requirements relating to user interface. Included in this are requirements concerning graphical interface for a new simulation and graphical interface during a running simulation.

4.1.1 New Simulation Interface

4.1.2 Running Simulation Interface

4.2 Simulation

This section outlines the functional requirements relating to the actual simulation. It address roads and surroundings and vehicle behavior.

4.2.1 Roads and Surroundings

4.2.2 Vehicle Behavior

5. Non-Functional Requirements

In this section the non-functional requirements are outlined. Memory leaks, usability, testing, invalid input, and unhandled exceptions are all discussed in this section.

6. Performance and Environmental Requirements

This section lays out the performance and environmental requirements.

7. Discussion of Requirements

Each milestone should be completely finished and tested before work starts on the next milestone. This will help to ensure that bugs are all fixed before continuing. Basic work on each section must be completed as there are many dependecies. There must be a basic simulation framework available, for example, basic road and driver classes must be implemented before features such as stoplights, highways and intersections may be added. Verification is done with testing, but in some areas there can be problems determining what is acceptable. For example, flickering of the graphics is extremely hard to measure in terms of "acceptability.".

Applet size is also a concern. With the number of features that could potentially be available, the tradeoffs of speed versus size versus performance must be carefully considered. For example, the detailed collection of data is quite important for this project, but taking the effort to collect data at every timestep may significantly hinder performance. Graphically, zoom ability and fast-forwarding and rewinding may all lead to a major performance hit. Zooming especially seems like it would be difficult to implement. Having to manipulate and magnify the graphics seems like a daunting task. The benefits and drawbacks of using Swing vs. AWT to render the graphics is yet to be determined.

Some options that we can offer to the customer include a variying number of maximum lanes, the quantity of fastforward and rewind features, including timed stoplights (either for the map as a whole or for individual lights), and the ability to put driver accidents into the simulation model. For the data collection, the quantity, types, and ways of acquiring data are variable, and so are the ways of outputting it.