Requirement Traceability Analysis - QA Skill Library

Why this Skill

It turns this Skill's method into a quality input that can be executed, reviewed, and reused.

You need to check whether requirements have acceptance, design, implementation, test, and defect coverage.
Use RT-## finding IDs; each row includes requirement/control, source, linked artifact, relationship type, coverage status, evidence, and gap action.
Relationship types: direct, derived, indirect, contradictory, and missing.
Coverage statuses: complete, partial, unverified, stale, unexecuted, and unassessed.
Claiming coverage because a test filename or ticket link exists.

When to use

Use this Skill

You need to check whether requirements have acceptance, design, implementation, test, and defect coverage.
You need to find orphan requirements, orphan tests, broken links, stale artifacts, or missing evidence.
You need an auditable traceability matrix for release, change review, compliance, or risk governance.

Common pitfalls

Claiming coverage because a test filename or ticket link exists.
Building only a requirement-to-test matrix and missing orphan tests or unlinked defects.
Treating missing evidence as no issue, or treating a report's “passed” as execution proof.
Replacing stable IDs with similar titles and linking artifacts across versions or scopes.

Input

Minimum Input

The current task scope, objective, and subject under review.

Recommended Input

Project goal
Test scope
Constraints

Optional Context

Relevant code or configuration
Historical results
Logs and metrics

Output

The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.

Judge the output value before installing

01Input audit, scope, version, time window, and key assumptions are recorded
02Both requirement-to-artifact and artifact-to-requirement traceability are checked
03Every conclusion has source, evidence, relationship type, coverage status, and validation method
04Relationship types direct, derived, indirect, contradictory, and missing are separate from coverage statuses complete, partial, unverified, stale, unexecuted, and unassessed

View full output structure

05Static presence, report wording, and test names are not presented as execution results

How It Works

01Read and follow prompts/requirement-traceability-analysis.md; audit target, version, scope, time window, and input boundary first.
02Map requirements, acceptance, design, code, tests, defects, and evidence using stable identifiers, preserving source, version, and applicability.
03Keep relationship types direct, derived, indirect, contradictory, and missing separate from coverage statuses complete, partial, unverified, stale, unexecuted, and unassessed; never use one group as the other.
04When the task requests coverage_analysis or test-coverage-analysis, preserve bidirectional RT-## traceability and add a TC-## coverage view with test assets, coverage state, execution identity/time/environment, evidence quality, and orphan signals.
05Preserve orphan items, broken links, duplicate mappings, missing execution records, and name-only links with a gap, owner, next action, and validation method.
06Keep conclusions bounded by supplied material; execution, defect closure, and release claims require corresponding evidence.

Install & Quick Start

Install command / SHELL

npx skills add \
  https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-traceability-analysis
  -g

requirement-traceability-analysis.prompt

@skill requirement-traceability-analysis

Using the current project context, produce an actionable result following this Skill.

Additional context:
[Paste project context or requirement]

---
name: requirement-traceability-analysis
description: Use this skill when requirements, acceptance criteria, design, code, tests, defects, or evidence must be mapped bidirectionally and coverage gaps made explicit; triggers include requirement traceability, traceability analysis, and traceability matrix.
---

# Requirement Traceability Analysis

Build a bidirectional, auditable mapping from requirements or controls to acceptance criteria, design, code, tests, defects, and validation evidence. Keep relationship types separate from coverage statuses; never turn names, static presence, or report wording into execution results.

## When to Use

- You need to check whether requirements have acceptance, design, implementation, test, and defect coverage.
- You need to find orphan requirements, orphan tests, broken links, stale artifacts, or missing evidence.
- You need an auditable traceability matrix for release, change review, compliance, or risk governance.

Do not use it only to write test cases, execute tests, or decide business priority; this Skill analyzes the mappings and evidence supplied by the user.

## Output Format Options

- Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
- Do not present a structured format or static inventory as execution, pass, approval, or release evidence.

## How to Use

1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.

## Workflow

1. Read and follow `prompts/requirement-traceability-analysis.md`; audit target, version, scope, time window, and input boundary first.
2. Map requirements, acceptance, design, code, tests, defects, and evidence using stable identifiers, preserving source, version, and applicability.
3. Keep relationship types `direct`, `derived`, `indirect`, `contradictory`, and `missing` separate from coverage statuses `complete`, `partial`, `unverified`, `stale`, `unexecuted`, and `unassessed`; never use one group as the other.
4. When the task requests `coverage_analysis` or `test-coverage-analysis`, preserve bidirectional `RT-##` traceability and add a `TC-##` coverage view with test assets, coverage state, execution identity/time/environment, evidence quality, and orphan signals.
5. Preserve orphan items, broken links, duplicate mappings, missing execution records, and name-only links with a gap, owner, next action, and validation method.
6. Keep conclusions bounded by supplied material; execution, defect closure, and release claims require corresponding evidence.

## Core Constraints

- Use `RT-##` finding IDs; each row includes requirement/control, source, linked artifact, relationship type, coverage status, evidence, and gap action.
- Relationship types: `direct`, `derived`, `indirect`, `contradictory`, and `missing`.
- Coverage statuses: `complete`, `partial`, `unverified`, `stale`, `unexecuted`, and `unassessed`.
- In `coverage_analysis` mode, use `TC-##` for coverage views while preserving `RT-##` relationship findings; relationship types and coverage states remain separate.
- Check both directions: trace requirements downstream and trace tests/defects/evidence upstream; mark an item orphaned when no counterpart is found.
- Do not call a file, link, test name, report summary, or code presence executed, passed, fixed, or approved.
- When artifacts, stable IDs, versions, execution records, data, or environment are missing, mark `unassessed`/`unverified`/`unexecuted` and ask for evidence.
- Do not invent requirements, relationships, thresholds, owners, approvals, or runtime results; state the basis and close condition for recommendations.

## Reference Files

- Always read `prompts/requirement-traceability-analysis.md` before producing an analysis.
- Use `evals/eval.yaml` and `evals/cases/` to regress this Skill; configuration and static mappings do not prove real system execution.
- To check discovery behavior, run `scripts/run_skill_trace_eval.py` with `evals/trigger-prompts.csv` and `evals/local-rules.json`; missing `skill.selection` evidence is `BLOCKED`, not a trigger pass.
- This is a repository-root development check; a standalone Skill package does not include the repository runner and does not depend on it at runtime.
- To regress `test-coverage-analysis`, use the `coverage-*` Evals and a local trigger prompt containing “coverage analysis”; the target remains this physical Skill directory and no alias directory is created.

## Best Practices

- Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
- Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.

## Pre-delivery Checklist

- [ ] Input audit, scope, version, time window, and key assumptions are recorded
- [ ] Both requirement-to-artifact and artifact-to-requirement traceability are checked
- [ ] Every conclusion has source, evidence, relationship type, coverage status, and validation method
- [ ] Relationship types `direct`, `derived`, `indirect`, `contradictory`, and `missing` are separate from coverage statuses `complete`, `partial`, `unverified`, `stale`, `unexecuted`, and `unassessed`
- [ ] Static presence, report wording, and test names are not presented as execution results

## Common Pitfalls

- Claiming coverage because a test filename or ticket link exists.
- Building only a requirement-to-test matrix and missing orphan tests or unlinked defects.
- Treating missing evidence as no issue, or treating a report's “passed” as execution proof.
- Replacing stable IDs with similar titles and linking artifacts across versions or scopes.