What it shows:
A hierarchical tree that breaks down a broad, complex business area into its smaller, constituent sub-functions. It maps exactly what the business area does, not how they do it.
Why it’s needed:
Scope containment and boundary defence. For the delivery team, this is the primary weapon against scope creep. By explicitly mapping out the sub-functions, it highlights exactly which boxes the proposed solution will support and, crucially, which boxes are out of scope. It plainly defines: “Functions A, B, and C are enabled. Function D is out of scope for this delivery phase.”
When to use it:
Highly recommended for SADs when deploying massive, multi-modular platforms (like ERP, CRM, or PLM systems). Even for COTS products, if the vendor software can do 50 different things but the contract only dictates implementing three of them, this diagram is absolutely required to ring-fence the delivery.
When NOT to use it:
Omit for single-purpose utility deployments or pure infrastructure hardware (e.g., deploying a standalone licensing server, an Active Directory node, or replacing physical storage arrays). If the function being delivered is singular, self-evident, and has no sub-components, drawing a decomposition tree adds zero value.
Example:
