RTM

Understand and Practice the RTM Development Process

Requirements Traceability Matrix

Requirements Traceability Defined

  • Traceability ensures completeness; that all lower level requirements (including interface requirements) come from higher level requirements and that all higher level requirements are allocated to lower level requirements.  Traceability is also used to manage change and provides the basis for verification planning.

RTM Purpose

  • The RTM is a requirements management and verification planning tool 
    • Supports bi-directional requirements traceability 
    • Tracks every change made to requirements 
    • Helps identify requirement change impacts 
    • Helps plan requirement verification and validation 
    • Helps to ensure that project requirements are met during verification 
    • Helps to develop artifacts such as: RFPs, P-Specs, Sub-System Specs, Interface Specs, SOWs 
  • The RTM should be continually updated and reviewed during appropriate SETRs, Test Events and Milestones, and beyond Milestone C (In Service Reviews, ECPs in sustainment efforts)

RTM Structure

  • User Requirements Document section of RTM
    • SON, U-UNS, CDD, CPD, ORD, LOCs, etc 
  • System/Performance Spec section of RTM
  • Verification sections of RTM: 
    • Provides traceability to planned verification events, verification methods, and test procedures 
    • Summary of the observed results along with reference to location in verification documentation/reports –Verification method mapping complete NLT DT TRR 
    • Verification results captured by SVR 
  • Validation section of RTM (if desired): 
    • MCOTEA is validating agent for programs requiring independent OT 
    • For any program that does not require independent OT, the PM is the validating agent 

Identify if the RTM statements are true or false.

  • The RTM is one of the most important artifacts during a product's life cycle.
  • The RTM tracks every change made to requirements.
  • The RTM does not support verification planning.

Parsing

Parsing Defined

  • To break complex statements down into simple, more easily understood statements by following a set of rules so that they may be more accurately interpreted and managed. 
  • First, parsing is breaking down a paragraph into individual sentences 
  • Then, parsing is performed to the atomic level, or breaking down a sentence into individual statements

Parsing Rules

  • Dealing with “and” (parsing not required) 
    • Acronyms 
    • Between XXX and XXX
    • Both XXX and XXX
    • Titles of documents
    • Titles of table & figures

Parsing Importance

  • Produces statements that are more concise 
  • Simplifies identification and tracking of each individual requirement through spec to Verification & Validation
  • Supports identification of redundancies 
  • Ensures each statement is considered/dealt with individually 
  • Aids in identifying requirements needing clarification

Parsing Example

  • The system shall be green, weigh no more than 100 lbs, and fly. 
    • The system shall be green. 
    • The system shall weigh no more than 100 lbs. 
    • The system shall fly.

Parse the following statement: The bottle shall biodegrade within 12 months (T) / 8 months (O) upon disposal and shall not generate any toxic chemical when biodegrading.

Parse the following statement: The bottle shall be 30% (T) / 40% (O) lighter than the current generation.

Parsing Example

Scoping

Scoping Defined

  • Evaluating each statement to determine how each will be handled 
    • Is the statement a requirement?
    • If so, is the requirement redundant?  
    • Is the requirement a condition of another requirement’s evaluation?
    • Is the requirement ambiguous and in need of clarification?

Scoping Rules

  • Scoping should be done in collaboration with the user community, testers, etc
  • Example RTM Scoping Codes:
    • A - Appropriate 
    • Admin - Administrative code (used for titles, etc.) 
    • IDESC - Inappropriate – Descriptive 
    • IR - Inappropriate - Redundant (specified in Note) 

Scoping Importance

  • Addresses every statement within a document 
  • Identifies verifiable requirements 
  • Reduces/eliminates redundant requirements 
  • Ensures 100% positive coverage of all requirements, not simple elimination or exclusion from tracking 
  • Provides specific reason for exclusion of requirements

Scope the following statements.

  • Strengthener Polyhedral Oligomeric Silsesquioxane (POSS) shall be added to the material mixture.
    A - Appropriate
  • The battery connection shall be a bayonet type twist lock.
    A - Appropriate
  • Specifications for the Vehicle Adapter are contained in appendix 1.
    IDESC - Inappropriate Descriptive
  • This document identifies the performance characteristics of the ESS Bottle.
    IDESC - Inappropriate Descriptive

Mapping

Mapping Defined

  • Process of matching subsystem requirements to system/performance specification requirements to user requirements. 
  • Establish relationship between parent requirements and child requirements

Mapping Guidelines

  • Mapping is conducted in collaboration with project stakeholders 
  • A child requirement could be mapped to multiple parent requirements 
  • Multiple child requirements could be mapped to one parent requirement

Mapping Importance

  • Identifies if all high level requirements are fully addressed via lower level requirements 
  • Identifies potential  gold-plating (adding more to a system than is required which can increase cost and risk) 
    • Orphan requirements 
  • Identifies potential system capability gaps 
    • Childless user requirements

Map the following statements.

  • All variants shall be capable of being torn down in 30 minutes or less.
    The system shall be torn down for redeployment in a maximum of 30 minutes with one person.
  • The system variants shall be capable of withstanding shock and vibration
    The system, configured for transport shall be capable of withstanding “off-the road” rugged terrain environment.
  • The system will be operable by personnel wearing full MOPP Level IV.
    All system equipment shall be operable by personnel wearing full MOPP IV.
  • The bottle shall be 30% (T) lighter than the current generation.
    The bottle shall not exceed 14.1 grams empty weight.
  • The bottle opening shall allow for a flow rate of .5gal/minute (T).
    The bottle neck shall be tapered as specified in BTL-STD-11to allow for a flow rate of .5gal/minute.

RTM Development Exercise

Parsing Exercise - Step 1

Exercise uses MS Excel.

Parsing steps:

Copy each section and sentence into Excel.

Parsing Exercise - Step 2

Find and highlight the and statements.

Parsing Exercise - Step 3

Parse each statement to its lowest level.

  • Some statements may not contain an and and need to be parsed.

Parsing Exercise - Step 4

Fill in all paragraph sections.

Parsing Exercise - Step 5

Delete the original statements that were parsed.

Scoping Exercise - Step 1

Review each statement and identify the appropriate scoping code.

Scoping Exercise - Step 2

Filter to only show the "A" appropriate statements and transfer to the mapping tab.

Mapping Exercise

Identify the parent/child relationships between the user requirements and specifications.

Acronyms

  • CDD – Capability Development Document 
  • CM – Configuration Management 
  • CPD – Capability Production Document 
  • DAU – Defense Acquisition University 
  • DOORS – Dynamic Object-Oriented System 
  • DT – Developmental Test 
  • DT&E – Developmental Test and Evaluation 
  • ECP – Engineering Change Proposal 
  • FOC – Full Operational Capability 
  • IOC – Initial Operational Capability 
  • LOC – Letter of Clarification 
  • MCOTEA – Marine Corps Operational Test and Evaluation Agency 
  • MS – Microsoft 
  • NLT – No Later Than
  • ORD – Operational Requirements Document 
  • OT – Operational Test 
  • OT&E – Operational Test and Evaluation 
  • PG – Product Group 
  • PM – Program Manager 
  • PMM – Program Manager Marine 
  • RTM – Requirements Traceability Matrix 
  • SIAT – Systems Engineering, Interoperability, Architectures & Technology 
  • SE – Systems Engineering 
  • SETRs – Systems Engineering Technical Reviews 
  • SON – Statement of Need 
  • SVR – System Verification Review 
  • TRR – Test Readiness Review 
  • U-UNS – Urgent Universal Need Statement