Module 4 - A103

A103: Introduction to ITS Standards Requirements Development

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

"Welcome" See extended text description below.

(Extended Text Description: “Welcome.” Graphic image of introduction information. 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 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

Head shot photo of Shelley Row, P.E., PTOE - Director - ITS Joint Program Office

Shelley Row, P.E., PTOE

Director

ITS Joint Program Office

Shelley.Row@dot.gov

Screen capture snapshot of RITA website - for illustration only - see the extended text description below.

(Extended Text Description: Slide 2: Screen capture snapshot of RITA website - for illustration only. Below this image is a link to the current website: http://www.pcb.its.dot.gov - 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: http://www.pcb.its.dot.gov)

WWW.PCB.ITS.DOT.GOV

(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 www.pcb.its.dot.gov.

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:

"A103 Introduction to ITS Standards Requirements Development" Footer graphic with long blue rectangle, white DOT logo, RITA, US Department of Transportation, Research and Innovative Technologies Administration with Standards ITS Training logo on left side.

 

Slide 4:

Target Audience

 

Slide 5:

Instructor

Photo of Instructor - Ralph W. Boaz

Ralph W. Boaz President

Pillar Consulting, Inc. San Diego, CA, USA

 

Slide 6:

Who Are Stakeholders?

Box with red check mark. TMC Operator, Field Maintenance, Operational Support (e.g. IT Dept.)

Box with red check mark. Interfacing System Owner, Purchaser

Box with red check mark. Sponsor of the Project

Box with red check mark. Regulatory Agency (if there is one)

Box with red check mark. Public, Politician

 

Slide 7:

Stakeholders for a System

"Stakeholders for a System." Graphic image. See extended text description below.

(Extended Text Description:“Stakeholders for a System.”   A graphic of four concentric circles arranged like an archery target.  The innermost circle is a reddish tan.  The three bands of colors that are further from the center are in lighter shades of tan.  This is called an “onion diagram” as onions are made up of multiple layers.  The inner circle is labeled “Physical System.”  The next layer outward is labeled “Operational System.”  The next layer outward is labeled “Containing System.”  The outermost layer is labeled “Wider Environment.” There are smaller black graphics of person positioned in the different layers of the diagram.  Each person has a project role next to it as follows: 1)  Inner Circle has no people – It represents the system; 2) Next Layer Outward has three people labeled TMC Operator, Field Maintenance, and Operational Support respectively; 3) Next Layer Outward has two people labeled Interfacing System Owner and Purchaser respectively; and 4) Outermost Layer has four people labeled Sponsor of the Project, Regulatory Agency, Public, and Politician respectively. The picture demonstrates while they are all stakeholders, different stakeholders have different levels of influence on the physical system to be defined.  The most influence coming from those closest to the center. There is a copyright reference to Ian Alexander 2006.  See references in Student Supplement.)

© Ian Alexander, 2006

 

Slide 8:

Curriculum Path (Non-SEP)

Curriculum Path (Non-SEP). Graphic image. See extended text description below.

(Extended Text Description: A flow chart of nine box in three rows of three, showing the curriculum path for implementing a system that uses standards that are not based on the systems engineering process. The first blue box contains the words “I101 – Using Standards: An Overview” with an arrow leading to the second box in the top row, stating “A101 – Introduction to Acquiring Standards-based ITS Systems” with an arrow leading to the last box “A102 – Introduction to User Needs Identification.” The arrow from this last box curves down and back to the left between the rows leading to the first box on the middle row, which states “A201 – Details on Acquiring Standards-Based ITS Systems” with an arrow leading to the second middle box, stating “A202 – Identifying and Writing User Needs when ITS Standards Do Not Have SEP Content” with an arrow leading to the third highlighted purple box of the middle row, stating “A103 – Introduction to ITS Standards Requirements Development.” The arrow from this last box curves down and back to the left between the rows to point to the left box on the third (bottom) row, which states “A203 – Writing Requirements When ITS Standards Do Not Have SEP Content” an arrow leading to the second box of the last row, stating “A3xxa – Identifying and Writing Specific User Needs for NTCIP 12xx vxx” with an arrow leading to the last box on the third row, stating “A3xxb – Specifying Requirements for NTCIP 12xx vxx.” The last two boxes are denoted with an asterisk that indicates these two modules are expected in year 2 of the training program.)

*Expected in year 2 training modules.

 

Slide 9:

Recommended Prerequisites

 

