Module 4 - A103

A103: Introduction to ITS Standards Requirements Development

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

 

"A103 Introduction to ITS Standards Requirements Development." See extended text description below.

(Extended Text Description: Cover page graphic including title “A103 Introduction to ITS Standards Requirements Development” with blue background, three diagonal lines in the middle of the page in lighter blue, at the lower middle left side there is a logo with a white background square with words “Standards ITS Training” and “Student Supplement” under the white logo box. Directly under this are words “RITA Intelligent Transportation Systems Joint Program Office.”)

A103: Introduction to ITS Standards Requirements Development

Table of Contents

Purpose 3

1 Defining Requirements for Overall Operation to Satisfy User Needs 3

2 Well-Formed Requirements 6

3 Defining the System and Interfaces as Functional Architecture 8

4 Using Decomposition of the Architecture and Requirements as Necessary to Properly Define the System 11

5 Verifying that Requirements are Complete and Correct 11

6 How Requirements Development Applies to ITS Communication Standards 13

References 14

 

PURPOSE

This participant outline provides supplemental information for the Professional Capacity Building (PCB) Module A103. In some cases, additional information is included within the supplement. In other cases, references are provided for more in-depth study. Some information may be repeated from the module for context.

Module A103 introduces what requirements are, where they fit in the project life cycle, how they are used to satisfy user needs and how to determine if they are correct. In A103, participants learn:

  1. To define requirements for overall operation to satisfy user needs
  2. The concept of a well-formed requirement
  3. To define the system and interfaces as a functional architecture
  4. To use decomposition of the architecture and requirements as necessary to properly define the system
  5. To verify that requirements are complete and correct
  6. How requirements development applies to ITS communication standards

The remainder of this supplement is organized based upon these learning objectives and concludes with general references and a glossary.

 

1 DEFINING REQUIREMENTS FOR OVERALL OPERATION TO SATISFY USER NEEDS

Systems Life-Cycle and the Systems Engineering Process (SEP)

"Systems Life-Cycle and the Systems Engineering Process (SEP)" See extended text description below.

(Extended Text Description: “Systems Life-Cycle and the Systems Engineering Process (SEP).” A graphic of the systems engineering process (SEP). The main graphic of the SEP is a V-shaped diagram in gradated blue with some additional horizontal extensions on the left and right side of the top of the V shape. Each section is separated with dark blue lines. There is a key at the lower right showing the blue separator lines, and designating them as “Document/Approval.” The left horizontal extension is labeled as “Lifecycle Processes” and include the sections “Regional Architecture” (separated by a white space) to the second section labeled “Needs Assessment,” (blue line) “Concept Selection,” (blue line) “Project Planning,” (blue line) and “Systems Engineering Management Planning.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Subsystem Requirements,” “Detailed Design,” and “Software Coding / Hardware Fabrication” at the bottom juncture of the V shape. Underneath the bottom point of the V shape are the words “Implementation” then “Development Processes” and a long thin arrow pointing to the right labeled “Time Line.” There is a long thin diagonal arrow pointing down along the left side of the V labeled “Decomposition and Definition.” From the bottom point of the V, the sections begin to ascend up the right side of the V with “Unit Testing,” (blue line) “Subsystem Integration,” (blue line) “Subsystem Verification,” (blue line) “System Integration,” (blue line) “System Verification,” (blue line) “Initial Deployment,” (blue line) “System Validation,” and (blue line) “Operations and Maintenance.” There is a long thin arrow pointing up along the right side of the V shaped labeled “Integration and Recomposition.” At this point the sections on the right “wing” of the V are labeled with “Changes and Upgrades” and (white space) “Retirement/Replacement.” Between the V shape there are a series of gray dashed arrows connecting the related sections on each left/right side of the V shape. The first arrow (top) is labeled “System Validation Plan” and connects “Concept of Operations” on the left and “System Validation” on the right. The second arrow is labeled “System Verification Plan (System Acceptance)” and connects “System Requirements” on the left and “System Verification and Deployment” on the right. The third arrow is labeled “Subsystem Verification Plan (Subsystem Acceptance)” and connects “High-Level Design” on the left and “Subsystem Verification” on the right. The last arrow (at the bottom) is labeled “Unit/Device Test Plan” and connects “Detailed Design” on the left and “Unit/Device Testing” on the right. The slide has animation.  As the instructor discusses each of the development processes, a circle is drawn around the process on the V diagram.)

