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.)

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

Definition of Systems Engineering

Components of a Concept of Operations

Definitions of a Requirement

Types of Requirements

2 WELL-FORMED REQUIREMENTS

Definition of a Well-Formed Requirement

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

 

3 DEFINING THE SYSTEM AND INTERFACES AS FUNCTIONAL ARCHITECTURE

Functional 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

 

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

Contents of ITS Standards Without SEP Content

PCB Modules on Standards With SEP Content

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

ITS Device Communications Standards With SEP Content

ITS Device Communications Standards Without SEP Content

REFERENCES

Web sites for ITS Standards

Web sites for Systems Engineering Development

Guides that Use the Systems Engineering Process

Specific Texts, Documents, and Standards