What is a Requirement Traceability Matrix

When developing software applications, we want to make sure the application does what the software requirements say it’s supposed to do, and testing proves that it does. In this article, I’ll explore how to link requirements to test cases, and I’ll explain what a requirement traceability matrix is and how to build a simple one.
Article first appeared on Stackify blog.

What Is a Requirement Traceability Matrix?

Wikipedia describes traceability matrices in general and software requirement traceability matrices in particular.

A requirement traceability matrix may be used to check if the current project requirements are being met, and to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks.

I will use a simple example.  Let’s assume our application has a login screen that shields it from unwanted access and that we want a user to enter a valid username and password in order to access it.

So let’s start by creating some simple requirements.

Create Software Requirements

Typically, system requirements are described in bland language so that they’re clear … hopefully.  A few requirements for our simple example might read something like this:

  • 1.1 The system allows a valid user to access the application.
  • 1.2 The system requires the user to enter a valid username and password in order to access the application.
  • 1.3 The system prevents an invalid user from accessing the application.

Next, we add some numbers.  Without getting into any complex numbering systems, which are usually the norm for large and complex systems, we’ll use simple numbering.  However, complex projects often use modules and sub-modules to group and number requirements. Depending on the complexity, the numbering can become very involved, but we’ll keep things simple.

Now, let’s create a few specific test cases. I know these examples are very simple and that you will find many faults with them. However, I am purposefully keeping things simple so I can illustrate the most important aspects of developing an effective requirement traceability matrix.

Create Test Cases

Experience teaches us that we should always focus on testing the desired behavior before concerning ourselves with testing error cases. Usually, we refer to this as the “happy path test.” This “happy path” happens when everything lines up correctly. When user input is correct and the application functions correctly, we should see the expected outcome. Only after defining the happy path will we create two very simple error cases.

Test Case 1.1 – Log in Successfully

  1. Prerequisites: valid user account exists
  2. Enter valid username
  3. Enter valid password
  4. Click the login button
  5. Verify that the user can access the application and can see the application home page

Test Case 1.2 – Attempt to Log in With Bad Credentials

  1. Prerequisites: valid user account exists
  2. Enter an invalid user name and/or an invalid password
  3. Click the login button
  4. Verify that the user sees a validation error
  5. Verify that the user cannot access the application and keeps seeing the login screen

Test Case 1.3 – Attempt to Log in With Empty Credentials

  1. Leave username and/or password fields empty
  2. Click the login button
  3. Verify that the user sees a validation error indicating that fields are required
  4. Verify that the user cannot access the application and keeps seeing the login screen

Usually, there is a loose correlation between the numbering of test cases and the numbering of requirements. However, it is beyond the scope of this article to go into numbering schemes, as opinions and practices tend to differ greatly.

Trace Requirements to Test Cases

Useful test cases respond to system requirements. Consequently, when we write a specific test case, we will have one or more specific requirements that we want to satisfy. Depending on how rigorous and formal your test documentation has to be, you can write the applicable requirements into each test case. This is forward requirements tracing.

Trace Test Cases to Requirements

Another important goal for tracing requirements is the ability to quickly go backward. In our case, we want to be able to go from a specific test case back to the requirement that it satisfies.  This is called backward requirement tracing.

With these two main requirements, let’s build a simple requirement traceability matrix.

Build a Simple Requirement Traceability Matrix

A requirement traceability matrix has four basic components: requirement identifier, requirement summary text, test case identifier, and test case status.

Requirement IDRequirement TitleTest CasesTest Case Status
1.1Successful loginTC 1.1pass
1.2Login requires user name & passwordTC 1.1
TC 1.3
1.3Block invalid loginTC 1.2
TC 1.3

Add More Information Only If Needed

Depending on the complexity of our application, we can add more information to our matrix.  First, we usually add a requirement category or module. As a result, we can quickly sort our information into these sub-groupings and make things easier to follow.

Requirement IDCategoryRequirement TitleTest CasesRun 1
Run 2
1.1LoginSuccessful loginTC 1.1
TC 1.3
1.2LoginLogin requires username & passwordTC 1.1
TC 1.3
1.2LoginBlock invalid loginTC 1.2
TC 1.3

Note that the single Test Case Status column has been replaced with two columns. These new Run Status columns represent the status of each test case during a particular test run. We can obviously add more columns for each test run we’re performing. Consequently, our requirement traceability matrix provides a quick visual status of our application’s current condition. Thus, using this matrix we can go forward from requirements to test cases.  We can also go backward from the failed test cases to the requirements and flag issues quickly.

Keep Things Simple

The main purpose of a requirement traceability matrix is capturing the link between each requirement and its tests in a clearly visible way. If, on the other hand, there is too much information in your matrix and you keep having to search through it, your matrix is not serving its purpose. Every new column should be carefully analyzed before inserting it.

Requirement Traceability Matrix Today

By now you’re probably thinking that creating a requirement traceability matrix entails a lot of manual work.  Generally, I would agree that this is not in keeping with agile principles.  However, custom software development involving a contract often requires written software requirements. Consequently, it is only natural to create a requirement traceability matrix so we can prove that our application actually meets the requirements.

On the other hand, when software development happens in-house, work contracts are not required. In this case, user stories normally replace formal requirements.  Consequently, during agile development, we develop user stories in response to user input. In addition, user stories often change during development. Even when that happens, however, depending on the level of formality required by your company, you might still need to trace user stories to test cases. Modern tools like Prefix (which only supports Java and .NET) allow developers to create tests that respond quickly to requirements.

Do You Need a Requirement Traceability Matrix?

The answer really depends on your project. Frequently, software requirements constitute a formal work contract, which means that you most likely will need to develop a traceability matrix. On the other hand, when your development is in-house, agility becomes your main requirement, and investing time developing a complex requirement matrix would not be efficient. Instead, you might direct your resources toward automated testing, which responds to more fluid user requirements.

Leave a Comment