https://ops.fhwa.dot.gov/publications/seitsguide/section3.htm#s3.3 https://ops.fhwa.dot.gov/publications/seitsguide/

Definition of Systems Engineering

  • Systems engineering (SE) is an interdisciplinary approach and a means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost, and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (International Council on Systems Engineering (INCOSE) Systems Engineering Handbook)
  • An interdisciplinary collaborative approach to derive, evolve, and verify a life-cycle balanced system solution that satisfies customer expectations and meets public acceptability. (Institute of Electrical and Electronics Engineers (IEEE))

Components of a Concept of Operations

  • See IEEE Standard 1362-1998.
  • See Federal Highway Administration (FHWA) Systems Engineering Guidebook V3.
  • See ANSI/AIAA G-043-1992.

Definitions of a Requirement

  • A statement that identifies a system, product or process' characteristic or constraint, which is unambiguous, clear, unique, consistent, standalone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability. (INCOSE Systems Engineering Handbook)
  • A translation of needs into a set of individual quantified or descriptive specifications for the characteristics of an entity in order to enable its realization on examination. (ISO/IEC Guide 25: 1990)

Types of Requirements

  • Functional requirements
    • What the system shall do.
    • Example from the Dynamic Message Sign (DMS) Standard

    3.4.2.6 Determine Total Number of Events
    The DMS shall allow a management station to determine the total number of events that the DMS has logged since powerup.

  • Performance requirements
    • How well the requirements should perform.
    • Example from the Transportation Sensor System (TSS) Standard

    3.4.2.6 Determine Total Number of Events
    The TSS shall process the Get, GetNext, or Set request in accordance with all of the rules of NTCIP 1103 v02, including updating the value in the database and initiating the transmission of the appropriate response, within 1 second of receiving the last byte of the request.

  • Interface requirements
    • Definition of the interfaces.
    • Example from the NEMA TS 2 Standard:

    3.3.1.3 Data and Clock Communications Protocol The transfer of data shall take place over the data and clock links by means of the SDLC (Synchronous Data Link Control) Protocol, as defined by International Business Machines Corporation document GA27-3093-3, dated June 1986.

  • Data requirements
    • Definition of the data contained in or interfacing to the system.
    • Example from the Traffic Management Data Dictionary (TMDD) Standard:

    3.3.1.4.1.1 Required Error Report Contents

    The error report sent from a receiving center to a sending center shall include:

    a. Unique identifier of the receiving organization;
    b. Unique identifier of the sending organization;
    c. Unique error identifier; and
    d. Error text.

  • Non-Functional requirements
    • Requirements in areas such as reliability, safety, and environmental.
    • Example from the ITS Cabinet Standard:

    5.1.26 Operating Ambient Temperature

    The TFCS's shall have an operating ambient temperature range from -37 degrees Celsius to +74 degrees Celsius.

  • Enabling requirements
    • Requirements that have to do with production, development, testing, training, support, deployment, and disposal.
    • Example from the National Electrical Manufacturers Association (NEMA) TS 2 Standard:

    2.1.6 Transients, Power Service

    The CA shall maintain all defined functions when the independent test pulse levels specified in 2.1.6.1 and 2.1.6.2 occur on the alternating-current power service.

  • Constraints
    • Anything that constrains the development or system that are not already covered by the other areas (e.g. a particular technology, design, tools, and/or standards to be used).
    • Example from the ATC Application Programming Interface (API) Standard:

    3.4.2 Programming Language

    The API function calls shall be specified using the C programming language as described by "ISO/IEC 9899:1999," commonly referred to as the C99 Standard.

     

2 WELL-FORMED REQUIREMENTS

Definition of a Well-Formed Requirement

  • A statement of system functionality (a capability) that can be validated and that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and is qualified by measurable conditions and bounded by constraints. (IEEE Standard 1233, 1998 IEEE Guide for Developing System Requirements).

WELL-FORMED REQUIREMENT

The Form: [Actor] [Action] [Target] [Constraint] [Localization]

Where:

Actor Identifies who or what that does the action

Action Identifies what is to happen

Target Identifies who or what receives the action

