Audit Evidence, Not Spreadsheets — How Links Explorer Replaces Your RTM Workflow

Overview

This document describes how Links Explorer enables regulated industry teams to generate audit-ready Requirements Traceability evidence directly from Jira — without maintaining separate spreadsheets, rebuilding matrices before each audit cycle, or exporting data to external tools.

It is intended for engineering leads, quality managers, and compliance owners who are responsible for producing traceability evidence under standards such as IEC-62304, DO-178C, ASPICE, or ISO 9001.

The Compliance Challenge

Why Traceability Matrices Fail in Practice

Every regulated engineering team maintains some form of a Requirements Traceability Matrix (RTM). The RTM is the artefact that connects what was required to what was built and how it was verified — the core evidence that auditors, notified bodies, and certification authorities examine.

In most teams, that RTM lives in Excel or a shared document. It was accurate when it was created. It is rarely accurate when it is needed.

The root cause is structural, not behavioural. Requirements change. Stories are split and closed. Test cases are added mid-sprint. The RTM is updated manually — by a person, on a schedule, as a separate task. Between that update and the next audit, work continues and the matrix drifts.

The result is predictable:

• Coverage gaps are discovered during audit preparation, not during development

• Engineering time is spent rebuilding the matrix from Jira exports rather than shipping work

• Auditors raise findings against gaps that were already closed — they just were not reflected in the evidence

This is not a people problem. It is a tooling problem. The matrix is maintained in a system that does not know what Jira knows.

The Standard Requirement

Most regulated frameworks require bidirectional traceability from requirements through implementation to verification evidence. The specific artefact names vary by standard, but the requirement is consistent:

The challenge is not knowing what is required. The challenge is producing evidence that reflects the current state of Jira without a manual rebuild step.

How Links Explorer Approaches This

Links Explorer does not introduce a new traceability layer on top of Jira. It reads the issue links your team has already created and generates a live traceability matrix from them on demand.

The core principle is that your Jira project already contains traceability — expressed as issue links between requirements, stories, test cases, and test execution results. Links Explorer makes that structure visible, navigable, and exportable as audit evidence.

There is no data migration, no configuration wizard, and no separate database to maintain. Install the app and your existing links are immediately traceable.

Generating a Requirements Traceability Matrix

Step 1 — Define the audit scope using JQL

Open Links Explorer from the Jira navigation. The first input is a JQL filter that defines the scope of your trace matrix. This can be a release version, a sprint, an epic, or any cross-project query that matches the scope of your compliance submission.

Example — Medical device release scope:

Example — Automotive ASPICE scope across two projects:

Example — Defence program-level scope:

The scope field accepts any valid JQL. Results update as you type. Once the scope is defined, the trace matrix is generated from live Jira data.

Open

Open

Step 2 — Review the full trace chain

The Traceability Report presents the complete chain for each requirement in scope. Each row expands to show all linked items across every level: requirement → implementation story → test case → test execution result.

The table is read from left to right, following the traceability chain from the source requirement through to verification evidence. Each linked item shows its issue key, summary, status, and link type.

For a medical device team following IEC-62304, a fully traced requirement looks like this:

Open

Step 3 — Identify coverage gaps

As the matrix generates, Links Explorer automatically flags requirements that are missing links at one or more levels of the chain. These are the gaps that become audit findings if left unresolved.

Orphan requirements — those with no downstream implementation or test links.

Open

Open

The gaps view answers the questions your auditor will ask before you are in the room with them:

• Which requirements have no implementation story linked?

• Which requirements have implementation but no test case?

• Which test cases have no execution result in this release?

Addressing gaps during development, not during audit preparation, is the workflow change that Links Explorer enables.

Exporting Audit-Ready Evidence

Once the matrix is reviewed and gaps are resolved, the RTM can be exported in a single step.

Export formats

The exported file includes all columns visible in the Traceability Report: Requirement ID, Requirement Summary, Implementation Status, Test Case, Test Case Status, and Test Execution Result. Export filenames include the JQL scope reference for traceability back to the exact query used to generate the evidence.

Open

Cross-Project Traceability

For programs where requirements and implementation are tracked across multiple Jira projects — Links Explorer supports cross-project and cross-instance dependency mapping.

A single Traceability Report can include issue keys from multiple project prefixes. This is particularly relevant for:

• Defence and aerospace programmes where system-level requirements (SYS-xxx) trace through to software-level requirements (SW-xxx) in a separate project

• Automotive ASPICE assessments where the system scope and the software scope are maintained by different teams in different Jira projects

• Medical device programmes with separate projects for hardware and software verification

Open

Saved Views for Recurring Audit Cycles

Most compliance programs follow a recurring audit schedule — quarterly reviews, release gate checks, or annual certification audits. Links Explorer Saved Views allow teams to configure a trace scope once and reload it for every cycle without re-entering the JQL.

Each Saved View stores:

• The JQL scope query

• The link types included in the trace chain

• The export format preference

Open