#   Define High Level and Detailed Requirements

##  {#section .HB-Heading-2}

##  {#section-1 .HB-Heading-2}

##  {#section-2 .HB-Heading-2 .unnumbered}

##  Purpose of this Chapter {#purpose-of-this-chapter .HB-Heading-2 .unnumbered}

> This chapter describes the activities and considerations specific to
> migration projects that occur during the requirements development
> phase.

1.  Requirements Activities Defined

As shown in , once the key project goals and objectivesnare described in
the concept of operations, requirements can be developed that link to
those project goals and objectives. Although the Vee implies a somewhat
linear system engineering process, there is likely an interaction
between each step that results in "going backwards up the Vee". In other
words, project managers should anticipate that the concept of operations
may chang, based on the requirements development process.

The following provides an overview and definition of the typical
activities conducted during the requirements elicitation and definition
phase of the systems engineering process. Good resources for
requirements development include:

-   [*Developing Functional Requirements for Intelligent Transportation
    Systems*](http://www.mitretek.org/ITS_guide_to_management.doc),
    April 2002. (FHWA-OP-02-046)

-   IEEE Standard 1233:1998, *IEEE Guide for Developing System
    Requirements Specifications*.(outline for a requirements document is
    provided in this report, below)

In addition, overall systems engineering advice is available from the
International Council on Systems Engineering website (INCOSE.org).

The requirements development process includes eliciting, analyzing and
documenting high level requirements, and decomposing the high-level
requirements into detailed requirements (with associated analysis and
documentation). Elicitation of requirements is the focus of this
chapter. Analysis of requirements helps ensure that the requirements are
complete and meet the users' needs. The analysis process is not
addressed in this document. The above resources supply additional
information on requirements decomposition and analysis.

Documentation is addressed in the chapter on cross-cutting activities
under configuration management.

![](media/image1.wmf){width="6.003472222222222in"
height="4.645138888888889in"}

> Figure ‎4‑1: Systems Engineering "V" Diagram\
> (High Level and Detailed Requirements Step Highlighted)

4.1.1 Elicit Requirements

Requirements elicitation is often considered the most important step in
the systems engineering process. Information gathered during
requirements elicitation often has to be interpreted, analyzed, modeled
and validated before a complete set of systems requirements is
generated.

One of the most important goals of elicitation is to find out what
problems need to be solved, and therefore identify system boundaries.
These boundaries define, at a high level, where the final delivered
system will fit into the current operational environment. Identifying
and agreeing upon a system's boundaries affects all subsequent
elicitation efforts.

The techniques used to elicit stakeholder needs and requirements include
the following:

-   Literature search: Review existing documents to develop a
    background.

-   Day-in-the-life studies: Spend time with key stakeholders to
    document what tasks they perform and how they do them.

-   Surveys: Carefully design and administer surveys to collect
    information and opinions regarding priorities and needs.

-   One-on-one interviews. Examine perspectives of individual
    stakeholders.

-   Workshops: Facilitate discussion and consensus by presenting
    stakeholders with collected information and identified issues.

### 4.1.2  {#section-3 .HB-Heading-3 .unnumbered}

### Define Requirements {#define-requirements .HB-Heading-3 .unnumbered}

Requirements development is a set of activities that will produce
requirements for the system and its subsystems. What is a requirement?
The definition from the systems engineering standard (EIA 632) is
"Something that governs what, how well, and under what conditions a
product will achieve a given purpose." Simply stated, requirements
define the functions, performance and environment of the system under
development to a level that can be built. There are several types of
requirements:

Functional Requirements --What is the System Supposed to Do?

Functional requirements define the specific functionality that must be
built into systems and software to allow users to complete desired
tasks. These requirements include required inputs, outputs, states, and
transformation rules. The functional requirements will eventually be
reflected in the system specification.

Performance Requirements -- How Well Does the System do its Functions?

Performance requirements specify the minimum performance requirements
the system must provide under various operational scenarios. These
requirements are generally measured in terms of quantity, quality,
coverage, timeliness, or readiness.

**Interface Requirements -- How** **Will** **the** **Parts of the**
**System** **Work Together?**

Interface requirements are concerned with making the pieces of a system
desirably connect and interoperate with other parts of the system and
with external systems. Interface requirements also include assuring that
system interfaces are able to accept new features.

**Enabling Requirements -- What Do I Need to** **Accomplish the**
**Project?**

Enabling requirements define other aspects of systems development that
are needed but do not show up as part of the final delivered system.
Enabling requirements are often overlooked in requirements development
process.

-   Development -- What is needed in terms of a development suite or lab
    environment? Is there a constraint on the location or time frame for
    development?

-   Testing -- What is required to support testing? This is not the
    actual test requirements; rather, it would indicate conditions for
    testing such as use of simulators or actual deployment testing.

-   Deployment -- These requirements define the transition between the
    old and new systems, and any constraints that affect the actual
    system deployment.

-   Support -- What additional support will be needed from the system
    developers? Will there also need to be testing software, simulators
    and other systems developed to be delivered with the new system?
    Will on-going support be needed after deployment?

-   Production -- These requirements relate to items that are produced
    in larger quantities, and may address the production environment,
    qualifications of workers and the like.

-   Training -- What types of training (live, on-site, on-line) and
    support materials (manuals) will need to be provided?

-   Disposal -- How will by-products of development and/or components
    that are being replaced be disposed of upon completion of the
    project?

**The importance of a well-developed set of requirements for any
systems/software project cannot be overstated. Readers are encouraged to
review other sources of information on requirements engineering.** This
guide book does not provide detail on how to develop good requirements.
Rather, the reader is referred to other guidance and the FHWA report
titled **"Developing Functional Requirements for ITS Projects**" states
that well-written functional requirements should have the following
characteristics:

-   Necessary -- Only the essential parts of the target system should be
    defined as a detailed requirement. In other words a detailed
    requirement should not be defined if it is not needed or desired.
    Likewise, if a critical part of the system is missing, a detailed
    requirement should be written to compensate for its absence.

-   Concise -- Detailed requirements should be written so that they are
    clear, and easy to understand. They should be straight to the point
    and have enough information so their intent is easy to understand.

-   Attainable -- Detailed requirements must be feasible. Requirements
    that are not attainable should not be included in the target
    system's design.

-   Complete -- Detailed requirements should stand on their own, and
    need not have additional language to make them understandable.

-   Consistent -- Detailed requirements should not contradict or
    duplicate language embedded in other detailed requirements. In
    addition, terms to describe a part of a system should be used
    similarly throughout the description of the requirement.

-   Unambiguous -- Detailed requirements should be written in such a
    manner that reduces the possibility of alternate meanings.

-   Verifiable -- Once target systems have been implemented, it must be
    possible to determine whether the requirement has been met.

-   

-   

-   

-   

-   The overall requirements development process begins with high-level
    requirements that are further decomposed into detailed requirements.
    The detailed requirements are more precise in describing what the
    system will provide.

## Application to Migration Projects {#application-to-migration-projects .HB-Heading-2}

The success of an ITS migration project, like any other system/software
project, depends significantly on the ability of the migration team to
develop the detailed requirements for the target system.

Once again, the analogy of the migration project for a heart patient is
useful in understanding the requirements phase of the project.

The surgeon has already worked with the patient to establish the goals
and objectives of the heart treatment, high-level alternatives have been
explored, and a preferred approach selected. The surgeon will then
explore the functional, performance, interface and enabling requirements
for the surgery.

As with the concept of operations, the first step in the requirements
development process is to assemble the stakeholders. The user group is
represented by the patient alone in this analogy. He is supplemented by
various other "domain" experts -- the anesthesiologist, the internist,
the surgical nursing staff, the recovery team, and others as needed
depending upon whether the patient's other systems are of concern - to
help in the description of the surgery's requirements. Not only is the
outcome of the surgery addressed, but in the enabling requirements, the
actual surgery is also addressed.

e presents some examples of the various types of requirements for the
surgery. The development of the requirements requires bringing together
the user and "domain" experts -- that is, the patient and the medical
staff. All of the requirements noted below are high-level (not detailed)
requirements, and the list is not comprehensive. Although certainly
incomplete, the illustration should be useful to migration concept
understanding.

Table ‎4‑1: Examples of Various Types of Requirements\
using the Hypothetical Surgery Example

+--------------+-------------------------------------------------------+
| **           | -   The stent shall improve blood flow at the site of |
| Functional** |     the existing obstruction.                         |
| **Re         |                                                       |
| quirements** | -   The stent shall not rupture.                      |
|              |                                                       |
|              | -   The stent shall not collapse.                     |
|              |                                                       |
|              | -   The patient shall not be able to sense any        |
|              |     negative difference between his heart system with |
|              |     a stent and his heart system without a stent.     |
|              |                                                       |
|              | -   After healing, the patient will not experience    |
|              |     shortness of breath during normal activities.     |
+--------------+-------------------------------------------------------+
| **P          | -   The overall heart system will have an ejection    |
| erformance** |     fraction (the amount of blood pumped out of the   |
| **Re         |     heart with each beat) of at least 50%.            |
| quirements** |                                                       |
|              | -   The recovery period shall not exceed 3 days.      |
|              |                                                       |
|              | -   The stent will operate without blockage (if the   |
|              |     patient follows his drug, exercise and diet       |
|              |     regimen) for at least 3 years.                    |
+--------------+-------------------------------------------------------+
| **Interface  | -   Some interface requirements are internal to the   |
| Re           |     heart system:                                     |
| quirements** |                                                       |
|              |     -   The stent shall fuse to healthy veins.        |
|              |                                                       |
|              | -   Some interface requirements relate to systems     |
|              |     external to the heart system:                     |
|              |                                                       |
|              |     -   After healing, the heart with the stent will  |
|              |         provide blood circulation throughout the      |
|              |         complete venous system.                       |
+--------------+-------------------------------------------------------+
| **Enabling   | -   Development -- Will there be any "mock"           |
| Re           |     procedures performed to practice for the surgery? |
| quirements** |                                                       |
|              | -   Testing -- Will the stent be tested prior to      |
|              |     installation? How will the stent be tested before |
|              |     closing? How will it be tested after surgery?     |
|              |     What is the plan for those tests? What equipment  |
|              |     is needed? What are the test criteria?            |
|              |                                                       |
|              | -   Deployment -- Will the heart remain functioning   |
|              |     during the stent procedure? What are the          |
|              |     requirements for the entry site to begin the      |
|              |     stent implementation? What are the options if     |
|              |     there are other issues discovered during the      |
|              |     surgery that affect the goals of the surgery or   |
|              |     the patient as a whole (part of the outcome of a  |
|              |     risk assessment as described in the Cross-Cutting |
|              |     chapter)?                                         |
|              |                                                       |
|              | -   Support -- Defining the equipment and staff       |
|              |     needed to support the surgical procedure. What    |
|              |     are the requirements for the surgical room?       |
|              |                                                       |
|              | -   Training -- Define a post-operative treatment     |
|              |     plan.                                             |
|              |                                                       |
|              | -   Disposal -- How will all the waste products of    |
|              |     the surgery be disposed of? Which require special |
|              |     handling? If any item is removed, should it be    |
|              |     examined and documented before disposal?          |
|              |                                                       |
|              | -   What are the requirements for the surgical room   |
|              |     in terms of sterility, size, lighting,            |
|              |     heat/cooling, etc.?                               |
+--------------+-------------------------------------------------------+

-   

-   

-   

-   

-   

-   

-   

-   

-   

-   -   
    -   

The enabling requirements listed in Table ‎4-1 are the key requirements
that define the surgical process.

-   

-   

-   

-   

-   

-   

-   

-   Note that the surgeon has not yet defined (specified) the size or
    type of stent. That would be considered a design detail. Also note
    that there is a contingency plan, in case conditions discovered
    inside the patient are different from what the testing indicates
    prior to surgery. This is a key parallel with ITS migration
    projects, because existing systems can never be fully described or
    fully understood.

## What Is Different About Migration Projects That Affects The Requirements Development Stage? {#what-is-different-about-migration-projects-that-affects-the-requirements-development-stage .HB-Heading-2}

At this stage of the systems engineering process, it may seem that the
defining requirements for an ITS migration can follow that of a new
development completely -- because the focus of a requirements analysis
is on [what]{.underline} the target system should do, not
[how]{.underline} to do it. The "what" should be the same whether or not
there is an existing system -- right? In theory, this is correct.
However, the following pressures, many of which are encountered in the
concept of operations stage (and were described in the previous
chapter), come to bear on requirements development.

-   A strong focus on technology -- or a ready solution is the focus. As
    noted in chapter 3, there is often a technology solution in the
    user's mind when approaching a migration. Sometimes, the functional
    requirements are developed around a specific manufacturer's
    technology. The danger in this approach is that the operations
    needs, objectives and goals can be overshadowed by the technology.

-   A resistance to change, or an apparent inability to think beyond the
    functions of the legacy system. It is sometimes difficult to
    determine if issues in envisioning a target system arise from a
    resistance to change or an in ability to describe the current
    system. Sometimes users feel ownership in the existing system,
    including any work-arounds they may have developed to address
    various problems. The existing system must be understood to ensure
    that the strengths are preserved while the weaknesses are avoided.
    And, it is often difficult for users to describe their existing
    system functionality, because it is simply too obvious to them.
    Requirements elicitation in these cases poses additional challenges,
    but the elicitation techniques described in the next section can be
    helpful in working through such resistance. An example of the
    difficulties in defining requirements for a migration project is
    presented below. If the staff didn't have a DMS system with which to
    compare, the task would have been much more straightforward.

-   Functional requirements for the transition period must also be
    addressed. The decision regarding the need for parallel system
    operation (legacy and target system) should have been addressed
    previously in the concept of operations phase. At this point, the
    overall cut-over requirements should be outlined including how long
    parallel systems should be operated (if parallel systems are
    required), the time period and duration when systems can be out of
    operation, and the like.

-   

### 4.3.1  {#section-4 .HB-Heading-3 .unnumbered}

###  {#section-5 .HB-Heading-3 .unnumbered}

### Eliciting Requirements -- Considerations for ITS Migration {#eliciting-requirements-considerations-for-its-migration .HB-Heading-3 .unnumbered}

Requirements elicitation is the process of understanding systems and
software to identify requirements. One of the major difficulties in ITS
system migration is that there typically is little or no documentation
of the existing systems functional requirements from which to start or
use as a baseline. The baseline must be somehow reconstructed or
"reverse engineered". The extent to which an entire legacy system is
baselined will depend largely on the migration effort. The trade-off
between developing a complete system baseline and the target system
needs must be understood. The trade-off may not be well understood until
the design or even the implementation is underway. The pressure for
"push-back" and iteration of the steps in the Vee model is stronger in a
migration project than in a new implementation. That is, discoveries
made as the requirements, design, implementation and even testing phases
are accomplished may result in a need to revisit previous steps, even as
far back as the project concept of operations. The project staff must be
open to and prepared for the need for such changes. The likelihood that
requirements can be considered complete and "frozen" before moving on to
the subsequent stages of the system engineering process is never 100
percent. However, the pressure for change is even greater for migration
projects simply because there are so many unknowns. This requires an
aggressive change management process and approach be implemented, as
described in Chapter 8.

The key to all requirements elicitation processes is to maintain focus
on the operational needs. The process should allow for free expression
of ideas, concerns, constraints and desires. Comments that need to be
addressed later in the process can be noted as such. After any extensive
elicitation, all requirements should be tied back to operational needs
identified in the concept of operations. In systems engineering jargon,
this is known as traceability. If some requirements cannot be traced
back to identified needs, additional work must be done to determine if
they should be discarded, modified or if the needs should be reassessed.

It is important to keep in mind that the overall requirements
development process begins with high-level requirements that are further
decomposed into detailed requirements. It is generally best if this
process of decomposing requirements, or deriving detailed requirements,
be done cooperatively between the owner and the developer. This will
allow the detailed requirements to be developed with both the knowledge
of the desired functionality of the system and the technical approach to
be taken in the development. In a migration project, there may be
certain detailed requirements that will be known from the outset. These
requirements should be included in the initial development of
requirements, even though most requirements at that stage will be
high-level. There may be a temptation to develop all of the detailed
requirements at this stage because the users are familiar with the
system they have and the system they want. However, it is extremely
important to have the developer's input in the detailed requirements to
make sure that the users aren't inadvertently creating a more expensive,
less functional, or less flexible system.

There are several methods by which requirements may be elicited, and
each requires special consideration when working on ITS migrations
versus new systems, depending on the migration project needs and
complexities. These methods are bulleted below and described in the
following sections.

-   Revisiting User Needs.

-   Observations.

-   Using Existing Systems and Documentation.

-   Operational Scenarios.

-   Prototyping.

Revisiting User Needs

Several meetings should be conducted with users to confirm user's needs,
and to perform requirements walk-throughs. Reaching a common
understanding during this phase will be much less costly than if user
requirements have to be readdressed after systems and software have been
developed. Therefore, it is absolutely critical that practitioners work
with users to establish requirements that are clear, concise and
correct.

As with any development, it is important to conduct requirement
walk-throughs more than once over the course of a project. Typically, a
walk-through with stakeholders when high-level requirements are
developed is necessary. Then, when detailed requirements are derived or
conditions cause several requirements to be in need of change,
additional walk-throughs are appropriate.

It has been a common issue in migration projects that, because there is
an existing system in place, the ability to describe the requirements of
the target system is compromised. This is due to several factors. First,
the users of the existing system are so familiar with its functions that
they tend to overlook requirements that seem obvious to them. Another
common issue is the lack of baseline requirements for the legacy system.
Requirements may have to be constructed (reverse engineered) for the
legacy system at this stage. Without a baseline of requirements, it is
very difficult to understand what must be changed. Last, the existing
system may bias some users in that it will constrain their ability to
develop a set of target system requirements that operate in a different
context. Legacy system users often simply describe their current system
when developing target system requirements because it is difficult for
them to think "outside the box", or outside their normal operational
context. Their view of what is possible may be constrained by what
exists. As a caveat, on the opposite end of the spectrum, users
sometimes over-reach technical possibilities when describing what they
need from a new system, simply because they have an existing system.
They may believe that what seems to them to be a small change, or
"tweak" of an existing system would be possible and easy. However,
sometimes small changes are very complex and require extensive reworking
of interfaces, databases, and other links.

Observations

Systems and software requirements may be elicited through visual
observations of operators using legacy systems. In particular, an
observation of current processes can lead to suggestions to modify those
processes, which would affect target system design. Observations can
also identify the type of data used, users, when they use this data, and
how it is used. The current processes can be diagramed and suggested
changes mapped to these existing processes. Observations of how a system
is actually used typically differ from user descriptions. Therefore,
some level of observation is typically needed in migration projects.

Using Existing Systems to Elicit Requirements

Baselining the legacy system is a process of documenting its agreed-to
current functions and interfaces with other systems. It is only logical
to assume that a firm understanding of the legacy system is needed
before one can envision what functions the target system will employ,
what interfaces it may need, and what actions need to be preformed to
implement these functions and interfaces. This includes an understanding
of the environments in which the legacy system operates and the
equipment that support it. Therefore, it is good practice to baseline
legacy system understanding and properties to form the foundation from
which target system development can begin. Legacy system properties
should be documented in a formal configuration management process so
these actions do not have to be repeated and so this understanding can
be drawn upon in the future. Properties of legacy systems and software
that may be worth preserving include:

-   Functional characteristics that are desired.

-   Functional characteristics that are not desired. This includes the
    reasons why characteristics are not desired.

-   Non-functional characteristics (i.e., performance, accuracy,
    reliability, maintainability, etc).

-   Legacy system code.

Legacy system understanding is obtained in part through user (i.e.,
operators, maintainers, and developers) knowledge and experience of the
system. Other sources include existing documentation such as operations
plans, maintenance plans and logs, system-level architectures, and
vendor information. This understanding is critical to the development of
the target system for several reasons. First, the legacy system baseline
provides the understanding needed to identify system components that are
desirable and should be retained, and those that aren't and can be
discarded. Discarding undesirable or unneeded functions or components
can reduce the overall cost to develop and implement the target system.
Second, the legacy system baseline can be compared to the baseline of a
proposed target system to determine the extent of work that needs to be
completed to implement the target system.

Error Reports

Error reports may provide insight on aspects of systems that are not
working well. They may offer ideas on how to improve existing systems
and software so they may be used more efficiently. Staff responsible for
troubleshooting problems may also be excellent sources for eliciting
system and software requirements. Requirements in these cases may
resolve current problems. However, it is important to assess the amount
of any rework on a legacy system that will be valuable in the long term.

> Prototyping

Prototypes are scaled-down versions of potential solutions that can
effectively demonstrate to users how the potential solutions would look
and feel if implemented. They are powerful consensus building tools that
enable better development of the target system. However, prototypes can
be costly. In the context of the requirements elicitation process,
prototypes may be used to clarify and complete requirements for more
complex or intensive changes.

Prototypes can be used to test potential target system alternatives.
Prototypes may be developed to demonstrate what an entire system will
look like or just the individual elements that will comprise it. The
benefits of prototypes increase with the complexity of systems
especially if they involve many users. By developing prototypes of the
target system, users can experience different versions of the system,
(scaled down) to determine which is best for meeting user and public
expectations, while not having to pay for a full-scale system
deployment. Prototypes also offer the ability to quickly point out and
correct problems with requirements before the target system is
full-developed.

Guidelines for developing prototypes include:

-   Prototypes should be included in the project scope.

-   Schedule time to develop, evaluate, and modify prototypes.

-   Don't try to perfect prototypes beyond what is needed to demonstrate
    capabilities of the target system.

-   Don't prototype requirements that are well understood.

-   Develop realistic system interfaces.

In the context of a migration, prototypes can be very useful if
resistance to change must be overcome. A new system's operations can be
clearly demonstrated, and user's can describe how well various aspects
of the new systems meet their needs.

4.3.2 Eliciting Development Requirements

Development requirements are an area where migration projects are
somewhat different from new implementations. The following indicates
some of the areas where differences may be found.

-   Testing -- One key issue in the development of testing requirements
    in a migration project is that sometimes it can be hard to define
    performance when the interactions and performance of the existing
    systems are unknown.

-   Deployment - Often, migration projects must consider the space needs
    for deploying systems in parallel with others.

-   Training -- It may be more difficult to train staff on a migration
    when they are fully occupied with current assignments. A training
    approach must be designed that recognizes this.

-   Disposal -- Various questions should be answered in the disposal
    requirements including: When will the old system be removed? How
    long will parallel operation last? Who should dispose of the legacy
    system? Can it be surplused? Should it be used for parts?

##  {#section-6 .HB-Heading-2}

##  {#section-7 .HB-Heading-2}

##  {#section-8 .HB-Heading-2}

## Mini Cases -- Discussion {#mini-cases-discussion .HB-Heading-2}

For each mini-case described in Chapter 1, the following questions are
posed:

-   Does this step apply to the mini-case?

-   If no, why not?

-   If yes, what are the possible actions that should be taken?

In all of the cases described below, a critical step is to make sure
that the requirements considered support the concept of operations
described in the previous chapter. Requirements may be uncovered that do
not support any concept described in the concept of operations. If such
a requirement is uncovered, then the concept of operations must be
revisited to determine if a change is needed.

### 4.4.1 Field Device Migration: DMS for NTCIP Conformance {#field-device-migration-dms-for-ntcip-conformance .HB-Heading-3 .unnumbered}

The requirements development and management process is critical in any
project. In the case of migrating to a standards based system, it may be
easy to think that the requirements to meet the standard are fully laid
out so that requirements can be simplified or shortcut. This is not the
case. The central system ATMS needs a driver that "speaks" the NTCIP
language. NTCIP is a standard suite of protocols and the correct
configuration for NTCIP must be specified. However, requirements are
first and foremost a set of statements that reflect user needs and the
concept of operations. These are independent of standards.

In the case of migrating to an NTCIP compliant DMS system, it is
important to decide where to make the "cuts" in the existing system.
From the perspective of the central system, is it as straightforward as
just adding a device driver? Will graphic user interfaces also need to
be modified? Will the entire sign control module need to be modified or
replaced? Is the central software structured in such a way that it is
easier to replace the entire central system than to modify it?
Developing a well-structured, comprehensive set of requirements is the
first step in this decision-making process.

Elicit Requirements

Although standards should provide more consistency in the statement of
detailed requirements, it is important to go through the full
requirements elicitation process. It is important that the right level
of detail is developed in the requirements. Many standards guides have a
compliance matrix included with them. This lists the features that are
mandatory and those that are optional to be included. It is important to
develop requirements from the stakeholder perspective in order to
determine which options are needed. Just because an optional item exists
in the standard, does not mean that it should be included in the target
system. It is important to conduct a full requirements elicitation
process without regard to the standards and then make decisions on how
to specify a system that will meet the requirements and will be
standards compliant.

It is also important to be familiar with what the standard will support
and what it will not support. If a requirement is not supported by the
standard, it will be important to determine why that requirement is not
supported. Is it because the requirement borders on how the system will
operate rather than what it will do? Is it a detailed requirement that
can be stated differently and meet the intent? Is the requirement a nice
to have feature, but not truly needed? It is very important to include a
requirement that is not supported only when absolutely necessary. If the
system is built to meet the requirement that the standard doesn't
support, the system will not be fully compliant and may not be fully
interoperable with other standard-compliant systems or components.

As with any migration project, thought must be given to what operational
states will be required during the transition from the legacy system to
the target system. What will be acceptable in the operational state of
the system? Will it be acceptable to have any of the signs not
controlled by central software at any time over the transition period?
For DMS, it might be that either the legacy signs or the new signs can
be operated by vendor software on an independent server. In other cases,
this may not be acceptable. It is important to elicit the requirements
for the operational transition from the old sign system to the new one.

Define Requirements

It is important to understand what is needed in the migration project
for the new sign system to interface with legacy elements that will
remain. The requirements development process may be somewhat iterative
if the decision on where to make the cut changes and new requirements
are needed for a different aspect of the legacy system, especially if
the legacy system does not have an up-to-date set of requirements. In
decomposing high level requirements to detailed requirements, interfaces
will need to be more fully understood and considered.

### 4.4.2 Communications Systems Migration {#communications-systems-migration .HB-Heading-3 .unnumbered}

As mentioned in earlier chapters, this migration was undertaken
primarily because the vendor offered a good deal on a technology
upgrade, migrating from an Asynchronous Transfer Mode (ATM) backbone to
an Ethernet backbone with IP addressable devices. The agency has a value
for keeping current with technology and the opportunity (and cost) was
too good to pass up. The agency was not going to replace any of the old
devices simply to migrate to IP addressing, but was going to change to
IP addressable cameras on a new construction project and will specify IP
addressable devices on all future projects.

In this case, it is important to keep in mind throughout the
requirements process that the communication system is not the end
product. The requirements should focus on communication requirements to
support current and planned system functionality and how to migrate
devices from legacy communication system to the target communication
system.

The cut seems to be pretty straightforward -- the communication system
itself with no changes in central system modules. However, if the idea
is to migrate to IP addressable devices, the agency will have to
determine if their current software supports IP addressing for field
devices. If it doesn't, more extensive changes (either software or
hardware "converters") will be needed as IP addressable field devices
are installed. For the requirements exercise, it is important to make
sure these types of questions are answered in the concept of operations
and then develop requirements that meet those concepts. The specifics of
the design and how to make legacy system communicate with IP addressable
devices will be developed later (in the design phase).

