Arc Skills / Requirements
Identify missing requirements from operational scenarios
Arc Skills walks a scenario through its meaningful states and compares each transition with the requirement baseline. It returns a coverage map and candidate obligations only where an approved scenario needs behavior the baseline does not express.
Use this skill
Use Arc Skills to find missing requirements for the supplied operational scenario.
Inputs:
- Scenario actor, states, triggers, normal path, interruption, and recovery path
- Current requirement baseline with IDs and revisions
- Approved recovery behavior, interface rules, and decision owners
Return a transition coverage table, gap count, and conditional candidate wording.
Separate product behavior from procedures and tests. Leave unspecified recovery choices with the ownerWhat you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Operational scenario | Defines initial, interrupted, and recovery states | Transition map |
| Requirement baseline | Shows behavior already promised | Covered and partial transitions |
| Recovery decisions | Constrains any new duty | Open questions and candidate text |
A file transfer interrupted by link loss
Illustrative engineering example.
An operator requests a file, the link drops at 50%, then reconnects. R-1 covers starting a requested transfer; R-2 covers data integrity only for completed transfers.
R-1: The unit shall send a file when requested by the operator.
R-2: The unit shall verify integrity of each completed file transfer.
Scenario: idle → sending → link lost at 50% → reconnected → operator repeats request.| Scenario transition | Coverage | Candidate or decision |
|---|---|---|
| Idle → sending | Covered by R-1 | No new initiation requirement. |
| Sending → link lost | Partial: R-2 addresses completed transfer only | Define partial-file state and observable failure indication. |
| Reconnect → repeat request | Uncovered | Owner chooses resume or restart; then state required behavior. |
| Recovery → complete file | Partial: R-2 checks completed transfer | Confirm duplicate request semantics before claiming safe recovery. |
Of four transitions, one is covered, two partial, and one uncovered. The critical gap is not a generic retry count; it is what the system should do with a partial file and repeated request after reconnection.
A conditional candidate could read: “After link restoration and a repeated request, the unit shall [resume from an agreed checkpoint / restart the file] and provide [defined completion indication].” The bracketed choices require an owner decision before baselining.
Trace each meaningful state change
- Record actor, initial state, trigger, system response, and next state.
- Map actual behavior to exact requirement clauses, not shared nouns.
- Classify missing requirement, interface rule, procedure, or test separately.
- Draft only necessary recovery obligations after owners choose the behavior.
Questions about this task
Should every possible failure path become a requirement?
No. Focus on credible interruptions that prevent completion or safe recovery of the stated task.
Does R-2 cover partial transfers?
No. Its condition is a completed transfer; the link-loss state remains unresolved.
Sources and further reading
- NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.