Page 1 of 18

Real-time Traffic Monitoring System – System

Requirements Review
Stevens Institute of Technology
Systems Engineering
SYS 625 – Spring 2007

Team 1
 Aaron Griggs
 Christine Adelfio
 Louis Lovas
 Marvin Mondesir

Page 1 of 18
 Page 2 of 18

Table of Contents
Table of Contents ............................................................................... 2
Need................................................................................................... 3
Stakeholders ...................................................................................... 3
Requirements ..................................................................................... 3
Drivers ..................................................................................... 3
Passengers ............................................................................... 3
Installers ................................................................................. 3
Maintainers .............................................................................. 4
Navigation System Manufacturers ............................................ 4
Fleet Managers ......................................................................... 4
Content Providers .................................................................... 4
Emergency Responders ............................................................ 4
Acceptance Criteria ............................................................................ 5
Concept Definition and Selection ........................................................ 5
Alternatives.............................................................................. 5
Pugh Matrix .............................................................................. 5
Selection and Rationale ............................................................ 5
Context Diagram (External Systems Diagram) ................................... 6
Use Case Scenarios ............................................................................ 7
Profile Management ................................................................. 7
Hazardous Weather .................................................................. 8
Traffic Jams.............................................................................. 9
Maintenance and Diagnostic................................................... 10
Installation ............................................................................ 11
Quality Function Deployment ........................................................... 12
Objective Hierarchy.......................................................................... 13
System Requirements ...................................................................... 14
Functional Requirements ....................................................... 14
Input Requirements .......................................................... 14
Output Requirements........................................................ 14
Interface Requirements..................................................... 15
System-wide Requirements.................................................... 15
Suitability Requirements ................................................... 15
Physical Requirements ...................................................... 15
Technology Requirements ................................................. 16
Cost Requirements ........................................................... 16
Standards and Protocols.................................................... 16
Schedule Requirements by Phase ....................................... 16
Supportability and Maintenance ......................................... 16
Functional Architecture .................................................................... 16
Risks ................................................................................................ 18

Page 2 of 18
 Page 3 of 18

Need
People need to see and understand real-time traffic conditions. This opportunity provides drivers
with recommended routes to avoid unsafe road conditions, whether it is weather related or
congestion from an accident. The end result: a more efficient commute and an overall
happier, safer driver.

Stakeholders
The following table represents the active and passive stakeholders (bold are the customers):

Active Passive
Drivers Navigation System
Manufacturers
Installers Fleet Managers
Maintainers Emergency Responders
Content Providers*
* Providers of weather, road conditions, routes data

Requirements
This section contains the requirements for all the identified stakeholders.

To gather requirements, interviews were conducted with drives. The goal was to understand
how drivers cope with unsafe road conditions, the factors that affect getting to destinations
given some standard conditions and some of their feelings as they drive under these conditions.

Note in a real environment, many interviews would be conducted with drivers in person and via
the Internet and phone. Sample of people would be taken from automobile membership
organizations (i.e., AAA) or consumer panel survey participants.

Outcome is to determine whether the responses from interviewees justify the need for a real-
time traffic condition notification system.

Drivers
 Want a safe commute
 Want an efficient commute
 Want to understand why traffic is backed up
 Want alternative routes
 Want timely, accurate information on road conditions
 Want low (e.g. $20) monthly cost

Passengers
 Want a safe commute
 Want an efficient commute
 Want to understand why traffic is backed up

Installers
 Easy to install

Page 3 of 18
 Page 4 of 18
Maintainers
 Easy to repair

Navigation System Manufacturers

 Easy to integrate
 Easy to update
 Cost effective
 Differentiates the navigation system

Fleet Managers
 Want efficient use of fleet vehicles
 Want to keep operators safe while on the road
 Lower insurance costs

Content Providers
 Want to reach a larger audience

Emergency Responders
 Want to detour traffic during accidents or hazardous road conditions
 Want timely, accurate information

Page 4 of 18
 Page 5 of 18

Acceptance Criteria
The following criteria were defined to influence the implementation of the system:
 Provide the driver with configurable, relevant up to date information.
 Easy and safe to use while driving.
 Reasonable monthly cost for basic service—$10 per month.

Concept Definition and Selection

This section contains the alternative concepts, a Pugh Matrix to inform a single concept selection
and the selection with rationale.

Alternatives
Four concepts were defined:
 Radio – Broadcast through radio air waves.
 Cell phone – Audio and text service that is delivered through cellular networks.
 Traffic signs – Text based digital traffic signs.
 Add-on service to existing navigation systems (e.g., Garmin, TomTom).

