This is the Department of Transportation logo.

 

Developing Functional Requirements

for ITS Projects

 

April 2002

 

This is a picture of the V diagram that illustrates the concept of systems engineering, overlayed with icons that represent transportation and transit. The icons are a traffic light, a transit rail train, a bus, and vehicles on a road. The V diagram shows different phases of a systems life cycle, with early stages going down the left hand side of the V, pointing downward, with the implementation phase at the bottom of the V, and with the later stages going up the right hand side of the V. The V diagram is explained in the text of the document.

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:

 

 

 

 

 

 

 

 

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.

  This figure shows the relative cost to fix an error, depending on the project phase. There are 6 phases shown: requirements, design, coding, development, acceptance testing, and operation. The cost to fix an error in requirements is $1; the cost then rises until, in operation, the cost to fix an error rises to as much as $1000. The data in this figure also appears in Table 2 of the document.


Figure ES-1

Relative Cost to Fix an Error, by Project Phases

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:

  This figure, in the shape of the letter V, depicts the different stages of the system life cycle. There are arrows showing the direction in which time flows during the life cycle, with an arrow pointing down along the left hand side of the V, one moving from left to right along the bottom of the V, and one pointing upward along the right hand side of the V. Moving down the left hand side of the V are the following steps, with the order being the order in which the steps are performed: Concept of Operations, High Level Requirements, Detailed Requirements, High Level Design, and Detailed Design. Along the bottom of the V is the Implementation step. Rising on the right hand side of the V are the following steps: Integration and Test, Subsystem Verification, System Verification, and Operation and Maintenance.


 


Conception (Concept of Operations stage) vs. Operations and Maintenance.  During the Conception stage of the system life cycle, you create a Concept of Operations for the system.  The Concept of Operations should describe how the system will work once it’s built.  Therefore, it relates directly to the Operation and Maintenance stage, during which the system’s Concept of Operations is realized.