Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}


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

h2. {color:#003366}{*}1.1 Notes{*}{color}

NPR 7150.2 does not include any notes for this requirement.

h2. 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.


h1. 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 lifecycle 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.

h1. 3. Guidance

Include requirements for suppliers to provide electronic access to traceability data as part of the solicitation (e.g., RFP) 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

When reviewing traceability data, the following tasks may be included, as appropriate for the lifecycle 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 included
** Software requirements trace to higher level requirements
** Design elements trace to software requirements
** Source code traces to software design
** Test procedures trace back to the software requirements they verify
* 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
* 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 the [Acquisition Guidance topic|] 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 requirements in this handbook:
| *[SWE-052|SWE-052]* | Bidirectional Traceability (software requirements to higher level   requirements) |
| *[SWE-059|SWE-059]* | Bidirectional Traceability (software requirements to software design) |
| *[SWE-064|SWE-064]* | Bidirectional Traceability (software design to software code) |
| *[SWE-072|SWE-072]* | Bidirectional Traceability (test procedures to software requirements) |

h1. 4. Small Projects

There is no guidance specific to small projects for this requirement at this time.

h1. 5. Resources

# [Traceability Analysis|], NASA Assurance Process for Complex Electronics, 2009
# [Requirements traceability for quality management|], Compuware Corporation, 2004

h2. {toolstable}


h2. 6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes that lifecycle 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. ([|])

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. "([|])