Systems engineers do a task that is commonly known as functional decomposition. This task starts at the very top of the definition of a system and breaks down all the functions required to support the product’s mission (use cases) into layers of finer and finer functions. Functions are expressed as Verb-Object statements such as “Acquire target” or “Compute trajectory”.
I’ve always found it easy to quickly decompose a function into a set of 3 or 5 or 7 child functions that fully cover the parent function’s scope and intent. However, the fact that I can break down a function in many different ways reveals a very important truth – Functional decomposition is a decision! There’s more than one way to decompose any function; each model of N children is a unique alternative for the specific “Functional Model” decision.
Just like every other decision, the Functional Model choice has a criteria pattern that can be used to evaluate the relative effectiveness of one functional decomposition model compared to another. Here are the criteria I use when I think through a particularly complex decomposition problem:
If you are a proponent of Model-based Systems Engineering (MBSE), remember that not all models are created equal! Your first functional decomposition will seldom be the best you can do; you can use these criteria to test and improve your model.
You can both define and decompose the functional model for your system using the Decision Driven® Solutions Framework (DDSF). Please contact the Decision Driven® Solutions team at firstname.lastname@example.org or email@example.com to start your free trial of DDSF.