PPI Articles & Presentations

Read interesting and informative short articles relevant to systems engineering and projects.

Functional Design – Traps For The Unwary


Functional design is one of the foundation practices of Model-Based Systems Engineering (MBSE). But there are plenty of ways of doing it wrongly and losing the benefits. Here is PPI Director Robert Halligan’s list. Do you have any additions?

• defining a function that is the purpose of the system element, but not a function to be performed by the system element as an object

• naming functions with vague names

• using state names for functions

• defining “functions” that are negatives 

• defining functions that are not functions, for reasons other than above

• starting a function name with a noun

• starting a function name with an adjective

• thinking of the function as being just the short name, rather than the package of information that the short name represents

• simplistic logic that would never work if implemented

• muddling up control flow and item flow

• allocating to system elements without having added item flows

• showing a requirements level function in sequence with its decomposition

• showing sequence when concurrency actually applies

• defining “out-of-boundary” functions in the decomposition

• allocating un-allocatable functions rather than decomposing

• omitting “out-of-boundary” interfacing functions

• omitting item flows to “out-of-boundary” interfacing functions

• not flowing down performance

• identifying input/output items but not specifying them

• omitting essential preceding functions, e.g. reading something that hasn’t been stored

• terminating a function by the use of sequence when in fact, the function must continue to be performed

• designing or redesigning the containing system, not the system of interest (SOI)

• using a loop to try to show continuous operation

• using a flow chart notation (thereby loosing some of the logic on allocation)

• using a notation that cannot express the necessary logical relationships, e.g. replication

• using a non-executable notation where complex timing is involved

• using a notation that cannot distinguish between control flow and item flow

• starting decomposition with item flow rather than control flow

• not considering and reflecting resource utilization in the design

• defining the start of a function as a function

• defining the end of a function as a function

• not including unwanted functions that will occur and affect behavior

• omitting functions performed by solution elements that are not themselves engineered

• not doing a Failure Modes and Effects Analysis (FMEA) in relation to each allocatable function

• doing the FMEA only at the end of design.


Published By

Systems engineering thought leader, consultant, trainer and coach, impacting people's lives on six continents.
Published 6 years ago


2023_PPI-Website_Side-bar-portrait_350x350px (2)


Gain concepts and principles that will take your career to another level with PPI training!

FREE Monthly SE Industry News?
Scroll to Top