Pugh Matrix

Criteria Radio Cell phone Traffic Signs Navigation

System
Ease of use S S S +
Configurability - S - +
Cost + S S S
Reliability S S - S
Timeliness - - - +
Safety S - + S
Integration S S S +
Schedule + S S -
∑+ 2 0 1 4
∑- 1 2 3 1
∑S 4 6 4 3

Selection and Rationale

The Pugh Matrix shows the navigation system scoring slightly higher than the other concepts.
Although the radio, cell phone and traffic sign solutions satisfy the criteria (evident by the
scores), the navigation system is favored when weighing ―ease of use,‖ ―accuracy‖ and
―configurability‖. Given the goal for a better view into road and traffic conditions, the navigation
system is clearly the choice.

Page 5 of 18
 Page 6 of 18

Context Diagram (External Systems Diagram)

Shown below is the external system diagram for the real-time traffic monitoring system.
Displayed are all the active stakeholders and their interactions with the system.

Installers

Installation Alerts
Configurations

Log Updates
Modes
Profile Management Profile Management
Location Road Conditions
Real-time Traffic
Road Conditions Monitoring System Weather Conditions Content
Drivers
Alternative Route Traffic Conditions Providers
Service Requests Service Requests
Configurations
Service Alerts

Log Updates
Modes

Maintainers

Page 6 of 18
 Page 7 of 18

Use Case Scenarios

The main flow use case scenarios are defined for the active stakeholders.

Profile Management
The profile management use case is shown below. The system manages the content providers
and drivers’ preferences through profiles.

Provider Activation Request

Provider Activation Response

Provider Profile Modify Request

Provider Profile Modify Response

Provider Termination Request

Provider Termination Response

Consumer Activation Request

Consumer Activation Response

Consumer Profile Modify Request

Consumer Profile Modify Response

Consumer Termination Request

Consumer Termination Response

Content Provider Traffic Monitoring System Driver

Page 7 of 18
 Page 8 of 18

Hazardous Weather
The hazardous weather use case is shown below. The system receives weather and road
condition information from content providers. When road conditions affect the driver based on
the driver’s location, the driver is notified. The driver then requests an alternative route to
avoid the traffic jam.

Location Notification
Acknowledgement

Weather Alert Notification

Acknowledgement

Road Conditions Notification

Acknowledgement

Weather Hazard Notification

Acknowledgement

Alternative Route Request

Alternative Route Response

Content Provider Traffic Monitoring System Driver

Page 8 of 18
 Page 9 of 18

Traffic Jams
The traffic jams use case is shown below. The system receives traffic information from content
providers. When traffic conditions affect the driver based on the driver’s location, the driver is
notified. The driver then requests an alternative route to avoid the traffic jam.

Location Notification
Acknowledgement

Traffic Alert Notification

Acknowledgement

Traffic Conditions Notification

Acknowledgement

Traffic Jam Notification

Acknowledgement

Alternative Route Request

Alternative Route Response

Content Provider Traffic Monitoring System Driver

Page 9 of 18
 Page 10 of 18

Maintenance and Diagnostic

The maintenance and diagnostics use case is shown below. The system receives a service
request from a driver. The request is forwarded to the maintainers. The maintainers test and
modify the system in diagnostics mode returning the system to normal operation after
maintenance completion.

Service Request
Acknowledgement

Service Alert
Acknowledgement

Diagnostics Mode Request

Diagnostics Mode Response

Self Test Request

Self Test Response

Configuration Change Request

Configuration Change Response

Log Update Request

Acknowledgement

Normal Mode Request

Normal Mode Response

Normal Operation Notification

Acknowledgement

Driver or
Maintainers Traffic Monitoring System Content Provider

Page 10 of 18
 Page 11 of 18

Installation
The installation use case is shown below. The system receives an installation request from a
driver. The request is forwarded to the installers. The installers install and configure the
system in installation mode returning the system to normal operation after installation
completion.

Installation Request
Acknowledgement

Installation Alert
Acknowledgement

Installation Mode Request

Installation Mode Response

Self Test Request

Self Test Response

Configuration Change Request

Configuration Change Response

Log Update Request

Acknowledgement

Normal Mode Request

Normal Mode Response

Normal Operation Notification

Acknowledgement

Driver or
Installers Traffic Monitoring System Content Provider

Page 11 of 18
 Page 12 of 18

Quality Function Deployment

Installation Gear Form

Amount of Information
Objectives (DDPs)

