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

Date Posted
02/20/2014
TwitterLinkedInFacebook
Identifier
2014-L00671

Integrated Corridor Management: Implementation Guide and Lessons Learned

Summary Information

The Integrated Corridor Management: Implementation Guide and Lessons Learned document is intended for use by adopters of integrated corridor management (ICM) approaches and strategies to address congestion and travel time reliability issues within specific travel corridors. It introduces the topic of ICM and identifies the type of information system, known as the integrated corridor management system (ICMS), used to support transportation network managers and operators in applying ICM.

The U.S. DOT partnered with eight transportation agencies in large metropolitan areas, referred to as "Pioneer Sites," to research effective means of implementing ICM approaches in their major travel corridors. The guide discusses lessons learned that arose during the U.S. Department of Transportation’s (U.S. DOT’s) research initiative.

Lessons 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.
System Engineering Elements

Keywords Taxonomy: