1. Requirements

3.1.1.4 The project shall perform, document, 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

Classes C-E and Safety Critical are labeled "P (Center) +SO." This means that this requirement applies to the safety-critical aspects of the software and that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

Class C Not Safety Critical  and Class G are labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

Class F is labeled with "X (not OTS)."  This means that this requirement does not apply to off-the-shelf software for this class.

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. ²⁷⁶ 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. Traceability also helps ensure that all requirements are addressed, and that only what is required is developed. Traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

Bidirectional traceability is defined as 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.

3. Guidance

Before starting the traceability activity, it is assumed that the documents being traced (e.g., requirements, design, code, test data, etc.) have been approved.

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; however, traceability also extends to design, code, and test procedures (see SWE-059, SWE-064, and SWE-072).  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 CSCIs (Computer Software Configuration Items) 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

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 Excel), a simple database (such as 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." ⁵⁶⁰