Module 8 - A203
A203: Writing Requirements When ITS Standards Do Not Have SEP Content
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: Large graphic cover page with dark blue background with the title in white letters “A203 - Writing Requirements When ITS Standards Do Not Have SEP Content” At the middle left is the “Standards ITS Training” logo with a white box and letters in blue and green. The words “Student Supplement” and “RITA Intelligent Transportation Systems Joint Program Office” in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)
A203: Writing Requirements When ITS Standards Do Not Have SEP Content
Table of Contents
Purpose - 2
Requirements Development is a Process - 2
Avoiding Pitfalls When Writing Requirements - 4
Writing Requirements When An ITS Communication Standard Does Not Have SEP Information - 5
Traceability Matrices as Tools for Requirement Development - 8
NTCIP Device Standards With and Without System Engineering Content - 10
References - 11
This is the supplemental information for the Professional Capacity Building (PCB) Module A203. In some cases, additional information is included within the supplement and, references are provided for more in-depth study.
Module A203 trains how to write requirements that support a functional decomposition process and how to verify said requirements at the system, subsystem, and communications standard level. In A203, participants will be able to:
The remainder of this supplement is organized based upon these learning objectives and concludes with a section on references.
REQUIREMENTS DEVELOPMENT IS A PROCESS
Requirements development is recursive. Recall from the previous course how the system could be decomposed into subsystems. The process of defining Functional Requirements, Performance Requirements, Non-Functional Requirements, and Constraints can be applied recursively over the requirements expressed at higher levels. See Figure 1.
(Extended Text Description: Figure 1. Developing requirements recursively over previous levels of requirements. There are three rectangular boxes containing text; two on the left one on top of the other and one on the right placed midway between the two on the left. The first box is in the upper left side. The second box is about midway on the right side. The third is box is directly below the first in the lower left. There are arrows going from the first box to the second box to the third box. The first box has the word “SYSTEM” at the top of the box with bulleted items underneath “Functional Reqs,” “Performance Reqs,” “Non-Functional Reqs” and “Constraints.” The second box has the word “SUBSYSTEM” and the same bulleted items as the first box. The third box has the word “INTERFACE” and the same bulleted items as the first and second boxes. The graphic illustrates the same requirement processes being applied to different levels of the system. )
Figure 1: Developing requirements recursively over previous levels of requirements.
Requirements development is iterative. It is often the case that needs and requirements established at one stage of development must be revised or rephrased after later stages of development. Sometimes a project team will know that a requirement will need to be rephrased later. This is a case of "sufficient for purpose" to allow a project to advance to the next stage of development. See Figure 2.
(Extended Text Description: Figure 2. Developing requirements iteratively by revising and rephrasing after later stages of 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. )
Figure 2: Developing requirements iteratively by revising and rephrasing after later stages of development.
Requirements development is a process of discovery. All inquiry circles have periods of action and reflection: action to move forward and reflection to consider whether the work is complete, going in the right direction, or consider a redirection. See Figure 3.
When we get to the subsystem and interface levels, we find that the standards can be a source for discovery.
(Extended Text Description: Figure 3. Developing requirements is a process of discovery. This graphic shows a large circle with three arrows located equidistantly around the circle pointing in a clock-wise direction. Between the arrows are three ovals with text located equidistantly around the circle. The first oval (on the left side of the circle) says “Discover.” Going clockwise around the circle, the next oval says “Document.” Continuing clock-wise around the circle the next oval says “Validate.” In the middle of the circle are small representations of people with the word “Stakeholders” over them. There are arrows pointing out from the people to the ovals around the circle. The “Validate” oval (located on the lower right portion of the circle has an arrow pointing from the oval to text to the right that says “Next Activity.” )
Figure 3: Developing requirements is a process of discovery.
AVOIDING PITFALLS WHEN WRITING REQUIREMENTS
Definition of a Well Formed Requirement
A statement of system functionality (a capability) that can be validated, and that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and is qualified by measurable conditions and bounded by constraints. (IEEE Std 1233, 1998 IEEE Guide for Developing System Requirements)
STRUCTURE OF A 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
Some pitfalls to avoid when building well-formed requirements are as follows:
Pitfall #1 - Design and implementation. There is a tendency on the part of analysts and customers who are defining requirements to include design and implementation decisions along with the requirements statements. Such information may still be important. In this case, the information should be documented and communicated in some other form of documentation in order to aid in design and implementation.
Pitfall #2 - Overspecified. Requirements that express an exact commercial system set or a system that can be bought rather than made (these are not an expression of what the system should do). Requirements that state tolerances for items deep within the conceptual system (frequently stated as error requirements at very low levels); Requirements that implement solutions (requirements state "what" is needed).
Pitfall #3 - Overconstrained. Requirements with unnecessary constraints. (For example, if a system must be able to run on rechargeable batteries, a derived requirement might be that the time to recharge should be less than 3 hours. If this time is too restrictive and a 12 hour recharge time is sufficient, potential solutions are eliminated.)
Pitfall #4 - Unbounded. Requirements making relative statements. (These requirements cannot be verified and may only need to be restated. For example, the requirement to "minimize noise" may be restated as "noise levels should not exceed..."). Requirements that are open-ended (frequently stated as "including, but not limited to... " or lists ending in "etc."). Requirements making subjective or vague statements (frequently contain terms such as "user friendly," "quick response time," or "cost effective").
Pitfall #5 - Assumptive. Requirements based on undocumented assumptions. The assumption should be documented as well as the requirement. Requirements based on the assumption that a particular standard or system undergoing development will reach completion. The assumption and an alternative requirement should be documented.
WRITING REQUIREMENTS WHEN AN ITS COMMUNICATION STANDARD DOES
NOT HAVE SEP INFORMATION
It is important to understand how the design is specified in the standard. For device standards this is generally expressed as Objects and Dialogs. Objects are organized in a Management Information Base (MIB):
Example Object Definition (Data Element Definition) in ASN.1 Notation
Dialogs - A series of communication exchanges to execute some feature or task. A dialog may be expressed in words or as a sequence diagram.
Example #1: A Dialog Expressed in Words
126.96.36.199 Retrieve Sensor Zone Class Labels
The standardized dialog for a management station to retrieve the class labels for a sensor zone shall be as follows:
x = zoneClassEntry y = sampleZoneClass
Example #2: A Dialog Expressed as a Sequence Diagram
(Extended Text Description: Example #2. A Dialog Expressed as a Sequence Diagram - This illustrates a graphical representation of an example message dialog diagram between a Management Station and an Electrical Lighting Management Station (ELMS) Device. The main part of the diagram is defined by two widely spaced parallel vertical dotted lines. The line on the left is identified by a rectangular box at the top of the line containing the text “Management Station.” The line on the right is identified by a rectangular box at the top of the line containing the text “ELMS Device.” Between the boxes at the top is a larger rectangular box containing the text “Precondition: The management station shall ensure that there are sufficient rows in the action, day plan and time base schedule tables to down load the proposed schedule.” A point of communication is represented by small boxes on the lines. Message transfers are represented by horizontal lines between the left and right vertical dotted lines. There are small boxes on the left dotted line with solid line arrows going across horizontally to small boxes on the right dotted line. There are small boxes on the right dotted line with dotted line arrows going across horizontally to small boxes on the left dotted line. The horizontal lines are labeled with the data that is to be transferred. This depicts the exchange of a set of information (dialog) between the Management station and the ELMS Device. There are additional larger rectangular boxes to the right of the main diagram. These contain text to identify when an exchange is to be repeated. There is also a larger rectangular box at the bottom of the diagram that is used as a key to identify the abbreviations used in the message labeling. )
Applying Discover-Document-Validate to the ASC Standard
TRACEABILITY MATRICES AS TOOLS FOR REQUIREMENTS DEVELOPMENT
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: Needs-To-Requirements Traceability Matrix (NRTM). User needs are traced to requirements.
Example #2: 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.
Example #3: Protocol Requirements List (PRL) Traces User Needs to Requirements but with additional information. It indicates whether the requirement is mandatory or optional within the standard or if there is some conditional conformance. 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.
NTCIP Device Standards With Systems Engineering Content
NTCIP Device Standards Without Systems Engineering Content
Web sites for ITS Standards
Web sites for Systems Engineering Development
Guides that Use the Systems Engineering Process
Specific Texts, Documents, and Standards
Finding the Relevant Standards