bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

Error formatting macro: alias: java.lang.NullPointerException
SWE-047 - Traceability Data
Unknown macro: {div3}

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">1.1 Notes

NPR 7150.2 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.

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

    X

   

    X

   

    X

   

   

    P(C)

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

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.

Unknown macro: {div3}

3. Guidance

Include requirements for suppliers to provide electronic access to traceability data as part of the solicitation (e.g.,

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

RFP

]]></ac:plain-text-body>
</ac:macro>

) 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

      <ac:macro ac:name="unmigrated-wiki-markup">
      <ac:plain-text-body><![CDATA[

      FCA

      ]]></ac:plain-text-body>
      </ac:macro>

      /

      <ac:macro ac:name="unmigrated-wiki-markup">
      <ac:plain-text-body><![CDATA[

      PCA

      ]]></ac:plain-text-body>
      </ac:macro>

      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
  • 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]

Bidirectional Traceability (software requirements to higher level requirements)

[SWE-059]

Bidirectional Traceability (software requirements to software design)

[SWE-064]

Bidirectional Traceability (software design to software code)

[SWE-072]

Bidirectional Traceability (test procedures to software requirements)

Unknown macro: {div3}

4. Small Projects

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

Unknown macro: {div3}

5. Resources

  1. NASA Assurance Process for Complex Electronics, Traceability Analysis, 2009. Accessed June 2011.
  2. Compuware Corporation, Requirements traceability for quality management, 2004.  Accessed October 2011.

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.

Unknown macro: {div3}

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to traceability data:

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 (SRR, SDR) review process. (http://www.nasa.gov/offices/oce/llis/1504.html)

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. "(http://www.nasa.gov/offices/oce/llis/imported_content/lesson_3377.html)

  • No labels