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.4 Needs Assessment Template

Purpose of this Document

The Needs Assessment Document is a record of the stakeholder needs which motivate the development of the system. It is essential that these needs be well understood and agreed upon before system development begins. Corrections are far easier and less costly to make at this preliminary stage vs. development or deployment.

Often the needs are vague, ill formed, or unstated. Two stakeholders who are saying the same things may actually want something entirely different. The needs assessment process clarifies these needs. So this document is a record of what the stakeholders are actually looking for, in a clear and complete manner.

Generally, it is not possible to meet all of the needs within the time and budget available for the project. Often the stakeholders may have conflicting needs. For example, transit or emergency response may need signal preemption, which conflicts with traffic management’s need for smooth flow. This means that tradeoffs and prioritizations may need to be made to balance the needs that will be the focus of the system. The Needs Assessment Document will be a record of the process for selecting these key needs.

There are several purposes for the Needs Assessment Document.

  • Get and document stakeholder agreement on the needs that the system is to meet to ensure that the development starts off in the right direction, to avoid later redirection
  • Clearly describe the needs that the system will meet, as the first step toward defining system requirements
  • Document the process and results of stakeholder consensus, relative to conflicting needs
  • Demonstrate to the stakeholders that their individual views have been incorporated

Tailoring this Document to Your Project

Some systems are defined for a very specific and clear purpose and stakeholder, and the budget and schedule are adequate to meet that purpose. In that case, a short and simple Needs Assessment Document is sufficient, about a page or less. This will clearly state what the needs are and include an acknowledgement from the stakeholders that they concur.

More often, some sort of elicitation process is necessary to draw out the needs. There are many ways to do this [see 3.8.2], each with its own output that will be included in this document recording the process and its results. Similarly, prioritization and gap analysis results are included in this document as a justification for the key needs selected.

In general, the form and complexity of this document reflect the amount of elicitation and analysis that was undertaken to come up with the key needs.

Checklist: Critical Information

check Are all the stakeholders identified?
check Are the needs of each stakeholder clearly described?
check Are the process and results of each elicitation activity described?
check Have essential needs [those that must be in the system] been distinguished from secondary needs [wants]?
check Is the prioritization of the secondary needs, if done, fully and clearly justified and its process documented?
check Are the process and results of the gap analysis, if done, fully described?
check Is there documentation to show that the stakeholders validated and concur with the identified key needs?
check Are the key needs, constraints, and corresponding measures of effectiveness clearly and unambiguously described?




Title Page

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

  • NEEDS ASSESSMENT FOR THE [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 Purpose of Document

This section is a brief statement of the purpose of this document. It is, a description and rationale of the needs that the system will be built to meet. This is a vehicle for stakeholder feedback, and a justification for the key needs selected.

2.0 Overview

This section gives a brief overview of the system to be built, describes the stakeholders, and the expected role of each.

3.0 Referenced Documents

This optional section is a place to list any supporting documentation used and other resources that are thought useful in understanding the operations of the system.

4.0 Needs Elicitation

This is the description and discussion of all elicitation activities. The process used and the results are included, possibly backed up by specifics [e.g., records of interviews] included in the appendix.

5.0 Needs Description

This section is the heart of the document. It describes clearly and fully the needs expressed by the stakeholders as they stand after the elicitation and validation processes. The essential needs are highlighted, and distinguished from those that are “wants” that may be sacrificed for cost or for more critical needs. This section also includes all system constraints that are known at this point. In addition, as much as possible, the needs should have corresponding measures of effectiveness or measures of performance that provide metrics for how well, or whether, the need is met.

6.0 Needs Validation

This section describes the process and results of validating the collected needs with the stakeholders. Any changes that came out of this process should be incorporated into 5.0.

7.0 Gap Analysis

This optional section describes the current system, compares it with the needs, and identifies the most pressing gaps to fill, in terms of criticality of the need and the extent of the gap. This section is not needed if the needs in 5.0 are consistent with each other and with budget and schedule.

8.0 Cost Comparison

This optional section may be used if there are conflicting needs. This gives a rough order of magnitude life cycle cost estimate for each option. Alternatively, ease of implementation, or some other stand-in for cost, may be used. This section may also be used to document any analysis that was done to verify that the identified needs can be met within the budget.

9.0 Selection of Key Needs

This optional section is used if the needs must be prioritized. This refers back to 7.0 and 8.0 and documents the process and results of prioritizing the needs, and the rationale for the selection. It describes the selected key needs.

10.0 Validation of Key Needs

This optional section documents the final feedback of the stakeholders relative to the key needs described in 9.0. This is used if the needs must be prioritized. This section documents the stakeholders’ agreement that the system will focus on the identified key needs.

11.0 Appendix

The appendix is optional. This is a good place to put back-up material from the elicitation and analyses. The main sections should be succinct and full justification of the results is available here for those interested. It also may include a glossary or notes, if appropriate.


Related Task 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