Overview

The IDEF3 Process Description Capture Method provides a mechanism for collecting and documenting processes. IDEF3 captures precedence and causality relations between situations and events in a form natural to domain experts by providing a structured method for expressing knowledge about how a system, process, or organization works. IDEF3 descriptions can:

	Record the raw data resulting from fact-finding interviews in systems analysis activities.
	Determine the impact of an organization's information resource on the major operation scenarios of an enterprise.
	Document the decision procedures affecting the states and life-cycle of critical shared data, particularly manufacturing, engineering, and maintenance product definition data.
	Manage data configuration and change control policy definition.
	Make system design and design trade-off analysis.
	Provide simulation model generation.

IDEF3 captures the behavioral aspects of an existing or proposed system. Captured process knowledge is structured within the context of a scenario, making IDEF3 an intuitive knowledge acquisition device for describing a system. IDEF3 captures all temporal information, including precedence and causality relationships associated with enterprise processes. The resulting IDEF3 descriptions provide a structured knowledge base for constructing analytical and design models. Unlike simulation languages (e.g., SIMAN, SLAM, GPSS, WITNESS) that build predictive mathematical models, IDEF3 builds structured descriptions. These descriptions capture information about what a system actually does or will do and also provide for the organization and expression of different user views of the system.

There are two IDEF3 description modes, process flow and object state transition network. A process flow description captures knowledge of "how things work" in an organization, e.g., the description of what happens to a part as it flows through a sequence of manufacturing processes. The object state transition network description summarizes the allowable transitions an object may undergo throughout a particular process. Both the Process Flow Description and Object State Transition Description contain units of information that make up the system description. These model entities, as they are called, form the basic units of an IDEF3 description. The resulting diagrams and text comprise what is termed a "description" as opposed to the focus of what is produced by the other IDEF methods whose product is a "model."

An IDEF3 Process Flow Description captures a description of a process and the network of relations that exists between processes within the context of the overall scenario in which they occur. The intent of this description is to show how things work in a particular organization when viewed as being part of a particular problem solving or recurring situation. The development of an IDEF3 Process Flow Description consists of expressing facts, collected from domain experts, in terms of five basic descriptive building blocks.

The following example illustrates how the building blocks of the IDEF3 method can describe a scenario typically found in a manufacturing environment. The situation to be described is a painting and inspection process associated with applying primer paint to a part that will become an element of a subassembly for a piece of heavy construction equipment. The example IDEF3 description shown in Figure 1 is the graphical representation of the scenario (story) told by a paint shop supervisor when asked to describe: "What goes on in the primer shop?"

The story the example describes follows:

Parts enter the shop ready for the primer coat to be applied. We apply one very heavy coat of primer paint at a very high temperature. The paint is allowed to dry in a bake oven after which a paint coverage test is performed on the part. If the test reveals that not enough primer paint has been sprayed on the surface of the part, the part is re-routed through the paint shop again. If the part passes the inspection, it is routed to the next stop in the process.Note the activities described in the scenario are clearly identified and appear as labeled boxes in Figure 1 and that the labeled boxes can describe activities, processes, events, etc. The IDEF3 term for elements represented by boxes is a Unit Of Behavior (UOB). The arrows (links) tie the boxes (activities) together and define the logical flows. The smaller boxes define junctions that provide a mechanism for introducing logic to the flows.

Not directly represented in Figure 1 is the Decomposition and Elaboration component of IDEF3. Each UOB can have associated with it both "descriptions in terms of other UOBs" and a "description in terms of a set of participating objects and their relations." We refer to the former as decompositions of a UOB and the latter as an elaboration of a UOB. Intuitively, a decomposition is a closer look at some given UOB within a larger diagram. A decomposition is a diagram, and may be a decomposition of some UOB in the scenario (top level) diagram or it may be the decomposition of a UOB in a decomposition. More precisely, a decomposition of a given UOB is a more fine grained IDEF3 representation of that UOB. Multiple views (decompositions) are allowed in IDEF3 primarily because it is meant to be used as a description capture method. Experience with related modeling methods has demonstrated the need to capture different views of the same activity. IDEF3 provides this capacity by allowing multiple decomposition of the same UOB.

An elaboration is an element of the IDEF3 description that captures the objects that participate in a particular activity and the facts and constraints that are defined on these objects and on instances of that activity. Each element of an IDEF3 description can have an elaboration. It is in the elaboration that resource requirements of systems will be captured.

Object state transition network (OSTN) diagrams capture object-centered views of processes which cut across the process diagrams and summarize the allowable transitions. Figure 2 shows a sample OSTN diagram.

Object states and state transition arcs are the key elements of an OSTN diagram. In OSTN diagrams, object states are represented by circles and state transition arcs are represented by the lines connecting the circles. An object state is defined in terms of the facts and constraints that need to be true for the continued existence of the object in that state and is characterized by entry and exit conditions. The entry conditions specify the requirements that need to be met before an object can transition into a state. The exit conditions characterize the conditions under which an object can transition out of a state. The constraints are specified by a simple list of property/value pairs or by a constraint statement. The values of the attributes must match the specified values for the requirements to be met.

State transition arcs represent the allowable transitions between the focus object states. It is often convenient to highlight the participation of a process in a state transition. The importance of such a process constraint between two object states can be represented in IDEF3 by attaching a UOB referent to the transition arc between the two object states.

KBSI has developed two automated Process Modeling tools, PROSIM® and PROCAP®, to support the IDEF3 method.