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 Topic 7.3 - 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:
Bidirectional Traceability Between Higher Level Requirements and Software
Bidirectional Traceability Between Software Requirements and Software Design
Bidirectional Traceability Between Software Design and Software Code
Bidirectional Traceability Between Software Test Procedures and Software