Constraint Identifies how to measure success or failure of the requirement

Localization Identifies the circumstances under which the requirement applies

Localization and constraint portions are important but not all requirements will have both

Example: The system [Actor] shall generate [Action] event reports [Target] containing the following information [Constraint] on a scheduled interval [localization]

If a requirement can't be stated in this simple format, you probably need to define the functionality using multiple requirements

 

Characteristics of Well-Formed Requirements

  • Necessary
    • Must be useful and traceable to needs.
  • Concise
    • Minimal, understandable, and expressed in a declarative language (i.e., "shall" statements).
  • Attainable
    • Realistic to achieve within available resources and time.
  • Standalone
    • The requirement is stated completely in one place. Not grouped.
  • Consistent
    • Does not contradict itself, nor any other stated requirement.
  • Unambiguous
    • Susceptible 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.

 

3 DEFINING THE SYSTEM AND INTERFACES AS FUNCTIONAL ARCHITECTURE

Functional Architecture

  • The parts are sometimes called "functional elements"
  • Not a design drawing
  • Provides a structure for describing operations in terms of where the operations will be carried out
  • Describes what the lines of communication will be
  • Many ways to represent an architecture

Example #1 - Architecture Diagram from the ITS Cabinet V2 Standard

"Example #1 - Architecture Diagram from the ITS Cabinet V2 Standard" See extended text description below.

