This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-052 - Bidirectional Traceability Between Higher Level Requirements and Software Requirements

1. Requirements The project manager shall perform, record, and maintain bidirectional traceability between the software requirement and the higher-level requirement.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

If Class D software is safety critical, this requirement applies to the safety-critical aspects of the software.























Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

2. Rationale

Software requirements come from a variety of sources, including system requirements specifications, safety standards, security standards, hazard and risk analyses, system constraints, customer input, software safety "best practices," etc. 276 Bidirectional traceability matrices help ensure that all the requirements included in the Software Requirements Specification (SRS) trace back to a higher-level requirement that is the source or reason for having that requirement in the SRS. Bidirectional traceability also helps ensure that all requirements are addressed, and that only what is required is developed. Bidirectional traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

3. Guidance

Bidirectional traceability is defined as an “association among two or more logical entities that is discernible in either direction (to and from an entity)” (ISO/IEC/IEEE 24765:2010 Systems and software engineering—Vocabulary 230).

Bidirectional traceability is a traceability chain that can be traced in both the forward and backward directions as illustrated below (Bidirectional Requirements Traceability, Westfall, 2006 356). It is important because it can point out software design elements that are not fulfilled in the code (i.e., missing or incomplete functionality) as well as source code that does not have a parent design element (i.e., extra functionality). Ideally, the trace does not identify any elements that have no source, such as a design element with no parent requirement, but if such "orphan" elements are discovered in the trace, they need to be discussed by the project team and assurance personnel to determine if the "orphan" elements are necessary. If they are determined to be necessary, any missing source elements, such as requirements, are added to the project.

Figure 2 illustrates possible sources of higher level requirements that are to be traced into the software requirements.

Using a matrix such as the one shown below (Bidirectional Requirements Traceability, Westfall, 2006 356), allows a single exercise to show traceability both forwards and backwards. The matrix is completed left to right early in the appropriate phase in the project life cycle. As each column is completed, the forward trace is extended to the next set of products. Simply starting with a column such as the LLD (low-level design) Section and looking at the data in the columns to the left shows the backward traceability from a LLD element to its parent HLD (high-level design) element and back to the parent requirements.

Missing requirements are an indication that the resulting software product may not fully meet the goals and objectives for which the software is being designed. Extra requirements mean the end product may include unnecessary features and functionality which add complexity and allow for additional areas where problems could occur with the software.

This requirement, SWE-052, is specific to tracing software requirements to higher-level requirements.  Software requirements come from a number of different sources and can also be derived, if needed.  Sources of requirements include, but are not limited, to the following items:

  • Hardware specifications.
  • Computer\processor\programmable logic device specifications.
  • Hardware interfaces.
  • Operating system requirements and board support packages requirements.
  • Data\File definitions and interfaces.
  • Communication interfaces including bus communication and fault interfaces.
  • Software interfaces.
  • Derived from domain analyses.
  • Fault detection, isolation and recovery actions and requirements.
  • Models.
  • Commercial software interfaces and functional requirements.
  • Software security requirements.
  • User interface requirements.
  • Algorithms.
  • Legacy or reuse software requirements.
  • Derived from operational analyses.
  • Prototyping activities.
  • Interviews.
  • Surveys.
  • Questionnaires.
  • Brainstorming.
  • Observation.
  • Software test requirements.
  • Software fault management requirements.
  • Hazard analyses.

Per the NASA Software Safety Guidebook 276 , the key benefits of tracing requirements include:

  • Verification that all user needs are implemented and adequately tested. Full requirements test coverage is virtually impossible without some form of requirements traceability.
  • Verification that there are no "extra" system behaviors that cannot be traced to a user requirement.
  • Improved understanding of the impact of changing requirements.

When creating a bidirectional traceability matrix, consider the following actions:

  • Create the matrix at the beginning of the project. 147
  • Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage. 147
  • Capture the source of the requirement, such as the document or standard identifier for the highest level requirements or the unique identifier for the higher-level (parent) requirement.
  • List a requirement once and show all of its higher level requirement relationships using the appropriate identifiers; do not duplicate requirements in the traceability matrix.  
  • Consider including the requirement text in the matrix (rather than just the identifier).
  • Keep the matrix maintained throughout the life of the project.
  • Assign responsibility for creating and maintaining the matrix to a project team member, since managing the links/references can be a labor-intensive process that needs to be tracked and monitored. 142
  • Maintain the matrix as an electronic document to make maintenance and reporting easier.
  • Create the matrix such that it may be easily sorted to achieve/convey bi-directional traceability. 233
  • Provide justification for requirements that are not directly traceable to higher-level requirements to show that they are included for a purpose.
    • For example, a system architectural design that creates multiple computer software configuration items (CSCI) may result in requirements about how the CSCIs will interface, even though these interfaces are not covered in system requirements. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation.
  • Have the matrix reviewed at major phases / key reviews of the project. 

