Decision: Functional Model

Form - Fit - FUNCTION.  I’ve always wondered why this little design ditty isn’t inverted; the heart of any product design lies in its Functional Model.  This decision determines which capabilities the product will deliver to the end user; a product that provides more functionality or the same functionality with better performance will generally win in the marketplace.  Even a pet rock has a purpose.

The product design decision pattern within the Decision Driven® Strategy web service includes multiple decisions related to functional design.  These appear under the State Model branch that organizes the functions into life cycle and operational states (not all functions are active in all states of a product).

I’ve framed the Functional Model decision as “What is the product’s top-level functional model/architecture (functional flow, relationships)?”.  This decision is sometimes called the Logical Architecture to distinguish it from the physical structure of a product (hardware + software components).

The functions delivered by a product are primarily driven from 3 other decisions:

• Use Cases to Support: The sum of all the functions (use case steps) across all use cases defines the capabilities that the user will pay for
• Operating Regime(s), Behaviors to Exploit/Control: The operating environment and performance levels of the product determine which material properties or scientific behaviors the product will experience.  The methods used to exploit or control these properties/behaviors are a source of functions.
• Life Cycle: The capabilities that are built into the product to support its life cycle model (e.g. deployment, training, diagnostics, maintenance, upgrades).

Functional design is not just adding up the list of functions from these sources, but rather organizing them into a lean, mean performing machine.

Every function will be delivered or implemented by some technology, method or algorithm; the decision model branches out into “Choose Technology for Function X” decisions below the Functional Model decision.  However, functional design doesn’t always occur top-down.  At times, engineers will have to look ahead to these technology decisions to determine the optimum building blocks for their solution.  Once they have identified the best technologies for the high priority functions, they may iterate through the Functional Model decision to look for clever ways to “wire” these technologies together to form a complete solution.

Functional design may occur on multiple levels as complex functions are further decomposed.  Decomposition is a decision process (not just modeling); the Child Functions decision is really just the Functional Model decision repeated one level deeper.

Functional design must also consider function-to-function interactions or interfaces.  Systems engineers have historically depicted these interactions as an “N-Squared” diagram.  There may be an Interface Concept decision for each functional interaction or groups of similar interactions.