Requirements traceability matrix: the map to testing use cases

Managing requirements is the kind of thing that calls for time, patience, care and attention. There’s a lot of details that surround even the most basic requirements, creating a prime situation for overwhelming the team and letting the small stuff go by unchecked. That’s where the requirements traceability matrix comes in.

The matrix is, essentially, a map to imperfections. It lists out all the pieces of information about the project that, together, paint the big picture. But what does that document even look like? How can we make one that makes sense? What doctors are there to consider? Let’s take a closer look at the traceability matrix and how you can use it to deliver the perfect user experience.

Think of the traceability matrix as a crucial document that keeps track of every single requirement in your project and establishes a link between each requirement, along with its test. First off, the name of this file can be a bit deceiving. “Traceability” here doesn’t actually refer to being able to trace the team’s steps, but rather keeping track that each individual requirement is both tested and met by the product.

That is the essence of the matrix. It consists of a long list of requirements that can go from engineering to design, along with key information such as the ID code of the test that validated the requirement has been met. While there are many free templates for requirements traceability matrices, there isn’t a one single document that all teams use around the world.

But what do we mean with “testing requirements”? We don’t mean a classic usability study, but rather testing each user case and scenario. Consider a log in action. The user wants to log into his account. Naturally, the cases here could be that:

A) He logs in successfully
B) He doesn’t manage to login
C) He needs to enter his email to be able to reset a forgotten password

Each of these scenarios is possible in their own right – which means that all three need to be properly tested in order to make sure that nothing fails, no matter what the user does. As one can imagine, all the actions and their corresponding scenarios in a product can add up to a very long list. A list so long, in fact, that it’s generally accepted that no one tries to meet their requirements without a matrix and a specific tool.

It’s just too easy to miss the little things, such as a tiny error in login. It can be easily overlooked without the traceability matrix, but a login error could impede your users from even accessing the product, let alone use it. In UX design, even small errors can erode the general experience depending on how serious they are or how many there are.

The traceability matrix is basically a checklist, where we make sure that every single possible scenario has been checked and found to work by the end of the project. This concept has many names, but tends to be referred to as ‘testing coverage’, as well as ‘testing engagement’ quite often. Ultimately, you want a 100% testing coverage by the end of the project.

It’s true that all these requirements and their corresponding scenarios and cases can be complex to manage. It’s just a lot and in a way, all of it is crucial. Enter the traceability matrix. With this handy document in hand, your team can spot blind spots that haven’t been tested and validated – like a map.

The matrix is meant to help us keep track of what requirements have been tested. But what kind of information is included in the matrix? Is it a simple matter of requirement, actions and scenarios along with a testing ID code? Well, no. A traceability matrix usually includes some of the following:

• Requirement, with actions and corresponding use cases, scenarios
• Testing ID code
• Status of testing
• Results of tests
• Designer in charge of each individual test
• Defects found (if any)

The truth is, each team will have their own way of organizing the traceability matrix. The main idea is that each piece of information helps to give you a snapshot of how much ground you’ve covered with your testing at any point in time. For this, you’ll need a well-organized code system for each requirement, each case, each scenario, as well as defects.

It’s true that the traceability matrix in itself implies the creation of other documents. For example, for large products that have lots of actions and use cases and scenarios, a Use Case Document might be in order. That way, your matrix stays clean and it becomes a matter of simply checking which code stands for each.

You’ll want to have some balance between how much raw information you actually write down in the matrix and how much of it is summarized by ID codes. Too much will make the matrix a nightmare to read, too little harms its efficiency in giving us that snapshot of covered ground.

Like we mentioned before, it’s not particularly uncommon to see requirements traceability matrix templates online. In this section, we’ll go over some popular templates out there. Each of these can be downloaded as an Excel file with the main structure of the matrix already assembled.

The Strong QA platform offers a wide array of testing document templates, making it a good resource for design teams everywhere. Their requirement traceability matrix template has a five-star rating by the 222 users who downloaded it!

As always, the best way to approach this is using the template to avoid the initial setup of the spreadsheet. Once you have taken a good look at what kind of information is included, try to decide if you need more information that is specific to your project.

Given the close relationship between managing requirements, testing cases and the traceability matrix, it’s no surprise that a testing platform took the time to create a matrix template. The file can be easily downloaded and adjusted to suit your needs.

Stakeholder Map created a requirements traceability matrix template that brings something new to the table. This matrix doesn’t just focus on the vitality of testing coverage. Indeed, this matrix is more focused on the business side of things, offering an entire column to business objectives and another for its deliverables.

It’s true that many times, the traceability matrix is simply done in a spreadsheet, such as Excel.

That simplicity means that it will be easy to deal with a simple tool, without getting deep into more advanced features that make most Excel users get a cold sweat down their back. It does mean, however, that you and your team are likely to spend long hours creating and maintaining the spreadsheet. A traceability matrix involves a lot of details and calls for some skill in organizing the information logically.

For those who aren’t ready for all that time in close proximity to Excel, there are other options. Not all of these tools will have a classic matrix as a feature, but they have their own brand of traceability that makes up for it.

Helix ALM is brought to us by Perforce, and it prides itself on offering users a potent tool to create requirements traceability matrices. Users praise the tool’s ability to link requirements with the testing involved in any given project. In fact, the tool itself is used by some teams as the requirements management tool of choice.

We love that Helix ALM checks all the right boxes, with features ranging from the matrix to risk management. It becomes evident that the true value in the tool, however, lies in its testing case module – an aspect of the matrix that can be challenging to manage in other tools.

Jama is a well-loved requirements management in the industry. The tool itself is complete with all the features a design team could want from a requirements management tool. Users rage about how easily they can generate reports of different aspects of the project – including the traceability matrix!

With good customer support, thought-out features and a user-friendly UI, Jama has earned its place in the hearts of designers all around the world.

As a requirements management tool that is more oriented towards development and engineering teams, codeBeamer understands the importance of tracking errors. The tool itself goes far beyond managing requirements but also places great importance in tracking and managing defects.

It makes for a feature-packed tool that can definitely help any design team keep track of testing and establishes a clear relationship between testing and the requirements themselves. The tool itself works as a wonderful matrix.

Visure is a big name in the requirements management industry. The tool itself is very popular for its wide array of features that cover Test Management, Defect and Issue Tracking, Change Management and Risk Management. It prides itself in helping users optimize their management of requirements while adapting itself to any workflow possible.

We love that they take defect and issue tracking seriously, making it easy to get that crucial snapshot we mentioned earlier. The tool has different reports that all summarize progress, acting in a very similar way to a classic traceability matrix.

Having a traceability matrix isn’t the first thing most of us think of, when it comes to requirements management. This little document can often be misunderstood or overlooked, but it plays a very important part in the project development.

Having a traceability matrix can be the difference between a clean product with a smooth experience and a sloppy product that never quite wins users over. The truth is that in UX design, testing coverage is crucial if you hope to deliver a top-quality design – making the matrix a must-have tool in your arsenal. Without it, the details can fall between cracks in the workflow, slowly eating away at the potential of the final product.