Developing Functional Requirements

for ITS Projects

 

April 2002

 

Prepared for

Intelligent Transportation Systems

Joint Program Office

US Department of Transportation

 

By Mitretek Systems, Inc.

     

Executive Summary

 

This document is one of a series of monographs that introduce systems engineering topics to transportation and transit engineers involved in Intelligent Transportation Systems (ITS) projects.  Other monographs in this series include:

 

·        Building Quality Intelligent Transportation Systems Through Systems Engineering

·        Understanding Software Development: A Primer for ITS Public Sector Managers

·        A Guide to Configuration Management for Intelligent Transportation Systems

 

This monograph focuses on the development of functional requirements for ITS projects and is intended for the following audience:

 

·        ITS project managers

·        ITS project team members

·        ITS project Contractors and staff

·        Transportation system planners

·        Anyone else interested in writing quality functional requirements to support project implementation

 

The monograph is primarily geared to ITS project managers and system engineers on ITS projects, who are the front-line people that convert high-level goals and plans into implemented ITS systems.

 

What Are Functional Requirements?

 

Functional requirements are statements of the capabilities that a system must have (“functions”), geared to addressing the business needs that a system must satisfy.  Business needs are mission-oriented objectives of the organization for which the system is built.  For example, a business need of a Traffic Management Center (TMC) could be to manage incidents (e.g., accidents, hazardous materials spills on the roadway) that occur within the TMC’s area of operation.  Good functional requirements are written without specifying implementation details.  The organization for which the system is being built should describe what must be done.  It’s up to the implementer of the system to decide how that function should be implemented, given the constraints of time and money that have been established.

 

Well-written functional requirements should have the following characteristics:

 

• Necessary.  Something that must be included or an important element of the system is missing and other system components can’t compensate for its absence.

 

• Concise (minimal, understandable).  Stated in language that is easy to read, yet conveys the essence of what is needed.

 

• Attainable (achievable or feasible).  A realistic capability that can be implemented for the available money, with the available resources, in the available time.

 

• Complete (standalone).  Described in a manner that does not force the reader to look at additional text to know what the requirement means.

 

• Consistent.  Does not contradict other stated requirements nor is it contradicted by other requirements.  In addition, uses terms and language that means the same from one requirements statement to the next.

 

• Unambiguous.  Open to only one interpretation.

 

• Verifiable.  Must be able to determine that the requirement has been met through one of four possible methods:  inspection, analysis, demonstration, or test.

 

Good functional requirements are essential to good systems.  Studies done to assess why software projects have failed or have not been completed have shown that the cost to fix an error that occurs during the project’s requirements phases goes up dramatically in each later stage.  Figure ES-1 below illustrates this study’s findings.

 

Figure ES-1

Relative Cost to Fix an Error, by Project Phases

What can be a small cost during the Requirements phase of a project is up to 1000 times greater once the system goes into operation.  Even during the Acceptance Testing phase the cost can be 30 to 70 times higher.  So potential savings in project cost is one reason to get requirements right.

 

Functional Requirements and Systems Engineering

 

Requirements analysis is a phase within all system development life cycle models.  The phase may not have that explicit name in all models, but it’s recognized as a key part of the system development process.  The systems engineering approach starts with high-level requirements, usually derived from the Concept of Operations for the system and then continually refines and expands on these requirements descriptions until a sound set of system requirements are developed.  The process of developing functional requirements is illustrated in Figure ES-2.

 

Requirements review is a critical component in the process and the last step prior to iterating.  This step means that you, as the ITS Project Manager, bring your stakeholders together, along with any contractors that you may have brought in to help you develop your system, and go through each requirement – in detail – to ensure that everyone has the same understanding of what the requirement means and what impact implementing the requirement will have on the overall system.

 

It’s important to ensure that you, your stakeholders, and your contractor(s) agree on what the requirements are and what they mean.  Implementing a system and then having the users tell you that you misinterpreted their needs means that you’ve wasted valuable time and money.  You’ll either then go over budget to correct your mistakes or you’ll have a “white elephant” system that won’t provide much utility.

 

Functional Requirements, the National ITS Architecture, and Regional ITS Architectures

 

The National ITS Architecture was developed to address user needs that were ultimately articulated as User Service Requirements.  User Service Requirements are high-level functional requirements and the various elements of the National ITS Architecture deal with ways of satisfying them.  Since User Service Requirements are included in the distribution media for the National ITS Architecture material, you can compare them to the functional requirements your own users provide, to see if your users may have overlooked any important requirements.  However, the National ITS Architecture may address requirements that your region doesn’t have.  For example, a rural area may not have the same requirements for transit information as does an urban area.

 

The ruleES-1 enacted by the U.S. Department of Transportation (DOT) on conformity with the National ITS Architecture requires regions to develop a regional ITS architecture, i.e., a local implementation of the National ITS Architecture, within four years after the region’s first ITS project advances to final design.  All subsequent ITS projects in the region must adhere to that regional ITS architecture.  This makes the regional ITS architecture, once it’s developed, the driving force for all ITS projects in the region.  Regional users of ITS systems must define their high-level functional requirements as part of the process of developing a well-defined regional ITS architecture.

 

Using Functional Requirements on an ITS Project

 

Functional requirements serve as the basis for the system to be built.  In this capacity, they help you:

 

·        Determine whether to build or buy a system component.

·        Interface subsystems or components.

·        Conduct performance testing of subsystems and systems.

·        Conduct acceptance testing of the final system.

 

You can also use functional requirements to define enhancements to existing systems and to develop statements of work for contractors.  When you compare the functional requirements for an enhanced version of a system to its existing capability, it helps you develop a migration plan or route to follow in implementing the desired enhancements.  The migration plan also points out which parts of the system you can leave untouched, because there will be no changes to functionality in them.  Writing a Statement of Work (SOW) for a contractor’s effort is easier when you can spell out the functionality that you’ll want the contractor to implement.  (Don’t forget, however, that you still need to conduct a requirements walkthrough, even if you have an SOW with written functional requirements.)

 

Requirements Tracing

 

One of the key items that you’ll create as part of your requirements package is a requirements traceability matrix.  A requirements traceability matrix maps requirements that you’ve written against the components and subsystems in which you expect to satisfy them.  It is helpful in developing tests and test plans, since you know which requirements you need to test when a part of the system has been developed.  But, in addition, the requirements traceability matrix also helps you make sure that you don’t overlook any requirements.  If you can’t trace, through this tool, a requirement to a system component, it clearly hasn’t been addressed.

 

Managing Requirements

 

After you have a set of requirements that you and your stakeholders have agreed upon, one of your next major tasks is keeping those requirements under control.  Good systems development practice calls for systems to be built in small increments that you can control and manage effectively.  This means that you won’t implement all of the functionality of a system all at once, unless the system is very simple and small.

 

This fact, and other external factors, leads to changes in system requirements.  One goal of an ITS project manager should be to keep the requirements change process under control, not to avoid making changes.  Change is a natural and healthy aspect of system development.  Uncontrolled change, however, is disastrous.  You want to control change, through the process known as “configuration management.”

 

Configuration management is a process that applies to more than just requirements management.  The process is described in more detail in a companion monograph in this series, A Guide to Configuration Management for Intelligent Transportation Systems.  The key point for this monograph, however, is that configuration management provides a process that allows you to make changes to your requirements after you’ve considered and evaluated the impact of those changes on the overall project, its costs, and the schedule for completing it.  You make changes only after you know the expected effect of those changes.

 

Functional requirements are an important part of the design of any information system, not just ITS systems.  An advantage that you have as an ITS project manager is the availability of the National ITS Architecture to help you develop functional requirements.  Software tools exist that you can use to develop and maintain functional requirements.  None of these tools deal solely with functional requirements; usually, they are part of an overall Computer Assisted Software Engineering (CASE) package.

 

We hope that this monograph also serves as a useful tool in determining how to develop and use functional requirements for ITS projects.

 

1. Introduction

Purpose of This Document

This document is one of a series of monographs intended to introduce topics that can help transportation and transit engineers involved in Intelligent Transportation Systems (ITS) projects.  Other monographs in this series include:

 

·        Building Quality Intelligent Transportation Systems Through Systems Engineering

·        Understanding Software Development: A Primer for ITS Public Sector Managers

·        A Guide to Configuration Management for Intelligent Transportation Systems

 

This document focuses on the development of functional requirements as a basis for ITS projects.  We’ll examine the National ITS Architecture, which contains representative functional requirements for ITS systems, as a tool for identifying the types of requirements that we must establish to guide ITS project development and system implementation.  Then we’ll discuss how to go about developing good functional requirements and what they are.

 

Intended Audience

The audience for this document includes the following:

 

·        ITS project managers

·        ITS project team members

·        ITS project Contractors and staff

·        Transportation system planners

·        Anyone else interested in writing quality functional requirements to support project implementation

 

We’ve primarily geared it, however, to ITS project managers and system engineers on ITS projects, who must convert high-level goals and plans into requirements documents that become the basis for ITS system implementation.  The combination of good system engineering practices and good functional requirements help project managers succeed in their efforts.  Of course, there is no “magic bullet” that guarantees success in any project; external factors can always cause a project to fail.  And there is no single formula that, when applied mechanically, guarantees you can produce good functional requirements; in this area, as in many others, experience and judgment are very important.  However, there are general guidelines we can give you to use.  We’ll also provide some examples you might use to your benefit.  Experience shows that failure to write good functional requirements often leads to serious project problems, possibly even to project failure.  Having good functional requirements, while it may not guarantee success, gives you a better chance to succeed.

 

Let’s begin by looking at what functional requirements are all about.

2. What are Functional Requirements?

When working on an ITS project, you should have a clear idea of what your project is to accomplish, and what the system you’re going to implement should do when completed.  From the people who want the system, you’re going to get some “high-level” goals and objectives and some “requirements.”  These goals, objectives, and requirements specify what is to be accomplished, but they may not give you a sound basis for planning and executing your project.  What you must do is translate the initial set of information that you receive into functional requirements, which are statements of the things the system you’re implementing must do, in enough detail to guide you in designing a system that meets those requirements.

 

Types of System Requirements

Our primary focus in this document is on functional requirements, and we’ll define what we mean by functional requirements a few pages from now. But functional requirements aren’t the only type of system requirements that you’ll need.  In addition, you usually find three other types of system requirements defined (and there may be more types defined as well).  The three key types of system requirements usually developed, in addition to functional requirements, are:

 

·        Performance requirements

·        Interface requirements

·        Human-Machine interface requirements

 

Before we discuss functional requirements, let’s take a quick look at these other types of system requirements and explain them.

 

Performance Requirements.  This type of system requirement states the performance parameters of some capability within the system.  Our example comes from the State of Maryland’s Chesapeake Highways Advisory Routing Traffic (CHART) software requirements document.  In it, the following requirement for the Device Control Subsystem appears:

 

