Write well-formed requirements from the perspective of the system and not the system user that are concise and include data elements that are uniquely identifiable.

Lessons from the ICM Implementation Guide

February 2012
Nationwide,United States

Background (Show)

Lesson Learned

Having a good requirements development process is vital to defining the details of the system and communicating those details so that a physical system can be implemented. The System Requirements Specification (SyRS) document organizes and communicates the details of the system including information about the system functionality, internal and external interfaces, constraints, performance, reliability, maintainability, availability, safety, and security. The SyRS provides stakeholders with an opportunity to verify that details of the system have been captured adequately and the project is ready to move forward to software/hardware development and implementation (i.e., build and test). The software/hardware development and implementation teams will closely follow the SyRS to verify that the work they perform meets the stakeholder’s expectations.

The following lessons learned apply to developing requirements for an ICM program.
  • Define requirements ID organization. Defining the requirements ID organization and hierarchy is important for managing the requirements documentation and traceability to other needs or requirements. The relationships between parent, children, and sibling requirements should be well defined and understood to avoid confusion during document reviews. Make sure child requirements are related to the parent and make sure that parent requirements have at least two child requirements.
  • Keep requirements concise. Writing and reading requirements can be time consuming, so it is best to avoid using superfluous words and keep requirements concise.
  • Develop a table of action words with definitions. Each requirement includes an action word that helps to define what the requirement accomplishes (e.g., provide, publish, store, manage, etc.). Make sure that all action words are defined and that there are no conflicting meanings among action words.
  • Do not create compound requirements. Each requirement should accomplish one action. If a requirement is compound or references more than one action, consider creating two requirements.
  • Create a structured procedure for addressing requirement data flows. When dealing with a requirement that has one action with multiple primitive data flows (e.g., the system shall send user ID, user name, user address, etc.) consider using a lettered list (e.g., a) user ID, b) user name, c) user address, etc.). This allows each of the flows to be uniquely identifiable, which is important when the requirement and flows are tested.
  • Understand requirements terminology. Requirements terminology must be well understood by the requirements authors, especially the use of will, shall, should, and must (e.g., shall requires that an action be performed whereas should means the action is optional).
  • Avoid confusing terms. Confusing terms should be avoided or defined in the requirements document (e.g., productivity, real-time, peak period, continuously, bottleneck, support, etc.)
  • Write requirements from the perspective of the system. System requirements should be written from the perspective of the system focusing on what functions the system shall perform. Do not write system requirements from the user perspective as it is not the user that needs to be designed and built.
  • Partition requirements. User requirements, system requirements and design requirements should be organized in separate documents or sections of a document.
  • Do not include external system upgrades. Requirements related to external system upgrades should not be included with the system requirements. External system upgrade requirements should be included in a separate document or added to an appendix of the SyRS.
  • Focus requirements on what the system does. Make sure the system requirements focus on what the system does and not on the external systems and what they do.
  • Provide access to Interface Control Documents (ICDs). If ICDs are referenced in the SyRS, provide access to the documents.
  • Review user needs. It is a good idea to review needs prior to a requirements walkthrough or set aside a designated time to review them during the walkthrough.
  • Conduct a Preliminary Design Review. When the ConOps, architecture and requirements are at the draft or final draft stage, it is a good time to conduct a preliminary design review to determine whether the preliminary design can be approved and the project can move on to the detailed design stage.

Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.


Integrated Corridor Management: Implementation Guide and Lessons Learned

Author: Gonzalez, Paul: Dawn Hardesty; Greg Hatcher; Michael Mercer; Michael Waisley Noblis, Inc. 3150 Fairview Park Drive Falls Church, VA 22042 703-610-2000

Published By: U.S. DOT Federal Highway Administration

Source Date: February 2012

Other Reference Number: Report No. FHWA-JPO-12-075

URL: https://rosap.ntl.bts.gov/view/dot/3375

Other Lessons From this Source

Lesson Contacts

Lesson Analyst:

Cheryl Lowrance


Average User Rating

0 ( ratings)

Rate this Lesson

(click stars to rate)

Lesson ID: 2014-00671