Arc Skills / Requirements
Allocate requirements to systems and subsystems
Arc Skills compares a requirement baseline with system responsibilities and proposes allocation links. The output is an ownership table, not a claim that the design already satisfies each obligation.
Use this skill
Use Arc Skills to allocate the supplied requirements to responsible systems.
Inputs:
- The controlled requirement baseline with IDs, statements, and revisions
- System hierarchy, functional responsibilities, and relevant interface definitions
- Existing allocations and any disputed ownership boundaries
Return an allocation table with proposed links, retained links, contested boundaries, and reconciled counts.
Ground each proposed owner in architecture evidence. Keep cross-system outcomes open until responsibility is agreedWhat you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Requirement set | Preserves each actor and required outcome | Proposed owner for each ID |
| Architecture and interfaces | Shows which system detects, decides, and transmits | Evidence for the ownership boundary |
| Existing allocations | Separates retained links from changes | Contested and unallocated count |
A fault command across two subsystems
Illustrative engineering example.
The baseline has three requirements. The Detector reports faults to the Controller over INT-4; the Controller issues safe-mode commands. The Display only presents status.
R-10: The Detector shall send a fault indication to the Controller within 200 ms of fault detection.
R-11: The Controller shall issue a safe-mode command within 1 s of receiving a fault indication.
R-12: The system shall enter safe mode within 1 s of fault detection.
Existing link: R-11 allocated_to Controller.| Requirement | Current → proposed owner | Reason and disposition |
|---|---|---|
| R-10 | None → Detector | Detector creates the INT-4 indication; propose allocated_to Detector. |
| R-11 | Controller → Controller | Controller owns command output; retain existing link. |
| R-12 | None → unresolved system level | End-to-end 1 s starts before Controller receives the indication; allocation needs budget/ownership decision. |
The three rows reconcile to one new allocation, one unchanged allocation, and one contested requirement. R-12 cannot be given to the Controller solely because the Controller sends the final command: Detector latency and interface transport consume part of the same 1 s.
A possible follow-up is to derive measurable child obligations once the timing budget is agreed. The proposed links express responsibility only; no satisfied_by claim follows from them.
Decide who owns the outcome
- Pin the revisions of requirements, hierarchy, and interfaces before comparing responsibility.
- For each obligation, locate the actor that produces the stated response at the required boundary.
- Retain the lowest justified owner; hold cross-boundary outcomes at system level until apportioned.
- Count retained, new, contested, and unallocated rows and propose only justified links.
Questions about this task
Can a requirement have two owners?
An end-to-end outcome may involve two implementers, but two allocations do not explain who owns each part. Keep the system-level obligation and derive distinct duties after the boundary decision.
Does an allocation mean verification is complete?
No. It records implementation responsibility. Satisfaction and current verification evidence require separate assessment.
Sources and further reading
- NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.