The Maryland Transportation Authority’s (MdTA’s) Device Control Subsystem must be … designed to allow for expansion of up to 10,000 devices and 100 protocols.

 

The device control subsystem has a requirement that it be capable of handling up to 10,000 devices and 100 protocols.  This requirement sets a performance limit (it does not need to handle 10,001 devices nor need it handle 101 protocols) and a performance goal (if the subsystem cannot handle 9,999 or 99 protocols, it fails to meet this performance requirement).  Is the requirement testable, i.e., can you determine whether it’s been met?  With a little work, probably.  You may need to simulate devices to get the test device count up to 10,000 -- depending on how many devices the current system has.  As far as the 100 protocols are concerned, you may need to define this element more precisely (what constitutes a “different” protocol such that it would be included in the count), but you should still be able to come up with a test suite.

 

Interface Requirements.  We’re distinguishing here between “interfaces” with users (Human-Machine Interface, which we’ll cover next) and “interfaces” with other systems. Most systems interact with other systems, either already deployed or being deployed.  In general, you must work out the interface between any two systems carefully and specify it (or them, if there are several interfaces between two systems) in considerable detail[1].  Sometimes, these requirements go beyond functionality and border on detailed design, including language that mentions specific manufacturer’s parts.  You may have requirements both for external interfaces, i.e., other systems with which your system must interact, and for internal interfaces, i.e., subsystems within your main system interacting with each other.  An example of an external interface is a toll collection system that connects to systems at financial institutions to initiate transfer of money.  An internal interface might be the interface between high-speed video cameras and a real‑time video storage device.  Interface requirements are sometimes hard to work out, particularly with external systems.  You frequently must establish a working relationship with the “owner” of the external system to work out all of the detail of making your system interface with the other.

 

Human-Machine Interface Requirements.  The way that a user interacts with a system strongly influences what the user thinks about the system capabilities.  A system could be a high‑quality, well performing system, but if the user interface is poor, that’s not the way it’s perceived.  Getting these requirements right might not be the most important thing you do on a project, but it ranks up there among the top five.  It’s not just important from a user satisfaction point of view; user interfaces can affect how well the system is operated.  There are many horror stories about poorly designed human-machine interfaces causing system failures.  Sometimes, the failures can lead to fatalities.  The airplane crash that killed singer John Denver was attributed to a poor interface design that required the pilot (Denver) to turn around while seated to reach a key control.  However, the cockpit design caused him to press on the rudder pedals, sending the plane into a fatal spin.  Another, more recent example of poor human interface design is the “butterfly” ballot used in Florida for the 2000 Presidential election.  Controversy over how voters interpreted those ballots led to weeks of uncertainty regarding the final outcome of that election.  A third example of a poor human interface was the design of the control room indicators at the Three Mile Island nuclear facility.  When the reactor started to overheat, the operators didn’t notice the malfunction until far along in the cycle, when it was almost too late to prevent a full meltdown.  While we don’t expect similar extreme results from poor human-machine interface design on an ITS project, we do recommend that you place a high priority on getting these right.

 

So, after that brief digression, let’s define what we mean by a functional requirement.

 

Definition of Functional Requirements

Martin[2] defines functional requirements as follows:

(1) the necessary task, action, or activity that must be accomplished, or (2) what the system or one of its components must do

A key aspect of the functional requirement is that it addresses what a system must do, but does not address how the system should accomplish the what.  In other words, a functional requirement should not go into the details of how to implement the function.  This is key to writing good functional requirements.

 

There’s a second aspect of functional requirements that is important.  Functional requirements are geared to the business needs a system must satisfy, i.e., they must address those activities that constitute the mission or business objectives of the organization that wants the system; they’re not there to provide “bells and whistles.”  We’ll expand on this point later.

 

Some authors include design constraints in the list of functional requirements.  Design constraints are requirements imposed by factors outside of your control.  For example, if you have a requirement to install new hardware in an existing vehicle as part of the implementation of an ITS system, one design constraint that you’ll face is the capability of the power source available to run the hardware along with other vehicle hardware.  If you place too high a power drain on the vehicle’s power supply with your new hardware, you risk failure in other important vehicle systems.  As long as you state the design constraint as “what” needs to be done and not “how” it needs to be done, it fits in with the definition of functional requirement.

 

Functional Requirements and the Systems Engineering Process

 

The requirements for a system drive its design and development.  Functional requirements are major drivers because they define what the system must do, but obviously they’re not the only drivers.  One way of seeing the impact of requirements on the final system is to look at how all of the front-end activities in the system development effort affect the later stages in the system’s evolution.  We can see this impact easily by using a model or depiction of the systems engineering process known as the “V” (or “VEE”) model.

 

The “V” model, illustrated in Figure 1, shows the early stages in building a system as steps along the left leg of the “V,” the decomposition leg of the process.  The steps on the decomposition leg break the system down into its pieces, proceeding from development of a Concept of Operations[3] for the system, through the definition and refinement of the system’s requirements (going from high-level to detailed requirements), to the system design stage, which also goes from high-level to detailed design.  On the right-hand leg of the “V,” we have the re-composition steps, where we take and test all of the parts of the system we’ve built and also put them together.  As we proceed up the right-hand leg, we combine the system’s building blocks into larger and larger pieces, until we have finally assembled and installed the complete system.

 

The “V” model also helps us understand the relationships between the work done on each side of the “V,” as follows:

 

3. Functional Requirements and the National ITS Architecture

How Does the National ITS Architecture Relate to Functional Requirements

 

The National ITS Program seeks to improve ground transportation in the United States through use of information technology-based systems that deliver timely information and control transit and traffic flow.  It encourages the use of interconnected information-based systems that collect appropriate information and that help users make decisions, control signals and other devices, and interact with external systems such as banking systems.

 

The National ITS Program defined a high-level architecture, the National ITS Architecture, as a tool to provide:

 

·        A framework for identifying and specifying all necessary components and interconnections, including standards

 

·        A common vocabulary to facilitate internal and external communications with colleagues and others involved in transportation planning

 

·         Guidance in developing regional or other ITS architectures, including the flexibility to tailor solutions to individual needs[9]

 

The National ITS Architecture focuses on delivery of services to users.  These User Services derive from User Needs.  In turn, the User Services spawned a set of User Service Requirements.  The User Service Requirements became the high-level requirements that the National ITS Architecture had to satisfy.  The progression from User Needs to the National ITS Architecture is illustrated in Figure 2.

 

Although they are not part of the National ITS Architecture, the User Services that the National ITS Architecture addresses are documented on material distributed by the National ITS Architecture Team.  Version 3.0 of the CD-ROM distribution of the National ITS Architecture documentation contains a section discussing User Services.  This section describes 31 User Services, grouped into 7 User Service Bundles.  Table 3 below depicts the current User Service Bundles and corresponding User Services.  Although this table lists the current breakdown of User Service Bundles and corresponding User Services, it is valid only as of Version 3.0 of the National ITS Architecture.  Later versions of the National ITS Architecture may add User Services and/or User Service Bundles.

 

User Services are further broken down into User Service Requirements.  A partial breakdown of a single User Service, Incident Management, is shown in Table 4.  The numbers shown in the column for Process Specifications refer to the number of the Process Specification[10] in the National ITS Architecture documentation.  To view a Process Specification within the National ITS Architecture documentation, click on the “Logical Architecture” button on the main menu of either the National ITS Architecture CD-ROM or the National ITS Architecture web site (www.iteris.com/itsarch).  Then click on any of the “pspec” entries from the list on the page presented.  This will take you to a page that is a hyperlinked view of the Process Specification you selected.

Figure 2

Progression from User Needs to National ITS Architecture

The National ITS Architecture documentation correlates User Service Requirements with Process Specifications (pspecs).  Pspecs are associated with Subsystems and may be associated with Equipment Packages.  Equipment Packages reference Architecture Flows and Market Packages.  Pspecs, Subsystems, Equipment Packages, Architecture Flows, and Market Packages are all examples that illustrate how you can deploy ITS capabilities.

 

Consider the pspec (1.3.2.1) that addresses User Service Requirements 1.7.1.1.2 and 1.7.1.1.3 (see Table 4) for descriptions).  Figure 3 shows a textual description of the pspec, taken from Version 3.0 of the National ITS Architecture CD-ROM.  In the figure, you can see a section entitled “Functional Requirements” that provides more detail on the functional requirements that this process specification addresses.  These are examples of how the National ITS Architecture can help you develop functional requirements.

Table 3

User Service Bundles and User Services

 

User Service Bundle	User Services
Travel and Traffic Management	1.          Pre-trip Travel Information 2.          En-route Driver Information 3.          Route Guidance 4.          Ride Matching and Reservation 5.          Traveler Services Information 6.          Traffic Control 7.          Incident Management 8.          Travel Demand Management 9.          Emissions Testing and Mitigation 10.      Highway-rail Intersection
Public Transportation Management	1.          Public Transportation Management 2.          En-route Transit Information 3.          Personalized Public Transit 4.          Public Travel Security
Electronic Payment	1.          Electronic Payment Services
Commercial Vehicle Operations	1.          Commercial Vehicle Electronic Clearance 2.          Automated Roadside Safety Inspection 3.          On-board Safety Monitoring 4.          Commercial Vehicle Administrative Processes 5.          Hazardous Material Incident Response 6.          Commercial Fleet Management
Emergency Management	1.          Emergency Notification and Personal Security 2.          Emergency Vehicle Management
Advanced Vehicle Safety Systems	1.          Longitudinal Collision Avoidance 2.          Lateral Collision Avoidance 3.          Intersection Collision Avoidance 4.          Vision Enhancement for Crash Avoidance 5.          Safety Readiness 6.          Pre-crash Restraint Deployment 7.          Automated Vehicle Operation
Information Management	1.          Archived Data Function

 

The User Service Requirements that the National ITS Architecture must satisfy are functional expressions of what an ITS system that provides this User Service should do.  One can consider User Service Requirements as the highest level of functional requirements in an ITS system.  User Service Requirements give a global picture of what overall needs should be met by ITS systems, but exactly which User Service Requirements are satisfied varies for each ITS system actually implemented.  Since the National ITS Architecture is merely a guide to designing Intelligent Transportation Systems, each regional and local implementation is unique and requires its own separate set of functional requirements.[11]

 

Table 4

User Service Requirements in Incident Management User Service

(Partial)

 

