# Requirements Traceability

> Use when planning or auditing requirements traceability per ARP4754A: determine closure status across SRATS, high-level requirements (HLR), low-level requirements (LLR), code, and test levels, list traceability gaps for a level, flag derived requirements, and compute the verified-closure ratio of the trace matrix. Bidirectional closure (each level traces down and back up) and open verification items drive the closed/open verdict; all logic is deterministic, offline stdlib. Trigger: traceability, requirements, closure, SRATS, high-level requirements, low-level requirements, derived requirements, verification, trace matrix.

- Skill: `ashfordeou/requirements-traceability` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ashfordeou/requirements-traceability`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashfordeou/requirements-traceability/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: ashfordeOU (https://skillmd.com/u/ashfordeou)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashfordeou/requirements-traceability

---


# ARP4754A Requirements Traceability (systems-engineering-safety/arp4754a/requirements-traceability)

Use when the task is requirements traceability per ARP4754A:
determining closure across the SRATS-to-test chain, listing
traceability gaps, flagging derived requirements, and measuring
verified-closure of the trace matrix.

## Domain quick reference

- ARP4754A development assurance runs on traceability: system
  requirements (SRATS) trace to high-level requirements (HLR), HLR
  trace to low-level requirements (LLR), LLR trace to code and test.
- Closure is bidirectional per level: every HLR has an incoming SRATS
  trace and an outgoing LLR trace; every LLR has an incoming HLR trace
  and an outgoing code or test trace.
- A traced pair with verification still open is an open verification
  item and keeps the closure status open.
- Derived requirements (requirements whose content is not directly
  traceable to a parent source) must be explicitly flagged.
- Verified-closure ratio = verified traces / total traces (0..1).

## Workflow

1. Collect the trace matrix as (from, to, verified) links.
2. Determine closure status and review the gap list.
3. Focus on one level (srats/hlr/llr/code/test) for triage.
4. Flag derived requirements explicitly.
5. Track the verified-closure ratio as evidence of closure progress.

## Pitfalls

- One-directional closure treated as closure (HLR down but no SRATS
  back-up).
- Verification status ignored (open items left in a 'closed' claim).
- Derived requirements unflagged and treated as top-level.
- Ratio reported without the gap list (a high ratio can still hide
  missing coverage).

## Behavior contract (gate 3)

The logic is exercised by the gate 3 contract test:
scripts/test_requirements_traceability.py against
scripts/requirements_traceability_logic.py (stdlib unittest, offline).
Run: python3 scripts/test_requirements_traceability.py

## Compliance

- Standards referenced, not reproduced: ARP4754A / ARP4761A text is
  proprietary (SAE); summary-only per standards-map.yaml and brief 06.
- Revision note: ARP4754B (2023) supersedes ARP4754A; this skill keys
  to ARP4754A as the certification-baseline revision (FAA AC 20-174
  cites A); see standards-map.yaml arp4754a.revision_decision.
- compliance: STANDARDS-REF, gated: false.