1. Requirements

2.6.2.5 The project shall require the software supplier(s) to make available, electronically, the software traceability data for the project's review.

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 through E and Safety Critical are labeled with "SO if D-E."  This means that for Classes D through E, this requirement applies only to the safety-critical aspects of the software.

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

2. Rationale

Traceability records help ensure that project requirements are carried through design, implementation, and verification to ensure they are implemented to produce the intended product. Traceability helps identify where requirements may be missing (i.e., dropped from the design or implementation), and where functionality does not have an originating requirement (i.e., a reason for being in the product).  The preferred traceability approach is bidirectional traceability, which traces work products forward to the next life cycle phase as well as backward to the preceding phase, keeping a continuous link from beginning to end.

Reviewing traceability records allows the acquirer (NASA) to ensure that requirements given to the supplier are being implemented and verified and provides a level of assurance that the resulting product will fulfill its goals and objectives.  Traceability records also allow the acquirer to assess the impact of changes to work products when a requirement changes or an issue is found that must be addressed.

Electronic access to traceability data, or any supplier records, can save time and cost for both the supplier and the acquirer because they do not have to duplicate records and the acquirer can use search utilities to review the records.

3. Guidance

Include requirements for suppliers to provide electronic access to traceability data as part of the solicitation (e.g., RFP (Request for Proposal)) as well as the resulting contract.

Access could be as simple as an account on the supplier (provider) system that contains the traceability records. Alternatively, access could be granted by providing electronic copies of the records through email or via electronic media, such as a USB drive or DVD, making sure to follow the appropriate NASA IT security policies for electronic media.   

Factors which could affect the actual method by which the supplier provides electronic access to traceability data include:

• The supplier's traceability tools.
• Acquirer preference for receipt of the data.
• Ease of accessing the supplier's systems.
• Other factors specific to the project.

Before starting the traceability activity, it is assumed that the documents being traced (e.g., requirements, design, code, test data, etc.)  have been approved.
When reviewing traceability data, the following tasks may be included, as appropriate for the life cycle phase or the needs of the project:

• Confirm that every software requirement is included.
• Confirm the elements in the traceability data are clearly identifiable and distinguishable from each other.
  • Unique identifiers for each requirement, design element, code element, test procedure or test case.
• Confirm bidirectional traceability is between:
  • Software requirements and higher-level requirements.
  • Design elements and software requirements.
  • Source code and software design.
  • Test procedures and the software requirements they verify (confirm during FCA (Functional Configuration Audit) / PCA (Physical Configuration Audit) audits).
• Confirm there are no "holes" in the traceability data.
  • Indicating missing elements in the software requirements, design, code, tests.
  • Indicating elements with no reason ("parent" or requirement) for being part of the product (scope "creep" or "gold-plating").
• Determine if traceability data is being maintained and kept up to date.
• Assess impact of known changes and issues.
  • Identify affected work products via the links in the traceability data.
• Assess test coverage.
  • Determine if sufficient tests are used for safety-critical or other key functionality.
• Plan testing strategy:
  • Identify where requirements are implemented in the design.
  • Requirements implemented in multiple design elements may require high-level testing.
  • Requirements implemented in a single design element or code module may be tested at a lower level.
  • Determine order of testing, especially when time is short.
• Determine maintenance tasks.
  • Areas affected by a change are identified in the traceability data.
• Determine who to notify when a change occurs (owner/author of traced work products).

See 7.03 - Acquisition Guidance in this Handbook for guidance on acquisition activities which include considerations and requirements for solicitations and contracts as well as monitoring activities such as access to and review of project records.

Guidance related to bidirectional traceability, including what suppliers include in their software traceability data, may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

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 lessons learned related to traceability data:

Orbital Space Plane - Technical Rigor & Integrity. Lesson Number 1504: A documented lesson from the NASA Lessons Learned database notes that 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 ((Software Requirements Review (SRR), Software Design Review (SDR)) review process ⁵⁶⁰.

Software Requirements Management. Lesson Number 3377: A second lesson from the NASA Lessons Learned database notes that the "ability to manage and trace software requirements is critical to achieve success in any software project and to produce software products in a cost-effective and timely fashion... Manual methods for management of software requirements are ineffective and inefficient, contributing to excessive costs as well as schedule delays. Aspects of the management of software requirements include the elicitation/specification, analysis, development, tracking, and changing of software requirements used during the implementation and sustaining phases of the software life cycle. Management and traceability of software requirements are critical to the success of producing reliable, high-quality, and safe software products that meet end-users requirements and needs in a cost-effective and timely fashion." ⁵⁷⁶