DI-MGMT-82133A

Requirements Traceability Verification Matrix (RTVM)

The RTVM provides bidirectional traceability from high-level system performance requirements to the lowest-level requirements and is used to verify how each requirement is verified.

Approval DateJuly 29, 2025

AMSC NumberN10593

Preparing ActivityAS

Project NumberMGMT-2025-019

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Requirements Traceability Verification Matrix (RTVM) provides bidirectional traceability from high-level system performance requirements, to the lowest-level requirements. The RTVM shows the traceability and allocation of the requirements contained in the specification tree (i.e. performance specification, detailed specification, subsystem specification, software requirements specification, interface specification and design documentation). The RTVM is also used to verify how each requirement is verified.

This DID contains the format, content, and intended use information for the data product resulting from the work task described in the contract SOW.

Preparation Instructions

1Reference documents.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices and revisions, shall be as specified in the contract.

2Format:The RTVM shall be in an electronic relational database format that can be manipulated to show bidirectional requirements traceability and track the verification of each requirement.

3Content:The RTVM package shall contain the following:

3.1Cover Page and Documentation.The RTVM software database files shall contain the following:

3.1.1Cover Page:Enter the Title, Date of Issue, Revision Date Contract Number, Contractor's name and address, Distribution Statement (as delineated in the contract), Export Control Warning Label (as delineated in the contract and if applicable), and Security classification.

3.1.2Record of Change Page:Enter a record of all changes made to the RTVM.

3.1.3Database Architecture Description Pages:Enter a detailed description of the database, show relationships and define all the terms/acronyms used in the database fields.

3.2Data Description:This Section describes the data to be contained in the RTVM relational database.

3.2.1Tier 0 Unique Identification Number (UID):Enter the UID for every requirement in the system configuration baseline (functional and physical). Example: REQ-T0-PROJECTNAME-001.

3.2.2Source document:For each specification and source document, enter the document number and title for the source of each requirement statement.

3.2.3Specification or Source Document Paragraph Number:Enter the specification or source document paragraph number for each requirement.

3.2.4Requirement Text (Tier 0):Enter the specification or source document requirement text. Tier 0 requirements are broad statements of intent. They describe what the system needs to accomplish without specifying how it should be done.

3.2.5Tier 1 UID:Enter the UID for every requirement in the system configuration baseline (functional and physical). (Example: REQ-T1-PROJECTNAME-001)

3.2.6Tier 1 Requirement Text:Tier 1 requirements in an RTVM represent the highest level of abstraction in the project's requirements hierarchy. They articulate the fundamental needs, goals, and objectives that the project aims to satisfy.

3.2.7Tier 2 UID (if required):Enter the UID for every requirement in the system configuration baseline (functional and physical). (Example: REQ-T2-PROJECTNAME-001)

3.2.8Tier 2 Requirement Text (if required):Tier 2 requirements are derived directly from the Tier 1 requirements. They take the high-level needs and objectives defined in Tier 1 and begin to translate them into more specific system-level or feature-level requirements. They define what the system or specific features within the system must do to satisfy the Tier 1 objectives.

3.2.9Tier 3 UID (if required):Enter the UID for every requirement in the system configuration baseline (functional and physical). (Example: REQ-T3-PROJECTNAME-001)

3.2.10Tier 3 Requirement Text (if required):Tier 3 requirements are derived directly from the Tier 2 requirements. They represent the most detailed level of requirements specification, providing the granular instructions needed for developers to implement the system. They define how the system will achieve the functionality outlined in Tier 2.

3.2.11Requirement Type:The RTVM database shall identify if the requirement is "Derived" or "Decomposed".

3.2.12Requirement Attribute:For each requirement, define whether the requirement is a measure of performance, design parameter, software functional requirement, interface requirement, physical parameter, environmental or cybersecurity (This data field can encompass other data attributes if needed.)

3.2.13OEM Compliance of Requirement:The RTVM database shall identify if the OEM's compliance of the requirement is "Compliant", "Non-Compliant", or "Partial Compliant".

3.2.14Requirement Status:Identify the Requirement status for each requirement as "Approved", "Under Review", "Needs Revision", or "Rejected". The status should identify the latest revision number.

3.2.15Non-Conforming Requirements:For non-conforming requirements, enter the System Trouble Report (STR) and Deficiency Report (DR) number and title.

3.2.15.1Hyperlink:Provide hyper-link to the STR and DR databases.

3.2.16Design Reference:Enter the specific piece of design information (e.g., design document section, drawing, etc.) associated with each requirement.

3.2.17Requirement Allocation:Enter the specific system, subsystem, hardware item, component, Computer Software Configuration Item, Computer Software Component and Computer Software Unit that each requirement has been allocated. System level requirements shall be allocated to all Configuration Items defined for the system.

3.2.18Form of End Product:Enter the form and maturity level of the end product used for verification. For example, the form can be the system, subsystem, unit level, software configuration Item and the maturity level can be the first article, production representative, prototype or final configuration item.

3.2.19Verification Method:For each requirement, enter the verification method as follows:

3.2.19.1"Analysis"An element of verification that uses established technical or mathematical models or simulations, algorithms, charts, graphs, circuit diagrams, or other scientific principles and procedures to provide evidence that stated requirements were met. [Source: MIL-STD-961E with Change 2]

3.2.19.2"Demonstration"An element of verification that involves the actual operation of an item to provide evidence that the required functions were accomplished under specific scenarios. The items may be instrumented and performance monitored. [Source: MIL-STD-961E with Change 2]

3.2.19.3"Inspection"An element of verification that is generally nondestructive and typically includes the use of sight, hearing, smell, touch, and taste; simple physical manipulation; and mechanical and electrical gauging and measurement. [Source: MIL-STD-961E with Change 2]

3.2.19.4"Test"An element of verification in which scientific principles and procedures are applied to determine the properties or functional capabilities of items. [Source: MIL-STD-961E with Change 2]

3.2.20Verification Document:Enter the document number, title, and date of the verification document that contains the verification method.

3.2.21Verification Document Paragraph:Enter the verification document paragraph number that provides the verification method.

3.2.22Verification Procedure:Enter the verification procedure section, and verification procedure step(s) that provides the verification method for each requirement.

3.2.23Other Tests:Enter the names of other tests conducted prior to verification of the requirement.

3.2.24Verification Results:Enter the results of the verification for each requirement. Did system under test conform to the requirement? (Yes, No).

3.2.25Corrective Actions:Enter all corrective actions taken and the results of the corrective actions.

3.2.26Comments:Enter explanatory notes as required.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer