Summary

Relationship to Other Components

As shown in the figure below, Functional Requirements are mapped directly to Inventory through the Functional Objects that are defined for each element. These Functional Objects are also a part of Service Packages, so requirements relate to the Service Packages. The interfaces between elements also generate a subset of the requirements (e.g. those related to interfaces to the element).

Regional ITS Architecture Components – Functions/Requirements

Approach

Whether this is an update to an existing architecture or the development of a completely new architecture the approach for the architecture's functionality involves organizing the data collected and decided so far and analyzing the requirements provided by ARC-IT as a starting point.

The next sections describe the different activities involved in each approach:

-         Updating Functional Requirements

-         Developing Functional Requirements

Updating Functional Requirements

Functional requirements in regional ITS architectures are defined for major elements in the ITS inventory. The requirements can be defined at two levels. The higher level is defined by the Functional Objects from ARC-IT that are mapped to each element through the mapping to physical objects of ARC-IT that is done in RADIT. For example, an element that is mapped to Traffic Management Center can select from 39 functional objects including functional objects such as TMC Traffic Information Dissemination, which is the functional object supporting the TMC functionality to operate dynamic message signs.

The lower level of functional requirements is when regional ITS architectures select a set of functional requirements for each of the selected functional objects. Again, this is done in RAD-IT (see discussion below). For example, there are 15 defined functional requirements for the functional object mentioned above, with the first requirement being "The center shall remotely control dynamic messages signs for dissemination of traffic and other information to drivers."

Updating Functions in the existing architecture involves reviewing the Functional Object selections for the key elements. Once the functional objects are updated, then the requirements themselves can be updated and the updated mappings outputted to the architecture website or document.

The update of the functional requirements in a regional ITS architecture is best done once the ITS inventory, the Service Packages, and User Needs have been revised. Then the update can be accomplished on the Functions tab of RAD-IT using the Autoselect feature to preselect the right functional objects and requirements.

There have been major changes made to the functional objects in ARC-IT in the past few years, so it is a good idea to review all the functional object mappings and revise as necessary. It will be a good idea to spend some time reviewing the details provided during the RAD-IT conversion process for the changes and use the Autoselect feature to bring in the latest functional objects and requirements.

Functional requirements do not need to be generated for all the elements of an architecture, only for the ones that are being implemented by ITS stakeholders in ITS projects. In fact, for an element that is mapped only to terminators of ARC-IT, there is no functionality that will be available for mapping in RAD-IT. Therefore, if you want an element to have automatically-defined functionality, then the element must be mapped to at least one subsystem of ARC-IT. User defined functional objects and requirements will have to be defined for elements that are mapped only to terminators; this should be done only if the elements will be implemented by ITS stakeholders as part of ITS projects.

Developing Functional Requirements

Functional Requirements are defined for elements in a regional ITS architecture. See the discussion in Updating Functional Requirements above for a further description of how these functional requirements can be defined for a regional ITS architecture.

Functional requirements should be developed for elements in the regional ITS architecture. As discussed in the Inventory component, an inventory will normally include elements on the boundary of ITS that don't directly provide transportation services, but do exchange information with ITS elements. The classic example of an inventory element that is on the boundary is a financial institution that interfaces with ITS elements to support financial transactions. In general, a regional ITS architecture should include functions for ITS elements and should not include functions for ITS elements on the boundary.

An architectural boundary should be established to determine where functional requirements are needed. There are several ways to establish this boundary.

1.             Perhaps the best approach is to consider whether each ITS element in the inventory will be implemented or enhanced with ITS projects implemented by the region's stakeholders. ITS elements that are implemented or enhanced with ITS projects are inside the ITS boundary and should include functional requirements. This may be the most definitive criteria for a regional ITS architecture boundary since this reflects one of the best uses for functional requirements. . .they are a starting point for ITS project specification.

2.             Is the ITS element in this region, or in another region that is subject to the requirements of another regional ITS architecture? ITS elements in other regions probably should not be functionally specified.

