1. Requirements

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

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

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 is a traceability chain that can be traced in both the forward and backward directions, as illustrated below (Bidirectional Requirements Traceability, Westfall, 2006

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

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.

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

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

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

• Create a matrix at the beginning of the project.

  Swerefn
  refnum 147

• Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage.

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

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

  Swerefn
  refnum 233

• 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? 

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

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

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

  Swerefn
  refnum 031

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

  Swerefn
  refnum 127

Software requirements to the system hazards

Bi-directional traceability with the 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. 

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 to the levied functional software requirements, including SWE-134, 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 to initialize and execute 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 assure 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.

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.

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

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

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

  Swerefn
  refnum 560

  : 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

  Swerefn
  refnum 576

  : "The ability to manage and trace software requirements is critical to achieving success in any software project and to produce 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

1. Confirm that bi-directional traceability has been completed, recorded, and maintained.
2. Confirm that the software traceability includes traceability to any hazard that includes software. 

7.2 Products

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

  
  

  Note
  title Objective Evidence
  Bi-directional traceability results, including traceability to any hazard that includes software.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

7.3 Metrics

• # of Software Requirements (e.g., Project, Application, Subsystem, System, etc.)
• # of software requirements with completed test procedures 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

7.4 Guidance

Confirm that bi-directional traceability has been completed, recorded, and maintained for the software elements in NPR 7150.2C - 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.

Confirm that the software bi-directional 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.

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 requirement items "a" through "l."

4. Assess that the source code satisfies the conditions in the NPR 7150.2 SWE-134 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