No.	User Service Requirement Description	Associated Process Specifications (Pspecs)
1.7.1	Incident Management shall provide an incident identification function to identify incidents.	1.1.1.1, 1.1.1.3, 1.1.2.2, 1.1.2.7, 1.3.1.1, 1.3.1.3, 1.3.2.1, 1.3.2.2, 1.3.2.3, 1.3.3, 1.3.4.1, 1.3.4.3, 1.3.4.5, 4.4.1.8, 6.1.1, 6.5.1
1.7.1.1	The incident identification function shall include the capability to identify predicted incidents.	1.1.1.1, 1.1.1.3, 1.1.2.2, 1.1.2.7, 1.3.2.1, 1.3.2.2, 1.3.4.3, 1.3.4.5, 6.1.1, 6.5.1
1.7.1.1.1	The incident identification function shall use information from the following types of sources, where available, to identify predicted incidents: Traffic flow sensors.   Environmental sensors. Public safety sources. Media sources. Weather information sources. Transportation providers. Sponsors of special events. Hazardous condition prediction algorithms.	1.1.1.1, 1.1.1.3, 1.1.2.2, 1.1.2.7, 1.3.2.2 1.1.1.3, 1.3.2.2 1.3.2.2, 1.3.4.5 1.3.2.2, 1.3.4.3 1.3.2.2, 6.5.1 1.3.2.2, 6.1.1 1.1.1.3, 1.3.2.2, 6.1.1 1.3.2.2
1.7.1.1.2	The incident identification function shall determine at least the following characteristics of each predicted incident: Type. Extent. Severity. Location. Expected duration.	1.3.2.1 1.3.2.1 1.3.2.1 1.3.2.1 1.3.2.1
1.7.1.1.3	The incident identification function shall determine the expected traffic flow impact of each predicted incident.	1.3.2.1

 

But let’s step back for a moment and look at the National ITS Architecture from a broader perspective.

 

How the National ITS Architecture Influences Functional Requirements[12]

The National ITS Architecture is not, in itself, a complete set of functional requirements.  But there are three principal ways in which it can assist in planning and implementing ITS systems:

 

Pspec 1.3.2.2---Review and Classify Possible Incidents

Overview: This process shall review input data about possible incidents and provide verification of the incident. The process shall have the capability of using algorithms to automatically identify and verify an incident. The process shall have the capability to classify an incident as current incident or a planned event and shall be load the data into the store of possible incidents as either current incidents or planned events. The process shall report any incidents that it is unable to verify or classify to the traffic operations personnel for manual verification and classification. The process shall allow the traffic operations personnel to request all possible incidents and carry out the verification and classification process manually.   This PSpec is associated with the Traffic Management Subsystem.   This PSpec is associated with the following Equipment Packages: TMC Incident Detection, TMC Road Weather Monitoring.   Data Flows:   current_incidents_new_data--Out incident_data_update--Out incident_details--In incident_details_request--Out operations_incident_data_updates--In planned_event_data--Out planned_events--Out planned_events_new_data--Out possible_incident_data_update--In possible_incidents--In possible_incidents_data_output--Out request_possible_incidents_data--In tcm_incident_confirmation--Out tcm_request_incident_change--Out tep_event_confirmation--Out   Functional Requirements: This process shall: (a) run when any of the unsolicited data flows described above is received; (b) be capable of automatically determining which possible incidents can be converted into real incidents (i.e. are not false alarms) and further classifying the real incidents as planned events or current incidents; (c) the incident classification process shall use the level of confidence data attached to each set of possible incident data; (d) if the classification cannot be done automatically with a locally determined level of confidence, send the data to the Traffic Operations Personnel via the ‘possible_incidents_data_output’ output data flow, for manual classification; (e) where necessary, format the data for a possible incident into the standard form, adding in any missing fields if necessary, and adding in the traffic impact data field; (f) when a possible incident has been classified: load it into the planned events or current incidents data stores, delete it from the store of possible incidents, send data flows to activate the process responsible for reviewing either planned events or current incidents, and send the appropriate message to other parts of the ITS; (g) if necessary, update the data retrieved from the store of possible_incidents for a possible incident sent in from the Construction and Maintenance terminator so that it takes place at time(s) that cause the minimum impact to traffic and return the amended data to the Construction and Maintenance terminator via the ‘tcm-request_incident_change’ output data flow; (h) new data read from the store of possible_incidents which is found to complement data already in the planned events or current incidents data stores, will be merged, with any additional data items in the new data loaded into the appropriate data store for the incident that is already recorded.

 

Figure 3

Sample (Partial) Process Specification Description

 

·        As a model

·        As a guide

·        As a boundary

 

Let’s review how it helps us in these areas.

 

The National ITS Architecture as a Model

 

The National ITS Architecture is a well thought-out framework for ITS systems.  The National ITS Architecture contains the definition of the processes that implement the functions satisfying User Services, and the physical partitioning of the functions, and serves as a model for implementation at regional and local levels.  That is, transportation planners can formulate regional and local architectures along the same lines as the National ITS Architecture, with suitable adjustments for local variations.  For example, some rural areas may have no local transit systems, and so a regional ITS architecture for such an area can omit the transit components of the National ITS Architecture.

 

As an ITS project manager, you can use the subsystems and market packages in the National ITS Architecture as models for how you allocate functions to the subsystems that you need to build.  The National ITS Architecture also helps you visualize what interfaces you’ll need to construct to tie different capabilities together.

 

The National ITS Architecture as a Guide

 

The National ITS Architecture is itself expressed in terms of functional requirements.  There are User Needs that must be serviced, and functions that will service them.  For example, there is a user need to have information relevant to trip planning: route, road conditions, and unusual activity.  There are functions to satisfy this need, and they include providing route guidance based on traffic management information.  The National ITS Architecture breaks these functions down to levels that can be more easily implemented.  So in this sense, the National ITS Architecture is a guide to writing good functional requirements for transportation systems.  Planners and project implementers can review relevant pieces of the National ITS Architecture to see how the requirements were expressed functionally, and use similar language and strategy in their own applications.

 

The National ITS Architecture as a Boundary

 

Just as the National ITS Architecture describes what’s in ITS systems, it also establishes, by what it doesn’t contain, what isn’t part of the ITS systems boundary.  This helps control the scope of an ITS project and keep extraneous requirements from creeping in.  Boundaries also help define interface points for a system.  If you are conducting an ITS project that adds capability where intelligent transportation systems already exist, the boundaries drawn by the National ITS Architecture point out where and what interfaces you should plan.

 

At the same time, it’s important to note that there may well be ITS requirements that are not part of the User Service Requirements and not characterized by the National ITS Architecture.  You should add these additional ITS requirements to your system requirements document.  Adding these requirements may force an extension or expansion of your regional or project architecture.  The template provided by the National ITS Architecture allows regions and projects to define extended boundaries for their more localized architectures.

 

Why Aren’t User Service Requirements Sufficient as Functional Requirements?

If you’ve gone to a course on the National ITS Architecture, you’ve heard many reasons why using the National ITS Architecture can help you in defining and developing ITS systems.  One reason is that the User Service Requirements defined for the National ITS Architecture are high-level functional requirements.  However, by themselves, User Service Requirements aren’t complete functional requirements.

 

First, User Service Requirements are specified at a high level, the most abstract level.  When you build a system, you’re making very explicit technology and performance specifications.  Functional requirements do not exist as independent entities, nor can we derive them without thinking about potential designs.  The following example makes this clear:

When a town planner decides that the ferry that transports people across a bay in his city no longer has sufficient capacity to carry all the traffic, [and building a larger one is not feasible], he is likely to ask a civil engineer to design a bridge.  The town planner does not ask the civil engineer, “Say, I’ve got people on opposite sides of this bay, and I need some way to transport them across.  Got any ideas?”  Before the town planner contacts an engineer, he has already decided what he wants built.  He knows a standard type of artifact—a bridge—and he knows who is capable of designing one specifically for the traffic across the bay.  The fact that orderly engineering starts with some type of design pattern has an important implication for requirements:

Rigorous research and definition of requirements is possible only in relation to a specific design pattern.[13]

Once we know that we’re going to build a bridge, we can ask pertinent questions such as, “What type of traffic will the bridge carry?”  “How many lanes does it need?”  “Where will it connect to existing roads?”  When these questions are answered, we can write functional requirements.

 

Second, User Service Requirements don’t necessarily address or satisfy local requirements and conditions.  Since the National ITS Architecture is high-level and abstract, it doesn’t address:

 

·        Location-specific laws and regulations

·        Expectations and desires of the local population

·        Availability of funds for deployment

·        Nature of existing transportation infrastructure

·        Ability to interconnect with other systems in the locality

·        Technology choices, hardware and software choices, and performance characteristics, such as lane width, throughput, capacity, schedule, and similar items

 

You may not control any of the above factors, but your project, to be successful, must take them into account.  Thus you need to reflect local conditions in the functional requirements for your system. User Service Requirements at the National ITS Architecture level are clearly not sufficient for this purpose.

 

Third, you’ll need to derive additional requirements to ensure smooth integration of your system with other local systems.  You’ll probably also need to derive additional requirements just to satisfy specific needs and accommodate limitations in the systems and conditions with which you’ll interact in building your new system.  Deriving additional requirements from existing ones or developing more detailed requirements as you move through the system development process is a natural order of events.  We’ll cover that in more detail later in this document.

 

National versus Regional ITS Architectures

 

As a last point before going on to the next section, let’s make sure we understand the role of regional ITS architectures as well.  A well-defined regional ITS architecture results in a high-level tailoring of the National ITS Architecture for your region.  Once you construct such a well-defined regional ITS architecture, it provides a blueprint for ITS in your region.  It will require updating over time, as changes to regional needs occur, and may require updating when the National ITS Architecture changes.  If there is a regional ITS architecture for your area, it reflects the needs of your immediate stakeholders.  You need to conform to your regional ITS architecture to ensure that you effectively address the needs of your stakeholders.

 

Now let’s look at how we develop functional requirements that are specific to the system we need to build and how we manage functional requirements to help engineer the project in the most effective way.

4. Analyzing and Writing ITS Functional Requirements

Where Do You Start?

As the King said to the White Rabbit: “Begin at the beginning, and go on till you come to the end; then stop.”[14]  That’s not bad advice.  Let’s start with some basic systems engineering homework.  We have to figure out what need the system is going to meet, how the system will operate once it’s been implemented, what it’s going to do, and how the system fits in with other systems once it’s in operation.  That’s the basic homework.  We’ll start with what’s known as a needs analysis.

 

Needs Analysis

 

In a needs analysis, we ask certain basic questions:

 

·        What is less than satisfactory with the current situation and how does the proposed project fill that need?

·        Do all stakeholders have a common understanding of the project’s goals and objectives?

·        How do we resolve conflicting stakeholder goals?

 

In conducting a needs analysis, there may be some preliminary steps that you have to take to put your effort into the proper context.  Someone else may have done some of this basic homework and provided you with the results.  If they haven’t, it may be necessary for you to perform the work in these two steps.  They are:

 

·        Understand the local institutional environment

·        Determine stakeholders

 

Let’s look at what’s involved in these two steps.

 

(1) Understanding the Local Institutional Environment

 

There are a number of local factors that could affect the requirements on ITS projects.  These include:

 

·        The political situation. 
What can realistically be done, in light of who wields political power and what power they have?  Who will make decisions about ITS projects to be implemented?  How will these decisions be made?

 

