Requirements Traceability Matrix (RTM) for Systems Engineers

 Oct 20, 2022 Libor Buš tips share

Maintaining requirements traceability could be time-consuming and error-prone. Learn how to create a requirements traceability matrix and use it effectively.

Role of Requirements Traceability in Development of HW/SW Products

Requirements traceability represents relationships between requirements and project artifacts maintained through the whole development process. For instance, derived requirements are related to their source requirements, or tests cases are linked to the requirements they verify. With a proper approach and toolset, you can successfully master complex product development, improve product quality and ensure compliance with industry standards.

Deal With Complexity

Products combining hardware and software are typically too complex to be described by MS Word documents, Excel spreadsheets or ticket tracking systems. These products are developed using the traditional V-model process to deal with their complexity. With this approach, you can iteratively capture abstract business and user needs and decompose them into a more detailed high-level solution. Finally, you can describe low-level design with all the necessary details for product development. However, you need to trace related requirements in both directions.

Improve Product Quality

Detailed and consistent requirements traceability increases product quality. You can simply track project progress and demonstrate which requirements were fully implemented and verified, or you can analyze the impact of requirement changes to estimate related costs and risks.

Comply With Industry Standards

Requirements traceability is the key to compliance with industry standards for functional safety:

• IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
• ISO 26262: Road Vehicles – Functional Safety
• IEC 62304: Medical Device Software — Software Life Cycle Processes
• DO 178C: Software Considerations in Airborne Systems and Equipment Certification
• EN 50128: Railway Applications — Communication, Signaling and Processing Systems — Software for Railway Control and Protection Systems

Requirements Organization for HW/SW Products

Let’s see how to organize requirements to better understand the value of requirements traceability.

Standard ISO/IEC/IEEE 29148

The international standard ISO/IEC/IEEE 29148 — Systems and software engineering — Life cycle processes — Requirements engineering describes how to capture requirements using different requirements specifications:

• Business Requirements Specification (BRS)
• Stakeholder Requirements Specification (StRS)
• System Requirements Specification (SyRS)
• Software Requirements Specification (SRS)

Requirements Traceability in V-Model

We’ve learned in the previous section that we need to manage traceability between requirements and other project artifacts in the V-model. For that, you can use several types of traceability links:

• Satisfaction links: lead from detailed requirements to more abstract source requirements
• Verification & Validation links: lead from verification & validation test cases to requirements
• Mitigation links: lead from requirements to mitigated risks

Traceability links are directional, and there is a convention to create them from bottom to top in the V-model. It means that derived (detailed) requirements are linked to their source (abstract) requirements. However, you must follow relations between requirements in both directions to analyze requirements traceability effectively. For instance, follow satisfaction links from top to bottom to explore how the product solves a specific user need. On the other hand, follow satisfaction links from bottom to top to understand what the source user needs are for a selected low-level design requirement.

Example V-Model for Safety-Critical Products

The V-model for safety-critical products usually has 3 levels of abstraction:

• Stakeholder Requirements: Capture user needs for the developed product and describe how they are validated by tests.
• Safety Risks: Identify potential failures, their causes, and effects using Failure Modes and Effects Analysis (FMEA) method. If the risk level for a potential failure is too high, propose corrective actions mitigating the risk.
• System Requirements: From stakeholder requirements and safety risks derive system requirements providing a high-level solution of user needs. Describe how system requirements are verified by system-level tests.
• SW or HW Requirements: Decompose the system to independent HW/SW subsystems. For each subsystem derive its detailed low-level requirements from system requirements. Describe how HW/SW requirements are verified by integration tests.

Coverage and Impact Analysis

We now understand how to organize requirements and link them together. What are the benefits of this? Let’s explain how it enables requirements coverage and impact analysis.

Requirements Coverage Analysis

Identify which high-level requirements are not covered by a derived lower-level requirement. These requirements are apparently not implemented, and the product does not meet user needs.

Tests Coverage Analysis

Demonstrate that all requirements were verified by test cases. We cannot prove that the product works as expected if some requirements are not verified. Moreover, test cases can clarify requirements and identify duplicate or even wrong requirements. Analyze test coverage from early product development stages. It can reveal requirements issues and save costs of implementing unwanted functionality.

