IDEF3


IDEF3 or Integrated DEFinition for Process Description Capture Method is a business process modelling method complementary to IDEF0. The IDEF3 method is a scenario-driven process flow description capture method intended to capture the knowledge about how a particular system works.
The IDEF3 method provides modes to represent both
This method is part of the IDEF family of modeling languages in the field of systems and software engineering.

Overview

One of the primary mechanisms used for descriptions of the world is relating a story in terms of an ordered sequence of events or activities. The IDEF3 Process Description Capture Method was created to capture descriptions of sequences of activities, which is considered the common mechanisms to describe a situation or process. The primary goal of IDEF3 is to provide a structured method by which a domain expert can express knowledge about the operation of a particular system or organization. Knowledge acquisition is enabled by direct capture of assertions about real-world processes and events in a form that is most natural for capture. IDEF3 supports this kind of knowledge acquisition by providing a reliable and wellstructured approach for process knowledge acquisition, and an expressively, yet easy-to-use, language for information capture and expression.
Motives for the development of IDEF3 were the need:
The original IDEFs were developed since the mid-1970s for the purpose of enhancing communication among people who needed to decide how their existing systems were to be integrated. IDEF0 was designed to allow a graceful expansion of the description of a systems' functions through the process of function decomposition and categorization of the relations between functions. IDEF1 was designed to allow the description of the information that an organization deems important to manage in order to accomplish its objectives.
The third IDEF was originally intended as a user interface modeling method. However, since the Integrated Computer-Aided Manufacturing Program needed a simulation modeling tool, the resulting IDEF2 was a method for representing the time varying behavior of resources in a manufacturing system, providing a framework for specification of math model based simulations. It was the intent of the methodology program within ICAM to rectify this situation but limitation of funding did not allow this to happen. As a result, the lack of a method which would support the structuring of descriptions of the user view of a system has been a major shortcoming of the IDEF system. The basic problem from a methodology point of view is the need to distinguish between a description of what a system is supposed to do and a representative simulation model that will predict what a system will do. The latter was the focus of IDEF2, the former is the focus of IDEF3.

IDEF3 basic concepts

Descriptions and models

The distinction between descriptions and models, though subtle, is an important one in IDEF3, and both have a precise technical meaning.
The power of a model comes from its ability to simplify the real-world system it represents and to predict certain facts about that system by virtue of corresponding facts within the model. Thus, a model is a designed system in its own right. Models are idealized systems known to be incorrect but assumed to be close enough to provide reliable predictors for the predefined areas of interest within a domain. A description, on the other hand, is a recording of facts or beliefs about something within the realm of an individual’s knowledge or experience. Such descriptions are generally incomplete; that is, the person giving a description may omit facts that he or she believes are irrelevant, or which were forgotten in the course of describing the system. Descriptions may also be inconsistent with respect to how others have observed situations within the domain. IDEF3 accommodates these possibilities by providing specific features enabling the capture and organization of alternative descriptions of the same scenario or process, see figure.

Description capture

Modeling necessitates taking additional steps beyond description capture to resolve conflicting or inconsistent views. This, in turn, generally requires modelers to select or create a single viewpoint and introduce artificial modeling approximations to fill in gaps where no direct knowledge or experience is available. Unlike models, descriptions are not constrained by idealized, testable conditions that must be satisfied, short of simple accuracy.
The purpose of description capture may be simply to record and communicate process knowledge or to identify inconsistencies in the way people understand how key processes actually operate. By using a description capture method users need not learn and apply conventions forcing them to produce executable models. Forcing users to model requires them to adopt a model design perspective and risk producing models that do not accurately capture their empirical knowledge of the domain.

Scenarios

The notion of a scenario or story is used as the basic organizing structure for IDEF3 Process Descriptions. A scenario can be thought of as a recurring situation, a set of situations that describe a typical class of problems addressed by an organization or system, or the setting within which a process occurs. Scenarios establish the focus and boundary conditions of a description. Using scenarios in this way exploits the tendency of humans to describe what they know in terms of an ordered sequence of activities within the context of a given scenario or situation. Scenarios also provide a convenient vehicle to organize collections of process-centered knowledge.

Process-Centered Views

IDEF3 Process Schematics are the primary means for capturing, managing, and displaying process-centered knowledge. These schematics provide a graphical medium that helps domain experts and analysts from different application areas communicate knowledge about processes. This includes knowledge about events and activities, the objects that participate in those occurrences, and the constraining relations that govern the behavior of an occurrence.

Object-Centered Views

IDEF3 Object Schematics capture, manage, and display object-centered descriptions of a process—that is, information about how objects of various kinds are transformed into other kinds of things through a process, how objects of a given kind change states through a process, or context-setting information about important relations among objects in a process.

IDEF3 process description language

IDEF3 descriptions are developed from two different perspectives: process-centered and object-centered. Because these approaches are not mutually exclusive, IDEF3 allows cross-referencing between them to represent complex process descriptions.

Process Schematics

Process schematics tend to be the most familiar and broadly used component of the IDEF3 method. These schematics provide a visualization mechanism for process-centered descriptions of a scenario. The graphical elements that comprise process schematics include Unit of Behavior boxes, precedence links, junctions, referents, and notes. The building blocks here are:
IDEF offers a series of building blocks to express detailed object-centered process information; that is, information about how objects of various kinds are transformed into other kinds of things through a process, or how objects of a given kind change states through a process.