1. Requirements

3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: 

1.1 Notes

The project manager will maintain bi-directional traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Bidirectional traceability matrices help ensure that all the required software requirements (only what is required is developed) are addressed in software design and tested in the software testing activities. Bidirectional traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

3. Guidance

3.1 Bidirectional Traceability

Bidirectional traceability is defined as an “association among two or more logical entities that are discernible in either direction (to and from an entity)” (ISO/IEC/IEEE 24765:2010 Systems and software engineering—Vocabulary ²³⁰).

Software requirements come from various sources, including system requirements specifications, safety standards, security standards, hazard and risk analyses, system constraints, customer input, software safety "best practices," etc. ²⁷⁶ Bidirectional traceability matrices help ensure that all the requirements included in the 5.09 - SRS - Software Requirements Specification  trace back to a higher-level requirement that is the source or reason for having that requirement in the SRS. Bidirectional traceability also helps ensure that all requirements are addressed and that only what is required is developed. Bidirectional traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

Bidirectional traceability is a traceability chain that can be traced in both the forward and backward directions, as illustrated below (Bidirectional Requirements Traceability, Westfall, 2006 ³⁵⁶). It is important because it can point out software design elements that are not fulfilled in the code (i.e., missing or incomplete functionality) and 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. Still, 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.

See also SWE-050 - Software Requirements, SWE-051 - Software Requirements Analysis, SWE-200 - Software Requirements Volatility Metrics

Figure 2 illustrates possible sources of higher-level requirements that are to be traced to the software requirements.

Figure 3 shows Bidirectional traceability is defined as a traceability chain that can be traced in both the forward and backward directions.

Figure 3

Using a matrix such as the one shown below (Bidirectional Requirements Traceability, Westfall, 2006 ³⁵⁶) allows a single exercise to show traceability both forwards and backward. 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 an 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 additional areas where problems could occur with the software.

3.2 Tracing Software Requirements To Higher-level Requirements

This requirement, SWE-052, is specific to tracing software requirements to higher-level requirements.  Software requirements come from different sources and can also be derived if needed.  Sources of requirements include, but are not limited, to the following items:

• Hardware specifications.
• Computer\processor\programmable logic device specifications.
• Hardware interfaces.
• Operating system requirements and board support package requirements.
• Data\File definitions and interfaces.
• Communication interfaces, including bus communication and fault interfaces.
• Software interfaces.
• Derived from domain analyses.
• Fault detection, isolation, and recovery actions and requirements.
• Models.
• Commercial software interfaces and functional requirements.
• Software security requirements.
• User interface requirements.
• Algorithms.
• Legacy or reuse software requirements.
• Derived from operational analyses.
• Prototyping activities.
• Interviews.
• Surveys.
• Questionnaires.
• Brainstorming.
• Observation.
• Software test requirements.
• Software fault management requirements.
• Hazard analyses.
• COTS, GOTS, MOTS, OSS, or reused software components.

Per the NASA Software Safety Guidebook ²⁷⁶ , the key benefits of tracing requirements include the following:

• 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 cannot be traced to a user requirement.
• Improved understanding of the impact of changing requirements.

3.3 Bidirectional Traceability Matrix

When creating a bidirectional traceability matrix, consider the following actions:

• Create a matrix at the beginning of the project. ¹⁴⁷
• Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage. ¹⁴⁷
• 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 required 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. ¹⁴²
• 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. ²³³
• Justify 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 computer software configuration items (CSCI) 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.
• Has the matrix been reviewed at major phases/key reviews of the project? 

3.4 Software Design

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 ²⁷⁶)

Traceability is important because it can point out software design elements that are not fulfilled in the code (i.e., missing or incomplete functionality) and 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. Still, 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.

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 project's scope (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, a collaboration between the different groups may be needed to ensure proper understanding and proper traceability documentation.

According to “Software Development Life Cycles: Outline for Developing a Traceability Matrix,” an article from The Regulatory Forum ¹²⁷, 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 the design back to hazard analysis if the design introduces hazards.

See also SWE-058 - Detailed Design,  SWE-053 - Manage Requirements Changes,  Topic 5.13 - SwDD - Software Design Description, 

3.5 Software Test Procedures

Software test procedures are created to verify the software requirements for a project. To ensure that all requirements are verified via the test procedure set, the requirements need to be linked to the test procedures which verify them.

Traceability matrices help ensure that test procedures verify one or more software requirements by mapping those procedures back to one or more software requirements. Traceability is also used to ensure that the necessary level of test coverage is achieved, i.e., that there are sufficient tests to verify the requirements have been correctly implemented in the software.

