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
(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
Shelley Row, P.E., PTOE
Director
ITS Joint Program Office
(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)
(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:
Slide 4:
Target Audience
Slide 5:
Instructor
Ralph W. Boaz President
Pillar Consulting, Inc. San Diego, CA, USA
Slide 6:
Who Are Stakeholders?
TMC Operator, Field Maintenance, Operational Support (e.g. IT Dept.)Interfacing System Owner, Purchaser
Sponsor of the Project
Regulatory Agency (if there is one)
Public, Politician
Slide 7:
Stakeholders for a System
(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)
(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
Slide 12:
Learning Objectives (cont.)
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
(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
(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
(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
(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
(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
(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:
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
(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
(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?
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
https://www.standards.its.dot.gov/
Slide 64: