Arc Skills / Requirements

Derive interface requirements from an interface definition

Arc Skills reads a controlled System-to-System interface and proposes only requirements justified by its exchange facts. The result names the responsible endpoint, source fact, existing coverage, and parameters still awaiting owners.

Use this skill

Use Arc Skills to derive endpoint requirements from the supplied interface definition.

Inputs:
- Controlled interface revision, endpoint systems, direction, and exchanged items
- Existing linked requirements and endpoint responsibilities
- Approved units, timing, format, and invalid-data behavior, where defined

Return candidate requirement statements and an interface-fact coverage map.
Keep unspecified parameters as owner questions. Preserve source IDs and avoid duplicate obligations

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
Interface definition	Establishes endpoints, direction, and exchanged item	Justified interface obligations
Existing requirements	Avoids duplicating linked source duties	Existing versus new map
Owner decisions	Supplies units and timing when approved	Open parameter list

Temperature exchange on INT-4

Illustrative engineering example.

The controlled interface says only that Sensor sends temperature data to Controller. Existing R-8 covers Sensor production of the value, but there is no approved rate or unit.

INT-4 rev A: Sensor → Controller; exchanged item: temperature data.
R-8: The Sensor shall provide temperature data to the Controller.
No approved unit, sampling rate, receiver validity rule, or encoding is supplied.

Temperature exchange on INT-4 — illustrative output
Interface fact	Requirement coverage / candidate	Open decision
Sensor sends temperature data	Existing R-8 covers source duty; retain link to INT-4.	Check whether provide means transmit at this boundary.
Controller receives value	Candidate receiver acceptance requirement only after behavior is agreed.	Controller owner must define acceptance and invalid-data handling.
Unit and rate	No candidate numeric or format clause supported.	Interface owners choose units and rate; then derive both endpoint duties.

A name and direction justify examining source and receiver responsibilities, but not a 1 Hz rate or degrees Celsius. Adding either would turn an example convention into design authority.

The output preserves one existing source requirement and two unresolved interface decisions. INT-4 remains an interface relationship between systems; there is no need for a separate Interface Item.

Derive from agreed exchange facts

Pin INT-4 revision, endpoints, direction, and exchanged item.
Map existing linked requirements to source generation, transport, and receiver use.
Propose only missing endpoint behavior grounded in an approved interface fact.
Ask owners for absent units, rate, encoding, and invalid-data rules before wording them.

Questions about this task

Should both endpoints get the same requirement?

No. Source generation and receiver acceptance are distinct obligations and need separately named actors.

Does an interface name define a protocol?

No. Preserve the available exchange fact and request protocol details if they affect interoperability.

Sources and further reading

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