Trace Change Impact Across Every Linked Issue — Impact Analysis in Links Explorer

Overvie

This document explains how Links Explorer maps the impact of a change across every linked issue in your Jira project — upstream to the requirements and specifications that define the changed item, and downstream to the stories, tasks, and test cases that depend on it.

It is intended for engineering leads, quality managers, and configuration control teams who need to assess the scope of a change before implementing it, submitting a change request to a review board, or updating a compliance package.

The capability described here is impact analysis: selecting any issue in Jira and generating a complete upstream and downstream dependency map from the existing issue links — without opening each linked issue individually.

Why Change Impact Matters in Regulated Development

In regulated environments, changes to requirements, designs, or safety-critical items are not standalone decisions. Every change has a chain of consequence: upstream items that constrained the changed issue, and downstream items that must be reviewed, re-implemented, or re-tested as a result of the change.

Standards that govern regulated development formalise this requirement:

In practice, the challenge is producing this analysis from Jira without spending hours manually tracing dependencies project by project. A Change Control Board (CCB) submission that relies on a partial or manually assembled impact list is an audit risk. An undetected downstream dependency that was not re-tested after a requirement change is a certification failure.

How Impact Analysis Works in Links Explorer

When a requirement, design item, or story is selected in Links Explorer, the impact analysis view traverses the issue link graph in both directions from that issue.

Upstream traversal follows the links from the selected issue back toward the source: the parent requirement, the system specification it implements, the safety goal it derives from. Upstream items define the intent and scope of the selected issue. A change to the selected issue may require these upstream items to be reviewed and their own downstream items to be re-assessed.

Downstream traversal follows the links from the selected issue forward toward the evidence: implementing stories, sub-tasks, linked test cases, and test execution results. These are the items that will need to be reviewed, updated, or re-executed as a consequence of the change.

Both directions are traversed recursively. If a downstream story has its own linked test cases, and those test cases have linked test results, LXP traverses all of them — not just the first level.

The result is a complete impact map generated from the link graph already in Jira, at the moment the view is opened.

Open

Reading the Impact View

The impact view is structured around the selected issue as the root.

Items represent the intent behind the selected issue. If the selected issue is a software requirement, the upstream items are the system requirements, safety goals, or specifications from which it was derived.

Items are the direct consequences of the change. For a software requirement, downstream items typically include implementing stories, linked test cases, and test execution results.

Open

Open

Using Impact Analysis for CCB Submissions

A Change Control Board submission typically requires the proposing team to document:

1. The item being changed and a description of the change

2. The upstream requirements and specifications that authorise or constrain the change

3. The downstream items — stories, tests, modules — that will be affected and must be reviewed or re-tested

4. A plan for verifying that the affected downstream items are updated and re-validated before the change is closed

LXP's impact analysis view addresses items 2 and 3 directly. The upstream and downstream lists are generated from the existing Jira links — not manually assembled.

Example workflow for a DO-178C CCB submission:

1. A change is proposed to Product Requirement PRD-178

2. Open LXP impact analysis on PRD-178

3. The upstream panel shows the Regulatory Requirement (SRS-042) that PRD-178 derives from — confirming whether the change is within the original SRS scope or requires an SRS change as well

4. The downstream panel shows the verification and risk linked to PRD-178 — the complete set of items that must be reviewed and re-tested

5. The total affected item count is visible in the sidebar

6. The impact map is exported as evidence for the CCB package

Open

Cross-Project Impact

In programs where requirements and implementation are distributed across multiple Jira projects, a change in one project has downstream consequences in another. LXP traverses these cross-project links in the same impact view.

This is particularly relevant for:

• Defence and aerospace programmes where system-level and software-level requirements are owned by different teams in separate Jira projects and linked across project boundaries

• Automotive ASPICE assessments where the system scope and software scope are maintained by different project teams

• Medical device programmes with separate hardware and software verification projects that share requirement links

Open

Filtering and Scoping the Impact View

By default, the impact view traverses all link types connected to the selected issue. In projects with many link types — including relates to, blocks, duplicates, and compliance-specific custom types — the full traversal may include items that are not relevant to a specific change assessment.

The impact view can be filtered to include only the link types relevant to the assessment:

• Include only implements and is tested by links to trace the implementation and verification chain

• Include only is derived from links to trace the requirements derivation chain

• Exclude relates to links to remove informational cross-references from the impact count

Filtered impact views can be saved as named Saved Views and reused for recurring change assessment workflows — for example, a saved view named "CCB Impact — Requirements Chain" that includes only the link types relevant to a CCB submission.

Open

Open

Standards-Specific Impact Chains

The structure of the impact chain differs by standard. The table below describes the upstream and downstream traversal relevant to each regulated framework.

DO-178C — Change impact for software requirements

For a change to a Software Requirement:

• Upstream: High-Level Requirement (HLR) → Mission/Capability Need

• Downstream: Low-Level Requirements (LLRs) → Source Code Stories → Test Procedures → Test Results

All downstream items must be reviewed for impact. Those affected must be re-tested and re-verified before the change is closed.

IEC 62304 — Software change impact assessment

For a change to a software unit:

• Upstream: Software Requirement (SRS) → System Requirement

• Downstream: Implementation Stories → Unit Tests → Integration Tests → Verification Records

IEC 62304 requires that previously completed V&V activities affected by the change are identified and re-performed. The downstream panel provides the list.

ISO 26262 — Safety-related change impact

For a change to a safety goal or HARA item:

• Upstream: Vehicle-level hazard → Accident scenario

• Downstream: Functional Safety Concept → System Requirements → Software Requirements → Validation Tests

ISO 26262 requires that changes to safety goals are propagated through the full safety case. The impact view shows the full propagation path.

ASPICE — Requirement change impact

For a change to any baselined requirement:

• Upstream: Stakeholder requirement → Customer need

• Downstream: System requirement → Software requirement → Design element → Test case

ASPICE change management (MAN.5) requires that impact is assessed before implementation begins. The impact view is the assessment artefact.

Exporting Impact Evidence

The impact view can be exported as structured evidence for a CCB package, a change management record, or an audit submission.

The export includes:

• The root issue (the changed item)

• All upstream items with their link type and current status

• All downstream items with their link type, level in the chain, and current status

• Total affected item count

• Generation timestamp

Open

Open