3.             Consider the services that are provided by the ITS element. If the ITS element provides surface transportation-related services, then it is probably inside the architecture boundary and should be supported by functional requirements.

4.             Review how the ITS element was mapped to the ARC-IT. ITS elements that map only to ARC-IT terminators may be on the boundary; ITS elements that map to ARC-IT subsystems may be inside the boundary and include functional requirements. If you have an element that is only mapped to terminators, but is one that is being implemented or enhanced through an ITS project, consider reviewing the mapping to ARC-IT to include a mapping to the subsystem that most closely matches the functionality of the element.

Once your boundary has been established of what's inside and outside your functional boundary it's time to build on the services, needs, and operational concept to define functional requirements, focusing on those with regional implications.

Using the information gathered previously, document the functions required to support the services the stakeholders decided to provide for the region. Draft the starting set of functional requirements and refine them as you get closer to deployment.

Once the inventory of elements have been defined in RAD-IT then functional requirements can be defined (See the RAD-IT tab discussion for this component). This can start with a selection of Functional Objects for the element. This selection will build on the ITS service package choices and user needs defined for the stakeholder and element.

When selecting and customizing requirements a suggestion is to focus on those elements with regional implications. The functional requirements can be documented best on an architecture website, which can list both functional objects and functional requirements assigned to elements.

RAD-IT

The key information about system functional requirements is found on the Functions tab of RAD-IT. The updates to Functional Objects mentioned above is performed on this tab. As shown below, for each element there is a list of functional objects. This list is based on the physical objects mapped to the element. The Autoselect button will allow selection of a set of Functional Objects based upon which service packages in which the element participates.

Functions Tab in RAD-IT

Selecting the Requirements button will open a new window that shows all the requirements defined for the selected Functional Objects. The figure below shows a subset of the Requirements for the element selected above. Note that some requirements are included and some are not, indicating that these requirements have been customized. Additional customization is allowed by tailoring requirements or creating new requirements.

Functional Requirements Form in RAD-IT

In regional ITS architectures, many elements, particularly center elements are mapped to multiple physical objects. If for example, you had mapped a center element to Maintenance and Construction Management Center (MCMC), but after completing customization on the Function tab find that no MCMC Functional Objects are selected, then it is likely you did not need that element mapping to the MCMC and should delete it on the Elements tab.

Opinions vary on how much effort to spend customizing functional requirements as part of a regional architecture effort. Requirements analysis is a key activity once a project begins its systems engineering effort. Using RAD-IT to automatically select a set of requirements based on the Inventory, Service Packages, and Needs for the regional architecture and then letting the requirements that come from ARC-IT be the starting point for customization once the project starts maybe a good middle-ground approach. If you know of projects that will be defined from this regional architecture then it may be worthwhile to the stakeholders to go ahead and start customizing the functional requirements. These customized functional requirements in the project architectures will then be available for additional systems engineering effort when using the SET-IT tool to create more detailed project architectures based on the project architecture in RAD-IT.

Examples

Examples of System Functional Requirements can be found in most regional ITS architectures if the region created an architecture website. For those architectures that create a website based on the RAD-IT tool, the following requirements information is provided for each element by selecting the Functionality link(s) on the Element detail page. The example below is from the Denver Council of Governments (DRCOG) Regional ITS Architecture.

Functional Objects Output Example

This web page provides the Functional Object level definition of the requirements. Access to the actual functional requirements is through the Functions tab on the home page which provides a list of the Functional Objects selected for the architecture (organized by Physical Object). An example of that page from a web site created for the Nashville Region is shown below. Selecting any of the Functional Area links provides a list of all the functional requirements from ARC-IT associated with the Functional Object.

Functions Web Page Example

Clicking on one of the Functional Areas (another name for Functional Objects from ARC-IT) will then show the functional requirements for those areas and the elements from the inventory that are assigned to those functions. See the page below for the Emergency Data Collection functional area from the Nashville Architecture.

Functional Requirements Web Page