High-Level Requirements for the US-75 Integrated Corridor in Dallas, Texas
April 30, 2008
Award# DTFH-61-06-H-00040
5. User Requirements
Use cases are a technique for capturing the functional requirements of a system. Use cases work by describing the typical interactions between the users of a system and the system itself, by providing a narrative of how a system is used.
Utilizing the scenarios developed during the concept of operations phase of the ICM project, use cases were developed to tie the scenarios together by a common user goal. The goal of the typical user (traveler) is to make a trip from one location to another. This trip requires the user to plan, understand the current conditions of the transportation network, and make changes during the trip if the conditions of the network change. In use case terminology, the users are referred to as actors. An actor is a role that a user plays with respect to the system. Actors might include travelers, agency operators, or the ICM steering committee. Actors carry out use cases. A single actor may perform many use cases; conversely a use case may have several actors performing it.
There are three key things we need to know to describe a use case:
- The actor or actors involved.
- The system being used.
- The functional goal that the actor achieves using the system (the reason for using the system.)
There's a little more to it than that, for example if we were developing a use case for an Automated Teller Machine:
- The actor describes a role that users play in relation to the system. Maybe the cardholder is an advertising executive, but that doesn't interest us. We only care about his relationship to the system.
- The actor is external to the system itself.
- Actors don't have to be people. They can be other systems. For example, the ATM may need to connect to the cardholder's bank. External systems that interact in a use case are also actors.
- The goal must be of value to the actor. We wouldn't have a use case called Cardholder enters PIN because that, by itself, has no value to the cardholder. We don't build ATM's just so people can enter their PINs.
When we are analyzing functional requirements for a system, the key questions we need to ask are; who will be using the system, and what will they be using it to do?
In order to get a more complete understanding of the user needs within the corridor, and identification of functions required, the input from the corridor stakeholders was utilized to develop a preliminary list of needs and functions.
Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.
5.1. Actors
In order to understand the process of each use case, the actors (or users of the system) were identified. The following actors would be the main stakeholders and users of the ICM System, in some instances the actors are subsystems of the ICM and would interact with other parts of the ICM.
5.1.1. Traveler
Travelers utilize the transportation network to make trips. They need up to date information on the routes, modes and conditions of the various networks available to make the trip.
5.1.2. ICM Agency
ICM Agencies operate and control the transportation network and supporting facilities within the corridor. This includes enforcement agencies (police, fire, EMS), maintenance, and operators of the corridor networks. Their role is to operate the network in a coordinated fashion to improve the mobility and efficiency of the entire network within the corridor.
5.1.3. Evaluation Model Subsystem
In order to measure the effectiveness of the pre-approved responses, and develop new responses, an Evaluation Model subsystem will utilize the data from ICM Agencies via the Regional Data Warehouse in order to model the corridor and the potential operational responses to improve the efficiency of the overall corridor network.
5.1.4. Decision Support Subsystem
The Decision Support Subsystem (DSS) is an external system to the corridor that is utilized to assist in the response to various incidents within the corridor. The DSS will be utilized as a search tool to assist with the distribution of pre-approved responses to ICM Agencies, and Third Party. The DSS System also includes a real-time Corridor Model which will be used to model the network in real-time, and predict required responses for operating the network.
5.1.5. Third Party Infrastructure
For certain network conditions, a third party is required to provide additional infrastructure (parking, van pools, etc.) for the corridor in order to respond to certain incidents and special events.
5.1.6. Regional Data Warehouse
During the daily operations of each network a tremendous amount of data is collected for various uses. NCTCOG has developed a regional Data Warehouse that will be utilized by the ICM agencies. The data in the regional Data Warehouse will be used by the Evaluation Model subsystem in order to model the corridor and the potential operational responses to improve the efficiency of the overall corridor network, and used for the baseline model for the DSS.
5.2. Existing Use Case: Plan Trip (External to ICMS)
5.2.1. Brief Description
Prior to making a trip within the region, a traveler will utilize multiple media, personal experience, and current conditions information to plan their route and mode for the trip to and from a location.
5.3. Existing Use Case: Change Trip – En route (External to ICMS)
5.3.1. Brief Description
As travelers make trips, information on the condition of their current route and mode will be available and updated in near real-time; this will potentially have the impact of changing the route or mode of the trip, depending on the traveler's requirements.
5.4. New Use Case: Determine Response
5.4.1. Brief Description
As the ICM Agency monitors their infrastructure and the conditions of their network, incidents will occur. When an incident occurs, the agency system will send data on the incident to the ICM Decision Support Subsystem. Once the DSS receives the data, it will compare the data to its pre-approved response plans, and select the closest matching plan. Once the DSS has selected the response plan, it will notify all ICM Agencies and any 3rd parties of the incident, and recommended response.
5.4.2. Actors
- ICM Agency
- Decision Support Subsystem
5.4.3. Work Scenario
- ICM Agency Inputs information on current incident
- DSS receives agency information
- DSS compares inputted data to pre-approved response plans
- DSS selects closest matching response plan
- DSS sends out response plan and incident data to agencies and regional ATIS
5.4.4. Tool(s)
- Regional Center to Center
- Decision Support Subsystem
5.4.5. Special Requirements
- None
5.4.6. Non-functional Requirements
- Determine Response Plan within 30 seconds
- Send out Response Plan Requests within 10 minutes of receiving data
5.4.7. Interfaces
- ICM Agencies
- Decision Support Subsystem
- Regional ATIS
5.4.8. Post Condition
- Response is selected and sent to be implemented
5.4.9. Priority
- High
5.5. New Use Case: Update Pre-planned Responses
5.5.1. Brief Description
After incidents have occurred, the ICM committee will meet on a routine basis to review how the response plans worked during various incidents. Based upon the Evaluation Model subsystem, and lessons learned from the incident responses, updates to the pre-approved plans may be required.
5.5.2. Actors
- ICM Steering Committee
- Regional Data Warehouse
- Evaluation Model subsystem
- Decision Support Subsystem
5.5.3. Work Scenario
- ICM Steering Committee receives incident information and response plan used from the Regional Data Warehouse
- ICM Steering Committee receives the effectiveness measures from the Evaluation Model subsystem
- ICM Steering Committee reviews the incident information, response plan information, lessons learned, and effectiveness measures for a given incident
- ICM Steering Committee decides if the response plan can be improved, needs alterations, or is okay as written
- ICM Steering Committee updates existing response plan, or creates new response plan
- ICM Steering Committee provides updated and new response plans for the DSS
5.5.4. Tool(s)
- Evaluation Model subsystem
- Decision Support Subsystem
5.5.5. Special Requirements
- None
5.5.6. Non-functional Requirements Interfaces
- Evaluation Model subsystem
- Regional Data Warehouse
5.5.7. Post Condition
- Pre-approved response plan updated
5.5.8. Priority
- High
5.6. Enhance Use Case: Monitor Network Conditions
5.6.1. Brief Description
Agencies, as part of their normal operations, monitor the conditions of their infrastructure and network. As conditions change, the change in conditions may be due to incidents, congestion, or malfunction of devices.
5.6.2. Actors
- ICM Agency – provides information and data on current incidents
5.6.3. Work Scenario
- ICM Agency monitors network conditions of their infrastructure
- ICM Agency responds to abnormal conditions
- ICM Agency informs others of abnormal conditions
5.6.4. Tool(s)
5.6.5. Special Requirements
- None
5.6.6. Non-functional Requirements
- Receive updates approximately every 5 minutes from field equipment
5.6.7. Interfaces
- ICM Agency ATMS
- ICM Agency Signal Systems
- ICM Agency CAD E911 Systems
- ICM Agency Infrastructure
- ICM Agency Operations
- Regional Center to Center
5.6.8. Post Condition
5.6.9. Priority
- High
5.7. Enhance Use Case: Update Network Conditions
5.7.1. Brief Description
As ICM Agencies operate their infrastructure and network, the ICM System will receive data on the current conditions of each agency's network. During an incident, the ICM system will receive updated conditions and provide this information to the other agencies, travelers, and other systems. This updated condition information could include information on an incident, or information on return to normal conditions, for example.
5.7.2. Actors
- DSS – provide current and predictive status of the network
- ICM Agency – provides information and data on current incidents
5.7.3. Work Scenario
- ICM Agency monitors network conditions of their infrastructure
- ICM Agency informs others of changes in previously reported abnormal conditions
- ICM Agency informs others when return to normal operation
5.7.4. Tool(s)
- ICM Agency Infrastructure (DMS, Websites)
- 3rd Party ISP
- 511 System
5.7.5. Special Requirements
5.7.6. Non-functional Requirements
- ICM Agency systems will be able to receive data from other agencies and systems
- Provide updates approximately every 10 minutes on condition of network
5.7.7. Interfaces
- Regional ATIS
- Regional Center to Center
- ICM Agency Infrastructure
5.7.8. Post Condition
- Network conditions updated
5.7.9. Priority
- High
5.8. New Use Case: Implement Pre-approved response plan
5.8.1. Brief Description
When and incident occurs within the ICM corridor (or impacts the corridor) the DSS system will recommend a pre-approved response plan. This response plan recommendation, along with current incident information, will be provided to the ICM agencies, and 3rd parties. As part of the response plan, the ICM agencies and in some cases the 3rd parties, will implement the response.
5.8.2. Actors
- ICM Agency
- 3rd Party
- Decision Support Subsystem
5.8.3. Work Scenario
- ICM Agency receives pre-approved response plan request from the DSS
- ICM Agency implements response plan; or notifies system and other ICM Agencies if changed
- 3rd Party receives pre-approved response plan request from the DSS (or ICM Agency)
5.8.4. Tool(s)
- ICM Agency Infrastructure (DMS, Websites)
- CAD E911 System
- Regional Center to Center
- Decision Support Subsystem
5.8.5. Special Requirements
5.8.6. Non-functional Requirements
- ICM Agency systems will be able to receive data from the DSS and other ICM agency systems
- Begin to implement response plans within 10 minutes of receiving request (or provide response to requesting agency)
5.8.7. Interfaces
- Decision Support Subsystem
- Regional Center to Center
5.8.8. Post Condition
- Response Plan implemented
5.8.9. Priority
- High
5.9. Enhance Use Case: Collect Historical Information
5.9.1. Brief Description
In order to measure the effectiveness and for planning purposes, the ICM system must collect and store the data and information on the infrastructure and network collected during the operation of the system. This historical information can be used for a variety of planning and operational purposes.
5.9.2. Actors
- ICM Agency
- Decision Support Subsystem
- Regional Data Warehouse
- Evaluation Model subsystem
5.9.3. Work Scenario
- ICM Agency provides data warehouse with network condition data
- ICM Agency provides data warehouse with incident data
- DSS provides data warehouse with response plan list used during incidents
- Evaluation Model subsystem receives data from data warehouse for modeling of the corridor
5.9.4. Tool(s)
- Regional Data Warehouse
5.9.5. Special Requirements
5.9.6. Non-functional Requirements
- Regional Data Warehouse will be able to receive the data from all ICM Agency systems and the DSS in various formats
5.9.7. Interfaces
- ICM Agency network
- ICM Steering Committee
- Regional Data Warehouse
- Decision Support Subsystem
- Regional Center to Center
5.9.8. Post Condition
- Historical information is stored
5.9.9. Priority
- High