Requirements must include full set of data or information transferred
along with number of devices and other features that will drive
bandwidth and technology needed. Don't be proscriptive. Be careful about
migrating solely for technology.

Elicit Requirements

The requirement elicitation process will need to address the
requirements for the communication system itself, but be reflective of
the needs of the entire traffic management system. What bandwidth is
required? How many devices will the communication system be required to
handle? The requirements will also have to reflect the capabilities of
the existing fiber plant. What are the requirements for operation during
the implementation process and after the new communication system is in
place, but before all the field devices are replaced with IP addressable
units?

### 4.4.3 Change in Function: TMC Central Software Migration {#change-in-function-tmc-central-software-migration .HB-Heading-3 .unnumbered}

As mentioned in previous chapters, the migration of central TMC software
is relatively complex. In this case, software for many of the subsystems
is being replaced. It is important to develop a full set of requirements
for these subsystems and the interfaces to legacy subsystems. If the
original system had a set of requirements that were a project
deliverable, this task would be less onerous. If the agency has the
original requirements and have actively managed and updated the
requirements as conditions changed, the requirements development process
would be relatively straightforward. However, these two conditions are
not often met in today's legacy ITS systems and a full elicitation of
requirements is needed.

Elicit Requirements

Stakeholders from several different groups should be involved in the
elicitation process -- operators, traffic managers, maintenance
personnel, systems administrators, and representatives of other agencies
that have interfaces with or are affected by the central system. The
elicitation process should produce a thorough listing of the features of
the legacy system that must be retained as well as new requirements that
are beyond the capabilities of the legacy system.

