1. Requirements

4.1.2.3 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

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. ²⁷⁶ 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 ²³⁰).

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 ³⁵⁶). 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 ³⁵⁶), 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 ²⁷⁶ , 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. ¹⁴⁷
• Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage. ¹⁴⁷
• 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. ¹⁴²
• 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. ²³³
• 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:

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. ²³⁷

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

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." ⁵⁶⁰