What is Functional Decomposition? [closed]

Question

Functional Decomposition is the process of taking a complex process and breaking it down into its smaller, simpler parts.

For instance, think about using an ATM. You could decompose the process into:

1. Walk up to the ATM

2. Insert your bank card

3. Enter your pin

well...you get the point.

You can think of programming the same way. Think of the software running that ATM:

1. Code for reading the card

2. PIN verification

3. Transfer Processing

Each of which can be broken down further. Once you've reached the most decomposed pieces of a subsystem, you can think about how to start coding those pieces. You then compose those small parts into the greater whole. Check out this Wikipedia Article:

Decomposition (programming)

The benefit of functional decomposition is that once you start coding, you are working on the simplest components you can possibly work with for your application. Therefore developing and testing those components becomes much easier (not to mention you are better able to architect your code and project to fit your needs).

The obvious downside is the time investment. To perform functional decomposition on a complex system takes more than a trivial amount of time BEFORE coding begins.

Personally, I think that amount of time is well worth it.

It's the same as WorkBreakDown Structures (WBS), mindMapping and top down development - basically breaking a large problem into smaller, more comprehensible sub-parts.

Pros

• allows for a proactive approach to programming (resiting the urge to code)
• helps identify the complex and/or risk areas of a project (in the ATM example, security is probably the more complex component)
• helps identify ALL components of a project - the #1 cause of project/code failure (via Capers Jones) is missing pieces - things not thought of until late in the project (gee, I didn't realize I had to check the person's balance prior to handing out the $)
• allows for decoupling of components for better programming, sharing of code and distribution of work

Cons - there are no real CONS in doing a decomposition, however there are some common mistakes

• not breaking down far enough or breaking down to far - each person needs to determine the happy level of detail needed to provide them with the insight to the component without overdoing it (don't break down into programming lines of code...)
• not using pre-existing patterns/code modules into consideration (rework)
• not reviewing with clients to ensure the scope is correct
• not using the breakdown when actually coding (like designing a house than forgetting about the plan and just starting to nail some boards together)

Here's an example: your C compiler.

First there's the preprocessor: it handles #include and #define and all the macros. You give it a file name and some options and it returns a really long string. Let's call this function preprocess(filename).

Then there's the lexical analyzer. It takes a string and breaks it into tokens. Call it lex(string). The parser takes tokens and turns them into a tree, call it parse(tokens). Then there's a function for converting a tree to a DAG of blocks, call it dag(tree). Call the code emitter emit(dag), which takes a DAG of blocks and spits out assembler.

The compiler is then:

emit(dag(parse(lex(preprocess(filename)))));

We've decomposed a big, difficult to understand function (the compile function) into a bunch of smaller, easier to understand functions. You don't have to do it as a pipeline, you could write your program as:

process_data(parse_input(), parse_config())

This is more typical; compilers are fairly deep programs, most programs are broad by comparison.

Functional decomposition is a way of breaking down the complex problem into simpler problems based on the tasks that need to be performed rather than the the data relationships. This term is usually associated with the older procedure-oriented design.

A short description about the difference between procedure-oriented and object-oriented design.

Functional decomposition is helpful prior to creating functional requirements documents. If you need software for something, functional decomposition answers the question "What are the functions this software must provide". Decomposing is needed to define fine-grain functions. "I need software for energy efficiency measurement" is too general. That's why we break this into smaller pieces until the point where we clearly understand all the functions the systems need to provide. This can be later used as a checklist for completeness of a system.

A functional requirements document (FD) is basically a textual representation of functional decomposition. Coding directly from the FD may be ok for procedural languages, but it is not good enough for object-oriented solutions, because it doesn't identify objects. Neither is good for usability planning and testing.

My opinion is that you should take some time to create a FD, but not to use it too much of the time. Consult every person that knows the process you are following with your system to find all the functions needed.

I have a lot of experience in software design, development, and selling, and I use functional decomposition as the first step of development. I use it as a base for the contract, so the client knows what they will get and I know what I must provide.