Arc Skills / Verification and validation
Build a requirements verification matrix
Use Arc Skills to map requirements to proposed verification methods, acceptance criteria and evidence. The matrix separates missing plans, missing results and configuration gaps so a planned activity is never mistaken for an accepted outcome.
Use this skill
Use Arc Skills to build a requirements verification matrix.
Inputs:
- Requirements with IDs, wording and revisions
- Planned verification activities and acceptance criteria
- Test results, evidence references and configurations, where available
Return one entry per requirement with method, criterion, activity, configuration, evidence status, gap and owner. Reconcile the input IDs. Distinguish proposed methods from approved plans and executed results.
Keep unknown test IDs, values and decision rules unresolved rather than inventing them.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Controlled requirement scope | Identify every obligation and revision | Reconciled matrix entries |
| Plans and acceptance criteria | Assign a defensible verification route | Methods and planning gaps |
| Results and tested configurations | Assess evidence support separately | Missing, applicable and unresolved evidence |
Keep requirements, plans and results distinct
Synthetic inputs: the same four requirements used in the cleanup example and one test-evidence record for REQ-003. The source CSV provides no controlled revision identifiers. The separate evidence fixture supplies revision B for REQ-003 only.
Download the four requirements · Download the synthetic timing evidence
A verification matrix that exposes the gaps
| Requirement / revision | Proposed method and criterion | Activity / configuration | Status and gap |
|---|---|---|---|
| REQ-001 / Not supplied | Test (proposed). Calibrated frame delivery rate ≥2 Hz during imaging; measurement window and configuration to be approved. | No approved activity supplied. Not supplied | Planned method only. No approved activity or executed evidence; measurement window missing. |
| REQ-002 / Not supplied | Test (proposed). Each calibrated frame produced within 400 ms during imaging; start/end events to be defined. | No approved activity supplied. Not supplied | Planned method only. No approved activity or executed evidence; timing events missing. |
| REQ-003 / B (synthetic evidence input) | Test (proposed). Detected sensor fault reported within 100 ms; apply agreed uncertainty decision rule. | TEST-03, procedure revision 2 (supplied synthetic evidence). Evidence: firmware 1.2; required: firmware 1.3 with modified fault filter | Cannot close verification. 98 ms with bounded ±5 ms spans 93–103 ms; no decision rule and configuration applicability unresolved. |
| REQ-004 / Not supplied | Not selected. Cannot define from “appropriate warning quickly”. | No approved activity supplied. Not supplied | Requirement clarification needed. Missing trigger, warning, recipient and latency; no planned activity or evidence. |
Count reconciliation: 4 input requirement IDs → 4 distinct matrix entries. Three have tentative methods; one needs clarification before method selection. No requirement has been closed as passed. A proposed method is not an approved verification plan.
Why 98 ms is insufficient to close a 100 ms requirement
The synthetic TEST-03 record measures 98 ms with bounded uncertainty of ±5 ms. The resulting interval is 93–103 ms, spanning the 100 ms limit. No acceptance decision rule is supplied. It is therefore inappropriate to label the result passed solely because 98 is below 100.
The test also used firmware 1.2, while the required configuration is firmware 1.3 with a modified fault filter. The engineer must resolve uncertainty handling and evidence applicability or plan targeted re-verification. This does not establish that the current product fails.
Plan coverage, then assess evidence independently
- Preserve requirement IDs and revisions, splitting compound obligations where coverage needs separate evidence.
- Choose methods and acceptance criteria from the actual behavior and supplied project rules.
- Keep approved activities, executed results and configuration applicability in separate fields.
- Reconcile all in-scope IDs and give each missing decision or evidence gap an owner action.
Sources and further reading
- NASA handbook: requirements verification matrix: background on planning verification against requirements.
- Timing evidence fixture: the configuration and uncertainty inputs used here.
- RTM and verification matrix guide: how trace and verification planning differ.
Synthetic inputs and authored reference matrix, checked on 3 October 2026. Three methods are tentative; the supplied timing evidence does not resolve acceptance.