Arc Skills / Interfaces
Identify missing interface requirements
An empty trace link is not proof that a new requirement is needed. Arc Skills takes an Interface, ConOps and existing requirements and returns a gap register with justified candidate wording.
Use this skill
Use Arc Skills to identify requirement gaps for my existing System Interface.
Inputs:
- Interface exchanges and their linked Requirements
- Full existing requirement set, controlled ICD or specifications, and revisions
- ConOps scenarios and both endpoint owners' stated needs
Return a gap register separating unlinked existing obligations, genuinely unstated needs and open design questions. Draft wording and a verification idea only for source-backed candidate requirements.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Interface exchange list | Identifies actual source, sink and mode | Exchange inventory |
| Requirements and links | Finds existing obligations before drafting | Linked, unlinked or missing classification |
| ConOps and ICD behavior | Tests whether a gap has a user need | Candidate requirement and verification idea |
Command and acknowledgment are different obligations
Illustrative engineering example.
A fictional actuator accepts an open command. Requirement REQ-12 already specifies the command syntax but is not linked to the Interface. The ConOps says the remote operator must know whether the command was accepted; no controlling acknowledgment statement is found.
Existing REQ-12: controller sends OPEN command to actuator
ConOps need: remote operator sees command acceptance
Linked Interface requirements: none
Automatic retry after timeout: no stated need| Exchange or behavior | Current evidence | Gap class | Proposed disposition |
|---|---|---|---|
| OPEN command syntax | REQ-12 exists; link absent | Trace gap | Link REQ-12 after owner check; do not duplicate |
| Acceptance acknowledgment | ConOps asks for remote confirmation; no statement found | Candidate requirement gap | Draft intent: report each valid OPEN command acceptance to remote operator; timing and endpoint owner TBD |
| Timeout retry | No approved recovery behavior | Open design question | Ask if automatic retry is required before writing obligation |
| Fault indication | ICD description incomplete | Evidence gap | Check fault scenario and existing requirement set |
The first row needs trace repair, not a new requirement. The second row has a source-backed user outcome, so a candidate acknowledgment obligation is warranted; its timing, exact signal and owner still require agreement before it can be baselined. A possible verification case would send a valid OPEN command and observe the response at the defined remote receiver after the owners settle its timing and path.
Automatic retry is common in some systems, but this evidence does not establish it as a need. Inventing that behavior could cause repeated actuation. Keep it a decision question until the operational owner defines the safe response to missing acknowledgment.
Classify each apparent gap
- List the exchanges and behavior parameters actually needed for interoperability.
- Search existing requirements and controlled agreements before drafting anything.
- Use scenario evidence to decide whether the omission is a real obligation or an open design choice.
- Give justified candidate wording, owner and verification idea without changing the baseline.
Questions about this task
Does a missing link mean missing coverage?
No. The requirement may exist elsewhere; link and content are separate review questions.
Can I draft a requirement from good practice alone?
You can suggest a question, but do not present it as an approved need without a source or owner decision.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.