5. Requirements
Requirements are the foundation for building an Integrated Corridor Management System. In this stage, a determination is made, in a more detailed manner than in the concept of operations, of what the ICMS should do. Requirements drive system development and are also used to determine (i.e., verify) if the ICMS has been built and installed correctly.
Requirements are statements of the capabilities that the ICMS must have (i.e., "functions"), geared to addressing the needs and objectives as defined by the corridor stakeholders and their respective organizations. For requirements to be most useful, they should be statements of what is desired, not descriptions of how the need should be satisfied; that is, good functional requirements are written without specifying technical design or implementation details.
The ICMS functional requirements should be based on the information obtained during the System Concept Stage (as documented in the Concept of Operations). In developing the requirements, several questions should be continuously asked, such as: What's the reason for this requirement? What critical purpose does it meet? What happens if we don't provide this capability? How can this requirement be quantified and verified?
Written requirements are important. A written requirements document captures what you are trying to achieve with this system in a tangible form, that others can read, review, and interpret. In addition to being technology-independent, good system requirements posses the following attributes:
- Necessary. Something that must be included, or an important element of the system that, if absent, other system components would be unable to compensate for.
- Concise (minimal, understandable). Stated in language that is easy to read, yet conveys the essence of what is needed.
- Attainable (achievable or feasible). A realistic capability that can be implemented for the available money, with the available resources, in the available time.
- Complete (standalone). Described in a manner that does not force the reader to look at additional text to know what the requirement means.
- Consistent. Does not contradict other stated requirements nor is it contradicted by other requirements. In addition, uses terms and language that mean the same thing from one requirements statement to the next.
- Unambiguous. Open to only one interpretation.
- Verifiable. Must be able to determine that the requirement has been met through one of four possible methods: inspection, analysis, demonstration, or test.
As is the case with most activities in the ICMS Implementation/Systems Engineering process, the development of ICM requirements can run through several iterative cycles of defining, reviewing, and refining. A key point related to this stage is that the end product must be a set of requirements on whose meaning all the ICM stakeholders agree. To achieve this buy-in and to eliminate ambiguity, it is often useful to conduct one or more ICM System Requirements review or "walk-through." It is important to make sure that all stakeholders interpret the requirements the same way. This is a critical step in the overall process; if everyone does not have the same interpretation, some will have expectations that will not be met, and unnecessary or inadequate capabilities may end up being implemented. It is also useful to have the system testers (i.e., the "verifiers") engaged during this process not only to review the requirements that they will have to test against, but also to begin developing the tests.
There will likely be two levels of requirements developed for an ICMS:
- High-level requirements: These focus on ICMS functions as a whole (i.e., system level). A few examples of such ICMS requirements are provided in Table 5-1.
- Detailed requirements: Each system level requirement is decomposed into a more refined set of requirements allocated to individual network systems and sub-systems.
Requirement Types:
UR1: The following systems shall be integrated under the umbrella of the ICMS (e.g., State DOT ATMS, Rail Agency Transit Management System, City Signal System). FR1: The ICM shall operate in the following modes (e.g., off-line, on-line monitoring, on-line control, training and simulation). PR1: The ICMS shall make available corridor operations measures to provide information about the real-time performance of travel alternatives on a network link basis. PR2: Corridor performance measures shall consist of: (e.g., travel times on selected comparable network links, travel times on corridor trips). |
In addition to the requirements document, a traceability matrix should also be prepared that "traces" each ICMS requirement back to the specific ICM concepts, objective(s), and needs as defined during the System Concept Stage; and vice-versa. As the ICMS development process moves forward, this Traceability Matrix will be expanded to document the compliance of the system designs with these requirements.
Once the requirements have been accepted, changes and updates to the ICMS requirements (and the traceability matrix) should be controlled using a change management process as discussed in chapter 11.
Performance Analysis
This recommended activity entails simulating the corridor under a variety of operational scenarios and combinations of ICM approaches and strategies as defined in the Concept of Operations. Simulation techniques that vary demand and capacity, and that provide for network shifts, should be used (see Technical Memorandum 5.5.). Such a performance analysis will permit a detailed evaluation of corridor and individual network performance when operated as an ICMS under a variety of scenarios and demand situations, and with different boundaries (e.g., networks and their limits).
This will permit a check on the operational implications of the proposed ICMS. Trade-offs may be required between the characteristics of the corridor to support the chosen strategies; the different scenarios (e.g., incident, regular, evacuation) that need to be addressed; the ability to manage spare capacity or to temporarily create spare capacity; and the boundaries that identify the operational impact of the corridor. The results from this performance analysis may be utilized to modify the ICM approaches and strategies (and, as a result, the associated requirements), further refine the corridor networks and boundaries, and provide quantitative estimates of benefits (e.g., travel times and delays with and without ICM) that can be used in promoting the ICM program to stakeholders and decision makers.