Getting started with functional modeling for system specifications

When seeking to build a model that could be used with simulation software, we can start with functional modeling. A functional model (or, alternatively, function model) is a graphical representation of a system. Each building block represents a discrete function. The inputs and outputs flow in and out of the system and between functions. Different teams can build different functional models, all connecting to achieve an overall system view.

We observe functional modeling as far back as the 1800s. Frank Gilbreth was an early proponent of Taylorism and scientific management (originating from the breakthrough work of Frederick Winslow Taylor). Gilbreth introduced flow process charts in the early 1920s, long before continuous quality improvement became popular in the mid-1990s. Mainstream functional modeling originated in the 1950s and 1960s through the ‘then emergent’ fields of systems engineering and software engineering.

Today, we will look at functional modeling using the Integrated DEFinition Methods (IDEF) IDF0 specification (Mayer, 1990), which provided a straightforward, defined approach applicable to any system.

Why do we do functional modeling?

Functional modeling is central to most comprehensive modeling frameworks for systems and software products and paradigms. It can facilitate analysis, discovery, and design in its own right or as a part of a multi-faceted approach.

Like all other modeling and simulation work, the primary prerequisite to functional modeling is understanding purpose, viewpoint, and context.

1. What is the reason for creating the model (purpose)?
2. What perspective is adopted for the model purpose, creation, and use (viewpoint)?
3. What are the model’s subject and boundaries/scope (context)?

These foundational questions will inform and shape the entire functional modeling process.

Using a functional modeling specification: IDEF0

Modeling specifications, such as the classic Integrated DEFinition Methods (IDEF) modeling specifications, provided consistency, approachability, and agnosticism to modeling efforts. The IDEF0 specification, in particular, is an older but classic functional modeling specification that is useful for engineers who are getting started with functional modeling.

IDEF0 fits into a broader set of IDEF modeling specifications, covering information modeling, data modeling, and process modeling. The IDEF website suggests their “wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design, and knowledge acquisition.” A wide range of business process modeling techniques exist. These modeling specifications were developed primarily by US Department of Defense projects.

The IDEF0 building blocks

The fundamental building block of IDEF0 functional modeling is a singular-component function. The function transforms inputs into outputs with controls and mechanisms (Figure 1):

• Inputs are transformed by the function
• Outputs are produced by the function
• Controls guide the function
• Mechanisms are how the function is performed

Each IDEF0 function should additionally include

• Function name

Function names should describe the activity in a verb-noun phrase, such as “build artifact,” “draft specification,” or “inspect traffic.”

• Time study information

Time studies will add information to the function, if possible. This information is valuable for understanding and facilitates later simulation of the whole functional model. The time study data may be a simple minimum, maximum, average, or more rigorous statistics.

• Key performance indicators

Key performance indicators address other essential metrics beyond the activity duration, e.g., security score, retry count, or activity cost.

• An activity owner

Finally, all functions must be assigned to an activity owner - ownership facilitates participation, motivation, and accuracy.

Decomposing IDEF0 functions

Some basic rules of functional decomposition include:

• Every function is decomposed into 3-6 children. Each function is decomposed into smaller function models (Figure 3).
• The “sweet spot” in function modeling decomposition is where further decomposition would not provide any value and where there aren’t too many unmanageable, complex component models.
• The purpose, viewpoint, and context defined before the modeling effort will inform the level of decomposition required.

Next steps: The results of modeling

The functional paradigm (Cares Gallardo, et al., 2006). guides systems designers and developers of a complex system:

“designing a system means to describe its functions, their organization in order to fulfill given mission, and to gather all these functions in a coherent functional architecture, later allocated to a physical architecture. This allows then to describe and to reason not only on what the system must do but also on when and how it must do it i.e., the resulting dynamic of the entire system of interest”

— (Aizier, et al., 2012, July, p. 170).

A short course could furnish the team with a comprehensive introduction to Systems Analysis, Modeling, and Simulation. However, functional modeling itself is only one such component.

In creating functional models, complex sociotechnical systems can be observed, analyzed, understood, and improved. We understand the overall working system better, and the model may be used as an input to a simulation (if the tool allows), adjusting variables to gauge effects.