Number of items per

HOWs - System

Information Update

Maintenance Time
Configuraiton Time

Mean Time Repair

5 High, 1 Low
Responsive Time

Importance:
Installation Time
Number of user

Signal Strength
Size of device

Warning/Error

Subscription

Interpolation
Repair Time
Associated

Parts Cost
Amount of

Amount of

Displayed
screens

screen

Rate
WHATs - Stakeholder Requirements

Ease of use Intuitive +++ +++ ++ +++ + ++ 4

Installation ++ ++ +++ ++ ++ ++ ++ ++ 3

Repair ++ ++ ++ +++ ++ - ++ ++ 3

Integration with content ++ +++ + ++ 5

Configurability Differentiate vehicles +++ 3

Large customer base ++ 4

Customizable ++ + 3

Cost Low Monthly subscription +++ 5

Reliability Minimal maintenance +++ +++ +++ ++ +++ + + + + 4

Timeliness Road conditions +++ ++ ++ 5

Traffic conditions +++ ++ ++ 5

Weather conditions +++ ++ ++ 5

Efficienct commute ++ + + + + 4

Safety Less accidents + + ++ ++ 2

Reduce congestion ++ ++ 2

Key
Strong Positive Correlation +++
Medium Positive Correlation ++
Weak Positive Correlation +
No correlation
Strong Negative Correlation -
Medium Negative Correlation --
Weak Negative Correlation ---

Page 12 of 18
 Page 13 of 18

Objective Hierarchy

O perational O bjectives

C os t O bjectives O perational P erformance

O bjectives

S ubs cription < $10

S ys tem T ime O bjectives

P hys ical O bjectives Info Acces s T ime < 30 s ec

O peration within P hys ical R es pons e T ime < 3 s ec

S pec.of Nav. S ys tem
(brand, model T B D ) Info Update T ime < 1 min

Us er C onfig T ime < 30 s ec

Availability O bjectives
S tandards and P rotocols

MT B F 1 – 2 min
C ompliance with F C C
R egulations for W ireles s
D evices Maint. T ime < 30 min
between 2am and 3am
O peration within S ame S td. &
P rotocol of Nav S ys . R epair T ime < 30 min
(brand, model T B D )

L ife C ycle – min 15 yrs

C ommunication through
C ellular Medium (wireles s Integration with C urrent
Medium T B D ) Nav. S ys . within 1 Y ear
of P artner A greement

Page 13 of 18
 Page 14 of 18

System Requirements
The functional requirements in this section were derived from the use cases and QFD.

Functional Requirements

Input Requirements
 The system shall accept an activation request from a driver.
 The system shall accept an activation request from a content provider.
 The system shall accept a profile modify request from a driver.
 The system shall accept a profile modify request from a content provider.
 The system shall accept a termination request from a driver.
 The system shall accept a termination request from a content provider.
 The system shall accept a location notification from a driver.
 The system shall accept a weather alert notification from a content provider.
 The system shall accept a road conditions notification from a content provider.
 The system shall accept a weather hazard notification acknowledgement from a driver.
 The system shall accept an alternative route request from a driver.
 The system shall accept a traffic alert notification from a content provider.
 The system shall accept a traffic conditions notification from a content provider.
 The system shall accept a traffic jam notification acknowledgement from a driver.
 The system shall accept a service request from a driver.
 The system shall accept a service request from a content provider.
 The system shall accept a service alert acknowledgement from a maintainer.
 The system shall accept a diagnostics mode request from a maintainer.
 The system shall accept a self-test request from a maintainer.
 The system shall accept a self-test request from an installer.
 The system shall accept a configuration change request from a maintainer.
 The system shall accept a configuration change request from an installer.
 The system shall accept a log update request from a maintainer.
 The system shall accept a log update request from an installer.
 The system shall accept a normal mode request from a maintainer.
 The system shall accept a normal mode request from an installer.
 The system shall accept a normal operation notification acknowledgement from a driver.
 The system shall accept a normal operation notification acknowledgement from a content
provider.
 The system shall accept an installation request from a driver.
 The system shall accept an installation request from a content provider.
 The system shall accept an installation alert acknowledgement from an installer.
 The system shall accept an installation mode request from an installer.

Output Requirements
 The system shall provide an activation response to a driver.
 The system shall provide an activation response to a content provider.
 The system shall provide a profile modify response to a driver.
 The system shall provide a profile modify response to a content provider.
 The system shall provide a termination response to a driver.
 The system shall provide a termination response to a content provider.
 The system shall provide a location acknowledgement to a driver.
 The system shall provide a weather alert notification acknowledgement to a content
provider.
 The system shall provide a road conditions notification acknowledgement to a content
provider.
 The system shall provide a weather hazard notification to a driver.
Page 14 of 18
 Page 15 of 18
 The system shall provide an alternative route response to a driver.
 The system shall provide a traffic alert notification acknowledgement to a content
provider.
 The system shall provide a traffic conditions notification acknowledgement to a content
provider.
 The system shall provide a traffic jam notification to a driver.
 The system shall provide a service acknowledgement to a driver.
 The system shall provide a service acknowledgement to a content provider.
 The system shall provide a service alert to a maintainer.
 The system shall provide a diagnostics mode response to a maintainer.
 The system shall provide a self-test response to a maintainer.
 The system shall provide a self-test response to an installer.
 The system shall provide a configuration change response to a maintainer.
 The system shall provide a configuration change response to an installer.
 The system shall provide a log update acknowledgement to a maintainer.
 The system shall provide a log update acknowledgement to an installer.
 The system shall provide a normal mode response to a maintainer.
 The system shall provide a normal mode response to an installer.
 The system shall provide a normal operation notification to a driver.
 The system shall provide a normal operation notification to a content provider.
 The system shall provide an installation acknowledgement to a driver.
 The system shall provide an installation acknowledgement to a content provider.
 The system shall provide an installation alert to an installer.
 The system shall provide an installation mode response to an installer.

Interface Requirements
 The navigation system (specific brand and model TBD) shall provide the system external
interfaces.
 The system shall integrate with the navigation system (specific brand and model TBD)
internal interfaces.

System-wide Requirements

Suitability Requirements
 Accessing the required information shall take less than 30 seconds and less than 4 user
screens.
 The number of items per screen shall be such that it takes the user less than 5 seconds
to see all of them.
 The system shall be easily configured within 30 seconds for driver use.
 The system shall have a MTBF of greater than 1 year. The design goal is 2 years.
Failure is defined to be a complete inability to provide traffic updates.
 All system warnings or error messages shall fit within system screen.
 Response time from button select to screen output shall be less than 3 seconds.
 User set-up time shall take less than 10 minutes.
 Maintenance on system shall occur between 2am and 3am daily and shall take less than
one-half hour.
 Repair time of system unit is limited to 30 minutes before user is notified that repair time
must be extended.

Physical Requirements
 The system shall operate within the physical specifications of the navigation system
(specific brand and model TBD).

Page 15 of 18
 Page 16 of 18
Technology Requirements
 The road, traffic, and weather conditions for the requested location shall be current as of
the previous 1 minute.

Cost Requirements
 The system operational costs shall be $10 a month through a subscription plan.

Standards and Protocols

 The system shall support the same standards and protocols as navigation system
(specific brand and model TBD).
 The system shall comply with FCC regulations for wireless devices.
 The system shall communicate through cellular (specific wireless medium TBD).

Schedule Requirements by Phase

 The system shall have an expected life of at least 15 years.
 The system shall integrate with existing navigation systems within 1 year of partner
agreement.

Supportability and Maintenance

 The system shall provide sparing of monitoring site equipment.
 The system shall provide training for maintenance personnel.

Functional Architecture
Shown on the next page is the functional architecture using an IDEF0 A1 diagram

Page 16 of 18
Page 17 of 18

Page 17 of 18

Risks
Item Severity Risk Description
1 High Timeliness of content provider
data
2 Medium Development of common set of
diagnostic tools to maintain
system and co-operability with
content provider and selected
navigation systems within
allocated time.
3 Medium Interfaces for selected
navigation systems may be
much different adding to
design and material costs.
4 Medium Cost risk will increase time and
effort to design different
interfaces for various
navigation systems.
5 Low Integration with multiple
navigation systems.
6 Low Cooperation and collaboration
needed from navigation system
manufacturers.
Page 18 of 18
Primary
Impact Mitigation Plan
Performance Perform modeling and simulation
of response times from content
provider systems. Prototype with
content providers.
Maintanence Involve maintenance team in
technical discussions with
selected navigation system
makers and content provider.
Integration Periodic Technical Interchange
Meetings (TIMs) to discuss
integration issues.
Cost Periodic TIMs to discuss
integration issues.
Integration Define set of interfaces (hw/sw)
to conform to leading navigation
systems. Periodic TIMs to discuss
integration issues.
Integration Periodic TIMs to discuss
integration issues.
Page 18 of 18