Learn How to Create and Manage an RTM for full Test Coverage

In this article, I’m going to discuss what an RTM is in software testing.  

I’ll also go through some fundamental points on why you need one for your software testing projects.

I’ll then talk about how to use it as part of your project to ensure you have full test coverage of each requirement.

The contents of this article are based on over a decade of working with RTM documents.

What is a requirements traceability matrix in software testing?

An RTM is a single document that captures every project requirement during a software development project. A testing team can create test scripts using full bi directional traceability by mapping each project requirement to appropriate test cases. It also allows stakeholders to understand test coverage.

Why is a Requirements Traceability Matrix Important?

All project requirements and specification can be captured in a single golden source

Whenever I start to design test cases, I always prefer to have ALL requirements beforehand.

The RTM acts as a document where you can literally ‘chuck’ everything into.

Think of the RTM as the nerve centre for all requirements.

This really makes your life easier.

We’ll get to that later in this article.

Test coverage can be captured in its entirety

• Forward traceability coverage – each requirement can be mapped to a test case, script or scenario
• Backward traceability coverage – Each test case and test condition can be mapped back to a requirement document using reverse traceability.
• Bidirectional traceability coverage – You have full end to end visibility for each requirement

It allows easier easier requirements management and maintenance

Lets say you’ve spent some time creating test cases without an RTM.

What if customer requirements change?

How do you track which requirements have been updated, removed or added?

What if the FRS document needs an update after a static review?

It can be an absolute nightmare. You can do it but it takes a lot of work and reviewing tons of documentation.

With a RTM, you literally update the document and VOILA.

Take it from someone who has the scars.

Sorting and filtering becomes much easier.

Allows easier test script / test case / test scenario creation

I’ve found that when every user requirement is categorised in a Requirements traceability Matrix document, it is far easier to create test scripts.

For example, filtering by a specific category such as ‘area of functionality’ or ‘functional module’ gives me an idea of the types of tests to create.

Better Effort Estimation for Test Design/Test Plan Stage

You know when your Project Manager asks you ‘how long will it take to create test cases?‘.

With an RTM and some experience, this task is made somewhat easier.

I find that I can usually give high level estimates ‘better’ than if I didn’t have an RTM.

You can provide a Traceability report quickly

I’m sure many of you reading this have to provide a daily or weekly status update to your line manager or wider stakeholder group.

Now just imagine how easy it becomes when a project stakeholder randomly asks you how many test cases you’ve created or how much test coverage you have.

This is one of the major benefits of having an RTM which can be a lifesaver.

I remember a key stakeholder asked my team this question once and we couldn’t answer because there was no RTM.

We knew how many test cases we were planning to create but didn’t know the exact test coverage in terms of percentage.

We had to trawl through a magnitude of requirements documentation before we could give him the numbers.

Don’t let that be you.

Audit Trail

I’ve worked in a banking environment for many years.

It’s incredibly regulated and rightly so.

If you cough, sneeze of breathe, you have to let the regulators know.  I’m obviously being pedantic but you get my drift.

An RTM allows you to capture a full audit trail of each requirement.

If an internal or external audit team wants to look at your documentation then you know you’re covered.

My projects have been audited not only by internal teams but also external (including the big 4 consultancies) many times.

You’ll know where I’m coming from for those of you that deal with the three lines of defence (3LoD) risk model.

When it comes to making notes in the RTM I always date and initial the comments section so literally EVERYTHING is documented.

It’s almost like a running commentary.  It’s not required but just how I like to work.

This has honestly helped so much when it comes to things like audits or if you just want to see the history of a requirement.

Identify Regression Testing Gaps

An RTM will allow you to also identify any gaps in your existing regression test pack and allow you to update it.

Helps your Testing Team Colleagues with continuity

I’m a positive person so don’t want to use the ‘getting run over by bus scenario’

But lets say you leave your role tomorrow.

With an RTM, any one of your colleagues can pick up the document and get a real grasp of the project requirements at a granular level.

How to create a Requirements Traceability Matrix (RTM) Document Template

Your RTM needs to include a few very important pieces of information.

You can create this in Microsoft Excel, Google Sheets or any tool of your choice.

Below are the fields I always like to include as a minimum.

Project Requirement ID

This is a unique ID that will be generated specifically for this project.  I usually keep this different from tha actual Requirement ID in specification documents.

Document Name

The actual name of the actual requirement document.

Document Type

This should detail the type of document you are referencing to, for example (but not limited to);

• Business requirement document (BRD)
• Functional Requirement Specification (FRS)
• Non functional requirement specification (NFRs)
• Data flow diagrams
• Use Case descriptions
• High Level Design (HLD)
• Security Requirements

Any other software or technical requirement that you need to capture.

Author

Include the name of the author of the document.

Version

This will indicate whether or not the document is a draft or baselined version.

It is also particularly handy to know this so you know which version you are designing your tests against.

If the client requirement change then you can update the RTM accordingly.

Source Document Requirement ID

This is the actual requirement ID that is in the source document.

For example, BRD0001 may be the referenced in the the business requirement document.

You should copy and paste BRD001 here.

Requirement Description

Using the above example, copy and paste the whole requirement description for BRD001 here.

Include any business rules, logic etc.

If you think that the requirement needs to be broken down further into numerous conditions, then you can also do this.

I would actively encourage this as it gives you more control over the quality of your software application under test.