Traceability links between individual requirements and other system elements, including but not limited to test procedures, 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  ²⁷⁶.)

Traceability is important because it can point out software requirements that are not tested (i.e., missing tests) and tests that do not serve to test requirements (i.e., extra tests).

Keep in mind that a single requirement could trace to multiple test procedures. The reverse is also true. Test procedures could trace back to multiple requirements, so the relationships identified in the matrix are not required to be one-to-one. The matrix needs to contain no missing relationships, i.e., empty cells in the matrix. Those indicate a problem with the set of test procedures that need to be designed such that every requirement is verified.

New requirements may be generated during design and implementation.  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 needs to be revised to include the new requirements and the mapped design elements, implementation (source code), and test procedures.

To ensure full traceability between requirements and tests, it is important to trace test cases, test scripts, test data, and other supporting test information not already found in the test procedures to the relevant test procedures.  This level of trace information may or may not appear in a traceability matrix.  The test procedures, test cases, test scripts, and test data can include the proper links and references to ensure full traceability among all the elements of the tests.

Key aspects of tracing test procedures include:

• Ensure that tests for safety-critical functions are identified either through the traceability matrix or through test procedure documentation.

• Trace each requirement and functional specification to one or more test cases (Manager's Handbook for Software Development ⁰³¹). If not already done, trace unit tests to source code and design specifications.
• Trace integration tests to high-level design specifications.
• Trace system tests to software requirement specifications (SRS). ¹²⁷

A project must define processes that trace requirements to validation and verification, test procedures, and evidence, in accordance with this requirement. This traceability enables the project to demonstrate that its validation and verification of each requirement is sufficient. A Project should connect the computing system requirements to the analytical and test evidence that demonstrates their implementation in a manner suited to its development process. The connections should be verifiable and human-readable, and the connections for safety requirements should be included in the application materials. NASA does not prescribe the technical methods for making these traceability connections but will evaluate the selected method for possibilities of error.

See also SWE-066 - Perform Testing, SWE-071 - Update Test Plans and Procedures, 

3.6 Software requirements to the system hazards

Bi-directional traceability with hazard analyses that include software allows a project to develop and maintain a list of all software safety-critical components that have been identified by the system hazard analysis.  The bi-directional traceability with the hazard analyses allows the engineers and safety personnel to see which software components are software safety-critical components and allows the project to ensure that the software safety-critical requirements are implied to those software components that trace to hazard analyses. See also Topic 8.58 - Software Safety and Hazard Analysis, 

The key to determining if the software is safety-critical software is the hazard analysis process.

Hazard Analysis must consider the software’s potential to cause or control a given hazard. It is a best practice to integrate the software within the system hazard analysis whenever possible. The general hazard analysis must consider software common-mode failures that can occur in redundant flight computers running the same software.

Software Safety Analysis supplements the system hazard analysis by assessing the software performing critical functions serving as a hazard cause or control. The review assures compliance with the levied functional software requirements, including SWE-134 - Safety-Critical Software Design Requirements, the software doesn’t violate the independence of hazard inhibits, and the software doesn’t violate the independence of hardware redundancy. The Software Safety Analysis should follow the phased hazard analysis process. A typical Software Safety Analysis process begins by identifying the must-work and must not work functions in Phase 1 hazard reports. The system hazard analysis and software safety analysis process should assess each function, between Phase 1 and 2 hazard analysis, for compliance with the levied functional software requirements, including SWE-134. For example, Solar Array deployment (must work function) software should place deployment effectors in the powered-off state when it boots up and requires initializing and executing commands in the correct order within 4 CPU cycles before removing a deployment inhibit. The analysis also assesses the channelization of the communication paths between the inputs/sensors and the effectors to ensure no violation of fault tolerance by routing a redundant communication path through a single component. The system hazard analysis and software safety analysis also assures the redundancy management performed by the software supports fault tolerance requirements. For example, software can’t trigger a critical sequence in a single fault-tolerant manner using single sensor input. Considering how software can trigger a critical sequence is true for triggering events such as payload separation, tripping FDIR responses that turn off critical subsystems, failover to redundant components, and providing closed-loop control critical functions such as propellant tank pressurization. See also SWE-192 - Software Hazardous Requirements, 

The project should have bi-directional traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events.

Traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events, allows us to determine which software components are software safety-critical and ensure that the required software safety-critical requirements are included in the software requirements and software activities.

Bidirectional traceability is a traceability chain that can be traced in both the forward and backward directions, as illustrated below (Bidirectional Requirements Traceability, Westfall, 2006 ³⁵⁶). It is important because it can point out software design elements that are not fulfilled in the code (i.e., missing or incomplete functionality) and 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. Still, 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.7 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.8 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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 Microsoft® Excel), a simple database (such as Microsoft® Access)  or a textual document. The project must be diligent about keeping such traces up to date. 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 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. ²³⁷

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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."  

