Arc Skills / Requirements

Review requirement rationale

Arc Skills reviews a controlled requirement and its stated rationale for decision usefulness. It returns a verdict, a concise proposed rationale, and exact evidence needed before a numerical explanation can be approved.

Use this skill

Use Arc Skills to review the rationale for the supplied requirement.

Inputs:
- Exact requirement statement, revision, and current rationale
- Parent or customer source and intended operational outcome
- Supporting hazard, interface, trade, or budget evidence where applicable

Return a usefulness verdict, phrase-specific issue, proposed rationale, and missing-source question.
Keep rationale separate from the requirement. Do not invent the reason for an approved limit

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 revision	Fixes the exact obligation being explained	Rationale verdict
Current rationale	Shows whether it adds causal information	Minimal replacement proposal
Source evidence	Can justify a non-obvious limit	Open locator or owner question

A two-second latch with a circular rationale

Illustrative engineering example.

The current rationale says only that the latch must work reliably. The design team mentions a sequence budget, but the controlled budget document is not available.

R-14: The door shall latch within 2 s of a valid close command.
Rationale: To ensure reliable operation.
Referenced timing budget: [document and locator not supplied].

A two-second latch with a circular rationale — illustrative output
Element	Review	Proposed action
R-14 obligation	Actor, trigger, and 2 s bound are present.	Keep wording; define valid command and latch observation if absent elsewhere.
Current rationale	Partial: “reliable operation” restates a goal but does not explain 2 s.	Propose: “The 2 s bound supports [identified sequence timing budget].”
Timing source	No controlled passage supplied.	Timing owner provides budget ID and locator before rationale approval.

A rationale should help a later engineer decide whether the limit can change. “Reliable operation” does not reveal why 2 s matters or whether a looser value would harm a sequence.

The proposed sentence is intentionally incomplete. It preserves the possible budget explanation without claiming that a budget exists or that a safety hazard has been identified.

Ask what future decisions need to know

Read the requirement and rationale at the same revision.
Check whether the rationale explains the chosen response, condition, or limit rather than repeating it.
Find a traceable customer, hazard, interface, or calculation source for non-obvious choices.
Keep a concise proposal and exact missing locator separate from controlled text.

Questions about this task

Does every direct customer clause need a long rationale?

No. A short source trace can be enough when the obligation and reason are already explicit.

Can a plausible safety reason be added?

Only if an actual hazard or safety decision supports it. Do not infer criticality from the sentence alone.

Sources and further reading

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