Slide 10:

Prerequisites (cont.)

 

Slide 11:

Learning Objectives

  1. Define requirements for overall operation to satisfy user needs
  2. Understand the concept of a well-formed requirement
  3. Define the system and interfaces as a functional architecture

 

Slide 12:

Learning Objectives (cont.)

  1. Use decomposition of the architecture and requirements as necessary to properly define the system
  2. Verify that requirements are complete and correct
  3. Understand how requirements development applies to ITS communication standards

 

Slide 13:

Learning Objective #1

Defining Requirements For Overall Operation To Satisfy User Needs

 

Slide 14:

Learning Objective #1

Review of the Systems Life Cycle

"Review of the Systems Life Cycle." Graphic image. See extended text description below.

(Extended Text Description: “Review of the Systems Life Cycle.”  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.)

 

Slide 15:

Learning Objective #1

Components of a Concept of Operations

 

Slide 16:

Learning Objective #1

Components of a Concept of Operations (cont.)

 

Slide 17:

Learning Objective #1

Characteristics of Well-Written User Needs

 

Slide 18:

Learning Objective #1

An Example User Need

4.3.1.11 Limit Audible Noise

The user needs the TFCS to have limited audible noise. TFCSs will be deployed in areas where residents are sensitive to ambientsound.

It is said that user needs identify the high-level WHAT of the system?

 

Slide 19:

Learning Objective #1

The Relationship of User Needs to Requirements

A Definition of a Requirement

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]

 

Slide 20:

Learning Objective #1

The Relationship of User Needs to Requirements

Requirement...

5.1.20 Audible Noise Level

The TFCS shall have no component that emits an audible noise level exceeding a peak I evel of 55 dBA when measured at a distance of one meter away from its surface.

 

Slide 21:

Learning Objective #1

The Relationship of User Needs to Requirements

"The Relationship of User Needs to Requirements" Graphic flow chart image. See extended text description below.

(Extended Text Description: "The Relationship of User Needs to Requirements." A flow chart with two columns of long green rectangular boxes. The first box is "Need #1" on the upper left side with a long blue horizontal two-directional arrow to a box on the upper right side, "Requirement #1". The second box on the left side, "Need #2", has a long blue two-directional arrow to a box on the right side, "Requirement #2". It also has a long diagonal two-directional arrow pointing to a box on the right side, "Requirement #3". The third box on the left side, "Need #3", is connected with a long blue horizontal two-directional arrow to the last box on the right side, "Requirement #4". The last box on the left side, "Need #4", is also connected with a long blue diagonal two-directional arrow to the same last box on the right side, "Requirement #4".)

 

Slide 22:

Learning Objective #1

Requirements in the Systems Life Cycle

"Requirements in the Systems Life Cycle." V diagram graphic.

(Extended Text Description: “The Relationship of User Needs to Requirements.” The V diagram as described in “Review of Systems Life Cycle” above. It is animated to highlight the relationship and differences between a user need and a requirement with circles around “Systems Requirements” on the left side and “System Verification & Deployment” on the right side.)   

 

Slide 23:

Learning Objective #1

Different Types of Requirements

 

Slide 24:

Learning Objective #2

The Concept of a Well-Formed Requirement

 

Slide 25:

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 26:

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 27:

Learning Objective #2

Characteristics of a Well-Formed Requirement

 

Slide 28:

Learning Objective #2

Characteristics of a Well-Formed Requirement (cont.)

 

Slide 29:

Learning Objective #2

Characteristics of a Well-Formed Requirement (cont.)

 

Slide 30:

Learning Objective #2

An Example Requirement

5.1.20 Audible Noise Level

The TFCS shall have no component thht emits an audiblenoiselevel exceeding a peak level of 55dBA whhe meaasred at a adisdtatnacne oefoofne meter arway from itsitts surface.

It is said that requirements definethe detailed WHAT of the system.

 

Slide 31:

Learning Objective #3

Defining the System and Interfaces as a Functional Architecture

 

Slide 32:

Learning Objective #3

Context Diagrams

 

Slide 33:

Learning Objective #3

Amber Alert System Context Diagram

"Amber Alert System Context Diagram" Flow chart graphic. See extended text description below.

