Arc Skills / Architecture and engineering budgets
Decompose a system into subsystems
Decomposition is useful when each child has a real ownership, integration or verification boundary. Arc Skills takes the parent System and required capabilities and returns a proposed contained-System tree with reasons for each split.
Use this skill
Use Arc Skills to propose a subsystem decomposition for my parent System.
Inputs:
- Parent System and selected product or functional viewpoint
- Required capabilities, existing hierarchy, and ownership or supplier boundaries
- Physical architecture and exchanges that justify child boundaries
Return a parent-child tree, responsibility coverage, reason for each split, and cross-boundary exchanges. Keep algorithms and behaviors within a System unless they have a real product or integration boundary.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Parent and current tree | Prevents duplicate or conflicting child records | Proposed contains tree |
| Capabilities and requirements | Maps behavior to meaningful children | Responsibility coverage |
| Ownership and interfaces | Explains why a split helps integration | Cross-boundary exchange list |
Navigation assembly product tree
Illustrative engineering example.
This fictional assembly receives inertial measurements and produces a navigation estimate. The viewpoint is the integrated product, not a functional-flow chart; an external flight computer is outside this parent.
Drone navigation assembly
├─ Sensor processing unit
└─ Navigation computer
External: flight computer receives navigation estimate
Behavior within sensor processing: configurable filter algorithm| Element | Responsibility | Boundary reason | Exchange |
|---|---|---|---|
| Sensor processing unit | Acquire and condition inertial measurements | Own sensor timing and source data quality | Conditioned samples → navigation computer |
| Navigation computer | Estimate state and validity | Own fusion state and navigation output | Navigation estimate → external flight computer |
| Filter algorithm | Condition samples within processing unit | No separate product or integration boundary | Internal behavior, not child System |
| Flight computer | Consume navigation output | Outside chosen assembly boundary | External Interface candidate |
The two child Systems have different outputs and test concerns: timing and data quality on one side, estimation and output validity on the other. The filter can be configured and verified as behavior without turning it into a third child System. That keeps the tree readable and avoids a spurious Interface for an internal computation.
If an inertial sensor arrives as a separately controlled supplier unit, the product tree may need a distinct sensor child instead of hiding it within sensor processing. That decision depends on the actual procurement and configuration boundary, so the example leaves it for the architecture owner rather than assuming a universal hierarchy.
Choose meaningful children
- Name the decomposition viewpoint and parent boundary before drawing children.
- Give each child a coherent responsibility, owner or integration boundary.
- Map required behaviors onto children and identify cross-child exchanges.
- Reject proposed children that are only algorithms, tasks or duplicate names for existing Systems.
Questions about this task
Can a function be a System?
Only when there is a meaningful product boundary behind it. A behavior alone can remain a function allocated to a System.
How deep should the tree go?
Stop when deeper nodes add no useful ownership, interface or verification distinction for the current work.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.