·        Receptivity to innovation and new ways of doing business. 
Will local operators and citizens fight some or all proposed changes to the transportation system?  Will they be willing to use new devices in their vehicles and access new information systems?  How will uncertainty in this area affect the success of ITS projects?

 

·        Willingness to invest in ITS solutions. 
How much can be committed to new transportation systems in light of other community priorities?

 

·        Local laws and regulations. 
In addition to national laws and regulations, such as environmental statutes, are there local laws or regulations that will affect ITS projects and the functional requirements to implement them?

 

Let’s look at how these affect functional requirements for ITS projects.

 

The Political Situation.  The political situation in your area creates the context in which you implement your ITS project.  The people who created the political situation are usually key stakeholders in the project and have needs that you must meet.  You’ll need to determine what those needs are and how much support they’re willing to give to meet their needs.  In addition, some of the people involved in creating the political situation you face may be involved in the decision-making process that affects your ITS project.  You may report to some of them or have to make presentations to them as part of keeping the project on track.

 

You shouldn’t view the political situation as a negative constraining your project.  It may be, but it could also be a very positive factor that drives the project to success.  If key political players are behind you, you’ll probably have more chance of making things turn out well.  Even if you don’t have the political support when you start, you always have the opportunity, through good project management and astute expectation management, to win people over as supporters.

 

Receptivity to Innovation and New Ways of Doing Business.  There are some who are receptive to innovation and change (the “early adopters”) and some who resist change all the way.  Most people fall in the middle; they’re not looking for change, but they’ll accept it if it’s presented to them in a positive way.  Part of your job is to help the middle group, which is usually the largest one, accept the change by pointing out the positive aspects of what’s new, by promising only what you can deliver, and by keeping your promises.  When you meet resistance, you must look for the reasons -- keeping personalities out of the picture.  It could well be that the reason for the resistance is that some key requirement isn’t being met for a group that considers themselves stakeholders.  While you may not be able to address that requirement in your implementation (due to lack of money, lack of time, or lack of resources), you should acknowledge the requirement and help the group understand how and when it could be met.  If the requirement is one that you can or will satisfy, you need to educate the group and overcome their resistance to the new system.

 

Willingness to Invest in ITS Solutions.  Since our assumption is that you’re developing requirements because you have an ITS project underway, there has to be some willingness to invest in an ITS solution.  However, it may be necessary for you to provide information on the return on investment that your project offers the community it serves.  If your project doesn’t yield greater benefits than it costs, it’s hard to justify why it was funded in the first place.  Education may be necessary.

 

Local Laws and Regulations.  Laws and regulations are frequently the source of many key requirements.  They set conditions that the system must meet and boundaries within which the system must operate.  In some cases, they may be the reason that the system project was undertaken.

 

(2) Determining Stakeholders

 

Let’s clarify the concept of “stakeholder.”  A stakeholder is anyone who has an interest in the success of the ITS project (a “stake” as it were).  Stakeholders include users, politicians, and the public.  Each stakeholder has some idea of what he or she wants the system to do.  Part of our job is to determine what needs stakeholders want satisfied.

 

Not all stakeholders are going to have their needs satisfied.  You can’t please everyone.  (Sometimes, you can’t even please anyone.)  But you should determine who the people and organizations are that you must satisfy.  Since the stakeholders are the local users of the ITS services and others who are influenced by any ITS projects, their particular needs ultimately determine which ITS components you implement, and how available funds get apportioned to improve local transportation and satisfy the local constituency.  Therefore, you must determine the following:

 

• Potential users of all ITS services under consideration. 
  Who are all the potential users, and what are their primary concerns?  Commuting time?  Notification of adverse road conditions?

 

• Others who may be affected directly or indirectly by ITS services, but who will not be users. 
  Will they support ITS efforts?  Will any of them be adversely affected by ITS solutions?

 

• Persons or organizations with a strong material interest in success or failure of ITS solutions.
  Are there persons or organizations who profit or lose (money, influence, business) if ITS solutions are implemented?  Does this need to be taken into account in writing requirements?

 

The stakeholders are sources of requirements and they are also ones who validate or verify the requirements.  You need to bring them into the picture early on to make sure you consider their needs and to determine how you’re going to involve them in the process of reviewing and verifying the requirements that you define.  In particular, you need to identify the principal stakeholders, the ones for whom this system is key to doing their job.  Although there may be many stakeholders for a system, the principal stakeholders are the ones who ultimately must accept the system once it’s implemented.  These are the key people you have to satisfy.

 

Concept of Operations

 

After you decide whose needs you’re trying to meet and what priority to set in meeting stakeholder goals, you develop your idea of how the system you’re going to build will operate.  This view of the system in operation is called a Concept of Operations.  To develop a concept of operations, you have to answer several basic questions, among which are:

 

·        Do we know who all the users will be?

·        Do we know how the users will interact with the proposed system?

·        Is how we plan to operate the system consistent with all systems with which it must interact?

·        Have we coordinated with all other agencies affected by this system?

 

Let’s look at that last question for a minute.  Coordination is important because our system fits into the overall system environment within our region.  It’s not going to operate in isolation; it has to fit in with and interact with other agencies’ systems.  If we focus only on what we’re going to do and don’t include all others with whom we must interact in our thinking and planning, we’re liable to overlook some key requirements for our system.

 

Also, we should consider other agencies so that we don’t duplicate functionality that already exists.  It’s hard enough to build a good system on time and on budget without making extra work for ourselves.  We want to do all the things that are necessary in our system, but we want to avoid doing anything that isn’t necessary.

 

As part of the process of identifying needs and developing a concept of what our system will do, we’re going to develop the requirements for our system.  To refine the requirements, we’ll conduct basic fact-gathering.

 

Fact-Gathering

 

You base your functional requirements on facts, not “wish lists” or misperceptions about what’s needed to do a job.  You should always ask questions like:  “What’s the reason for this requirement?”  “What critical purpose does it meet?”  “What happens if we don’t provide this capability?”  In particular, you should gather facts to let you establish measures that let you quantify requirements.  It’s better to have a requirement that says you have to support “10,000 devices” than one that says you have to be “able to expand the system to accommodate future growth.”  The first requirement is one you can verify; the second you can’t.

 

In gathering facts, ask such basic questions as:

 

·        What functions will this project perform?

·        Have all functions been defined in detail?

·        Are all interfaces identified and defined?

·        Are system requirements given in quantifiable terms?

·        Have requirements been reviewed with stakeholders, and is there understanding and agreement?

·        Have we determined measures of system reliability, maintainability, and availability?

·        What derived requirements must be validated with stakeholders?

 

We want to emphasize a couple of key points.  First, reviewing requirements with stakeholders (at least those who are our primary stakeholders) is critical.  We have to get everyone in agreement on what’s meant by the language of each requirement.  We’ll give an example later on of requirements interpretation to illustrate why this is important.  It’s not just the initial set of requirements that we have to verify with stakeholders and get agreement on.  It’s also the derived requirements.  Derived requirements are ones that you find out you must meet as the result of having primary requirements.  Let’s look at an example.

 

Let’s say that our customer is the Metropolis Traffic Department with video data acquired through roadway intersection cameras.  We find out that the Metropolis Traffic Department wants its roadway maintenance department to share that video data.  By sharing the data, the Metropolis Traffic Department believes that maintenance crews can better determine which roads are suffering from potholes and which are beginning to show signs of potholing.  The roadway maintenance department could then send crews out early enough either to keep potholes from occurring or to repair existing potholes before they become a serious road hazard and congestion point.  Our primary requirement is to share traffic video data with the roadway maintenance department.

 

However, the question that we have to answer is, in what manner should we present the video data to the roadway department?  Should it be full-motion video or frames from the video taken at specific times during the day to show road conditions?  If the need is for full-motion video, does it need to be real-time or can the day be taped and the tape sent to the roadway maintenance department for study?  The answer to those specific questions determines how heavy the load is on the data network that we have to build into our system.  We have to document the requirements we derive as part of the requirements package for our system.  And, before we finalize our requirements, we have to review these derived requirements with our customer and ensure that our interpretation, which led to a specific statement of the derived requirements, is correct.

 

Second, we have to make sure that we have measurable values for key requirements and that those measures are reasonable.  One of the characteristics of a good requirement, as listed in the last chapter, is that it be verifiable.  One way to verify a requirement is to have a value that we want it to achieve.  For example, in an availability requirement, we might determine that we want key components of the system to be available 99.9% of the time.  That means, in a system that operates 24 hours a day 7 days a week, that the system could have no more than 8.75 hours of downtime in a year or about 10 minutes of downtime per week.  That kind of availability is frequently called “three 9s” availability.  There’s a cost associated with this type of availability requirement, so we should know that it’s a real requirement, not something on someone’s “wish list.”

 

The concept of operations and the requirements you define begin to determine your system architecture.  There are some more basic questions that you address while defining your system architecture.  These include:

 

·        How does this system integrate with other ITS systems in the region?

·        Is it consistent with the National ITS architecture and any applicable regional architecture?

·        What are its principal components?

 

Your system is part of a family of systems in your region.  It should interact effectively with each of these other systems.  The functional requirements you derive from the manner of interaction are the interface requirements that we discussed earlier.  How your system meshes with the National ITS Architecture is important from the point of view of what services you’re going to provide and how they interface with other systems in your region.

 

The information you gather during this “basic homework” forms the basis of all functional requirements, since it deals with what the system must do, and the context in which it must operate.  Once this information is in hand, you begin to write your requirements document.

 

Writing a Requirements Document

 

Once you’ve done your initial fact-finding, you can begin writing the requirements document for your ITS project.  Written requirements are important.  (To paraphrase a Hollywood mogul, “Oral requirements aren’t worth the paper they’re written on.”)  A written requirements document captures what you’re trying to achieve with this system in a tangible form, one that others can read and review and interpret.  And the fact that others can read and review it is important, because you want to express the requirements in language that meets the criteria for good requirements that we defined in an earlier section.  You’ll know when you’ve achieved good requirements.  It’s when everybody that’s a stakeholder (including you and your team) agree on what the requirements mean.

 

But you’re probably not going to get the requirements right the first time you write them down.  That would reflect a lack of serious thinking about quantifiable requirements and cost-benefit tradeoffs.  The first time through, you’ll mostly write down what you were told and won’t have done much in the way of analysis on whether the requirements are valid, reasonable, feasible, or any of the other characteristics that we want in good requirements.  But you’ll at least have them written down.  That’s the first step in analyzing them.

 

Analyzing the Requirements

 

Begin by determining, based on user needs, the exact function that the system must perform.  This is often the most difficult step.  Describe the function in ordinary language, and then work to make the language more precise and less ambiguous and less subject to differing interpretations.  For example, if the user need is to have a vehicle’s identification tag scanned so that the vehicle does not have to stop at a toll collection booth, the first cut at a functional requirement statement might be:

 

