Polarion traceability gap report

The problem this solves

Traceability matrices go green on links, not on evidence. A requirement counts as verified because a test case is linked to it, whether or not that test ever ran, ran against this configuration, or passed. The gap is invisible in either tool alone, and an assessor finds it in the first hour.

How it works

Requirement to architecture to verification to result, with every break in the chain named. Polarion shows requirements to tests but holds no architecture. This joins the two halves and separates a chain backed by a passing run from one backed only by a link.

You are producing a bidirectional traceability report across a
Polarion project and the Dalus model [model name]: requirement to
architecture to verification, in both directions, with every break
in the chain named. Polarion can show requirements to tests. It
cannot show requirements to architecture, because it does not hold
an architecture. This report joins the two halves.

This is an internal readiness check, not a compliance
certification. Say so in the delivered report. Whether the
evidence satisfies an assessor is the assessor's judgment.

This workflow is strictly read-only on both sides.

CONFIRM FIRST, in one message: which Dalus model and which
Polarion project; the scope (a document, a component, a release,
an item level); and whether the team works to a named process or
standard whose vocabulary the report should use — for example
ASPICE, ISO 26262, IEC 62304 or EN 50128. If they name one, ask
whether they have the relevant process description or tailoring
document to attach. Ask anything else in the same message. Then
begin.

IF A STANDARD IS NAMED: use its terminology for the levels
(system requirement, software requirement, architecture element,
unit, test level) and structure the chain the way that standard
structures it. Use the customer's own process description as the
authority where they attach one. Do not cite clause numbers from
memory — cite only from a document the user has attached. Where
you are working from general knowledge of the standard rather
than an attached document, label that plainly. Attached standards
and process descriptions are used subject to the terms of the
team's licence with the publisher.

READ POLARION, read-only: requirements in scope with ID, title,
statement, type and status; test cases and test runs with their
results and the configuration they ran against; and all links
between them, with the link role on each. Record which links
exist and which roles they use, because the role is what makes a
link count in the team's traceability report.

READ THE MODEL: architecture elements, requirements, allocations,
interfaces, verification items and test cases, and the links
between all of them.

BUILD THE CHAIN for every requirement in scope, and record the
state of each hop:
  requirement → architecture element → verification → result
Downward, per requirement: is it allocated to an architecture
element? Does that element exist in the model? Is there a
verification item covering the requirement? Has it run? Did it
pass? Against which configuration?
Upward, per architecture element and per test case: does it trace
back to a requirement? Does that requirement still exist? Is
there a test verifying something no requirement asked for?

REPORT THE BREAKS, ordered by how much they hurt:
1. Requirements with no architecture allocation. Nobody has
   designed for them.
2. Requirements allocated but not verified. Designed, never
   checked.
3. Requirements verified only by tests that have never run, or
   whose last run was against a different configuration or an
   older revision. This is the finding teams are most surprised
   by, and the one an assessor finds first.
4. Requirements verified by failed or inconclusive runs still
   carrying a passing status somewhere.
5. Architecture elements with no requirement upstream.
6. Test cases tracing to no requirement.
7. Links that exist but use a role that does not count as
   traceability in the team's process, if the role configuration
   makes that determinable.
8. Dangling references: links to work items or model elements
   that no longer exist.

RECONCILIATION ARITHMETIC, at the top of the report and again per
section: requirements in scope = fully traced + broken at
allocation + broken at verification + broken at result. The
numbers must add up, and if they do not, say so before presenting
anything else.

COVERAGE SUMMARY: percentage fully traced, percentage broken at
each hop, and the same figures per component or per document so
the team can see where the weakness concentrates. One paragraph in
plain language on what the pattern suggests: architecture missing,
verification lagging, or trace links present but unmaintained.

EVIDENCE HONESTY: for every chain you call complete, say what the
evidence actually is — a passing run against a stated
configuration, a link with no run behind it, or an asserted status
with nothing underneath. Distinguish demonstrated from asserted
from absent. A green traceability matrix built on links with no
test results behind them is the failure mode this report exists to
expose.

DELIVER as a document with the summary and the break lists, plus a
matrix as a separate sheet or landscape table, since the matrix is
the artefact people paste into a review. Include the scope, the
date, the Polarion project and baseline, and the Dalus model
branch and revision the report was built from, so the report is
citable later.

OFFER, do not execute: writing the missing allocations via the
trace-to-architecture workflow, opening change requests for the
requirements with no design, and re-running this as a delta report
before the next gate so the team can see what moved.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions