Module 44 - A307b

A307b: Understanding Requirements for Advanced Transportation Controllers Based on ATC 5201 Standard v06

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 - Graphic image of introductory slide. Please see the Extended Text Description below.

(Extended Text Description: 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 is the logo for the U.S. Department of Transpotation, Office of the Assistant Secretary for Research and Technology.)

 

Slide 2:

Welcome slide with Ken Leonard and screen capture of home webpage. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Welcome" has a photo of Ken Leonard, Director, ITS Joint Program Office, on the left hand side, with his email address, Ken.Leonard@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - from August 2014. Below this image is a link to the current website: www.pcb.its.dot.gov - this screen capture snapshot shows an example from the Office of the Assistant Secretary for Research and Development - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and a section labeled Free Training. Again, this image serves for illustration only. The current website link is: http://www.pcb.its.dot.gov.)

 

Slide 3:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 4:

A307b:

Understanding Requirements for Advanced Transportation Controllers Based on ATC 5201 Standard v06

 

Slide 5:

Instructor

Headshot photo of Ralph W. Boaz

Ralph W. Boaz

President

Pillar Consulting, Inc.

San Diego, CA, USA

 

Slide 6:

Target Audience

 

Slide 7:

Recommended Prerequisites

 

Slide 8:

Recommended Prerequisites (cont.)

 

Slide 9:

Curriculum Path

This slide contains a graphic illustration indicating the sequence of training modules that lead up to this course. Please see the Extended Text Description below.

(Extended Text Description: This slide contains a graphic illustration indicating the sequence of training modules that lead up to this course. Each module is represented by a box with the name of the module in it and arrows showing the logical flow between the modules. There are 12 boxes in total; three rows of 4 boxes. The sequence goes from left to right with the fourth box on the first and second rows having arrows which connect to the first box on the second and third rows respectively. The module titles are as follows:

The last box is highlighted indicating that it represents the current module in the series.)

 

Slide 10:

Learning Objectives

  1. Describe a systems engineering-based ATC specification development process
  2. Write requirements for ATCs based on user needs
  3. Describe a specification based on ATC 5201 Standard v06
  4. Verify an ATC procurement specification

 

Slide 11:

Learning Objective #1: Describe a Systems Engineering-Based ATC Specification Development Process

 

Slide 12:

Learning Objective #1

Traditional Approaches to Developing Transportation Controller Procurement Specification

 

Slide 13:

Learning Objective #1

Systems Engineering Approach to Developing an ATC Procurement Specification

 

Slide 14:

Learning Objective #1

Systems Engineering Processes Used in Standards Development

IEEE - Systems Engineering

An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability.

Systems Engineering Processes Used in Standards Development. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Systems Engineering Processes Used in Standards Development," uses a graphic that illustrates the systems engineering process used in standards development. 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.)

Graphics: Ralph W. Boaz

 

Slide 15:

Learning Objective #1

Systems Engineering Specification Development Process

Systems Engineering Specification Development Process. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Systems Engineering Specification Development Process," uses a graphic that illustrates the systems engineering process used to develop a specification. There are two circles evenly spaced in a descending fashion from left to right representing processes. They contain the text "User Needs" and "Requirements," respectively. There is a curved arrow extending from the User Needs process to the Requirements process. There is a curved arrow extending from the Requirements process to the User Needs process. There are three rectangular graphics with lines across them representing documents. The first document is located at the top of the slide and is labeled "Strategic or Regional Plans." It has a curved arrow extending from the document to the User Needs process. There is a curved arrow extending from the User Needs process two the second document located in the lower left of the slide that is labeled "Concept of Operations." There is a curved arrow extending from the Requirements process to the third document located in the lower right of the slide that is labeled "Agency Specification." There are dotted double arrows extending between the first and second documents and between the second and third documents. The double arrows are labeled "Traceability.")

Graphics: Ralph W. Boaz

 

Slide 16:

Learning Objective #1

Relationships of User Needs and Requirements

Relationships of User Needs and Requirements. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Relationships of User Needs and Requirements," uses graphics to highlight the relationships between a user needs and requirements. User needs are represented by green boxes on the left side of the slide labeled "Need #1," "Need #2," "Need #3," and "Need #4." Requirements are represented by green boxes on the right side of the slide labeled "Requirement #1," "Requirement #2," "Requirement #3," and "Requirement #4." Three relationships between the user needs and the requirements are represented using solid blue lines with arrows on each end connecting the needs and requirements as follows:

The slide is animated displaying each relationship as the instructor introduces it one at a time until all are shown.)

Graphics: Ralph W. Boaz

 

Slide 17:

Learning Objective #1

Benefits of the Systems Engineering Specification Development Process

 

Slide 18:

Learning Objective #1

Challenges to Preparing a Good ATC 5201 Standard v06-Based Specification

 

Slide 19:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 20:

Learning Objective #1

An agency specification comes out of what part of the systems engineering specification development process?

Answer Choices

  1. Concept of operations
  2. Requirements development
  3. Strategic plan
  4. User needs development

 

Slide 21:

Learning Objective #1

Review of Answers

A small graphical red and yellow X representing incorrect.a) Concept of operations
Incorrect. A concept of operations is the result of user needs development.

A small graphical green and yellow check mark representing correct.b) Requirements development
Correct! Requirements are stated in the agency's specification.

A small graphical red and yellow X representing incorrect.c) Strategic plan
Incorrect. A strategic plan may be an input to the user needs development process.

A small graphical red and yellow X representing incorrect.d) User needs development
Incorrect. User needs are stated in a concept of operations.

 

Slide 22:

Summary of Learning Objective #1

Describe a Systems Engineering-Based ATC Specification Development Process

 

Slide 23:

Learning Objective #2: Write Requirements for ATCs Based on User Needs

 

Slide 24:

Learning Objective #2

Definition of a "Well-Formed" Requirement

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

Actor - Identifies who or what 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 25:

Learning Objective #2

Example of a Well-Formed Requirement

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

5.3.7 Color Graphics Display

Example of a Well-Formed Requirement. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, five ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "A liquid crystal display (LCD)" is encompassed by two ovals and pointed to by "TARGET." "That is capable of color graphics" is encompassed by an oval and pointed to by "CONSTRAINT.")

If a requirement can't be stated in this simple format, you probably need to use multiple requirements.

 

Slide 26:

Learning Objective #2

Characteristics of Well-Formed Requirements

 

Slide 27:

Learning Objective #2

Characteristics of Well-Formed Requirements (cont.)

 

Slide 28:

Learning Objective #2

User Needs from Strategic and Regional Plans

Case Study

This section uses examples from the "Orange County Intelligent Transportation Systems (ITS) Strategic Deployment Plan (SDP) - Update 2013." This SDP was developed by the Orange County Transportation Authority (OCTA), a Metropolitan Planning Organization (MPO) for Orange County, CA.

The SDP uses ITS "strategies" to provide context for the agencies and the private sector who are deploying technology today and for the following ten years. Strategies are organized as follows: Transit Management and Multi-Modal (MM), Traffic Management (TM), Incident Management and Emergency Response (IM), Traveler Information (TI), Performance Monitoring (PM), Communications and Connectivity (CC), Safety (SF), and Institutional (IN).

Other strategic or regional plans may have different names and different methods of expressing desired capabilities.

 

Slide 29:

Learning Objective #2

Example "Strategy" and User Needs From Case Study

Strategy Example

CC1 - Countywide Communications Master Plan: Physical and logical connectivity to support multi-modal and multi-agency operations and data sharing needs.

User Need Example

7.4.3.1 Multi-Network Ready

The city needs transportation controllers equipped with communications capabilities to accommodate connectivity with multiple systems and communications networks. The city has legacy center-to-field (C2F) communications to some arterials. The majority of the arterials are supported by Ethernet communications through fiber or high speed radios. It is expected that some applications will share a physical network while others will require separate networks.

 

Slide 30:

Learning Objective #2

Example of a Well-Formed Requirement

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

5.4.9 Dual Ethernet Capability

Example of a Well-Formed Requirement. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "A minimum of two Ethernet ports supporting 10/100 BaseT communications" is encompassed by an oval and pointed to by "TARGET." "With RJ45 physical connectors" is encompassed by an oval and pointed to by "CONSTRAINT.")

 

Slide 31:

Learning Objective #2

Example "Strategy" and User Needs From Case

Study

Strategy

CC3 - Provide a Connected Vehicles Platform: Allow for the future possibility of connected vehicles in order to capitalize on the robust local operational environment and further enhance the existing foundation.