“Read the vehicle identification as it passes through the toll booth.”

 

Though the above statement isn’t bad, it’s not specific enough about the function to be carried out.  There are still some open questions, such as: Is the reading to be automatic or manual?; What vehicle identification is involved?  Your analysis should focus on resolving ambiguities like those.  You’ll want to explore the reason for performing the function.  Is it because you’re trying to collect tolls?  Is it because you’re trying to track the location of the vehicle?  Are you trying to keep track of a vehicle transporting hazardous materials?

You may want to write the requirement in a hierarchical fashion.  This allows you to start with the general requirement and then get more specific as you go down the hierarchy.  For example, the requirement might look like the following:

1.    The toll collection system shall automatically read the vehicle tag as the vehicle passes through the toll booth.

1.1.        The toll collection system shall determine, through data in the vehicle tag, the point at which the vehicle entered the highway system, as a means of calculating the toll amount.

1.2.        The toll collection system shall compute the toll amount.

1.3.        The toll collection system shall interface with the existing financial system to record the toll collected against the driver’s account.

1.4.        The toll collection system shall reduce the on-tag account balance by the amount of fare collected.

 

You might also want to consider what the system does if there is no vehicle tag, if the driver’s account balance is low enough that it might soon be overdrawn, or if the driver’s account has insufficient funds to cover the toll amount.  These are all conditions that the system should handle.  The stakeholder who stated the original requirements may not have explicitly stated them, but they’re ones that you should easily derive as requirements through your analysis process.

 

Next, determine the quantitative performance requirements for the system.  Quantitative performance requirements guide the system’s implementers in constructing it properly.  Make sure that the quantitative performance requirements do not push the state of the art, and are internally consistent.  And make sure that you express the quantitative performance requirements clearly.  Consider the following examples:

 

“The system shall read identification tags for all vehicles traveling at 30 mph or less.”

 

“The system shall read identification tags under all lighting conditions.”

 

“The system shall locate the tag at any height above the ground between 2 feet 6 inches and 9 feet 6 inches.”

 

Of the three requirement statements above, two are reasonable quantitative performance requirements statements.  If you didn’t spot the ringer we slipped in, it’s the second one.

 

Why is that one not a good requirement?  Well, it says “all lighting conditions.”  Think that’s testable?  Maybe, but not in any realistic manner.  The word “all” means “every possible.”  “Every possible” lighting condition covers a very broad spectrum of lighting conditions, and you’d have to test them all to verify that the system met the requirement.  It’s better to specify a realistic range of lighting conditions, e.g., in measurable terms, like lumens, so that you limit the conditions for which you must test.

 

As part of the analysis, particularly in getting at the feasibility of the requirements, you may need to perform some studies or conduct some experiments.  In particular, when you’re looking at user interface requirements, you may want to build prototypes of the user interface and try them out with the users of the system.  Prototypes are excellent tools for getting at user interface requirements because they let the users experience how they’ll interact with the system.

 

After you complete a cut at analyzing requirements, you should revise the requirements document and review it with your stakeholders.

 

Reviewing Requirements with Stakeholders.

 

This is a critical step in the process of getting requirements done properly.  It’s important to make sure that both you and your stakeholders interpret all requirements the same way.  If you don’t have the same interpretation, they’ll have expectations that you won’t meet and you’ll waste time implementing the wrong capabilities.

 

The best way (time-consuming though it may be) to review requirements is to conduct what’s known as a “requirements walkthrough.”  In a requirements walkthrough, you get the representatives of the major stakeholders together with your project team and you go through each requirement one-by-one, telling them how you interpret that requirement and asking them if they interpret it the same way.  Be very clear on what your interpretation is; this is a “make or break” step in the process.

 

You may be surprised at how easy it is to have different (sometimes even contradictory) interpretations of requirement statements.  Remember that words have multiple meanings and not everyone is using the same meaning when they use a word.  A famous example of how even a simple phrase can have multiple meanings is the phrase:  “Time flies.”  When an instructor asked a group of students at a course on software acquisition to give their interpretation of that phrase, the students gave the following interpretations:

 

·        Time (a measure of duration) moves very rapidly

·        People who work for Time magazine take airplanes, as opposed to other means of transportation (“Time flies; Newsweek takes the train”)

·        It’s an order to a baseball coach to measure the duration that a fly ball spends in the air

·        It’s a description of someone throwing a clock across the room

·        Someone is being asked to hold a stop watch on houseflies as they buzz around a room

 

Now, it’s true that the students were trying to be creative in their interpretation of the phrase, but the example does demonstrate how phrases can have different meanings to different people.

 

The payback on a requirements walkthrough however can be very high.  One ITS project manager who invested the time and energy in conducting one for his ITS project said it was the best system development tool he’d ever found.  Remember also what Table 2 showed.  The cost of fixing a mistake that you could have fixed in the requirements analysis stage goes up rapidly with each subsequent stage through which you pass.  By the time you get to the implementation stage, fixing an error in a key capability will cost you 40 to 1000 times as much as it would have back in the requirements analysis stage.

 

Functional Requirements Writing Styles

In addition to writing clearly, you should maintain a consistent style when writing functional requirements (actually, in all requirements documents).  The following are some rules of thumb for requirements writing:

 

• Use the word “shall” to indicate requirements.
• Use imperatives to condense requirements.
• Where appropriate, use explicit subjects for clarity.  For example, “The sensor shall emit a beep after reading the strip”, rather then “Emit a beep after reading the strip”.
• Try to avoid constant, repetitive use of phrases such as “the system” as the subject of functional requirements.  However, don’t eliminate these phrases if doing so can lead to ambiguity in the requirement.
• Avoid drift between declarative and imperative sentences.

 

You should also distinguish between functional requirements and comments that give the rationale for the capability sought, or information about how the capability is expected to be used in practice.  Consider the following example:[15]

The system shall maintain a Transaction Log file which tracks each person making a data base change, the types of records changed, the number of changed record occurrences, and the day and time of the user’s record-changing session.  This information will allow the system administrator to monitor whether expected data maintenance activities are in fact taking place.  It will also help to track the effect of unauthorized access to the system by individuals who have managed to evade the Contract Tracking System’s access controls.

In this example, there is a functional requirement to maintain a Transaction Log, and two comments, the first regarding use of the log to monitor activity, and the second regarding use of the log to control damage after system penetration.  Because the requirements statement runs all three together in the same paragraph, it is difficult to extract the requirement and establish its boundaries.

 

To separate requirements from comments (which are often quite helpful to system implementers), you should use one of the following four methods:[16]

 

• Label all requirements with a unique number.  Visually separate all comments from the labeled text containing the requirements.

 

• Use “shall” for functional requirements, and “will” for comments regarding use of the functions or capacity being specified.  This approach is often used for military requirements (cf. MIL-STD-490A).

 

• Use imperative sentences for functional requirements, and reserve declarative sentences for comments.

 

• Use special language and/or format for requirements, and regular text for comments.

 

As an example of how the last method might work, let’s take the requirements statement above and re-cast it:

 

The system shall maintain a Transaction Log file which tracks each person making a data base change, the types of records changed, the number of changed record occurrences, and the day and time of the user’s record-changing session.  This information will allow the system administrator to monitor whether expected data maintenance activities are in fact taking place.  It will also help to track the effect of unauthorized access to the system by individuals who have managed to evade the Contract Tracking System’s access controls.

 

What we’ve done in the above example is use two different fonts to separate the requirement statement itself from the explanatory comments.  In addition, we used italics and bolding to make the explanatory comments stand out.

 

Let’s take some examples of requirements and see what’s good and bad about them.

 

Examples of Good and Bad Functional Requirements

The following examples are not all transportation examples.  But they are taken from actual requirements documents that someone wrote.  In some cases, the language has been modified to protect the guilty.

Example:    “Design a transportation device.”

Comment:  This is a classic, almost hilarious, example of an ambiguous requirement.[17]  When given to a group of designers, results ranged from $10 devices to $15,000,000,000 devices!  Clearly, the designers must be given a better idea of what you would like to have!  That is, the requirements must make clear to them what problem is to be solved.

 

Example:    “The system shall deal with motorist requests for routing information efficiently.”

Comment:   This statement is too vague and cannot be tested because of the words ‘deal with’ and ‘efficiently’.  It is not clear what, exactly, is being asked for, nor how to determine if the requirement is being satisfied and therefore how to design to meet it.  A better version is:

 

                   “The system shall process motorist requests for routing information and supply the requested information within 1 second for 99% of requests under specified load conditions.”

 

Example:    “The system shall facilitate emergency response equipment reaching its destination quickly.”

Comment:   There is not enough information here to design a system or to determine if it satisfies the intent of the requirement.  Words such as ‘facilitate’ and ‘quickly’ should be avoided.  A statement that makes the goal clear is needed:

 

                   “The system shall receive requests for priority routing of emergency response equipment, determine the optimal (i.e., shortest time to destination) routing path, and communicate necessary information to traffic signaling devices within 5 seconds.”

 

Example:    Switched Voice Service (SVS) shall provide calling capabilities between WITS2001 Service Delivery Points (SDPs) as well as from any WITS2001 SDP to an Interexchange Carrier (IXC), Local Exchange Carrier (LEC), or Competitive Local Exchange Carrier (CLEC) Point-of-Presence (POP).  The contractor shall support the following types of central-office-based Switched Voice Services:

 

1.      WITS2001 lines, including analog and ISDN Basic Rate Interface (BRI) lines, but no trunks.  By definition,  WITS2001 lines are directly connected to a Government-owned serving office via a Type A or a Type A Alternate access arrangement.  Type B access arrangements do not apply because they are connected to a serving office provided by the contractor.  Currently, GSA provides WITS line service to customers that require at least 25 pairs of copper distribution cable.  GSA Consolidated Centrex lines serve smaller customers.

 

2.      Centrex-like lines, including analog and ISDN BRI lines.  By definition, Centrex-like lines are directly connected to a serving office that is part of the WITS2001 network but is owned or leased by the contractor.  Centrex-like lines are provided by Type B access arrangements.

 

3.      WITS2001 access trunks, including analog, T1, T3, and ISDN Primary Rate Interface (PRI) trunks.  WITS2001 access trunks will not be provided via Type A access arrangements because GSA does not have the right to use the associated distribution cable.

 

Comment:   This is a good functional requirements statement in a communications context.  It says clearly what is to be done in the first sentence, and then gives detailed performance specifications or comments (shown in italics) in the following numbered sentences.  Where needed, explanatory information is provided to aid in the understanding of the requirement.  Implementation details are not specified (e.g., use coaxial cable or fiber optic cable, or use Lucent or Nortel switches).

 

We’ve given you an idea of how to go about writing and analyzing requirements and provided examples to show good from bad requirements statements.  Let’s look at how you use requirements on an ITS project.

5. Using Functional Requirements on an ITS Project

