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.
• The gradual exposition of detail featuring a hierarchical structure, with the major functions at the top and with successive levels of subfunctions revealing well-bounded detail breakout.
• A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams.
• The limitation of detail to no more than six subfunctions on each successive function.

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:

• Control of the details communicated at each level (three to six function boxes at each level of a decomposition).
• Bounded Context (no omissions or additional out-of-scope detail).
• Diagram Interface Connectivity (Node numbers, Box numbers, C-numbers, and Detail Reference Expression).
• Data Structure Connectivity (ICOM codes and the use of parentheses).
• Unique Labels and Titles (no duplicated names).
• Syntax Rules for Graphics (boxes and arrows).
• Data Arrow Branch Constraint (labels for constraining the data flow on branches).
• Input versus Control Separation (a rule for determining the role of data).
• Data Arrow Label Requirements (minimum labeling rules).
• Minimum Control of Function (all functions require at least one control).
• Purpose and Viewpoint (all models have a purpose and viewpoint statement).

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.