Functional decomposition is a decision

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:

Functional Model-Criteria in DTT

Functional Model-Criteria in DTT

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 trial@decisiondriven.com or solutions@decisiondriven.com to start your free trial of DDSF.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Architecture, Decision Driven Product Development and tagged , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Functional decomposition is a decision

  1. G’day John.

    I’d like to know if there is any decision-oriented guidance for knowing the “time window” when it’s optimal to start this functional decomposition? I ask this question having seen the following anecdote:

    ““There are times when non-architects prematurely make major architectural decisions. For example, multiple contracts or subcontracts may be let based on organizational expertise, rational decomposition structures, project schedule and other reasons before the requirements and resulting overall system architecture have been adequately engineered. This can result in a suboptimal top-level system decomposition that is almost impossible to change.” [p.83]
    Firesmith, Donald G. et al (2008), “The Method Framework for Engineering System Architectures”, Auerbach Publications, USA.

    BRgds,
    Trevor.

    • decisiondriven says:

      Trevor,
      I think of functional decomposition as a time-agnostic process. It’s a continuous, branching process that occurs at every level of system context (operational capability, system, subsystem, component, etc.). Whenever you make a “Choose Technology for Function X” decision, you drive the next level decomposition of “Function X”. Your readiness to decompose function X is driven by the state of this parent decision; if there are widely divergent technologies in the running as alternatives, then you need to hold off on decomposing Function X. If there are many similar viable technologies/designs that would yield almost the same child functions or only a single viable solution, then there’s no significant advantage from delaying decomposition.
      I understand the desire to delay decision-making so you don’t lock yourself into a sub-optimum solution. However, the answer is not to wait, but rather to accelerate decision-making by attacking all the vital decisions in parallel. What matters is that all the critical decisions are made in such a way that their derived requirements don’t invalidate the other decision’s “preferred alternatives”. That’s a matter of state of the data, not a matter of chronological time.
      John

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s