NASA-specific bidirectional traceability resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to bidirectional traceability may be found in the following related requirements in this Handbook:


Bidirectional Traceability Between Software Requirements and Software Design


Bidirectional Traceability Between Software Design and Software Code


Bidirectional Traceability Between Software Test Procedures and Software Requirements

4. Small Projects

For small projects without access to a requirements tool that includes tracing features and with time/budget limitations preventing them from acquiring a new tool and associated training, requirements tracing may be done with a spreadsheet (such as Microsoft® Excel), a simple database (such as Microsoft® Access)  or a textual document. It is very important that the project be diligent about keeping such traces up to date as these methods do not include automatic updates when requirements, design elements, or other relevant documents change.

Value-based-requirement tracing may be an option for projects with small budgets where traceability of safety-critical requirements is the priority. Value-based requirement tracing prioritizes all of the requirements in the system, with the amount of time and effort expended tracing each requirement depending on the priority of that requirement. This can save a significant amount of effort by focusing traceability activities on the most important requirements. However, value-based tracing requires a clear understanding of the importance of each requirement in the system; it may not be an option if full tracing is a requirement of the customer or the development process standards used for the project. 237

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser

Requirements Experts


Requirements Experts ...

Tools and Templates for Developing Requirements. Others services and training also available.

Requisite Pro


IBM Rational ...

Rational RequisitePro helps project teams to manage their requirements, to write good use cases, to improve traceability, to strengthen collaboration, to reduce project rework, and to increase quality. Version 7.1.0.




ENSER/Parametric Technology Corporation (PTC) ...

Windchill RequirementsLink. Requirements capture and tracking tool. Windchill RequirementsLink - an integral option for Windchill PDMLink - lets you manage product requirements, including change control and associating requirements with specific product structures and design content. With bi-directional traceability between customer needs, market requirements and the underlying technical requirements, you can ensure that customer and market requirements are satisfied by designs, and properly verified during development.


Requirements traceability tool

SPAN - Accessible to NASA users via SPAN tab in this Handbook. By Request - Non-NASA users, contact User for a copy of this tool.

GSFC ...

This tool, an Excel spreadsheet, provides bidirectional traceability between requirements, design, code, and test procedures. For a list of features, see the tools section of the GSFC PAL. Note: You must be on site at Goddard in order to access this file. Search in span for "GSFC_TL_20161114_Req_Trace_Tool"


PTC Integrity


PTC ...

PTC Integrity is a systems and software lifecycle management (SSLM) and application lifecycle management (ALM) platform used for Process automation and workflow management


GSFC Requirements Matrix Tool

SPAN - Accessible to NASA users via SPAN tab in this Handbook. By Request - Non-NASA users, contact User for a copy of this tool.



This tool, an Excel spreadsheet, provides bidirectional traceability between requirements, design, code, and test procedures. Available in SPAN on page: GSFC_TL_20161114_Req_Trace_Tool




IBM® Rational® ...

IBM® Rational® DOORS® family is a group of requirements management tools that allow you to capture, trace, analyze and manage changes across the development lifecycle.


Dimensions® RM


MicroFocus ...

Create and manage requirements more efficiently. Dimensions® RM (formerly Serena® Dimensions RM) increases visibility and collaboration across business and delivery teams. Powerful reporting and tracking provide end-to-end traceability from initial concepts to production delivery.



Micro Focus ...

CaliberRM® is a requirements management tool that ensures that applications meet end user needs. Using CaliberRM, analysts, developers, testers and other stakeholders accurately capture and communicate the user's requirements throughout the application lifecycle. Version 11.5.

6. Lessons Learned

The NASA Lessons Learned database contains the following lesson learned related to bidirectional traceability:

Orbital Space Plane - Technical Rigor & Integrity (Compromise of technical products due to poor requirement traceability.) Lesson Number 1504: Life cycle milestone reviews can be affected by poor requirement traceability.  The project milestone review deliverables for the project described in the Lesson Learned "did not effectively communicate the work performed by the contractors to the reviewers. Contractor requirements traceability matrices did not fully address the issues of requirement rationale and allocation. The number of documents delivered and the lack of clear organization for traceability of requirements hampered the milestone (SRR, SDR) review process." 560 

  • No labels