Content updates needed on this page: 

  1. Update tabs as necessary
  2. Consider adding some SWEs and topics such as SWE-020 - Software Classification, SWE-205 - Determination of Safety-Critical Software, SWE-152 - Review Requirements Mapping Matrices, SWE-212 - NASA-STD-8739 Mapping Matrices, 7.02 - Classification and Safety-Criticality, etc.
  3. Consider adding documentation content topics into section 6.5 such as 5.08 - SDP-SMP - Software Development - Management Plan, etc.
7

1. Purpose

This topic defines how Software Technology Readiness Levels (STRLs) are used as part of Entrance and Exit Criteria (EEC) across NASA software and system milestone reviews. STRLs provide a maturity-based assessment that complements artifact-based evaluations, enabling better-informed technical and risk decisions.

2. Scope

  • All NASA programs using software that implements new, modified, or reused technologies.
  • Human-rated and non-human-rated systems.
  • Heritage, COTS/MOTS/GOTS, research, and newly developed components.
  • All major milestone reviews (MCR, SRR, SwRR, PDR, CDR, SIR, TRR, ORR, FRR).

3. Background

3.1 Software TRLs

  • Define maturity levels from TRL 1 (concept) to TRL 9 (flight-proven).
  • Evaluate documentation, logic stability, prototype demonstrations, and test fidelity.
  • Support maturity-based readiness assessments.
  • NASA NPR 7123.1 NASA Systems Engineering Processes and Requirements defines the TRLs at an agency level.

3.2 System Technology Readiness Alignment

  • Provides correlation between software maturity and system-level TRAs.
  • Supports continuous maturity assessment and risk reduction.
  • Informs technology transition planning for low-TRL items.

4. Rationale for Integrating STRLs into Reviews

Although STRLs provide useful structure, traditional TRL concepts have known limitations when applied to software. Software maturity is heavily influenced by the hardware and system context in which it executes, meaning that the same code may demonstrate different levels of readiness depending on processor architecture, memory layout, timing behavior, or I/O interactions. Additionally, even small changes in software can have cascading effects across an entire code base, effectively resetting maturity in ways not seen in hardware. Frameworks and reusable infrastructures also present challenges because they often evolve non-linearly, making it difficult to assign a single maturity level. Finally, software flown in space may not have executed all paths or functions, leaving unexercised logic that prevents full confidence in TRL 9 readiness.

  • Artifact completeness alone does not ensure technical maturity.
  • STRLs provide objective evidence of feasibility and readiness.
  • Early identification of immature software reduces downstream risk.
  • Supports consistent decision-making across programs.

Integrating TRLs with milestone reviews has advantages but does not represent a complete solution, the software itself may be matured through multiple projects that have their own milestone reviews.  These alternate milestone reviews increase the TRL for that instantiation of the software and system.

The distinction between the algorithm (the mathematical equations and/or logic) and the software code (including implementation) must be made.  The algorithm may have been used before but the implementation of that into the software can be different.

5. TRL ↔ Milestone Review Mapping

The TRLs presented below are based on a new development of software in a complete project.  If software is being reused, it is possible that the software TRL is higher or lower depending on the scenario and the key inputs presented below.

Key inputs to be considered:

  • Configuration files
  • Tool chains
  • Inputs into the software
    • Sensors, Simulations, and similar
  • Platform Hardware/software
    • Processor, RAM, Operating System, Endian
  • Algorithm assumptions/limitations