Module 8 - A203

A203: Writing Requirements When ITS Standards Do Not Have SEP Content

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation 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.)

Slide 1:

(Extended Text Description: Slide 1: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words “Standards ITS Training” in green and blue on the middle left side. The word “Welcome” in white is to the right of the logo. Under the logo box are the words “RITA Intelligent Transportation Systems Joint Program Office.”)

Slide 2:

Welcome

Shelley Row, P.E., PTOE

Director

ITS Joint Program Office

Shelley.Row@dot.gov

(Extended Text Description: Slide 2: Screen capture snapshot of RITA website - for illustration only. Below this image is a link to the current website: https://www.its.dot.gov/pcb - this screen capture snapshot shows an example from the RITA website from June 3, 2011. At the top of the page it shows the RITA logo with the text Research and Innovative Technology Administration - Intelligent Transportation Systems. Below the main site banner, it shows the main navigation menu with the following items: About RITA, Communities of Interest, Contact Us, Press Room, RITA Offices, Site Map, and a Search button. Below the main navigation menu, it shows a sub-navigation menu with the following items: About Us, T3 Webinars, ITS Peer-to-Peer, Resources, Local ITS PCB and Testimonials. Beneath the sub-navigation menu, the page is sub-titled "ITS Professional Capacity Building Program" and is divided into sub-sections such as "Welcome to ITS Professional Building", "News", "ITS Technical Assistance" and "Scheduled T3 Webinars". Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb)

ITS PCB Home

(Note: There is additional text attached to this slide that includes the following introductory information from Shelley Row):

"ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

I am Shelley Row the director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.

ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging  ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all. You can find information on additional modules and training programs on our web site ITS PCB Home.

Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you for participating and we hope you find this module helpful."

Slide 3:

A203

Writing Requirements When ITS Standards Do Not Have SEP Content

Slide 4:

Target Audience

• Decision Makers
• Project Managers
• Operational Stakeholders

Slide 5:

Instructor

Ralph W. Boaz

President

Pillar Consulting, Inc. San Diego, CA, USA

Slide 6:

Curriculum Path (Non-SEP)

(Extended Text Description: This slide is a curriculum path recommended by the course provider. The title of the slide is “Curriculum Path (Non-SEP).” Non-SEP refers to the fact that this curriculum path focuses on ITS Systems Development when using ITS standards that do not have Systems Engineering Process (SEP) content within the standard. There are 9 blue boxes representing each module suggested in a 3x3 arrangement. There are arrows connecting the boxes going across the row. The box at the end of each row has an arrow pointing back to the leftmost box of the next row. The order of the modules is as follows: “I101 Using ITS Standards, An Overview” “A101 Introduction to Acquiring ITS Systems” “A102 Introduction to User Need Identification” “A201 Details on Acquiring Standards Based ITS Systems” “A202 How to Identify and Write ITS Standards User Needs” “A103 Introduction to ITS Standards Requirements Development” “A203 Writing Reqs When ITS Standards Do Not Have SEP” [Highlighted in Purple] “*A3xxa Understanding User Needs Based on NTCIP 12xx vxx Standard” “*A3xxb Specifying Requirements Based on NTCIP 12xx vxx Standard” The bottom of the slide states “* expected in Year 2 training modules.)

Slide 7:

Recommended Prerequisites

• I101 Using ITS Standards: An Overview
• A101 Introduction to Acquiring Standards-based ITS Systems
• A102 Introduction to User Needs Identification
• A201 Details on Acquiring Standards-based ITS Systems
• A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content

Slide 8:

Prerequisites (cont.)

• A103 Introduction to ITS Standards Requirements Development
• Basic knowledge of the following areas is helpful:
  • Intelligent Transportation Systems (ITS)
  • Managing ITS deployment projects
  • Government procurement processes
  • Benefits of standards
  • Systems engineering process (SEP)

Slide 9:

Learning Objectives

1. Understand that requirements development is a process
2. Avoid pitfalls when writing requirements
3. Write requirements when an ITS communication standard does not have SEP information
4. Use traceability matrices as tools for requirements development

Slide 10:

Systems Engineering Process Applied to ITS Communications Standards

• A SEP is being applied to ITS standard's development and added to the standard's content
• Helps insure that the standard is complete and correct
• Provides users with the thought process of the standard developers and use of the design items
• Helps users identify needs and requirements for their own specifications that reference the standards

Slide 11:

SEP Content in ITS Standards Helps

Identify Needs and Requirements

(Extended Text Description: This slide shows how the SEP content in some ITS Standards help with specification development. The title of the slide is “SEP Content in ITS Standards Helps Identify Needs and Requirements.” On the left side of the slide is the subtitle “Specification Development.” On the right side of the slide is the subtitle “ITS Standard with SEP Content. Under the “Specification Development” subtitle is a graphic representing three stages of specification development. The graphic is in the shape of a light blue parallelogram that is approximately three times in height as it is in its width. The slant on the parallelogram is downward and to the right. The parallelogram is evenly divided into three horizontal sections by two dark blue lines. Three sections from top to bottom are labeled “Concept of Operations,” “Requirements” and “Design.” On the left side of the graphic running closely along and in parallel with the slant of the parallelogram is a dark arrow pointing downward. It is labeled “Decomposition and Definition.” Under the “ITS Standard with SEP Content” subtitle are five bulleted items representing the sections of an ITS Standard that contains SEP information. They are “General,” “Concept of Operations,” “Functional Requirements,” “Design Details” and “Annexes.” As the instructor describes the slide, three bold dark green arrows appear pointing from the bulleted items on the right to the sections of the graphic on the left as follows: An arrow points from the bulleted “Concept of Operations” to the “Concept of Operations” section of the graphic; An arrow points from the bulleted “Functional Requirements” to the “Requirements” section of the graphic; and An arrow points from the bulleted “Design Details” to the “Design” section of the graphic.)

Slide 12:

ITS Standards without SEP Content

More Difficult to Use

(Extended Text Description: This slide shows how the lack of SEP content in some ITS Standards makes it more difficult to write specifications. The title of the slide is “ITS Standards without SEP Content More Difficult to use.” On the left side of the slide is the subtitle “Specification Development.” On the right side of the slide is the subtitle “ITS Standard without SEP Content. Under the “Specification Development” subtitle is a graphic representing three stages of specification development. The graphic is in the shape of a light blue parallelogram that is approximately three times in height as it is in its width. The slant on the parallelogram is downward and to the right. The parallelogram is evenly divided into three horizontal sections by two dark blue lines. Three sections from top to bottom are labeled “Concept of Operations,” “Requirements” and “Design.” On the left side of the graphic running closely along and in parallel with the slant of the parallelogram is a dark arrow pointing downward. It is labeled “Decomposition and Definition.” Under the “ITS Standard without SEP Content” subtitle are three bulleted items representing the sections of an ITS Standard that does not contain SEP information. They are “Overview,” “General Information” and “Design Details.” As the instructor describes the slide, one bold dark green arrow appears pointing from the bulleted “Design Details” on the right to the “Design” section of the graphic on the left. A red box with rounded corners appears over the “Concept of Operations” and “Requirements” sections of the graphic on the left. It contains the word “HELP!” in bold red lettering. )

Slide 13:

Learning Objective #1

Requirements Development Is A Process

• Requirements development is recursive
• Requirements development is iterative
• Requirements development is a process of discovery

Slide 14:

Learning Objective #1

Requirements Development is Recursive

(Extended Text Description: This slide shows how the development of requirements is recursive. The title of the slide is “Requirements Development is Recursive.” There are three rectangular boxes containing text. The first box is in the upper left side of the of the slide. The second box is about midway down on the right side of the slide. The third is box is directly below the first in the lower left portion of the slide. There are arrows going from the first box to the second box to the third box. The first box has the word “SYSTEM” at the top of the box with bulleted items underneath “Functional Reqs,” “Performance Reqs,” “Non-Functional Reqs” and “Constraints.” The second box has the word “SUBSYSTEM” and the same bulleted items as the first box. The third box has the word “INTERFACE” and the same bulleted items as the first and second boxes. The slide illustrates the same requirement processes being applied to different levels of the system. During the discussion a smaller green text box appears in the upper right with the words: “Also called: DECOMPOSITION.” )

Slide 15:

Learning Objective #1

Requirements Development Is Iterative

(Extended Text Description: This slide shows how the development of requirements is Iterative. The title of the slide is “Requirements Development is Iterative.” This graphic introduces three circles evenly spaced in a descending fashion from left to right. They contain the text “User Needs,” “Requirements” and “Design,” respectively. There is a curved arrow leading from the “User Needs” circle to the “Requirements” circle. There is a curved arrow leading from the “Requirements” circle to the “User Needs” circle. This same arrange of arrows occurs between the “Requirements” circle and the “Design” circle. )

Slide 16:

Learning Objective #1

Requirements Development is a Process of Discovery

(Extended Text Description: This slide shows how the development of requirements is like discovery. The title of the slide is “Requirements Development is a Process of Discovery.” It shows a large circle with three arrows located equidistantly around the circle pointing in a clock-wise direction. Between the arrows are three ovals with text located equidistantly around the circle. The first oval (on the left side of the circle) says “Discover.” Going clockwise around the circle, the next oval says “Document.” Continuing clock-wise around the circle the next oval says “Validate.” In the middle of the circle are small representations of people with the word “Stakeholders” over them. There are arrows pointing out from the people to the ovals around the circle. The “Validate” oval (located on the lower right portion of the circle has an arrow pointing from the oval to text to the right that says “Next Activity.”)

Slide 17:

Learning Objective #1

ITS Standards are a Source for Requirements Discovery

(Extended Text Description: Relevant description as provided by author: This slide shows how ITS Standards work with discovery process described in the previous slide. The title of the slide is “ITS Standards are a Source for Requirements Discovery.” The same graphic from the previous slide is reduced to about 1/3 of its size and located on the right half of the slide. The left portion of the slide has has an example cover page of an ITS Standard identified as “NTCIP 1202:2005.” There are three arrows that point from the ITS Standard to the three ovals of the graphic on the right. )

Slide 18:

Learning Objective #1

Using ITS Standards in the Discover-

Document-Validate Process

• Not trying to write requirements for a standard
• DISCOVERING interface requirements that support system/subsystem requirements
• DOCUMENTING what we find using the terms that are used in the ITS Standard
• VALIDATING using techniques we have learned
  • With other interface requirements
  • With parent system/subsystem requirements

Slide 19:

Learning Objective #1

Using ITS Standards in the Discover-Document-Validate Process (cont.)

• We reach this stage through decomposition
• OK to add to or correct what you have done
• Need to document requirements that require a series of exchanges (dialogs)
• Capture performance and constraint criteria
• See the NTCIP Guide

Slide 20:

Learning Objective #2

Avoiding the Pitfalls When Writing

Requirements

• Structure of Well-Formed Requirements
• Characteristics of Well-Formed Requirements
• Discuss the Pitfalls
• Name the Pitfall Game

Slide 21:

Learning Objective #2

Structure of Well-Formed Requirements

[Actor] [Action] [Target] [Constraint] [Localization]

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

Slide 22:

Learning Objective #2

Structure of Well-Formed Requirements

[Actor] [Action] [Target] [Constraint] [Localization]

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.

Slide 23:

Learning Objective #2

Characteristics of a Well-Formed Requirement

• Necessary
  • Must be useful and traceable to needs
• Concise
  • Minimal, understandable and expressed in a declarative language (e.g. "shall statements")
• Attainable
  • Realistic to achieve within available resources and time
• Standalone
  • Stated completely in one place

Slide 24:

Learning Objective #2

Characteristics of a Well-Formed Requirement (cont.)

• Consistent
  • Does not contradict itself, nor any other stated requirement
• Unambiguous
  • Susceptible to only one interpretation
• Verifiable
  • Requirement can be met through inspection, analysis, demonstration, or test

Slide 25:

Learning Objective #2

Pitfalls To Avoid When Writing Requirements

• Design and Implementation
• Over Specified
• Over Constrained
• Unbounded
• Assumptive

Slide 26:

Slide 27:

Learning Objective #2

Name the Pitfall Game

__Unbounded__

6.1.4.2 Serial Bus #2 System Messages

Command/Response Messages shall use similar message format as Serial Bus #1, collecting operational status, detection speed reports, occupancy reports, counts, etc.

Slide 28:

Learning Objective #2

Name the Pitfall Game

__Over Specified__

6.2.2.4 Enclosure Door Frames and Door Seals

The dimension between the door edge and the enclosure external surface when the door is closed and locked shall be 0.156 inch (+/-0.08 inches).

Slide 29:

Learning Objective #2

Name the Pitfall Game

__Design and Implementation__

6.4.7.8 Power Distribution Assembly Wiring

Three 36-inch minimum length #8 gauge wires, one black for AC+, one white for AC-, and one green or green/yellow for equipment ground, shall be attached to the rear of the assembly at the AC raw power terminating block.

Slide 30:

Learning Objective #2

Name the Pitfall Game

__Assumptive__

5.4.2 Public Safety

The system shall use the low-voltage output options available in the ITS Cabinet Standard Version 2 (currently in development).

Slide 31:

Learning Objective #2

Name the Pitfall Game

__Over Constrained__

5.3.2 Startup Considerations

The Engine Board low-level hardware and O/S initialization shall be completed and application software shall be capable of exercising control of all ATC unit hardware within a maximum of 4.5 seconds.

Slide 32:

Learning Objective #2

Words of Wisdom

• Knowledgeable stakeholders must be part of the project team
  • Especially for the devices and systems you are interfacing to
• Hire a consultant if you do not have the experience in-house
• Helps to research it yourself

Slide 33:

Learning Objective #3 Writing Requirements When an ITS Communication Standard Does Not Have SEP Information

• An Example Signal System using the NTCIP ASC and CCTV Standards
• Applying the Discover-Document-Validate Process

Slide 34:

Learning Objective #3

An Example Signal System

(Extended Text Description: This slide is a graphic of a hypothetical system to be used as an example in the module. The title of the slide is “An Example Signal System.” The slide has a red brick building to the upper left of the slide with the initials TMC above it. It has four by four evenly spaced black lines in a grid pattern to the right of the building taking up most of the slide. Above this are the words “Downtown Grid.” There are nine small gray traffic control cabinet graphics at nine of the intersection points of the lines. There are six small traffic surveillance camera graphics at six of the intersection points of the lines. There are purple dotted lines from the TMC building to the cabinet and camera graphics on the grid. )

Slide 35:

Learning Objective #3

An Example Signal System

(Extended Text Description: This slide is an architectural representation of the previous slide. The title of the slide is “An Example Signal System.” It has a large round circle with the text Traffic Management System inside. There a two smaller rectangles at the lower left and lower right of the slide. The text “Traffic Controllers” and “Cameras” are in the boxes respectively. There is a curved arrow leading from the “Traffic Management System” circle to the “Traffic Controllers” rectangle. There is a curved arrow leading from the “Traffic Controllers” rectangle to the “Traffic Management System” circle. This same arrange of arrows occurs between the “Traffic Management System” circle and the “Cameras” rectangle. There are two red rectangular text boxes in the upper left and upper right portions of the slide. They have the text “Subject of NTCIP 1202 ASC Standard” and “Subject of NTCIP 1205 CCTV Standard” respectively. There is a curved red line from the left text box to a red circle surrounding the arrows between the “Traffic Management System Circle” and the “Traffic Controllers” rectangle. There is a curved red line from the right text box to a red circle surrounding the arrows between the “Traffic Management System Circle” and the “cameras” rectangle.)

Slide 36:

Learning Objective #3

NTCIP 1202 Actuated Signal Control (ASC) Device Overview

• Environmentally hardened computational device
• Runs application program(s) that control(s) vehicle and pedestrian right of way at roadway intersections
• Communicates with field sensors to determine demand for service
• Communicates with field displays to control right of way

Slide 37:

Learning Objective #3

NTCIP 1205 Closed Circuit Television (CCTV) Device Overview

• Video device providing composite video over a closed system through a restricted access medium
• NTCIP covers the camera control subsystem comprised of camera, lens, and pan/tilt functions
• Video signal transmission is currently outside the scope of the NTCIP

Slide 38:

Learning Objective #3

NTCIP "Device" Standards

• Generally, the NTCIP device standards must provide an interface that is able to:
  • Configure the device
  • Control the device
  • Monitor the device
  • Retrieve historical information from the device

Slide 39:

Learning Objective #3

Organization of the NTCIP Device Standards without SEP Content

• General Information
• Object Definitions (MIB)
• Block Objects (in some cases)
• Annexes
  • Conformance Groups
  • Other

Slide 40:

Learning Objective #3

Management Information Base (MIB)

• Defines the data elements (objects) of the device that are covered by the standard
• Written in Abstract Syntax Notation (ASN.1) notation
• Resource/reference for those familiar with the device
• Ineffective for a novice to learn a device by reading a MIB

Slide 41:

Learning Objective #3

Example Object Definition

(Extended Text Description: This slide is an example of a definition of an NTCIP data object. The title of the slide is “Example Object Definition.” It has the text as follows:

phaseWalk OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-write
STATUS optional
DESCRIPTION
"<Definition> Phase Walk Parameter in seconds. This shall control the amount of time the Walk indication shall be displayed."
REFERENCE
"NEMA TS 2 Clause 3.5.3.1 & 3.5.3.2.2.a"
::= { phaseEntry 2 }

As the instructor speaks, green ovals appear encompassing various parts of the definition. In most cases there is additional green text giving clarification to what was encompassed. “phaseWalk” is encompassed with additional text “Object Name.” “INTEGER (0..244)” is encompassed with additional text “Range of Values.” “read-write” is encompassed with additional text “Read/Write/Read-Only.” “optional” is encompassed with additional text “Mandatory - Optional - Deprecated - Obsolete.” "<Definition> Phase Walk Parameter in seconds. This shall control the amount of time the Walk indication shall be displayed" is encompassed with no additional text. "NEMA TS 2 Clause 3.5.3.1 & 3.5.3.2.2.a" is encompassed with no additional text. “phaseEntry 2” is encompassed with additional text “Location in MIB.”)

Slide 42:

Learning Objective #3

Sample of ASC Conformance Groups

Ref	Areas	Clause	Status	Support
A.3 A.4 A.5	Phase Conformance Group Detector Conformance Group Volume Occupancy Report Conformance Group	2.2 2.3 2.3	M M O	Yes Yes Yes/No
A.6 A.7 A.8	Unit Conformance Group Special Function Conformance Group Coordination Conformance Group	2.4 2.4 2.5	O O O	Yes/No Yes/No Yes/No

Slide 43:

Learning Objective #3

Sample of the Phase Conformance Group

Clause	Object Name	Object Type	Object Status	Object Support	Allowd Values	Supprtd Values
2.2	Phase Conformance Grp	—	M	Yes	---	---
2.2.1	maxPhases	S	M	Yes	2-255
2.2.2	phaseTable	—	M	Yes	----	---
	phaseEntry	—	M	Yes	---	---
2.2.2.1	phaseNumber	S	M	Yes	1..255
2.2.2.2	phaseWalk	P	M	Yes	0-255
2.2.2.3	phasePedestrianClear	P	M	Yes	0-255
2.2.2.4	phaseMinimumGreen	P	M	Yes	0-255

Slide 44:

Learning Objective #3

Applying the Discover-Document-Validate Process

• Assuming that the decision has been made to use NTCIP standards
• Write a user need and requirements that are consistent with the NTCIP ASC Standard
• Test our skill with a CCTV example

Slide 45:

Learning Objective #3

ASC Example User Need -Discover / Document

(Extended Text Description: This slide provides an example Actuated Signal Control (ASC) User Need. The title of the slide is “ASC Example User Need – Discover/Document.” It has the text as follows: 3.2.1 Display Intersection Right-of-Way Information The user needs the system to display current phase outputs information (red, yellow, green) for each signalized intersection. TMC operators must be able to identify the current right-of-way for each signalized intersection on the system. As the instructor speaks, green ovals appear encompassing various parts of the user need. “display,” “current,” “phase outputs information” and “each signalized intersection” are encompassed. Green text appears at the bottom of the slide as follows: “Each of the key items must be addressed in requirements to satisfy the user need!” )

Each of the key items must be addressed in requirements to satisfy the user need!

Slide 46:

Learning Objective #3

ASC Example System Requirements -Discover / Document

(Extended Text Description: This slide provides an example Actuated Signal Control (ASC) Requirement. The title of the slide is “ASC Example User Need – Discover/Document.” It has the text as follows: 4.2.1.4 Display Phase Outputs Information The system shall allow the operator to display phase output information for a selected intersection. As the instructor speaks, four green ovals appear encompassing various parts of the requirement that are part of the structure of a well formed requirement. The ovals are identified by green text that with an arrow to the corresponding oval. “The System” is encompassed and pointed to by “ACTOR.” “display” is encompassed and pointed to by “ACTION.” “phase output information” is encompassed and pointed to by “TARGET.” “selected intersection is encompassed and pointed to be “LOCALIZATION.” Green text appears at the bottom of the slide as follows: “It is best to verify that our requirements are well formed as we write them.” )

It is best to verify that our requirements are well formed as we write them.

Slide 47:

Learning Objective #3

ASC Example System Requirements -Discover / Document

4.2.1.2 Geolocated Intersection Icons

The system shall display geolocated user selectable intersection icons for each managed signalized intersection on the road map.

Slide 48:

Learning Objective #3

ASC Example System Requirements -Discover / Document

4.2.1.1 Road Map

The system shall provide a road map of the area to be managed by the system.

4.2.1.3 Pointing Device

The system shall provide a pointing device which allows operators to select icons on the road map.

Slide 49:

Learning Objective #3

ASC Example Interface Requirement -Discover / Document

4.2.1.5 Retrieve Phase Outputs Information

The system shall retrieve phase outputs information at a rate of once every second (acceptable range 0.6 to 1.0 seconds) from every intersection managed by the system.

Slide 50:

Learning Objective #3

ASC Example - Validate

• Are the requirements well formed? (Verification)
• Are the requirements logically consistent with parent requirements and user needs?
• Are the requirements consistent with sibling requirements?
• Is there traceability between the needs and requirements?
• Are all of the key items of the user need addressed by the requirements?

Slide 51:

Learning Objective #3

ASC Example - Validate

(Extended Text Description: This slide shows how each of the requirements discussed in previous slides addressed key items of the user need. The title of the slide is “ASC Example – Validate.” The main part of the user need is provided as follows: 3.2.1 Display Intersection Right-of-Way Information The user needs the system to display current phase outputs information (red, yellow, green) for each signalized intersection. TMC operators… The identifiers and names of the requirements are provided as follows: 4.2.1.1 Road Map 4.2.1.2 Geolocated Intersection Icons 4.2.1.3 Pointing Device 4.2.1.4 Display Phase Outputs Information 4.2.1.5 Retrieve Phase Outputs Information As the instructor speaks, red ovals appear encompassing key items in the requirement. Red arrows go from requirements to the encompassed key items they pertain to. The arrows are as follows: An arrow goes from “4.2.1.1 Road Map” to “each signalized intersection;” An arrow goes from “4.2.1.2 Geolocated Intersection Icons” to “each signalized intersection;” An arrow goes from “4.2.1.3 Pointing Device” to “each signalized intersection;” Arrows go from “4.2.1.4 Display Phase Outputs Information” to “display” and “phase outputs information;” and Arrows go from “4.2.1.5 Retrieve Phase Outputs Information” to “current,” “phase outputs information” and “each signalized intersection.”)

Slide 52:

Slide 53:

Test Our Skill...

CCTV Example User Need

3.20.1 Control a Remote CCTV Device

The TMC operator needs to remotely control the position of the CCTV device. TMC operators must be able to control the on-street cameras to be able to determine roadway congestion, assess environmental conditions, monitor incidents, and verify proper signal operation.

Slide 54:

Learning Objective #3

Test Our Skill...CCTV Example Select the Better Requirement

(Extended Text Description: This slide shows gives the participants an opportunity to respond to a poll question. The title of the slide is “Test Our Skill…CCTV Example – Select the Better Requirement” There are two possible answers provided. The answers have blue balls with the letters “A” and “B” respectively. The text for the answers is as follows: 4.20.1 Get CCTV Position The system shall be able to retrieve the pan/tilt/zoom (PTZ) of a remotely located CCTV device. 4.20.2 Set CCTV Position The system shall be able to set the position of a CCTV device located within a 12-mile radius of the TMC. Following the poll a red oval encompasses the entire option A to show the correct answer. )

Slide 55:

Learning Objective #3

Test Our Skill - CCTV Example Select the Better Requirement

(Extended Text Description: This slide shows gives the participants an opportunity to respond to a poll question. The title of the slide is “Test Our Skill…CCTV Example – Select the Better Requirement” There are two possible answers provided. The answers have blue balls with the letters “A” and “B” respectively. The text for the answers is as follows: 4.20.3 Get CCTV Feature Status The system shall be able to retrieve the camera feature status from the CCTV device. 4.20.4 Set CCTV Tilt Position The system shall be able to set the tilt position on the CCTV device. Following the poll a red oval encompasses the entire option B to show the correct answer. )

Slide 56:

Learning Objective #4 Traceability Matrices As Tools for Requirements Development

• Building Traceability Matrices
• Needs-To-Requirements Traceability
• Requirements to Interface Item (Design) Traceability

Slide 57:

Learning Objective #4

Building Traceability Matrices

• Trace User Needs to Requirements
• Trace Requirements to Design Items
• Tools used to help verify completeness and correctness
• Suggest capturing traceability informally through the discover-document-validate process
• Document results in matrix fashion/make updates

Slide 58:

Learning Objective #4

Needs-To-Requirements Traceability

• 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

Slide 59:

Learning Objective #4

Needs-To-Requirements Traceability (cont.)

• 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

Slide 60:

Learning Objective #4

Needs-To-Requirements Traceability Matrix (NRTM)

UN ID	User Need	Req ID	Requirement
3.2.1	Provide Intersect. Right-of-Way Info	4.2.1.1	Road Map
		4.2.1.2	Geolocated Intersect. Icons
		4.2.1.3	Pointing Device
		4.2.1.4	Display Phase Outputs Info
		4.2.1.5	Retrieve Phase Outputs Info
3.2.2	Provide Volume/ Occupancy Info	4.2.2.1	Display Volume/Occupancy Info

Slide 61:

Learning Objective #4

Requirements-to-Design Traceability

• Every requirement should trace to at least one interface item
• Every interface item must trace to at least one requirement
• Any requirement that is not addressed by at least one interface item means:
  • An interface item was missed or
  • The requirement must be reevaluated

Slide 62:

Learning Objective #4

Requirements-to-Design Traceability (cont.)

• Every interface item that does not address at least one requirement means:
  • The interface item must be reevaluated or
  • A requirement was missed
• Every aspect of each requirement should be addressed in the design

Slide 63:

Learning Objective #4

Requirements Traceability Matrix (RTM)

Req ID	Req	D-log ID	Dialog	Obj ID	Object
4.2.1.5	Retrieve Phase Outputs Information
		5.2.1	Retrieve Phase Outputs Dialog
				2.2.4	phaseStatusGroupTable
				2.2.4.1	phaseStatusGroupNumber
				2.2.4.2	phaseStatusGroupReds
				2.2.4.3	phaseStatusGroupYellows
				2.2.4.4	phaseStatusGroupGreens
				. . .	...

Slide 64:

Slide 65:

What did we learn today?

1. To understand that requirements development is a PROCESS
2. To avoid PITFALLSwhen writing requirements
3. How to write requirements when an ITS communication standard does not have SEP information
4. To use TRACEABILITY matrices as tools for requirements development

Slide 66:

Sources for More Information

Alexander, Ian, and Ljerka Beus-Dukic. Discovering Requirements. Wiley, 2009

FHWA Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0

IEEE 1233-1998 IEEE Guide for Developing System Requirements Specifications

IEEE 830-1998 Recommended Practice for Software Requirements Specifications

INCOSE Systems Engineering Handbook v3.2

NTCIP Guide, TMDD Guide, IEEE 1512 Guide

http://www.standards.its.dot.gov/

Slide 67:

Curriculum Path (Non-SEP)

(Extended Text Description: This slide is a curriculum path recommended by the course provider. The title of the slide is “Curriculum Path (Non-SEP).” Non-SEP refers to the fact that this curriculum path focuses on ITS Systems Development when using ITS standards that do not have Systems Engineering Process (SEP) content within the standard. There are 9 blue boxes representing each module suggested in a 3x3 arrangement. There are arrows connecting the boxes going across the row. The box at the end of each row has an arrow pointing back to the leftmost box of the next row. The order of the modules is as follows: “I101 Using ITS Standards, An Overview” “A101 Introduction to Acquiring ITS Systems” “A102 Introduction to User Need Identification” “A201 Details on Acquiring Standards Based ITS Systems” “A202 How to Identify and Write ITS Standards User Needs” “A103 Introduction to ITS Standards Requirements Development” “A203 Writing Reqs When ITS Standards Do Not Have SEP” “*A3xxa Understanding User Needs Based on NTCIP 12xx vxx Standard” [Highlighted in Purple] “*A3xxb Specifying Requirements Based on NTCIP 12xx vxx Standard” The bottom of the slide states “* expected in Year 2 training modules.)

Slide 68: