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:

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

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:

Logical Objects - as part of or preparation for object modeling
Data (logical) Objects - as part of creating a data map, data dictionary, data flow, or similar activity
Organizational Units - as part of organization modeling
System components - either hardware or logical components, as part of solution analysis. This might include databases, data elements, hardware components, etc.

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:

Strategic Goals - decomposed into departmental and business unit goals such as customer satisfaction, profitability measures, market share, etc.
Project Goals - decomposed into specific (measurable) results or objectives. This includes cost limits, number of bugs, development time, etc.
Personal Development Goals - decomposed into specific milestones. An example might be a goal to achieve CBAP certification broken down into specific sub-goals.

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

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

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:

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.

Examples of why decomposition might be used include:

The decomposition of organization functions into sub-functions. For example, a Human Resources function could include sub-functions for Hiring Employee's, Terminating Employee's; Changing Employee Roles; Managing Employee Benefits, and other similar activities. Note that this is a decomposition of functions, what the business does, not how the business does it or the order it is done in. Each sub-function unit should be as independent as possible from the other units at the same level.
The decomposition of high-level organizational functions into the processes that make up those functions.
The decomposition of specific system functions into sub-functions. For example, a Log-In function may be broken down into sub-functions called Get User ID, Get User Password, Validate User Password, Check User Permissions, Display User Home Screen, Display Error Screen, etc.
The decomposition of Strategic or Project Goals into the specific objectives or sub-goals that must be reached in order to meet the overall Goals.

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:

Identify the focus area that will be decomposed (the process, goal, business function, etc.).
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).
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:

Has a unique name
Describes how it fits into it's current group, and each group above it
Identifies any business rules for that component
Identifies any triggers (incoming or outgoing)

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

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

Outline

Take Order

Take Order from Customer
Input Order to Register

Prepare Order

Prepare Hot Foods
Prepare Drinks
Place in Bag

Take Payment

Inform Customer of Amount Owed
Receive Payment
Log Transaction in to Register
Deliver Change (if appropriate)

Deliver Order

Hand Customer their Order
Thank Customer

Table

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

Advantages

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.

Disadvantages

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.
A criticism of Functional Decomposition from a systems design perspective was put forth by Murray Cantor of Rational Software in 2003. It is called: Thoughts on Functional Decomposition

Tips

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.

References

BABOK 2.0: Functional Decomposition, Section 9.12, pages 174-176
Wikipedia: Functional Decomposition. Accessed on 11/26/2013.
Wikipedia: Decomposition (computer science). Accessed on 11/26/2013.
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.
Paper: A Taxonomy of Decomposition Strategies Based on Structures, Behaviors, and Goals. By Philip J. Koopman Jr. 1995
Thesis: Categorization and Representation of Functional Decomposition by Experts. By Paul W. Melancon. Naval PostGraduate School. 2008

Related Resources

Presentation: Guide to Functional Decomposition. From the Projects and Analysis page at Charles Sturt University in Australia.
Article Series: Decomposition in Project Management. By Ronda Bowen. On Bright Hub PM! 2009
Blog Post: Functional Decomposition. By Sam Ashok. 2008
Wiki Page: Functional Decomposition Diagrams. At TOGAF-Modeling.org. Accessed on 28 November 2013