Systems Engineering for Intelligent Transportation Systems

4 ITS Technical Processes

This document is intended to help you understand how systems engineering can be used throughout the ITS project life cycle. Chapters 4 and 5 present two different types of processes that support systems engineering:

1. Technical processes, such as system requirements, high-level design, integration, and verification, are described here in Chapter 4. These processes, depicted in the "V" systems engineering model, are performed to develop an ITS project that meets the user's needs. This chapter leads you step by step through each of the technical processes in the "V". Each process is summarized, key activities are identified, and outputs that should be generated are defined.
2. Project management processes, such as project planning, risk management, and configuration management, are described in Chapter 5. These cross-cutting activities are just as important to the success of the project, but they do not appear in the "V" diagram because they apply to many different steps in the "V". These processes are used to plan, monitor, and control the ITS project so that it is completed on time and on budget.

Relationship to Traditional Transportation Processes

ITS projects are identified and funded through transportation planning and programming/budgeting processes in each state, planning region (e.g., metropolitan planning area), and agency. The "V" diagram and the systems engineering process begin once a need for an ITS project has been identified. The early steps in the "V" define the project scope and determine the feasibility and acceptability as well as the costs and benefits of the project. These early steps actually support planning and programming/budgeting since they are intended to identify high-level risks, benefits, and costs and to determine if the ITS project is a good investment. The latter steps support project implementation, then transition into operations and maintenance, changes and upgrades, and ultimate retirement or replacement of the system. (The systems engineering "V" is placed in context with the traditional transportation project life cycle in Section 6.1.)

Technical Documentation

Each step of the process that is described in this chapter results in one or more technical outputs. This documentation is used in subsequent steps in the process and provides a critical documentation trail for the project. The documentation that is discussed in this chapter is identified in Table 1, which provides a bird's-eye view of where it fits in the "V". Several resources provide good descriptions and templates for this documentation.⁷ Note that not every ITS project will require every document listed in the table. (More information on tailoring is provided later in this chapter and in Section 6.2.3.)

About the Examples

This chapter is illustrated with real examples that show how different agencies have used the systems engineering process for their ITS projects. These real examples aren't perfect and shouldn't be taken as the only approach, or even the best approach, for accomplishing a particular step. As time goes by and we gain experience using systems engineering on ITS projects, many more examples will become available.

Table 1: Technical Documentation in the "V" Systems Engineering Process

4.1 Using the Regional ITS Architecture

In this step: The portion of the regional ITS architecture that is related to the project is identified. Other artifacts of the planning and programming processes that are relevant to the project are collected and used as a starting point for project development. This is the first step in defining your ITS project.

4.1.1 Overview

The regional ITS architecture provides a good starting point for systems engineering analyses that are performed during ITS project development. It provides region-level information that can be used and expanded in project development.

When an ITS project is initiated, there is a natural tendency to focus on the programmatic and technical details and to lose sight of the broader regional context. Using the regional ITS architecture as a basis for project implementation provides this regional context as shown in Figure 8. It provides each project sponsor with the opportunity to view their project in the context of surrounding systems. It also prompts the sponsor to think about how the project fits within the overall transportation vision for the region. Finally, it identifies the integration opportunities that should be considered and provides a head start for the systems engineering analysis.

Figure 8: Regional ITS Architecture Framework for Integration

The regional ITS architecture is a tool that is used in transportation planning, programming, and project implementation for ITS. It is a framework for institutional agreement and technical integration for ITS projects and is the place to start when defining the basic scope of a project.

The regional ITS architecture is the first step in the "V" because the best opportunity for its use is at the beginning of the development process. The architecture is most valuable as a scoping tool that allows a project to be broadly defined and shown in a regional context. The regional ITS architecture step and the concept exploration step that is described in the next section may iterate since different concepts may have different architecture mappings. The initial architecture mapping may continue to be refined and used as the Concept of Operations and system requirements are developed.

The Regional ITS Architecture Guidance Document provides detailed guidance for regional ITS architecture development, use, and maintenance. (Version 2 of this document provides detailed guidance for using a regional ITS architecture to support project implementation.)

4.1.2 Key Activities

Initial use of the regional ITS architecture requires a few basic activities: locating the right architecture, identifying the portion of the architecture that applies to your project, and notifying the architecture maintainer of any required regional architecture changes. None of these tasks is particularly time consuming – the basic extraction of information can be done in an afternoon, even for a fairly complex project, if you are knowledgeable about the regional ITS architecture. Of course, it can be time consuming to climb the learning curve, and coordinating and building consensus on the scope of the project will require time and effort. Each of the key activities is described in the following paragraphs.

• Identify regional ITS architecture(s) that are relevant to the project – First, find the regional ITS architecture that covers the geographic area where your project will be implemented. In some cases, more than one regional ITS architecture may apply. For example, a major metropolitan area may be included in a statewide architecture, a regional architecture for the metropolitan area, and subregional architectures that are developed for a particular agency or jurisdiction. Coordinate with the ITS specialist at the FHWA Division/FTA Regional Office if necessary to sort this out.

  In the event that no regional ITS architecture exists at the time that an ITS project is initiated, coordinate with the FHWA Division/FTA Regional Office on starting a regional ITS architecture effort. In the interim, a project-level architecture should be developed based on the National ITS Architecture⁸ to support the ITS project.

• Identify the portion of the regional ITS architecture that applies – Next, identify the portion of the regional ITS architecture(s) that are applicable to your project or identify the portion of the National ITS Architecture that applies if a regional ITS architecture does not exist. Document any constraints that the architecture may place on the project, including ITS standards that may be applicable.

  The systems engineering analysis requirements identified in FHWA Rule 940.11/FTA Policy Section VI require identification of the portion of the regional ITS architecture that is implemented by each ITS project that uses federal funds. If a regional ITS architecture does not exist, then the portion of the National ITS Architecture that will be implemented by the project must be identified.

  You should build consensus around the fundamental project scope decisions that are made as the relevant portions of the regional ITS architecture are identified. One good approach is to create a context diagram that shows the ITS system to be implemented in the middle of the diagram surrounded by all other potentially interfacing systems in the region. For example, Figure 9 is a context diagram for the MaineDOT Communications Center. A context diagram can be used to discuss integration opportunities that should be considered in this project and in future projects. A discussion like this puts the ITS project in context and raises awareness of future ITS integration opportunities. It also may highlight regional ITS architecture issues that should be addressed.

  In almost every case, the regional ITS architecture will identify potential integration opportunities that will not be included in the current project. Specific integration options may be deferred for many reasons – agencies on both sides of the interface may not be ready, there may not be sufficient funding or time available to implement everything, supporting infrastructure may not yet be completed, a necessary standard may not be available, implementing too much at once may incur too much complexity/risk, etc.

  Even if they are deferred, it is important to account for future integration options in the current project design. The ultimate goal is to make ITS deployment as economical as possible by considering how this project will support future projects over time. To support this objective, future integration options that may impact the project design should be identified and considered in the project development. For example, additional stakeholders may be involved in the current project to ensure that future interface requirements are identified and factored into the current project design.