Test Case ID / Test Script ID / Test Scenario ID

Add the corresponding test case, script or scenario ID where you have included the requirement.

The Initial RTM Creation Process – Pre Test Case Design Stage

For those of you that are familiar with the ISTQB testing process, the initial RTM stage would sit anywhere in between the first two phases. 

This totally depends on your organisation’s processes and working practices.

I would personally create the draft RTM at the ‘Test Planning’ or ‘Analysis and Design’ phase. 

It should really sit after the moment you receive the project requirements and prior to you starting your test design.

I would start on creating the RTM prior to commencing work on your test plan.

You can definitely work on the RTM and Test Strategy.in parallel.

Ensure project requirement and design specification documentation is baselined

This is SUPER IMPORTANT.

Ensure you have baselined or almost finalised requirements before you start working on your RTM.

Draft requirements that are in their early stages are not a good idea as they will mean more effort when making updates.

I’m always keen to get this done as soon as possible, BUT, its always a good idea to hold out until they are almost ready,

If you can, try and insist for a baselined version of a requirement specification document.

It really will make your life easier.

Fill out the template as much as possible

Once you receive your documentation, start to fill out key parts of the RTM. For example;

• Document Name
• Document Type
• Author
• Version
• Source Document Requirement ID
• Requirement Description

At this point, you will NOT be designing any test cases, only throwing all requirements into the RTM.

Think of it as a repository for project requirements.

Understand the Test Responsibility and Stakeholder’s Involvement

It’s all good and well having a complete and nice looking RTM.  However, you need to know what to do with it.

What if your team can’t test a requirement but another team can?

How do you agree on who tests what?

The RTM is a great way to agree this before you start any test design work.

Let’s go through a few points on how you can mitigate any gaps in coverage;

Agree on the requirement owner(s)

There are so many different requirement types and involvement from many different teams when you test software that it can sometimes get confusing.

Ensure you make a note of who owns the requirement.

For example, the Business requirement document (BRD) is generally owned by the end user in conjunction with the Business Analysis team.

Engage with the team who wrote the requirement and ensure you capture this in the RTM.

In the comments section, date and initial with a description of the conversation or email conversation.

Agree on who tests the requirement(s)

  – Pay particular attention to Non-Functional Requirements (NFRs)

  – Update the relevant requirement 

I’ve worked in many scenarios where the owner of the requirements isn’t necessarily the team that will conduct the test.

As a Test team function, the natural assumption is that you’ll be responsible for all testing.

This isn’t always true.

VERY IMPORTANT POINT

It’s absolutely imperative that you get this agreed before you start any design.

Take it from me, if you don’t get this agreed now, you’ll potentially have a big headache further down the line.

Oh and ALWAYS get confirmations in an email.  Verbal agreements do not count.

Pay particular attention to Non-Functional Requirements (NFRs)

Managing non functional requirements can be a NIGHTMARE!

They cover a wide net of different types of tests which involve different teams.

For this reason, it’s really important that you don’t forget about these.

I had a project where I was testing a web based functional application for many months.

We had a few issues at first but we’d managed to reach the end.

I completed a draft of the Test Completion report (Test exit report), only to be told that the NFRs hadn’t been tested.

The project was due to go into Production in a few days and no stakeholder was prepared to Sign off.

This was an absolute nightmare.

So what happened?

A number of things.

The requirement owner didn’t want to test the IT security requirements.

This is not something my team ever tests.

Thankfully our team had no option but to take on the responsibility to test most of the outstanding requirements.

We didn’t have to but we did this for the greater good.

Having a very experienced and awesome Project Manager also helped immensely.

We definitely would not have managed to do it without Chris (name changed).

This is an example of ensuring that your stakeholders category agree as early as possible on their responsibility.

Ensure all requirements have been covered

• Every single requirement needs to be covered in terms of whether ot nor it will be tested or not.
• There must be NO gaps.

Get Stakeholder approvals 

Once you have every single requirement covered, it’s time to get approval from the stakeholder community.

Baseline document and send out to all stakeholder teams

During the Test Design Phase 

Add corresponding test cases and their IDs to the RTM

As you design your test cases, make a note of the requirements that are being covered and literally fill out the RTM.

Update

If there are any specification updates, then now is a good time to update the RTM.

Pros and Cons of an RTM

There are a number of positive as well as not so good reasons for using an RTM.

Pros

• Can easily track coverage and gaps can be found quickly
• Allows the test team to feedback to the authors of specification documentation and therefore improving the quality of documentation.
• Quality of testing can be better.

The International Journal of Engineering also list the benefits of using an RTM.

Cons of the Requirements Traceability Matrix Document

Its not all roses with a RTM. There are a few downsides too.

• Can’t start until you receive documentation
• Can take some time to create – especially if you’re breaking down into conditions.
• Many test teams still do not adopt the RTM 
• Its an overhead – When you’re working to tight deadlines, managing yet another artefact can be an overhead they can cost time and money.  

Wrapping Up

Having worked in many different types of software testing projects over the years, I can category say that I’ve found the RTM incredibly useful.

Not only does it help you identify any gaps in coverage, but also gives you an idea of progress.

It also comes to your rescue when there is an audit or when management want to ask you any questions.

My advice would be to incorporate this document as part of your organisation’s testing process.

It really has helped me from a test management and stakeholder management perspective.

I’d love to hear your thoughts and whether or not you use an RTM as part of your test process.