User Need Example

7.5.1 Connected Vehicle V2I Communications

The city needs transportation controllers that will be capable of performing Connected Vehicle Vehicle-to-Infrastructure (V2I) communications. Connected vehicle applications have the potential for a major advancement in integrated traveler information, safety, transportation management, and eco driving. It is anticipated legacy controller units that were installed over eight years ago will not have the processing power to perform V2I communications.

 

Slide 32:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.5.1 Processing Power

Example of a Well-Formed Requirement. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall have" is encompassed by an oval and pointed to by "ACTION." "A CPU" is encompassed by an oval and pointed to by "TARGET." "With a minimum CoreMark Benchmark of 600 per specification by the chip manufacturer" is encompassed by an oval and pointed to by "CONSTRAINT.")

 

Slide 33:

Learning Objective #2

Example "Strategy" and User Needs From Case Study

Strategy

MM2 - Bus Rapid Transit: Roll out BRT service in a two-step implementation process. Technology applications could include transit signal priority (TSP), real-time bus arrival information, and automated fare collection.

User Need Example

7.8.3.3 Increase Public Use of Transit Buses

The city needs transportation controllers that can be used to help increase ridership of transit buses. The city needs to improve customer service and ridership experience through the use of field applications that may include transit signal priority (TSP), real-time bus arrival information, automated fare collection and others.

 

Slide 34:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.3.5 Screen Size

Example of a Well-Formed Requirement. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall have" is encompassed by an oval and pointed to by "ACTION." "A minimum screen size" is encompassed by an oval and pointed to by "TARGET." "Of 16 lines by 40 characters" is encompassed by an oval and pointed to by "CONSTRAINT.")

 

Slide 35:

Learning Objective #2

Example of Constraint Identified by Operations Staff

6.5.1 NEMA TS 2 Equipment

The city needs transportation controllers equipped for its existing transportation field cabinet systems. The city has 70% of its TFCSs that are NEMA TS 2 Type 1 and 30% of its TFCSs are NEMA TS 2 Type 2. The transportation controller should be suitable for these cabinet systems.

 

Slide 36:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.2.1 NEMA TS 2 Type 2 Interfaces

Example of a Well-Formed Requirement. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "Physical interfaces" is encompassed by an oval and pointed to by "TARGET." "Per NEMA TS 2 Standard v02.06 Section 3.3 for Type 2 controller units" is encompassed by an oval and pointed to by "CONSTRAINT.")

 

Slide 37:

Learning Objective #2

Write Requirements for ATCs Based on User Needs - Additional Guidance

 

Slide 38:

Learning Objective #2

Resolving Conflicting Requirements

 

Slide 39:

Learning Objective #2

Establish Precedence Between Referenced Standards Documents and Specifications to Resolve Conflicting Requirements

 

Slide 40:

Learning Objective #2

ATC Specification with Requirements That Exceed ATC 5201 Standard v06

 

Slide 41:

Learning Objective #2

Watch for Requirements That Subsume Others as It Can Cause Confusion

 

Slide 42:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 43:

Learning Objective #2

When a requirement is well-formed, which part of the requirement may not be present?

Answer Choices

  1. Action
  2. Constraint
  3. Target
  4. Actor

 

Slide 44:

Learning Objective #2

Review of Answers

A small graphical red and yellow X representing incorrect.a) Action
Incorrect. There is always an action in a well-formed requirement, for example, shall [blank].

A small graphical green and yellow check mark representing correct.b) Constraint
Correct! Well-formed requirements may not have a constraint that provides the bounds of a requirement.

A small graphical red and yellow X representing incorrect.c) Target
Incorrect. There is always a target that receives the action in a well-formed requirement.

A small graphical red and yellow X representing incorrect.d) Actor
Incorrect. There is always an actor in a well-formed requirement. Typically, a system, subsystem, or name thereof.

 

Slide 45:

Summary of Learning Objective #2

Write Requirements for ATCs Based on User Needs

 

Slide 46:

Learning Objective #3: Describe a Specification

Based on the ATC 5201 Standard v06

 

Slide 47:

Learning Objective #3

Structure of the ATC 5201 Standard

Section 1 - Introduction

Section 2 - Overall Description

Section 3 - Functional Requirements

Section 4 - Engine Board Details

Section 5 - Communication Interface Details

