During the information-gathering process, several themes emerged that have guided the development of requirements:
|Change must be supported
|The corridor is very much alive and changing. The road network and related infrastructure, data, tools, vehicles, organizations, processes, and technology are in a constant state of change. Some would say that the system requires continual maintenance, but it is more than that. There must be processes and associated resources by which these needed changes are actively identified, managed, and implemented into the ICM environment to address new opportunities or required updates at appropriate and timely intervals. These requirements are included as people-centric non-automatable requirements, with the goal of achieving a system that can adapt to change within the corridor, extending its system life and increasing its impact on the corridor and the people who live and travel within its boundaries.
|The need for simplicity was commonly mentioned. This included such desires as reducing the number of moving parts, providing as few interfaces as possible, or ensuring the system is understandable and usable.
|Leverage existing system assets
|While there was a general consensus that new functionalities are needed to implement the envisioned ICM system, it was also recognized that replacing existing systems used to monitor and control traffic would be cost-prohibitive. Therefore, the conclusion was to try to use, as much as possible, existing systems operated by stakeholder agencies.
|Correct level of integration
|While the need to integrate functions and processes was recognized, it was also emphasized that this need should not lead to the development of homogeneous systems or to the removal of individuality where it is both useful and required. This was interpreted to mean that the system should appear as a coherent set of working and predictable functions while allowing sub-functions to be unique in how they accomplish tasks.
|Single sources for processing methods
|The system should use common functional elements, algorithms, and design elements. For example, the system would be difficult to manage if one function determines data quality or calculates metrics differently from another function. If the same data results in different processed information, it is also difficult to isolate and resolve problems.
|Measurable metrics and data
|Rather than simply requiring functional results, it was seen as important to link requirements to success metrics and the use of data. Thus, where appropriate, requirements are written specifying that data be collected, that data be of a certain quality, that data quality be maintained over time, that it is clearly traceable how data is used in decision-making, and that there are appropriately trained and motivated personnel to ensure that these data needs are met on an ongoing basis. The intent was to define a system that includes everything necessary for its successful operation and maintenance.