• Software Requirements Management. Lesson Number 3377 ⁵⁷⁶: "The ability to manage and trace software requirements is critical to achieving success in any software project and producing 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-user requirements and needs in a cost-effective and timely fashion.
  • "Cost and schedule impacts that result from incomplete, incorrect, or changing software requirements increase the later they occur in the software life cycle.
  • "Current software technology, processes, and tools provide innovative automated methods to facilitate optimum management of software requirements (e.g., IBM Rational DOORS, IBM Rational RequisitePro, Cradle requirements management software).
  • "Additionally, a collaborative relationship between the customer using the software and the developer providing the software is paramount to the success of the software project. More specifically, the users/customers must effectively define and accurately communicate their requirements to the developer. For example, the user's defined requirements should be stated and unambiguous, concise, complete, autonomous, able to be implemented, and testable."

6.2 Other Lessons Learned

Interface Control Documents (ICDs)

• ICDs must document data behaviors for critical parameters.
• Include human factor considerations in ICD documentation (e.g., capturing notes that identify inconsistencies or other potential pitfalls).
• It is essential to have unambiguous traceability between ICD parameters and downstream software artifacts such as requirements, code, tests, and models.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Products

• Analysis of bi-directional requirements traceability and hazard analysis traceability, including corrective actions.

  
  

  Objective Evidence

  • Bi-directional traceability results, including traceability to any hazard that includes software.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• # of Software Requirements (e.g., Project, Application, Subsystem, System, etc.)
• # of software requirements with completed test procedures/cases over time
• % of traceability completed in each area: System-Level requirements to Software requirements; Software Requirements to Design; Design to Code; Software Requirements to Test Procedures
• % of traceability completed for all hazards to software requirements and test procedures
• Defect trends for trace quality (# of circular traces, orphans, widows, etc.)
• # of safety-related requirement issues (Open, Closed) over time
• # of safety-related non-conformances identified by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Confirm that bi-directional traceability has been completed, recorded, and maintained for the software elements in NPR 7150.2D - Table 1 in section 3.12.1 appropriate to software classification. Review the software results of their bi-directional traceability (usually performed in a tool) and check that all the traces have been listed below have been done, using the software classification to determine which traces are required. If there are issues found in the initial trace matrices, track to see that these are addressed. When changes are made to the system, confirm that any corresponding changes to the traceability have been documented.

3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: 

Confirm that the bi-directional software traceability includes traceability to the hazard analysis

The project should have bi-directional traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events.

Traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events, allows us to determine which software components are software safety-critical and ensure that the required software is safety-critical requirements are included in the software requirements and software activities.

7.4.1 Software Safety Requirements

Software safety requirements contained in NASA-STD-8739.8 ²⁷⁸

The software safety requirements contained in NASA-STD-8739.8 for safety-critical software are:

1. Confirm that the identified safety-critical software components have implemented the safety-critical software assurance requirements listed in this standard.

2. Analyze the software design to ensure that partitioning or isolation methods are used to logically isolate the safety-critical design elements from those that are non-safety-critical.

3. Analyze the design and work with the project to implement NPR 7150.2 SWE-134 - Safety-Critical Software Design Requirements requirement items "a" through "l."

4. Assess that the source code satisfies the conditions in the NPR 7150.2 SWE-134 - Safety-Critical Software Design Requirements requirement "a" through "l" for safety-critical software at each code inspection, test review, safety review, and project review milestone.

5. Confirm 100% code test coverage has been achieved or addressed for all identified software safety-critical components or provide a risk assessment explaining why the test coverage is not possible for the safety-critical code component.

6. Assess each safety-critical software component to determine the software component’s cyclomatic complexity value.

7. Confirm that all identified software safety-critical components have a cyclomatic complexity value of 10 or lower. If not, provide a risk assessment showing why the cyclomatic complexity value needs to be higher than ten and why the software component cannot be structured to be lower than 10.  

Figure 3 shows bidirectional traceability as a traceability chain that can be traced in both the forward and backward directions.

Figure 3

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: