Stage 4 — Decomposition

Functions, components, interfaces, design-to-requirement allocations.

Decomposition breaks the system into pieces and decides what each piece is responsible for.

What it outputs

OutputDefinition
FunctionsWhat the system does, decomposed hierarchically
ComponentsThe physical / logical pieces that realize the functions
InterfacesThe defined points at which components exchange information, energy, or matter
DTRsDesign-to-Requirement allocations — which component is responsible for satisfying which requirement

Functional vs physical decomposition

The Decomposition stage produces both:

  1. Functional decomposition — a tree of what the system does. Independent of any specific implementation
  2. Physical decomposition — components that map onto the functions. Multiple components may collaborate to satisfy one function; one component may serve multiple functions

The mapping between them is explicit (the DTRs).

Interface definition

Interfaces are first-class artifacts. Each interface has:

  • A name + ID
  • The two (or more) components it connects
  • The interface type (data / power / mechanical / thermal / RF)
  • A specification reference (e.g. "CCSDS Space Packet Protocol §3.2")

Why this matters: interface mistakes are among the most expensive errors in real SE projects. Pulling interfaces out as first-class artifacts makes them inspectable.

DTRs — who owns each requirement

A Design-to-Requirement allocation maps every requirement to the component(s) responsible for satisfying it. If a requirement is unallocated, that's a finding: either it's a system-level requirement that should stay at the parent level, or a component is missing from the decomposition.

The bundle's dtrs.json lists all allocations; the render produces an allocation matrix.

Quality signals

For a typical run:

  • 8–20 functions in 2–3 levels of hierarchy
  • 5–15 components
  • 4–12 interfaces
  • Every requirement allocated to ≥ 1 component (no orphans)
  • Every function realized by ≥ 1 component (no dangling functions)

Failure modes

  • Over-decomposition — 40 components for a system that should have 8. Usually means the Brief implied detail the system doesn't actually need; review and prune
  • Under-allocation — performance requirements not allocated to any component. Often means a component is missing (e.g. requirement on data latency but no data-handling component)
  • Phantom interfaces — interfaces between components that shouldn't talk to each other. Check the topology

Next

Design, Trade Studies & Risk →