Conduct a Requirements Analysis to determine the most appropriate ITS telecommunications solution.
Experiences from the Departments of Transportation (DOTS) of multiple states in selecting telecommunications options.
In conducting a rigorous requirements definition process for the Chesapeake Highway Advisories Routing Traffic (CHART) program, the Maryland State Highway Administration reasoned that it could not develop an efficient network for CHART without knowledge of why it was needed, who would be served, and how it would be used. This information enabled Maryland SHA to identify the appropriate technical characteristics of the telecommunications system, including data, video, and voice traffic.
By describing five key steps for performing a requirements analysis, there are lessons for anyone looking to begin the process of selecting their system:
- Identify ITS Program Goals, Objectives, and Requirements. Since the telecommunication is intended to support an ITS, the first step in developing the requirements is the formulation of ITS goals and objectives by the ITS stakeholders. In many cases these have been previously defined in earlier project documents. These goals and objectives serve as the bases for the derivation of high-level or generalized requirements, which can then be decomposed further into lower-level technical requirements.
- Derive Technical Requirements. The requirements analysis should include the following three types of technical requirements: functional, operational and performance.
- Functional requirements identify what is to be done. For example, a functional requirement is that the network must carry incident information from the traffic management system to the traveler information system.
- Operational requirements identify who or what performs the function, where the function is performed, how many perform the function and when it is performed.
- Performance requirements quantify performance measures such as how much, how often or how fast.
- Document Requirements. Each program-level and derived telecommunication requirement should be assigned to the appropriate requirement type and each should be assigned a unique identifier. Each requirement statement should be as concise as possible, and can be subdivided into two or more clearly identified parts.
- Validate Requirements. Upon identifying the set of requirements, it is necessary to review the complete list for inconsistencies, conflicts, and gaps and to check that each of the requirements is measurable. The requirements are then presented to the stakeholders (initially in writing and then in a group working session). It is important for someone at each stakeholder organization to indicate approval and to "take ownership" of the requirements. Reaching consensus on the requirements, both within and across stakeholder groups is likely to require multiple meetings. Reaching consensus will be facilitated if each stakeholder organization gives an individual the authority to speak for, and act on behalf of, the organization.
- Manage Requirements. The requirements analysis is a "living" document and should be carefully managed. Any changes to the document must be logged and described, and can only be made after formal review and approval by a configuration control board representing the interests of the stakeholder groups.
Author: Vince Pearce
Published By: U.S. Department of Transportation, Federal Transit Administration and Federal Highway Administration
Source Date: 2000
EDL Number: 11488
Other Reference Number: FHWA-JPO-99-023/FTA-TRI-11-99-02URL: http://ntl.bts.gov/lib/jpodocs/repts_te/11488.pdf
Average User Rating