Requirements Traceability Matrix: From Requirements to Verification in Jira

Requirements are the backbone of every software project. They define what needs to be built, why it matters and how its success will be measured. When it comes to the highly regulated industries, such as pharmaceuticals, medical devices, or finance - the stakes for requirements are even higher. In these areas, they act not only as guidelines for developers, but as formal evidence of compliance as well. If requirements are poorly defined or not properly verified, the cost of failure can be high, both in financial and reputational terms.

That’s where traceability comes in: the ability to follow every requirement through to the tests that verify it. This article explains what a requirements traceability matrix is, shows an example, and walks through how traceability works in regulated projects and in Jira.

The GAMP 5 Life Cycle Approach

The GAMP 5 framework (Good Automated Manufacturing Practice) highlights the importance of requirements within a life cycle approach. One of its key diagrams – Specification, Design, and Verification - illustrates how requirements move through each stage of system development:

• Specification: defining what the system must do.
• Design: translating specifications into a technical solution.
• Verification: ensuring the design meets the original requirements through testing.

This model emphasizes that traceability can’t be optional. It is the link that ensures every requirement is addressed in design and verified through tests. Without this closed loop, organizations cannot demonstrate that systems are fit for purpose or compliant with standards.

Requirements in Agile and Jira

Modern software development often follows Agile principles, where requirements are expressed more dynamically than in traditional models. Instead of large requirement documents, Agile teams capture business needs in tools like Jira. A tool like this suggests a specific structure, where:

• Epics represent broad goals or business capabilities.
• Stories break these goals into actionable tasks, focusing on user value.

This arrangement supports rapid delivery, however it also introduces challenges as byproducts. With the growing number of Epics and Stories, teams may lose visibility into whether each requirement is being tested and validated. In such cases, requirement traceability becomes particularly critical.

Traceability in GAMP 5 Framework

GAMP 5 underlines that every requirement, whether functional, non-functional or regulatory, should be linked to verification activities. Traceability matrices, coverage analysis and impact assessments – they all stem from this principle.

From a tester’s perspective, traceability answers these fundamental questions:

• Has every requirement been tested?
• Which tests prove compliance with specific requirements?
• What is the impact of changing or removing a requirement?
• If a test fails, which requirement is at risk?

By providing answers to these questions, traceability not only safeguards compliance, but also builds confidence in the overall quality of the system.

What Is a Requirements Traceability Matrix?

A requirements traceability matrix (RTM) is a table that maps each requirement to the test cases that verify it, the results of those tests, and any defects found. It shows at a glance which requirements are tested, which passed, and which have no tests at all.

Here’s a simple example:

The matrix immediately shows two risks: REQ-102 has a failing test and an open defect, and REQ-103 has no test at all.

Types of Traceability

• Forward traceability follows each requirement to its tests. It answers: has every requirement been tested?
• Backward traceability follows each test back to a requirement. It answers: does every test have a purpose, or are some tests “orphaned”?
• Bi-directional traceability combines both. It’s what regulated projects usually need, because it also shows the impact of changing or removing a requirement.

The Role of Traceability Reports in Jira

Jira gives you the building blocks for traceability: Epics, Stories, and work item links. On their own, they produce a list of links rather than a matrix. Appsvio Test Management (ATM) adds Test Cases, Test Plans, and Test Executions to Jira as work items. Test Cases link to your requirements, and failed executions link to the bugs you already track in Jira.

As it’s built on Atlassian Forge, ATM is the only Jira test management app with the Runs on Atlassian badge, so your test data stays within Atlassian’s infrastructure, with no data egress.

Most importantly, ATM includes a Traceability report, which works as a requirements traceability matrix in Jira. It follows each requirement through its Test Cases and Test Case Executions to defects, highlights requirements with no tests, and lets you narrow the scope with JQL, for example to one release or to high-priority requirements. You can add up to three extra fields each for requirements, Test Cases, and defects, and export the report to PDF or CSV for audits.

In practice, this means that the critical questions raised by GAMP 5 can be answered directly in Jira, without external spreadsheets or disconnected tools.

Why Does Traceability Matter to QA Teams?

To summarize, traceability is more than a compliance checkbox. It supports better decision-making by providing insight into project health. Teams can quickly identify gaps in testing, assess the impact of changes and demonstrate accountability to stakeholders.

By combining the structured perspective of GAMP 5 with Agile practices in Jira and leveraging tools like ATM, organizations can achieve both compliance and agility. The result is software that not only meets user expectations but also passes the rigorous test of regulatory scrutiny.

Sources:

1. Wyn Sion, GAMP 5 – Enabling Innovation, Pharmaceutical Engineering 28, no. 1(January/ February 2008), p. 3.