Functional Decomposition

Functional Decomposition

Use Functional Decomposition to:

• Hierarchically decompose a system into its functional components,
• Hierarchically decompose a business process into sub-processes,
• Provide a definition of all the business functions and sub-functions identified as system requirements. 

 

Method

1.  Overview of Functional Decomposition
2.  Levels of Detail for Functional Decomposition
3.  Guidelines for Decomposing Business Functions and Processes
4. Guidelines for Drawing a Function Chart

 

NOTATION ON A FUNCTION CHART

Squares indicate a business function or business process.

Solid Triangles indicate that a more detailed breakdown is provided on a subsequent Function Chart.

Triangles Containing Letters indicate that the function has been included on another diagram.  For example, a triangle containing "AD" indicates that the function has been further documented on an Action Diagram.  A triangle containing "DFD" indicates that the function has been further documented on a Data Flow Diagram.

 

Tips and Hints

Use an automated CASE tool when constructing Function Charts.

Example
 

The example Function Chart decomposes the business functions for a manufacturing company.

 

1 Overview of Functional Decomposition 

Functional Decomposition is a fundamental analysis technique.  It breaks a complex problem into successive layers of more manageable and comprehensive pieces, resulting in a hierarchically structured Function Chart that describes the problem and/or solution in levels of increasing detail.

In Functional Decomposition, the lower level functions/processes completely describe the parent.  A function/process at a lower level cannot exist unless it is included within its parent function/process.

Functional Decomposition drives the analysis process.  The logical functions and processes become the subject, and therefore the focus, of interviews and verification activities such as walk-throughs.  Similarly, the logical processes will eventually be organized into application systems.  The Functional Decomposition must therefore be approached in a systematic manner.  It must aim to ensure that each function and process is conceptually and operationally independent.

Concepts of Coupling and Cohesion

The aim of Functional Decomposition is to identify functions which are highly cohesive and loosely coupled.  This makes them conceptually and operationally independent and promotes more stable business systems.

Coupling is a measure of the degree to which two functions are interdependent.  Loose coupling is good because changes to one function can be made with less impact on other functions, i.e., you do not have to know about other functions to make changes to the function being studied.

Cohesion is a measure of the strength of association of the processes within a function.  High cohesion is good because highly cohesive functions that perform one well-defined objective are easier to understand and maintain.

Benefits of Good Functional Decomposition

A good Functional Decomposition helps the analysis in several ways:

• The simplicity of the structure and representation aids in understanding the breakdown of functions and processes.
• Specifying the precise requirements and features for each function becomes easier because the functions and processes are broken down into smaller units.
• The partitioning and independence of the functions localizes errors and minimizes system faults.
• It allows the customer to view and discuss the organization in a form that can be dealt with, i.e., as a collection of functions, rather than as a continuous process.

 

Problems of a Poor Functional Decomposition

Poor Functional Decomposition can hinder the project both now and in subsequent stages by:

• Hindering understanding of an organization's business when functions and processes overlap,
• Creating unnecessarily numerous, complex interfaces,
• Requiring extensive rework of other Process Modelling methods, such as Data Flow Diagrams, in later stages as detail problems emerge.

2 Levels of Detail for Functional Decomposition

Enterprise Level of Detail

At the enterprise level , the root of the Function Chart may contain the name of the organization (or a major function or sub-function within an organization).  The root is broken down into no more than three levels of detail.  A brief description is provided for each function.
 
The second level identifies major business functions, typically related to Planning, Execution, and Control.

Note that administrative functions such as Finance, Accounting, and Personnel should not be top level functions.  Top level functions should only be functions that directly contribute to the production of an organization's product or service.  Administrative functions should only be further decomposed if required, for example, if a system is being developed to support administrative functions.  Because Function Charts read so similarly to Organization Charts, i.e., both use a top-down structure, it can be politically very difficult to convince the Corporate Vice President of Finance and Personnel, for example, that his or her function is not a top level function.  One method of addressing this is to draw separate Function Charts for each of the administrative functions so that each has its own top level Function Chart.  This does not take much time, gets these functions included in the documentation, and works well as long as the charts are not further expanded.  Another method of addressing this is to include administrative functions under a function called, for instance, Organizational Support.

Conceptual Level of Detail

At the conceptual level, leaf level functions (i.e., lowest level functions) on the enterprise level chart within the context of the system are decomposed into the next level of detail.  This level identifies the major business processes necessary to accomplish each function.  Processes identified at this level typically correspond to application systems or sub-systems, for example, Sales, Finance, or Purchasing.
 
Functional Decomposition at the conceptual level of detail helps define the scope of a project.

Logical Level of Detail

At the logical level, the Function Chart decomposes processes into the lowest level of detail.  Functional Decomposition at this level identifies all the processes within the scope of the project.  The lowest level processes on the Function Chart can be documented using Action Diagrams, Structured English, or Pseudocode.
 
Once started, leaf level processes must continue to conclusion or else be totally undone.  A leaf level process takes the business from one state to another or does not change the state of the business at all.  To complete Functional Decomposition, each branch of the tree must be decomposed to the lowest level process.  However, not every branch will be decomposed to the same number of levels.

