U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
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:
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:
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
 |
Is there a definition of all the major system functions? |
|
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.] |
|
Are all terms, definitions, and acronyms defined? |
|
Are all supporting documents such as standards, concept of operations, and others referenced? |
|
Does each requirement have a link [traceability] to a higher level requirement of a user-specified need? |
|
Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent? |
|
Are all technology dependent requirements identified as constraints? |
|
Does each requirement have a method of verification defined? |
SYSTEM AND SUB-SYSTEM REQUIREMENTS TEMPLATE
IEEE Std 1233 Guide for developing System Requirements Specifications
| section |
contents |
|---|---|
Title Page |
The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:
|
1.0 Scope of System or Sub-system |
|
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 |
 |
 |
 |
