Knowledge Resources

Many factors must be considered in deciding upon the right telecommunications solution for an ITS Program, and a requirements analysis is an effective tool for outlining these factors. A requirements analysis is a hierarchical, iterative process for deriving and describing the full set of needs to be satisfied by a product, system or service provider. The selection of the most appropriate telecommunications solution depends on the identification of the full set of requirements.

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.
  The requirements must be written in terms that telecommunications engineers can use to derive technical architectures, including components such as video, data, voice, local area network (LAN), reliability, maintainability and availability (RAM), and security. Examples of detailed requirements are device message sizes and formats, frequency of transmission, polling interval for low speed devices, image and motion quality, transmission delay, number of simultaneously viewable images, and camera selection and control constraints for CCTV.
• 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.

The requirements analysis provides the technical basis for identifying the appropriate telecommunications solution for an ITS project. In defining technical requirements, Maryland SHA was able to minimize two key risks: 1) that the agency would build a network that would not meet its needs, and 2) that the agency would build a network that would be costly to change or redesign in order to take advantage of technology improvements. By understanding and documenting its requirements, particularly by identifying who needed access to the information and how much bandwidth was required to provide acceptable access, Maryland SHA could build a network that adequately addressed its needs.