Complete understanding of the characteristics of a leaf level process requires an understanding of:

• Volume and response time requirements, i.e., determine how often and how quickly a response from the process is required,
• Security, i.e., determine who performs what processes,
• Design menu structures, i.e., determine what user groups use what processes,
• Plan for distribution, i.e., determine the geographic locations where the processes are performed.

Application Design Issue

During application design, the lowest level processes may not necessarily map directly to modules.  For example, one leaf level process may become many program modules or many leaf level processes may become one program module.

 

3 Guidelines for Decomposing Business Functions and Processes

Identify a Business Function

Identify the business functions.  A function is composed of a logical set of ongoing activities or processes that sustain the organization's business objectives (i.e., producing a product, providing a service).  A function can be managed but cannot be performed.

Identify Business Processes

Once the business function has been identified, define the business processes that make up the business function.

A business process is a distinct activity described by its inputs and outputs.  A process describes a unique behaviour that has a beginning and an end.  A process is performed repeatedly.

A business process may be:

• manual,
• automated,
• assisted by automation.

 

Verbs Suitable for Naming Business Processes

The following verbs are suitable for naming business processes:

• acquire,
• agree,
• assess,
• attend,
• build,
• calculate,
• check,
• conduct,
• create,
• define,
• determine,
• develop,
• examine,
• identify,
• maintain,
• market,
• obtain,
• plan,
• record,
• remove,
• report,
• select,
• specify,
• test,
• update.

 

Distinguishing Between a Business Function and a Business Process

Functions, which describe what an organization does, can be decomposed into processes that describe how the work is accomplished.

If an activity can be performed, it is a process.  Otherwise, it is a function.  For example, you cannot perform the function Marketing but you can perform the business process Contact a Customer.

Functions can break down into other functions or business processes.  Business processes can only break down into other business processes.

Criterion of Decomposition

There should be a single criterion used to differentiate between levels of the decomposition.  The criterion is the rule applied during the process of building a decomposition diagram, e.g., a Function Chart, that assures the diagram contents are consistent.

The criterion, or rule, of decomposition specifies the relationship between the function that is being decomposed and its constituent processes.

 

4. Guidelines for Drawing Function Charts

Description of a Function Chart

A Function Chart is a hierarchical diagram showing a progressively more detailed breakdown of the business functions and business processes of an organization.

A Function Chart does not predefine a physical design or implementation of the system.

Function Charts Versus Other Tree-Structure Diagrams

There is a fundamental difference between Function Charts and other kinds of tree-structure charts such as Organization Charts and Structure Charts.  In a Function Chart, the collection of offspring completely describes the parent.  This is not true in organization charts nor in program structure charts.  In program structure charts a parent block may invoke its child blocks.  It is essential to understand this difference to create Function Charts correctly.  A Function Chart represents the basic functions that have to be carried out regardless of what organization groups or departments exist.  A function or process may cross organizational boundaries.

Option for Displaying the Function Chart

Consider drawing your Function Chart with the root box at the left of the diagram and subsequent levels presented vertically rather than horizontally when there are numerous child blocks.

Naming Functions on a Function Chart

Name a function with a noun or a word ending in "ing."  For example, Invoicing or Human Resources Management.

Naming Business Processes on a Function Chart

Begin the name of a business process with an active verb, for example, "Pay Bills."  Use a simple imperative statement to describe the intention of the process.  For example, "Pay Invoice" or "Approve Invoice."

 

CONSIDERATIONS WHEN DRAWING FUNCTION CHARTS

Levels on a Function Chart

A level of a Function Chart is composed of functions or business processes.  Do not mix functions and business processes on the same level.

Each lower level of the Function Chart provides details for the level immediately above.  Lower levels are a decomposition of the upper level business function or business process, not separate from the upper level.

Complete the subordinates for any one function before further exploding any of the subordinates.  For example, if a subordinate of the function Accounting is Pay Bill, identify all subordinates of Accounting before further decomposing Pay Bill.

Administrative services or utility functions are not typically top level functions.

Rule of Thumb for Number of Subordinates

As a rule of thumb, limit the number of subordinates of a function to seven.  If there are more, group related subordinates and explode them in a lower level.  For example, the function Finance may have subordinates Funds Management, Cash, Short-Term Financing, Long-Term Financing, Financial Control, Budget, Managerial Accounting, and General Accounting.  To limit the number of subordinates under Finance, you may combine Managerial Accounting and General Accounting under Accounting and explode them at the next level.

Function Chart Numbering Scheme

Use a hierarchical numbering scheme.  For example, if the function Accounting is numbered 1 on the chart, successive breakdowns of Accounting would be numbered 1.1, 1.2, 1.1.1, and so on.

Tip for Numbering Function Chart

When numbering the charts, remember that function numbers are just a label and have no meaning.  However, the specifications document will likely be organized by function number.  Therefore, it is a good idea to assign the low numbers to the functions that should appear first in the document.  Otherwise, top level users may not understand that what they consider to be the organization's most important function is, for example, number ten and starts on page 183 of the document.

Time Dependencies

Time dependencies are not shown on Function Charts