bannerb

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

SWE-059 - Bidirectional Traceability Between Software Requirements and Software Design

1. Requirements

4.3.4 The project manager shall perform, record, and maintain bidirectional traceability between the following:

a. Software requirements and software architecture.

b. Software architecture and software design.

c. Software requirements and software design.

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.

Classes F and G are labeled with "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

Traceability matrices help ensure that each design element, typically documented in a Software Design Description (SDD), traces back to a software requirement that is the source or reason for having that element in the design. Traceability also helps ensure that all requirements are addressed in the design and that only what is required is designed. 

3. Guidance

Software design is created based on the software requirements.  Some assurance is needed to show that the design fulfills the software requirements and that no requirements are lost or left out of the design. One method of providing this "check and balance" is to create a traceability matrix between the software requirements and the resulting design.

Traceability links between individual requirements and other system elements, including, but not limited to design, 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 )

Bidirectional traceability is defined as an “association among two or more logical entities that is discernable in either direction (to and from an entity)” (ISO/IEC 24765:2009 Systems and software engineering vocabulary  230). 

Traceability 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 design elements that have no source requirement, but if such "orphan" design 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 requirements are added to the project.

Bidirectional traceability is a traceability chain that can be traced in both the forward and backward directions.  Figure 1 illustrates how software design is 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 ( 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 UTS Case # and looking at the data in the columns to the left shows the backward traceability from a test case to its parent test specification all the way back to the parent requirement.

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 to which they apply, such as the SDD, 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 for design elements, 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 should be tracked/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.

A bidirectional traceability matrix can be manually created and maintained, or may be a by-product of a requirements management tool. The tracing system needs to be chosen based on project complexity and the number of requirements. Check with project management to see if a requirements management tool exists for the local project that is capable of producing a bidirectional traceability matrix.

Keep in mind that a single requirement could trace to multiple architectural elements, design elements, etc. The reverse is also true, design elements could trace back to multiple source requirements, so the relationships identified in the matrix are not required to be one-to-one.

As decisions are made during the development of the software design, the team may generate new requirements. When that happens and the requirements are confirmed as being within the scope of the project (not expanding the scope or “gold plating” the system by including unnecessary functionality), the traceability matrix is revised to include the new requirements and the mapped design elements.  Keep in mind that the requirements document(s) will also need to be revised when this occurs.

If the software design team is not the same as the requirements development team, collaboration may be needed to ensure proper bidirectional traceability between design and requirements.  Likewise, when tracing detailed design to high-level design, collaboration between the different groups may be needed to ensure proper understanding and proper documentation of traceability.

According to “Software Development Life Cycles: Outline for Developing a Traceability Matrix”, an article from The Regulatory Forum 127, key aspects of tracing design elements include:

  • Trace high level design specifications to software requirements.
  • Trace detailed design specifications to high level design.
  • Trace design interfaces to hardware, user, operator, and software interface requirements.
  • Trace design back to hazard analysis, if the design introduces hazards.

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

Value-based requirement tracing may be an option for projects with small budgets or projects where a specific set of requirements has priority such as Class C, Safety Critical projects where safety-critical requirements obviously have 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. This type of requirement tracing would also be useful for Class F and Class G projects where the software is not Off the Shelf (OTS).

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

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

A documented lesson from the NASA Lessons Learned database notes the following:

Software Requirements Management. Lesson Number 3377: This lesson notes the benefits of using "state-of-the-art software processes and tools to manage requirements for software development." 576

  • No labels