(Extended Text Description: “Example #1 Architecture Diagram from the ITS Cabinet V2 Standard.” This is a graphic illustrating an example of a functional architecture diagram.  The diagram is divided into three sections horizontally by two bold vertical dotted lines.  The middle section uses about 60% of the width of the page.  The two side sections use about 15% of the page width.  The left section has two rectangular boxes labeled “Field Sensors” and “Field Displays & Other Devices” respectively.  The right section has three rectangular boxes labeled “Central System or Other TFCS,” “External Reporting System” and “External Power” respectively.  The center section had eight circles of various circles representing the functional elements of the ITS Cabinet Functional Architecture.  They are labeled “Field Inputs,” “External Communications,” “Application Computer,” “System Reporting,” “Field Outputs,” “Cabinet Monitoring,” “Power Filtering & Distribution,” and “TFCS Components” respectively.  There are labeled arrows showing the flow of information through the boxes and circles.  Author's Note: The point is not the details but the style of the functional diagram.)

Example #2 - Architecture Diagram from the NTCIP 1208 CCTV Standard

"Example #2 - Architecture Diagram from the NTCIP 1208 CCTV Standard" See extended text description below.

(Extended Text Description: “Example #2  Architecture Diagram from the NTCIP 1208 CCTV Standard.” This is a graphic illustrating a second example of a functional architecture diagram.  It has a rectangular dotted line around the graphic that takes up about 75% of the width of the page.  The diagram has the following five lines of text in the upper right corner of the diagram: “Applicable Market Packages:,” “Network Surveillance,” “Surface Street Control,” “Freeway Control,” and “Incident Management.” In the upper left of the diagram there is a rectangle that takes up about 1/3 of the total diagram.  At the top of the rectangle are the words “Traffic management Subsystem (TMS).”  There is a dark oval with illustrations of three computer towers and a single computer monitor.  The remainder of the diagram has labeled boxes of various sizes representing various functional elements of a Closed Circuit Television system.  There are lines connecting the various boxes and the TMS box.  The lines are labeled with a mixture of technology and data types used between the functional elements. Author's Note: The point is not the details but another style of a functional diagram.)

Example #3 - Architecture Diagram from the NTCIP 1213 ELMS Standard

"Example #3 - Architecture Diagram from the NTCIP 1213 ELMS Standard" See extended text description below.

(Extended Text Description: “Example #3  Architecture Diagram from the NTCIP 1213 ELMS Standard.” This is a graphic illustrating a third example of a functional architecture diagram.  It has a rectangular dotted line with rounded corners as the boundary of the graphic.  At the bottom inside the boundary is the text “Electrical and Lighting Management System (ELMS).”  There are two rectangles inside the graphic boundary with dotted lines and rounded corners. The left rectangle takes up about 1/3 of the diagram.  At the bottom of the rectangle it has the text “AT MANAGEMENT CENTER LOCATION.”  In the middle of the rectangle there is a desktop computer illustration with the text “ELMS Management Station” underneath it. The right rectangle takes up about 2/3 of the diagram.  At the bottom of the rectangle it has the text “AT FIELD LOCATION.”  There is a box labeled “ELMS Device.”  There are labeled boxes of various sizes to the right representing other functional elements of the ELMS field equipment.  There is a laptop computer illustration below the “ELMS Device” box.  There is a single line labeled “NTCIP” between the “ELMS Management Station” desktop computer and the “ELMS Device” box.  There is a single line labeled “NTCIP” between the “ELMS Device” box and the “ELMS Management Station” laptop computer.  There are various other labeled lines between the “ELMS Device” box and the other functional element boxes to the right of it. Author's Note: The point is not the details but another example of a functional diagram.)

 

4 USING DECOMPOSITION OF THE ARCHITECTURE AND REQUIREMENTS AS NECESSARY TO PROPERLY DEFINE THE SYSTEM

There are many ways to organize requirements. Below are three examples.

Example #1 - By Feature

3.2 System features

3.2.1 System Feature 1

3.2.1.1 Introduction/Purpose of feature

3.2.1.2 Stimulus/Response sequence

3.2.1.3 Associated functional requirements

3.2.1.3.1 Functional requirement 1

...

3.2.1.3.n Functional requirement n

...

3.2.2 System feature 2

3.2.m System feature m

 

Example #2 - By User Class

3.2 Functional requirements

3.2.1 User class 1

3.2.1.1 Functional requirement 1.1

...

3.2.1.n Functional requirement 1.n

3.2.2 User class 2

...

3.2.m User class m

3.2.m.1 Functional requirement m.1

...

3.2.m.n Functional requirement m.n

 

Example #3 - By Mode

3.2 Functional requirements

3.2.1 Mode 1

3.2.1.1 Functional requirement 1.1

...

3.2.1.n Functional requirement 1.n

3.2.2 Mode 2

...

3.2.m Mode m

3.2.m.1 Functional requirement m.1

...

3.2.m.n Functional requirement m.n

 

5 VERIFYING THAT REQUIREMENTS ARE COMPLETE AND CORRECT

Traceability for Verifying Requirements

  • A tool used to help verify completeness and correctness
  • Every need must be addressed by at least one requirement
  • Every requirement must trace to at least one need
  • Any need that is not addressed by at least one requirement means:
    • A requirement was missed, or
    • The user need must be reevaluated
  • Every requirement that does not address at least one need means:
    • The requirement must be reevaluated, or
    • A user need was missed
  • Every aspect of each user need should be addressed in requirements

 

There are numerous types of traceability matrices used in ITS Standards, from the simple to the complex. Below are some examples.

Example #1

Requirements Traceability Matrix (RTM) traces requirements to the design elements of the standard. In this case, the design elements include the dialog (sequence of data exchanges) and objects (data elements) that are used to fulfill the requirement.

Requirement ID

Requirement

Dialog ID

Dialog

Object ID

Object

3.4.1.3.8

Execute Pending Configuration

4.3.1.3

Execute Pending Configuration Change

5.2.1 sensorSystemReset

5.2.2 sensorSystemStatus

3.4.1.3.9

Abort Pending Configuration

4.3.1.4

Abort Pending Configuration

5.2.1 sensorSystemReset

5.2.2 sensorSystemStatus

3.4.1.3.10

Validate Pending Configuration

4.3.1.5

Validate a Pending Configuration

5.2.1 sensorSystemReset

5.2.2 sensorSystemStatus

Example #2

Protocol Requirements List (PRL) traces user needs to requirements. It indicates whether the requirement is mandatory, optional, or if there is some conditional conformance to the standard. It then provides a checklist on whether users want to include the requirement in their project. The PRL also provides for other information to be added for further specification or if instructive information is necessary.

User Need Section Number

User Need

FR Section Number

Functional Requirement

Conformance

Support/Project Requirement

Additional Specifications

2.5.2.1

Reset the TSS

3.4.1.3.1

Restart the TSS

M

Yes

3.4.1.3.2

Reinitialize User Settings

M

Yes

3.4.1.3.3

Restore Factory Defaults

M

Yes

3.4.1.3.4.

Retune

M

Yes

3.4.1.3.8

Execute Pending Configuration

O.1

Yes/No

3.4.1.3.9

Abort Pending Configuration

O.1

Yes/No

3.4.1.3.10

Validate Pending Configuration

O.1

Yes/No

2.5.2.2

Initiate S

ensor Diagnostics

3.4.1.3.6 Short Diagnostics

M

Yes

3.4.1.3.7 Full Diagnostics

M

Yes

 

6 HOW REQUIREMENTS DEVELOPMENT APPLIES TO ITS COMMUNICATION STANDARDS

Contents of ITS Standards With SEP Content

  • General
  • Concept of Operations (ConOps)
  • Functional Requirements
  • Design Details
    • Dialogs and Interface Specifications
    • Object Definitions (MIB)
  • Annexes
    • Traceability Matrices
    • Test Procedures (in some standards only)
    • Documentation of Revisions

Contents of ITS Standards Without SEP Content

  • Overview
  • General Information
  • Object Definitions (MIB)
  • Conformance Groups
  • Conformance Statement

PCB Modules on Standards With SEP Content

  • Dynamic Message Signs
    • A311A Understanding User Needs for DMS Systems Based on NTCIP 1203 Standard
    • A311B Specifying Requirements for DMS Systems Based on NTCIP 1203 Standard
  • Environmental Sensor Systems
    • A313A Understanding User Needs for ESS Systems Based on NTCIP 1204 v03 Standard
    • A313B Specifying Requirements for ESS Systems Based on NTCIP 1204 v03 Standard
  • Transportation Management Data Dictionary
    • A321A Understanding User Needs for Traffic Management Systems Based on TMDD v03 Standard
    • A321B Specifying Requirements for Traffic Management Systems Based on TMDD v03 Standard

A203 Module on Writing Requirements When ITS Standards Do Not Have SEP - You will:

  • Identify different types of requirements
  • Understand that requirements development is a process
  • Avoid pitfalls when writing requirements
  • Write requirements when an ITS communication standard does not have SEP information
  • Use traceability matrices as tools for requirements development

ITS Device Communications Standards With SEP Content

  • NTCIP 1203 Object Definitions for Dynamic Message Signs (DMS)
  • NTCIP 1204 Environmental Sensor Station Interface Standard (ESS)
  • NTCIP 1209 Data Element Definitions for Transportation Sensor Systems (TSS)
  • NTCIP 1210 Field Management Stations - Part 1: Object Definitions for Signal System Masters (FMS)
  • NTCIP 1211 Object Definitions for Signal Control and Prioritization (SCP)
  • NTCIP 1213 Object Definitions for Electrical and Lighting Management Systems (ELMS)

ITS Device Communications Standards Without SEP Content

  • NTCIP 1201 Global Object (GO) Definitions
  • NTCIP 1202 Object Definitions for Actuated Traffic Signal Controller Units (ASC)
  • NTCIP 1205 Object Definitions for Closed Circuit Television (CCTV) Camera Control
  • NTCIP 1206 Object Definitions for Data Collection and Monitoring (DCM) Devices
  • NTCIP 1207 Object Definitions for Ramp Meter Control (RMC) Units
  • NTCIP 1208 Object Definitions for Closed Circuit Television (CCTV) Switching
  • NTCIP 1212 Object Definitions for Network Camera Operation

REFERENCES

Web sites for ITS Standards

Web sites for Systems Engineering Development

Guides that Use the Systems Engineering Process

  • NTCIP Guide
  • TMDD Guide
  • IEEE 1512 Guide

Specific Texts, Documents, and Standards

  • International Council on Systems Engineering. Systems Engineering Handbook Version 3.2. January 2010.
  • Alexander, Ian and Ljerka Beus-Dukic. Discovering Requirements. Wiley, 2009.
  • United States Department of Transportation. Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0. November 2009.
  • Berenbach, Brian, Daniel Paulish, Juergen Kazmeier, and Arnold Rudorfer. Software and Systems Requirements Engineering: In Practice. McGraw Hill, 2009.
  • IEEE 1233-1998 IEEE Guide for Developing System Requirements Specifications.
  • IEEE 830-1998 Recommended Practice for Software Requirements Specifications.
  • IEEE Std 1362-1998 IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document.
  • ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents.