Our Thinking

The Importance of Requirements Traceability

Posted by Rick Strempler on Apr 7, 2014 4:33:33 AM

The term “requirements traceability” refers to the ability to map requirements back to business goals and objectives, and also to map requirements forward to test cases, business processes, software, training materials, and more. The concept is quite simple, really – it’s a way to tie everything together from start to finish, and make sure that end products align with originating goals and objectives.

One of the starting points for a project is to establish the goals and objectives for the business or project. These should align with business needs or opportunities. As we continue with our project work and start gathering and documenting business requirements, traceability helps us to ensure that our requirements are consistent with the goals and objectives.

As you map your requirements back to those goals and objectives, you might find that some of your requirements aren’t directly related to your goals and objectives. What does this mean? It means that you may have deviated from the original intent of the project. The requirement might represent something that is useful to the business, but it doesn’t align with the goals and objectives. You should take these back to your stakeholders to decide whether that work should or should not be included in the scope of your project. Those requirements might represent scope creep – functionality that is nice to have, but doesn’t help you achieve your specific goals. In fact, by spending time on such requirements, you could incrementally delay your project and its benefits.

On the other hand, when you map your requirements back to your goals and objectives, you might find that there are some goals and objectives that are not being addressed at all, or are being addressed insufficiently. In such cases, you should consider going back to your stakeholders to spend more time addressing these goals and objectives, to see if there are additional requirements that need to be collected.

Traceability isn’t just about mapping requirements back to goals and objectives. It is equally important to ensure that requirements are being addressed appropriately by its consumers. When the QA team has finished defining test cases, they should map those test cases back to your requirements. This will help to improve the coverage of the test cases. Similarly, if you are working on a project where new software is being developed, then you should work with the development team to map requirements to design documents and software functionality.

You could create the most incredible, complete, thoughtful requirements document, but it won’t amount to anything if you don’t also take the time to ensure that all of the consumers of your deliverables are accounting for every requirement. It’s equally important to ensure that they understand your requirements correctly, which is why it is important that you work collaboratively on requirements traceability. A misunderstood requirement can create significant problems for a project.

Really, any downstream consumer of your requirements should be considered in scope for traceability. If your requirements result in new business processes, then include those business processes in your traceability. If your requirements result in RFPs, then include those RFPs in your traceability. If your requirements result in new training, then include that training material in your traceability.

The Traceability Matrix

One great benefit to traceability is the ability to assess the impact of your requirements. When requirements change midway through a project, a traceability matrix allows you to identify all of the impacted workflows, test cases, training materials, software code, etc. As a result, you are able to quickly assess the impact of the change and account for it appropriately.

Traceability is one of those things that tend to be removed from the scope of a project when things inevitably fall behind schedule. When the team is working hard to try to meet deadlines, it is tempting to jump to an assumption that traceability isn’t required. This can introduce tremendous risk to the project. One missed requirement can potentially result in significant rework. It can result in a product that doesn’t truly meet business needs.

One of the most common tools for documenting requirements traceability is the traceability matrix. Creating a traceability matrix really shouldn’t take very long, but maintaining it can be a challenge. You may want to choose a specific time to create a traceability matrix within your project, then plan for time to make project changes when you discover missed requirements or misaligned deliverables. You should also decide how long to maintain that traceability matrix.

So, what does a traceability matrix look like? It is essentially a table, with individual requirements listed along one axis and the related deliverables along the other axis. For example, you could list one test case in each row and one requirement in each column, and then place an “x” everywhere in the grid where a test case aligns with a requirement. I’ve used test cases in the following example, but the same approach could be used for training material, workflows, or any other type of project deliverable.

 

Req 1.1

Req 1.2

Req 1.3

Req 2.1

Test case 1.1

x

x

Test case 1.2

x

Test case 2.1

x

x

Test case 2.2

x

Test case 2.3

x

x

Test case 3.1

x

One of the challenges with using this approach is that some projects have a very large number of requirements. In these cases, you may choose to create separate matrices for various components or modules of the project/product. Alternatively, you could use a single column to identify the related requirements, and list all related requirements in that single column, as shown in the next example. This eliminates issues with large numbers of columns, but can make it more difficult to quickly identify traceability concerns.

Test   Case Requirements
1.1 1.1, 1.2
1.2 1.3
2.1 1.1, 1.3
2.2 1.1
2.3 1.1, 1.2
3.1 2.1

These are very simple examples of traceability matrices, but you can add additional attributes where necessary or appropriate. For example, the IIBA’s BABOK suggests that there are benefits to defining the type of relationships between the elements. This is commonly referred to as “typed traceability.” Furthermore, you could write more detailed explanations about those relationships. This is commonly referred to as “rich traceability.” Keep in mind that more time is required to create and maintain more complex traceability matrices. You need to find the sweet spot, which provides the maximum benefit with the minimum amount of effort. In some cases, traceability may actually be a regulatory requirement; in those cases, you may not have a choice about the level of detail.

Requirements Management Tools

Many requirements management software packages offer built-in requirements traceability, where deliverables managed within the software are automatically linked together. This is one of the great benefits with a requirements management tool. However, that traceability can only include the information that is contained within the management tool. It may leave some traceability gaps. Depending on the tool, you may not be able to use it to trace requirements to newly created code, or to training material, for example.

Conclusion

I strongly encourage you to include requirements traceability in your project plans. Account for the time to document traceability, and account for the time to make any changes that you discover during that exercise. When the schedule gets tight, fight off the temptation to skip this important process. Done right, requirements traceability can significantly reduce project risk without significant effort. Take the time to determine the appropriate level of traceability and stick to your guns. When you find that missing or misinterpreted requirement, you’ll be glad that you took the time to do this work.

 

Topics: Business Analysis, Quality Assurance

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates