Module 4 - A103
A103: Introduction to ITS Standards Requirements Development
HTML of the Student Supplement
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
(Extended Text Description: Cover page graphic including title “A103 Introduction to ITS Standards Requirements Development” with blue background, three diagonal lines in the middle of the page in lighter blue, at the lower middle left side there is a logo with a white background square with words “Standards ITS Training” and “Student Supplement” under the white logo box. Directly under this are words “RITA Intelligent Transportation Systems Joint Program Office.”)
A103: Introduction to ITS Standards Requirements Development
Table of Contents
Purpose 3
1 Defining Requirements for Overall Operation to Satisfy User Needs 3
2 Well-Formed Requirements 6
3 Defining the System and Interfaces as Functional Architecture 8
4 Using Decomposition of the Architecture and Requirements as Necessary to Properly Define the System 11
5 Verifying that Requirements are Complete and Correct 11
6 How Requirements Development Applies to ITS Communication Standards 13
References 14
PURPOSE
This participant outline provides supplemental information for the Professional Capacity Building (PCB) Module A103. In some cases, additional information is included within the supplement. In other cases, references are provided for more in-depth study. Some information may be repeated from the module for context.
Module A103 introduces what requirements are, where they fit in the project life cycle, how they are used to satisfy user needs and how to determine if they are correct. In A103, participants learn:
The remainder of this supplement is organized based upon these learning objectives and concludes with general references and a glossary.
1 DEFINING REQUIREMENTS FOR OVERALL OPERATION TO SATISFY USER NEEDS
Systems Life-Cycle and the Systems Engineering Process (SEP)
(Extended Text Description: “Systems Life-Cycle and the Systems Engineering Process (SEP).” A graphic of the systems engineering process (SEP). The main graphic of the SEP is a V-shaped diagram in gradated blue with some additional horizontal extensions on the left and right side of the top of the V shape. Each section is separated with dark blue lines. There is a key at the lower right showing the blue separator lines, and designating them as “Document/Approval.” The left horizontal extension is labeled as “Lifecycle Processes” and include the sections “Regional Architecture” (separated by a white space) to the second section labeled “Needs Assessment,” (blue line) “Concept Selection,” (blue line) “Project Planning,” (blue line) and “Systems Engineering Management Planning.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Subsystem Requirements,” “Detailed Design,” and “Software Coding / Hardware Fabrication” at the bottom juncture of the V shape. Underneath the bottom point of the V shape are the words “Implementation” then “Development Processes” and a long thin arrow pointing to the right labeled “Time Line.” There is a long thin diagonal arrow pointing down along the left side of the V labeled “Decomposition and Definition.” From the bottom point of the V, the sections begin to ascend up the right side of the V with “Unit Testing,” (blue line) “Subsystem Integration,” (blue line) “Subsystem Verification,” (blue line) “System Integration,” (blue line) “System Verification,” (blue line) “Initial Deployment,” (blue line) “System Validation,” and (blue line) “Operations and Maintenance.” There is a long thin arrow pointing up along the right side of the V shaped labeled “Integration and Recomposition.” At this point the sections on the right “wing” of the V are labeled with “Changes and Upgrades” and (white space) “Retirement/Replacement.” Between the V shape there are a series of gray dashed arrows connecting the related sections on each left/right side of the V shape. The first arrow (top) is labeled “System Validation Plan” and connects “Concept of Operations” on the left and “System Validation” on the right. The second arrow is labeled “System Verification Plan (System Acceptance)” and connects “System Requirements” on the left and “System Verification and Deployment” on the right. The third arrow is labeled “Subsystem Verification Plan (Subsystem Acceptance)” and connects “High-Level Design” on the left and “Subsystem Verification” on the right. The last arrow (at the bottom) is labeled “Unit/Device Test Plan” and connects “Detailed Design” on the left and “Unit/Device Testing” on the right. The slide has animation. As the instructor discusses each of the development processes, a circle is drawn around the process on the V diagram.)
https://ops.fhwa.dot.gov/publications/seitsguide/section3.htm#s3.3 https://ops.fhwa.dot.gov/publications/seitsguide/
Definition of Systems Engineering
Components of a Concept of Operations
Definitions of a Requirement
Types of Requirements
3.4.2.6 Determine Total Number of Events
The DMS shall allow a management station to determine the total number of events that the DMS has logged since powerup.
3.4.2.6 Determine Total Number of Events
The TSS shall process the Get, GetNext, or Set request in accordance with all of the rules of NTCIP 1103 v02, including updating the value in the database and initiating the transmission of the appropriate response, within 1 second of receiving the last byte of the request.
3.3.1.3 Data and Clock Communications Protocol The transfer of data shall take place over the data and clock links by means of the SDLC (Synchronous Data Link Control) Protocol, as defined by International Business Machines Corporation document GA27-3093-3, dated June 1986.
3.3.1.4.1.1 Required Error Report Contents
The error report sent from a receiving center to a sending center shall include:
a. Unique identifier of the receiving organization;
b. Unique identifier of the sending organization;
c. Unique error identifier; and
d. Error text.
5.1.26 Operating Ambient Temperature
The TFCS's shall have an operating ambient temperature range from -37 degrees Celsius to +74 degrees Celsius.
2.1.6 Transients, Power Service
The CA shall maintain all defined functions when the independent test pulse levels specified in 2.1.6.1 and 2.1.6.2 occur on the alternating-current power service.
3.4.2 Programming Language
The API function calls shall be specified using the C programming language as described by "ISO/IEC 9899:1999," commonly referred to as the C99 Standard.
2 WELL-FORMED REQUIREMENTS
Definition of a Well-Formed Requirement
WELL-FORMED REQUIREMENT
The Form: [Actor] [Action] [Target] [Constraint] [Localization]
Where:
Actor Identifies who or what that does the action
Action Identifies what is to happen
Target Identifies who or what receives the action
Constraint Identifies how to measure success or failure of the requirement
Localization Identifies the circumstances under which the requirement applies
Localization and constraint portions are important but not all requirements will have both
Example: The system [Actor] shall generate [Action] event reports [Target] containing the following information [Constraint] on a scheduled interval [localization]
If a requirement can't be stated in this simple format, you probably need to define the functionality using multiple requirements
Characteristics of Well-Formed Requirements
3 DEFINING THE SYSTEM AND INTERFACES AS FUNCTIONAL ARCHITECTURE
Functional Architecture
Example #1 - Architecture Diagram from the ITS Cabinet V2 Standard
(Extended Text Description: “Example #1 Architecture Diagram from the ITS Cabinet V2 Standard.” This is a graphic illustrating an example of a functional architecture diagram. The diagram is divided into three sections horizontally by two bold vertical dotted lines. The middle section uses about 60% of the width of the page. The two side sections use about 15% of the page width. The left section has two rectangular boxes labeled “Field Sensors” and “Field Displays & Other Devices” respectively. The right section has three rectangular boxes labeled “Central System or Other TFCS,” “External Reporting System” and “External Power” respectively. The center section had eight circles of various circles representing the functional elements of the ITS Cabinet Functional Architecture. They are labeled “Field Inputs,” “External Communications,” “Application Computer,” “System Reporting,” “Field Outputs,” “Cabinet Monitoring,” “Power Filtering & Distribution,” and “TFCS Components” respectively. There are labeled arrows showing the flow of information through the boxes and circles. Author's Note: The point is not the details but the style of the functional diagram.)
Example #2 - Architecture Diagram from the NTCIP 1208 CCTV Standard
(Extended Text Description: “Example #2 Architecture Diagram from the NTCIP 1208 CCTV Standard.” This is a graphic illustrating a second example of a functional architecture diagram. It has a rectangular dotted line around the graphic that takes up about 75% of the width of the page. The diagram has the following five lines of text in the upper right corner of the diagram: “Applicable Market Packages:,” “Network Surveillance,” “Surface Street Control,” “Freeway Control,” and “Incident Management.” In the upper left of the diagram there is a rectangle that takes up about 1/3 of the total diagram. At the top of the rectangle are the words “Traffic management Subsystem (TMS).” There is a dark oval with illustrations of three computer towers and a single computer monitor. The remainder of the diagram has labeled boxes of various sizes representing various functional elements of a Closed Circuit Television system. There are lines connecting the various boxes and the TMS box. The lines are labeled with a mixture of technology and data types used between the functional elements. Author's Note: The point is not the details but another style of a functional diagram.)
Example #3 - Architecture Diagram from the NTCIP 1213 ELMS Standard
(Extended Text Description: “Example #3 Architecture Diagram from the NTCIP 1213 ELMS Standard.” This is a graphic illustrating a third example of a functional architecture diagram. It has a rectangular dotted line with rounded corners as the boundary of the graphic. At the bottom inside the boundary is the text “Electrical and Lighting Management System (ELMS).” There are two rectangles inside the graphic boundary with dotted lines and rounded corners. The left rectangle takes up about 1/3 of the diagram. At the bottom of the rectangle it has the text “AT MANAGEMENT CENTER LOCATION.” In the middle of the rectangle there is a desktop computer illustration with the text “ELMS Management Station” underneath it. The right rectangle takes up about 2/3 of the diagram. At the bottom of the rectangle it has the text “AT FIELD LOCATION.” There is a box labeled “ELMS Device.” There are labeled boxes of various sizes to the right representing other functional elements of the ELMS field equipment. There is a laptop computer illustration below the “ELMS Device” box. There is a single line labeled “NTCIP” between the “ELMS Management Station” desktop computer and the “ELMS Device” box. There is a single line labeled “NTCIP” between the “ELMS Device” box and the “ELMS Management Station” laptop computer. There are various other labeled lines between the “ELMS Device” box and the other functional element boxes to the right of it. Author's Note: The point is not the details but another example of a functional diagram.)
4 USING DECOMPOSITION OF THE ARCHITECTURE AND REQUIREMENTS AS NECESSARY TO PROPERLY DEFINE THE SYSTEM
There are many ways to organize requirements. Below are three examples.
Example #1 - By Feature
3.2 System features
3.2.1 System Feature 1
3.2.1.1 Introduction/Purpose of feature
3.2.1.2 Stimulus/Response sequence
3.2.1.3 Associated functional requirements
3.2.1.3.1 Functional requirement 1
...
3.2.1.3.n Functional requirement n
...
3.2.2 System feature 2
3.2.m System feature m
Example #2 - By User Class
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Functional requirement 1.1
...
3.2.1.n Functional requirement 1.n
3.2.2 User class 2
...
3.2.m User class m
3.2.m.1 Functional requirement m.1
...
3.2.m.n Functional requirement m.n
Example #3 - By Mode
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
...
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
...
3.2.m Mode m
3.2.m.1 Functional requirement m.1
...
3.2.m.n Functional requirement m.n
5 VERIFYING THAT REQUIREMENTS ARE COMPLETE AND CORRECT
Traceability for Verifying Requirements
There are numerous types of traceability matrices used in ITS Standards, from the simple to the complex. Below are some examples.
Example #1
Requirements Traceability Matrix (RTM) traces requirements to the design elements of the standard. In this case, the design elements include the dialog (sequence of data exchanges) and objects (data elements) that are used to fulfill the requirement.
Requirement ID |
Requirement |
Dialog ID |
Dialog |
Object ID |
Object |
3.4.1.3.8 |
Execute Pending Configuration |
||||
4.3.1.3 |
Execute Pending Configuration Change |
||||
5.2.1 sensorSystemReset |
|||||
5.2.2 sensorSystemStatus |
|||||
3.4.1.3.9 |
Abort Pending Configuration |
||||
4.3.1.4 |
Abort Pending Configuration |
||||
5.2.1 sensorSystemReset |
|||||
5.2.2 sensorSystemStatus |
|||||
3.4.1.3.10 |
Validate Pending Configuration |
||||
4.3.1.5 |
Validate a Pending Configuration |
||||
5.2.1 sensorSystemReset |
|||||
5.2.2 sensorSystemStatus |
Example #2
Protocol Requirements List (PRL) traces user needs to requirements. It indicates whether the requirement is mandatory, optional, or if there is some conditional conformance to the standard. It then provides a checklist on whether users want to include the requirement in their project. The PRL also provides for other information to be added for further specification or if instructive information is necessary.
User Need Section Number |
User Need |
FR Section Number |
Functional Requirement |
Conformance |
Support/Project Requirement |
Additional Specifications |
2.5.2.1 |
Reset the TSS |
|||||
3.4.1.3.1 |
Restart the TSS |
M |
Yes |
|||
3.4.1.3.2 |
Reinitialize User Settings |
M |
Yes |
|||
3.4.1.3.3 |
Restore Factory Defaults |
M |
Yes |
|||
3.4.1.3.4. |
Retune |
M |
Yes |
|||
3.4.1.3.8 |
Execute Pending Configuration |
O.1 |
Yes/No |
|||
3.4.1.3.9 |
Abort Pending Configuration |
O.1 |
Yes/No |
|||
3.4.1.3.10 |
Validate Pending Configuration |
O.1 |
Yes/No |
|||
2.5.2.2 |
Initiate S |
ensor Diagnostics |
||||
3.4.1.3.6 Short Diagnostics |
M |
Yes |
||||
3.4.1.3.7 Full Diagnostics |
M |
Yes |
6 HOW REQUIREMENTS DEVELOPMENT APPLIES TO ITS COMMUNICATION STANDARDS
Contents of ITS Standards With SEP Content
Contents of ITS Standards Without SEP Content
PCB Modules on Standards With SEP Content
A203 Module on Writing Requirements When ITS Standards Do Not Have SEP - You will:
ITS Device Communications Standards With SEP Content
ITS Device Communications Standards Without SEP Content
REFERENCES
Web sites for ITS Standards
Web sites for Systems Engineering Development
Guides that Use the Systems Engineering Process
Specific Texts, Documents, and Standards