System Decomposition

Input: $ARGUMENTS

Interpretations

Before executing, identify which interpretation matches the user’s input:

Interpretation 1 — Decompose a new system concept into subsystems: The user has a system idea or high-level description and needs to break it down into manageable components with clear responsibilities, interfaces, and hierarchy. Interpretation 2 — Refactor an existing decomposition: The user has an existing system structure that has become unwieldy, has unclear boundaries, or needs reorganization to better match requirements or constraints. Interpretation 3 — Allocate requirements to components: The user has both a set of requirements and a preliminary architecture, and needs to systematically assign each requirement to specific components and verify complete allocation.

If ambiguous, ask: “I can help with decomposing a new system from scratch, refactoring an existing system structure, or allocating requirements to components — which fits?” If clear from context, proceed with the matching interpretation.

Depth Scaling

Default: 2x. Parse depth from $ARGUMENTS if specified (e.g., “/sysdecomp 4x [input]”).

The Process

Step 1: Identify Decomposition Criteria

Choose the primary decomposition strategy based on system characteristics:

DECOMPOSITION STRATEGY:

SYSTEM: [name]
PRIMARY CRITERION: [functional / physical / behavioral / data / organizational / layered / service]
JUSTIFICATION: [why this criterion fits]

SECONDARY CRITERION: [if hybrid approach needed]
JUSTIFICATION: [why a second dimension is needed]

CONSTRAINTS ON DECOMPOSITION:
- [technical constraints — e.g., latency requires co-location]
- [organizational constraints — e.g., team boundaries]
- [deployment constraints — e.g., must run on single node]
- [regulatory constraints — e.g., separation of concerns for audit]

Step 2: Perform Top-Down Decomposition

Start from the system level and break down iteratively:

LEVEL 0 — SYSTEM:
[System Name]: [one-sentence purpose]

LEVEL 1 — SUBSYSTEMS:
├── SS-1: [Subsystem Name] — [purpose]
├── SS-2: [Subsystem Name] — [purpose]
├── SS-3: [Subsystem Name] — [purpose]
└── SS-4: [Subsystem Name] — [purpose]

LEVEL 2 — COMPONENTS (expand each subsystem):
├── SS-1: [Subsystem Name]
│   ├── C-1.1: [Component Name] — [purpose]
│   ├── C-1.2: [Component Name] — [purpose]
│   └── C-1.3: [Component Name] — [purpose]
├── SS-2: [Subsystem Name]
│   ├── C-2.1: [Component Name] — [purpose]
│   └── C-2.2: [Component Name] — [purpose]
...

LEVEL 3 — SUB-COMPONENTS (if needed):
├── C-1.1: [Component Name]
│   ├── SC-1.1.1: [Sub-component Name] — [purpose]
│   └── SC-1.1.2: [Sub-component Name] — [purpose]
...

System Breakdown Structure (SBS) table:

Step 3: Define Component Responsibilities (Single Responsibility)

For each component, verify it has a single, clear responsibility:

COMPONENT RESPONSIBILITY MATRIX:

| Component | Primary Responsibility | Does NOT Handle | Cohesion Check |
|-----------|----------------------|-----------------|----------------|
| C-1.1 | [one clear job] | [things it delegates] | HIGH/MED/LOW |
| C-1.2 | [one clear job] | [things it delegates] | HIGH/MED/LOW |
...

For each component, apply the Single Responsibility Test:

Step 4: Identify Component Interactions

Map how components communicate:

INTERACTION MATRIX:

          | C-1.1 | C-1.2 | C-2.1 | C-2.2 | C-3.1 |
----------|-------|-------|-------|-------|-------|
C-1.1     |  —    | [D/E] | [D/E] |       |       |
C-1.2     | [D/E] |  —    |       |       | [D/E] |
C-2.1     | [D/E] |       |  —    | [D/E] |       |
C-2.2     |       |       | [D/E] |  —    |       |
C-3.1     |       | [D/E] |       |       |  —    |

D = Data flow, E = Event/signal, C = Control flow, blank = no interaction

Interface specification for each interaction:

Coupling assessment:

Step 5: Validate Decomposition Completeness

Verify every requirement is allocated to at least one component:

REQUIREMENT ALLOCATION MATRIX:

| Requirement ID | Description | Allocated To | Allocation Type |
|---------------|-------------|-------------|-----------------|
| REQ-001 | [description] | C-1.1 | Primary |
| REQ-002 | [description] | C-1.2, C-2.1 | Shared |
| REQ-003 | [description] | ??? | ORPHAN — needs allocation |
...

ALLOCATION SUMMARY:
  Total Requirements: [N]
  Allocated: [N]
  Orphaned (no component): [N] — ACTION REQUIRED
  Shared (multiple components): [N] — verify coordination

Functional coverage check:

Step 6: Check Decomposition Depth

Verify the decomposition is neither too shallow nor too deep:

DEPTH ASSESSMENT:

| Component | Current Level | Assessment | Recommendation |
|-----------|--------------|------------|----------------|
| C-1.1 | 2 | Too shallow — has 3 distinct responsibilities | Decompose further |
| C-1.2 | 2 | Just right — single responsibility, testable | Keep |
| SC-1.1.1 | 3 | Too deep — trivial wrapper | Merge into parent |
...

Output Format

## SYSTEM BREAKDOWN STRUCTURE: [System Name]

### Decomposition Strategy
Primary criterion: [criterion]
Levels: [N]
Total components: [N]

### Hierarchy
[Tree diagram of system → subsystems → components]

### Component Registry
[Table: ID, Name, Parent, Level, Purpose, Owner, Responsibility]

### Interface Catalog
[Table: From, To, Mechanism, Data, Protocol]

### Requirement Allocation
[Table: Requirement → Component mapping]
Orphan requirements: [N]
Gold-plated components: [N]

### Coupling Assessment
[Summary of coupling types found and recommendations]

### Depth Assessment
[Components that need further decomposition or merging]

### Open Questions
[Decisions needed about decomposition boundaries]

Quality Checklist

Before completing:

• Decomposition criterion chosen and justified
• All components have single, clear responsibility
• All interactions between components identified and specified
• Every requirement allocated to at least one component
• No gold-plated components (components without requirements)
• Coupling assessed and high-coupling areas flagged
• Decomposition depth assessed (not too shallow, not too deep)
• Cross-cutting concerns allocated (logging, security, error handling)
• External interfaces have owning components
• Component naming is consistent and specific

Next Steps

After system decomposition:

1. Use /requirements to verify all requirements are well-specified before allocation
2. Use /tracematrix to formalize requirement-to-component traceability
3. Use /de to map dependencies between components
4. Use /testplan to design integration tests for component interfaces
5. Use /lcca to estimate costs per component and subsystem
6. Use /tpm to assign technical performance measures to critical components