Section 6 - Physical and User Interface Details

Section 7 - Parallel and Serial I/O Details

Section 8 - Environmental and Test Procedures

 

Slide 48:

Learning Objective #3

Structure of the ATC 5201 Standard (cont.)

Section 9 - Performance and Material Requirements Section 10 Quality Control

Appendix A - Linux Operating System and Minimum Kernel Configuration

Appendix B - Required Device Driver Interfaces

Appendix C - Historical Background of Traffic Controllers

 

Slide 49:

Learning Objective #3

Transportation Controller Specifications are Subject to the Agency's Procurement Process

 

Slide 50:

Learning Objective #3

Proposed Outline for an ATC Specification

  1. Purpose
  2. Scope
  3. References
  4. Background
  5. Requirements

 

Slide 51:

Learning Objective #3

Essential Areas That Must be Addressed so

That a Controller Unit Conforms to ATC 5201 Standard v06

*Areas that are influenced by the TFCS standard or specification in which the ATC unit is to operate.

 

Slide 52:

Learning Objective #3

Example Operational Voltage Requirements

Operational voltages are dictated by the TFCS

5.6.1 Operating Voltage

The transportation controller shall meet the operating voltage requirements per Section 2.1.2 of the NEMA TS 2 Standard.

5.6.2 Operating Frequency

The transportation controller shall meet the operating frequency requirements per Section 2.1.3 of the NEMA TS 2 Standard.

5.6.3 Power Interruptions

The transportation controller shall meet the power interruption requirements per Section 2.1.4 of the NEMA TS 2 Standard.

 

Slide 53:

Learning Objective #3

User Interface Requirements - ATC Minimums

User Interface Requirements – ATC Minimum. Please see the Extended Text Description below.

(Extended Text Description: This slide, entitled "User Interface Requirements – ATC Minimums," highlights the minimum ATC user interface requirements. The graphic consists of three large text boxes that are aligned vertically and extend the width of the slide. They are outlined by heavy solid lines. The content of the text boxes is as follows:
Text Box 1 (top)

Text Box 2 (middle)

OR
• RJ45, serial connector for console
Text Box 3 (bottom)

OR

There is a large plus sign between Text Box 1 and Text Box 2 and between Text Box 2 and Text Box 3 all centered on the slide.)

Graphics: Ralph W. Boaz

 

Slide 54:

Learning Objective #3

User Interface Options

 

Slide 55:

Learning Objective #3

User Interface Options

Agencies are cautioned to verify that these types of interfaces will also operate in a mode that supports the basic ATC 5201 and ATC 5401 standard interfaces

Agencies are cautioned that requiring manufacturer-specific front panel keys in their specifications will restrict their option of ATC providers

 

Slide 56:

Learning Objective #3

Example User Interface Requirements

 

Slide 57:

Learning Objective #3

Serial and Parallel I/O Requirements

Agencies are cautioned to not unnecessarily require communications ports as it can drive up costs and limit choices of vendors

 

Slide 58:

Learning Objective #3

Example I/O Requirements

5.4.13 Generic Serial Port 1

The transportation controller shall have a general purpose serial port using a male DB9 connector.

5.4.14 Generic Serial Port 2

The transportation controller shall have a general purpose serial port using a male DB25 connector.

 

Slide 59:

Learning Objective #3

CPU Performance and Memory Requirements

ATC 5201 Standard v06 Minimum Requirements

Agencies are cautioned not to arbitrarily require the highest number of MIPS and memory available as it can drive up costs and limit choices of vendors

 

Slide 60:

Learning Objective #3

Example CPU Performance and Memory Requirements

5.5.2 DRAM Memory

The transportation controller shall have DRAM capacity of 128 MB minimum.

 

Slide 61:

Learning Objective #3

Example Other Requirements

5.8.4 Software Requirements

5.8.4.1 Application Tool Chain

The vendor shall identify in writing the tool chain (compiler and C libraries) used to create application programs for the Engine Board of the transportation controller.

5.8.4.2 Linux BSP Tool Chain

The vendor shall identify in writing the tool chain (compiler and C libraries) used to create the Linux Board Support Package for the Engine Board of the transportation controller.

5.8.4.3 Linux BSP Source Code

The vendor shall provide access to the source code used to produce the Linux Board Support Package environment for the Engine Board. (Note: This requires special arrangements, possibly an escrow.)

 

