![](media/image1.png)

Developing Functional Requirements

**for ITS Projects**

# April 2002

![](media/image2.png){width="5.25in" height="3.75in"}

# Prepared for

# Intelligent Transportation Systems

# Joint Program Office

**US Department of Transportation**

**By Mitretek Systems, Inc.**

**Technical Report Documentation Page**

+---------------------+---+----------+---------+---+---------+--------+
| 1\. Report No.      | 2 |          |         | 3 |         |        |
|                     | \ |          |         | \ |         |        |
| > FHWA-OP-02-047    | . |          |         | . |         |        |
|                     | G |          |         | R |         |        |
|                     | o |          |         | e |         |        |
|                     | v |          |         | c |         |        |
|                     | e |          |         | i |         |        |
|                     | r |          |         | p |         |        |
|                     | n |          |         | i |         |        |
|                     | m |          |         | e |         |        |
|                     | e |          |         | n |         |        |
|                     | n |          |         | t |         |        |
|                     | t |          |         | \ |         |        |
|                     | A |          |         | ' |         |        |
|                     | c |          |         | s |         |        |
|                     | c |          |         | C |         |        |
|                     | e |          |         | a |         |        |
|                     | s |          |         | t |         |        |
|                     | s |          |         | a |         |        |
|                     | i |          |         | l |         |        |
|                     | o |          |         | o |         |        |
|                     | n |          |         | g |         |        |
|                     | N |          |         | N |         |        |
|                     | o |          |         | o |         |        |
|                     | . |          |         | . |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 4\. Title and       |   |          |         | 5 |         |        |
| Subtitle            |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
| > Developing        |   |          |         | R |         |        |
| > Functional        |   |          |         | e |         |        |
| > Requirements for  |   |          |         | p |         |        |
| > ITS Projects      |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | D |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | > |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | A |         |        |
|                     |   |          |         | p |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | l |         |        |
|                     |   |          |         | > |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | 2 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 2 |         |        |
+---------------------+---+----------+---------+---+---------+--------+
|                     |   |          |         | 6 |         |        |
|                     |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
|                     |   |          |         | P |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | f |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | m |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | O |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | z |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | C |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | d |         |        |
|                     |   |          |         | e |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 7\. Author(s)       |   |          |         | 8 |         |        |
|                     |   |          |         | \ |         |        |
| > Paul J. Gonzalez, |   |          |         | . |         |        |
| > Thomas B. Fowler  |   |          |         | P |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | f |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | m |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | O |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | z |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | R |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | p |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | N |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | . |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 9\. Performing      |   |          |         | 1 |         |        |
| Organization Name   |   |          |         | 0 |         |        |
| and Address         |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
| > Mitretek Systems, |   |          |         | W |         |        |
| > Inc.              |   |          |         | o |         |        |
| >                   |   |          |         | r |         |        |
| > 600 Maryland      |   |          |         | k |         |        |
| > Avenue, SW, Suite |   |          |         | U |         |        |
| > 755               |   |          |         | n |         |        |
| >                   |   |          |         | i |         |        |
| > Washington, DC    |   |          |         | t |         |        |
| > 20024             |   |          |         | N |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | . |         |        |
|                     |   |          |         | ( |         |        |
|                     |   |          |         | T |         |        |
|                     |   |          |         | R |         |        |
|                     |   |          |         | A |         |        |
|                     |   |          |         | I |         |        |
|                     |   |          |         | S |         |        |
|                     |   |          |         | ) |         |        |
+---------------------+---+----------+---------+---+---------+--------+
|                     |   |          |         | 1 |         |        |
|                     |   |          |         | 1 |         |        |
|                     |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
|                     |   |          |         | C |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | c |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | G |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | a |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | t |         |        |
|                     |   |          |         | N |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | . |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | > |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | D |         |        |
|                     |   |          |         | T |         |        |
|                     |   |          |         | F |         |        |
|                     |   |          |         | H |         |        |
|                     |   |          |         | 6 |         |        |
|                     |   |          |         | 1 |         |        |
|                     |   |          |         | - |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | - |         |        |
|                     |   |          |         | C |         |        |
|                     |   |          |         | - |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 0 |         |        |
|                     |   |          |         | 1 |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 12\. Sponsoring     |   |          |         | 1 |         |        |
| Agency Name and     |   |          |         | 3 |         |        |
| Address             |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
| > Department of     |   |          |         | T |         |        |
| > Transportation    |   |          |         | y |         |        |
| >                   |   |          |         | p |         |        |
| > Intelligent       |   |          |         | e |         |        |
| > Transportation    |   |          |         | o |         |        |
| > Systems Joint     |   |          |         | f |         |        |
| > Program Office    |   |          |         | R |         |        |
| >                   |   |          |         | e |         |        |
| > 400 Seventh       |   |          |         | p |         |        |
| > Street, SW --     |   |          |         | o |         |        |
| > Room 3416         |   |          |         | r |         |        |
| >                   |   |          |         | t |         |        |
| > Washington, DC    |   |          |         | a |         |        |
| > 20590             |   |          |         | n |         |        |
|                     |   |          |         | d |         |        |
|                     |   |          |         | P |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | d |         |        |
|                     |   |          |         | C |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | v |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | d |         |        |
+---------------------+---+----------+---------+---+---------+--------+
|                     |   |          |         | 1 |         |        |
|                     |   |          |         | 4 |         |        |
|                     |   |          |         | \ |         |        |
|                     |   |          |         | . |         |        |
|                     |   |          |         | S |         |        |
|                     |   |          |         | p |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | s |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | r |         |        |
|                     |   |          |         | i |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | A |         |        |
|                     |   |          |         | g |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         | n |         |        |
|                     |   |          |         | c |         |        |
|                     |   |          |         | y |         |        |
|                     |   |          |         | C |         |        |
|                     |   |          |         | o |         |        |
|                     |   |          |         | d |         |        |
|                     |   |          |         | e |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | > |         |        |
|                     |   |          |         |   |         |        |
|                     |   |          |         | H |         |        |
|                     |   |          |         | O |         |        |
|                     |   |          |         | I |         |        |
|                     |   |          |         | T |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 15\. Supplementary  |   |          |         |   |         |        |
| Notes               |   |          |         |   |         |        |
|                     |   |          |         |   |         |        |
| > William S. Jones  |   |          |         |   |         |        |
| > -- Task Manager   |   |          |         |   |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 16\. Abstract       |   |          |         |   |         |        |
|                     |   |          |         |   |         |        |
| This monograph is   |   |          |         |   |         |        |
| one of a series     |   |          |         |   |         |        |
| intended to         |   |          |         |   |         |        |
| introduce systems   |   |          |         |   |         |        |
| engineering topics  |   |          |         |   |         |        |
| to managers and     |   |          |         |   |         |        |
| staff working on    |   |          |         |   |         |        |
| transportation      |   |          |         |   |         |        |
| systems projects,   |   |          |         |   |         |        |
| with particular     |   |          |         |   |         |        |
| emphasis on         |   |          |         |   |         |        |
| Intelligent         |   |          |         |   |         |        |
| Transportation      |   |          |         |   |         |        |
| Systems (ITS)       |   |          |         |   |         |        |
| projects. Systems   |   |          |         |   |         |        |
| engineering is a    |   |          |         |   |         |        |
| discipline that has |   |          |         |   |         |        |
| been used for over  |   |          |         |   |         |        |
| 50 years and has    |   |          |         |   |         |        |
| its roots in the    |   |          |         |   |         |        |
| building of large,  |   |          |         |   |         |        |
| complex systems for |   |          |         |   |         |        |
| the Department of   |   |          |         |   |         |        |
| Defense. Systems    |   |          |         |   |         |        |
| engineering is an   |   |          |         |   |         |        |
| approach to         |   |          |         |   |         |        |
| building systems    |   |          |         |   |         |        |
| that enhances the   |   |          |         |   |         |        |
| quality of the end  |   |          |         |   |         |        |
| result and the      |   |          |         |   |         |        |
| expectation is that |   |          |         |   |         |        |
| its application to  |   |          |         |   |         |        |
| transportation      |   |          |         |   |         |        |
| systems projects    |   |          |         |   |         |        |
| will make those     |   |          |         |   |         |        |
| projects more       |   |          |         |   |         |        |
| effective in        |   |          |         |   |         |        |
| developing and      |   |          |         |   |         |        |
| implementing the    |   |          |         |   |         |        |
| systems they are    |   |          |         |   |         |        |
| intended to build.  |   |          |         |   |         |        |
| Although applying   |   |          |         |   |         |        |
| systems engineering |   |          |         |   |         |        |
| techniques on a     |   |          |         |   |         |        |
| project doesn't     |   |          |         |   |         |        |
| guarantee success,  |   |          |         |   |         |        |
| not following a     |   |          |         |   |         |        |
| systems engineering |   |          |         |   |         |        |
| approach is a       |   |          |         |   |         |        |
| strong recipe for   |   |          |         |   |         |        |
| failure.            |   |          |         |   |         |        |
|                     |   |          |         |   |         |        |
| This monograph is   |   |          |         |   |         |        |
| primarily geared to |   |          |         |   |         |        |
| ITS project         |   |          |         |   |         |        |
| managers and        |   |          |         |   |         |        |
| systems engineers   |   |          |         |   |         |        |
| on ITS projects,    |   |          |         |   |         |        |
| the front line      |   |          |         |   |         |        |
| people who convert  |   |          |         |   |         |        |
| high-level goals    |   |          |         |   |         |        |
| and plans into      |   |          |         |   |         |        |
| implemented ITS     |   |          |         |   |         |        |
| systems. Good       |   |          |         |   |         |        |
| functional          |   |          |         |   |         |        |
| requirements are    |   |          |         |   |         |        |
| essential to good   |   |          |         |   |         |        |
| systems. Experience |   |          |         |   |         |        |
| shows that the      |   |          |         |   |         |        |
| failure to write    |   |          |         |   |         |        |
| good functional     |   |          |         |   |         |        |
| requirements often  |   |          |         |   |         |        |
| leads to serious    |   |          |         |   |         |        |
| project problems,   |   |          |         |   |         |        |
| sometimes even to   |   |          |         |   |         |        |
| project failure.    |   |          |         |   |         |        |
| While having good   |   |          |         |   |         |        |
| functional          |   |          |         |   |         |        |
| requirements does   |   |          |         |   |         |        |
| not guarantee       |   |          |         |   |         |        |
| success, it         |   |          |         |   |         |        |
| provides the        |   |          |         |   |         |        |
| project with a      |   |          |         |   |         |        |
| better chance at    |   |          |         |   |         |        |
| success. This       |   |          |         |   |         |        |
| monograph presents  |   |          |         |   |         |        |
| guidelines to help  |   |          |         |   |         |        |
| ITS project         |   |          |         |   |         |        |
| managers and staff  |   |          |         |   |         |        |
| develop good        |   |          |         |   |         |        |
| functional          |   |          |         |   |         |        |
| requirements.       |   |          |         |   |         |        |
|                     |   |          |         |   |         |        |
| This monograph is   |   |          |         |   |         |        |
| intended for use in |   |          |         |   |         |        |
| conjunction with    |   |          |         |   |         |        |
| the systems         |   |          |         |   |         |        |
| engineering courses |   |          |         |   |         |        |
| being offered by    |   |          |         |   |         |        |
| the National        |   |          |         |   |         |        |
| Highway Institute.  |   |          |         |   |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 17\. Key Word       |   |          | 18\.    |   |         |        |
|                     |   |          | Distr   |   |         |        |
| > Systems           |   |          | ibution |   |         |        |
| > Engineering,      |   |          | St      |   |         |        |
| > Intelligent       |   |          | atement |   |         |        |
| > Transportation    |   |          |         |   |         |        |
| > Systems, ITS,     |   |          | > No    |   |         |        |
| > Transportation    |   |          | > Restr |   |         |        |
| > System Projects,  |   |          | ictions |   |         |        |
| > Requirements,     |   |          | >       |   |         |        |
| > Functional        |   |          | > This  |   |         |        |
| > Requirements      |   |          | > d     |   |         |        |
|                     |   |          | ocument |   |         |        |
|                     |   |          | > is    |   |         |        |
|                     |   |          | > av    |   |         |        |
|                     |   |          | ailable |   |         |        |
|                     |   |          | > to    |   |         |        |
|                     |   |          | > the   |   |         |        |
|                     |   |          | >       |   |         |        |
|                     |   |          | public. |   |         |        |
+---------------------+---+----------+---------+---+---------+--------+
| 19\. Security       |   | 20\.     |         |   | 21\.    | 22\.   |
| Classif. (of this   |   | Security |         |   | No. of  | Price  |
| report)             |   | Classif. |         |   | Pages   |        |
|                     |   | (of this |         |   |         | > NA   |
| > Unclassified      |   | page)    |         |   | > 69    |        |
|                     |   |          |         |   |         |        |
|                     |   | > Uncl   |         |   |         |        |
|                     |   | assified |         |   |         |        |
+---------------------+---+----------+---------+---+---------+--------+

**Form DOT F 1700.7** (8-72) Reproduction of completed page authorized

**Table of Contents**

**Section Page**

List of Figures and Tables iii

**Executive Summary** vii

**Chapter 1 - Introduction** 1

> Purpose of This Document 1
>
> Intended Audience 1

**Chapter 2 -- What Are Functional Requirements?** 3

> Types of System Requirements 3
>
> Definition of Functional Requirements 5
>
> Functional Requirements and the Systems Engineering Process 5
>
> Characteristics of Good Functional Requirements 9
>
> The Importance of Good Functional Requirements 12

**Chapter 3 -- Functional Requirements and the National ITS
Architecture** 15

> How Does the National ITS Architecture Relate to Functional
> Requirements? 15
>
> How the National ITS Architecture Influences Functional Requirements
> 18
>
> The National ITS Architecture As Model 20
>
> The National ITS Architecture As Guide 20
>
> The National ITS Architecture As a Boundary 20
>
> Why Aren't User Service Requirements Sufficient As Functional\
> Requirements? 21
>
> National versus Regional Architectures 22

**Chapter 4 -- Analyzing and Writing ITS Functional Requirements** 23

> Where Do You Start? 23
>
> Needs Analysis 23
>
> Concept of Operations 26
>
> Fact-Gathering 26
>
> Writing a Requirements Document 28
>
> Analyzing the Requirements 29
>
> Reviewing the Requirements with Stakeholders 30
>
> Functional Requirements Writing Styles 31
>
> Examples of Good and Bad Functional Requirements 33

**Chapter 5 -- Using Functional Requirements on an ITS Project** 35

> How Functional Requirements Affect the Implementation Process 35
>
> Functional Requirements as the Basis for the System to be Built 35
>
> Functional Requirements as Basis for Enhancements to Existing Systems
> 37
>
> Functional Requirements as Basis for Contractors' Work Program 38
>
> Requirements Tracing As a Testing and Quality Assurance Method 39

**Chapter 6 -- Managing Functional Requirements** 41

> Scope Creep 41
>
> Configuration Management 42
>
> Establishing a System Baseline 42
>
> Managing the Configuration 44

**Chapter 7 -- Where to Go to Get More Help** 49

> Department of Transportation Resources 49
>
> Electronic Document Library (EDL) 49
>
> National ITS Architecture Web Site and CD-ROM 49
>
> Turbo Architecture 49
>
> Software Tools 49

Appendixes

> **A. Example Table of Contents for a Functional Requirements\
> Document** 51
>
> **B. Glossary of Terms** 55
>
> **C. References** 57

**List of Tables and Figures**

**Tables**

## No. Name Page

1.  Key Requirements Questions For Systems Engineering 9

2.  Relative Costs to Fix an Error by Project Phases 13

3.  User Service Bundles and User Services 17

4.  User Service Requirements in Incident Management User Service 18

**Figures**

**No. Name Page**

1.  "V" Model 6

2.  Progression from User Needs to National ITS Architecture 16

3.  Sample (Partial) Process Specification Description 19

4.  Relationship of Subsystems, Market Packages, and Equipment Packages
    37

5.  Requirements Traceability Matrix -- Requirements to Subsystems 39

