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

3.5.1 Requirements Development [System and Sub-system Level Requirements]



Requirements are the foundation for building Intelligent Transportation Systems [ITS]. They determine WHAT the system must do and drive the system development. Requirements are used to determine [verify] if the project team built the system correctly. The requirements development process identifies the activities needed to produce a set of complete and verifiable requirements.


Requirements development is a set of activities that will produce requirements for the system and sub-systems. The systems engineering standard [EIA 632] defines “requirement” as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” Requirements define the functions, performance, and environment of the system under development to a level that can be built:

Does the system do WHAT it is supposed to do? - These are Functional requirements.

How well does the system do its functions? - These are Performance requirements.

Under what conditions [e.g. environmental, reliability, and availability.], does the system have to work and meet its performance goals? – These are Environmental and Non-Functional requirements.

There are other types of enabling requirements that are also needed but often overlooked. They define other aspects of systems development that are needed [but do not show up] as part of the system. Some examples are: development, testing, support, deployment, production, training, and in some cases disposal. Primarily the Functional, Performance, Environmental, and Non – Functional Requirements are contained in the System and Sub-system requirements documents. The enabling requirements may also be in these documents but they mainly show up in the various plans [SEMP and project plan], statements of work for contracted work, and memorandums of understandings among participating stakeholders.


Shows the flow for Phase [2] Task 1, Requirements Development Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.



Concept of Operations documents the user needs, expectations, goals, and objectives. It describes the way the system is intended to operate from the user’s perspective.

Regional ITS Architecture defines the regional framework [environment] in which this project must operate. Major external interfaces, high level functional requirements, and stakeholders are identified.

Feasibility Study produces the conceptual high-level design and requirements which can be used as a starting point for the project.


Project Plan/SEMP contain various plans, such as the review plans, configuration management plans, and risk plans. [Control the requirements development].

Configuration management [CM] identifies the process to control changes to the requirements and manage the baseline documentation.

Risk management is used to monitor, control, and mitigate high risk requirements.


Technical reviews are used to identify defects, conflicts, missing, or unnecessary requirements. Then, the requirements review control gate [formal review] is used to approve the final set of requirements.

Stakeholder involvement is essential for validating the requirements. Are these the correct requirements?

Elicitation enables the discovery and understanding of the needed requirements.

A technical trade study is used to analyze and compare alternative requirements and their technical and cost impacts on the system.

Traceability of requirements to user needs & requirements, support documentation, and constraining policies [e.g., safety requirements & regional ITS architecture].


System and Sub-system Requirements Documents must be complete, verifiable, and validated. After formal review and approval by the system owner and stakeholders, they are put under configuration control.

Verification Plan [from the verification process] documents the plan to verify each system requirement.

Processes Activities:

Develop requirements

The first step is to develop requirements from the stakeholder needs and input products. Once requirements are documented, they are prioritized, de-conflicted, and validated with the stakeholders.

Write and document requirements

Characteristics of "good" system requirements are: they should be necessary, testable, clear, concise, technology-independent, feasible, and stand-alone. Requirements must be documented in order to establish the base to build upon [called a baseline], and for managing changes to the requirements.

Check completeness

A complete set of requirements defines all system functions that are needed to satisfy the stakeholder needs with their associated performance, environmental, and other non-functional requirements.

Analyze, refine, and decompose requirements

This process examines each requirement to see if it meets the characteristics of a good requirement [e.g., clear, unambiguous, and verifiable]. Each requirement will be decomposed into a more refined set of requirements that are allocated to sub-systems, and performance requirements are defined. Newly derived requirements are expected to emerge from this process, which continues until all requirements are defined and analyzed and the final project architecture is defined.

Validate requirements

Each requirement must be validated to ensure that these are the correct requirements. This will be done through stakeholder walkthroughs and tracing requirements to an associated need.

Manage requirements

Once the requirements have been accepted and a baseline is established by the stakeholders, changes to the requirements are controlled using a change management process.

Illustrates where the Requirements Development occurs in the Vee Development Model. The requirements are developed in the System Requirements, and High-Level Design (Project Architecture) Subsystem Requirements sections.

Where does the Requirements Development take place in the project timeline?

Is there a policy or standard that talks about Requirements?

The FHWA Final Rule requires that requirements be developed for ITS projects funded with the Highway Trust Fund, including the Mass Transit Account. The IEEE 1233 Guide for developing system requirements specifications provides a standard for developing requirements.