(Extended Text Description: “Amber Alert System Context Diagram.”  A graphic with a circle in the middle of the slide labeled “Amber Alert System.”  The circle has a diameter of about 25% of the slide.  To the left of the circle are three rectangular boxes labeled “Caller,” “Radio Stations,” and “Freeway Signs” respectively.  To the right of the circle are two rectangular boxes labeled “Police Vehicles” and “Highway Patrol Vehicles” respectively.  The boxes represent things that are interfaced to by the system but are considered outside of the Amber Alert System to be built.  General flow of information between the boxes outside the system and circle representing the system is shown through labeled arrows as follows: 1) There is an arrow labeled “Verbal Report” from “Caller” box to the “Amber Alert System” circle; 2) There is an arrow labeled “Media Alert” from the “Amber Alert System” circle to the “Radio Stations” box; 3) There is an arrow labeled “Sign Msg” from the “Amber Alert System” circle to the “Freeway Signs” box; 4) There is an arrow labeled “Dispatch Msg” from the “Amber Alert System” circle to the “Police Vehicles” box; 5) There is an arrow labeled “Police Reports” from “Police Vehicles” box to the “Amber Alert System” circle; 6) There is an arrow labeled “Dispatch Msg” from the “Amber Alert System” circle to the “Highway Patrol Vehicles” box; and 7) There is an arrow labeled “Hwy Reports” from “Highway Patrol Vehicles” box to the “Amber Alert System” circle.)

 

Slide 34:

Learning Objective #3

Functional Architecture

 

Slide 35:

Learning Objective #3

Amber Alert System Functional Architecture

"Amber Alert System Functional Architecture." Flow chart graphic. See extended text description below.

(Extended Text Description: “Amber Alert System Functional Architecture.”  A graphic illustrating an example functional architecture diagram for the context diagram discussed above. The slide is divided into three sections horizontally by two bold vertical dotted lines.  The middle section use about 50% of the slide.  The two side sections use about 25% of the slide. The left section has three rectangular boxes labeled “Caller,” “Radio Stations,” and “Freeway Signs” top to bottom respectively. The right section has two rectangular boxes labeled “Police Vehicles” and “Highway Patrol Vehicles” top and bottom respectively.  The center section had four circles representing the functional elements of the Amber Alert System. They are labeled “Emgcy Msg Prcssing,” (top left of the section) “Police Dsptching,” (middle right of the section)  “Traffic Mgmt Ops,” (lower left of the section) and “Hwy Patrol Dsptching” (lower right of the section).  The “Emgcy Msg Prcssing” circle is in the upper left of the center section.  The “Police Dsptching,” “Traffic Mgmt Ops,” and “Hwy Patrol Dsptching” circles are in a triangular formation in the middle right of the center section with “Police Dsptching” at the top of the triangle, “Traffic Mgmt Ops” at the left bottom and “Hwy Patrol Dsptching” at the right bottom. General flow of information is shown through labeled arrows as follows: 1) There is an arrow labeled “Verbal Report” from “Caller” box to the “Emgcy Msg Prcssing” circle; 2) There is an arrow labeled “Incident Report” from the “Emgcy Msg Prcssing” circle to the “Police Dsptching” circle; 3) There is an arrow labeled “Dispatch Msg” from the “Police Dsptching” circle to the “Police Vehicles” box; 4) There is an arrow labeled “Police Reports” from “Police Vehicles” box to the “Police Dsptching” circle; 5) There is an arrow labeled “Police Reports” from the “Police Dsptching” circle to the “Traffic Mgmt Ops” circle; 6) There is an arrow labeled “Police Rpts” from the “Police Dsptching” circle to the “Hwy Patrol Dsptching” circle; 7) There is an arrow labeled “Traffic Conditions” from the “Traffic Mgmt Ops” circle to the “Hwy Patrol Dsptching” circle; 8) There is an arrow labeled “Trffc Cnds” from the “Traffic Mgmt Ops” circle to the “Police Dsptching” circle; 9) There is an arrow labeled “Hwy Rpts” from the “Hwy Patrol Dsptching” circle to the “Traffic Mgmt Ops” circle; 11) There is an arrow labeled “Hwy Rpts” from the “Hwy Patrol Dsptching” circle to the “Police Dsptching” circle; 12) There is an arrow labeled “Dispatch Msg” from the “Hwy Patrol Dsptching” circle to the “Highway Patrol Vehicles” box; 13) There is an arrow labeled “Hwy Reports” from “Highway Patrol Vehicles” box to the “Hwy Patrol Dsptching” circle; 14) There is an arrow labeled “Media Alert” from the “Traffic Mgmt Ops” circle to the “Radio Stations” box; and 15) There is an arrow labeled “Sign Msg” from the “Traffic Mgmt Ops” circle to the “Freeway Signs” box.)

 

