bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-064 - Bidirectional Traceability Between Software Design and Software Code

1. Requirements

4.4.7 The project manager shall perform, record, and maintain bidirectional traceability from software design to the software code.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

If Class D software is safety critical, this requirement applies to the safety-critical aspects of the software.

Class F and Class G are labeled "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

2. Rationale

Bidirectional traceability matrices help ensure that all of the software features and components contained in the software design are included in the software code. Bidirectional traceability also helps ensure that only what is required is developed. Bidirectional traceability matrices also make it less likely that requirements and design are misinterpreted as they are refined.

3. Guidance

Code (software) is based on a software design which is based on a set of software requirements. Some measure of assurance is needed to show that the created code fulfills the design upon which it is based without leaving out any design elements or adding any new functionality not present in the design.

Tracing elements of the code such as functions, subsystems, modules, Computer Software Configuration Items (CSCI), etc. to design elements helps provide the basis of this assurance.

Traceability matrices help ensure that each design element, typically documented in a Software Design Document (SDD), is implemented in the resulting software, giving a reason for the code implementation through the design back to the software requirements.

Traceability links between individual requirements and other system elements, including, but not limited to, source code, are helpful tools when evaluating the impact of changing or deleting a requirement. When a requirement is changed, traceability can help identify the affected products, including design, documentation, source code, tests, etc. (NASA-GB-8719.13, NASA Software Safety Guidebook 276 ).

Tracing source code to design elements also provides the ability to demonstrate traceability of safety-critical software functions and safety-critical software controls to detailed design specifications.

Bidirectional traceability is defined as a traceability chain that can be traced in both the forward and backward directions as illustrated below (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 source code elements that have no source design element, but if such "orphan" source code 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 design elements and source requirements are added to the project.


Bidirectional traceability is a traceability chain that can be traced in both the forward and backward directions.  Figure 2 illustrates how software design and software code are traced between software products.

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

While traceability matrices are not the only method for capturing bidirectional traceability, they are the most common.  Traceability matrices can be included in the documents, such as the Software Requirements Specification (SRS), to which they apply or they can be combined into a single matrix covering higher level requirements, software requirements, design, code, and verification.  General guidance for creating a bidirectional traceability matrix includes the following suggested actions:

  • Create the matrix at the beginning of the project.
  • Uniquely identify the elements in the matrix (requirements identifiers, design document identifiers and paragraph numbers, code module identifiers, etc.).
  • 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.
  • 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.

Ensure a review of the matrix at major phases / key reviews of the project.

If the software development team is not the same as the software design team, collaboration may be needed to ensure proper bidirectional traceability between source code and design.  Early collaboration is valuable since a one-to-one subsystem to design package relationship (or as close as possible), makes the traceability activity between design and source code much simpler.

Key aspects of tracing source code include:

  • Clear tracing of safety requirements to the source code that implements them (typically via comments in the code or via the traceability matrix using requirements traced to design to code) (NASA-GB-8719.13, NASA Software Safety Guidebook 276).
  • For traceability purposes, safety-critical code and data is to be commented as such (NASA-STD-8719.13C, NASA Software Safety Standard 271).
  • Trace source code to the detailed design specifications.
  • Map each low level function or data specification to the requirements it fulfills. 047
  • Trace unit tests to source code and to design specifications. 127

NASA-specific bidirectional traceability resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to bidirectional traceability may be found in the following related requirements in this Handbook:

SWE-052

Bidirectional Traceability Between Higher Level Requirements and Software Requirements

SWE-059

Bidirectional Traceability Between Software Requirements and Software Design

SWE-072

Bidirectional Traceability Between Software Test Procedures and Software Requirements

4. Small Projects

For small projects without access to a tracing tool for requirements, design, and code and with budget limitations preventing them from acquiring a new tool and associated training, 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, etc. change.

In some instances, value-based requirements tracing may be a prudent deviation/waiver request against SWE-064 which would provide partial relief from this requirement. However, no matter how small the budget is, traceability of safety-critical requirements all the way through design and code is always a 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." (Why Software Requirements Traceability Remains a Challenge 237, Kannenberg, CrossTalkOnline, July/August 2009). 

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

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

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.

Code to FlowChart

COTS

AthTek

http://www.athtek.com/code-to-flowchart.html ...

Code to FlowChart is an advanced source code to flowchart converter for software engineers and document writers. It can automatically generate flowchart/NS chart from source code, and helps users to understand complex program structures by visual diagrams.

LaRC

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

No Lessons Learned have currently been identified for this requirement.

  • No labels