The Essential Guide to Requirements Management and Traceability
Requirements Traceability: Links in the Requirements Chain
Derived requirements traceability is a form of requirements management focused on tracing requirements that aren’t explicitly defined in higher-level requirements, but which are necessary for meeting them and for making the overall system work as expected. In derived requirements traceability, teams will document the dependencies and logical links between these lower-level requirements and other system elements.
Derived Requirements, Explained
For sufficient derived requirements traceability, each requirement must have a unique and persistent label that allows for unambiguous tracking throughout the project. A centralized, modern requirements management solution is preferable to numerous discrete requirements documents for this purpose.
Not only does such a management tool provide one convenient place for collecting feedback and collaborating in real time on reviews and approvals, but it also supports live traceability of upstream and downstream relationships, with clear visibility into the impact of changes on all levels of requirements as well as test coverage. Accordingly, project teams can set up four distinct types of traceability links for their derived requirements.
Figure 1. Four types of requirements traceability.
The Four Types of Derived Requirements Traceability
1. Forward to Requirements
When customer needs evolve, requirements may have to be adjusted in response. By making these adjustments, project teams can keep pace with changes in customers priorities, introductions of new business rules, and modifications of existing rules, among other events.
2. Backward From Requirements
Tracking backward from requirements can provide clarity into the origin of each derived requirement. For instance, a requirements management tool could show the link between the derived requirement, the requirement it came from, and the customer use case being addressed.
3. Forward From Requirements
Once derived requirements begin flowing into downstream deliverables during product development, it’s possible to draw trace relationships between requirements and their corresponding elements. This type of link provides assurance that every requirement is satisfied by a particular component.
4. Backward to Requirements
Finally, this type of link allows for visibility into why certain features were created. Consider how most applications include lines of code that don’t directly relate to stakeholder requirements. Even so, it is important to know why a software engineer wrote that code in the first place.
While a full accounting of all four types is beyond the scope of this piece, let’s look at a more in-depth example of the fourth type. Suppose a tester discovers unexpected functionality with no corresponding requirement. It could indicate two divergent possibilities:
- The underlying code might have been implemented to meet a legitimate implied (derived) requirement, which could then be added to the requirements specification.
- Alternatively, it might simply be orphan code that no longer belongs in the current product.
Traceability links create clarity in such situations, shining a light on how the different pieces of a system all fit together. Conversely, test cases derived from – and traced back to – individual requirements offer a mechanism for detecting unimplemented requirements, because the tester won’t find the expected functionality.
Figure 2. Some possible requirements traceability links.
There are many types of traceability relationships possible within a project, and not all of them will be needed on every project. However, there are good motivations for implementing derived requirements traceability, via a best-in-breed solution with flexibility that can be leveraged as needed for a given project.
The Main Motivations for Derived Requirements Traceability
At a high level, traceability contributes to a more efficient product lifecycle and superior project management. More specific reasons for implementing it include:
Certification
Traceability data can support certification of safety-critical products, by demonstrating that all requirements were implemented.
Impact analysis
By tracing derived requirements, it’s less likely that something will be overlooked when determining the effects of changes to requirements.
Maintenance
Clear traceability simplifies maintenance, as changes (e.g., in response to updates to government regulations or corporate policies) can be performed with more confidence. A modern requirements management tool makes it easier to show where each applicable rule was addressed in requirements.
Project tracking
Traceability information offers an accurate record of the implementation status of planned functionality, with missing links indicating work products not yet created.
Reengineering
List functions in a legacy system set for replacement and use traceability data to record where they were addressed in the new system’s requirements and software components.
Reuse
With derived requirements traceability in place, it’s more practical to reuse product components by identifying packages of related requirements, designs, code, and tests.
Risk reduction
Documenting component interconnections reduces risk in the event that a key team member with essential knowledge about the system departs the project.
Testing
The links between requirements, tests, and code help indicate the likely locations of bugs when a test yields an unexpected result. Also, knowing which tests verify which requirements will save time by allowing for the elimination of redundant tests.
The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.
The purpose and importance of requirements traceability
Traceability enables product teams to associate a specific requirement with all the related project artifacts, as well as other requirements, both forward and backward, so that anyone can see how the activity relates to the requirement—and vice versa—at any point during development. This functionality, also called live traceability, fosters team collaboration and enables early detection of possible production risks.
Think of it this way: How important is it to have your products developed correctly in terms of definition, quality, and timing? Mission critical, right? That’s why end-to-end traceability is so critical.
Let’s take a look at some of the benefits of traceability throughout the product development lifecycle. For example, live traceability:
- Simplifies project estimates
- Enhances process visibility
- Increases development efficiency
- Improves impact analysis of change
- Demonstrates verification and validation
- Strengthens product quality
- Proves compliance or functional safety
A single line of sight on a requirement, or a digital thread, is supremely important for application lifecycle management (ALM) and product lifecycle management (PLM). Both endure tight timelines and increasing numbers of requirements — including those from regulations, where compliance is non-negotiable.
Knowing the relationship between requirements, risk, tests, and so forth, is the difference between developing a compliant product on time and getting stuck in rework, delaying launches, and dealing with unhappy stakeholders. With requirements traceability, you don’t have to compromise on speed or quality.
The bottom line is that end-to-end traceability confirms you’re building the right thing and helps you prove compliance or functional safety. Without requirements traceability your development efficiency and product quality are in jeopardy.
Forward and backward traceability: The mechanics of creating a digital thread
To connect all the phases of the product development lifecycle, from customer needs through support, four distinct kinds of links must be used to thread the process end-to-end. This includes high-level requirements as well as derived requirements—those not specifically defined but necessary for meeting defined requirements or having the system work as expected. Derived requirements must also be adequately traced to reap the full benefits of live traceability.
What is forward traceability?
There are two kinds of forward traceability: forward to requirements and forward from requirements. They both trace from an upstream component to downstream artifacts. The difference is in where they begin.
Forward to requirements traces from customer need to requirements. This is important because customer needs can evolve over time. If they do, requirements may need to change as a result. Following this type of forward traceability enables teams to be informed of changes in priorities at any time throughout development.
Forward from requirements traces relationships between requirements and corresponding downstream artifacts, including test cases. This type of trace ensures that each requirement is not only satisfied but verified and validated.
What is backward traceability?
Like forward traceability, there are two kinds of backward traceability. This pair traces from an endpoint, or downstream work product, to upstream elements. The two types of backward traceability have differing starting points.
Backward from requirements gives insight on how a requirement came to be by linking the requirement to the customer use case it addresses. This enables teams to improve decision making by understanding the origin of a requirement.
Backward to requirements begins at performed work and traces to its requirement. It gives visibility into why specific items were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing requirements.
What is bidirectional traceability?
Bidirectional requirements traceability is the ability to perform both forward and backward traceability. Bidirectional traceability is the optimal type of traceability because it gives teams full visibility from requirements specifications through building, testing, changes, defects, and back again. Traceability of this caliber can only be achieved through automated requirements management tools, such as Jama Connect®.
Common challenges of requirements traceability
If all this sounds like traceability is too difficult, fear not. While there are some challenges to requirements traceability, there are also many templates and tools you can use to streamline the process (more on that below). For now, let’s tackle some of the challenges so you can see how they can be overcome.
Differing organizational viewpoints.
Not everyone has the same understanding of why and how traceability should be performed. Stakeholders in sponsor or management positions may only view requirements traceability from a standard or regulatory perspective. They see it as a “must-have” but may not understand the additional benefits of requirements traceability (as discussed above) in the way a project or systems engineer might.
One way to tackle this obstacle is to educate stakeholders on what can be achieved if end-to-end traceability is achieved. Share this article with everyone involved in your development process so they can have a basic understanding of why requirements traceability is an essential part of requirements management, beyond simply knowing they need it to cover their bases.
Organization-wide adoption.
There are a variety of reasons a company might be slow to adopt traceability. Training is one such example. As considered regarding stakeholders, not all teams or individuals working on a project know why traceability is so crucial, or they simply may not know how to execute proper traceability correctly. Additionally, some people may be worried that traceability data from their decision points could come back to bite them.
If this is a challenge for your organization, again, education is imperative. But even beyond that, you need to create a culture in which traceability is seen as an inherent part of the development process. Start by creating clear policies regarding how the organization manages traceability. Then develop a positive training program for all new and existing employees to complete. If you choose a requirements management tool, make sure it has a strong track record of being intuitive and easy to use software that adapts to your process—not the other way around.
Cost of implementation.
Getting an entire development organization on the same page regarding requirements traceability, then ensuring proper execution, can be a costly endeavor. The time spent developing policies, conducting training, and creating/maintaining traceability data add up and can even make folks feel less productive. Additionally, you may choose to adopt a traceability tool to streamline your process, which means upfront costs will be higher than previous projects.
Overcoming this obstacle requires a mindset change. We urge you to consider the cost of doing nothing. Unproductive work time, lengthy time-to-market, rework, and defects are all extremely expensive symptoms of inadequate requirements traceability. Each of these carries a hefty price tag. For a look at exactly how much these complications could be costing your organization, check out the calculators on pages 9-11 in our Buyer’s Guide. While there are costs to implementing requirements traceability and management tools, the amount saved throughout the development process far outweighs the short-term investment.
Managing change.
When building complex products, change is inevitable. It is essential that team members know about the changes and scope their impact across the product development lifecycle. That means looking closely at any related system requirements, downstream requirements, and verification tests that may be affected.
Performing this activity can be cumbersome and time consuming with manual requirements traceability tools. And the associated risks are similar to doing nothing, simply because you cannot be sure you’ve accounted for everything when dealing with static documents and human error.
If you’ve experienced this setback in your organization, it may be time to explore automated requirements management tools that enable Live Traceability™.
Improper management tools.
Some development teams are still tracing requirement relationships using Word or Excel documents and collaborating via email. A Requirements Traceability Matrix is one example of a document that manually traces elements of requirements management including, business requirements, objectives, design elements, and test cases via a spreadsheet. Teams input the list of requirements and fill in the related data. The spreadsheet is static but is updated manually by the team throughout the development lifecycle.
There can be advantages to using a Requirements Traceability Matrix if you are developing a product that doesn’t have many requirements. And it is better than not tracing at all. You can even use a template to create a Requirements Traceability Matrix. However, if your product is complex, with many requirements, you’ll likely experience many of the challenges discussed above.
In the case of complex products, a Requirements Traceability Matrix does not have the functionality you’ll need to keep up with the pace of change and create a quality product in the timeframe required by stakeholders. Flexible requirements management tools like Jama Connect can even capture trace relationships across teams and toolsets, further enhancing the benefits of traceability.
Insufficient compliance framework.
Regulated industries need requirements management to demonstrate compliance with industry standards. There are specific ways reviewers and regulators must receive regulatory submissions. To pass an audit you must present proof of comprehensive traceability.
If comprehensive traceability wasn’t performed throughout your development process, a lot of time will be committed to gathering the necessary information after the fact. Even if traceability was meticulously maintained in Word or Excel, there will still be time spent compiling it into an acceptable format for regulatory submission. In the meantime, competitors that make traceability inherent to their process will be first to market.
Sound familiar? Luckily, there are tools that perform end-to-end traceability and come with frameworks aligned with industry standards. Requirements management tools like Jama Connect simplify the audit process with export templates, thus speeding up the compliance presentation process.
Templates and tools to streamline the requirements traceability process
There are numerous tools available to assist with the traceability process. It’s important to assess your needs to know what is best for you.
Are you creating a straightforward product that doesn’t have functional safety or regulatory requirements? If so, an RTM may suffice. Download this Requirements Traceability Matrix template to get started today.
Are you creating a multifaceted product with both software and hardware components? Will you be required to prove functional safety or regulatory compliance? In these cases, you’ll need a requirements management tool with bidirectional traceability and compliance templates you can easily export.
In This Video, Learn About the Power of Live 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!