Slide 36:

Learning Objective #4

Using Decomposition of Architecture and Requirements to Define the System

 

Slide 37:

Learning Objective #4

Decomposition of the Architecture

"Decomposition of the Architecture" Flow chart graphic. See extended text description.

(Extended Text Description: “Decomposition of the Architecture.”  Animation is used to illustrate decomposition.  The participants first see the same diagram as shown in “Amber Alert System Functional Architecture” above except that the arrows are not labeled for simplicity and the “Traffic Mgmt Ops” circle is highlighted blue.  The instructor causes the diagram to change where the “Traffic Mgmt Ops” of the original diagram is replaced by three new functional elements in the left lower portion of the center section.  The three new functional elements are labeled “Media Dsptching,” “Traffic Ctrl Operations,” and “DMS Control.”)

 

Slide 38:

Learning Objective #4

Decomposition of Requirements

A System Requirement for the Traffic Management Operations Functional Element

5.1.20 Public Notice of Amber Alerts Traffic Management Operations shall notify the public of an Amber Alert.

 

Slide 39:

Learning Objective #4

Decomposition of Requirements

Requirements for the Subsystems of the Traffic Management Operations Functional Element

5.1.20.1 Send Amber Alert to Media Dispatch Traffic Control Operations shall send an Amber Alert notification to Media Dispatching.

5.1.20.2 Send Amber Alert to DMS Control Media Dispatching shall send an Amber Alert notification to Radio Stations.

 

Slide 40:

Learning Objective #5

Verifying That Requirements Are Complete and Correct

 

Slide 41:

“Activity” A placeholder graphic of a hand typing on a computer keyboard indicating an activity. DOT logo, RITA, Department of Transportation, Research and Innovative Technologies Administration in lower left corner and “Standards ITS Training” logo in lower right corner.

 

Slide 42:

Learning Objective #5

Verifying Requirements Are Correct

5.1.21.6 Acknowledge Alert

Traffic Control Operations shall acknowledge the receipt of an Amber Alert notification.

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

Is it well-formed? Necessary? Concise? Attainable? Standalone? Consistent? Unambiguous? Verifiable?

 

Slide 43:

Learning Objective #5

Validating Requirements Are Complete

 

Slide 44:

Learning Objective #5

Need-to-Requirement Logical Consistency

What is inconsistent about this need and requirement?

[Need]

4.3.1.9 Extreme Temperatures and Humidity

The user needs the TFCS to operate under extreme hot, cold and humid environmental conditions.

[Requirement]

5.1.25 Ambient Temperature Range The TFCS shall be capable of withstanding an ambient storage temperature range of -45 degrees Celsius to +85 degrees Celsius.

 

Slide 45:

Learning Objective #5

Requirement Consistency

What is inconsistent in these requirements?

5.4.3 120 VAC Switch Pack Modules

The output assembly shall accept switch pack modules suitable for controlling field displays that operate at nominal 120 VAC 60Hz.

5.4.4 Low Voltage Load Switch Packs

The output assembly shall accept switch packs suitable for controlling field displays that operate at 48 VDC (+/- 2.0 VDC).

 

Slide 46:

Learning Objective #5

Using Traceability

 

Slide 47:

Learning Objective #5

Using Traceability (cont.)

 

Slide 48:

Learning Objective #5

Using Traceability Graphical Representation

"Using Traceability Graphical Representation." See extended text description below.

(Extended Text Description:"Using Traceability Graphical Representation". Series of information phrases connected with a ladder-like series of lines. At the top, "2.5.2.6 Manage the Real-Time Clock" connects with a vertical line to a series of four horizontal lines. First line, "3.4.1.4.1 Get Date and Time", second line, "3.4.1.4.2 Get Daylight Saving Time Mode", third line, "3.4.1.4.3 Set Date and Time", and last, "3.4.1.4.4 Set Daylight Savings Time Mode.")

 

Slide 49:

Learning Objective #5

Using Traceability Needs-to-Requirements Traceability Matrix (NRTM)

User Need ID

User Need

Req ID

Requirement

2.5.2.6

Manage

Real-Time

Clock

3.4.1.4.1

Get Date and Time

3.4.1.4.2

Get Daylight Saving Time Mode