Which activities are critical for the System's owner to do?

  • Assist in gathering requirements and getting the correct stakeholders involved
  • Review requirements to make sure they are complete and address all of the needs
  • Participate in the requirements walkthrough. Ensure the correct requirements are being developed [validating the requirements]
  • Gain stakeholder approval and support for the requirements
  • Track the requirements development activities

How do I fit these activities to my project? [Tailoring]

In this activity, there are no shortcuts. Requirements development is a critical process for new systems. On small systems, the owner may be able to reduce the number of requirements documents by combining the system and sub-system requirements.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • Changes to requirements [high priority, cost, and risk] lead to increased cost and increased technical risk. The goal is to minimize changes to requirements after the baseline is established
  • An incomplete set of requirements leads to increased technical risk and increased cost. The goal is to track the number of requirements that have been fully defined, analyzed, and decomposed

On the project management side:

  • The number of completed requirements should match the schedule and work plan. The goal is that the completion rate of requirements should match, or exceed the plan prediction
  • The growth in the number of requirements after the baseline has been established often leads to "scope creep"

Checklist: Are all the bases covered?

check Were the requirements documented?
check Was a requirements walkthrough held to validate the requirements?
check Was each requirement checked to see that it met all of the following?
  - Necessary [trace to a user need]
  - Concise [minimal]
  - Feasible [attainable]
  - Testable [measurable]
  - Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
  - Unambiguous [Clear]
  - Complete [function fully defined]
check Was a verification case for each requirement developed? [test, demonstration, analysis, inspection]
check Was each user need fully addressed by one or more system requirement(s)?
check Is the requirement set complete? Have the following types of requirements been defined?
  - Functional
  - Performance
  - Enabling [training, operations & maintenance support, development, testing, production, deployment, disposal]
  - Data
  - Interface
  - Environmental
  - Non-functional [reliability, availability, safety, and security].
check Were attributes [quality factors] assigned to each requirement [Priority, risk, cost, owner, date, and verification method]? Verification methods could include demonstration, analysis, test, and inspection.
check Were the requirements reviewed and approved by the stakeholders and was a baseline [reference point for future decisions] established?
check During this process step, were periodic reviews performed? Were the reviews done in accordance with the review plan documented in the SEMP?

Are there any other recommendations that can help?

Caution.Requirements development activity

Give ample time to this activity. This is an area of high stakeholder involvement. This activity addresses risk early in the development cycle where the cost impacts are low; instead of later where the cost impacts are high.

Do not approve [Baseline] the requirements too early. Give ample time to develop a set of requirements that are complete and well written.

Once developed and approved, the requirements baseline will need to be managed using a change control process [See Chapter 3.7.3].

Changes [e.g. additions, changes or deletion of requirements] after the baseline has been established normally will mean a cost and/or schedule change. [Scope creep or loss of functionality]

Tools are essential in managing requirements on large ITS systems with hundreds of requirements. There are a number of tools that can help in the development of requirements. These tools manage the tracing of requirements, requirements attributes, and perform change management for requirements. For an extensive list of tools please see http://www.incose.org .

A closer look at attributes, baseline, and completeness of requirements:

Attributes are user-defined quality factors assigned to each requirement. Some of the more common attributes used are:

  • Author [Who requested it?]
  • Date [When was it requested?]
  • Owner [Who is responsible for completing it?]
  • Risk [Low, medium or high]
  • Cost [Low, medium or high]
  • Priority [How important is this requirement?]

Tip.These attributes can help track the technical and project performance. Attributes help in sorting and monitoring requirements. Requirements management tools have features that allow for managing these attributes along with the requirements.

Requirements Baseline [reference point] — Has the requirements document been formally approved by the system owner and stakeholders? If so, all future development and project decisions are based on the requirements baseline. New requirements that are added, and existing ones that are changed or deleted, would be controlled closely using a change management process identified in the Configuration Management Plan. Once changes have been approved by the stakeholders, a new baseline would be established.

Completeness of requirements ensures that all aspects of user needs are completely defined by a set of requirements. There is a trap in looking at functions as "stove-pipes" in isolation of other functions. This may cause problems when the functions are integrated together.

One way to mitigate this is to make sure that all functions are thoroughly understood and that the analysis of requirements through decomposition integrates all required functions.

Related Template Checklist  


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