Arc Skills / Requirements

Define acceptance criteria for a requirement

Arc Skills converts a controlled requirement into acceptance criteria for the intended configuration. The output says what evidence must show and flags missing definitions that would prevent a defensible pass.

Use this skill

Use Arc Skills to define acceptance criteria for the supplied requirement.

Inputs:
- Exact requirement ID, revision, statement, and approved limits
- Target article, operating conditions, relevant interface events, and state definitions
- Measurement accuracy and the project decision rule for uncertainty

Return a clause-to-criterion table with observation, condition, comparator, limit source, and readiness.
Distinguish the pass rule from operator steps. Leave missing event definitions and uncertainty policy unresolved

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
Requirement and approved limit	Supplies the obligation and numeric authority	Criterion linked to R-4
Definitions and configuration	Fixes start/end event and target article	Observable pass boundary
Measurement policy	Controls boundary cases near 2 s	Ready or blocked decision

Valve closure within two seconds

Illustrative engineering example.

R-4 states a 2 s requirement, but the interface and sensor documents have not yet fixed the acceptance timestamp or what confirms physical closure.

R-4 rev B: The valve shall close within 2 s after a valid close command.
Article: valve V-2 with Controller C2.
Open definitions: valid command acceptance event; confirmed closed state; timing uncertainty rule.

Valve closure within two seconds — illustrative output
Obligation	Draft criterion	Readiness / missing decision
Start condition	Valve open; accepted valid close command at t0	Blocked: define acceptance event and log source.
Closed outcome	Confirmed physical closed state at t1	Blocked: agree sensor or independent observation.
Time limit	Elapsed t1 − t0 ≤ 2 s for specified article	Limit comes from R-4; uncertainty treatment remains open.

The proposed rule measures the event R-4 actually promises. Observing a close command on a bus or a controller output alone would be a proxy and would not establish that the valve reached closed state.

The 2 s value is supplied by the requirement, so it is retained exactly. The criterion cannot yet be used for a final pass near the boundary until the project defines event timestamps and uncertainty treatment.

Write the pass boundary

Separate independently observable promises in the requirement.
State condition, configuration, measured event or quantity, comparator, and approved limit.
Check that passing the criterion would truly demonstrate the requirement rather than a convenient proxy.
Keep unknown sensor, sample, tolerance, and uncertainty decisions visible as blocked fields.

Questions about this task

Is a procedure the same as a criterion?

No. The criterion states the pass boundary; a procedure gives an operator the setup and ordered actions needed to gather evidence.

Can the 2 s limit be relaxed for test uncertainty?

Only under an approved decision rule. Record the measurement uncertainty and ask the responsible authority how boundary results are judged.

Sources and further reading

NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.