Slide 62:

Learning Objective #3

Example Other Requirements

5.8.4.4 API Software

The vendor shall provide operational API software for their transportation controllers once the API Reference Implementation is available from AASHTO, NEMA, and ITE.

Important:

See slides on "Creating a Specification Based on the ATC 5401 Standard" and "Additional Guidance When Procuring Application Software" in Module A208.

 

Slide 63:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 64:

Learning Objective #3

Which of the following is NOT an essential part of an ATC specification?

Answer Choices

  1. Optical disk requirements
  2. CPU performance requirements
  3. TFCS requirements
  4. User interface requirements

 

Slide 65:

Learning Objective #3

Review of Answers

A small graphical green and yellow check mark representing correct.a) Optical disk requirements
Correct! There is no mention of optical disks in ATC 5201 Standard v06.

A small graphical red and yellow X representing incorrect.b) CPU performance requirements
Incorrect. CPU performance requirements should be set by the user as the minimums allowed are low for contemporary processors.

A small graphical red and yellow X representing incorrect.c) TFCS requirements
Incorrect. The TFCS architecture in which the ATC unit is going to reside must be stated in the specification.

A small graphical red and yellow X representing incorrect.d) User Interface requirements
Incorrect. There are various UI options provided by ATC 5201 Standard v06. These requirements should be explicit.

 

Slide 66:

Summary of Learning Objective #3

Describe a Specification Based on the ATC 5201 Standard v06

 

Slide 67:

Learning Objective #4: Verify an ATC Procurement Specification

 

Slide 68:

Learning Objective #4

Verifying the Specification Using Traceability

 

Slide 69:

Learning Objective #4

Needs-To-Requirements Traceability

 

Slide 70:

Learning Objective #4

Needs-To-Requirements Traceability (cont.)

 

Slide 71:

Learning Objective #4

Needs-to-Requirements Traceability Matrix (NRTM)

UN ID User Need Req ID Requirement
6.5.1 NEMATS2 Equipment 5.2.1 NEMA TS 2 Type 2 Interfaces
    5.6.1 NEMA Operating Voltages
    5.6.2 NEMA Operating Frequencies
    5.6.3 NEMA Power Interruptions
7.3.1 Minimum Display Size 5.3.3 Text-Based Display Size

 

Slide 72:

Learning Objective #4

Verifying Conformance and Compliance

 

Slide 73:

Learning Objective #4

Verifying Conformance and Compliance

 

Slide 74:

Activity. A placeholder graphic with an image of hand over a computer keyboard to show that an activity is taking place.

 

Slide 75:

Learning Objective #4

Which of the following is a TRUE statement?

Answer Choices

  1. Agencies use standards so that they don't have to use specs
  2. There should only be one requirement per user need
  3. Demonstration may be used to verify compliance
  4. Traceability is not used in verifying specifications

 

Slide 76:

Learning Objective #4

Review of Answers

A small graphical red and yellow X representing incorrect.a) Agencies use standards so that they don't have to use specs
Incorrect. Agencies use standards to write their procurement specifications.

A small graphical red and yellow X representing incorrect.b) There should only be one requirement per user need
Incorrect. There may be multiple requirements needed to fully address a user need.

A small graphical green and yellow check mark representing correct.c) Demonstration may be used to verify compliance
Correct! Other methods of verifying compliance are through inspection, analysis, and testing.

A small graphical red and yellow X representing incorrect.d) Traceability is not used in verifying specifications
Incorrect. Traceability is used to help determine if the specification is complete and that all user needs identified are addressed.

 

Slide 77:

Summary of Learning Objective #4 Verify an ATC Procurement Specification

 

Slide 78:

What We Have Learned

  1. In a systems engineering development process, the agency specification is the result of requirements development.
  2. Specifications based on the ATC 5201 Standard v06 are a composite of standards and/or other specifications.
  3. Areas that must be addressed in an ATC specification are operational voltages, user interface requirements, input/output requirements, CPU, performance, and memory requirements.
  4. Agencies should verify that their ATC specification conforms to ATC 5201 Standard v06 and verify that vendors provide controllers that comply with their ATC specification.

 

Slide 79:

Resources

 

Slide 80:

Questions? A placeholder graphic image with word Questions? at the top, and an image of a lit light bulb on the lower right side.