Impact Analysis

Reveal the impact of any proposed stakeholder requirements change. Estimate the related costs to make an informed decision on whether to approve or reject the change.

Gold Plating Analysis

Identify low-level requirements which do not satisfy any high-level requirement. Their implementation will lead to wasting of project resources if they are not requested by any customer.

Requirements Traceability Matrix (RTM)

A requirements traceability matrix is a simple tool documenting relationships between requirements and related project artifacts. It is usually displayed as a table with requirements listed in rows and linked artifacts in columns.

Create Traceability Matrix in Excel

You can create an RTM as an Excel table representing low-level SW requirements as rows and test cases as columns. Then, gather all requirements and test cases in the table. Finally, if a test case verifies a requirement, put a cross character (“X”) in the corresponding table cell as shown on the left part of the image above.

You can also include short requirement and test case descriptions in the traceability matrix to improve its information value. Another possibility is to replace each cross character with the corresponding test case status (passed or failed). This allows computing the status of each requirement from all test statuses in its row.

Working with RTMs in Excel is only feasible for small projects. However, it is quite challenging for medium and large projects with hundreds or even thousands of requirements. You must deal with these problems:

• Manual maintenance: Maintaining RTM in Excel is time-consuming and error-prone. You need to manually update its rows and columns according to two different source documents – a requirements specification and a test plan.
• Poor usability: Working with large RTMs is cumbersome. Just imagine scrolling over an RTM with more than 100 rows and columns to find out if a requirement is verified by any test.
• View 2 documents only: Traceability analysis across multiple levels is difficult. You need to jump between multiple traceability matrices when tracing coverage from high-level requirements (user needs) via detailed software requirements down to design elements.

Generate Traceability Matrix in Requirements Management Tools

You really do not need to waste your time and effort with manual maintenance of RTM in Excel! There are advanced requirements management tools, such as IBM Rational DOORS and DOORS Next Generation (DNG), Polarion, Visure, or ReqView, in which you can use RTM very conveniently, even for thousands of requirements.

Requirements management tools offer several powerful RTM features not available in Excel:

• Real-time view: Update RTM automatically when requirements traceability changes.
• Custom layout: Configure RTM to display additional information about linked project artifacts, for instance, all test cases verifying a requirement with their last execution status.
• Multi-level traceability: Display project artifacts linked across several levels in a single view, for instance, system and SW requirements derived from a stakeholder requirement.
• Export to Word or Excel: Generate RTM from a requirements baseline to be reviewed offline.

How to Use Requirements Traceability Matrix in ReqView

ReqView is a requirements management tool for HW/SW products that stands out for its powerful requirements end-to-end traceability in the V-model.

Let’s demonstrate ReqView on an Example Project storing user needs (NEEDS), SW requirements (SRS), test cases (TESTS), information security risks (RISKS), and design elements (ARCH).

Manage Requirements Traceability

The video below shows how you can manage and browse requirements traceability easily in ReqView.

First link requirements with just a few clicks. Then display linked requirements in the Links pane conveniently. Finally, browse requirements traceability by clicking on links similarly as you browse the Internet.

You can edit and delete links if needed, and you can configure project traceability to define types of links supporting your workflow.

Let’s see how you can review the requirements traceability matrix in ReqView.

Review Requirements Traceability

The video below demonstrates how you can customize RTM views for your V-model to review end-to-end requirements traceability in ReqView.

First, configure a dynamic RTM view showing the whole context of SW requirements (SRS) in your software development life-cycle. Create a custom traceability column displaying upstream requirements (NEEDS) linked by satisfaction links. Set its name to “Satisfies” and place it on the left of the requirement description. Then create another traceability column “Is Verified By” displaying test cases (TESTS) linked by verification links and place it on the right of the requirement description. You can generate both traceability columns using the traceability wizard in just a few clicks.

Then, export a static RTM snapshot to HTML, MS Word, PDF, Excel, or CSV and share it with your team. You can customize traceability reports using export templates to fit your specific layout and styling needs.

