Arc Skills / Requirements

Trace requirements back to stakeholder needs

Arc Skills maps controlled stakeholder needs to candidate downstream requirements by actual outcome. It returns trace judgments with missing need portions and requirements that require another source.

Use this skill

Use Arc Skills to trace the supplied requirements to stakeholder needs.

Inputs:
- Controlled stakeholder needs and requirement revisions with exact wording
- Operational scenarios and intended stakeholder outcomes
- Existing traces and alternate sources for added requirements

Return a need-clause coverage table, proposed trace decisions, and an uncovered-outcome list.
Judge actual outcome, not shared terms or an existing link. Preserve independent sources for extra duties

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
Stakeholder need	Defines the user outcome	Coverage target
Requirements and links	Shows implemented behaviors and claimed traces	Supported, partial, or unsupported mapping
Operational context	Reveals missing user-facing outcome	Gap and alternate-source question

Pump fault detection versus operator awareness

Illustrative engineering example.

A stakeholder wants to know when the pump stops unexpectedly. The current requirements detect and log the event, but none requires a visible operator alert.

N-2: The operator needs to know when the pump stops unexpectedly.
R-40: The controller shall log an uncommanded pump stop.
R-41: The controller shall store the last 100 pump events.
Existing trace: N-2 → R-40.

Pump fault detection versus operator awareness — illustrative output
Need element / requirement	Trace verdict	Gap or alternate source
Unexpected pump stop / R-40	Partial support	Logging detects/stores the event but does not notify an operator.
Operator knows / no requirement	Uncovered	Candidate display or alarm behavior needs approved user-interface intent.
R-41 event history	Not direct satisfaction of awareness	Trace to maintenance/history need if one exists; do not force N-2 link.

R-40 is relevant but incomplete: an operator may never inspect the log. The trace link records a relationship, while the actual need includes a human-facing outcome.

R-41 may be useful for later diagnosis, but it cannot close N-2. The candidate alert requirement should be phrased only after the stakeholder or product owner chooses channel and timing.

Trace the outcome the stakeholder needs

Split the need into actor, situation, and desired outcome.
Compare each requirement’s actual response with that outcome.
Mark partial support when only detection, storage, or transport is covered.
Keep extra requirements attached to their true source or an open source question.

Questions about this task

Can a log satisfy operator awareness?

Only if the operational process requires and ensures the operator receives it in the relevant situation. That evidence is absent here.

Does every requirement need a direct stakeholder need?

A derived requirement may trace through a parent or design decision. Preserve the real source chain rather than forcing a direct link.

Sources and further reading

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