IDEF3 or Integrated DEFinition for Process Description Capture Method is a business process modelling method complementary to IDEF0.^[1] The IDEF3 method is a scenario-driven process flow description capture method intended to capture the knowledge about how a particular system works.^[2]

The IDEF3 method provides modes to represent both^[2]

• Process Flow Descriptions to capture the relationships between actions within the context of a specific scenario, and
• Object State Transition to capture the description of the allowable states and conditions.

This method is part of the IDEF family of modeling languages in the field of systems and software engineering.

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.^[1]

Motives for the development of IDEF3 were the need:^[1]

• to speed up the process of business systems modeling,
• to provides mechanisms to describe this data life cycle information,
• to supported project management techniques by an automated tool,
• to provide the concepts, syntax, and procedures for building system requirements descriptions, and
• to work well both independently and jointly with other methods which address different areas of concentration (e.g., the IDEF0 Function Modeling method) as a complementary addition to the IDEF method family.

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 (i.e., in terms of the Input, Output, Control, and Mechanism classification). IDEF1 was designed to allow the description of the information that an organization deems important to manage in order to accomplish its objectives.^[2]

The third IDEF (IDEF2) was originally intended as a user interface modeling method. However, since the Integrated Computer-Aided Manufacturing (ICAM) 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 (existing or proposed) 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.^[2]

The distinction between descriptions and models, though subtle, is an important one in IDEF3, and both have a precise technical meaning.^[1]

• The term description is used as a reserved technical term to mean records of empirical observations; that is, descriptions record knowledge that originates in or is based on observations or experience.
• The term model is used to mean an idealization of an entity or state of affairs. That is, a model constitutes an idealized system of objects, properties, and relations that is designed to imitate, in certain relevant respects, the character of a given real-world system. Frictionless planes, perfectly rigid bodies, the assumption of point mass, and so forth are representative examples of models.

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.^[1]

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.^[1]

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 (e.g., conventions ensuring accuracy, internal consistency, logical coherence, non-redundancy, completeness). 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.^[1]

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.^[1]

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.^[1]

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.^[1]

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.^[1]

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 (UOB) boxes, precedence links, junctions, referents, and notes. The building blocks here are:^[1]

• Unit of Behavior (UOB) boxes
• Links : Links are the glue that connect UOB boxes to form representations of dynamic processes.
• Simple Precedence Links : Precedence links express temporal precedence relations between instances of one UOB and those of another.
• Activation Plots : Activation plots are used to represent activations.
• Dashed Links : Dashed links carry no predefined semantics.
• Link Numbers : All links have an elaboration and unique link numbers.
• Activation Semantics for Nonbranching Process Schematics.
• Junctions : Junctions in IDEF3 provide a mechanism to specify the logic of process branching.
• UOB Decompositions : Elaborations capture and structure detailed knowledge about processes.
• UOB Reference Numbering Scheme : A UOB box number is assigned to each UOB box in an IDEF3 Process Description.
• Partial Descriptions : UOB boxes are joined together by links. Since the description capture is the focus of IDEF3, it is possible to conceive of UOBs without links to other parts of an IDEF3 schematic.
• Referents : Referents enhance understanding, provide additional meaning, and simplify the construction (i.e., minimize clutter) of both process schematics and object schematics.

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.^[1]

• Objects : An object of a certain kind, like a chassis, will be represented simply by a circle containing an appropriate label.
• Object States : A certain kind of object being in a certain state will be represented by a circle with a label that captures the kind itself and a corresponding state, representing thereby the type, or class, of objects that are in that state.
• Object schematics : The construction of complex representations built from kind symbols and object state symbols.
• Transition Schematics : The first and most basic construct is the basic state transition schematic or simply, transition schematic.

• IDEF
• Ontology
• Ontology (computer science)

• Costin Badic and Chris Fox (2004). "Hybrid IDEF0/IDEF3 Modelling of Business Processes: Syntax, Semantics and Expressiveness"
• Mounira Harzallah (2007). "Incorporating IDEF3 into the Unified Enterprise Modelling Language". In: Proceedings of the 2007 Eleventh International IEEE EDOC Conference Workshop. pp 133–140.
• C.H. Kim et al. (2001). "An integrated use of IDEF0, IDEF3 and Petri net methods in support of business process modelling". In: Proceedings of the Institution of Mechanical Engineers. Part E, Journal of process mechanical engineering. Vol. 215, no 4, pp. 317–329.
• Jeong K-Y et al. (2008). "Integration of queuing network and IDEF3 for business process analysis". In: Business Process Management Journal. Vol 14, Issue: 4, pp. 471–482.
• L. Whitman and B. Huff (1997). "Structured Models And Dynamic Systems Analysis: The Integration Of The IDEF0/IDEF3 Modeling Methods And Discrete Event Simulation". In: Simulation Conference, 1997., Proceedings of the 1997 Winter. 7-10 Dec 1997 pp. 518–524

• Overview of IDEF3 Archived 2010-04-25 at the Wayback Machine at www.idef.com