6.  Requirements Traceability Matrix -- Tests versus Requirements 40

7.  Evaluation Cube -- Cost, Schedule, Value Inputs 46

### Executive Summary

This document is one of a series of monographs that introduce systems
engineering topics to transportation and transit engineers involved in
Intelligent Transportation Systems (ITS) projects. Other monographs in
this series include:

-   *Building Quality Intelligent Transportation Systems Through Systems
    Engineering*

-   *Understanding Software Development: A Primer for ITS Public Sector
    Managers*

-   *A Guide to Configuration Management for Intelligent Transportation
    Systems*

This monograph focuses on the development of functional requirements for
ITS projects and is intended for the following audience:

-   ITS project managers

-   ITS project team members

-   ITS project Contractors and staff

-   Transportation system planners

-   Anyone else interested in writing quality functional requirements to
    support project implementation

The monograph is primarily geared to ITS project managers and system
engineers on ITS projects, who are the front-line people that convert
high-level goals and plans into implemented ITS systems.

**What Are Functional Requirements?**

Functional requirements are statements of the capabilities that a system
must have ("functions"), geared to addressing the *business needs* that
a system must satisfy. *Business needs* are mission-oriented objectives
of the organization for which the system is built. For example, a
*business need* of a Traffic Management Center (TMC) could be to manage
incidents (e.g., accidents, hazardous materials spills on the roadway)
that occur within the TMC's area of operation. Good functional
requirements are written *without specifying implementation details*.
The organization for which the system is being built should describe
*what* must be done. It's up to the implementer of the system to decide
*how* that function should be implemented, given the constraints of time
and money that have been established.

Well-written functional requirements should have the following
characteristics:

-   Necessary. Something that must be included or an important element
    of the system is missing and other system components can't
    compensate for its absence.

-   Concise (*minimal*, *understandable)*. Stated in language that is
    easy to read, yet conveys the essence of what is needed.

-   Attainable (*achievable* *or feasible*). A realistic capability that
    can be implemented for the available money, with the available
    resources, in the available time.

-   Complete (*standalone)*. Described in a manner that does not force
    the reader to look at additional text to know what the requirement
    means.

-   Consistent. Does not contradict other stated requirements nor is it
    contradicted by other requirements. In addition, uses terms and
    language that means the same from one requirements statement to the
    next.

-   Unambiguous. Open to only one interpretation.

-   Verifiable. Must be able to determine that the requirement has been
    met through one of four possible methods: inspection, analysis,
    demonstration, or test.

Good functional requirements are essential to good systems. Studies done
to assess why software projects have failed or have not been completed
have shown that the cost to fix an error that occurs during the
project's requirements phases goes up dramatically in each later stage.
Figure ES-1 below illustrates this study's findings.

![](media/image3.wmf){width="4.335416666666666in"
height="3.9319444444444445in"}

Figure ES-1

Relative Cost to Fix an Error, by Project Phases

What can be a small cost during the Requirements phase of a project is
up to 1000 times greater once the system goes into operation. Even
during the Acceptance Testing phase the cost can be 30 to 70 times
higher. So potential savings in project cost is one reason to get
requirements right.

**Functional Requirements and Systems Engineering**

*Requirements analysis* is a phase within all system development life
cycle models. The phase may not have that explicit name in all models,
but it's recognized as a key part of the system development process. The
systems engineering approach starts with high-level requirements,
usually derived from the Concept of Operations for the system and then
continually refines and expands on these requirements descriptions until
a sound set of system requirements are developed. The process of
developing functional requirements is illustrated in Figure ES-2.

Requirements review is a critical component in the process and the last
step prior to iterating. This step means that you, as the ITS Project
Manager, bring your stakeholders together, along with any contractors
that you may have brought in to help you develop your system, and go
through each requirement -- in detail -- to ensure that everyone has the
same understanding of what the requirement means and what impact
implementing the requirement will have on the overall system.

It's important to ensure that you, your stakeholders, and your
contractor(s) agree on what the requirements are and what they mean.
Implementing a system and then having the users tell you that you
misinterpreted their needs means that you've wasted valuable time and
money. You'll either then go over budget to correct your mistakes or
you'll have a "white elephant" system that won't provide much utility.

**Functional Requirements, the National ITS Architecture, and Regional
ITS Architectures**

The National ITS Architecture was developed to address user needs that
were ultimately articulated as User Service Requirements. User Service
Requirements are high-level functional requirements and the various
elements of the National ITS Architecture deal with ways of satisfying
them. Since User Service Requirements are included in the distribution
media for the National ITS Architecture material, you can compare them
to the functional requirements your own users provide, to see if your
users may have overlooked any important requirements. However, the
National ITS Architecture may address requirements that your region
doesn't have. For example, a rural area may not have the same
requirements for transit information as does an urban area.

The rule[^1]^S-1^ enacted by the U.S. Department of Transportation (DOT)
on conformity with the National ITS Architecture requires regions to
develop a regional ITS architecture, i.e., a local implementation of the
National ITS Architecture, within four years after the region's first
ITS project advances to final design. All subsequent ITS projects in the
region must adhere to that regional ITS architecture. This makes the
regional ITS architecture, once it's developed, the driving force for
all ITS projects in the region. Regional users of ITS systems must
define their high-level functional requirements as part of the process
of developing a well-defined regional ITS architecture.

**Using Functional Requirements on an ITS Project**

Functional requirements serve as the basis for the system to be built.
In this capacity, they help you:

-   Determine whether to build or buy a system component.

-   Interface subsystems or components.

-   Conduct performance testing of subsystems and systems.

-   Conduct acceptance testing of the final system.

You can also use functional requirements to define enhancements to
existing systems and to develop statements of work for contractors. When
you compare the functional requirements for an enhanced version of a
system to its existing capability, it helps you develop a *migration
plan* or route to follow in implementing the desired enhancements. The
migration plan also points out which parts of the system you can leave
untouched, because there will be no changes to functionality in them.
Writing a Statement of Work (SOW) for a contractor's effort is easier
when you can spell out the functionality that you'll want the contractor
to implement. (Don't forget, however, that you still need to conduct a
requirements walkthrough, even if you have an SOW with written
functional requirements.)

**Requirements Tracing**

One of the key items that you'll create as part of your requirements
package is a *requirements traceability matrix*. A requirements
traceability matrix maps requirements that you've written against the
components and subsystems in which you expect to satisfy them. It is
helpful in developing tests and test plans, since you know which
requirements you need to test when a part of the system has been
developed. But, in addition, the requirements traceability matrix also
helps you make sure that you don't overlook any requirements. If you
can't trace, through this tool, a requirement to a system component, it
clearly hasn't been addressed.

**Managing Requirements**

After you have a set of requirements that you and your stakeholders have
agreed upon, one of your next major tasks is keeping those requirements
under control. Good systems development practice calls for systems to be
built in small increments that you can control and manage effectively.
This means that you won't implement all of the functionality of a system
all at once, unless the system is very simple and small.

This fact, and other external factors, leads to changes in system
requirements. One goal of an ITS project manager should be to keep the
requirements change process under control, not to avoid making changes.
Change is a natural and healthy aspect of system development.
*Uncontrolled* change, however, is disastrous. You want to control
change, through the process known as "configuration management."

*Configuration management* is a process that applies to more than just
requirements management. The process is described in more detail in a
companion monograph in this series, *A Guide to Configuration Management
for Intelligent Transportation Systems*. The key point for this
monograph, however, is that configuration management provides a process
that allows you to make changes to your requirements after you've
considered and evaluated the impact of those changes on the overall
project, its costs, and the schedule for completing it. You make changes
only after you know the expected effect of those changes.

Functional requirements are an important part of the design of any
information system, not just ITS systems. An advantage that you have as
an ITS project manager is the availability of the National ITS
Architecture to help you develop functional requirements. Software tools
exist that you can use to develop and maintain functional requirements.
None of these tools deal solely with functional requirements; usually,
they are part of an overall Computer Assisted Software Engineering
(CASE) package.

We hope that this monograph also serves as a useful tool in determining
how to develop and use functional requirements for ITS projects.

# 1. Introduction

## Purpose of This Document

This document is one of a series of monographs intended to introduce
topics that can help transportation and transit engineers involved in
Intelligent Transportation Systems (ITS) projects. Other monographs in
this series include:

-   *Building Quality Intelligent Transportation Systems Through Systems
    Engineering*

-   *Understanding Software Development: A Primer for ITS Public Sector
    Managers*

-   *A Guide to Configuration Management for Intelligent Transportation
    Systems*

This document focuses on the development of functional requirements as a
basis for ITS projects. We'll examine the National ITS Architecture,
which contains representative functional requirements for ITS systems,
as a tool for identifying the types of requirements that we must
establish to guide ITS project development and system implementation.
Then we'll discuss how to go about developing good functional
requirements and what they are.

## Intended Audience

The audience for this document includes the following:

-   ITS project managers

-   ITS project team members

-   ITS project Contractors and staff

-   Transportation system planners

-   Anyone else interested in writing quality functional requirements to
    support project implementation

We've primarily geared it, however, to ITS project managers and system
engineers on ITS projects, who must convert high-level goals and plans
into requirements documents that become the basis for ITS system
implementation. The combination of good system engineering practices and
good functional requirements help project managers succeed in their
efforts. Of course, there is no "magic bullet" that guarantees success
in any project; external factors can always cause a project to fail. And
there is no single formula that, when applied mechanically, guarantees
you can produce good functional requirements; in this area, as in many
others, experience and judgment are very important. However, there are
general guidelines we can give you to use. We'll also provide some
examples you might use to your benefit. Experience shows that failure to
write good functional requirements often leads to serious project
problems, possibly even to project failure. Having good functional
requirements, while it may not guarantee success, gives you a better
chance to succeed.

Let's begin by looking at what functional requirements are all about.

# 2. What are Functional Requirements?

When working on an ITS project, you should have a clear idea of what
your project is to accomplish, and what the system you're going to
implement should do when completed. From the people who want the system,
you're going to get some "high-level" goals and objectives and some
"requirements." These goals, objectives, and requirements specify *what*
is to be accomplished, but they may not give you a sound basis for
planning and executing your project. What you must do is translate the
initial set of information that you receive into *functional
requirements*, which are statements of the things the system you're
implementing must do, in enough detail to guide you in designing a
system that meets those requirements.

## Types of System Requirements

Our primary focus in this document is on *functional* requirements, and
we'll define what we mean by *functional* requirements a few pages from
now. But functional requirements aren't the only type of system
requirements that you'll need. In addition, you usually find three other
types of system requirements defined (and there may be more types
defined as well). The three key types of system requirements usually
developed, in addition to functional requirements, are:

-   Performance requirements

-   Interface requirements

-   Human-Machine interface requirements

Before we discuss functional requirements, let's take a quick look at
these other types of system requirements and explain them.

**Performance Requirements.** This type of system requirement states the
performance parameters of some capability within the system. Our example
comes from the State of Maryland's Chesapeake Highways Advisory Routing
Traffic (CHART) software requirements document. In it, the following
requirement for the Device Control Subsystem appears:

> The Maryland Transportation Authority's (MdTA's) Device Control
> Subsystem must be ... designed to allow for expansion of up to 10,000
> devices and 100 protocols.

The device control subsystem has a requirement that it be capable of
handling up to 10,000 devices and 100 protocols. This requirement sets a
performance limit (it does not need to handle 10,001 devices nor need it
handle 101 protocols) and a performance goal (if the subsystem cannot
handle 9,999 or 99 protocols, it fails to meet this performance
requirement). Is the requirement testable, i.e., can you determine
whether it's been met? With a little work, probably. You may need to
simulate devices to get the test device count up to 10,000 \-- depending
on how many devices the current system has. As far as the 100 protocols
are concerned, you may need to define this element more precisely (what
constitutes a "different" protocol such that it would be included in the
count), but you should still be able to come up with a test suite.

**Interface Requirements.** We're distinguishing here between
"interfaces" with users (Human-Machine Interface, which we'll cover
next) and "interfaces" with other systems. Most systems interact with
other systems, either already deployed or being deployed. In general,
you must work out the interface between any two systems carefully and
specify it (or them, if there are several interfaces between two
systems) in considerable detail[^2]. Sometimes, these requirements go
beyond functionality and border on detailed design, including language
that mentions specific manufacturer's parts. You may have requirements
both for external interfaces, i.e., other systems with which your system
must interact, and for internal interfaces, i.e., subsystems within your
main system interacting with each other. An example of an external
interface is a toll collection system that connects to systems at
financial institutions to initiate transfer of money. An internal
interface might be the interface between high-speed video cameras and a
real‑time video storage device. Interface requirements are sometimes
hard to work out, particularly with external systems. You frequently
must establish a working relationship with the "owner" of the external
system to work out all of the detail of making your system interface
with the other.

**Human-Machine Interface Requirements.** The way that a user interacts
with a system strongly influences what the user thinks about the system
capabilities. A system could be a high‑quality, well performing system,
but if the user interface is poor, that's not the way it's perceived.
Getting these requirements right might not be the most important thing
you do on a project, but it ranks up there among the top five. It's not
just important from a user satisfaction point of view; user interfaces
can affect how well the system is operated. There are many horror
stories about poorly designed human-machine interfaces causing system
failures. Sometimes, the failures can lead to fatalities. The airplane
crash that killed singer John Denver was attributed to a poor interface
design that required the pilot (Denver) to turn around while seated to
reach a key control. However, the cockpit design caused him to press on
the rudder pedals, sending the plane into a fatal spin. Another, more
recent example of poor human interface design is the "butterfly" ballot
used in Florida for the 2000 Presidential election. Controversy over how
voters interpreted those ballots led to weeks of uncertainty regarding
the final outcome of that election. A third example of a poor human
interface was the design of the control room indicators at the Three
Mile Island nuclear facility. When the reactor started to overheat, the
operators didn't notice the malfunction until far along in the cycle,
when it was almost too late to prevent a full meltdown. While we don't
expect similar extreme results from poor human-machine interface design
on an ITS project, we do recommend that you place a high priority on
getting these right.

So, after that brief digression, let's define what we mean by a
*functional* requirement.

## Definition of Functional Requirements

Martin[^3] defines functional requirements as follows:

\(1\) the necessary task, action, or activity that must be accomplished,
or (2) [what]{.underline} the system or one of its components must do

A key aspect of the functional requirement is that it addresses
[what]{.underline} a system must do, but does not address
[how]{.underline} the system should accomplish the [what]{.underline}.
In other words, a functional requirement should not go into the details
of how to implement the function. This is key to writing good functional
requirements.

There's a second aspect of functional requirements that is important.
Functional requirements are geared to the *business needs* a system must
satisfy, i.e., they must address those activities that constitute the
mission or business objectives of the organization that wants the
system; they're not there to provide "bells and whistles." We'll expand
on this point later.

Some authors include *design constraints* in the list of functional
requirements. *Design constraints* are requirements imposed by factors
outside of your control. For example, if you have a requirement to
install new hardware in an existing vehicle as part of the
implementation of an ITS system, one *design constraint* that you'll
face is the capability of the power source available to run the hardware
along with other vehicle hardware. If you place too high a power drain
on the vehicle's power supply with your new hardware, you risk failure
in other important vehicle systems. As long as you state the *design
constraint* as "what" needs to be done and not "how" it needs to be
done, it fits in with the definition of *functional requirement.*

## Functional Requirements and the Systems Engineering Process

The requirements for a system drive its design and development.
Functional requirements are major drivers because they define
[what]{.underline} the system must do, but obviously they're not the
only drivers. One way of seeing the impact of requirements on the final
system is to look at how all of the front-end activities in the system
development effort affect the later stages in the system's evolution. We
can see this impact easily by using a model or depiction of the systems
engineering process known as the "V" (or "VEE") model.

The "V" model, illustrated in Figure 1, shows the early stages in
building a system as steps along the left leg of the "V," the
decomposition leg of the process. The steps on the decomposition leg
break the system down into its pieces, proceeding from development of a
Concept of Operations[^4] for the system, through the definition and
refinement of the system's requirements (going from high-level to
detailed requirements), to the system design stage, which also goes from
high-level to detailed design. On the right-hand leg of the "V," we have
the re-composition steps, where we take and test all of the parts of the
system we've built and also put them together. As we proceed up the
right-hand leg, we combine the system's building blocks into larger and
larger pieces, until we have finally assembled and installed the
complete system.

