The Essential Guide to Requirements Management and Traceability
How to Create and Use a Requirements Traceability Matrix
You know how essential requirements traceability is for product teams to have a digital thread throughout the development lifecycle. But where do you start? How can you improve a process that isn’t serving your team as it should?
A requirements traceability matrix (RTM) is usually the first choice. It has low barriers to entry, including ease of getting started and virtually no upfront cost. We’ve even created a free requirements traceability matrix template so you can get started today.
Requirements management software tools, such as Jama Connect®, are also an option. This article will explain:
- What is a requirements traceability matrix
- What are the different types of traceability matrices
- How to create a requirements traceability matrix
- When a company would benefit from using requirements management software instead of using a requirements traceability matrix in Excel
What is a Requirements Traceability Matrix?
A requirements traceability matrix (RTM) is a document in which product teams track the relationships between requirements, verification, risks and other artifacts throughout the product development process. The matrix content may include business requirements, system and subsystem requirements, design elements, test cases, defects, as well as pertinent information about these items, e.g., status, depending on the kind of requirements traceability employed. Its purpose is to demonstrate that requirements have been satisfied by showing a direct trace from individual requirements to their implementation and verification
To ensure you have a concrete understanding of the most effective way to implement requirements traceability in your organization, this article will also compare manually managed traceability matrix with those managed by application lifecycle management (ALM) tools. These requirements management tools automatically create trace relationships that develop a digital thread from high level requirements through low level requirements and testing.
The Purpose of Using a Requirements Traceability Matrix
Product teams need to ensure they are building the right thing. To do this they must keep track of requirements data, including the testing that verifies all the requirements are met. In some industries this proof is required for functional safety or regulatory compliance.
Requirements traceability enables multi-disciplinary teams involved in product definition, design, risk evaluation and verification to relate work items from their activities and analyze connects and impact across complex, highly interconnected systems. Additionally, stakeholders and regulators can see that product requirements generated from the business or even regulations and standards are met.
Different Types of RTMs – With Examples
At a high level, there are three types of requirements traceability matrices: forward traceability, backward traceability, and bidirectional traceability. Each type of traceability matrix is created to ensure high-level requirements have been decomposed to appropriate levels of abstraction, lower-level requirements are tied to a higher-level need, and that the verification test cases are in place with their results. The difference is in which direction of events is the user able to view—forward in time, backward in time, or both. The difference in types is significant based on the information the user needs to gather from the matrix: e.g., are all my subsystem requirements tracing to a system need? Have verifications for all my requirements passed? If we change this high-level requirement what are the impacts downstream?
A forward traceability matrix traces from customer, or high-level, needs through to system and subsystem requirements to all corresponding downstream design artifacts and test cases. Following forward traceability enables teams to be informed of changes and the potential impact of those changes at any time throughout development. Additionally, it ensures that each requirement is not only satisfied but verified and validated.
Example: Midway through the development process, a computer company lowers the weight requirement in its new laptop. Teams can use forward traceability to investigate the impact of change on the project. Any related requirements or resulting artifacts can be adjusted accordingly and test cases can be tweaked to ensure full test coverage.
A backward traceability matrix (sometimes called a reverse traceability matrix) begins at verified work products and traces to upstream requirements and the customer needs they fulfill. This trace gives visibility into why specific artifacts were created and how different pieces of a system fit together. Tracing in this way allows testers to find gaps or missing requirements. Additionally, teams can manage scope and avoid scope creep by ensuring lower-level needs directly trace to business, customer and/or regulatory requirements.
Example: Continuing the example above, backward or reverse traceability gives teams producing the laptop the ability to look at the customer need that caused the change in the weight requirement. They may also want to determine if any project requirements are out of scope, which they can therefore eliminate to meet the new weight requirement and still deliver on time.
A bidirectional traceability matrix is the combination of both forward and backward traceability in one place. It is the optimal type of traceability because it gives teams full visibility from customer needs and requirements specifications through building, testing, changes, and defects—and back.
If bidirectional traceability were employed, the computer manufacturing company in the examples above would only need to look in one place for all the information in both the forward and backward traceability matrices.
How to Create a Requirements Traceability Matrix in Excel – Step by Step
Step 1: Decide what type of traceability matrix you need
When creating a requirements traceability matrix, you want to start with the end in mind. What are your goals for the matrix? And what type of traceability matrix do you need to meet that goal? Take another look at the different types of RTMs just discussed for inspiration.
Step 2: Decide what components should be included
Once you know what you want your requirements traceability matrix to do for you, you can determine what content, or work items, should be included. For example, you may want to include these three typical types of items: Requirements, Tests, and Defects. You’ll likely want to include the following information in your requirements traceability matrix:
High-level Requirements
- Customer needs
- Business requirements
- Requirement ID (for each)
System and Lower-level Requirements
- System Requirements (trace to High-level requirements)
- Hardware, software requirements (trace to System)
- Requirement ID (for each)
Verification
- Test Case (trace to requirements)
- Test case ID
- Verification Result (e.g., Pass/Fail)
Defects
- Defect description (trace to verification)
- Defect ID
You may want to include other work items in your RTM, such as:
- System architecture
- Subsystem design elements
- Risk analysis
- Functional safety goals
- User needs
Additionally, you may want to include pertinent information, other than a unique ID, about each of the work items included in the traceability matrix. For example, it may be helpful to include their status or a short description.
Step 3: Build a traceability matrix in Excel
Now that you know the type of matrix, you’ll employ to meet your goal, it’s time to start building your spreadsheet with your chosen elements. These should be inputted as column headings.
Requirements traceability matrix spreadsheets can be templatized, like the downloadable traceability matrix template we’ve created, to get you started quickly. You can tweak the columns to be sure you capture the information you need and meet your defined goals.
Step 4: Gather and input the data
To get the right information in your traceability matrix, you’ll need to gather data from a variety of sources — the business requirement document (BRD), functional or technical requirement documents, and the test case document.
Once you have collected the information you need, start by adding each high-level requirement (e.g., customer needs) and their related system and lower-level requirements. . Then assign each requirement a unique requirement ID. From there you can add as much detail as you need to based on the columns you opted to use.
Step 5: Get to work
You can begin work as soon as you have all the necessary data input into your requirements traceability matrix. That work includes the steadfast upkeep of the RTM.
As the product development activities continue, you will find that requirements, tests, defects, etc. will be added, obsoleted or changed. While it is obvious that the documents that house this information must be updated (e.g., the system requirements document or verification protocols) to reflect these changes, it is important to also assess the RTM and update accordingly. This may involve adding new item and/or updating relationships between items. Without diligent maintenance, you will be unable to realize any benefits of requirements traceability. For example, you’ll lose any enhanced visibility you were hoping to achieve, and there’s little chance of increasing efficiency or improving change impact analysis. It is especially risky to use an outdated RTM in the analysis of coverage or for determining change impact. As significant as the traceability matrix is to the quality and safety of a product, decision-making and analysis supported by a neglected matrix can lead to decreased quality and impact schedules.
Risks of Using Spreadsheets for Requirements Traceability When Working with Complex Products in Regulated Industries
Medical devices, automobiles, or aerospace developers, for example, must prove they are developing safe products that meet all the necessary standards and regulations.
For complex products and industries that require regulatory or functional safety compliance, managing requirements traceability in documents is a rigorous and precarious route. When relying upon static documents like RTMs, you encounter a variety of risks:
- Inefficiency. Manual data input slows teams down and takes team members away from performing central job functions. Furthermore, with the complex products being built, there would need to be many more columns and hundreds or thousands of rows of data. It would be near impossible to keep everything up to date while maintaining version control, giving access to the right stakeholders, and still being able to glean insights on relationships.
- User error. A requirements traceability matrix is prone to user error as it is updated manually by the team throughout the development lifecycle. Often, information is compiled from a variety of sources such as emails or other spreadsheets, which may have outdated or wrong information themselves.
- User fatigue. RTM maintenance is usually seen as busy work. This means data entry might be put off until after other work is complete. This negates the in-production value of requirements traceability. In addition, you run the risk of missing important compliance-related information should you be unable to track down all the disparate emails and documents in which the records live.
A requirements management tool, such as Jama Connect, can streamline requirements traceability matrices because it records bidirectional traceability for you as work is performed. It also simplifies the validation and verification process.
The Advantages of Using Requirements Management Software for Traceability
Most requirements management tools can support traceability. Jama Connect, however, replaces static traceability matrices by creating dynamic views of trace relationships we call – Live Traces. Jama Connect’s Live Traceability™ view can display the digital thread of requirements relationships and also provides a real time analysis and editing experience.
With Jama Connect, teams can reap all the benefits of requirements traceability automatically. Benefits include enhancing process visibility, improving impact analysis of change, demonstrating verification and validation, and proving compliance or functional safety.
Likewise, the risks of using spreadsheets — like user error and fatigue — are eliminated, and efficiency increases as teams can focus on their central duties. Live Traceability also fosters team collaboration and enables the earliest detection of possible production risks.
In This Webinar, We Cover Best Practices for Requirements Traceability
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!