What is it?
Generally speaking, Decomposition is the process of breaking complex entities (processes, technology, business problems, business needs) into smaller sub-parts, and then breaking those smaller parts down even more, until the complex entity has been broken down into more discreet components with a more understandable structure.
Activity decomposition is an abstraction technique that enables the modularisation of business processes. A decomposed process is more intuitive and easier to understand as each decomposition step incrementally focuses on a smaller number of overlapping concerns. This fosters reusing the process models and also increases the ability to communicate and analyse each model.
However, each decomposition step must provide a consistent level of detail so that the resulting set of atomic activities comprising the lowest level of decomposition is always the same regardless of the modelling team’s experience.
It is a common analytical technique, and business analysts use it frequently. Among the things business analyst’s commonly decompose are:
- Systems – into processes, functions, rules, and decisions
- Processes – into steps, actors, and decisions
- Goals – into sub-goals and objectives
- Requirements – into functional requirements, non-functional requirements, business rules, decisions, and constraints
Why do it?
Decomposition can be used to:
- Assist in the analysis of processes by breaking them down into smaller component parts. These can be documented as sub-processes; analyzed for decisions, rules, and dependencies; or otherwise evaluated in relative isolation in order to make them more comprehensible.
- Assist in defining Scope by allowing the project team to clearly specify from a functional decomposition diagram which functions are in scope and how they relate and roll-up into larger feature sets.
- Assist in elicitation and analysis by identifying areas that need more elicitation work, and by providing a visual model of the functions that have been identified so far.
- As part of the elicitation and analysis processes by decomposing greater business goals and needs into actual requirements.
- Identifying current system functionality for an undocumented system that needs to be replaced.
- Strategic Planning, by breaking high-level corporate goals into lower division, department, and unit goals.
What Should the Results be?
In addition to differences in what is being functionally decomposed, there are different ways to document the results of the decomposition analysis, and different levels of detail that are used. The different methods of documentation include:
- A Functional Decomposition Diagram
- An outline structure
- A table structure
- Functional Decomposition is an intuitive process for most people and is readily understood by the customer.
- Helps to discover duplicate or overlapping activities.
- Breaks complex systems into relatively separate components, which can help with scope, development, and planning.
- Is internally focused (what are we currently doing versus what should we be doing)
- It can be easy to define too much detail.
- There is no way to be sure that every necessary component has been captured and properly related.
- It is very easy to conflate a functional diagram with an organizational diagram (especially for stakeholders). This can make it easy to overlook interdependencies where there may be high levels of coupling to functions that were not diagramed on other organizational units, or where multiple organizational units are involved in the function that was diagrammed.
- It is often a good idea to start with a draft decomposition diagram (or table, or outline) based on your project initiation documents or other readily available material (such as procedure documents) before engaging with your clients. This means that they don’t have to start with an empty structure that they have to fill and enables them to quickly move into evaluating your initial work and identifying gaps.
- You can also reverse this technique and do functional composition. This is starting a very fine grained step of a process or function and moving up to identify how that function fits into larger groups.
- Book: Determining Project Requirements. Hans Jonasson. ESI International Project Management Series. Auerbach Publications. 2008
- Book: Seven Steps to Mastering Business Analysis. Barbara A. Carkenord. Pages 237-240. J. Ross Publishing. 2009.
- BABOK 2.0: Functional Decomposition, Section 9.12, pages 174-176
- Wikipedia: Functional Decomposition. Accessed on 11/26/2019.
- Wikipedia: Decomposition (computer science). Accessed on 11/26/2013.
- Wiki Page: Functional Decomposition Diagrams. At TOGAF-Modeling.org. Accessed on 28 November 2019
- Article Series: Decomposition in Project Management. By Ronda Bowen. On Bright Hub PM! 2009