How Functional Requirements Affect the Implementation Process

Functional requirements form the basis of good systems development, whether you do the work in-house or contract it out.  They give implementers the information they need to find cost-effective, high-performance solutions to user needs.  Let’s explore the relationship of functional requirements to system development and/or procurement in more detail.

 

Functional Requirements as the Basis for the System to be Built

 

Since functional requirements tell system developers and implementers what the system is supposed to do, in concise and precise form when properly written, they, together with the system architecture, form the basis for system implementation.  This includes the following activities:

 

• Determining whether to build or buy system components.  It’s always better to buy an existing system that meets your requirements than to build one from scratch.  If you can buy an existing system that meets your requirements, you benefit from work done by others and by the fact that other people have found and fixed many problems that the system had when first implemented.  But buying a system presupposes several things:

 

-         A system that meets your needs exists

-         You can afford that system

-         Buying the system doesn’t constrain you from being able to add new, needed capabilities in the future

 

Buying’s not a perfect answer, nor should you undertake it without thoroughly considering all the consequences this decision will have.  Building a system also has many consequences, many of which entail serious risk.

 

“Buying,” in an ITS context, involves one of two options.  The first is acquiring a commercial off-the-shelf (COTS) system.  Although there are only a limited number of COTS systems available in the ITS arena, when the ones that exist meet your requirements, you should seriously consider them.  The systems don’t need to meet all of your requirements, as long as there’s some flexibility for modifying the systems to add the capabilities that they lack and you need.  If there are competing systems (the best situation, from a procurement or contracting office’s point of view), you use your requirements to determine which competing system best meets them.  Although the technical match of requirements isn’t the only criterion to use in selecting a system, it identifies what’s missing and gives you a way to estimate the overall cost of acquiring it (purchase price + cost to enhance + cost to maintain the system and its enhancements).  The second is to acquire the ITS system from some other government entity.  Once again, the system has to match your requirements, even if the match isn’t perfect.  This option, which usually involves an intra-government agreement, may not involve money changing hands; there’s usually some quid pro quo that makes all parties happy.  This option lets you “partner” with the other government entity to create an enhanced system that may benefit both of you.  In terms of maximizing government investment, it’s an attractive option.

 

However, if there’s no system, whether a COTS product or a government-furnished option, that meets your requirements, you still have the option to build.  Then your requirements form the basis for your preliminary and detailed design.  They provide your implementation team with the guidance necessary to build a quality system.

 

• Interfacing subsystems or components.  When you build a system, you typically connect individual components together to form subsystems and then interconnect the subsystems to form the final system.  Each component and subsystem carries out certain functions necessary for overall system operation.  By allocating functional requirements to the component and subsystem levels, it is easier to ensure that the interconnected components are designed properly and the subsystem meets its goals.  The process of allocating requirements to components or subsystems is something you do during the preliminary design of your system.

 

The National ITS Architecture illustrates how to do this by relating subsystems, market packages, and equipment packages to deliver user services.  This is shown in Figure 4.

 

• Performance testing of subsystems, and systems.  This is critical, because you need to know if everything is working properly and, if not, where the problem lies.  With functional requirements available for each subsystem and system, you can develop tests that examine if each meets its requirements.  This lets you track progress and sign off on completed phases, components, and subsystems.  It also lets you determine if vendors have delivered what they contracted to deliver.  All deliverables must meet the performance and other criteria specified in the functional requirements document.

 

• Acceptance testing of final systems.  Acceptance testing certifies that a system is ready for action.  Since you’ve plainly spelled out functional requirements for the system, you can devise a comprehensive acceptance test to verify that the system meets its requirements and performs as you expect it to.  Without functional requirements, you would find it difficult to determine if what has been built performs satisfactorily in the real world.

Figure 4

Relationship of Subsystems, Market Packages, and Equipment Packages

 

Functional Requirements as Basis for Enhancements to Existing Systems

 

Modifying an existing system can pose significant problems to you as project manager.  A simple “enhancement” may actually require significant system redesign and lead to unexpected costs.  In addition, people tend to modify existing systems by adding features rather than new functions.[18]  This “spruces up” the old system, sometimes at great cost, but it doesn’t do anything new.  So it’s important to know what you’re getting into when someone proposes a new project that “enhances” an existing system!  Good functional requirements can help you deal with this situation in four essential ways.

 

First, by comparing the functional requirements for the old system with those of the new system, you can determine where (and whether) the requirements have changed.  This helps you better estimate just where, at the subsystem and component levels, you’ll have to make changes, how much effort those changes will require, and whether the changes are feasible, given the existing system’s implementation and available time, money, and other resources.  For example, an enhancement to a vehicle-based system may require doubling the data rate to the vehicle.  With existing hardware, this may not be possible, and may require an entirely new wireless system to be installed on both vehicles and in the central or the roadside facility.

 

Second, given functional requirements for the enhanced system, you can lay out an effective migration plan to implement the desired enhancements.  A good migration plan minimizes disruptions (if you need to continue system operation during the transition to a new system capability).  You can leave the parts of the system untouched that meet existing requirements.  It is only the new requirements that you need to worry about.  If you can encapsulate the new requirements into their own subsystems, you can build (or buy) those subsystems and just integrate the final products into what you have.  This is simpler and more effective than throwing everything out, including what works, and replacing it with new, less mature components.

 

Third, functional requirements let you estimate more accurately the cost of implementing the proposed enhancements.  In fact, you should use functional requirements to estimate all of the following elements of a project plan:

 

·        Schedule

·        Resources

·        Cost

·        Risk

·        System size

 

Fourth, concentrating on functional requirements makes the substitution of features for functions in existing systems more difficult.  You can legitimately ask, of every new requirement, “Is this a feature or a real functional enhancement?”  This separates the wheat from the chaff, and concentrates effort on functions and their associated functional requirements.  Consider the following example:

…suppose you are building a new car, and the competitive analysis says that the other cars in this class all have gold monograms on the steering wheel.  When the marketing people try to make “gold monogram on steering wheel” into a requirement, ask, “What function does it serve?”  Most commonly, you’ll get the reply, “It doesn’t serve any function.  It’s just there to match the competitor’s.”[19]

Other telling replies might be, “It’s just there because so-and-so thought it would be nice,” or “Everybody’s doing it.”  Avoid these kinds of justifications!  In some cases, such “gold plating” may be a marketing requirement but it is not a functional requirement.

 

Functional Requirements as Basis for Contractor’s Work Program

 

If you contract with someone to build all or part of your system, you have to let each contractor know what its responsibilities are.  You can use your functional requirements as the basis for generating all Statements of Work (SOWs), and system specifications.  You also should base your evaluation of both technical and cost proposals on how a contractor plans to meet the requirements you describe in any SOW.

 

Requirements Tracing As a Testing and Quality Assurance Method

Experience has shown that the ability to trace requirements all the way through a project, from inception to final implementation, is essential to project success.  Requirements tracing involves two major steps: 1) tracing the requirements to the system or component whose functionality satisfies it; and 2) tracing the tests you plan to conduct to the requirement or function whose correctness and existence it examines.  The first step is necessary so that you know where a functional requirement is satisfied.  The second is necessary so that you know whether a functional requirement is satisfied.  The second step also alerts you to any case where you’ve created a test that’s unnecessary.

 

To trace requirements to where you’ve allocated them, set up a matrix such as the one shown in Figure 5.  There should be a check mark against a subsystem for each requirement.  If there isn’t you’ve failed to account for a requirement.

Figure 5

Requirements Traceability Matrix

Requirements to Subsystems

 

You check to see whether you’re testing for all requirements in the same manner.  You create a second matrix, such as the one shown in Figure 6. The check marks show which tests verify which requirements.  If there are any columns with no check marks, then you aren’t testing that functional requirement.  Either you will have to devise a new test or modify a planned one to ensure that the requirement is tested. Similarly, if a test doesn’t verify any requirement (see test 12 in figure 6), it’s superfluous.  Each matrix shown is an example of a requirements traceability matrix.

 

Of course, this is no replacement for the usual systems engineering and project management tools of Gantt charts, PERT charts, and work breakdown structure for laying out a project plan and schedule.  It’s a good systems engineering practice to tie your project plan and schedule to the functional requirements as well.  You’ll show testing periods on Gantt charts.  Passing a group of tests successfully is a milestone at the end of a testing period.

Figure 6

Requirements Traceability Matrix

Tests versus Requirements

 

6. Managing Functional Requirements

It’s essential to manage functional requirements (and other requirements as well), since some change is inevitable and you must deal it with effectively.  One author gives the following four reasons why you had better be prepared with a good requirements change process:[20]

 

• Because (project) scope creep is lethal.
• Because only fools believe that you can freeze requirements and then build to them, especially in politically sensitive areas such as transportation.
• Because even though you all agree in November, you may not be speaking in January.
• Because all of the parameters of a systems project can change overnight, and the ability to adapt in real time to changing priorities, changing budgets, changing schedules, and changing technologies is not only desirable but absolutely essential.

 

Well thought out functional requirements make the change process much smoother, since the impact of any change on actual system functions will be much clearer.  Requirements expressed in terms of implementation details greatly obscure the effects of changes.

 

We discuss how to manage requirements in this chapter, but first, let’s look at the major project bugaboo -- scope creep.

 

Scope Creep

One major problem you face on almost every project is “scope creep”.  Scope creep is the gradual increase in the number of functions that you have to implement in your system, along with changes in the technical performance measurements for them.  Scope creep typically occurs when someone says, “Can’t we just do a little more here?” or “Would it hurt if we made a small change there?”  or “Can we do it a slightly different way?”  Unfortunately, “small” changes can add up to major architectural changes and, as a result, have major cost and schedule impact.  For this reason, scope creep is often lethal to a project.  Freezing functional requirements is a well-intentioned, but misguided method for avoiding scope creep.  Freezing functional requirements is intended to force everyone to stick to the functional requirements originally agreed upon.  This allows you to avoid having to negotiate and argue about requirement changes throughout the implementation process.  However, the problem with “freezing” functional requirements is that it just doesn’t work!  It’s an impractical solution and no one has ever successfully frozen functional requirements on a project and been able to deliver a satisfactory product.  (Well, maybe “never.”  Maybe somebody’s been able to do it.  If you find that person, introduce us to him or her; we’d like to meet the person who’s been able to do what others have failed miserably at.)

 

So, if you can’t freeze functional requirements and scope creep is fatal, what do you do?  The answer is:  configuration management!

 

Configuration Management

 

The “configuration” in the term configuration management refers to the set of items that make up a system.  These items include documents, hardware, software, procedures, and anything else that makes up the description and embodiment of a system.  Configuration management is the process by which you control changes to this set of system items.  But before we can get to configuration management, we have to discuss the concept of baselining a system.

 

Establishing a System Baseline

 

