U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

8.4.6 Requirements Template

Purpose of This Document

This document describes what the system is to do [functional requirements], how well it is to perform [performance requirements], and under what conditions [non-functional and performance requirements]. This document does not define how the system is to be built. It pulls together requirements from a number of sources including but not limited to:

  • Concept of Operations and Scenarios
  • Elicitation process – previous studies, "Day in the Life" studies, interviews, and workshops
  • Constraints that are put onto a project, such as policies that will drive constraints on the system. [Example, the Agency policy is to use Oracle in ITS]

Intelligent Transportation System projects have a Requirements Specification at the system and sub-system levels.

This document sets the technical scope of the system to be built. It is the basis for verifying the system and sub-systems when delivered [via the Verification Plan].

Tailoring this Document to Your Project

Any ITS projects will need a set of requirements defining what is needed. The tailoring is in how extensive to document these requirements. One way to gauge how many requirements to write and/or how much detail to have in the requirements document is to start at the finish line. The following should be asked when starting at the top level of the system:

  • What are all the functions needed in order to satisfy the agency that the system is doing what it is expected to do?
  • How well does the system need to perform the required functions?
  • Under what conditions does the system need to operate?

Each of these tests will need a requirement. This is done for the system and the sub-systems. For simple systems there may only be 1 or 2 pages of requirements that can fully define what the system is to do. In more complex systems this could be 10 to 20 pages or more.

Other factors that drive the extent to which requirements need to be written are the amount of COTS products that are used. These off-the-shelf products have their own specifications. So, it may be sufficient to reference them after they have been reviewed to determine if the product will meet the agency’s intended need. For example, the traffic control systems that are on the market have sufficient documentation to cover the majority of functions that are required. The additional requirements would be for any modifications or enhancements needed.

Checklist: Critical Information

check Is there a definition of all the major system functions?
check With each function of the system, is there a set of requirements that describes: what the function does, who is assigned to do it, and under what conditions [e.g. environmental, reliability, and availability.]
check Are all terms, definitions, and acronyms defined?
check Are all supporting documents such as standards, concept of operations, and others referenced?
check Does each requirement have a link [traceability] to a higher level requirement of a user-specified need?
check Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent?
check Are all technology dependent requirements identified as constraints?
check Does each requirement have a method of verification defined?


IEEE Std 1233 Guide for developing System Requirements Specifications



Title Page

The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

  • SYSTEM REQUIREMENTS/SUB-SYSTEM REQUIREMENTS [insert name of project] AND [insert name of transportation agency]
  • Contract number
  • Date that the document was formally approved
  • The organization responsible for preparing the document
  • Internal document control number, if available
  • Revision version and date issued

1.0 Scope of System or Sub-system

  • Contains a full identification of the system
  • Provides a system overview and briefly states the purpose of the system
  • Describes the general nature of the system
  • Summarizes the history of system development, operation, and maintenance
  • Identifies the project stakeholders, acquirer, users, and support agencies
  • Identifies current and planned operating sites

2.0 Reference

Identifies all needed standards, policies, laws, concept of operations, concept exploration documents and other reference material that supports the requirements.

3.0 Requirements

Functional requirements [What the system shall do]

Performance requirements [How well the requirements should perform]

Interface requirements [Definition of the interfaces]

Data requirements [Data elements and definitions of the system]

Non-Functional requirements, such as reliability, safety, environmental [temperature]

Enabling requirements [Production, development, testing, training, support, deployment, and disposal]. This can be done through references to other documents or embedded in this requirements

Constraints – [e.g. Technology, design, tools, and/or standards]

4.0 Verification Methods

For each requirement, identify one of the following methods of verification:

Demonstration is a requirement that the system can demonstrate without external test equipment.

Test is a requirement that requires some external piece of test equipment. E.g. logic analyzer, and/or volt meter.

Analyze is a requirement that is met indirectly through a logical conclusion or mathematical analysis of a result. E.g. Algorithms for congestion: the designer may need to show that the requirement is met through the analysis of count and occupancy calculations in software or firmware.

Inspection is verification through a visual comparison. For example, quality of welding may be done through a visual comparison against an in-house standard.

5.0 Supporting Documentation

Catch-all for anything that may add to the understanding of the Requirements without going elsewhere [Reference section]

Examples: diagrams, analysis, key notes, memos, rationale, stakeholders contact list

6.0 Traceability Matrix

This is a table that traces the requirements in this document to the higher level requirements or if this is a top level requirements document, it should trace to the User Requirements or needs

7.0 Glossary

Terms, acronyms, definitions


Related Task Examples Checklist  


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000