Functional Decomposition: What Have You Done for Me Lately?

Oh no! Functional decomposition!

It sounds like an evil villain from an elementary school play like tooth decay or gingivitis. Actually, functional decomposition is a BA’s favorite tool. If you haven’t heard of it then you are in for a treat. If you have heard of it, don’t worry there is a still a great lesson to be learned in the following article.

Functional decomposition, according to the BABOK, “Helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analyzed independently” (BABOK, 2016).

You may be asking yourself, “What does this mean for me?” Functional decomposition is used to break down a complex process in order to capture all the needed requirements for a project. If you use the tool properly you will be able to break down all the functional areas in order to provide more complete project estimates and requirements.

I have used functional decomposition throughout most of my career as a BA, but sometime in the past few years I stopped using it as I had access to various project management and requirement documenting tools that assisted with the process of gathering requirements and project estimation. The problem is that there wasn’t a real functional decomposition occurring and my projects suffered for it.

---

---

It wasn’t until a year ago, after speaking with Bob Prentiss (www.bobtheba.com) through a seminar that I realized what was missing from my routine and could increase the accuracy of my estimates for my projects as well as assisting in avoiding missing requirements. Bob unlocked this part of my brain that had been shut off temporarily almost like a code word in a spy novel to unlock hidden abilities in an agent or in my case hidden potential.

Using something similar to the following diagram you can take your main project and break it down into its functional areas or your requirements.

Notice how the project is broken out into its various functions? Then each function in turn may have sub functions. I prefer to label my items using either color codes or in the example shown number codes. This way I can see how my requirements will flow through my requirements documentation and aides in traceability. I know that I have a Function 1 and that function has Sub Function 1.1 and Sub Function 1.2 helping me in documenting all requirements and aiding me in preventing missed requirements.

The lesson to be learned is to not forget about the available techniques and tools at your disposal when working on a project. We can easily get side tracked by timelines or stakeholders requesting for updates and immediate results that we forget to slow down and use every appropriate tool or technique at our disposal. We need to take time to plan out our requirements in order to provide a better end product. We should be saying to ourselves “Functional decomposition: What haven’t you done for me lately?”