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.
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.
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:
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.
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.
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.
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.
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.
A requirement traceability matrix has four basic components: requirement identifier, requirement summary text, test case identifier, and test case status.
| Requirement ID | Requirement Title | Test Cases | Test Case Status |
| 1.1 | Successful login | TC 1.1 | pass |
| 1.2 | Login requires user name & password | TC 1.1 TC 1.3 | pass fail |
| 1.3 | Block invalid login | TC 1.2 TC 1.3 | pass fail |
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 ID | Category | Requirement Title | Test Cases | Run 1 Status | Run 2 Status |
| 1.1 | Login | Successful login | TC 1.1 TC 1.3 | pass fail | pass pass |
| 1.2 | Login | Login requires username & password | TC 1.1 TC 1.3 | pass fail | pass pass |
| 1.2 | Login | Block invalid login | TC 1.2 TC 1.3 | fail fail | pass pass |
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.
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.
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.
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.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