• Verify consistency with the regional ITS architecture and identify any necessary changes to it – Confirm that nothing planned in your project would be counter to the regional ITS architecture. If you determine that the regional ITS architecture should be updated to more accurately reflect your ITS project, submit the required changes to the regional ITS architecture maintainer named in the architecture maintenance plan.

  Each region should define a mechanism that allows the project team to provide comments on the architecture with minimal time investment. Project teams that use the architecture will be among the most significant sources for regional ITS architecture maintenance changes, and the region should strive to facilitate this feedback. If your region does not have such a mechanism, consult the Regional ITS Architecture Guidance Document for more information on facilitating architecture use and maintenance in your region.

4.1.3 Outputs

The first output of this step is the subset of the regional ITS architecture for the ITS project. While the Rule/Policy requires a subset of the regional ITS architecture to be identified, it does not define the components that should be included. You should consult local guidelines or requirements to help make this determination. In most cases, the following components will precisely define the scope of the project: (1) stakeholders, (2) inventory elements, (3) functional requirements, and (4) information flows.

These four components define the system(s) that will be created or impacted by the project, the affected stakeholders, the functionality that will be implemented, and the interfaces that will be added or updated. Other components may be identified, including market packages, roles and responsibilities, relevant ITS standards, and agreements. For very large ITS projects, this might be several pages of information. For a small ITS project, this might fit on a single page. The information that is extracted will actually be used in the concept exploration, Concept of Operations, requirements, and design steps that follow.

The Turbo Architecture software tool can be used to quickly and accurately define an ITS project architecture if the regional ITS architecture was developed with Turbo. Turbo Architecture can be used to generate diagrams and reports that fully document the portion of the regional ITS architecture that will be implemented by the project. Turbo Architecture can also be used to develop a project ITS architecture based on the National ITS Architecture if a regional ITS architecture does not exist. The Turbo Architecture software can be obtained from McTrans by visiting their website at http://www-mctrans.ce.ufl.edu/featured/turbo/.

If you don't find what you need in the regional ITS architecture, then you should add the missing or changed items to your architecture subset and highlight them so it is clear what you changed. For example, if there is a system in your project that is not represented in the regional ITS architecture, add it to your architecture subset and highlight it. The highlighted changes serve two purposes: they allow you to move forward with an augmented architecture subset that you can use in the next steps of the process, and they provide the basis for your feedback for regional ITS architecture maintenance.

The second output of this step – feedback to the regional ITS architecture maintenance team – is just as important as the first output. Submit any recommended changes using the mechanism defined for your region in the regional ITS architecture maintenance plan.

4.1.4 Examples

The subset of the regional ITS architecture that is included in the project can be shown in a series of simple tables and/or a diagram from Turbo Architecture, as shown in Figure 9. This figure identifies the inventory elements and interfaces that will be implemented by a MaineDOT Dynamic Message Sign (DMS) project in which several signs will be installed in Portland, Maine, along with a central control system with interfaces to a number of other centers. Functional requirements that are relevant to the project were also extracted, as shown in Table 2.

Figure 9: Example: MaineDOT DMS Project Architecture Subset

Table 2: MaineDOT DMS Project Functional Requirements (Partial List)

4.2 Feasibility Study/Concept Exploration

In this step: A business case is made for the project. Technical, economic, and political feasibility is assessed; benefits and costs are estimated; and key risks are identified. Alternative concepts for meeting the project's purpose and need are explored, and the superior concept is selected and justified using trade study techniques.

4.2.1 Overview

In this step, the proposed ITS project is assessed to determine whether it is technically, economically, and operationally viable. Major concept alternatives are considered, and the most viable option is selected and justified. While the concept exploration should be at a fairly high level at this early stage, enough technical detail must be included to show that the proposed concept is workable and realistic. The feasibility study provides a basis for understanding and agreement among project decision makers – project management, executive management, and any external agencies that must support the project, such as a regional planning commission.

The Rule/Policy requires the systems engineering analysis to include an analysis of alternative system configurations and technology options. The focus of this Rule/Policy requirement is on design decisions that are made later in the process, but a fundamental analysis of basic systems configurations is performed in this step.

It is easy to confuse the concept exploration that is performed in this step with the Concept of Operations that is developed in the next step. Concept exploration is a broad assessment of fundamentally different alternatives – for example, a new electronic toll facility versus additional conventional lanes. The alternatives would have dramatically different concepts of operations, so it is important to select a proposed concept before developing a Concept of Operations. Different alternatives may also have different regional ITS architecture mappings, so this step may iterate with the previous regional ITS architecture step.

The process is driven by the project vision, goals, and objectives, and by the needs for the project that were identified through the transportation planning process. It starts by identifying a broad range of potential concepts that satisfy the project need(s). The concepts are compared relative to measures that assess the relative benefits, costs, and risks of each alternative. Project stakeholders must be involved to establish the evaluation criteria, verify that all viable alternative concepts are considered, and make sure there is consensus on the selected alternative. The recommendations provide a documented rationale for the selected project approach and an assessment of its feasibility. The process is identical to a feasibility study done for large roadway and transit projects.

The alternatives analysis that is performed during a feasibility analysis uses a basic trade study technique, shown in Figure 10, that will be repeated many times during the project life cycle. At this early concept exploration step, the alternatives are fundamental choices, such as to maintain the existing facility ("do nothing"), build a new road, or add ITS technology to the existing facility. During design, the alternatives are design decisions, such as whether signs should be located at location A, B, or C. During construction, alternatives may have to do with optimizing closures while the work is performed. At each step, a set of alternatives is identified and analyzed from technical, economic, and operational perspectives.

Figure 10: Concept Exploration Uses Basic Trade Study Techniques

A feasibility study should be conducted only when a broad analysis is needed before the commitment of development resources. Some states require a feasibility study for certain ITS projects. A feasibility study is typically not required for smaller, incremental ITS projects where there are not fundamentally different approaches for implementation and where feasibility is not in question – for example, a project that adds DMS to an existing system. In other cases, a broad exploration of alternatives is not warranted but a cost-benefit study is needed to make the business case for the project.

4.2.2 Key Activities

Here at the very beginning of project development, the unknowns will certainly outnumber the knowns. Without a Concept of Operations or requirements, many assumptions will have to be made. It is important to educate the group performing this assessment on the concept exploration process and to set a schedule – otherwise, this stage could be an open-ended process since there's always something new over the horizon. The process activities are:

• Define evaluation criteria – Work with stakeholders to clearly define the problem or opportunity that is to be addressed by this project, elaborating on the identified purpose and the need(s), goals, and objectives as necessary. These elements were originally defined through the transportation planning and programming process that identified the project. The inputs may be augmented by the portion of the regional ITS architecture that was identified in the previous step.

  Based on the statement of the problem, establish cost constraints and any other constraints that will be used to limit the acceptable alternatives. Determine how success will be measured – the degree to which the project will solve the stated problem or realize the identified opportunity. These measures should be included in the criteria that will be used to evaluate the alternative concepts. Also, do a preliminary risk analysis to identify issues and obstacles that may affect the project, and develop evaluation criteria that will measure the sensitivity of each candidate solution to each of the risks.

  It is a good idea to define evaluation criteria before alternative concepts are enumerated. By developing the criteria first, you reduce the risk of intuitively settling on an alternative and then subconsciously biasing the criteria toward the preferred alternative. It is important to develop the criteria so that they are not preferential to one of the concepts.