Systems can have many baselines.  You establish a system baseline when you reach a point where everyone agrees on what the system description contains.  The first time that occurs is when you first establish your agreed-upon functional requirements for the system.  That’s known as the functional baseline.  At this point, you have a requirements document written, reviewed, and accepted by everyone as describing what the system should do.  At this point, you declare the existence of the functional baseline and you put the functional baseline under configuration management.  (We’ll cover what that means in a short while.  Some of the common baselines that the literature[21] of configuration management describes include:

 

·        Functional baseline:  The definition of the problem, the basis for agreements between buyer and seller, the description of the product that will be developed

 

·        Allocated baseline:  The apportionment, to specific hardware and software entities, of the functions that must be performed

 

·        Top-design baseline:  For each software entity, the overall scheme of meeting its requirements

 

·        Detailed design baseline:  For each software entity, the description of how it will be built

 

·        Product baseline:  The definition of each software entity at the time of formal test

 

·        Operational baseline:  The definition of each software entity at any time during its service life

 

Although those descriptions of baselines concentrate on “software,” they’re just as valid at the system level.

 

It really doesn’t matter how many baselines you create during a system implementation project.  However, you must create the first when you first get an agreed-upon set of functional requirements.  If you don’t, then configuration management won’t work.  The baselines change over time, but you control how they change through configuration management.

 

A system baseline is a formal event and the contents of the system baseline are frozen as of the time you establish the system baseline.  That doesn’t mean that you can’t change the system baseline; it means that you only change the system baseline through one of two formal processes:

 

·        System development

·        Change control

 

System development is what you do while you’re moving the project from one phase to another.  After you’ve completed the requirements analysis phase of a project, you move onto the system design phase.  During the system design phase, you’ll allocate requirements to system components, i.e., you’ll decide in what part of the system you’re going to satisfy each requirement.  During this process, you have a formal, frozen baseline, but you’re doing the work that allows you to establish the next baseline, building on the first.  If the first baseline were to change during this process, it would have an effect on the work that you’re doing.  Therefore, you want to avoid changing the existing baseline if at all possible.

 

At the end of the system design phase, you’ll conduct another review, one that gets everyone to examine how you’ve decided to satisfy requirements (i.e., in what part of the system they’ll get handled) and either to agree with your allocation of requirements to system components or to decide as part of the group what allocation to accept.  The final acceptance of a design for the system creates a new baseline and that baseline replaces the old one.  Depending on the size and complexity of your project.  This new baseline incorporates the old one and adds all new documents resulting from the design acceptance as well as anything else that you include in the system baseline at this point.  Whatever the next phase is, you should have a formal review and baseline establishment milestone at the end of it.  Your project should contain a series of review and baseline establishment milestones at the end of every discrete phase of system development.  At the very end of the project, when you go into operation and maintenance of the system, the final delivered version of the system, with all associated documentation, programs, support infrastructure, and everything else that makes the system what it is, becomes the operations and maintenance baseline.

 

In a perfect world, we’d only go forward on a project, from one milestone to the next, never having to review and perhaps modify the work that we did in prior steps.  Unfortunately, that’s not the world of software-based systems.  So what do you do when something comes up that means you have to re-think some or all of an existing baseline?  The answer is configuration management or change control.

 

Change control is what configuration management is all about.  We need to make a change to an established baseline, but we need to do it in a manner that doesn’t disrupt all of the work that we’re doing in whatever system development phase we’re in.  More than that, we need to make sure that whatever change we make gets reflected in all of the pieces of the system that it affects.

 

Let’s say that you’re building a Traveler Information System.  When you started your effort in 1998, you listed Microsoft® Windows 95™ as an allowable operating system for the desktop and laptop computers that are part of your system.  However, now that you’ve reached the final stages of implementing your system, Microsoft has ceased support for the Windows 95™ product and you’re concerned about continuing technical support for this operating system version.  You inventory your desktop and laptop computers and find that about 20% of them still use Windows 95™, despite your organization’s aggressive hardware upgrade policy, which has resulted in newer computers with later operating systems replacing older machines running Windows 95™.  You want to remove Windows 95™ from the list of allowable desktop and laptop operating systems and replace it with Microsoft’s Windows 2000™ as a standard, since that’s Microsoft’s latest business‑oriented PC operating system.  Although many of your current desktop and laptop computers are configured with Windows 2000™, it’s not officially an allowable operating system within your current configuration.  The discussion of allowable PC operating systems appears in many places in your documentation and you also don’t want to make a change without assessing how long it will take, and what it will cost, to upgrade all computers currently running Windows 95 to some later operating system, preferably Windows 2000™.  So what do you do?

 

That’s what we mean by change control.  Let’s discuss how we do this by explaining more about configuration management.

 

Managing the Configuration

 

Configuration management starts with a system baseline.  Then it adds a change control board or CCB.  The CCB decides whether to allow a change or not.  It has absolute power over changes to system baselines.  If the CCB decides “yes,” the baseline gets changed; if the CCB decides “no,” no change occurs.  You, as the project manager, normally chair the CCB.  You also decide who’s going to be part of the CCB, so choose well; these people are going to have significant impact on how your project proceeds.  Usually, if you have a contractor working on the project, the contractor manager also sits on the CCB; this is because changes to project baselines usually have an impact on the contractor’s resources and costs.  If there is a user stakeholder whose stake in the project is major, that stakeholder (or a representative) should sit on the CCB.  Don’t make the CCB too large, however.  If it all possible, keep membership to 3-5 people, no more than 7.  Groups larger than that are less effective and can be hard to get together when you need them to make decisions on potential changes to baselines.

 

There’s a formal process that you go through when deciding to make a change.  The process consists of the following steps:

 

1.      Someone proposes a change to the baseline.  Anyone can propose a change to the baseline, but whoever proposes the change must state exactly what change is being proposed and why the change is needed.  The easiest type of proposed change to understand is when someone detects an error in an item under configuration control.  During operation of the system, for example, if a program fails, i.e., has an error condition occur, you’d propose a change to get the program fixed and a new, corrected version put into production use.  In the development stages, it’s less easy to know what can cause a change.  But legislation could cause a change, for example.  If there is now a legal requirement for the system to perform that wasn’t in force before, that’s a strong and legitimate reason for the change.

 

2.      The impact of the change is assessed.  When a change is proposed, someone has to evaluate it and determine how much impact implementing it will have on the project.  Deciding whether to implement the change is the CCB’s decision; however, someone other than the CCB usually assesses the change’s impact.  The people closest to the problem are the ones who should perform the assessment.  This usually means the project team working on the subsystem or component for which the change is being proposed.

 

The assessment that this team performs has three major axes to consider: value to the project, impact on project schedule, and impact on project cost.  Consider Figure 7, which tries to show the assessment graphically.  Let’s assume that we assessed each axis on a simple scheme of rating the values on each axis either “high,” “medium,” or “low.”  That means there are 27 possible combinations.  The ideal situation is a change that has a high value, and low cost and schedule impacts.  The worst-case scenario is a change that has low value and high cost and schedule impacts.  It’s unlikely that you’ll have cases that are that clear cut.  And there is also the issue that you have to consider the cumulative impact of proposed changes.  Sometimes a lot of “small” changes can have a large cumulative (negative) effect on project cost and schedule.

 

3.      The analysts provide a recommendation to the CCB.  The team that’s asked to assess a proposed change isn’t just asked to determine value, and cost and schedule impact.  It’s also asked to make a recommendation to the CCB on what action it should take.  The CCB doesn’t have to accept the recommendation, but it does give the CCB a context in which to make a decision.

 

Possible actions that the analysts can recommend include:  accept and implement the proposed change; reject the proposed change; defer the proposed change; defer the decision.  The last recommendation is only made if the project team needs more time to complete its analysis.  The CCB usually accepts that
recommendation, but asks fora specific time when the project team will have its final recommendation ready.

 

 

4.      The CCB makes its decision.  After the CCB considers the analysts’ recommendation and develops its own understanding of the implications of the change, it decides what it wants to do.  A decision to accept the proposed change means that the project team has to modify the baseline.  A decision to reject the proposed change still causes work, because the decision should be explained to the person or organization that proposed the change.

 

5.      The decision is implemented.  If the decision was to accept the proposed change, the project team has to go through the entire set of items that form the existing baseline and ensure that the accepted change is reflected correctly in all of them.  This can be a lot of work, particularly if the change is a major one.  And after the change is made, the change needs to be communicated to everyone on the project and everyone who has copies of configuration-controlled items related to the project.  That’s the value of configuration management -- the fact that the change is made to all controlled items and then communicated to everyone that it affects.  Of course, if the decision was not to accept the change, the only thing that needs to be done is to tell the proposer why it wasn’t.  That can have its own set of headaches.

 

Seem simple?

 

To some extent, it is.  Configuration management isn’t rocket science.  It is hard work and that’s a reason that it can be overlooked on ITS projects.  It may seem overly rigid and formalistic, but our experience is that it is highly effective.  If we haven’t convinced you to practice it on your project, that’s OK.  Experience is a good teacher.  It may be a painful teacher, but what you learn through experience you usually retain for a long time.  But it takes a while for the scars to heal.

7. Where to Go to Get More Help

 

Department of Transportation Resources

 

Electronic Document Library (EDL)

 

The Department of Transportation (DOT) maintains an ITS Electronic Document Library (EDL) on its web site (www.itsdocs.fhwa.dot.gov).  You can search the site’s electronic index to find examples of different types of requirements-related documents.  Two types are:

 

• Requirements documents written for other projects, e.g., ATIS and CVO Development Objectives and Performance Requirements
• Deployment guidance documents, e.g., Developing Traffic Signal Control Systems Using the National ITS Architecture

 

National ITS Architecture Web Site and CD-ROM

 

The National ITS Architecture is available on both a web site maintained for DOT (www.iteris.com/itsarch) and on CD-ROM.  Both sources provide you a searchable, hyperlinked version of the National ITS Architecture documentation.

 

Turbo Architecture

 

There is an automated tool, known as Turbo Architecture, maintained by McTrans at the University of Florida (www-mctrans.ce.ufl.edu).  Turbo Architecture is a high-level, interactive software program designed to assist transportation planners and system integrators, in both the public and private sectors, in developing regional and project architectures using the National ITS Architecture as a starting point.  See the McTrans web site for additional information, including how to acquire the product.

 

Software Tools

While there are a number of tools available to help with the process of determining requirements, such as brainstorming, decision trees, interviewing techniques, meetings, right-brain methods, technical reviews, context-free questions, and user satisfaction tests,[22] there are no software tools available dedicated solely to developing and managing requirements.  Most software tools, such as Computer Aided Software Engineering (CASE) and Computer Aided Design (CAD) tools, are geared to the overall systems engineering process, rather than to the requirements development phase.  However, many CASE tools can manage the development of requirements and requirements documents.  You should use tools that, as a minimum, let you capture requirements electronically.  In most cases, you actually write functional requirements with a word processing program, since you’ll want to distribute the requirements document to all stakeholders, and everyone can read standard word processing document formats.  If you plan to contract out some or all of the work, then you’ve have to send the document to prospective offerors.

We prefer not to recommend specific tools, as this might seem to be an endorsement of them.  However, you can find considerable information on systems engineering tools at the International Council on Systems Engineering (INCOSE) web site’s tools database page.  The location is www.incose.org/tools/.  The information is organized by INCOSE project, as follows:

 

·        SE Tool Surveys

 

-         Requirements Management Tools Survey (Updated May 2000)

-         Systems Architecture Tools Survey

-         Measurement Tools Survey (Updated June 2000)

-         Vendors who have responded to previous surveys

 

·        SE Tool Databases

 

-         Tools Database by Name (Updated February 2000)

-         Tools Database by Vendor (Updated February 2000)

 

·        SE Tools by Taxonomy

 

-         Tools Database by IMPIG Taxonomy

-         Tools Database by EIA-632 Taxonomy

-         Tools Database by IEEE-1220 Taxonomy

 

The INCOSE web site, because it is operated by an organization whose purpose it is to disseminate systems engineering information, may contain the most objective and complete list of systems engineering tools available.  However, note the dates (as of this writing) on which the various “projects” were updated.  Check this site to see how dated the information is.

 

In addition, the book by Andriole, Managing Systems Requirements: Methods, Tools, and Cases, contains an extensive list of tools for all phases of systems analysis.  However, the list is very dated and many tools listed are either no longer available or the vendor has gone out of business.  This is one of the problems of providing a static list of tools in a printed document, book, or report.  After a short while, the list becomes obsolete.  Software engineering tool development is an area of considerable development and work.  Web sites usually contain more up-to-date information.  For example, use web sites such as cnet.com (www.cnet.com) to find discussions of available tools, along with recommendations from the site’s owner on the tools.  Recognize, however, that any web site that offers recommendations is only offering the opinions of the people making the recommendations.

Appendix A
Example Table of Contents
for a
Functional Requirements Document

 

The following table of contents for a functional requirements document is taken from the functional requirements document for the Gary-Chicago-Milwaukee Corridor Multi-modal Traveler Information Systems Functional Requirements Document[23].  It illustrates the type and breadth of information that one should include in a good functional requirements document.  The document is used as an example because it follows the guidance in IEEE Standard 1233:1998, IEEE Guide for Developing System Requirements Specifications.

 

1.      Introduction

1.1.            Project Overview

1.2.            Purpose

1.3.            Goals

1.4.            Intended Audience

1.5.            Document Organization

1.6.            Terminology

1.7.            Definitions, Acronyms, and Abbreviations

1.8.            Related Documents and Working Papers

 

2.      Gateway Overview

2.1.            Introduction

2.2.            Objectives

2.3.            National ITS Architecture

2.4.            NTCIP

2.5.            LRMS

2.6.            Corridor Architecture

2.6.1.         Phased Approach

2.6.2.         Corridor Definition

2.6.3.         Regional Hubs

2.6.4.         Gateway

2.7.            GCM Data Pipe

2.8.            Data Providers

 

3.      System Requirements

3.1.            Data Acquisition Subsystem

3.2.            Data Validation and Fusion Subsystem

3.3.            Data Access Subsystem

3.4.            Data Distribution Subsystem

3.5.            Monitoring Subsystem

3.6.            Administrative Subsystem

3.7.            Operator Interface

3.8.            Cooperative Control Pass Through

3.9.            Operation

3.10.        Backups

3.11.        Data Users

3.12.        GCM Corridor Object Model

3.13.        Data Types Supported

3.13.1.     Detector Data

3.13.2.     Travel Times

3.13.3.     Incidents

3.13.4.     Construction/Maintenance Events

3.13.5.     VMS

3.13.6.     Weather and Road Conditions

3.13.7.     Traffic Signal Data

3.13.8.     Ramp Meters

3.13.9.     Transit Schedules and Transit Schedule Adherence

3.13.10. Voice

3.13.11. Video

3.13.12. Airport Data

3.14.        Transfer Techniques Supported

3.15.        Location Referencing Requirements

 

4.      General Requirements

4.1.            National Standards Compliance

4.2.            Open Systems

4.3.            Topology

4.4.            Object Orientation

4.5.            Flexibility

4.6.            Scaleability

4.7.            Adaptability

4.8.            Security

4.9.            Reliability

4.10.        Fault Detection and Scalability

4.11.        Performance

4.12.        Error Detection

4.13.        Privacy

4.14.        Support for Future Technologies

 

5.      Hardware Requirements

5.1.            Performance

5.2.            Reliability

5.3.            Safety

5.4.            Testing

5.5.            Server Machines

5.6.            System Components

5.7.            Main Storage

5.8.            Off-Line Storage

5.9.            Local Area Network

5.10.        Printer

5.11.        Workstation Machines

5.12.        Large Screen Display System

5.13.        Operating Environment

5.14.        Power

5.15.        Startup/Shutdown

 

6.      Commercial Software

6.1.            Overall Requirements

6.2.            Operating System

6.3.            Graphical User Interface (GUI)

6.4.            Networking Support

6.5.            Database

6.6.            Relational Database Requirements

6.7.            Object Oriented Database Requirements

6.8.            Interprocess Communications

6.9.            Web Server

6.10.        Pass Through

6.11.        Testing

 

7.      Gateway Developed Software

7.1.            Implementation Language

7.2.            Implementation Model

7.3.            Software Engineering Requirements

7.4.            Design Phase Requirements

7.5.            Testing

 

8.      Web Interface

 

9.      Communications Requirements

9.1.            Communications Functions

9.1.1.         Video

9.1.2.         Voice

9.1.3.         Data

9.2.            Gateway Requirements

9.2.1.         Wide Area Network Requirements

9.2.2.         Local Area Network Requirements

9.2.3.         Internet Requirements

9.2.4.         Internet Service Provider (ISP) Requirements

9.3.            Illinois Regional Hub Requirements

9.3.1.         Wide Area Network Requirements

9.3.2.         Local Area Network Requirements

9.3.3.         Internet Requirements

9.3.4.         ISP Requirements

 

10.  Illinois Regional Hub

 

11.  ISP Server

 

 

 

Appendix B
Glossary of Terms

Architecture.                           Highest level structural and functional organization of a system.  Comprises subsystems and their interconnection.  The National ITS Architecture defines the functions that must be performed, the Subsystems that provide these functions, and the information that must be exchanged to support defined User Services.

Boundary                                 Edge of a system, the point beyond which system functions are not defined.  Only interfaces with other systems are defined at the system boundary.

Derived Requirement              (1) A requirement that is further refined from a primary source requirement.  (2) A requirement that results from choosing a specific implementation for a system element.[24]

Equipment Package                Building blocks of the Physical Architecture subsystems in the National ITS Architecture. Equipment Packages group like processes of a particular subsystem together into an “implementable” package. The grouping also takes into account the user services and the need to accommodate various levels of functionality.

Function                                  One or more coordinated processes or operations designed to achieve a particular goal.

Functional Requirement.        Requirement for a system expressed in terms of what the system is expected to do, without reference to how the system will be designed or implemented.

Interface                                  Connection of a system or process with the outside world or with another internal system.

Logical Architecture               Functions comprising the architecture, without reference to their partitioning among platforms or subsystems.

Market Package                     Particular grouping of entities defined in the Physical Architecture corresponding to specific transportation services.

Physical Architecture              Functions comprising the architecture partitioned among the platforms where they will be implemented. Physical Architecture is comprised of transportation, communications, and institutional layers.

Primary Requirement              A requirement that comes from a primary source or stakeholder, e.g., acquirer, user, customer, manufacturer, installer, tester, maintainer.  Also known as a Primary Source Requirement

Primary Source Requirement  See Primary Requirement

Process                                    A series of actions to bring about a desired result.  May be performed in hardware, software, or both.

Program Requirements           Specify the process to be followed by the vendor, and the various non-performance requirements and regulations with which the vendor must comply.  These include compliance with federal, state or local laws; compliance with environmental and safety regulations; administrative requirements such as security.

Requirement                            A function that must be performed by a system, together with all quantitative measures pertaining to it.

System                                     Interconnected set of components and subsystems, including hardware and/or software, designed to implement a function or achieve a goal.

Systems Engineering               Discipline that uses orderly, consistent, and systematic quantitative methods to ensure that systems are built to meet all requirements. 

Technical Requirements          Specify the product, service, or system to be delivered according to the contract.  Technical requirements include functional requirements, design constraints, and interface requirements

User Needs                              Describe what the user of the final system desires or requires the system to do in order to provide a benefit, or correct a current problem.

Appendix C
References

 

Andriole, Stephen J., Managing Systems Requirements: Methods, Tools, and Cases, New York: McGraw Hill, 1996.

 

Carroll, Lewis (pseudonym of Charles L. Dodgson), Alice’s Adventures in Wonderland, Leicester, England: Gallery Press, 1988

 

DeLeuw, Cather & Company, in association with JHK Associates, Gary-Chicago-Milwaukee (GCM) ITS Priority Corridor Multi-Modal Traveler Information System Gateway Functional Requirements, Document #17250.02, Issued November 17, 1997

 

Dunn, Robert and Richard Ullman, Quality Assurance for Computer Software, New York: McGraw Hill, 1982

 

Gause, Donald, and Weinberg, Gerald, Exploring Requirements, Quality Before Design, New York: Dorset House, 1989.

 

Graham, Ian, Requirements Engineering and Rapid Development, Harlow, England: Addison Wesley Longman, 1998.

 

Institute for Electrical and Electronic Engineers, IEEE Std. 1233:1998, IEEE Guide for Developing System Requirements Specifications, New York: The Institute for Electrical and Electronics Engineers, 1998

 

ITS Mission Definition document, December, 1999.

 

Kar, Pradip, and Bailey, Michelle, “Characteristics of Good Requirements”, 6^th INCOSE Symposium.

 

Kovitz, Benjamin, Practical Software Requirements, Greenwich, CT: Manning Publications, 1999.

 

Martin, Charles F., User-Centered Requirements Analysis, Englewood Cliffs: Prentice‑Hall, 1988.

 

Martin, James N., Systems Engineering Guidebook: A Process for Developing Systems and Products, Boca Raton, FL: CRC Press, 1997.

 

Mitretek Systems, Building Quality Intelligent Transportation Systems Through Systems Engineering.

 

Mitretek Systems, Understanding Software Development: A Primer for ITS Public Sector Managers.

 

Sommerville, Ian, and Sawyer, Pete, Requirements Engineering, A Good Practice Guide, Chichester: Wiley & Sons, 1997.

 

The Project Management Forum, Wideman Comparative Glossary of Common Project Management Terms, V. 2.0. www.pmforum.org/library/glossary/PMG_F03.htm

 

Using the National ITS Architecture For Deployment, course.