Example: Create an RTM view displaying SW requirements (SRS) with the related user needs (NEEDS), test cases (TESTS) and design elements (ARCH). Export an RTM snapshot to Excel for offline reviewers.

Dynamic RTM view in ReqView

Static RTM report exported to Excel

Let’s see how to analyze requirements coverage and the impact of changes using an RTM in ReqView.

Inspect Requirements Coverage Using Traceability Matrix

You can analyze the impact of changes for selected high-level requirements conveniently. Use RTM views with custom template columns displaying requirements coverage.

Template columns are defined using Handlebars templates to output HTML snippets displayed in RTM views. You can use predefined export helper functions in your templates to iterate traceability links and evaluate specific conditions, for instance, to display a warning about missing satisfaction or verification links.

Example: Create an RTM view with Downstream Traceability column displaying coverage of top-level user needs (NEEDS) by downstream SW requirements (SRS) and their test cases (TESTS). Output a warning for user needs not covered by satisfaction or verification traceability links. More info 

Filter Traceability Matrix

You may need to detect missing or unverified functionality represented by gaps in requirements coverage. To identify gaps in traceability you can simply scroll an RTM view or exported traceability reports and look for empty cells or warnings. However, this approach is not convenient for large documents.

You can display requirements with missing links using the filter links feature. To filter links, you need to capture a requirement type (User Story, Functional Requirement, Constraint, etc.) in a custom enumeration attribute and consistently link requirements and other project artifacts using link types.

Example: To display user stories (NEEDS) without any satisfaction link from SW requirements (SRS), focus the Filter field above the RTM view and enter  Type: User Story and  NOT Is satisfied by conditions. More info 

Export Requirements Traceability Reports

You can export traceability reports if you need to review requirements traceability offline. Similarly to template columns, traceability reports are defined using Handlebars templates to output text files (HTML, XML, CSV, JSON). You can iterate traceability links and evaluate custom conditions using template helpers. The advantage of traceability reports is that they have more powerful layout and styling options than traceability columns. For instance, you can use external JS, CSS or icon libraries in HTML templates.

Example: Create an RTM report displaying coverage of top-level user needs (NEEDS) by downstream SW requirements (SRS) and their test cases (TESTS). Display the status of SW requirements and tests to understand the development status. Output a warning for user needs not covered by satisfaction or verification traceability links. More info 

If you need a little help with your specific traceability reports, contact us. We offer custom services and will be happy to tailor complex custom reports according to your specific needs.

Query and Visualize Requirements Traceability Graphs

You can extend ReqView with powerful free tools based on Neo4j graph database to solve more advanced usecases:

• Query traceability: Explore traceability graphs using intuitive Cypher graph query language, e.g., list all user stories impacted by a change in a selected SW module.

• Validate traceability consistency: Detect anomalies of requirements traceability and display them in a report, e.g., list all satisfaction links with the wrong direction or leading between wrong documents.

• Visualize traceability graphs: Select a part of requirements traceability and display it graphically, e.g., make a figure visualizing requirements coverage by a tree view and include it in your Powerpoint presentation.

  

For more information, see How to Analyze Requirements Traceability in Neo4j Graph Database.

Conclusion

We explained the key benefits of managing requirements traceability during the development of HW/SW products:

• Deal with product complexity
• Ensure that requirements are fulfilled and verified
• Make the right decisions during the development
• Comply with standards

Then, we introduced the requirements traceability matrix (RTM) as a powerful tool for exploring requirements traceability. We also discussed why maintenance of RTM in Excel is not feasible for complex HW/SW products.

Finally, we demonstrated how ReqView solves these challenges and helps you in managing requirements traceability effectively.

Learn More

• ReqView Blog: Manage Requirements Better Than in Excel
• ReqView Blog: How to Analyze Requirements Traceability in Neo4j Graph Database
• ReqView Documentation: Requirements Traceability Links — learn how to manage requirements traceability links
• ReqView Documentation: Custom Export using Templates — learn how to customize traceability reports
• Contact us — we’ll be happy to answer your questions

Try ReqView