Skill Hub — Decision & Validation

Traceability Matrix Drafting Working Skill

Map every requirement from its origin through design, test, and release so that gaps, orphans, and untested requirements are visible before they become production defects.

What this skill is for

A requirement that cannot be traced to a test is a requirement that may never be verified. A test that cannot be traced to a requirement is waste. This skill creates and maintains traceability matrices that link requirements to their sources, design artifacts, test scenarios, and release packages. The matrix becomes a diagnostic tool: it reveals orphan requirements with no tests, orphan tests with no requirements, and gaps where design or implementation is missing. It also provides the evidence auditors and release managers need to confirm that every approved requirement has been addressed.

When to use this skill

Requirements are approved and need to be tracked through design, build, and test.
A requirement changes mid-project and you need to know which design documents, test cases, and code modules are affected.
Test planning starts and you need to measure coverage: which requirements have tests and which do not.
An audit or compliance review asks for evidence that all requirements were tested before release.
A release is scoped and you need to bundle only the requirements, tests, and transports that belong together.
A production defect occurs and you need to trace it back to the requirement it violates.

Real work situations

SAP S/4 upgrade: order-to-cash process changes

An upgrade project changes pricing procedures, delivery blocks, and billing routines. The traceability matrix maps each business requirement to the SAP functional design document, the configuration change in the transport request, the test scenario in the test tool, and the release package. Without the matrix, a pricing requirement is implemented but never tested because the test team did not know it changed. The transport reaches production and pricing errors appear on the first invoice run.

Integration project: e-commerce to SAP IDoc flow

A new e-commerce channel sends orders to SAP via IDoc. The matrix maps the business requirement "orders must create within 5 minutes" to the interface design document, the mapping specification, the IDoc test scenario, the monitoring alert configuration, and the go-live release. Without the matrix, the monitoring alert is built but never linked to the requirement, so when the alert fires in production, no one knows which requirement it validates or who owns the response.

Regulatory compliance: customer master data validation

A tax regulation requires that customer tax numbers be validated before invoice creation. The matrix maps the regulatory source to the validation rule in the business rules catalog, the MDG change request configuration, the test scenario for invalid tax numbers, and the audit report. Without the matrix, the audit cannot demonstrate that the requirement was tested, and the organization faces compliance penalties.

Inputs required

Approved requirements list with unique IDs and source references.
Design documents: functional specifications, configuration guides, interface mappings, workflow definitions.
Test plan or test scenario set with IDs and descriptions.
Release plan or transport list showing what will be deployed and when.
Source documents: stakeholder requests, regulatory texts, defect reports, change requests.
Tool selection: spreadsheet, ALM tool (Jira, Azure DevOps), or simple Markdown table.
Change log or version history of requirements, designs, and tests (if available).

Questions to ask

Which requirement has no design artifact? Who will create it?
Which requirement has no test scenario? Is it untested or was the test never written?
Which test scenario does not trace to any requirement? Is it an orphan test or a missing requirement?
Which design change affects which requirements, and have the related tests been updated?
Which requirements are included in the upcoming release, and do they have complete traceability chains?
Which requirements were deferred, and are they excluded from the current release traceability?
What is the minimum viable traceability: source → requirement → test → release, or do we need more dimensions?

Working method

List all requirements. Create a column with requirement IDs and short descriptions. Include status: approved, deferred, or changed.
Identify traceability dimensions. Decide which columns you need. Minimum: Source → Requirement → Design → Test → Release. Add columns for Owner, Priority, or Compliance if needed.
Map requirements to sources. For each requirement, link to the stakeholder request, regulation, defect, or change request that originated it. If a requirement has no source, flag it as orphan.
Map requirements to design. For each requirement, link to the functional specification, configuration document, or code module that implements it. If a requirement has no design, flag it as unimplemented.
Map requirements to tests. For each requirement, link to the test scenario or test case that verifies it. If a requirement has no test, flag it as untested.
Map requirements to releases. For each requirement, link to the release package, transport request, or deployment plan that contains it. If a requirement is approved but not assigned to a release, flag it as unscheduled.
Identify gaps and orphans. Scan the matrix for empty cells, broken links, and mismatches. Produce a Gap Report with severity and owner.
Establish change control. When a requirement changes, update all downstream links. When a test is added, link it to the requirement. When a release is scoped, verify all included requirements have complete chains.
Maintain and review. Update the matrix within one business day of any change. Review the matrix weekly for gaps and stale entries.

Decision rules

If a requirement has no test, flag it as untested and block release until a test is defined.
If a test has no requirement, flag it as orphan: either remove the test or add the missing requirement.
If a requirement changes, update all downstream links (design, test, release) before the next review.
If a release excludes a requirement, document the deferral and remove the requirement from the release traceability.
If a source document is updated, verify that linked requirements are still valid and update if not.
If the matrix has more than seven dimensions, consider splitting into multiple matrices to avoid unreadability.
If a requirement is approved but has no design or release assignment, it is not ready for build.

Deliverables

Traceability Matrix — Table or tool artifact linking requirements to source, design, test, and release. See template below.
Gap Report — List of orphan requirements, orphan tests, missing design links, and untested requirements with severity and owner.
Orphan Register — Running list of items that were removed from the matrix and why, for audit trail.

Templates

Traceability Matrix (Markdown compact)

---
artifact: Traceability Matrix
id: TM-001
project: <Project Name>
dimensions: Source, Requirement, Design, Test, Release
last_updated: YYYY-MM-DD
---

| Req ID | Requirement | Source | Design Doc | Test Scenario | Release | Status | Owner |
|--------|-------------|--------|------------|---------------|---------|--------|-------|
| REQ-001 | <Short description> | SRC-001 | FSD-001 | TS-001 | REL-1.0 | complete | <Name> |
| REQ-002 | <Short description> | SRC-002 | — | TS-002 | REL-1.0 | missing design | <Name> |
| REQ-003 | <Short description> | — | FSD-003 | TS-003 | REL-1.0 | orphan source | <Name> |
| REQ-004 | <Short description> | SRC-004 | FSD-004 | — | REL-1.0 | untested | <Name> |

## Gap Report

### Untested Requirements
- REQ-004: <description>. Action: <what to do>. Owner: <name>. Due: <date>.

### Orphan Tests
- TS-005: <description>. No linked requirement. Action: remove or add requirement. Owner: <name>.

### Missing Design Links
- REQ-002: <description>. No design document. Action: create FSD. Owner: <name>. Due: <date>.

## Change Log
| Date | Change | Affected Req IDs | Updated By |
|------|--------|------------------|------------|
| YYYY-MM-DD | <description> | REQ-001, REQ-002 | <Name> |

Traceability Matrix (spreadsheet compact)

Columns: Req ID | Requirement | Source ID | Source Type | Design Doc | Test ID | Release | Status | Owner | Gap Notes

Status values: complete | missing design | untested | orphan source | orphan test | deferred

Use conditional formatting to highlight: untested (yellow), orphan (red), complete (green).

Quality checklist

Every approved requirement traces to at least one source document or stakeholder request.
Every approved requirement traces to at least one design artifact or implementation item.
Every approved requirement traces to at least one test scenario or test case.
Every approved requirement traces to a release or deployment package.
No test scenario exists without a linked requirement, unless it is explicitly labeled as regression or exploratory.
The matrix is updated within one business day of any requirement, design, or test change.
All gaps are documented in a Gap Report with severity, owner, and due date.

Common mistakes

Creating the matrix after testing is complete. Consequence: the matrix is a backward-looking record, not a planning tool. Gaps are discovered too late to fix.
Not updating the matrix when requirements change. Consequence: the matrix becomes stale, tests verify outdated requirements, and release scope is unclear.
Adding too many dimensions. Consequence: the matrix becomes unreadable and maintenance is abandoned. Seven columns is usually the practical maximum.
Treating traceability as a one-time documentation task. Consequence: the matrix is accurate on day one and wrong by day ten. Traceability is a living artifact.
Not linking to the actual artifact IDs. Consequence: the matrix says "see FSD" but does not name the document, so no one can find it.

Weak output vs Strong output

Weak output

A sparse table with vague references and no status: "Requirements are linked to designs and tests where applicable. Most requirements have coverage. Some gaps exist in the test area. The matrix is stored in the project folder." No requirement IDs, no test IDs, no release IDs, no gap owners, no due dates.

Why it fails: Cannot be used for planning, auditing, or release scoping. No one can find the artifacts. No one is accountable for gaps. The matrix is a decorative document.

Strong output

---
artifact: Traceability Matrix
id: TM-S4-O2C-2026-001
project: S/4 Order-to-Cash Enhancement
last_updated: 2026-06-12
---

| Req ID | Requirement | Source | Design Doc | Test Scenario | Release | Status | Owner |
|--------|-------------|--------|------------|---------------|---------|--------|-------|
| REQ-101 | Credit limit block at 50k EUR | CR-2026-044 | FSD-101 | TS-101, TS-102 | REL-2.3 | complete | A. Kumar |
| REQ-102 | Emergency order bypass | CR-2026-044 | FSD-102 | — | REL-2.3 | untested | A. Kumar |
| REQ-103 | Incompletion procedure for incoterms | DEF-2025-891 | FSD-103 | TS-103 | REL-2.3 | complete | M. Chen |
| REQ-104 | Delivery block for incomplete orders | DEF-2025-891 | — | TS-104 | REL-2.3 | missing design | R. Patel |

## Gap Report — 2026-06-12

### Critical
- REQ-102 (Emergency order bypass): approved but no test scenario. Blocks REL-2.3. Action: create TS-105 by 2026-06-14. Owner: A. Kumar.
- REQ-104 (Delivery block): approved but no design document. Blocks REL-2.3. Action: create FSD-104 by 2026-06-15. Owner: R. Patel.

### Major
- TS-201 (Pricing check): no linked requirement. Orphan from REL-2.2. Action: verify if still needed or remove. Owner: M. Chen. Due: 2026-06-13.

Agent instructions

AI Prompt Pattern

Role: Traceability analyst for an enterprise SAP project.

Context: You have an approved requirements list, design documents, test scenarios, and a release plan. You need to build or update a traceability matrix.

Task: Create a Traceability Matrix linking requirements to source, design, test, and release. Identify gaps and orphans. Produce a Gap Report with severity and owner.

Output format: Markdown table with columns: Req ID, Requirement, Source, Design Doc, Test Scenario, Release, Status, Owner. Follow with a Gap Report section.

Always use actual artifact IDs. Do not write "see FSD." Write "FSD-101."
Flag every empty cell. An untested requirement is not "mostly covered." It is untested.
Update the matrix when requirements change. Do not produce a static snapshot. Include a change log.
Keep dimensions practical. Do not add more than seven columns. Split complex matrices by domain or release.
Do not invent artifacts. If a design document does not exist, flag it as missing. Do not make up an ID.
Link to Atlas diagnostics when requirements touch SAP processes. For example, order-to-cash requirements should reference Delivery Billing Block Order-to-Cash Delays for process context.

Related skills

Requirements Elicitation Working Skill — Use to produce the requirements list that feeds the matrix.
Acceptance Criteria Working Skill — Use to define the test scenarios that trace to requirements.
Test Scenario Derivation Working Skill — Use to create the test scenarios that populate the Test column.

Related Atlas pages

SAP Process Audit — Diagnostic context for linking requirements to actual process behavior and system checks.
Delivery Billing Block Order-to-Cash Delays — Scenario with traceability from business pain to process touchpoints and system checks.

Verification status and limitations

This skill is a public working interpretation of traceability practices. It is not official IEEE, CMMI, or SAP documentation. It focuses on practical traceability for enterprise projects where requirements must be demonstrably tested before release.

Known limitations: the skill assumes requirements have unique IDs and that design and test artifacts exist or can be created. It does not cover automated traceability extraction from code repositories or test automation tools. It does not address regulatory traceability for safety-critical systems or medical devices.