Arc Skills / Requirements
Check whether a requirement is verifiable
Arc Skills reviews requirement wording against the intended article and available evidence route. It returns a verifiability verdict, exact blockers, and the smallest useful criterion or wording proposal.
Use this skill
Use Arc Skills to check whether the supplied requirements are verifiable.
Inputs:
- Requirement IDs, exact statements, revision, and controlled definitions
- Intended product boundary, article or model, and available observations
- Existing acceptance criteria and verification context
Return a per-requirement verdict, shortest credible evidence route, exact blocker, and minimal proposal.
Separate missing wording from missing test resources. Preserve the originals and leave unsupplied limits openWhat you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Controlled statements | Identifies actor, condition, response, and limit | Verifiability verdict |
| Definitions and criteria | Resolves event and observable boundaries | Specific wording or criterion gap |
| Article and access | Shows whether evidence can be gathered at this level | Plausible verification route |
Readable display versus timed fault indication
Illustrative engineering example.
Two illustrative display requirements are assessed on a Controller C2 prototype. A working screen is available, but the fault-detection timestamp source has not been defined.
R-1: The display shall be easy to read.
R-2: The display shall show fault code F within 1 s of fault detection.| Requirement | Verdict and shortest route | Exact blocker / proposal |
|---|---|---|
| R-1 | Not yet verifiable; human inspection or usability trial possible later | No reader, task, lighting, or pass boundary. Define those from approved use conditions. |
| R-2 | Conditionally verifiable; timed functional test | Fault detection start event and timestamp source undefined; retain the 1 s limit. |
| R-2 timing | Screen inspection alone is insufficient | A code visible at an arbitrary instant cannot demonstrate elapsed time ≤1 s. |
R-1 is understandable in ordinary language but gives two assessors no common decision boundary. R-2 contains a bounded observable outcome, so it needs event instrumentation rather than a new performance limit.
The third row explains method suitability for R-2 rather than counting another requirement. If the prototype lacks timestamp access, that is an evidence-resource issue; once the event is defined, the statement may still be sound.
Find the decisive observation
- Identify subject, trigger or state, observable response, and comparator in each statement.
- Check controlled definitions for terms that shift the pass boundary.
- Name a plausible inspection, analysis, demonstration, or test on the intended article.
- Distinguish missing requirement content from unavailable equipment or configuration.
Questions about this task
Does an existing Test link make a requirement verifiable?
No. A Test can be linked while missing the criterion or condition needed to decide the obligation.
Must every qualitative requirement be rewritten numerically?
No. Some attributes are inspectable with agreed qualitative criteria. Add numbers only when project intent supplies them.
Sources and further reading
- NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.
- ECSS-E-ST-10-06C technical requirements specification: Official standard identification and scope; use the controlled edition for clause findings.