• Identify alternative concepts - Identify a broad range of potential concepts that will solve the identified problem. The alternative concepts should be defined in clear, technology-independent terms that all affected organizations will understand. At least two (and preferably more) alternatives should be defined. One alternative should always be "do nothing", which provides a basis for comparison with the other alternatives.

  If you find that you are identifying specific products or vendors as the alternative solutions, you are being too specific. A trade comparison of products or vendors occurs much later in the process based on defined requirements during design. The alternatives here should be high-level concepts – for example, instrumentation with traffic detectors versus use of traffic probes to support traffic data collection for a corridor. Alternatives may also reflect life-cycle options, such as leased versus owned equipment, contracted versus in-house staffing, etc. You may have to establish a basic architecture and a minimal strawman design to support the analysis, but do no more than is necessary to support the evaluation.

  A common pitfall in developing a concept exploration or any trade study comparison is the premature selection of an alternative early in the study process. Be sure to keep an open mind and spend enough time on all viable options. If only one of the alternatives is defined in detail in a concept exploration, it creates the appearance that the other alternatives were not earnestly considered or explored.

• Evaluate alternatives – Perform a systematic analysis of the alternatives, applying the same criteria to each. The evaluation should measure the technical benefit, the economic impact, the operational feasibility, the life-cycle costs, and the risks associated with each alternative. A cost-benefit analysis is a key aspect of the evaluation.

  A number of tools support cost-benefit analysis for ITS projects:

  • The ITS Costs database contains estimates that can be used for policy analysis and cost-benefit analysis. It contains unit cost estimates for more than 200 ITS technologies as well as system costs for selected ITS deployments. (The unit cost database is available online and as an Excel spreadsheet at http://www.itscosts.its.dot.gov.)
  • The ITS Benefits database contains information regarding the impacts of ITS projects on the operation of the surface transportation system. The ITS Benefits website provides an online and Excel spreadsheet version of this database as well as several other documents pertaining to ITS benefits. (See http://www.itsbenefits.its.dot.gov.)
  • The ITS Deployment Analysis System (IDAS) is software developed by the Federal Highway Administration that can be used to estimate the benefits and costs of ITS investments, which are either alternatives to or enhancements of traditional highway and transit infrastructure. IDAS can currently predict relative costs and benefits for more than 60 types of ITS investments. (See http://idas.camsys.com/.)
  • SCRITS (SCReening for ITS) is a spreadsheet analysis tool for estimating the user benefits of ITS. It is intended as a sketch- or screening-level analysis tool for allowing practitioners to obtain an initial indication of the possible benefits of various ITS applications. (For more information, see http://www.fhwa.dot.gov/steam/scrits.htm.)

  While it is best to do a complete analysis of every alternative, sometimes the sheer number of alternatives makes this thorough approach impractical. One common practice is to apply the evaluation criteria in stages, weeding out the alternatives that don't meet the fundamental criteria so that the more detailed, time-consuming analysis is performed on only a few of the most viable alternatives. The evaluation should be validated by reviewing the analysis with stakeholders who may have reasonable objections to certain assumptions and alternatives.

• Document results - The feasibility study is documented to provide an overview of the project and determine if feasible solutions exist that should be funded and implemented. The study document should include sufficient information to support the decision makers who will make funding decisions based on the study. The cost-benefit analysis may be included as part of the feasibility study document or included in a separate cost-benefit analysis document, depending on the nature of the project and state/local documentation requirements.

  Remember your audience when writing a feasibility study; this study makes a business case primarily for a management audience. Any feature of the study that prevents the reader from assimilating the costs and benefits and the associated risks of each alternative solution as briefly, completely, and painlessly as possible reduces the effectiveness of the study for the audience.

  Several review cycles may be required for the feasibility study. First, the document should be circulated among the project team to make sure that there is buy-in. Then an updated draft should be distributed to internal management and other organizations for approval.

4.2.3 Outputs

The feasibility study establishes the business case for investment in a project by defining the reasons for undertaking the project and analyzing its costs and benefits. Different organizations and different projects will have different requirements, but a feasibility study should contain, at a minimum, the following:

1. A description of the problem or opportunity that the project is intended to address.
2. The project objectives that must be achieved for an alternative to be an effective response to the problem or opportunity, and the evaluation criteria that were used.
3. Economic and risk analyses of each of the alternatives that meet the established objectives, and the reasons for rejecting the alternatives that were not selected.
4. A summary description of the selected alternative, including the major system features and resources that will be used.
5. An economic analysis of the funding sources, the life-cycle costs and benefits of the project, and the life-cycle costs and benefits of the current method of operation.

4.2.4 Examples

Identification of Alternatives – Transportation Planning Studies

Feasibility studies that examine alternative concepts are frequently done for large transportation projects as part of corridor studies, major investment studies, and environmental analysis reports. The ITS option(s) in these studies often compete with traditional capital improvement options; hybrid options, which include a mix of technology and traditional capital improvements, are also considered.

For example, a congested corridor in Collin County, Texas, was the subject of a feasibility study report (FSR)⁹ that was prepared by representatives from the North Central Texas Council of Governments and affected agencies. This FSR examined the following alternatives: (1) do nothing, (2) build a new freeway, (3) build a toll road with electronic collection (two alternatives), and (4) build managed lanes. One summary table that compared the traffic volumes supported by the different alternatives is shown in Table 3. Supported traffic volumes, estimated capital costs, and potential revenue generation were used to compare the alternatives. The analysis favored the electronic toll alternatives.

Broad alternatives analyses like these are included in many planning studies.

Table 3: Comparison of Alternatives – Supported Traffic Volumes for 2025

Cost-Benefit Analysis

Minnesota DOT developed a guidance document¹⁰ for cost-benefit analysis in 2005 that includes several illustrative examples. Generally, higher-level graphics that visually compare the costs and benefits of the alternatives, like the one shown in Figure 11, are used in the body of the cost-benefit analysis. More detailed computation that supports high-level graphics, like the table reproduced in Table 4, is included in appendices.

Figure 11: Example of High-Level Economic Comparison of Alternatives

Table 4: Example of Alternatives Benefit Estimation

4.3 Concept of Operations

In this step: The project stakeholders reach a shared understanding of the system to be developed and how it will be operated and maintained. The Concept of Operations (ConOps) is documented to provide a foundation for more detailed analyses that will follow. It will be the basis for the system requirements that are developed in the next step.

4.3.1 Overview

The Concept of Operations (ConOps) is a foundation document that frames the overall system and sets the technical course for the project. Its purpose is to clearly convey a high-level view of the system to be developed that each stakeholder can understand. A good ConOps answers who, what, where, when, why, and how questions about the project from the viewpoint of each stakeholder, as shown in Figure 12.

• Who – Who are the stakeholders involved with the system?
• What – What are the elements and the high-level capabilities of the system?
• Where – What is the geographic and physical extent of the system?
• When – What is the sequence of activities that will be performed?
• Why – What is the problem or opportunity addressed by the system?
• How – How will the system be developed, operated, and maintained?

Figure 12: Concept of Operations (Adapted from ANSI/AIAA-G-043-1992)

In ITS, we draw a distinction between an Operational Concept, which is the high-level description of roles and responsibilities that is included in the regional ITS architecture, and a Concept of Operations, which is the more detailed, multifaceted document described in this section.

Don't assume that a new ConOps is required for every ITS project. A single system-level ConOps can support many ITS projects that incrementally implement and extend a system. For example, a ConOps may be developed for a large transportation management system. This system may be implemented and expanded with numerous ITS projects over several years. Once the ConOps is developed, it may be reviewed and used with relatively minor updates for each of the projects that incrementally implement the transportation management system.

4.3.2 Key Activities

Although there is no single recipe for developing a ConOps, successful efforts will include a few key activities:

• Identify the stakeholders associated with the system/project – Systems engineering in general, and this effort in particular, require broad participation from the project's stakeholders. One of the first steps in developing a ConOps is to make sure that all the stakeholders involved in or impacted by the project – owners, operators, maintainers, users, and so forth – are identified and involved. You can start with the stakeholder list from the regional ITS architecture and then expand it to identify the more specific organizations – divisions and departments – that should be involved. One of the most effective ways to involve the stakeholders is to create an integrated product team (IPT) that brings together the necessary expertise and provides a forum for all project stakeholders.
• Define the core group responsible for creating the ConOps – Although broad involvement is critical, you can't have 20 people on your writing team. Select a few individuals who are responsible for capturing and documenting the vision of the broader group. Depending on the size of the project and staff capabilities, this team might include a consultant or staff members with knowledge of the project and requisite writing and communications skills.

  If you hire a consultant, don't assume that is the end of your responsibility for ConOps development. The stakeholders are the foremost experts on their needs and must be materially involved in the ConOps development. The consultant can provide technical expertise on what should be in a ConOps, facilitate the meetings and outreach activities, prepare the document, and coordinate the review, but the stakeholders' concept should be documented in the end. The stakeholders should consider the ConOps their document, not the consultant's document.

  The best person to write the ConOps may not be the foremost technical expert on the proposed system. Stakeholder outreach, consensus building, and the ability to understand and clearly document the larger picture are key.

• Develop the initial ConOps, review it with the broader group of stakeholders, and iterate - Incrementally create the ConOps, review relevant portions with stakeholders, and adjust the concept as necessary to get buy-in. All stakeholders do not have to agree on every aspect of the project, but all must feel that they are achieving their major goals for the project.

  Portions of the ConOps can often be created from existing documents. For example, the regional ITS architecture identifies stakeholder roles and responsibilities that can be used. A feasibility study, project study report, or other preliminary study documentation may provide even more relevant information. A project application form used to support project programming will normally include goals, objectives, and other information that should be reflected in the ConOps for continuity.

  Operational scenarios are an excellent way to work with the stakeholders to define a ConOps. Scenarios associated with a major incident, a work zone, or another project-specific situation provide a vivid context for a discussion of the system's operation. It is common practice to define several scenarios that cover normal system operation (the "sunny day" scenario) as well as various fault-and-failure scenarios.

• Define stakeholder needs – Actually, this is a key purpose of the ConOps – to capture a clear definition of the stakeholders' needs and constraints that will support system requirements development in the next step. Interviews, workshops, and surveys are some of the techniques that are used to perform this activity. The ConOps is a great tool for defining needs since it forces the stakeholders to think about the way the system will behave and how it will interact with users and other systems. The operational scenarios in the ConOps are among the best tools for discovering needs. The list of needs that is generated should be prioritized by the stakeholders. Once they start to compare and rank the needs, they will discover that some of their "needs" are really "wants" or "nice-to-haves".
• Create a System Validation Plan – The initial performance measures that are identified in the ConOps provide a foundation for the System Validation Plan. While expectations for the system will change over time, the performance measures outlined in the ConOps force early consideration and agreement of how system performance and project success will be measured. Examples of performance measures include travel time, incident duration, and level of service. You should define a set of performance measures that will assess the effectiveness of the system you are implementing.

  A System Validation Plan is prepared that defines the consensus validation approach and performance measures. As with the ConOps, all affected stakeholder organizations should formally approve the System Validation Plan at this early stage so that downstream, all will agree on when they can "declare victory" that the new system is the right system. The plan will be finalized during system validation (see Section 4.9.2).

4.3.3 Output

The ConOps should be an approachable document that is relevant to all project stakeholders, including system operators, maintainers, developers, owners/decision makers, and other transportation professionals. The art of creating a good ConOps lies in using natural language and supporting graphics so that it is accessible to all while being technically precise enough to provide a traceable foundation for the requirements document and the System Validation Plan.

The ConOps is not a requirements document that lists the detailed, testable requirements for the system, nor is it a design document that specifies the technical design or technologies to be used. Resist the temptation to predetermine the solution in the ConOps – you should not unnecessarily preclude viable options at this early step. You also want to "keep it simple" and refrain from using formalized, highly structured English that is more suitable for the requirements and design specifications that follow.

Done right, the ConOps will be a living document that can be revised and amended so that it continues to reflect how the system is really operated. Later in the life cycle, an up-to-date ConOps can be used to define changes and upgrades to the system.

Two different industry standards provide suggested outlines for Concepts of Operations: ANSI/AIAA-G-043-1992 and IEEE Std 1362-1998, as shown in Figure 13. Both outlines include similar content, although the structure of the IEEE outline lends itself more to incremental projects that are upgrading an existing system or capability. The ANSI/AIAA outline is focused on the system to be developed, so it may lend itself more to new system developments where there is no predecessor system. Successful ConOps have been developed using both outlines. Obtain a copy of both, and make your own choice if you need to develop a ConOps.

Figure 13: Industry-Standard Outlines for Concept of Operations

Graphics should be used to highlight key points in the ConOps. At a minimum, a system diagram that identifies the key elements and interfaces and clearly defines the scope of the project should be included. Tables and graphics can also be a very effective way to show key goals and objectives, operational scenarios, etc.

The Rule/Policy requires identification of participating agency roles and responsibilities as part of the systems engineering analysis for ITS projects. It also requires that the procedures and resources necessary for operations and management of the system be defined. These elements are initially defined and documented for the project as part of the ConOps. In the ANSI/AIAA standard outline, most of these elements fit under Chapter 3 (User-Oriented Operational Description). In the IEEE outline, the current system information is included in Chapter 3 and the proposed system information is in Chapter 5.

The System Validation Plan that is created during this step should describe how the final system will be measured to determine whether or not it meets the original intent of the stakeholders as described in the ConOps. (For further details and examples, see Section 4.9.)

4.3.4 Examples

Many Concepts of Operations have been generated for all types of ITS projects in the last five years. Excerpts from a few examples are included here to show some of the ways that key elements of the ConOps have been documented for ITS projects following the sequence from the ANSI/AAIA outline.

User-Oriented Operational Description (Roles and Responsibilities)

Typically, roles and responsibilities are documented as a list or in tabular form. Table 5 is an excerpt of a table from the California Advanced Transportation Management System (CATMS) ConOps that is structured to show shared responsibilities and to highlight coordination points between the different system stakeholders. This early documentation of "who does what" grabs the stakeholders' attention and supports development of system requirements and operational agreements and procedures in future steps.

Table 5: Roles and Responsibilities (Excerpt from CATMS Concept of Operations)

System Overview

The system overview is typically supported by one or more diagrams that show the scope, major elements, and interrelationships of the system. Many types of diagrams can be used, from simple block diagrams to executive-level graphics-rich diagrams. Figure 14 is an example of a high-level graphic that includes basic process flow information, roles and responsibilities, and interfaces, providing an "at a glance" overview of the major facets of the system.

Figure 14: Example of System Overview Graphic
(from Communicating with the Public Using ATIS During Disasters Concept of Operations)

Operational Scenarios

In operational scenarios, the ConOps takes the perspective of each of the stakeholders as different scenarios unfold that illustrate major system capabilities and stakeholder interactions under normal and stressed (e.g., failure mode) circumstances. The stakeholders walk through the scenario and document what the agencies and system would do at each step.

Figure 15 shows an example of a scenario that includes some realistic detail that help stakeholders immerse themselves in the scenario and visualize system operation. This is one of five scenarios that were developed for the City of Lincoln StarTRAN AVL system to show the major system capabilities and the interactions between the AVL system and its users and other interfacing systems.

Figure 15: Operational Scenario Description¹¹

4.4 System Requirements

In this step: The stakeholder needs identified in the Concept of Operations are reviewed, analyzed, and transformed into verifiable requirements that define what the system will do but not how the system will do it. Working closely with stakeholders, the requirements are elicited, analyzed, validated, documented, and baselined.

4.4.1 Overview

One of the most important attributes of a successful project is a clear statement of requirements that meet the stakeholders' needs. Unfortunately, creating a clear statement of requirements is often much easier said than done. The initial list of stakeholder needs that are collected will normally be a jumble of requirements, wish lists, technology preferences, and other disconnected thoughts and ideas. A lot of analysis must be performed to develop a good set of requirements from this initial list.

Figure 16: Requirements Engineering Activities

EIA-632¹² defines requirement as "something that governs what, how well, and under what conditions a product will achieve a given purpose." This is a good definition because it touches on the different types of requirements that must be defined for a project. Functional requirements define "what" the system must do, performance requirements define "how well" the system must perform its functions, and a variety of other requirements define "under what conditions" the system must operate. Requirements engineering covers all of the activities needed to define and manage requirements that are shown in Figure 16.

Specify What, Not How. Be sure to keep the definition of a requirement in mind as you develop your system requirements. Many requirements documents contain statements that are not requirements. One of the most common pitfalls is to jump to a design solution and then write "requirements" that define how the system will accomplish its functions. Specify what the system will do in the system requirements, and save how the system will do it for the system design step.

It is important to involve stakeholders in requirements development. Stakeholders may not have experience in writing requirements statements, but they are the foremost experts concerning their own requirements. The project requirements ultimately are the primary formal communication from the system stakeholders to the system developer. The project will be successful only if the requirements adequately represent stakeholders' needs and are written so they will be interpreted correctly by the developer.

In the effort to get stakeholders involved, make sure you don't sour them on the project by making unreasonable demands on their time or putting them in situations where they can't contribute. Many nontechnical users have been subjected to stacks of detailed technical outputs that they can't productively review. Sooner or later, the user will wave the white flag in this situation and become unresponsive. You must (1) pick your stakeholders carefully and (2) make participation as focused and productive as possible.

The Requirements step is an important one that you shouldn't skimp on. Every ITS project should have a documented set of requirements that are approved and baselined. Of course, this doesn't mean that a new requirements specification must be written from scratch for every project. Projects that enhance or extend an existing system should start with the existing system requirements. This doesn't have to be a particularly large document for smaller ITS projects. The system requirements specification for a recent website development project was less than 20 pages.

4.4.2 Key Activities

There isn't one "right" approach for requirements development. Different organizations develop requirements in different ways. Even in the same organization, the requirements development process for a small ITS project can be much less formal than the process for the largest, most complex ITS projects. The differences are primarily in the details and in the level of formality. All requirements development processes should involve elicitation, analysis, documentation, validation, and management activities. Note that each of these activities is highly iterative. In the course of a day, a systems engineer may do a bit of each of the activities as a new requirement is identified, refined, and documented.

• Elicit requirements – Building on the stakeholders' needs and other inputs, such as the functional requirements from the regional ITS architecture and any relevant statutes, regulations, or policies, define a strawman set of system requirements and review and expand on them, working closely with the project stakeholders. There are many different elicitation techniques that can be used, including interviews, scenarios (see discussion under Concept of Operations in Section 4.3), prototypes, facilitated meetings, surveys, and observations. These techniques can be used in combination to discover the stakeholders' requirements.

  Elicit and elicitation are words you may not run into every day. Elicit means to draw forth or to evoke a response. This is the perfect word to use in this case because you will have to do some work to draw out the requirements from the stakeholders and any existing documentation. More work is implied by "elicit requirements" than if we said "collect requirements" or even "identify requirements", and this is intended.

  Make sure that you have the right stakeholders involved. This means not only the right organizations but also the right individuals within them. For example, it isn't enough to engage someone from the maintenance organization – it should be an electrical maintenance person who has experience with ITS equipment maintenance for ITS projects. Furthermore, as we move through the steps in the process and the products become more technical, different stakeholders may be involved. Managers may be more involved in the Concept of Operations, while technical staff will be more involved in review of the system requirements and high-level design. Finding individuals with the right combination of knowledge of current operations, vision of the future system, and time to invest in supporting requirements development is one of the key early challenges in any requirements development effort.

  There are many techniques for working with stakeholders to get to the fundamental requirements of the system. The Florida SEMP¹³ highlights one of the best and simplest techniques – the "Five Whys" – that was popularized by Toyota in the 1970s. Using the Five Whys technique, you look at an initially stated need and ask "Why?" repeatedly, not unlike a curious four-year-old, until you find the real underlying requirements. The dialog in Table 6 is an example that is based on an actual conversation.

  Table 6: The "Five Whys" Technique in Action

  Stakeholder	Systems Engineer
  I need irrigation channels on my keyboard.	Why?
  I occasionally spill coffee on the keyboard.	Why?
  I need to have three or four manuals open to operate the system and the coffee just gets knocked over.	Why do you need to have three or four manuals open?
  ...	...
  The dialog continues as the systems engineer discovers several different underlying needs that will drive environmental requirements, human factors/workspace requirements, and user interface requirements, all by pursuing the initial stated need for "irrigation channels".

  Of course, you sometimes need to direct the conversation by asking more than "why" to use this technique effectively. In the example, the conversation could easily have veered off to a discussion of the user's love for Starbucks coffee. Five iterations is a good rule of thumb, but it may take fewer or more iterations – the idea is to be persistent until you get to the core issues. Note also that the dialog can be internal – the stakeholder could have sat down and asked herself "Why", using the same technique to get at her underlying needs.

  As you gather the requirements, be sure to look beyond the operational requirements for the system and cover the complete life cycle (system development, deployment, training, transition, operations and maintenance, upgrades, and retirement) as well as requirements such as security and safety. More than one ITS project has failed because the security requirements of public safety stakeholders were not captured and reflected in the ITS project requirements. A good system requirements template can be used as a checklist to help ensure that all types of requirements are considered.

  The best way to start writing requirements is to use just two words: a verb and a noun. For example, the user requirement "monitor road weather conditions" would yield system requirements such as "shall detect ice", "shall monitor wind speed", and "shall monitor pavement temperature". Performance requirements would define the different kinds of ice conditions and the range of wind speeds and pavement temperatures.

• Analyze requirements – The requirements are analyzed in detail, and the stakeholders negotiate to prioritize them. This is where the requirements are cleaned up: conflicts are resolved, gaps are identified and addressed, ambiguity and redundancy are removed, and the requirements are organized and decomposed into more detailed requirements. Several levels of requirements are developed, providing sufficient granularity so that they can be allocated to individual subsystems and components in the next step, high-level design.

  Requirements are normally defined in a requirements hierarchy in which the highest-level "parent" requirements are supported by more detailed "child" requirements. A hierarchy allows you to start with high-level requirements and work your way down to the details. The highest-level requirements should trace to stakeholder needs in the Concept of Operations. A hierarchy is a useful organizational structure that makes it easier to write and review requirements and to manage the requirements development activity. An example of a requirements hierarchy is given in Figure 17.

  

  Figure 17: Example of Hierarchy of High-Level and Detailed Requirements

  For larger systems, it can be very difficult to "get your arms around" all of the requirements. Requirements modeling tools provide a graphic way to define requirements so that they are easier to understand and analyze. These tools are particularly useful for more complex ITS projects. There are numerous requirements modeling tools and techniques available that can help you model the system as part of the analysis process. INCOSE maintains a data repository of available modeling tools that is available on its website¹⁴.

  A model is a representation of something else. There are physical models, like the scale model of a train, and more abstract models, like an architectural plan for a new building. Many different models of the system to be built can be created and used as part of the systems engineering process. During requirements analysis, logical models are used that describe what the system will do. Later, during system design, physical models are created that show how the system will be implemented.

  Requirements modeling is an iterative process. Draft models can be developed early in the process based on the Concept of Operations and the regional ITS architecture. These models are refined as they are used to support requirements elicitation and walkthroughs, keeping bounds on the system and reducing requirements creep.

• Document requirements – The requirements are documented in a well-organized, approachable fashion so that the stakeholders and system development team can all easily understand and review them. Typically, a combination of plain language and diagrams are used to define the requirements.

  The requirements documentation should include more than requirements. There are many different attributes that should be tracked for each requirement. A rich set of attributes is particularly important for large, complex projects. If you are developing such a project, consider specifying the following for each requirement: requirement number, source, author, creation date, change history, verification method, priority, and status. The historical and change-tracking attributes are particularly important since they allow management to measure and track requirements stability.

  Traceability is another important aspect of requirements documentation. Each requirement should trace to a higher-level requirement, a stakeholder need, or other governing rules, standards, or constraints from which the requirement is derived. As the system is developed, each requirement will also be traced to the test case that will verify it, to more detailed "child" requirements that may be derived from it, and to design elements that will help to implement it. Establish and populate the Traceability Matrix at this stage, and continue to populate it during development. The Traceability Matrix is a vital document that is maintained to the end of project development, allowing traceability from user needs to the system components, verification, and validation.

• Validate requirements – The documented requirements are carefully checked for consistency, accuracy, and completeness. This is a critical step that is intended to identify requirement defects as early in the process as possible, when correcting them is most economical. To support validation, requirements walkthroughs are held to review the requirements in a systematic way with the project stakeholders and project team.

  You will see "validation" used in a few different contexts in systems engineering. Here in requirements validation, you make sure that the requirements are correct and complete. Later, in system validation (discussed in Section 4.9), you make sure that you have built the right system. In fact, the requirements validation that is performed here will ultimately help to make sure that the system validation is successful in the end.

  A walkthrough is a technique in which a review team steps through a deliverable (e.g., requirements, design, or code) looking for problems. A walkthrough should be relatively informal and "blame free" to maximize the number of problems that are identified. A requirements walkthrough should be attended by the people that have a vested interest in the requirements. For a large project, this might include the requirements author, customer, user representative(s), implementers, and testers.

  Table 7 identifies an oft-repeated list of attributes of good requirements. As part of the validation process, you do your best to make sure that the requirements have all of these desired attributes. Unfortunately, computers can do only a fraction of this validation and people have to do the rest. Techniques for validating a requirement against each of these quality attributes are also shown in Table 7. An attribute list like this can be converted into a checklist that prompts reviewers to ask themselves the right questions as they are reviewing the requirements.

  Table 7: Validating Quality Attributes of Good Requirements

  Quality Attribute	Validate by:
  Necessary	Make sure that each requirement traces to either a stakeholder need in the ConOps or a parent requirement. A computer can check that the traceability is complete, but people have to verify that the identified traces are valid.
  Clear	Some requirements management tools can help with this by looking for red-flag words and constructs in the requirements (e.g., "user friendly", "optimum", "real-time", pronouns, and complex sentences). Most of this aspect of validation relies on walkthroughs and other reviews to make sure the requirements aren't subject to different interpretations. The main culprit here is ambiguity in the English language.
  Complete	Does every stakeholder or organizational need in the ConOps trace to at least one requirement? If you implement all of the requirements that trace to the need, will the need be fully met? A computer can answer the first question, but only stakeholder(s) can answer the second.
  Correct	In general, it takes a walkthrough to verify that the requirements accurately describe the functionality and performance that must be delivered. The stakeholders must validate that the highest-level system requirements are correct. Traceability can assist in determining the correctness of lower-level requirements. If a child requirement is in conflict with a parent requirement, then either the parent or the child requirement is incorrect.
  Feasible	Again, this must be determined by review and analysis of the requirements. A computer can help with the analysis and possibly even flag words like "instant" or "instantaneous" that may be found in infeasible requirements, but a person ultimately makes the judgment of whether the requirements are feasible. In this case, it is the developer who can provide a reality check and identify requirements that may be technically infeasible or key cost drivers early in the process. Since system performance is dependent on system design and technology choices, requirements feasibility will continue to be monitored and addressed as the system design is developed.
  Verifiable	Does the requirement have a verification method assigned? (This is something a computer can check.) Is the requirement really stated in a way that is verifiable? (This much more difficult check can only be performed by people.) For example, ambiguous requirements are not verifiable.

   
• Manage requirements – Processes and tools are established to manage the requirements and associated information that is collected, track changes to the requirements, and provide facilities that support traceability, requirements retrieval and reporting, etc. (See Section 5.4 for more information on configuration management techniques that should be used on the requirements baseline.)

  Every ITS project should have a tool that helps to manage the requirements baseline. More complex ITS projects will benefit from a tool specifically for requirements management such as DOORS or Requisite-Pro.¹⁵ A professional requirements management tool is expensive, but it includes a long list of capabilities including change management, requirements attributes storage and reporting, impact analysis, requirements status tracking, requirements validation tools, access control, and more.

  Like the other requirements engineering activities, the requirements management capabilities should be scaled based on the complexity and size of the ITS project. Requirements for smaller ITS projects can be managed easily and effectively by a single engineer using a general purpose tool like Microsoft Access or Excel.

• Create a System Verification Plan – As the requirements are documented, a plan for verifying the system based on the requirements is defined. This is extremely important because only verifiable requirements should find their way into the system requirements document. A verification method is identified for every requirement – normally, by one of four ways: Test, Demonstration, Inspection, or Analysis. The purpose of this early assignment of a method, long before the requirements will actually be verified, is to make sure that the requirements author thinks about how the requirement will be verified from the very start. (See Section 4.7 for more information on System Verification.)
   
• Create a System Acceptance Plan – A plan should be created that describes the functionality the new system must successfully display prior to acceptance by the customer; consensus by all parties on the contents of this plan should be reached early in the life cycle.

4.4.3 Outputs

No matter how you developed your requirements, you must document them in some consistent, accessible, and reviewable way. The requirements development process may result in several different levels of requirements over several steps in the "V" – stakeholder requirements, system requirements, subsystem requirements, etc. – that may be documented in several different outputs. For example, stakeholder requirements might be documented in a series of Use Cases; system requirements, in a System Requirements Specification; and subsystem requirements, in subsystem specifications. All of these requirements should be compiled in a single repository that can be used to manage and publish the requirements specifications at each stage of the project.

It is much easier to use a standard template for the requirements specifications than it is to come up with your own, and numerous standard templates are available. If your organization does not have a standard requirements template, you can start with a standard template like the one contained in IEEE Standard 830 (for software requirements specifications) or IEEE Standard 1233 (for system requirements specifications). Starting with a template saves time and ensures that the requirements specification is complete. Of course, the template can be modified as necessary to meet the needs of the project.

The system requirements specification should fully specify the system to be developed and should include the following information:

• System boundary with interfacing systems clearly identified
• General system description, including capabilities, modes, and users, as applicable
• External interface requirements for interfacing systems and people
• Functional requirements and associated performance requirements
• Environmental requirements
• Life-cycle process requirements supporting development, qualification (e.g., test, verification, validation, and acceptance), production, deployment, transition, operations and maintenance, change and upgrade, and retirement/replacement, as applicable
• Reliability and availability
• Expandability
• Staffing, human factors, safety, and security requirements; and
• Physical constraints (such as weight and form factors).

As you read through this list, you may recognize that some of this information has already been collected and documented in previous steps, and there is no need to recreate it here. Refer back to the Concept of Operations that already contains a description of the system boundary, the system itself, and other items in this list.

A System Verification Plan, describing the approach for verifying each and every system requirement, and a System Acceptance Plan, describing the capabilities that must function successfully for customer acceptance, should be created, reviewed, and approved.

4.4.4 Examples

Stakeholder Requirements

The Oregon DOT TripCheck project developed a User Functional Requirements Specification, which lists the user requirements for the redesigned TripCheck website. The excerpt from this document in

Table 8 shows several user requirements for the website autorouting function. As shown, every requirement is prioritized on a scale from 1 ("must have") to 4 ("don't implement") and is related to different types of end users – Commuters (C), Inter-City Travelers (ICT), Tourist Travelers (TT), ADA Travelers (ADA), and Commercial Truckers (CT). These prioritized user requirements were used by the contractor to support Use Case modeling and to define system requirements.

Table 8: ODOT TripCheck User Requirements (Excerpt)

Note that stakeholder requirements that are collected through the requirements elicitation process are likely to have a few imperfections. The key is to document the stakeholder requirements, make them as clear and succinct as possible, prioritize them, and then use them to develop more formally stated system requirements.

System Requirements

The Maryland CHART II system is a statewide traffic management system that has been operational since 2001. The CHART program maintains a website that provides all of the CHART documentation at http://www.chart.state.md.us, including a comprehensive system requirements document. A few of the system requirements for the equipment inventory and report generation functions are shown in Table 9.

Table 9: CHART II System Requirements (Excerpt)

Traceability Matrix

Table 10 is a typical traceability matrix that would be maintained and populated throughout the project development process. The matrix may be maintained directly in a database or spreadsheet for small projects or generated and maintained with a requirements management tool for more complex projects. Using either approach, the matrix provides backwards and forwards traceability between stakeholder needs (and other potential requirements sources), system requirements, design, implementation, and verification test cases. As shown, only the unique identifiers (e.g., UN1.1) are actually included in the traceability matrix so you don't have to keep many instances of the actual text up-to-date. Note also that the design and implementation columns would not actually be completed until later in the process.

Table 10: Sample Traceability Matrix

4.5 System Design

In this step: A system design is created based on the system requirements including a high-level design that defines the overall framework for the system. Subsystems of the system are identified and decomposed further into components. Requirements are allocated to the system components, and interfaces are specified in detail. Detailed specifications are created for the hardware and software components to be developed, and final product selections are made for off-the-shelf components.

4.5.1 Overview

In the systems engineering approach, we define the problem before we define the solution. The previous steps in the "V" have all focused primarily on defining the problem to be solved. The system design step is the first step where we focus on the solution. This is an important transitional step that links the system requirements that were defined in the previous step with system implementation that will be performed in the next step, as shown in Figure 18.

Figure 18: System Design is the Bridge from Requirements to Implementation

There are two levels of design that should be included in your project design activities:

High-level design is commonly referred to as architectural design in most systems engineering handbooks and process standards. Architectural design is used because an overall structure for the project is defined in this step. IEEE 610¹⁶ defines architectural design as "the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system". Of course, ITS projects may include several computer systems, a communications network, distributed devices, facilities, and people. High-level design defines a framework for all of these project components.

Detailed design is the complete specification of the software, hardware, and communications components, defining how the components will be developed to meet the system requirements. The software specifications are described in enough detail that the software team can write the individual software modules. The hardware specifications are detailed enough that the hardware components can be fabricated or purchased.

Many consider design to be the most creative part of project development. Two different designs might both meet the system requirements, but one could be far superior in how efficiently it can be developed, integrated, maintained, and upgraded over time. Perhaps the most significant contributor to a successful design is previous design experience with similar systems. The latest car designs all build on 100 years of accumulated automotive design experience. Similarly, the design of a new transportation management system should build on existing successful transportation management system designs. In both cases, the system designer builds on knowledge of what worked before and, perhaps even more importantly, what did not.

It is extremely rare to find an ITS system that is truly "unprecedented", so many if not most system designs should be able to build on existing design information. This is particularly true for projects that are extending an existing system that already includes a well- documented design. In this case, the high-level design will change only to the degree that new functionality or interfaces are added. Similarly, much of the detailed design can be reused for projects that extend the coverage of an existing system.

4.5.2 Key Activities

System design is a cooperative effort that is performed by systems engineers and the implementation experts who will actually build the system. The process works best when there is a close working relationship among the customer, the systems engineers (e.g., a consultant or in-house systems engineering staff), and the implementation team (e.g., a contractor or in-house team).

High-Level Design

High-level design is normally led by systems engineers with participation from the implementation experts to ensure that the design is implementable. Typical activities of high-level design are shown in Figure 19. Each of the activities are actually performed iteratively as high-level design alternatives are defined and evaluated.

Figure 19: High-Level Design Activities

• Evaluate off-the-shelf components - One key aspect of high-level design is the identification of components that will be purchased, reused, or developed from scratch. The project may be required to use off-the-shelf hardware or software, or this may simply be the preferred solution. Specific design constraints may also require that a particular product be used. For example, a municipality that is expanding a signal control system that already includes 300 Type 170 controllers may constrain the design of the expansion to use the same controllers to facilitate operation and maintenance of the overall system. State DOTs and other large agencies often publish approved products lists that identify ITS-related products that meet agency specifications.

  When off-the-shelf components will be used, the high-level design must be consistent with the capabilities of the target products. The designer should have an eye on the available products as the high-level design is produced to avoid specifying a design that can be supported only by a custom solution. A particular product should not be specified in the high-level design unless it is truly required. When possible, the high-level design should be vendor and technology independent so that new products and technologies can be inserted over time.

  You should give off-the-shelf hardware and software serious consideration and use it where it makes sense. The potential benefits of off-the-shelf solutions – reduced acquisition time and cost, and increased reliability – should be weighed against the requirements that may not be satisfied by the off-the-shelf solution and potential loss of flexibility. If you have requirements that preclude off-the-shelf solutions, determine how important they are and what their real cost will be. This make/buy evaluation should be documented in a summary report that considers the costs and benefits of off-the-shelf and custom solution alternatives over the system life cycle. This report should be a key deliverable of the project.

  Also recognize that there is a large grey area between off-the-shelf and custom software for ITS applications. Every qualified software developer starts with an established code base when creating the next "custom solution", accruing some of the benefits of off-the-shelf solutions. Many vendors of off-the-shelf solutions offer customization services, further blurring the distinction between off-the-shelf and custom software.

  The FHWA report The Road to Successful ITS Software Acquisition includes a good discussion of software make/buy decision factors and a lot of other good information on software acquisition for ITS. The executive summary for the report is available at www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/36s01!.pdf.

• Develop and evaluate high-level design alternatives - The system is partitioned into subsystems, and the subsystems are in turn partitioned into smaller assemblies. The process continues until system components – the elemental hardware and software configuration items – are identified. Figure 20 shows a partial decomposition of an electronic toll collection system that identifies all of the major subsystems and the components for the Video Enforcement subsystem.

  

  Figure 20: Electronic Toll Collection Subsystems and Components (Excerpt)

  
  

  There are many different ways that a system can be partitioned into subsystems and components. In this Electronic Toll Collection example, we might consider whether the Clearinghouse Processing subsystem should be handled by a single centralized facility or distributed to several regional facilities. As another example, vehicle detectors could be included in the Video Enforcement subsystem or in the Tag Reader subsystem, or both.

  Even a relatively simple traffic signal system has high-level design choices. For example, a traffic signal system high-level design can be two-level (central computer and local controllers), three-level (central computer, field masters, and local controllers), or a hybrid design that could support either two or three levels. High-level design alternatives like these can have a significant impact on the performance, reliability, and life-cycle costs of the system. Alternative high-level designs should be developed and compared with respect to defined selection criteria to identify the superior design.

  The selection criteria that are used to compare the high-level design alternatives include consistency with existing physical and institutional boundaries; ease of development, integration, and upgrading; and management visibility and oversight requirements. One of the most important factors is to keep the interfaces as simple, standard, and foolproof as possible. The selection criteria should be documented along with the analysis that identifies the superior high-level design alternative that will be used. If there are several viable alternatives, they should be reviewed by the project sponsor and other stakeholders.

  The Rule/Policy requires the systems engineering analysis for ITS projects to include an analysis of alternative system configurations.

• Analyze and allocate requirements - The requirements analysis described in Section 4.4.2 continues as the requirements are decomposed until there is enough granularity to allocate requirements to the system components identified in the high-level design.

  The detailed functional requirements and associated performance requirements are allocated to the system components. To support allocation, the relationships between the required system functions are analyzed in detail. Once you understand the relationships between functions, you can make sure that functions that have a lot of complex and/or time-constrained interactions are allocated to the same component as much as possible. Through this process, each component is made as independent of the other components as possible.

  You would not want to develop a high-level design and requirements allocation for a complex ITS project without software tools. Fortunately, there are many good tools that support both requirements analysis and architectural design. The INCOSE tools database, available to nonmembers free of charge at www.incose.org, includes a broad range of systems engineering tools and a detailed survey of tools that support requirements management and system architecture.

• Document the interfaces and identify standards – Interfaces should be identified early, fully documented, and then managed throughout the project development. Interface specifications should be developed for external interfaces (i.e., interfaces between the current project and external systems) and internal interfaces (i.e., interfaces between project components). Interfaces between systems that are owned and operated by different agencies may require additional lead time to negotiate interface agreements.

  This is the place to identify ITS standards and any other industry standards that will be used in detail. There are a variety of standards that should be considered at this point. Take a look at all interfaces, both external and internal. Since your regional ITS architecture and/or project ITS architecture was based on the National ITS Architecture, many of the interfaces probably already have a set of ITS standards you should consider. You should also identify standards that are used in your region or state, and also in adjoining states if your project is a multistate deployment. A methodical assessment should be made for each interface to determine which standards are relevant, which standards should be deployed, and perhaps which standards should be phased in over time as part of a longer-range plan.

  Once you have taken a look at the relevant standards, beginning with your system's external interfaces, document the nature of the data, formats, ranges of values, and periodicity of the information exchanged on the interface. Then proceed to each of the internal interfaces and document the same information for those.

  Agencies are encouraged to incorporate the ITS standards into new systems and upgrades of existing systems. The Rule/Policy requires the systems engineering analysis for ITS projects to include an identification of ITS standards. Consult the ITS Standards Program website at http://www.standards.its.dot.gov/ for more information and available resources supporting standards implementation.

• Create Integration Plan, Subsystem Verification Plans, and Subsystem Acceptance Plans – An Integration Plan, Subsystem Verification Plans, and Subsystem Acceptance Plans should be completed parallel with the high-level design. (See Section 4.7 for more information on integration and verification planning.)

Detailed Design

Hardware and software specialists create the detailed design for each component identified in the high-level design. Systems engineers play a supporting role, providing technical oversight on an ongoing basis. As you might expect, the detailed design activity will vary for off-the-shelf and custom components, as shown in Figure 21.

Figure 21: Detailed Design Activities

• Prototype user interface - If a user interface is to be developed, a simple user interface prototype is an efficient way to design it.

  A prototype is a quick, easy-to-build approxi-mation of a system or part of a system. A software prototype can be used to quickly implement almost any part of a system that you want to explore, but it is used most often to make a quick approximation of a user interface for a new system.

  A user interface prototype should be employed to help the user and developer visualize the interface before significant resources are invested in software development. This is one area in particular where you can expect multiple iterations as the developers incrementally create and refine the user interface design based on user feedback. (You will find that it is often easier to get users to provide feedback on a prototype than on system requirements and design specifications, which can be tedious to review.)

  While the user interface prototype is included here because it is an effective way to design the user interface, prototypes may ac