The "V" model also helps us understand the relationships between the
work done on each side of the "V," as follows:

> **Conception (Concept of Operations stage) vs. Operations and
> Maintenance.** During the Conception stage of the system life cycle,
> you create a *Concept of Operations* for the system. The Concept of
> Operations should describe how the system will work once it's built.
> Therefore, it relates directly to the Operation and Maintenance stage,
> during which the system's Concept of Operations is realized.
>
> Looking at the explicit relationship between the two stages helps the
> systems engineer focus, at the beginning of the project, on issues
> associated with keeping the system in operation and effectively
> maintained once it's built. This long-range perspective is important
> in systems engineering.
>
> **Requirements Analysis vs. System Acceptance.** The Requirements
> Analysis stage isn't explicitly shown in the "V" diagram, but it
> covers what the "V" shows as "High-Level Requirements" and "Detailed
> Requirements," since those are the products of the Requirements
> Analysis stage. In the Requirements Analysis stage, you determine what
> the system has to do, when it has to do it, and how well it has to
> perform. In the System Acceptance stage, you determine whether the
> system you built satisfies those requirements. Satisfying those
> requirements involves two different approaches:

-   Verification -- ensuring that the desired functions have been
    implemented in the delivered system

-   Validation -- ensuring that all functions implemented in the system
    have been implemented correctly.

> Another way of describing *verification* and *validation* is that
> verification is "building the right system" and validation is
> "building the system right."
>
> It's important to recognize that you should be able to trace every
> requirement in the system to the system component that satisfies it.
> One way to do this is through a *requirements traceability matrix*,
> which we discuss in Chapter 3.
>
> **System Design vs. Integration and Testing.** The "V" diagram in
> Figure 7 actually breaks this down into two components. System Design
> is subdivided into "High-Level Design" and "Detailed Design." Directly
> across from "High-Level Design" is "Subsystem Verification," which is
> a reasonable correlation. Part of what's done in the High-Level Design
> activity is to break the system down into its subsystems, each of
> which is assigned a major functional area of the overall system. In
> Subsystem Verification, you're integrating all of the components of
> the subsystem and testing the subsystem(s) as units. It's the
> appropriate way to look at how the two stages are correlated.
>
> "Detailed Design" is directly across from the "Integration and Test"
> component. Detailed Design relates to the definition of the complete
> system, the final design of all of the elements, at the level
> necessary to build it bottom-up. The Integration and Test portion of
> the "V" is the start up on the leg where you bring all of the pieces
> together. During this stage, you'll test individual components as
> "units" and begin testing the individual units that interact with one
> another, preparing to fit them all together into individual
> subsystems.
>
> The design of a system, in part, allocates functions to be performed
> by specific system components. In addition, during design, we decide
> [how]{.underline} we're going to implement those functions. That may
> involve developing *algorithms* (i.e., specific, detailed instructions
> on how to perform a function) or developing *interfaces* that allow
> devices in our system to interoperate. The integration and testing of
> a system involves ensuring, at all levels of the system, that each
> piece works as it should and that all pieces successfully and
> accurately interact.
>
> The design stage is the final *decomposition* stage of the
> decomposition leg of system development. It's the stage where you
> establish, at the most detailed level, your plan for how you will
> accomplish the work of the system. The integration and testing stage
> is the first of the major *re-composition* stages, where you begin
> assembling the pieces of the system into an integrated whole.

At the bottom of the "V" is the Integration stage. This stage represents
the transition from decomposition (the conceptual level) to
re-composition (the physical level). During this stage, we transform the
system's design into actual products.

A quick aside on when certain things are done in a systems project. It's
fairly common on ITS projects for public sector agencies to hire
contractors either to build the ITS system or to integrate it using
commercial off‑the‑shelf (COTS) components, along with any custom-built
hardware or software needed to tie everything together. It's important
for the public sector to work together with its contractors in the
requirements definition, analysis, and refinement process. One reason is
that the system contractors usually have more experience in developing
good requirements than do public sector agencies. Developing sound
requirements is a major part of the contractors' business. Thus, they
should have the tools and skills to take the high-level user
requirements and convert them into a solid basis for a buildable system.

A second reason for the public sector to work together with system
contractors on requirements is the need for everyone on the project to
have a common understanding of what each requirement
[means]{.underline}. Writing a requirement down doesn't ensure that
everyone will interpret it the same way. English is an imperfect
language for documenting requirements. The writer and reader of a
requirement can legitimately, honestly, and with no mal intent differ on
what it means. If the public sector and the system developer have
different interpretations of any requirements and these different
interpretations are not resolved early in the project, the
misunderstandings can have serious negative impact on the project.

One way to achieve a common understanding between the public sector and
the system developer on the meaning of requirements is to conduct a
requirements review. This involves having all parties review
requirements together, discuss them, and agree on their meaning. A
requirements review can be a lengthy, painstaking process; field
experience on ITS projects indicates that it's a valuable one.

OK. Back to the discussion of requirements.

How do we determine the overall system requirements, so as to be able to
write good functional requirements? As the Systems Engineering
monograph[^5] says, an important part of systems engineering is risk
mitigation. Understanding the *domain* (in this case, ITS systems) and
having experience in developing and implementing systems is essential.
In addition, answering certain key questions is an excellent way to
ensure that we understand what we are going to do. It is from the
answers to four groups of questions that we may begin to write our
functional requirements. Refer to Table 1, which is a modified version
of a table in the Systems Engineering monograph, to see the areas of
importance for functional requirements writing indicated.

Table 1

Key Requirements Questions for Systems Engineering

+-----------+-----------------------------------------------------------+
| **Area**  | **Key Questions**                                         |
+===========+===========================================================+
| **Needs   | -   What is wrong with the current situation?             |
| A         |                                                           |
| nalysis** | -   What needs does the ITS project fill?                 |
|           |                                                           |
|           | -   Have we clearly articulated the need?                 |
|           |                                                           |
|           | -   Do all ITS project stakeholders have a common         |
|           |     understanding of its goals and objectives?            |
+-----------+-----------------------------------------------------------+
| **Concept | -   Is our concept consistent with any Architecture(s)    |
| of        |     with which it must interact?                          |
| Ope       |                                                           |
| rations** | -   Have we identified all intended users of the ITS      |
|           |     system?                                               |
|           |                                                           |
|           | -   How will each intended user interact with the ITS     |
|           |     system?                                               |
|           |                                                           |
|           | -   How is this different from the current situation, if  |
|           |     at all?                                               |
|           |                                                           |
|           | -   Do the intended users understand their role in the    |
|           |     ITS system?                                           |
|           |                                                           |
|           | -   Have we coordinated with all other agencies affected  |
|           |     by this ITS system?                                   |
+-----------+-----------------------------------------------------------+
| **Requi   | -   What specific functions will this ITS project         |
| rements** |     perform?                                              |
|           |                                                           |
|           | -   Have we defined each function in detail?              |
|           |                                                           |
|           | -   Have we identified all system interfaces?             |
|           |                                                           |
|           | -   Are all system interfaces well defined?               |
|           |                                                           |
|           | -   Have we defined our required system performance in    |
|           |     quantifiable terms?                                   |
|           |                                                           |
|           | -   Have we reviewed all requirements with stakeholders?  |
|           |                                                           |
|           | -   Have we considered system availability requirements?  |
|           |                                                           |
|           | -   Have we assessed our reliability and maintainability  |
|           |     requirements?                                         |
|           |                                                           |
|           | -   What derived requirements must we validate with our   |
|           |     customer(s)?                                          |
|           |                                                           |
|           | -   Have we considered what security our system needs?    |
+-----------+-----------------------------------------------------------+
| **System  | -   How does this ITS system fit in with other ITS        |
| Archi     |     systems in the region?                                |
| tecture** |                                                           |
|           | -   What are the components of the ITS (e.g., TMC, ATIS)? |
|           |                                                           |
|           | -   Is there an existing regional or project architecture |
|           |     based on the National ITS Architecture?               |
+-----------+-----------------------------------------------------------+

## Characteristics of Good Functional Requirements

Kar and Bailey[^6] state that good functional requirements should be:

-   Necessary

-   Concise (*minimal*, *understandable)*

-   Attainable (*achievable* *or feasible*)

-   Complete (*standalone)*

-   Consistent

-   Unambiguous

-   Verifiable

Let's look at each of these characteristics and see why each is
important.