3.4.1.4.3

Set Date and Time

3.4.1.4.4

Set Daylight Saving Time Mode

 

Slide 50:

Learning Objective #5

Using Traceability

Example One-to-Many Relationship

2.5.2.6 Manage the Real-Time Clock

This user needs the management station to configure a Real-Time Clock on the TSS for the purpose of providing timestamps on sample data. Accurate timing stamps across the system are critical to all data collection and sampling activities of the TSS. The clock should be able to support Daylight Saving Time adjustments so that local time stays consistent.

 

Slide 51:

Learning Objective #5

Using Traceability Example One-to-Many Relationship (cont.)

3.4.1.4.1 Get Date and Time

The TSS shall allow a management station to get the current sensor system date and time.

3.4.1.4.2 Get Daylight Saving Time Mode

The TSS shall allow a management station to get the current daylight saving time mode.

 

Slide 52:

Learning Objective #5

Using Traceability Example One-to-Many Relationship (cont.)

3.4.1.4.3 Set Date and Time

The TSS shall allow a management station to set the sensor system date and time to within one second of receiving the command.

3.4.1.4.4 Set Daylight Saving Time Mode

The TSS shall allow a management station to set the daylight saving time mode.

 

Slide 53:

Learning Objective #5

Traceability Beyond Requirements

 

Slide 54:

Learning Objective #6

Applying What We Learned to ITS Communications Standards

 

Slide 55:

Learning Objective #6

Systems Engineering Process Applied to ITS Communications Standards

 

Slide 56:

Learning Objective #6

Systems Engineering Process Applied to ITS Communications Standards

"Systems Engineering Process Applied to ITS Communications Standards" animation graphic. See extended text description below.

(Extended Text Description: “Systems Engineering Process Applied to ITS Communications Standards.”  The purpose is to illustrate when in the development process ITS communications processes are typically used.  When the slide is first displayed, it shows the lower portion of the SEP V diagram described above in Slide 14 on the right side.  The animation is different than Slide 14. The animation is as follows: 1) As the instructor discusses subsystems, most of the V diagram fades except for the bottom portion containing the five processes “High-Level Design,” “Detailed Design,” “Software/Hardware Development Field Installation,” “Unit/Device Testing” and “Subsystem Verification.”  The instructor refers to this as the “Subsystem Little V.” 2) The Subsystem Little V moves to the top right portion of the slide.  An oval is drawn around the processes “High-Level Design” and “Detailed Design.”  An arrow points to from the left oval to the left at a picture of the cover of the NTCIP 1209:2005 Standard. On the left side, there is a graphic of a burgundy cover with the title and information “NTCIP 1209:2005 National Transportation Communications for ITS Protocol,” “Data Elements Definitions Transportation Sensor Systems,” “Joint Standard of AASHTO, ITE and NEMA,” “version 01.19,” IHS logo, ITE logo, AASHTO logo, NEMA logo, “NTCIP Standards Publications,” and “A Joint Publications of American Association of State Highway and Transportation Office (AASHTO), Institute of Transportation Engineers (ITE), National Electrical Manufacturers Association (NEMA).”)

 

Slide 57:

Learning Objective #6

Contents of ITS Center-To-Field Communication Standards With SEP Content

 

Slide 58:

Learning Objective #6

Example

Requirements Traceability Matrix (RTM)

Req

ID

Req

Dialog ID

Dialog

Object ID

Object

3.4.1

.2.8

Determine Maximum Number of Classes

4.3.3.1

Retrieve Sensor Zone Sequence Parameters

5.2.4

maxSensorZones

5.4.3.1

numSampleDataEntries

5.4.3.2

numSensorZoneClass

 

Slide 58:

Learning Objective #6

PCB Modules on Standards With SEP Content

 

Slide 59:

Learning Objective #6

PCB Modules on Standards With SEP Content (cont.)

 

Slide 60:

Learning Objective #6

Contents of ITS Center-To-Field Communication Standards Without SEP Content

 

Slide 61:

Learning Objective #6

A203 Module on Writing Requirements for ITS Standards Without SEP Content

The participant will learn to:

 

Slide 62:

What Did We Learn Today?

  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

 

Slide 63:

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 64:

“Questions?” A placeholder graphic of a light bulb indicating questions. DOT logo, RITA, Department of Transportation, Research and Innovative Technologies Administration in lower left corner and “Standards ITS Training” logo in lower right corner.