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.
