Decomposition - Functional and Otherwise

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.

It is a common analytical technique, and business analysts use it frequently. Among the things business analyst's commonly decompose are:

Decomposition is perhaps the single most-practiced technique in business analysis. A common output of a decomposition is a hierarchical diagram of some sort, such as the Functional Decomposition Diagram. This is similar to a number of other Business Analysis techniques, including Organizational Analysis, Feature Tree's, Work Breakdown Structures, and Mind Mapping. The key difference between decomposition and those other analysis techniques is that the sub-components (the children) of something that is decomposed should completely describe the component (the parent) that has been decomposed. This may not be true of something like an Org Chart (which may not show all sub-units).

Types of Decomposition

Koopman[6] describes three basic types of decomposition that are described below:

Structural Decomposition

Structures are physical components, logical objects, attributes, fields, or arrangements of other structures within a design. Structures typically answer the question of what in a design, and are typically described using nouns and adjectives. For business analyst's, structural decomposition is most likely to take the following forms:

Behavioral / Functional Decomposition

Behaviors are an action, force, process, or control that is exerted on or by a structure with respect to the structure's external environment. In the case that only a portion of a design (a sub-design) is under consideration, other sub-designs constitute a portion of the external environment for the behavior under consideration.  Behaviors typically answer the questions of how and when in a design, and are typically described using verbs and adverbs. For most business analyst's, this takes the form of Functional Decomposition (where the business function is the action in question).

Functional Decomposition is the type of Decomposition that is described in many Business Analysis references and is one of the core business analysis techniques according to the IIBA[1]. It's also a good idea to know that Functional Decomposition exists in other disciplines, although it is often done in different ways. It exists in mathematics (for decomposing formulas and mathematical problems), signal processing, machine learning, database theory, knowledge representation, software development, and systems engineering.[2,3] Just be aware that when you refer to functional decomposition others may have different understandings of exactly what is being done than you do, so be sure you clarify.

Goal Decomposition

Goals are emergent properties that satisfy the needs which the effort or design is intended to fulfill. Goals include any result that is not directly available as an off-the-shelf building block. Goals thus include performance targets, costs and aesthetics. For business analysts', goal decomposition can include:


Cohesion and Coupling

The concepts of Cohesion and Coupling are key to well executed functional decomposition. However, they can also be applied to structural and goal decomposition as well.


Cohesion is simply a measure of how similar functions in a group are. The greater the cohesion between two or more functions, the more likely they should be grouped together in decomposition results. This helps to ensure that similar functions are grouped together and helps to identify potential duplicate functions that may be performed by different groups, or at different steps in a sequence. If a function does several things that have low cohesion, there is a good chance that the function needs further analysis and may need to be broken into several discreet functions at the same level as the current function.


Coupling is a measure of interdependence between two or more functions. So a change to a function or function group with low coupling would affect very few other functions outside of its function group.

The measure of a good decomposition effort is that the sub-units have high cohesion and high coupling only within themselves, and low cohesion and low coupling with any other sub-groups.


Why do it?

Decomposition has a lot of uses.  It can be used to:


Examples of why decomposition might be used include:


How do I do it?

The following steps below show the general process that a Business Analyst goes through in order to conduct Functional Decomposition. Different documentation types will be shown afterwards.

Step 1

Decide the what and how of the decomposition effort. This usually involves making the following three decisions:

  1. Identify the focus area that will be decomposed (the process, goal, business function, etc.).
  2. Decide the level of detail that will be needed. In some cases you may only want a quick outline (such as when just starting a project to generate an initial elicitation artifact) while in others you may want substantial detail (such as when the functional decomposition results provide a significant part of the project or requirements artifacts).
  3. Then decide what type of documentation  will be generated to show the results of the decomposition effort.  See below for examples.

Step 2

Work with the customer / SME if appropriate to identify the main components that are within the focus area.

Step 3

Review each of those main functions to identify any sub-components within them.

Step 4

Review all identified components to determine if they need further decomposition.

Step 5

Check for completeness. Are all aspects of the entity under review that should be captured represented? Are the components correctly organized into discreetly related groups? Is further decomposition needed?

Step 6

Repeat and Refine the results until all business and project team members are satisfied with the completeness and level of detail.

Step 7

If desired, each component can be documented in a consistent way so that each component:


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:

The following are simple examples of each documentation type using the idea of a functional breakdown of the drive-thru window of a typical fast food restaurant.


Functional Decomposition Diagram

Simple Example of Functional Decomposition  


  1. Take Order
    1. Take Order from Customer
    2. Input Order to Register
  2. Prepare Order
    1. Prepare Hot Foods
    2. Prepare Drinks
    3. Place in Bag
  3. Take Payment
    1. Inform Customer of Amount Owed
    2. Receive Payment
    3. Log Transaction in to Register
    4. Deliver Change (if appropriate)
  4. Deliver Order
    1. Hand Customer their Order
    2. Thank Customer


The table method of decomposition is commonly used when you want to capture additional information about a function. In this case we are capturing the actor who commonly undertakes a function.

Number Action Actor
1 Take Order Cashier
1.1 Receive Order from Customer Cashier
1.2 Input Order into Register Cashier
2 Prepare Order Cook / Window Attendant
2.1 Prepare Hot Foods Cooks
2.2 Prepare Drinks Window Attendant
2.3 Place Food in Bag Window Attendant
3 Take Payment Cashier
3.1 Inform Customer of Amount Owed Cashier
3.2 Receive Payment Cashier
3.3 Log Transaction into Register Cashier
3.4 Deliver Change (if appropriate) Cashier
4 Deliver Order Window Attendant
4.1 Hand Customer their Order Window Attendant
4.2 Thank Customer Window Attendant








  1. BABOK 2.0: Functional Decomposition, Section 9.12, pages 174-176
  2. Wikipedia: Functional Decomposition.  Accessed on 11/26/2013.
  3. Wikipedia: Decomposition (computer science).  Accessed on 11/26/2013.
  4. Book: Determining Project Requirements.  Hans Jonasson. ESI International Project Management Series.  Auerbach  Publications.  2008
  5. Book: Seven Steps to Mastering Business Analysis.  Barbara A. Carkenord.  Pages 237-240.  J. Ross Publishing.  2009.
  6. Paper: A Taxonomy of Decomposition Strategies Based on Structures, Behaviors, and Goals. By Philip J. Koopman Jr. 1995
  7. Thesis: Categorization and Representation of Functional Decomposition by Experts. By Paul W. Melancon. Naval PostGraduate School. 2008

Related Resources