> **Necessary.** If a requirement isn't *necessary*, you'd have to
> question why it was included. What we mean here is that the function
> required is an essential part of the system. If it isn't there, some
> important element of the system is missing and other capabilities of
> the system can't compensate for its absence. While this may seem like
> a trivial characteristic, the reason it's included as first on the
> list is a tendency of system users to make something a requirement
> that really isn't *necessary.* A classic example of an unnecessary
> requirement was one stated by the marketing department of an
> automobile manufacturer that was significantly upgrading its luxury
> car model. When the engineering department was gathering requirements
> for the new luxury model, the marketing department said that one
> requirement was that the company's logo had to appear in gold trim on
> the steering wheel of the new car. When the engineers asked what
> function the gold trim logo served, the marketing department replied,
> "All other cars in this market have it!" Until the marketing
> department could demonstrate (which they never did) that the car
> wouldn't sell without this feature, the requirement was deemed
> unnecessary and dropped.
>
> **Concise.** Functional requirements must use well-chosen words to
> state their meaning and intent. You should use as few words as
> necessary to describe the requirement, but your audience should
> readily understand what the requirement means. Any language that
> confuses the issue should be pared away so that the requirement is
> stated crisply. The requirements should also be easy to read. For best
> results, each requirement should be a single statement that states
> what must be done and only what must be done. This means that if the
> requirement statement is a compound sentence (e.g., "The system shall
> manage Dynamic Message Signs and Highway Advisory Radio messages."),
> it really contains multiple (in the example used, two) requirement
> statements and should be broken into two (or more) requirement
> statements. Comments, if any, should be kept apart from the
> requirements statement.
>
> A common practice in writing requirements statements is to mandate the
> use of the word "shall" to indicate a requirement. Thus, a system that
> imported weather data for use in a traffic management center might
> have a requirements statement such as the following:
>
> The system *shall* import the following weather products: weather
> forecasts, warning statements, local and national radar imagery,
> satellite imagery, and other graphic weather maps. ("Shall" in italics
> for emphasis.)
>
> Note that the requirement does not specify *where* the data comes
> from. That's because there are alternate sources for the different
> weather products and deciding where to get them from is a decision
> that doesn't have to be made when stating the *what* that needs to be
> done.

Requirements writers who follow the practice of using "shall" to denote
a requirements statement also use "should" and "will" to distinguish
between requirements and clarifications of the requirements. We'll
expand on this in Chapter 4.

> **Attainable.** This means that it should be possible to achieve the
> requirement; it must be feasible. One way to know whether a
> requirement is attainable is through experience. If you or someone on
> your team has implemented a system that met this requirement, you know
> that a solution exists and the requirement is attainable. If the
> requirement is one that's never been attained in practice before, you
> should carefully research its feasibility before you commit to it.
> Good systems engineering practices, such as trade-off studies and
> prototyping, help you determine what technology can do. This gives you
> a better chance of writing *attainable* functional requirements. The
> studies help you understand what's possible, given the state of
> technology and industry practice, and flush out requirements that may
> be beyond the state of the art. If the requirement is not
> *attainable*, don't include it as part of your system design.
>
> **Complete.** A requirement statement should stand on its own and not
> need further amplification to make it understandable. If you need to
> add clarifying language, the requirement statement is probably weak
> and you should re-work it. Examine all your requirement statements for
> this characteristic. Tightening up the language that states the
> requirement often helps meet several characteristics.
>
> **Consistent.** You achieve *consistency* in several ways. First, no
> requirement statement should contradict another. If you have multiple
> authors of a requirements document, with the authors having possibly
> conflicting points of view, you should carefully review your
> requirements to ensure you haven't fallen into the trap of conflicting
> requirements. Second, no requirement should duplicate another.
> Duplicate or overlapping requirements are troublesome when they are
> interpreted differently or when someone on your project team expends
> extra effort to satisfy a requirement that a different part of the
> project team is addressing. Third, make sure that you use the same
> term for the same item in all your requirements. Using different terms
> for the same item makes it appear that you have separate requirements
> when, in fact, you may have duplicate ones.
>
> **Unambiguous.** Each requirement should have one and only one
> interpretation. An excellent way to ensure that requirements are
> unambiguous is to hold a requirements walkthrough and have all parties
> review the requirements and agree on their meaning. It should become
> clear when the way you've stated the requirement is open to several
> interpretations. Oral agreement on the meaning of a requirement is not
> sufficient; the understanding that you reach on the meaning of each
> requirement during the walkthrough needs to be reflected in the
> requirements document.
>
> Large and complex ITS projects need very detailed requirements because
> there will be many people involved and adding detail should enhance
> the commonality of understanding. Adding detail is one way to reduce
> ambiguity. On smaller ITS projects, where there is more interaction
> between the developer and the customer stakeholders, you may not need
> as much detail to get and maintain agreement on the meaning of the
> requirements. Within the project team, everyone should agree on the
> level of detail needed in requirements and also agree on the
> interpretation of the requirements. Agreement on requirements
> interpretation comes through requirement review(s), where all parties
> discuss the requirements and ensure that each party has the same
> understanding of each requirement's meaning.
>
> **Verifiable.** This last characteristic may be the most critical one.
> You must be able to determine whether the requirement has been met
> once the system is implemented. You must verify the requirement by one
> of four methods: inspection, analysis, demonstration, or test.
> Usually, the method used is *test*. If the requirement is at all
> testable (and not all are), a test to verify its satisfaction must be
> part of the system acceptance test you conduct at the end of the
> implementation stage of the project.

Most authors who discuss how to write requirements recommend that you
avoid certain words when writing requirements. These include such
favorites as: "flexible," "fault tolerant," "high fidelity,"
"adaptable," "rapid or fast," "adequate," "user friendly," "support,"
"maximize," "minimize," "and/or," "etc.", and "may." These words are
considered either too general or too vague for use in requirements. When
you see them, they usually mean that one or more of the characteristics
cited above is missing.

## The Importance of Good Functional Requirements

So why are good functional requirements important? Why don't we just
rough out the requirements and fix things up later after we see how they
work out? Why do we care if the requirements are a little hazy or
ambiguous? The basic answer is "Cost!"

We're always concerned about getting the job done right, which some tend
to define as "on time and within budget."[^7] Historically, projects
involving large software components (which is what an ITS project can
be) have had large cost and schedule overruns. Many studies have been
done, looking for the causes of overruns on software projects. While
there are many factors that can cause these overruns, one common theme
that studies have found is that the later you find a mistake, the more
it costs to fix it.

One study[^8] that analyzed software development projects came up with
the cost inflation factors shown in Table 2. If you consider the cost to
fix an error in the requirements phase to be \$1, the cost of fixing the
same error gets rapidly higher in later phases. The reason is simple,
much the same way that the cost to fix an error in the design of a road
is cheaper during the architectural phase than after you've poured
concrete and laid asphalt. When you're in the requirements stage, you're
still dealing with an abstract thing. The further along the system
development life cycle you go, the more concrete that thing becomes. As
it becomes more concrete, it affects more parts of the system (e.g.,
documentation, training, software, possibly even hardware).

Table 2

Relative Cost to Fix an Error By Project Phases [^9]

  ----------------------------------- -----------------------------------
  **Phase in which error found**      **Cost relative to Requirements
                                      Phase**

  Requirements                        1

  Design                              3-6

  Coding                              10

  Development testing                 15-40

  Acceptance testing                  30-70

  Operation                           40-1000
  ----------------------------------- -----------------------------------

No matter how important good functional requirements are, you may not
get them right the first time through. If not, don't worry. There is
nothing wrong with iterating through the process until you get the
requirements right. If you generate a set of requirements and further
analysis finds some problems with the requirements, use all the tools at
your disposal to resolve those problems and improve the requirements. As
Table 2 shows, every dollar you spend getting the requirements right
early means many dollars you won't have to spend later, fixing problems.

We'll discuss how to analyze and write functional requirements later in
this document. For now, let's look at the relationship between
functional requirements and the National ITS Architecture.

## 

# 3. Functional Requirements and the National ITS Architecture

**How Does the National ITS Architecture Relate to Functional
Requirements**

The National ITS Program seeks to improve ground transportation in the
United States through use of information technology-based systems that
deliver timely information and control transit and traffic flow. It
encourages the use of interconnected information-based systems that
collect appropriate information and that help users make decisions,
control signals and other devices, and interact with external systems
such as banking systems.

The National ITS Program defined a high-level architecture, the National
ITS Architecture, as a tool to provide:

-   A *framework* for identifying and specifying all necessary
    components and interconnections, including standards

-   A common *vocabulary* to facilitate internal and external
    communications with colleagues and others involved in transportation
    planning

-   *Guidance* in developing regional or other ITS architectures,
    including the flexibility to tailor solutions to individual
    needs[^10]

The National ITS Architecture focuses on delivery of services to users.
These User Services derive from User Needs. In turn, the User Services
spawned a set of User Service Requirements. The User Service
Requirements became the high-level requirements that the National ITS
Architecture had to satisfy. The progression from User Needs to the
National ITS Architecture is illustrated in Figure 2.

Although they are not part of the National ITS Architecture, the User
Services that the National ITS Architecture addresses are documented on
material distributed by the National ITS Architecture Team. Version 3.0
of the CD-ROM distribution of the National ITS Architecture
documentation contains a section discussing User Services. This section
describes 31 User Services, grouped into 7 User Service Bundles. Table 3
below depicts the current User Service Bundles and corresponding User
Services. Although this table lists the current breakdown of User
Service Bundles and corresponding User Services, it is valid only as of
Version 3.0 of the National ITS Architecture. Later versions of the
National ITS Architecture may add User Services and/or User Service
Bundles.

User Services are further broken down into User Service Requirements. A
partial breakdown of a single User Service, Incident Management, is
shown in Table 4. The numbers shown in the column for Process
Specifications refer to the number of the Process Specification[^11] in
the National ITS Architecture documentation. To view a Process
Specification within the National ITS Architecture documentation, click
on the "Logical Architecture" button on the main menu of either the
National ITS Architecture CD-ROM or the National ITS Architecture web
site ([www.iteris.com/itsarch](http://www.odetics.com/itsarch)). Then
click on any of the "pspec" entries from the list on the page presented.
This will take you to a page that is a hyperlinked view of the Process
Specification you selected.

The National ITS Architecture documentation correlates User Service
Requirements with Process Specifications (pspecs). Pspecs are associated
with Subsystems and may be associated with Equipment Packages. Equipment
Packages reference Architecture Flows and Market Packages. Pspecs,
Subsystems, Equipment Packages, Architecture Flows, and Market Packages
are all examples that illustrate how you can deploy ITS
capabilities.![](media/image4.wmf){width="4.645833333333333in"
height="3.0194444444444444in"}

Consider the pspec (1.3.2.1) that addresses User Service Requirements
1.7.1.1.2 and 1.7.1.1.3 (see Table 4) for descriptions). Figure 3 shows
a textual description of the pspec, taken from Version 3.0 of the
National ITS Architecture CD-ROM. In the figure, you can see a section
entitled "Functional Requirements" that provides more detail on the
functional requirements that this process specification addresses. These
are examples of how the National ITS Architecture can help you develop
functional requirements.

Figure 2

Progression from User Needs to National ITS Architecture

Table 3

User Service Bundles and User Services

+-----------------------------+----------------------------------------+
| **User Service Bundle**     | **User Services**                      |
+=============================+========================================+
| Travel and Traffic          | 1.  Pre-trip Travel Information        |
| Management                  |                                        |
|                             | 2.  En-route Driver Information        |
|                             |                                        |
|                             | 3.  Route Guidance                     |
|                             |                                        |
|                             | 4.  Ride Matching and Reservation      |
|                             |                                        |
|                             | 5.  Traveler Services Information      |
|                             |                                        |
|                             | 6.  Traffic Control                    |
|                             |                                        |
|                             | 7.  Incident Management                |
|                             |                                        |
|                             | 8.  Travel Demand Management           |
|                             |                                        |
|                             | 9.  Emissions Testing and Mitigation   |
|                             |                                        |
|                             | 10. Highway-rail Intersection          |
+-----------------------------+----------------------------------------+
| Public Transportation       | 1.  Public Transportation Management   |
| Management                  |                                        |
|                             | 2.  En-route Transit Information       |
|                             |                                        |
|                             | 3.  Personalized Public Transit        |
|                             |                                        |
|                             | 4.  Public Travel Security             |
+-----------------------------+----------------------------------------+
| Electronic Payment          | 1.  Electronic Payment Services        |
+-----------------------------+----------------------------------------+
| Commercial Vehicle          | 1.  Commercial Vehicle Electronic      |
| Operations                  |     Clearance                          |
|                             |                                        |
|                             | 2.  Automated Roadside Safety          |
|                             |     Inspection                         |
|                             |                                        |
|                             | 3.  On-board Safety Monitoring         |
|                             |                                        |
|                             | 4.  Commercial Vehicle Administrative  |
|                             |     Processes                          |
|                             |                                        |
|                             | 5.  Hazardous Material Incident        |
|                             |     Response                           |
|                             |                                        |
|                             | 6.  Commercial Fleet Management        |
+-----------------------------+----------------------------------------+
| Emergency Management        | 1.  Emergency Notification and         |
|                             |     Personal Security                  |
|                             |                                        |
|                             | 2.  Emergency Vehicle Management       |
+-----------------------------+----------------------------------------+
| Advanced Vehicle Safety     | 1.  Longitudinal Collision Avoidance   |
| Systems                     |                                        |
|                             | 2.  Lateral Collision Avoidance        |
|                             |                                        |
|                             | 3.  Intersection Collision Avoidance   |
|                             |                                        |
|                             | 4.  Vision Enhancement for Crash       |
|                             |     Avoidance                          |
|                             |                                        |
|                             | 5.  Safety Readiness                   |
|                             |                                        |
|                             | 6.  Pre-crash Restraint Deployment     |
|                             |                                        |
|                             | 7.  Automated Vehicle Operation        |
+-----------------------------+----------------------------------------+
| Information Management      | 1.  Archived Data Function             |
+-----------------------------+----------------------------------------+

The *User Service Requirements* that the National ITS Architecture must
satisfy are functional expressions of *what* an ITS system that provides
this User Service should do. One can consider User Service Requirements
as the highest level of *functional requirements* in an ITS system. User
Service Requirements give a global picture of what overall needs should
be met by ITS systems, but exactly which User Service Requirements are
satisfied varies for each ITS system actually implemented. Since the
National ITS Architecture is merely a guide to designing Intelligent
Transportation Systems, each regional and local implementation is unique
and requires its own separate set of functional requirements.[^12]

Table 4

###### User Service Requirements in Incident Management User Service

(Partial)

+------+------------------------------------------+--------------------+
| **N  | **User Service Requirement Description** | **Associated       |
| o.** |                                          | Process            |
|      |                                          | Specifications     |
|      |                                          | (Pspecs)**         |
+======+==========================================+====================+
| 1    | Incident Management shall provide an     | 1.1.1.1, 1.1.1.3,  |
| .7.1 | incident identification function to      | 1.1.2.2, 1.1.2.7,  |
|      | identify incidents.                      | 1.3.1.1, 1.3.1.3,  |
|      |                                          | 1.3.2.1, 1.3.2.2,  |
|      |                                          | 1.3.2.3, 1.3.3,    |
|      |                                          | 1.3.4.1, 1.3.4.3,  |
|      |                                          | 1.3.4.5, 4.4.1.8,  |
|      |                                          | 6.1.1, 6.5.1       |
+------+------------------------------------------+--------------------+
| 1.7  | The incident identification function     | 1.1.1.1, 1.1.1.3,  |
| .1.1 | shall include the capability to identify | 1.1.2.2, 1.1.2.7,  |
|      | predicted incidents.                     | 1.3.2.1, 1.3.2.2,  |
|      |                                          | 1.3.4.3, 1.3.4.5,  |
|      |                                          | 6.1.1, 6.5.1       |
+------+------------------------------------------+--------------------+
| 1    | The incident identification function     | 1.1.1.1, 1.1.1.3,  |
| .7.1 | shall use information from the following | 1.1.2.2, 1.1.2.7,  |
| .1.1 | types of sources, where available, to    | 1.3.2.2            |
|      | identify predicted incidents:            |                    |
|      |                                          | 1.1.1.3, 1.3.2.2   |
|      | a.  Traffic flow sensors.                |                    |
|      |                                          | 1.3.2.2, 1.3.4.5   |
|      | b.  Environmental sensors.               |                    |
|      |                                          | 1.3.2.2, 1.3.4.3   |
|      | c.  Public safety sources.               |                    |
|      |                                          | 1.3.2.2, 6.5.1     |
|      | d.  Media sources.                       |                    |
|      |                                          | 1.3.2.2, 6.1.1     |
|      | e.  Weather information sources.         |                    |
|      |                                          | 1.1.1.3, 1.3.2.2,  |
|      | f.  Transportation providers.            | 6.1.1              |
|      |                                          |                    |
|      | g.  Sponsors of special events.          | 1.3.2.2            |
|      |                                          |                    |
|      | h.  Hazardous condition prediction       |                    |
|      |     algorithms.                          |                    |
+------+------------------------------------------+--------------------+
| 1    | The incident identification function     | 1.3.2.1            |
| .7.1 | shall determine at least the following   |                    |
| .1.2 | characteristics of each predicted        | 1.3.2.1            |
|      | incident:                                |                    |
|      |                                          | 1.3.2.1            |
|      | a.  Type.                                |                    |
|      |                                          | 1.3.2.1            |
|      | b.  Extent.                              |                    |
|      |                                          | 1.3.2.1            |
|      | c.  Severity.                            |                    |
|      |                                          |                    |
|      | d.  Location.                            |                    |
|      |                                          |                    |
|      | e.  Expected duration.                   |                    |
+------+------------------------------------------+--------------------+
| 1    | The incident identification function     | 1.3.2.1            |
| .7.1 | shall determine the expected traffic     |                    |
| .1.3 | flow impact of each predicted incident.  |                    |
+------+------------------------------------------+--------------------+

But let's step back for a moment and look at the National ITS
Architecture from a broader perspective.

## How the National ITS Architecture Influences Functional Requirements[^13]

The National ITS Architecture is not, in itself, a complete set of
functional requirements. But there are three principal ways in which it
can assist in planning and implementing ITS systems:

+-----------------------------------------------------------------------+
| ######### Pspec 1.3.2.2\-\--Review and Classify Possible Incidents    |
+-----------------------------------------------------------------------+
| Overview: This process shall review input data about possible         |
| incidents and provide verification of the incident. The process shall |
| have the capability of using algorithms to automatically identify and |
| verify an incident. The process shall have the capability to classify |
| an incident as current incident or a planned event and shall be load  |
| the data into the store of possible incidents as either current       |
| incidents or planned events. The process shall report any incidents   |
| that it is unable to verify or classify to the traffic operations     |
| personnel for manual verification and classification. The process     |
| shall allow the traffic operations personnel to request all possible  |
| incidents and carry out the verification and classification process   |
| manually.                                                             |
|                                                                       |
| This PSpec is associated with the Traffic Management Subsystem.       |
|                                                                       |
| This PSpec is associated with the following Equipment Packages: TMC   |
| Incident Detection, TMC Road Weather Monitoring.                      |
|                                                                       |
| Data Flows:                                                           |
|                                                                       |
| > current_incidents_new_data\--Out                                    |
| >                                                                     |
| > incident_data_update\--Out                                          |
| >                                                                     |
| > incident_details\--In                                               |
| >                                                                     |
| > incident_details_request\--Out                                      |
| >                                                                     |
| > operations_incident_data_updates\--In                               |
| >                                                                     |
| > planned_event_data\--Out                                            |
| >                                                                     |
| > planned_events\--Out                                                |
| >                                                                     |
| > planned_events_new_data\--Out                                       |
| >                                                                     |
| > possible_incident_data_update\--In                                  |
| >                                                                     |
| > possible_incidents\--In                                             |
| >                                                                     |
| > possible_incidents_data_output\--Out                                |
| >                                                                     |
| > request_possible_incidents_data\--In                                |
| >                                                                     |
| > tcm_incident_confirmation\--Out                                     |
| >                                                                     |
| > tcm_request_incident_change\--Out                                   |
| >                                                                     |
| > tep_event_confirmation\--Out                                        |
|                                                                       |
| Functional Requirements: This process shall: (a) run when any of the  |
| unsolicited data flows described above is received; (b) be capable of |
| automatically determining which possible incidents can be converted   |
| into real incidents (i.e. are not false alarms) and further           |
| classifying the real incidents as planned events or current           |
| incidents; (c) the incident classification process shall use the      |
| level of confidence data attached to each set of possible incident    |
| data; (d) if the classification cannot be done automatically with a   |
| locally determined level of confidence, send the data to the Traffic  |
| Operations Personnel via the 'possible_incidents_data_output' output  |
| data flow, for manual classification; (e) where necessary, format the |
| data for a possible incident into the standard form, adding in any    |
| missing fields if necessary, and adding in the traffic impact data    |
| field; (f) when a possible incident has been classified: load it into |
| the planned events or current incidents data stores, delete it from   |
| the store of possible incidents, send data flows to activate the      |
| process responsible for reviewing either planned events or current    |
| incidents, and send the appropriate message to other parts of the     |
| ITS; (g) if necessary, update the data retrieved from the store of    |
| possible_incidents for a possible incident sent in from the           |
| Construction and Maintenance terminator so that it takes place at     |
| time(s) that cause the minimum impact to traffic and return the       |
| amended data to the Construction and Maintenance terminator via the   |
| 'tcm-request_incident_change' output data flow; (h) new data read     |
| from the store of possible_incidents which is found to complement     |
| data already in the planned events or current incidents data stores,  |
| will be merged, with any additional data items in the new data loaded |
| into the appropriate data store for the incident that is already      |
| recorded.                                                             |
+-----------------------------------------------------------------------+

Figure 3

Sample (Partial) Process Specification Description

-   As a model

-   As a guide

-   As a boundary

Let's review how it helps us in these areas.

### The National ITS Architecture as a Model

The National ITS Architecture is a well thought-out framework for ITS
systems. The National ITS Architecture contains the definition of the
processes that implement the functions satisfying User Services, and the
physical partitioning of the functions, and serves as a *model* for
implementation at regional and local levels. That is, transportation
planners can formulate regional and local architectures along the same
lines as the National ITS Architecture, with suitable adjustments for
local variations. For example, some rural areas may have no local
transit systems, and so a regional ITS architecture for such an area can
omit the transit components of the National ITS Architecture.

As an ITS project manager, you can use the subsystems and market
packages in the National ITS Architecture as models for how you allocate
functions to the subsystems that you need to build. The National ITS
Architecture also helps you visualize what interfaces you'll need to
construct to tie different capabilities together.

### The National ITS Architecture as a Guide

The National ITS Architecture is itself expressed in terms of functional
requirements. There are *User Needs* that must be serviced, and
*functions* that will service them. For example, there is a user need to
have information relevant to trip planning: route, road conditions, and
unusual activity. There are functions to satisfy this need, and they
include providing route guidance based on traffic management
information. The National ITS Architecture breaks these functions down
to levels that can be more easily implemented. So in this sense, the
National ITS Architecture is a *guide* to writing good functional
requirements for transportation systems. Planners and project
implementers can review relevant pieces of the National ITS Architecture
to see how the requirements were expressed functionally, and use similar
language and strategy in their own applications.

### The National ITS Architecture as a Boundary

Just as the National ITS Architecture describes what's in ITS systems,
it also establishes, by what it doesn't contain, what *isn't* part of
the ITS systems boundary. This helps control the scope of an ITS project
and keep extraneous requirements from creeping in. Boundaries also help
define interface points for a system. If you are conducting an ITS
project that *adds* capability where intelligent transportation systems
already exist, the boundaries drawn by the National ITS Architecture
point out where and what interfaces you should plan.

At the same time, it's important to note that there may well be ITS
requirements that are not part of the User Service Requirements and not
characterized by the National ITS Architecture. You should add these
additional ITS requirements to your system requirements document. Adding
these requirements may force an extension or expansion of your regional
or project architecture. The template provided by the National ITS
Architecture allows regions and projects to define extended boundaries
for their more localized architectures.

## Why Aren't User Service Requirements Sufficient as Functional Requirements?

If you've gone to a course on the National ITS Architecture, you've
heard many reasons why using the National ITS Architecture can help you
in defining and developing ITS systems. One reason is that the User
Service Requirements defined for the National ITS Architecture are
high-level functional requirements. However, by themselves, User Service
Requirements aren't complete functional requirements.

First, User Service Requirements are specified at a high level, the most
abstract level. When you build a system, you're making very explicit
technology and performance specifications. Functional requirements do
not exist as independent entities, nor can we derive them without
thinking about potential designs. The following example makes this
clear:

When a town planner decides that the ferry that transports people across
a bay in his city no longer has sufficient capacity to carry all the
traffic, \[and building a larger one is not feasible\], he is likely to
ask a civil engineer to design a bridge. The town planner does not ask
the civil engineer, "Say, I've got people on opposite sides of this bay,
and I need some way to transport them across. Got any ideas?" Before the
town planner contacts an engineer, he has already decided what he wants
built. He knows a standard type of artifact---a bridge---and he knows
who is capable of designing one specifically for the traffic across the
bay. The fact that orderly engineering starts with some type of design
pattern has an important implication for requirements:

Rigorous research and definition of requirements is possible only in
relation to a specific design pattern.[^14]

Once we know that we're going to build a bridge, we can ask pertinent
questions such as, "What type of traffic will the bridge carry?" "How
many lanes does it need?" "Where will it connect to existing roads?"
When these questions are answered, we can write functional requirements.

Second, User Service Requirements don't necessarily address or satisfy
local requirements and conditions. Since the National ITS Architecture
is high-level and abstract, it doesn't address:

-   Location-specific laws and regulations

-   Expectations and desires of the local population

-   Availability of funds for deployment

-   Nature of existing transportation infrastructure

-   Ability to interconnect with other systems in the locality

-   Technology choices, hardware and software choices, and performance
    characteristics, such as lane width, throughput, capacity, schedule,
    and similar items

You may not control any of the above factors, but your project, to be
successful, must take them into account. Thus you need to reflect local
conditions in the functional requirements for your system. User Service
Requirements at the National ITS Architecture level are clearly not
sufficient for this purpose.

Third, you'll need to derive additional requirements to ensure smooth
integration of your system with other local systems. You'll probably
also need to derive additional requirements just to satisfy specific
needs and accommodate limitations in the systems and conditions with
which you'll interact in building your new system. Deriving additional
requirements from existing ones or developing more detailed requirements
as you move through the system development process is a natural order of
events. We'll cover that in more detail later in this document.

## National versus Regional ITS Architectures

As a last point before going on to the next section, let's make sure we
understand the role of regional ITS architectures as well. A
well-defined regional ITS architecture results in a high-level tailoring
of the National ITS Architecture for your region. Once you construct
such a well-defined regional ITS architecture, it provides a blueprint
for ITS in your region. It will require updating over time, as changes
to regional needs occur, and may require updating when the National ITS
Architecture changes. If there is a regional ITS architecture for your
area, it reflects the needs of your immediate stakeholders. You need to
conform to your regional ITS architecture to ensure that you effectively
address the needs of your stakeholders.

Now let's look at how we develop functional requirements that are
specific to the system we need to build and how we manage functional
requirements to help engineer the project in the most effective way.

# 4. Analyzing and Writing ITS Functional Requirements

## Where Do You Start?

As the King said to the White Rabbit: "Begin at the beginning, and go on
till you come to the end; then stop."[^15] That's not bad advice. Let's
start with some basic systems engineering homework. We have to figure
out what need the system is going to meet, how the system will operate
once it's been implemented, what it's going to do, and how the system
fits in with other systems once it's in operation. That's the basic
homework. We'll start with what's known as a *needs analysis*.

**Needs Analysis**

In a *needs analysis*, we ask certain basic questions:

-   What is less than satisfactory with the current situation and how
    does the proposed project fill that need?

-   Do all stakeholders have a common understanding of the project's
    goals and objectives?

-   How do we resolve conflicting stakeholder goals?

In conducting a needs analysis, there may be some preliminary steps that
you have to take to put your effort into the proper context. Someone
else may have done some of this basic homework and provided you with the
results. If they haven't, it may be necessary for you to perform the
work in these two steps. They are:

-   Understand the local institutional environment

-   Determine stakeholders

Let's look at what's involved in these two steps.

### (1) Understanding the Local Institutional Environment

There are a number of local factors that could affect the requirements
on ITS projects. These include:

-   *The political situation*.\
    What can realistically be done, in light of who wields political
    power and what power they have? Who will make decisions about ITS
    projects to be implemented? How will these decisions be made?

-   *Receptivity to innovation and new ways of doing business*.\
    Will local operators and citizens fight some or all proposed changes
    to the transportation system? Will they be willing to use new
    devices in their vehicles and access new information systems? How
    will uncertainty in this area affect the success of ITS projects?

-   *Willingness to invest in ITS solutions*.\
    How much can be committed to new transportation systems in light of
    other community priorities?

-   *Local laws and regulations*.\
    In addition to national laws and regulations, such as environmental
    statutes, are there local laws or regulations that will affect ITS
    projects and the functional requirements to implement them?

Let's look at how these affect functional requirements for ITS projects.

> **The Political Situation.** The political situation in your area
> creates the context in which you implement your ITS project. The
> people who created the political situation are usually key
> stakeholders in the project and have needs that you must meet. You'll
> need to determine what those needs are and how much support they're
> willing to give to meet their needs. In addition, some of the people
> involved in creating the political situation you face may be involved
> in the decision-making process that affects your ITS project. You may
> report to some of them or have to make presentations to them as part
> of keeping the project on track.
>
> You shouldn't view the political situation as a negative constraining
> your project. It may be, but it could also be a very positive factor
> that drives the project to success. If key political players are
> behind you, you'll probably have more chance of making things turn out
> well. Even if you don't have the political support when you start, you
> always have the opportunity, through good project management and
> astute expectation management, to win people over as supporters.
>
> **Receptivity to Innovation and New Ways of Doing Business.** There
> are some who are receptive to innovation and change (the "early
> adopters") and some who resist change all the way. Most people fall in
> the middle; they're not looking for change, but they'll accept it if
> it's presented to them in a positive way. Part of your job is to help
> the middle group, which is usually the largest one, accept the change
> by pointing out the positive aspects of what's new, by promising only
> what you can deliver, and by keeping your promises. When you meet
> resistance, you must look for the reasons \-- keeping personalities
> out of the picture. It could well be that the reason for the
> resistance is that some key requirement isn't being met for a group
> that considers themselves stakeholders. While you may not be able to
> address that requirement in your implementation (due to lack of money,
> lack of time, or lack of resources), you should acknowledge the
> requirement and help the group understand how and when it could be
> met. If the requirement is one that you can or will satisfy, you need
> to educate the group and overcome their resistance to the new system.
>
> **Willingness to Invest in ITS Solutions.** Since our assumption is
> that you're developing requirements because you have an ITS project
> underway, there has to be some willingness to invest in an ITS
> solution. However, it may be necessary for you to provide information
> on the return on investment that your project offers the community it
> serves. If your project doesn't yield greater benefits than it costs,
> it's hard to justify why it was funded in the first place. Education
> may be necessary.
>
> **Local Laws and Regulations.** Laws and regulations are frequently
> the source of many key requirements. They set conditions that the
> system must meet and boundaries within which the system must operate.
> In some cases, they may be the reason that the system project was
> undertaken.

### (2) Determining Stakeholders

Let's clarify the concept of "stakeholder." A *stakeholder* is anyone
who has an interest in the success of the ITS project (a "stake" as it
were). *Stakeholders* include users, politicians, and the public. Each
*stakeholder* has some idea of what he or she wants the system to do.
Part of our job is to determine what *needs* stakeholders want
satisfied.

Not all stakeholders are going to have their needs satisfied. You can't
please everyone. (Sometimes, you can't even please anyone.) But you
should determine who the people and organizations are that you must
satisfy. Since the stakeholders are the local users of the ITS services
and others who are influenced by any ITS projects, their particular
needs ultimately determine which ITS components you implement, and how
available funds get apportioned to improve local transportation and
satisfy the local constituency. Therefore, you must determine the
following:

-   *Potential users of all ITS services under consideration*.\
    Who are all the potential users, and what are their primary
    concerns? Commuting time? Notification of adverse road conditions?

-   *Others who may be affected directly or indirectly by ITS services,
    but who will not be users*.\
    Will they support ITS efforts? Will any of them be adversely
    affected by ITS solutions?

-   *Persons or organizations with a strong material interest in success
    or failure of ITS solutions.\
    *Are there persons or organizations who profit or lose (money,
    influence, business) if ITS solutions are implemented? Does this
    need to be taken into account in writing requirements?

The stakeholders are sources of requirements and they are also ones who
validate or verify the requirements. You need to bring them into the
picture early on to make sure you consider their needs and to determine
how you're going to involve them in the process of reviewing and
verifying the requirements that you define. In particular, you need to
identify the principal stakeholders, the ones for whom this system is
key to doing their job. Although there may be many stakeholders for a
system, the principal stakeholders are the ones who ultimately must
accept the system once it's implemented. These are the key people you
have to satisfy.

**Concept of Operations**

After you decide whose needs you're trying to meet and what priority to
set in meeting stakeholder goals, you develop your idea of how the
system you're going to build will operate. This view of the system in
operation is called a *Concept of Operations*. To develop a *concept of
operations*, you have to answer several basic questions, among which
are:

-   Do we know who all the users will be?

-   Do we know how the users will interact with the proposed system?

-   Is how we plan to operate the system consistent with all systems
    with which it must interact?

-   Have we coordinated with all other agencies affected by this system?

Let's look at that last question for a minute. Coordination is important
because our system fits into the overall system environment within our
region. It's not going to operate in isolation; it has to fit in with
and interact with other agencies' systems. If we focus only on what
we're going to do and don't include all others with whom we must
interact in our thinking and planning, we're liable to overlook some key
requirements for our system.

Also, we should consider other agencies so that we don't duplicate
functionality that already exists. It's hard enough to build a good
system on time and on budget without making extra work for ourselves. We
want to do all the things that are necessary in our system, but we want
to avoid doing anything that isn't necessary.

As part of the process of identifying needs and developing a concept of
what our system will do, we're going to develop the requirements for our
system. To refine the requirements, we'll conduct basic fact-gathering.

### Fact-Gathering

You base your functional requirements on facts, not "wish lists" or
misperceptions about what's needed to do a job. You should always ask
questions like: "What's the reason for this requirement?" "What critical
purpose does it meet?" "What happens if we don't provide this
capability?" In particular, you should gather facts to let you establish
measures that let you quantify requirements. It's better to have a
requirement that says you have to support "10,000 devices" than one that
says you have to be "able to expand the system to accommodate future
growth." The first requirement is one you can verify; the second you
can't.

In gathering facts, ask such basic questions as:

-   What functions will this project perform?

-   Have all functions been defined in detail?

-   Are all interfaces identified and defined?

-   Are system requirements given in quantifiable terms?

-   Have requirements been reviewed with stakeholders, and is there
    understanding and agreement?

-   Have we determined measures of system reliability, maintainability,
    and availability?

-   What derived requirements must be validated with stakeholders?

    We want to emphasize a couple of key points. First, reviewing
    requirements with stakeholders (at least those who are our primary
    stakeholders) is critical. We have to get everyone in agreement on
    what's meant by the language of each requirement. We'll give an
    example later on of requirements interpretation to illustrate why
    this is important. It's not just the initial set of requirements
    that we have to verify with stakeholders and get agreement on. It's
    also the *derived* requirements. Derived requirements are ones that
    you find out you must meet as the result of having *primary*
    requirements. Let's look at an example.

Let's say that our customer is the Metropolis Traffic Department with
video data acquired through roadway intersection cameras. We find out
that the Metropolis Traffic Department wants its roadway maintenance
department to share that video data. By sharing the data, the Metropolis
Traffic Department believes that maintenance crews can better determine
which roads are suffering from potholes and which are beginning to show
signs of potholing. The roadway maintenance department could then send
crews out early enough either to keep potholes from occurring or to
repair existing potholes before they become a serious road hazard and
congestion point. Our *primary* requirement is to share traffic video
data with the roadway maintenance department.

However, the question that we have to answer is, in what manner should
we present the video data to the roadway department? Should it be
full-motion video or frames from the video taken at specific times
during the day to show road conditions? If the need is for full-motion
video, does it need to be real-time or can the day be taped and the tape
sent to the roadway maintenance department for study? The answer to
those specific questions determines how heavy the load is on the data
network that we have to build into our system. We have to document the
requirements we derive as part of the requirements package for our
system. And, before we finalize our requirements, we have to review
these derived requirements with our customer and ensure that our
interpretation, which led to a specific statement of the derived
requirements, is correct.

Second, we have to make sure that we have measurable values for key
requirements and that those measures are reasonable. One of the
characteristics of a good requirement, as listed in the last chapter, is
that it be verifiable. One way to verify a requirement is to have a
value that we want it to achieve. For example, in an availability
requirement, we might determine that we want key components of the
system to be available 99.9% of the time. That means, in a system that
operates 24 hours a day 7 days a week, that the system could have no
more than ***8.75 hours of downtime in a year*** or about ***10 minutes
of downtime per week***. That kind of availability is frequently called
"three 9s" availability. There's a cost associated with this type of
availability requirement, so we should know that it's a real
requirement, not something on someone's "wish list."

The concept of operations and the requirements you define begin to
determine your *system architecture*. There are some more basic
questions that you address while defining your system architecture.
These include:

-   How does this system integrate with other ITS systems in the region?

-   Is it consistent with the National ITS architecture and any
    applicable regional architecture?

-   What are its principal components?

Your system is part of a family of systems in your region. It should
interact effectively with each of these other systems. The functional
requirements you derive from the manner of interaction are the interface
requirements that we discussed earlier. How your system meshes with the
National ITS Architecture is important from the point of view of what
services you're going to provide and how they interface with other
systems in your region.

The information you gather during this "basic homework" forms the basis
of all functional requirements, since it deals with what the system must
do, and the context in which it must operate. Once this information is
in hand, you begin to write your requirements document.

### Writing a Requirements Document

Once you've done your initial fact-finding, you can begin writing the
requirements document for your ITS project. Written requirements are
important. (To paraphrase a Hollywood mogul, "Oral requirements aren't
worth the paper they're written on.") A written requirements document
captures what you're trying to achieve with this system in a tangible
form, one that others can read and review and interpret. And the fact
that others can read and review it is important, because you want to
express the requirements in language that meets the criteria for good
requirements that we defined in an earlier section. You'll know when
you've achieved good requirements. It's when everybody that's a
stakeholder (including you and your team) agree on what the requirements
mean.

But you're probably not going to get the requirements right the first
time you write them down. That would reflect a lack of serious thinking
about quantifiable requirements and cost-benefit tradeoffs. The first
time through, you'll mostly write down what you were told and won't have
done much in the way of analysis on whether the requirements are valid,
reasonable, feasible, or any of the other characteristics that we want
in good requirements. But you'll at least have them written down. That's
the first step in analyzing them.

### Analyzing the Requirements

Begin by determining, based on user needs, the exact function that the
system must perform. This is often the most difficult step. Describe the
function in ordinary language, and then work to make the language more
precise and less ambiguous and less subject to differing
interpretations. For example, if the user need is to have a vehicle's
identification tag scanned so that the vehicle does not have to stop at
a toll collection booth, the first cut at a functional requirement
statement might be:

> "Read the vehicle identification as it passes through the toll booth."

Though the above statement isn't bad, it's not specific enough about the
function to be carried out. There are still some open questions, such
as: Is the reading to be automatic or manual?; What vehicle
identification is involved? Your analysis should focus on resolving
ambiguities like those. You'll want to explore the reason for performing
the function. Is it because you're trying to collect tolls? Is it
because you're trying to track the location of the vehicle? Are you
trying to keep track of a vehicle transporting hazardous materials?

You may want to write the requirement in a hierarchical fashion. This
allows you to start with the general requirement and then get more
specific as you go down the hierarchy. For example, the requirement
might look like the following:

1.  The toll collection system shall automatically read the vehicle tag
    as the vehicle passes through the toll booth.

    1.  The toll collection system shall determine, through data in the
        vehicle tag, the point at which the vehicle entered the highway
        system, as a means of calculating the toll amount.

    2.  The toll collection system shall compute the toll amount.

    3.  The toll collection system shall interface with the existing
        financial system to record the toll collected against the
        driver's account.

    4.  The toll collection system shall reduce the on-tag account
        balance by the amount of fare collected.

You might also want to consider what the system does if there is no
vehicle tag, if the driver's account balance is low enough that it might
soon be overdrawn, or if the driver's account has insufficient funds to
cover the toll amount. These are all conditions that the system should
handle. The stakeholder who stated the original requirements may not
have explicitly stated them, but they're ones that you should easily
derive as requirements through your analysis process.

Next, determine the quantitative performance requirements for the
system. Quantitative performance requirements guide the system's
implementers in constructing it properly. Make sure that the
quantitative performance requirements do not push the state of the art,
and are internally consistent. And make sure that you express the
quantitative performance requirements clearly. Consider the following
examples:

> "The system shall read identification tags for all vehicles traveling
> at 30 mph or less."
>
> "The system shall read identification tags under all lighting
> conditions."
>
> "The system shall locate the tag at any height above the ground
> between 2 feet 6 inches and 9 feet 6 inches."

Of the three requirement statements above, two are reasonable
quantitative performance requirements statements. If you didn't spot the
ringer we slipped in, it's the second one.

Why is that one not a good requirement? Well, it says "all lighting
conditions." Think that's testable? Maybe, but not in any realistic
manner. The word "all" means "every possible." "Every possible" lighting
condition covers a very broad spectrum of lighting conditions, and you'd
have to test them all to verify that the system met the requirement.
It's better to specify a realistic range of lighting conditions, e.g.,
in measurable terms, like lumens, so that you limit the conditions for
which you must test.

As part of the analysis, particularly in getting at the feasibility of
the requirements, you may need to perform some studies or conduct some
experiments. In particular, when you're looking at user interface
requirements, you may want to build prototypes of the user interface and
try them out with the users of the system. Prototypes are excellent
tools for getting at user interface requirements because they let the
users experience how they'll interact with the system.

After you complete a cut at analyzing requirements, you should revise
the requirements document and review it with your stakeholders.

### Reviewing Requirements with Stakeholders.

This is a critical step in the process of getting requirements done
properly. It's important to make sure that both you and your
stakeholders interpret all requirements the same way. If you don't have
the same interpretation, they'll have expectations that you won't meet
and you'll waste time implementing the wrong capabilities.

The best way (time-consuming though it may be) to review requirements is
to conduct what's known as a "requirements walkthrough." In a
*requirements walkthrough*, you get the representatives of the major
stakeholders together with your project team and you go through each
requirement one-by-one, telling them how you interpret that requirement
and asking them if they interpret it the same way. Be very clear on what
your interpretation is; this is a "make or break" step in the process.

You may be surprised at how easy it is to have different (sometimes even
contradictory) interpretations of requirement statements. Remember that
words have multiple meanings and not everyone is using the same meaning
when they use a word. A famous example of how even a simple phrase can
have multiple meanings is the phrase: "Time flies." When an instructor
asked a group of students at a course on software acquisition to give
their interpretation of that phrase, the students gave the following
interpretations:

-   Time (a measure of duration) moves very rapidly

-   People who work for *Time* magazine take airplanes, as opposed to
    other means of transportation ("*Time* flies; *Newsweek* takes the
    train")

-   It's an order to a baseball coach to measure the duration that a fly
    ball spends in the air

-   It's a description of someone throwing a clock across the room

-   Someone is being asked to hold a stop watch on houseflies as they
    buzz around a room

Now, it's true that the students were trying to be creative in their
interpretation of the phrase, but the example does demonstrate how
phrases can have different meanings to different people.

The payback on a requirements walkthrough however can be very high. One
ITS project manager who invested the time and energy in conducting one
for his ITS project said it was the best system development tool he'd
ever found. Remember also what Table 2 showed. The cost of fixing a
mistake that you could have fixed in the requirements analysis stage
goes up rapidly with each subsequent stage through which you pass. By
the time you get to the implementation stage, fixing an error in a key
capability will cost you 40 to 1000 times as much as it would have back
in the requirements analysis stage.

## Functional Requirements Writing Styles

In addition to writing clearly, you should maintain a consistent style
when writing functional requirements (actually, in all requirements
documents). The following are some rules of thumb for requirements
writing:

-   Use the word "shall" to indicate requirements.

-   Use imperatives to condense requirements.

-   Where appropriate, use explicit subjects for clarity. For example,
    "The sensor shall emit a beep after reading the strip", rather then
    "Emit a beep after reading the strip".

-   Try to avoid constant, repetitive use of phrases such as "the
    system" as the subject of functional requirements. However, don't
    eliminate these phrases if doing so can lead to ambiguity in the
    requirement.

-   Avoid drift between declarative and imperative sentences.

You should also distinguish between functional requirements and comments
that give the rationale for the capability sought, or information about
how the capability is expected to be used in practice. Consider the
following example:[^16]

The system shall maintain a Transaction Log file which tracks each
person making a data base change, the types of records changed, the
number of changed record occurrences, and the day and time of the user's
record-changing session. This information will allow the system
administrator to monitor whether expected data maintenance activities
are in fact taking place. It will also help to track the effect of
unauthorized access to the system by individuals who have managed to
evade the Contract Tracking System's access controls.

In this example, there is a functional requirement to maintain a
Transaction Log, and two comments, the first regarding use of the log to
monitor activity, and the second regarding use of the log to control
damage after system penetration. Because the requirements statement runs
all three together in the same paragraph, it is difficult to extract the
requirement and establish its boundaries.

To separate requirements from comments (which are often quite helpful to
system implementers), you should use one of the following four
methods:[^17]

-   Label all requirements with a unique number. Visually separate all
    comments from the labeled text containing the requirements.

-   Use "shall" for functional requirements, and "will" for comments
    regarding use of the functions or capacity being specified. This
    approach is often used for military requirements (cf. MIL-STD-490A).

-   Use imperative sentences for functional requirements, and reserve
    declarative sentences for comments.

-   Use special language and/or format for requirements, and regular
    text for comments.

As an example of how the last method might work, let's take the
requirements statement above and re-cast it:

The system shall maintain a Transaction Log file which tracks each
person making a data base change, the types of records changed, the
number of changed record occurrences, and the day and time of the user's
record-changing session. ***This information will allow the system
administrator to monitor whether expected data maintenance activities
are in fact taking place. It will also help to track the effect of
unauthorized access to the system by individuals who have managed to
evade the Contract Tracking System's access controls.***

What we've done in the above example is use two different fonts to
separate the requirement statement itself from the explanatory comments.
In addition, we used italics and bolding to make the explanatory
comments stand out.

Let's take some examples of requirements and see what's good and bad
about them.

## Examples of Good and Bad Functional Requirements

## The following examples are not all transportation examples. But they are taken from actual requirements documents that someone wrote. In some cases, the language has been modified to protect the guilty.

*Example:* "Design a transportation device."

*Comment:* This is a classic, almost hilarious, example of an ambiguous
requirement.[^18] When given to a group of designers, results ranged
from \$10 devices to \$15,000,000,000 devices! Clearly, the designers
must be given a better idea of what you would like to have! That is, the
requirements must make clear to them what problem is to be solved.

*Example*: "The system shall deal with motorist requests for routing
information efficiently."

*Comment*: This statement is too vague and cannot be tested because of
the words 'deal with' and 'efficiently'. It is not clear what, exactly,
is being asked for, nor how to determine if the requirement is being
satisfied and therefore how to design to meet it. A better version is:

"The system shall process motorist requests for routing information and
supply the requested information within 1 second for 99% of requests
under specified load conditions."

*Example*: "The system shall facilitate emergency response equipment
reaching its destination quickly."

*Comment*: There is not enough information here to design a system or to
determine if it satisfies the intent of the requirement. Words such as
'facilitate' and 'quickly' should be avoided. A statement that makes the
goal clear is needed:

"The system shall receive requests for priority routing of emergency
response equipment, determine the optimal (i.e., shortest time to
destination) routing path, and communicate necessary information to
traffic signaling devices within 5 seconds."

*Example*: Switched Voice Service (SVS) shall provide calling
capabilities between WITS2001 Service Delivery Points (SDPs) as well as
from any WITS2001 SDP to an Interexchange Carrier (IXC), Local Exchange
Carrier (LEC), or Competitive Local Exchange Carrier (CLEC)
Point-of-Presence (POP). The contractor shall support the following
types of central-office-based Switched Voice Services:

1.  WITS2001 lines, including analog and ISDN Basic Rate Interface (BRI)
    lines, but no trunks. *By definition, WITS2001 lines are directly
    connected to a Government-owned serving office via a Type A or a
    Type A Alternate access arrangement. Type B access arrangements do
    not apply because they are connected to a serving office provided by
    the contractor. Currently, GSA provides WITS line service to
    customers that require at least 25 pairs of copper distribution
    cable. GSA Consolidated Centrex lines serve smaller customers.*

2.  Centrex-like lines, including analog and ISDN BRI lines. *By
    definition, Centrex-like lines are directly connected to a serving
    office that is part of the WITS2001 network but is owned or leased
    by the contractor. Centrex-like lines are provided by Type B access
    arrangements.*

3.  WITS2001 access trunks, including analog, T1, T3, and ISDN Primary
    Rate Interface (PRI) trunks. *WITS2001 access trunks will not be
    provided via Type A access arrangements because GSA does not have
    the right to use the associated distribution cable.*

*Comment*: This is a good functional requirements statement in a
communications context. It says clearly what is to be done in the first
sentence, and then gives detailed performance specifications or comments
(shown in italics) in the following numbered sentences. Where needed,
explanatory information is provided to aid in the understanding of the
requirement. Implementation details are not specified (e.g., use coaxial
cable or fiber optic cable, or use Lucent or Nortel switches).

We've given you an idea of how to go about writing and analyzing
requirements and provided examples to show good from bad requirements
statements. Let's look at how you use requirements on an ITS project.

# 5. Using Functional Requirements on an ITS Project

## How Functional Requirements Affect the Implementation Process

Functional requirements form the basis of good systems development,
whether you do the work in-house or contract it out. They give
implementers the information they need to find cost-effective,
high-performance solutions to user needs. Let's explore the relationship
of functional requirements to system development and/or procurement in
more detail.

**Functional Requirements as the Basis for the System to be Built**

Since functional requirements tell system developers and implementers
what the system is supposed to do, in concise and precise form when
properly written, they, together with the system architecture, form the
basis for system implementation. This includes the following activities:

-   *Determining whether to build or buy system components*. It's always
    better to buy an existing system that meets your requirements than
    to build one from scratch. If you can buy an existing system that
    meets your requirements, you benefit from work done by others and by
    the fact that other people have found and fixed many problems that
    the system had when first implemented. But buying a system
    presupposes several things:

```{=html}
<!-- -->
```
-   A system that meets your needs exists

-   You can afford that system

-   Buying the system doesn't constrain you from being able to add new,
    needed capabilities in the future

Buying's not a perfect answer, nor should you undertake it without
thoroughly considering all the consequences this decision will have.
Building a system also has many consequences, many of which entail
serious risk.

> "Buying," in an ITS context, involves one of two options. The first is
> acquiring a commercial off-the-shelf (COTS) system. Although there are
> only a limited number of COTS systems available in the ITS arena, when
> the ones that exist meet your requirements, you should seriously
> consider them. The systems don't need to meet [all]{.underline} of
> your requirements, as long as there's some flexibility for modifying
> the systems to add the capabilities that they lack and you need. If
> there are competing systems (the best situation, from a procurement or
> contracting office's point of view), you use your requirements to
> determine which competing system best meets them. Although the
> technical match of requirements isn't the only criterion to use in
> selecting a system, it identifies what's missing and gives you a way
> to estimate the overall cost of acquiring it (purchase price + cost to
> enhance + cost to maintain the system [and]{.underline} its
> enhancements). The second is to acquire the ITS system from some other
> government entity. Once again, the system has to match your
> requirements, even if the match isn't perfect. This option, which
> usually involves an intra-government agreement, may not involve money
> changing hands; there's usually some *quid pro quo* that makes all
> parties happy. This option lets you "partner" with the other
> government entity to create an enhanced system that may benefit both
> of you. In terms of maximizing government investment, it's an
> attractive option.
>
> However, if there's no system, whether a COTS product or a
> government-furnished option, that meets your requirements, you still
> have the option to build. Then your requirements form the basis for
> your preliminary and detailed design. They provide your implementation
> team with the guidance necessary to build a quality system.

-   *Interfacing subsystems or components*. When you build a system, you
    typically connect individual components together to form subsystems
    and then interconnect the subsystems to form the final system. Each
    component and subsystem carries out certain functions necessary for
    overall system operation. By allocating functional requirements to
    the component and subsystem levels, it is easier to ensure that the
    interconnected components are designed properly and the subsystem
    meets its goals. The process of allocating requirements to
    components or subsystems is something you do during the preliminary
    design of your system.

> The National ITS Architecture illustrates how to do this by relating
> subsystems, market packages, and equipment packages to deliver user
> services. This is shown in Figure 4.

-   *Performance testing of subsystems, and systems*. This is critical,
    because you need to know if everything is working properly and, if
    not, where the problem lies. With functional requirements available
    for each subsystem and system, you can develop tests that examine if
    each meets its requirements. This lets you track progress and sign
    off on completed phases, components, and subsystems. It also lets
    you determine if vendors have delivered what they contracted to
    deliver. All deliverables must meet the performance and other
    criteria specified in the functional requirements document.

-   *Acceptance testing of final systems*. Acceptance testing certifies
    that a system is ready for action. Since you've plainly spelled out
    functional requirements for the system, you can devise a
    comprehensive acceptance test to verify that the system meets its
    requirements and performs as you expect it to. Without functional
    requirements, you would find it difficult to determine if what has
    been built performs satisfactorily in the real world.

> ![](media/image5.png){width="4.5in" height="3.442361111111111in"}

Figure 4

Relationship of Subsystems, Market Packages, and Equipment Packages

**Functional Requirements as Basis for Enhancements to Existing
Systems**

Modifying an existing system can pose significant problems to you as
project manager. A simple "enhancement" may actually require significant
system redesign and lead to unexpected costs. In addition, people tend
to modify existing systems by adding features rather than new
functions.[^19] This "spruces up" the old system, sometimes at great
cost, but it doesn't do anything new. So it's important to know what
you're getting into when someone proposes a new project that "enhances"
an existing system! Good functional requirements can help you deal with
this situation in four essential ways.

First, by comparing the functional requirements for the old system with
those of the new system, you can determine where (and whether) the
requirements have changed. This helps you better estimate just where, at
the subsystem and component levels, you'll have to make changes, how
much effort those changes will require, and whether the changes are
feasible, given the existing system's implementation and available time,
money, and other resources. For example, an enhancement to a
vehicle-based system may require doubling the data rate to the vehicle.
With existing hardware, this may not be possible, and may require an
entirely new wireless system to be installed on both vehicles and in the
central or the roadside facility.

Second, given functional requirements for the enhanced system, you can
lay out an effective *migration plan* to implement the desired
enhancements. A good migration plan minimizes disruptions (if you need
to continue system operation during the transition to a new system
capability). You can leave the parts of the system untouched that meet
existing requirements. It is only the new requirements that you need to
worry about. If you can encapsulate the new requirements into their own
subsystems, you can build (or buy) those subsystems and just integrate
the final products into what you have. This is simpler and more
effective than throwing everything out, including what works, and
replacing it with new, less mature components.

Third, functional requirements let you estimate more accurately the cost
of implementing the proposed enhancements. In fact, you should use
functional requirements to estimate all of the following elements of a
project plan:

-   Schedule

-   Resources

-   Cost

-   Risk

-   System size

Fourth, concentrating on functional requirements makes the substitution
of *features* for *functions* in existing systems more difficult. You
can legitimately ask, of every new requirement, "Is this a feature or a
real functional enhancement?" This separates the wheat from the chaff,
and concentrates effort on functions and their associated functional
requirements. Consider the following example:

...suppose you are building a new car, and the competitive analysis says
that the other cars in this class all have gold monograms on the
steering wheel. When the marketing people try to make "gold monogram on
steering wheel" into a requirement, ask, "What function does it serve?"
Most commonly, you'll get the reply, "It doesn't serve *any* function.
It's just there to match the competitor's."[^20]

Other telling replies might be, "It's just there because so-and-so
thought it would be nice," or "Everybody's doing it." Avoid these kinds
of justifications! In some cases, such "gold plating" may be a
[marketing]{.underline} requirement but it is not a *functional*
requirement.

**Functional Requirements as Basis for Contractor's Work Program**

If you contract with someone to build all or part of your system, you
have to let each contractor know what its responsibilities are. You can
use your functional requirements as the basis for generating all
Statements of Work (SOWs), and system specifications. You also should
base your evaluation of both technical and cost proposals on how a
contractor plans to meet the requirements you describe in any SOW.

## Requirements Tracing As a Testing and Quality Assurance Method

Experience has shown that the ability to trace requirements all the way
through a project, from inception to final implementation, is essential
to project success. Requirements tracing involves two major steps: 1)
tracing the requirements to the system or component whose functionality
satisfies it; and 2) tracing the tests you plan to conduct to the
requirement or function whose correctness and existence it examines. The
first step is necessary so that you know *where* a functional
requirement is satisfied. The second is necessary so that you know
*whether* a functional requirement is satisfied. The second step also
alerts you to any case where you've created a test that's unnecessary.

To trace requirements to where you've allocated them, set up a matrix
such as the one shown in Figure 5. There should be a check mark against
a subsystem for each requirement. If there isn't you've failed to
account for a requirement.

![](media/image6.wmf){width="5.493055555555555in" height="3.0in"}

Figure 5

Requirements Traceability Matrix

Requirements to Subsystems

You check to see whether you're testing for all requirements in the same
manner. You create a second matrix, such as the one shown in Figure 6.
The check marks show which tests verify which requirements. If there are
any columns with no check marks, then you aren't testing that functional
requirement. Either you will have to devise a new test or modify a
planned one to ensure that the requirement is tested. Similarly, if a
test doesn't verify any requirement (see test 12 in figure 6), it's
superfluous. Each matrix shown is an example of a *requirements
traceability matrix.*

Of course, this is no replacement for the usual systems engineering and
project management tools of Gantt charts, PERT charts, and work
breakdown structure for laying out a project plan and schedule. It's a
good systems engineering practice to tie your project plan and schedule
to the functional requirements as well. You'll show testing periods on
Gantt charts. Passing a group of tests successfully is a milestone at
the end of a testing period.

![](media/image7.wmf){width="5.316666666666666in"
height="4.669444444444444in"}

Figure 6

Requirements Traceability Matrix

Tests versus Requirements

# 6. Managing Functional Requirements

It's essential to manage functional requirements (and other requirements
as well), since some change is inevitable and you must deal it with
effectively. One author gives the following four reasons why you had
better be prepared with a good requirements change process:[^21]

-   Because (project) scope creep is lethal.

-   Because only fools believe that you can freeze requirements and then
    build to them, especially in politically sensitive areas such as
    transportation.

-   Because even though you all agree in November, you may not be
    speaking in January.

-   Because all of the parameters of a systems project can change
    overnight, and the ability to adapt in real time to changing
    priorities, changing budgets, changing schedules, and changing
    technologies is not only desirable but absolutely essential.

Well thought out functional requirements make the change process much
smoother, since the impact of any change on actual system *functions*
will be much clearer. Requirements expressed in terms of implementation
details greatly obscure the effects of changes.

We discuss how to manage requirements in this chapter, but first, let's
look at the major project bugaboo \-- *scope creep*.

## Scope Creep

One major problem you face on almost every project is "scope creep".
*Scope creep* is the gradual increase in the number of functions that
you have to implement in your system, along with changes in the
technical performance measurements for them. *Scope creep* typically
occurs when someone says, "Can't we just do a little more here?" or
"Would it hurt if we made a small change there?" or "Can we do it a
slightly different way?" Unfortunately, "small" changes can add up to
major architectural changes and, as a result, have major cost and
schedule impact. For this reason, scope creep is often lethal to a
project. Freezing functional requirements is a well-intentioned, but
misguided method for avoiding *scope creep*. Freezing functional
requirements is intended to force everyone to stick to the functional
requirements originally agreed upon. This allows you to avoid having to
negotiate and argue about requirement changes throughout the
implementation process. However, the problem with "freezing" functional
requirements is that **[it just doesn't work]{.underline}!** It's an
impractical solution and no one has ever successfully frozen functional
requirements on a project and been able to deliver a satisfactory
product. (Well, maybe "never." Maybe somebody's been able to do it. If
you find that person, introduce us to him or her; we'd like to meet the
person who's been able to do what others have failed miserably at.)

So, if you can't freeze functional requirements and scope creep is
fatal, what do you do? The answer is: configuration management!

**Configuration Management**

The "configuration" in the term *configuration management* refers to the
set of items that make up a system. These items include documents,
hardware, software, procedures, and anything else that makes up the
description and embodiment of a system. *Configuration management* is
the process by which you control changes to this set of system items.
But before we can get to *configuration management*, we have to discuss
the concept of *baselining* a system.

**Establishing a System Baseline**

Systems can have many *baselines*. You establish a system *baseline*
when you reach a point where everyone agrees on what the system
description contains. The first time that occurs is when you first
establish your agreed-upon functional requirements for the system.
That's known as the *functional baseline*. At this point, you have a
requirements document written, reviewed, and accepted by everyone as
describing what the system should do. At this point, you declare the
existence of the *functional baseline* and you put the *functional
baseline* under *configuration management*. (We'll cover what that means
in a short while. Some of the common baselines that the literature[^22]
of *configuration management* describes include:

-   **Functional baseline:** The definition of the problem, the basis
    for agreements between buyer and seller, the description of the
    product that will be developed

-   **Allocated baseline:** The apportionment, to specific hardware and
    software entities, of the functions that must be performed

-   **Top-design baseline:** For each software entity, the overall
    scheme of meeting its requirements

-   **Detailed design baseline:** For each software entity, the
    description of how it will be built

-   **Product baseline:** The definition of each software entity at the
    time of formal test

-   **Operational baseline**: The definition of each software entity at
    any time during its service life

Although those descriptions of baselines concentrate on "software,"
they're just as valid at the system level.

It really doesn't matter how many baselines you create during a system
implementation project. However, you must create the first when you
first get an agreed-upon set of functional requirements. If you don't,
then configuration management won't work. The baselines change over
time, but you control how they change through configuration management.

A system baseline is a formal event and the contents of the system
baseline are frozen as of the time you establish the system baseline.
That doesn't mean that you can't change the system baseline; it means
that you only change the system baseline through one of two formal
processes:

-   System development

-   Change control

**System development** is what you do while you're moving the project
from one phase to another. After you've completed the requirements
analysis phase of a project, you move onto the system design phase.
During the system design phase, you'll allocate requirements to system
components, i.e., you'll decide in what part of the system you're going
to satisfy each requirement. During this process, you have a formal,
frozen baseline, but you're doing the work that allows you to establish
the next baseline, building on the first. If the first baseline were to
change during this process, it would have an effect on the work that
you're doing. Therefore, you want to avoid changing the existing
baseline if at all possible.

At the end of the system design phase, you'll conduct another review,
one that gets everyone to examine how you've decided to satisfy
requirements (i.e., in what part of the system they'll get handled) and
either to agree with your allocation of requirements to system
components or to decide as part of the group what allocation to accept.
The final acceptance of a design for the system creates a new baseline
and that baseline replaces the old one. Depending on the size and
complexity of your project. This new baseline incorporates the old one
and adds all new documents resulting from the design acceptance as well
as anything else that you include in the system baseline at this point.
Whatever the next phase is, you should have a formal review and baseline
establishment milestone at the end of it. Your project should contain a
series of review and baseline establishment milestones at the end of
every discrete phase of system development. At the very end of the
project, when you go into operation and maintenance of the system, the
final delivered version of the system, with all associated
documentation, programs, support infrastructure, and everything else
that makes the system what it is, becomes the operations and maintenance
baseline.

In a perfect world, we'd only go forward on a project, from one
milestone to the next, never having to review and perhaps modify the
work that we did in prior steps. Unfortunately, that's not the world of
software-based systems. So what do you do when something comes up that
means you have to re-think some or all of an existing baseline? The
answer is *configuration management or change control*.

**Change control** is what configuration management is all about. We
need to make a change to an established baseline, but we need to do it
in a manner that doesn't disrupt all of the work that we're doing in
whatever system development phase we're in. More than that, we need to
make sure that whatever change we make gets reflected in all of the
pieces of the system that it affects.

Let's say that you're building a Traveler Information System. When you
started your effort in 1998, you listed Microsoft® Windows 95™ as an
allowable operating system for the desktop and laptop computers that are
part of your system. However, now that you've reached the final stages
of implementing your system, Microsoft has ceased support for the
Windows 95™ product and you're concerned about continuing technical
support for this operating system version. You inventory your desktop
and laptop computers and find that about 20% of them still use Windows
95™, despite your organization's aggressive hardware upgrade policy,
which has resulted in newer computers with later operating systems
replacing older machines running Windows 95™. You want to remove
Windows 95™ from the list of allowable desktop and laptop operating
systems and replace it with Microsoft's Windows 2000™ as a standard,
since that's Microsoft's latest business‑oriented PC operating system.
Although many of your current desktop and laptop computers are
configured with Windows 2000™, it's not officially an allowable
operating system within your current configuration. The discussion of
allowable PC operating systems appears in many places in your
documentation and you also don't want to make a change without assessing
how long it will take, and what it will cost, to upgrade all computers
currently running Windows 95 to some later operating system, preferably
Windows 2000™. So what do you do?

That's what we mean by change control. Let's discuss how we do this by
explaining more about configuration management.

**Managing the Configuration**

Configuration management starts with a system baseline. Then it adds a
*change control board* or CCB. The CCB decides whether to allow a change
or not. It has absolute power over changes to system baselines. If the
CCB decides "yes," the baseline gets changed; if the CCB decides "no,"
no change occurs. You, as the project manager, normally chair the CCB.
You also decide who's going to be part of the CCB, so choose well; these
people are going to have significant impact on how your project
proceeds. Usually, if you have a contractor working on the project, the
contractor manager also sits on the CCB; this is because changes to
project baselines usually have an impact on the contractor's resources
and costs. If there is a user stakeholder whose stake in the project is
major, that stakeholder (or a representative) should sit on the CCB.
Don't make the CCB too large, however. If it all possible, keep
membership to 3-5 people, no more than 7. Groups larger than that are
less effective and can be hard to get together when you need them to
make decisions on potential changes to baselines.

There's a formal process that you go through when deciding to make a
change. The process consists of the following steps:

1.  [Someone proposes a change to the baseline]{.underline}. Anyone can
    propose a change to the baseline, but whoever proposes the change
    must state exactly what change is being proposed and why the change
    is needed. The easiest type of proposed change to understand is when
    someone detects an error in an item under configuration control.
    During operation of the system, for example, if a program fails,
    i.e., has an error condition occur, you'd propose a change to get
    the program fixed and a new, corrected version put into production
    use. In the development stages, it's less easy to know what can
    cause a change. But legislation could cause a change, for example.
    If there is now a legal requirement for the system to perform that
    wasn't in force before, that's a strong and legitimate reason for
    the change.

2.  [The impact of the change is assessed]{.underline}. When a change is
    proposed, someone has to evaluate it and determine how much impact
    implementing it will have on the project. Deciding whether to
    implement the change is the CCB's decision; however, someone other
    than the CCB usually assesses the change's impact. The people
    closest to the problem are the ones who should perform the
    assessment. This usually means the project team working on the
    subsystem or component for which the change is being proposed.

The assessment that this team performs has three major axes to consider:
value to the project, impact on project schedule, and impact on project
cost. Consider Figure 7, which tries to show the assessment graphically.
Let's assume that we assessed each axis on a simple scheme of rating the
values on each axis either "high," "medium," or "low." That means there
are 27 possible combinations. The ideal situation is a change that has a
high value, and low cost and schedule impacts. The worst-case scenario
is a change that has low value and high cost and schedule impacts. It's
unlikely that you'll have cases that are that clear cut. And there is
also the issue that you have to consider the cumulative impact of
proposed changes. Sometimes a lot of "small" changes can have a large
cumulative (negative) effect on project cost and schedule.

3.  [The analysts provide a recommendation to the CCB]{.underline}. The
    team that's asked to assess a proposed change isn't just asked to
    determine value, and cost and schedule impact. It's also asked to
    make a recommendation to the CCB on what action it should take. The
    CCB doesn't have to accept the recommendation, but it does give the
    CCB a context in which to make a decision.

> Possible actions that the analysts can recommend include: accept and
> implement the proposed change; reject the proposed change; defer the
> proposed change; defer the decision. The last recommendation is only
> made if the project team needs more time to complete its analysis. The
> CCB usually accepts that recommendation, but asks for a specific time
> when the project team will have its final recommendation ready.

4.  [The CCB makes its decision]{.underline}. After the CCB considers
    the analysts' recommendation and develops its own understanding of
    the implications of the change, it decides what it wants to do. A
    decision to accept the proposed change means that the project team
    has to modify the baseline. A decision to reject the proposed change
    still causes work, because the decision should be explained to the
    person or organization that proposed the change.

5.  [The decision is implemented]{.underline}. If the decision was to
    accept the proposed change, the project team has to go through the
    entire set of items that form the existing baseline and ensure that
    the accepted change is reflected correctly in all of them. This can
    be a lot of work, particularly if the change is a major one. And
    after the change is made, the change needs to be communicated to
    everyone on the project and everyone who has copies of
    configuration-controlled items related to the project. That's the
    value of configuration management \-- the fact that the change is
    made to all controlled items and then communicated to everyone that
    it affects. Of course, if the decision was not to accept the change,
    the only thing that needs to be done is to tell the proposer why it
    wasn't. That can have its own set of headaches.

Seem simple?

To some extent, it is. Configuration management isn't rocket science. It
[is]{.underline} hard work and that's a reason that it can be overlooked
on ITS projects. It may seem overly rigid and formalistic, but our
experience is that it is highly effective. If we haven't convinced you
to practice it on your project, that's OK. Experience is a good teacher.
It may be a painful teacher, but what you learn through experience you
usually retain for a long time. But it takes a while for the scars to
heal.

**7. Where to Go to Get More Help**

## Department of Transportation Resources

##### Electronic Document Library (EDL)

The Department of Transportation (DOT) maintains an ITS Electronic
Document Library (EDL) on its web site
([www.itsdocs.fhwa.dot.gov](http://www.itsdocs.fhwa.dot.gov/)). You can
search the site's electronic index to find examples of different types
of requirements-related documents. Two types are:

-   Requirements documents written for other projects, e.g., *ATIS and
    CVO Development Objectives and Performance Requirements*

-   Deployment guidance documents, e.g., *Developing Traffic Signal
    Control Systems Using the National ITS Architecture*

##### National ITS Architecture Web Site and CD-ROM

The National ITS Architecture is available on both a web site maintained
for DOT ([www.iteris.com/itsarch](http://www.odetics.com/itsarch)) and
on CD-ROM. Both sources provide you a searchable, hyperlinked version of
the National ITS Architecture documentation.

##### Turbo Architecture

There is an automated tool, known as *Turbo Architecture*, maintained by
McTrans at the University of Florida
([www-mctrans.ce.ufl.edu](../www-mctrans.ce.ufl.edu)). Turbo
Architecture is a high-level, interactive software program designed to
assist transportation planners and system integrators, in both the
public and private sectors, in developing regional and project
architectures using the National ITS Architecture as a starting point.
See the McTrans web site for additional information, including how to
acquire the product.

## Software Tools

# While there are a number of tools available to help with the process of determining requirements, such as brainstorming, decision trees, interviewing techniques, meetings, right-brain methods, technical reviews, context-free questions, and user satisfaction tests,[^23] there are no software tools available dedicated [solely]{.underline} to developing and managing requirements. Most software tools, such as Computer Aided Software Engineering (CASE) and Computer Aided Design (CAD) tools, are geared to the overall systems engineering process, rather than to the requirements development phase. However, many CASE tools can manage the development of requirements and requirements documents. You should use tools that, as a minimum, let you capture requirements electronically. In most cases, you actually write functional requirements with a word processing program, since you'll want to distribute the requirements document to all stakeholders, and everyone can read standard word processing document formats. If you plan to contract out some or all of the work, then you've have to send the document to prospective offerors.

We prefer not to recommend specific tools, as this might seem to be an
endorsement of them. However, you can find considerable information on
systems engineering tools at the International Council on Systems
Engineering (INCOSE) web site's tools database page. The location is
[www.incose.org/tools/](http://www.incose.org/tools/). The information
is organized by INCOSE project, as follows:

-   SE Tool Surveys

    -   Requirements Management Tools Survey (Updated May 2000)

    -   Systems Architecture Tools Survey

    -   Measurement Tools Survey (Updated June 2000)

    -   Vendors who have responded to previous surveys

-   SE Tool Databases

    -   Tools Database by Name (Updated February 2000)

    -   Tools Database by Vendor (Updated February 2000)

-   SE Tools by Taxonomy

    -   Tools Database by IMPIG Taxonomy

    -   Tools Database by EIA-632 Taxonomy

    -   Tools Database by IEEE-1220 Taxonomy

The INCOSE web site, because it is operated by an organization whose
purpose it is to disseminate systems engineering information, may
contain the most objective and complete list of systems engineering
tools available. However, note the dates (as of this writing) on which
the various "projects" were updated. Check this site to see how dated
the information is.

In addition, the book by Andriole, *Managing Systems Requirements:
Methods, Tools, and Cases,* contains an extensive list of tools for all
phases of systems analysis. However, the list is very dated and many
tools listed are either no longer available or the vendor has gone out
of business. This is one of the problems of providing a static list of
tools in a printed document, book, or report. After a short while, the
list becomes obsolete. Software engineering tool development is an area
of considerable development and work. Web sites usually contain more
up-to-date information. For example, use web sites such as cnet.com
([www.cnet.com](http://www.cnet.com/)) to find discussions of available
tools, along with recommendations from the site's owner on the tools.
Recognize, however, that any web site that offers recommendations is
only offering the opinions of the people making the recommendations.

# Appendix A Example Table of Contents for a Functional Requirements Document

The following table of contents for a functional requirements document
is taken from the functional requirements document for the
Gary-Chicago-Milwaukee Corridor Multi-modal Traveler Information Systems
Functional Requirements Document[^24]. It illustrates the type and
breadth of information that one should include in a good functional
requirements document. The document is used as an example because it
follows the guidance in IEEE Standard 1233:1998, *IEEE Guide for
Developing System Requirements Specifications*.

1.  Introduction

    1.  Project Overview

    2.  Purpose

    3.  Goals

    4.  Intended Audience

    5.  Document Organization

    6.  Terminology

    7.  Definitions, Acronyms, and Abbreviations

    8.  Related Documents and Working Papers

2.  Gateway Overview

    1.  Introduction

    2.  Objectives

    3.  National ITS Architecture

    4.  NTCIP

    5.  LRMS

    6.  Corridor Architecture

        1.  Phased Approach

        2.  Corridor Definition

        3.  Regional Hubs

        4.  Gateway

    7.  GCM Data Pipe

    8.  Data Providers

3.  System Requirements

    1.  Data Acquisition Subsystem

    2.  Data Validation and Fusion Subsystem

    3.  Data Access Subsystem

    4.  Data Distribution Subsystem

    5.  Monitoring Subsystem

    6.  Administrative Subsystem

    7.  Operator Interface

    8.  Cooperative Control Pass Through

    9.  Operation

    10. Backups

    11. Data Users

    12. GCM Corridor Object Model

    13. Data Types Supported

        1.  Detector Data

        2.  Travel Times

        3.  Incidents

        4.  Construction/Maintenance Events

        5.  VMS

        6.  Weather and Road Conditions

        7.  Traffic Signal Data

        8.  Ramp Meters

        9.  Transit Schedules and Transit Schedule Adherence

        10. Voice

        11. Video

        12. Airport Data

    14. Transfer Techniques Supported

    15. Location Referencing Requirements

4.  General Requirements

    1.  National Standards Compliance

    2.  Open Systems

    3.  Topology

    4.  Object Orientation

    5.  Flexibility

    6.  Scaleability

    7.  Adaptability

    8.  Security

    9.  Reliability

    10. Fault Detection and Scalability

    11. Performance

    12. Error Detection

    13. Privacy

    14. Support for Future Technologies

5.  Hardware Requirements

    1.  Performance

    2.  Reliability

    3.  Safety

    4.  Testing

    5.  Server Machines

    6.  System Components

    7.  Main Storage

    8.  Off-Line Storage

    9.  Local Area Network

    10. Printer

    11. Workstation Machines

    12. Large Screen Display System

    13. Operating Environment

    14. Power

    15. Startup/Shutdown

6.  Commercial Software

    1.  Overall Requirements

    2.  Operating System

    3.  Graphical User Interface (GUI)

    4.  Networking Support

    5.  Database

    6.  Relational Database Requirements

    7.  Object Oriented Database Requirements

    8.  Interprocess Communications

    9.  Web Server

    10. Pass Through

    11. Testing

7.  Gateway Developed Software

    1.  Implementation Language

    2.  Implementation Model

    3.  Software Engineering Requirements

    4.  Design Phase Requirements

    5.  Testing

8.  Web Interface

9.  Communications Requirements

    1.  Communications Functions

        1.  Video

        2.  Voice

        3.  Data

    2.  Gateway Requirements

        1.  Wide Area Network Requirements

        2.  Local Area Network Requirements

        3.  Internet Requirements

        4.  Internet Service Provider (ISP) Requirements

    3.  Illinois Regional Hub Requirements

        1.  Wide Area Network Requirements

        2.  Local Area Network Requirements

        3.  Internet Requirements

        4.  ISP Requirements

10. Illinois Regional Hub

11. ISP Server

# Appendix B Glossary of Terms

*Architecture*. Highest level structural and functional organization of
a system. Comprises subsystems and their interconnection. The National
ITS Architecture defines the functions that must be performed, the
Subsystems that provide these functions, and the information that must
be exchanged to support defined User Services.

*Boundary* Edge of a system, the point beyond which system functions are
not defined. Only interfaces with other systems are defined at the
system boundary.

*Derived Requirement* (1) A requirement that is further refined from a
primary source requirement. (2) A requirement that results from choosing
a specific implementation for a system element.[^25]

*Equipment Package* Building blocks of the Physical Architecture
subsystems in the National ITS Architecture. Equipment Packages group
like processes of a particular subsystem together into an
"implementable" package. The grouping also takes into account the user
services and the need to accommodate various levels of functionality.

*Function* One or more coordinated processes or operations designed to
achieve a particular goal.

*Functional Requirement*. Requirement for a system expressed in terms of
*what* the system is expected to do, without reference to *how* the
system will be designed or implemented.

*Interface* Connection of a system or process with the outside world or
with another internal system.

*Logical Architecture* Functions comprising the architecture, without
reference to their partitioning among platforms or subsystems.

*Market Package* Particular grouping of entities defined in the Physical
Architecture corresponding to specific transportation services.

*Physical Architecture* Functions comprising the architecture
partitioned among the platforms where they will be implemented. Physical
Architecture is comprised of transportation, communications, and
institutional layers.

*Primary Requirement* A requirement that comes from a primary source or
stakeholder, e.g., acquirer, user, customer, manufacturer, installer,
tester, maintainer. Also known as a Primary Source Requirement

*Primary Source Requirement* See *Primary Requirement*

*Process* A series of actions to bring about a desired result. May be
performed in hardware, software, or both.

*Program Requirements* Specify the process to be followed by the vendor,
and the various non-performance requirements and regulations with which
the vendor must comply. These include compliance with federal, state or
local laws; compliance with environmental and safety regulations;
administrative requirements such as security.

*Requirement* A function that must be performed by a system, together
with all quantitative measures pertaining to it.

*System* Interconnected set of components and subsystems, including
hardware and/or software, designed to implement a function or achieve a
goal.

*Systems Engineering* Discipline that uses orderly, consistent, and
systematic quantitative methods to ensure that systems are built to meet
all requirements.

*Technical Requirements* Specify the product, service, or system to be
delivered according to the contract. Technical requirements include
functional requirements, design constraints, and interface requirements

*User Needs* Describe what the user of the final system desires or
requires the system to do in order to provide a benefit, or correct a
current problem.

# Appendix C References

Andriole, Stephen J., *Managing Systems Requirements: Methods, Tools,
and Cases*, New York: McGraw Hill, 1996.

Carroll, Lewis (pseudonym of Charles L. Dodgson), *Alice's Adventures in
Wonderland*, Leicester, England: Gallery Press, 1988

DeLeuw, Cather & Company, in association with JHK Associates,
*Gary-Chicago-Milwaukee (GCM) ITS Priority Corridor Multi-Modal Traveler
Information System Gateway Functional Requirements*, Document #17250.02,
Issued November 17, 1997

Dunn, Robert and Richard Ullman, *Quality Assurance for Computer
Software*, New York: McGraw Hill, 1982

Gause, Donald, and Weinberg, Gerald, *Exploring Requirements, Quality
Before Design*, New York: Dorset House, 1989.

Graham, Ian, *Requirements Engineering and Rapid Development*, Harlow,
England: Addison Wesley Longman, 1998.

Institute for Electrical and Electronic Engineers, IEEE Std. 1233:1998,
*IEEE Guide for Developing System Requirements Specifications*, New
York: The Institute for Electrical and Electronics Engineers, 1998

*ITS Mission Definition* document, December, 1999.

Kar, Pradip, and Bailey, Michelle, "Characteristics of Good
Requirements", 6^th^ INCOSE Symposium.

Kovitz, Benjamin, *Practical Software Requirements*, Greenwich, CT:
Manning Publications, 1999.

Martin, Charles F., *User-Centered Requirements Analysis*, Englewood
Cliffs: Prentice‑Hall, 1988.

Martin, James N., *Systems Engineering Guidebook: A Process for
Developing Systems and Products*, Boca Raton, FL: CRC Press, 1997.

Mitretek Systems, *Building Quality Intelligent Transportation Systems
Through Systems Engineering*.

Mitretek Systems, *Understanding Software Development: A Primer for ITS
Public Sector Managers*.

Sommerville, Ian, and Sawyer, Pete, *Requirements Engineering, A Good
Practice Guide*, Chichester: Wiley & Sons, 1997.

The Project Management Forum, Wideman Comparative Glossary of Common
Project Management Terms, V. 2.0.
[www.pmforum.org/library/glossary/PMG_F03.htm](http://www.pmforum.org/library/glossary/PMG_F03.htm)

*Using the National ITS Architecture For Deployment*, course.

[^1]: ^ES-1^ *23 CFR Parts 655 and 940, Intelligent Transportation
    Systems Architecture and Standards*

[^2]: Identifying all "other" systems and all interfaces among those
    systems is frequently a much more difficult exercise than it seems.
    Project managers and contractors on ITS projects often find that
    they spend more time documenting the systems with which they
    interface and the interfaces with those systems than they had
    planned for.

[^3]: Martin, James N., *Systems Engineering Guidebook: A Process for
    Developing Systems and Products*, p. 18

[^4]: The Institute of Electrical and Electronics Engineers (IEEE) has a
    standard describing what should go into a system's Concept of
    Operations document: *IEEE Std. 1362-1998, IEEE Guide for
    Information Technology -- System Definition -- Concept of Operations
    (ConOps) Document*. We discuss the Concept of Operations document
    and this standard in a companion monograph, *Building Quality
    Intelligent Transportation Systems Through Systems Engineering*.

[^5]: Mitretek Systems, *Building Quality Intelligent Transportation
    Systems Through Systems Engineering*.

[^6]: Kar, Pradip, and Bailey, Michelle, "Characteristics of Good
    Requirements", 6^th^ INCOSE Symposium.

[^7]: "Right" ought to mean implementing a quality system that meets all
    user requirements. Getting it done "on time and within budget" is an
    artificial "success" if the systems is of poor quality and doesn't'
    satisfy user needs.

[^8]: Barry W. Boehm, *Software Engineering Economics*, Englewood
    Cliffs, NJ: Prentice Hall, 1981.

[^9]: Donald C. Gause, Gerald M. Weinberg, *Exploring Requirements:
    Quality Before Design*, New York: Dorset House, 1989, p. 17.

[^10]: Course on *Using the National ITS Architecture for Deployment*,
    p. 2-8.

[^11]: A Process Specification is defined (in the National ITS
    Architecture documentation) as "the textual definition of the most
    detailed processes identified in the Logical Architecture. The
    specification includes an overview, a set of functional
    requirements, and a complete set of inputs and outputs."

[^12]: The U.S. Department of Transportation (DOT) has published a rule,
    *23 CFR Parts 655 and 940, Intelligent Transportation Systems
    Architecture and Standards*, that defines conformance with the
    National ITS Architecture as requiring the development of a regional
    ITS architecture, i.e., a local implementation of the National ITS
    Architecture, within four years after a region's first ITS project
    advances to final design, with subsequent projects having to adhere
    to that regional ITS architecture. For more information, look in the
    architecture conformity section of the DOT's web site
    ([www.its.dot.gov](http://www.its.dot.gov/)).

[^13]: Course *Using the National ITS Architecture for Deployment*, p.
    7-39.

[^14]: Benjamin L. Kovitz, *Practical Software Requirements*, Greenwich,
    CT: Manning Publications, 1999, p. 23.

[^15]: Carroll, Lewis (pseudonym of Charles L. Dodgson), *Alice's
    Adventures in Wonderland*, p. 182

[^16]: Charles F. Martin, *User-Centered Requirements Analysis*,
    Englewood Cliffs: Prentice Hall, 1988, p. 92.

[^17]: Adapted from Martin, *op. cit.*, p. 92.

[^18]: Gause and Weinberg, p. 218ff.

[^19]: Donald C. Gause, Gerald M. Weinberg, *Exploring Requirements:
    Quality Before Design*, New York: Dorset House Publishing, 1989, p.
    264-265.

[^20]: Gause and Weinberg, p. 265.

[^21]: Stephen Andriole, *Managing Systems Requirements: Methods, Tools,
    and Cases*, New York: McGraw Hill, 1996, p. 45.

[^22]: Dunn, Robert and Richard Ullman, *Quality Assurance for Computer
    Software*, McGraw-Hill Book Company, New York: 1982, p. 134

[^23]: Gause & Weinberg, p. 105ff.

[^24]: DeLeuw, Cather & Company, in association with JHK Associates,
    *Gary-Chicago-Milwaukee (GCM) ITS Priority Corridor Multi-Modal
    Traveler Information System Gateway Functional Requirements*,
    Document #17250.02, Issued November 17, 1997

[^25]: Martin, James N., *Systems Engineering Guidebook: A Process for
    Developing Systems and Products*, p. 19