bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

SWE-052 - Bidirectional Traceability Between Higher Level Requirements and Software Requirements

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.

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

    P(C)

    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

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. 276 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 356).  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 356), 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 276, 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. 147
  • Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage. 147
  • 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. 142
  • 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. 233
  • 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:

SWE-059

Bidirectional Traceability Between Software Requirements and Software Design

SWE-064

Bidirectional Traceability Between Software Design and Software Code

SWE-072

Bidirectional Traceability Between Software Test Procedures and Software Requirements


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. 271
 
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. 237

5. Resources


5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser

Requirements Experts

COTS

Requirements Experts

https://reqexperts.com/resources/tools-templates/ ...

Tools and Templates for Developing Requirements. Others services and training also available.

Requisite Pro

COTS

IBM Rational

https://www.ibm.com/support/knowledgecenter/en/SSSHCT7.1.0/com.ibm.reqpro.help/getstart/cproductover ...

Rational RequisitePro helps project teams to manage their requirements, to write good use cases, to improve traceability, to strengthen collaboration, to reduce project rework, and to increase quality. Version 7.1.0.

KSC

RequirementsLink

COTS

ENSER/Parametric Technology Corporation (PTC)

http://www.ptc.com/appserver/wcms/relnotes/note.jsp?icgdbkey=826imdbkey=119829 ...

Windchill RequirementsLink. Requirements capture and tracking tool. Windchill RequirementsLink - an integral option for Windchill PDMLink - lets you manage product requirements, including change control and associating requirements with specific product structures and design content. With bi-directional traceability between customer needs, market requirements and the underlying technical requirements, you can ensure that customer and market requirements are satisfied by designs, and properly verified during development.

SSC

Requirements traceability tool

SPAN - Accessible to NASA users via SPAN tab in this Handbook. By Request - Non-NASA users, contact User for a copy of this tool.

GSFC

http://software.gsfc.nasa.gov/tools/RequirementsTool080905.xls ...

This tool, an Excel spreadsheet, provides bidirectional traceability between requirements, design, code, and test procedures. For a list of features, see the tools section of the GSFC PAL. Note: You must be on site at Goddard in order to access this file. Search in span for "GSFC_TL_20161114_Req_Trace_Tool"

GSFC

PTC Integrity

COTS

PTC

http://www.ptc.com/application-lifecycle-management/integrity/lifecycle-manager ...

PTC Integrity is a systems and software lifecycle management (SSLM) and application lifecycle management (ALM) platform used for Process automation and workflow management

IV&V, GSFC

GSFC Requirements Matrix Tool

SPAN - Accessible to NASA users via SPAN tab in this Handbook. By Request - Non-NASA users, contact User for a copy of this tool.

GSFC

...

This tool, an Excel spreadsheet, provides bidirectional traceability between requirements, design, code, and test procedures. Available in SPAN on page: GSFC_TL_20161114_Req_Trace_Tool

GSFC

DOORS®

COTS

IBM® Rational®

http://www-01.ibm.com/software/awdtools/doors/ ...

IBM® Rational® DOORS® family is a group of requirements management tools that allow you to capture, trace, analyze and manage changes across the development lifecycle.

ARC, DFRC, GRC, GSFC, IV&V, JPL, JSC, JSC, LaRC, MSFC,

Dimensions® RM

COTS

MicroFocus

https://www.microfocus.com/products/dimensions-rm/ ...

Create and manage requirements more efficiently. Dimensions® RM (formerly Serena® Dimensions RM) increases visibility and collaboration across business and delivery teams. Powerful reporting and tracking provide end-to-end traceability from initial concepts to production delivery.

Caliber®

COTS

Micro Focus

https://www.microfocus.com/products/requirements-management/caliber/ ...

CaliberRM® is a requirements management tool that ensures that applications meet end user needs. Using CaliberRM, analysts, developers, testers and other stakeholders accurately capture and communicate the user's requirements throughout the application lifecycle. Version 11.5.

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." 560