Once the high level requirements were established, the team compared
them to the capabilities of the existing system and found that there
were additional modules that were not meeting stakeholder needs, most
notably the video system. The owning agency was very interested in using
commercial off-the-shelf and other existing software to the maximum
extent possible in order to minimize software development costs and
time. The team compared the list of requirements to several existing
software packages, both integrated traffic management software packages
and device specific (e.g., DMS) packages.

This process allowed them to see if there were any packages or
combination of packages that would meet all or most of their needs. The
benefit of comparing high-level requirements to existing software at
this stage is that the agency can determine if their requirements can
all be met by existing software, if minor development will be needed to
meet their requirements, or if major development will be required to
meet their requirements. The agency was trying to determine if
eliminating or changing requirements would lead to significant
reductions in the amount of development required. They found that by
eliminating or changing a few requirements that were not mission
critical, they could purchase a new system that would require very
little new development. Changes in the existing system would also be
somewhat reduced. The team traced these changes back to the Concept of
Operations and found that only minimal changes were required in that
document to support the requirement changes and that revisions the
Concept of Operations would not compromise the overall philosophy or
goals of the system.

The agency conducted a requirements walk-through with the original set
stakeholders to verify that the revised high-level requirements were
appropriate and that they had not missed something in their decision
change the requirements.

Define Requirements

The process of deriving detailed requirements from the high-level
requirements is generally best done cooperatively with the system
provider or developer. In this case, the agency still had two viable
options for meeting their requirements -- purchase a completely new
system, replacing all of their modules, or upgrading only those modules
needed to meet the high-level requirements. The decomposition of the
high-level requirements into detailed requirements would depend on which
approach the agency selected. If the new system was purchased, then
detailed requirements would largely come from the vendor and new
detailed requirements would only be developed where new code was needed
and to cover implementation issues, such as the transition from the
legacy system to the target system. However, if the legacy software was
going to be updated, detailed requirements would need to be derived for
all changes in the software. At this point, the agency charged the
consultant/integrator team with assessing the two options to see which
was most effective.

The results of the assessment were that replacement of the entire
central software system was more cost effective, provided more
flexibility to the agency, and would allow the software to be easily
upgraded when the vendor released new versions. The agency decided to
replace their central software. There were minor modifications that they
wanted in the incident management and video modules. They went through
their procurement process and conducted a requirements walk-through with
the selected contractor. Detailed requirements were derived for the
changes that would be needed to the vendor's software.