Real-Time System Management Information Program Data Exchange Format Specification — Implementation Guidance
3. Requirements Identification
It may be useful for the reader to have DXFS Section 3 Functional Requirements and Annex A – NRTM available. At this point in the process, an implementer has identified the user needs for DXFS information interchange. This section will discuss and demonstrate how to use the NRTM to identify DXFS system interface requirements.
3.1 Background
The DXFS systems requirements (DXFS Section 3) define the formal requirements that satisfy all DXFS user needs. This is achieved through the development of a Needs to Requirements Traceability Matrix (NRTM) that traces each user need to one or more requirements.
The functional requirements are presented in two broad categories as follows:
- Data Exchange and Operational Environmental Requirements. These requirements define the required behavior of the system in exchanging data across the communications interface based upon the features identified in this document. These requirements are found in Sections 3.5 and 3.6 of the DXFS
- Architectural Requirements. In the context of the DXFS, these requirements define management of the interface connections between centers. They cover connection management, error handling, and the two basic methods of making connections (e.g., request/response and subscription/publication). These requirements are found in Section 3.4 of the DXFS).
3.1.1 Needs to Requirements Traceability Matrix (NRTM)
The Needs to Requirements Traceability Matrix (NRTM) presented in DXFS Annex A, (DXFS Annex A – is contained in a separate volume) maps the user needs defined in DXFS Section 2 to the requirements defined in DXFS Section 3. The DXFS NRTM lists each user need to be addressed by the DXFS, followed immediately by the requirement(s) that supports (and traces to) that user need. The table can be used by:
- A user or specification writer to indicate which requirements are to be implemented in a project-specific implementation.
- The interface implementer, as a checklist to reduce the risk of failure to conform to the standard through oversight.
- The supplier and user, as a detailed indication of the capabilities of the implementation.
- The user, as a basis for initially checking the potential interoperability with another implementation.
3.1.2 Using the NRTM to Specify a DXFS System Interface
The DXFS is a system interface specification used to define information exchanges between a center and other centers. For each user need, the DXFS identifies the set of requirements that relate to that user need. All Mandatory requirements must be selected in order to satisfy the user need. Depending on the deployment some (or all, or none) of the optional requirements will be selected.
The NRTM contains the following columns: User Need ID and User Needs columns, Requirement Type, Requirement ID, Requirement, Conformance, and Support.
3.1.2.1 User Need ID and User Needs Column
The user needs are defined within the DXFS Section 2. The NRTM is based upon the user needs defined within Section 2 and includes the paragraph number and user need title.
3.1.2.2 Requirement Type, Requirement ID, and Requirement Columns
The requirements are defined within DXFS Section 3. The NRTM traces from a user need to one or more DXFS requirements. The requirement type, requirement ID (Section 3 paragraph number), and requirement title are indicated within these columns.
3.1.2.3 Conformance Column
The following notations and symbols are used to indicate status and conditional status in the NRTM within this standard. Not all of these notations and symbols are necessarily used within this standard.
3.1.2.4 Conformance Symbols
The following symbols are used to indicate status in the NRTM table:
Table 1. Conformance Symbols.
| Symbol |
Value |
| M |
Mandatory – This requirement(s) is required to support the specified user need |
| M.# |
Support of every item of the group labeled by the same numeral # is required, but only one is active at a time |
| O |
Optional –This requirement may be included in support of the specified user need |
| O.# (range) |
Part of an option group. Support of the number of items indicated by the ‘(range)’ is required from all options labeled with the same numeral # |
| N/A |
Not-applicable (i.e. logically impossible in the scope of the standard) |
The O.# (range) notation is used to show a set of selectable options (e.g., O.2 (1..*) would indicate that one or more of the option group 2 options must be implemented).
Much of the DXFS NRTM is based upon the Needs to Requirements Traceability Matrix (NRTM) from TMDD Volume 1 (meaning that the conformance indication for requirements equals that given in TMDD). In some cases the entry in the DXFS NRTM is different due to the specific user need. For example user need 2.5.2.2 Travel Time Data for Roads will have requirement 3.5.3.3.2.5.2.4 Link Travel Time as M*, while in TMDD this requirement is O. Where the conformance requirement differs from TMDD the entry in the DXFS NRTM will be indicated with a “*”.
Conditional Status Notification: Table 2 describes entries for the predicate notation that may be used.
Table 2. Predicate Notation.
| Symbol |
Value |
| <predicate>: |
This notation introduces a single item that is conditional on the <predicate>. |
| <predicate>:: |
This notation introduces a table or a group of tables, all of which are conditional on the <predicate>. |
| (predicate) |
This notation introduces the first occurrence of the predicate either in the NRTM or in that specific user need. The feature associated with this notation is the base feature for all options that have this predicate in their conformance column. |
The <predicate>: notation means that the status following it applies only when the NRTM states that the feature or features identified by the predicate are supported. In the simplest case, <predicate> is the identifying tag of a single NRTM item. When the group predicate is true then the associated section shall be completed. The symbol <predicate> also may be a Boolean expression composed of several indices – .AND., .OR., and .NOT. are used to indicate the Boolean logical operations.
3.2 Requirements Selection Guidance
The objective of this step is to select the requirements for a project, based on the user needs selected for the project. The selection of requirements is performed by filling out the NRTM for the project. The NRTM contains a column that identifies user needs and a corresponding column that identifies requirements that are mapped to a user need. The NRTM is used both as a traceability matrix and as a way to specify which requirements will be mandatory for a specific deployment. To make finding a particular need easy in the NRTM, the row that contains the user needs identifier (UN ID) and title is highlighted. The rows that follow then are a set of minimum requirements (some mandatory, some optional) that satisfy the need. Note that once an optional requirement is selected for a deployment, it then becomes mandatory for that individual deployment. The following steps may be used to fill out the NRTM for a specific project:
- Identify the section of the NRTM that contains the User Need(s) identified as being project‑relevant.
- Within that section, identify the requirements that are mandatory to support the user need(s). Mandatory requirements contain the indicator ‘M’ in the Conformance column. An M* (M with an asterisk is a requirement that is Optional in one the standards supporting the DXFS (TMDD, SIRI, TCIP, or OASIS CAP), but which is Mandatory to support the user need as written for the DXFS. For example, travel time is optional in the TMDD Link Status Message, but is Mandatory in DXFS to allow travel time to be reported and to satisfy User Need 2.5.2.2 Travel Time Data for Roads. All mandatory requirements relating to a need must be selected if the need is selected. The requirements under each user need are organize by the type of design they support. For example:
- The requirements to support Dialogs.
- The requirements to support Request Messages, Response Messages, or Error Report Messages.
- Identify those optional requirements that will be necessary to support the deployment. Selecting these will make them mandatory for the deployment. In general, if a requirement is optional in DXFS and mandatory in the deployment then highlight, circle, or box, the word ‘Yes’ in the Support column. At this point the dialogs and information content of messages has been identified:
- The dialogs of the DXFS have been written such that the wording for the requirement adheres to the following pattern:
- Request-Response dialogs is “Send [Information or Control Message] Upon Request.
- Publication dialogs is “Publish [Information].”
- Subscription dialogs is “Subscribe [Information].”
- If the deployment will only include request-response dialogs, then only the requirement that reads “Send Link Status Information Upon Request” needs to be selected.
- If the deployment will use subscription-publication dialogs, then the requirements to “Publish Link Status Information” and “Subscribe Link Status Information” are selected.
- A project deployer may want to support all three of these dialog types. If so, the project deployer selects all three of the requirements relating to dialogs.
3.3 Requirements Selection Example
This section provides an example of how to select requirements, using the three steps identified above. Note Table 3 below shows the relevant page in the NRTM that contains the user need for the example.
- Identify the portion of the NRTM that contains the User Need(s) identified as being project-relevant. For this example the relevant user need is 2.5.2.2 Travel Time Data for Roads. The top row of Table 3 lists the User Need, the need for which we want to identify requirements (repeated below). Reviewing the NRTM, there are two sections of the requirements relating to the need. One set of requirements relates to link based travel times and one set of requirements relates to route based travel times. Consider in this example that the deployment will implement just a link based travel time. The outputs below are based on that assumption.
Table 3. Project Relevant User Needs
| UN ID |
User Need, Requirement Type, Required ID, Requirement |
Conformance |
Support |
| 2.5.2.2 |
Travel Time Data for Roads |
Optional |
Yes/No |
- Identify the requirements that are mandatory to support the user need. For each mandatory requirement indicate Yes in the Support Column (as shown below). Mandatory requirements contain the indicator ‘M’ in the Conformance column. An M* (M with an asterisk is a requirements that is Optional in one of the standards supporting the DXFS (TMDD, SIRI, TCIP, or OASIS CAP) that is Mandatory for the DXFS. For example, travel time is optional in the TMDD Link Status Message, but is Mandatory in DXFS to allow travel time to be reported and to satisfy User Need 2.5.2.2 Travel Time Data for Roads.
Table 4. Dialogs for Link Based Information.
| 3.5.3.3.2.1 |
Send Link Status Information Upon Request |
M |
Yes |
For each user need there are four portions of the requirements to consider for Mandatory requirements:
- The requirements to support Dialogs.
- Requirement 3.5.3.3.2.1 Send Link Status Information Upon Request, a dialog, is required. (shown above).
- The requirements to support Request Messages.
- For the example, the following three requirements are mandatory and Yes should be selected in the Support column.
Table 5. Request Message
| 3.5.3.3.2.4 |
Contents of the Link Status Request |
M |
Yes |
| 3.5.3.1.1 |
Contents of the Traffic Network Information Request |
M |
Yes |
| 3.5.3.1.1.1 |
Required Traffic Network Information Request Content |
M |
Yes |
- The requirements to support Response Messages.
- For the example, the following three requirements are mandatory. Note the third requirement is one of those with the M* mentioned above.
Table 6. Request Message
| 3.5.3.3.2.5 |
Contents of the Link Status Information |
M |
Yes |
| 3.5.3.3.2.5.1 |
Required Link Status Information Content |
M |
Yes |
 |
|
|
|
| 3.5.3.3.2.5.2.4 |
Link Travel Time |
M* |
Yes |
- The requirements to support Error Report Messages.
- For the example, the following two requirements are mandatory.
Table 7. Error Report Message
| 3.4.4.1 |
Contents of the Error Report |
M |
Yes |
| 3.4.4.1.1 |
Required Error Report Contents |
M |
Yes |
- Identify those optional requirements that are needed for the deployment. If the requirement is needed for the deployment, then for that deployment the Yes in the Support column should be selected. For the example, if the deployment is expected to provide link name along with the link travel time, then the following Optional requirement must be selected as indicated with the text ‘Yes’, highlighted from the Support column:
Table 8. Response Message
|
|
|
|
| 3.5.3.3.2.5.2.2 |
Link Name |
O |
Yes |
Table 9 below shows the completed project-specific NRTM for link based travel time as tailored to identify project-relevant requirements. In this example, the Support column indicates the selection of an optional requirement indicated as mandatory for a specific implementation.
Table 9. NRTM Prior to Tailoring.
| Reqmt Type |
Req ID |
Requirement |
Conformance |
Support |
| Dialogs for Link Based Information |
3.5.3.3.2.1 |
Send Link Status Information Upon Request |
M |
Yes/No/NA |
| Dialogs for Link Based Information |
3.5.3.3.2.2 |
Publish Link Status Information |
Subscription:O |
Yes/No/NA |
| Dialogs for Link Based Information |
3.5.3.3.2.3 |
Subscribe to Link Status Information |
Subscription:O |
Yes/No/NA |
| Request Message |
3.5.3.3.2.4 |
Contents of the Link Status Request |
M |
Yes |
| Request Message |
3.5.3.1.1 |
Contents of the Traffic Network Information Request |
M |
Yes |
| Request Message |
3.5.3.1.1.1 |
Required Traffic Network Information Request Content |
M |
Yes |
| Request Message |
3.5.3.1.1.2.1 |
Authentication |
O |
Yes/No |
| Request Message |
3.5.3.1.1.2.1.1 |
Operator Identifier |
O |
Yes/No |
| Request Message |
3.5.3.1.1.2.2 |
Roadway Network Identifier |
O |
Yes/No |
| Request Message |
3.5.3.1.1.2.3 |
Traffic Network Identifier |
O |
Yes/No |
| Response Message |
3.5.3.3.2.5 |
Contents of the Link Status Information |
M |
Yes |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
M |
Yes |
| Response Message |
3.5.3.3.2.5.2.1 |
Restrictions |
O |
Yes/No |
| Response Message |
3.5.3.3.2.5.2.2 |
Link Name |
O |
Yes/No |
| Response Message |
3.5.3.3.2.5.2.3 |
Link Direction |
O |
Yes/No |
| Response Message |
3.5.3.3.2.5.2.4 |
Link Travel Time |
M* |
Yes/No |
| Response Message |
3.5.3.3.2.5.2.11 |
Status Date and Time Change Information |
O |
Yes/No |
| Error Report Message |
3.4.4.1 |
Contents of the Error Report |
M |
Yes |
| Error Report Message |
3.4.4.1.1 |
Required Error Report Contents |
M |
Yes |
| Error Report Message |
3.4.4.1.2.1 |
Restrictions |
O |
Yes / No |
Note: UN ID: 2.5.2.2
User Need: Travel Time Data for Roads
Table 10. NRTM with Tailoring of Project-Relevant Requirements.
| Reqmt Type |
Req ID |
Requirement |
Conformance |
Support |
| Dialogs for Link Based Information |
3.5.3.3.2.1 |
Send Link Status Information Upon Request |
M |
Yes |
| Dialogs for Link Based Information |
3.5.3.3.2.2 |
Publish Link Status Information |
Subscription:O |
No |
| Dialogs for Link Based Information |
3.5.3.3.2.3 |
Subscribe to Link Status Information |
Subscription:O |
No |
| Request Message |
3.5.3.3.2.4 |
Contents of the Link Status Request |
M |
Yes |
| Request Message |
3.5.3.1.1 |
Contents of the Traffic Network Information Request |
M |
Yes |
| Request Message |
3.5.3.1.1.1 |
Required Traffic Network Information Request Content |
M |
Yes |
| Request Message |
3.5.3.1.1.2.1 |
Authentication |
O |
No |
| Request Message |
3.5.3.1.1.2.1.1 |
Operator Identifier |
O |
No |
| Request Message |
3.5.3.1.1.2.2 |
Roadway Network Identifier |
O |
No |
| Request Message |
3.5.3.1.1.2.3 |
Traffic Network Identifier |
O |
No |
| Response Message |
3.5.3.3.2.5 |
Contents of the Link Status Information |
M |
Yes |
| Response Message |
3.5.3.3.2.5.1 |
Required Link Status Information Content |
M |
Yes |
| Response Message |
3.5.3.3.2.5.2.1 |
Restrictions |
O |
No |
| Response Message |
3.5.3.3.2.5.2.2 |
Link Name |
O |
Yes |
| Response Message |
3.5.3.3.2.5.2.3 |
Link Direction |
O |
No |
| Response Message |
3.5.3.3.2.5.2.4 |
Link Travel Time |
M* |
Yes |
| Response Message |
3.5.3.3.2.5.2.11 |
Status Date and Time Change Information |
O |
No |
| Error Report Message |
3.4.4.1 |
Contents of the Error Report |
M |
Yes |
| Error Report Message |
3.4.4.1.1 |
Required Error Report Contents |
M |
Yes |
| Error Report Message |
3.4.4.1.2.1 |
Restrictions |
O |
No |
Note: UN ID: 2.5.2.2
User Need: Travel Time Data for Roads
