IDEF3 (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
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.
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:
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.
History 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. 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.
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 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.
Description capture
… excerpt ends here. Continue reading the full article.
