IDEFØ
Function Modeling Method
Overview
IDEFØ is a method designed to model the decisions,
actions, and activities of an organization or system. IDEFØ was
derived from a well-established graphical language, the Structured
Analysis and Design Technique (SADT). The United States Air Force
commissioned the developers of SADT to develop a function modeling
method for analyzing and communicating the functional perspective
of a system. Effective IDEFØ models help to organize the analysis
of a system and to promote good communication between the analyst
and the customer. IDEFØ is useful in establishing the scope of an
analysis, especially for a functional analysis. As a communication
tool, IDEFØ enhances domain expert involvement and consensus decision-making
through simplified graphical devices. As an analysis tool, IDEFØ
assists the modeler in identifying what functions are performed,
what is needed to perform those functions, what the current system
does right, and what the current system does wrong. Thus, IDEFØ
models are often created as one of the first tasks of a system development
effort.
In December 1993, the Computer Systems Laboratory
of the National Institute of Standards
and Technology (NIST) released IDEFØ as a standard for Function
Modeling in FIPS
Publication 183.
IDEFØ Concepts
The IDEFØ method has basic concepts that address each
of the needs previously discussed. The basic IDEFØ concepts include
the following.
Cell Modeling Graphic Representation
The "box and arrow" graphics of an IDEFØ
diagram show the function as a box and the interfaces to or from
the function as arrows entering or leaving the box. To express functions,
boxes operate simultaneously with other boxes, with the interface
arrows "constraining" when and how operations are triggered
and controlled. The basic syntax for an IDEFØ model is shown in
the figure below.
Communication
IDEFØ concepts designed to enhance communication include
the following:
 |
Diagrams based on simple box and arrow graphics. |
 |
English text labels to describe
boxes and arrows and glossary and text to define the precise
meanings of diagram elements. |

Figure
1: IDEFØ Box and Arrow Graphics
Rigor and Precision
The rules of IDEFØ require sufficient rigor and precision
to satisfy needs without overly constraining the analyst. IDEFØ
rules include the following:
Methodology
Step-by-step procedures are provided for modeling,
review, and integration tasks. Formal training courses for transferring
the methodology are available.
Organization versus Function
The separation of organization from the function is
included in the purpose of the model and carried out by the selection
of functions and interface names during model development. This
concept is taught in the IDEFØ course, and the continual review
of these concepts during model development ensures that organizational
viewpoints are avoided.
Sequence and Timing Independence
Applying the IDEFØ method results in an organized
representation of the activities and the important relations between
these activities in a nontemporal fashion. IDEFØ does not support
the specification of a recipe or process. Such detailed descriptions
of the specific logic or timing associated with the activities requires
the IDEF3 Process Description Capture Method.
Strengths and Weaknesses of
IDEFØ
The primary strength of IDEFØ is that the method has
proven effective in detailing the system activities for function
modeling, the original structured analysis communication goal for
IDEFØ. Activities can be described by their inputs, outputs, controls,
and mechanisms (ICOMs). Additionally, the description of the activities
of a system can be easily refined into greater and greater detail
until the model is as descriptive as necessary for the decision-making
task at hand. In fact, one of the observed problems with IDEFØ models
is that they often are so concise that they are understandable only
if the reader is a domain expert or has participated in the model
development. The hierarchical nature of IDEFØ facilitates the ability
to construct (AS-IS) models that have a top-down representation
and interpretation, but which are based on a bottom-up analysis
process. Beginning with raw data (generally interview results with
domain experts), the modeler starts grouping together activities
that are closely related or functionally similar. Through this grouping
process, the hierarchy emerges. If an enterprise's functional architecture
is being designed (often referred to as TO-BE modeling), top-down
construction is usually more appropriate. Beginning with the top-most
activity, the TO-BE enterprise can be described via a logical decomposition.
The process can be continued recursively to the desired level of
detail. When an existing enterprise is being analyzed and modeled
(often referred to as AS-IS modeling), observed activities can be
described and then combined into a higher level activity. This process
also continues until the highest level activity has been described.
One problem with IDEFØ is the tendency of IDEFØ models
to be interpreted as representing a sequence of activities. While
IDEFØ is not intended to be used for modeling activity sequences,
it is easy to do so. The activities may be placed in a left to right
sequence within a decomposition and connected with the flows. It
is natural to order the activities left to right because, if one
activity outputs a concept that is used as input by another activity,
drawing the activity boxes and concept connections is clearer. Thus,
without intent, activity sequencing can be imbedded in the IDEFØ
model. In cases where activity sequences are not included in the
model, readers of the model may be tempted to add such an interpretation.
This anomalous situation could be considered a weakness of IDEFØ.
However, to correct it would result in the corruption of the basic
principles on which IDEFØ is based and hence would lose the proven
benefits of the method. The abstraction away from timing, sequencing,
and decision logic allows concision in an IDEFØ model. However,
such abstraction also contributes to comprehension difficulties
among readers outside the domain. This particular problem has been
addressed by the IDEF3 method.
KBSI has developed an automated Function
Modeling tool, AIØ
WIN®, to support the IDEFØ method. |