Key Terms

The terms defined here are basic to the understanding of the method used throughout this book. This listing is not intended to be a complete glossary of all terms used.

Activity/Process/Function    An activity is the smallest of the three forms of happening—something that is an action, rather than a static thing. A process is a group of activities joined together to accomplish a major task (the design process, the painting process, the planning process). A function is a role that occurs many times in the sequence of running an enterprise and requires a particular training or expertise associated with it (the management function, the training function, the quality assurance function). These three terms have specific meanings to various people. For the purposes of this book, any one of these words may be used for a happening.

A-0 diagram    The top-most diagram in an IDEFO model. Pronounced “a minus zero.”

Arrow    A directed container for the things (as opposed to the happenings) that comprise the contents of an IDEFO model. An arrow on an IDEFO diagram may show the interface between two boxes on the diagram (an internal arrow), or it may be a boundary arrow (an interface to an activity on the parent diagram). An arrow may contain anything that has no action associated with it: discrete objects, people, systems, information, and so forth. The term “data arrow” is typically used to speak about an IDEFO arrow, but the word “data” does not imply a restriction to information only. An arrow may include such esoteric items as “satisfaction,” items that are used up (like parts of an assembly), continuously available things (like electricity or temperature readings), or any other item that is static and may serve as an input, control, output, or mechanism in the model.

AS-IS    The name for the IDEFO model that shows how an enterprise now operates, as opposed to a TO-BE model, which shows how the enterprise will operate in the future (after changes are implemented).

Author    A person who has been trained in the creation of IDEFO models. He may also be a reader, but the label author is reserved for a person who is not only trained in how to read the IDEFO diagrams but is able to create diagrams and models himself.

Boundary arrow    An arrow showing one of its ends (head or tail) unconnected on the diagram. It is therefore an inter-diagram interface. Boundary arrows either show an ICOM to indicate the precise connection to the parent diagram, or show a tunnel (parentheses) to indicate that there is no connection to the parent.

Box    A rectangle identifying an IDEFO activity. The box contains a verb phrase naming the activity. The box name is merely a placeholder for the decomposition diagram for that activity. Therefore, all activities are contained in the bottom-most boxes (not the decomposed boxes of the model structure).

Bundling    The process of combining several arrows into a common “pipeline” or conduit. The bundling of arrows on an IDEFO diagram is intended to match the arrows’ level of detail to that of the boxes.

Business process reengineering    An approach to analyzing and restructuring the processes of an enterprise.

Child    The decomposition of an activity box in an IDEFO model is typically called the activity’s “child” diagram. The parent of the diagram is the activity box that was decomposed to generate the child diagram.

Clustering    The process of combining several related activities into a more general activity. It is typically employed when the number of identified activities must be reduced to obey the “six or fewer” rule of IDEFO, that no diagram may have more than six boxes.

Decomposition    The original form of breakdown used to create a top-down function model in SADT and IDEFO. The process of decomposing an activity is to define the sub-activities without regard for the timing or the context of the activity. Other forms of breakdown include applying the activity at different points in time (for example, wash before bed or wash in the morning) or showing how the parent activity is used in different environments (for example, wash the car, wash the dishes, or wash the dog).

DoD    The Department of Defense of the United States. The DoD policy committee adopted IDEFO and IDEF1X as the standard methods to be used with their reengineering efforts in downsizing or reinventing their portion of the government.

DRE    A detailed reference expression is a shorthand text used to point to a specific location on a diagram in a model. A specific arrow head or tail, or one branch of an arrow with forks and joins, may be identified using a DRE. The DRE is also written outside and below the right-hand corner of an IDEFO box to indicate that a decomposition of that box exists, and to identify the C-number of that decomposition diagram. Another use of the DRE comes in conjunction with tunneled arrows, where the boundary arrow on a diagram does not connect to its parent diagram, but occurs elsewhere in the model. The DRE is used to identify the spot (source or target) of such a boundary arrow.

Enterprise    A company, a group of companies, or a coalition (industry, commercial, university, or government) organized together to accomplish a goal, a kind of system. In the Department of Defense, an enterprise might be the Army or the Navy, or a strike force assembled to meet a threat (for example, the Gulf War or the Somalia force).

Enterprise analysis    As defined by the Department of Transportation in a request for proposal: “The study of an enterprise to define its activities or functions; how the various functions performed in the enterprise are distributed and conducted; and the competitive, regulatory, and technical environment of the enterprise.”

External arrow    A boundary arrow that occurs on the top-most (A-0) diagram in an IDEFO model. An external arrow represents an interface between the model and its environment (things and happenings outside the model’s scope).

FEO    A for-exposition-only diagram is used by an author to convey an important point, but the FEO is not considered to be part of the formal IDEFO model. The purpose of an FEO is to expose some information about the diagram, such as the source and target of a specific arrow in the model. An FEO diagram is drawn on the same diagram form as a basic IDEFO diagram, and it is cross-referenced to its related IDEFO diagram through the “Used At” box in the upper-left corner of the diagram form.

ICOM    Stands for input, control, output, and mechanism, the four sides of a box on an IDEFO diagram. An ICOM is an off-page connector of the form “C2” or “Ol” (control number 2 or output number 1), and is used to link the arrow structure between IDEFO diagrams. Many computer support tools automatically generate ICOMs when decomposing an activity box, to remind the author that a connection is required to make the new diagram fit properly into the model structure. Through common practice, the term ICOM has come to mean any arrow on an IDEFO diagram, but it is not used as such in this book.

IDEF1X modeling method    An entity-attribute-relationship method of modeling the information structure of a topic. Typically used to analyze the information of an enterprise and to lay the foundation for building an integrated database on a computer.

Migration model    Depicts the process of changing the enterprise to implement the reengineering recommendations—the dynamics of changing the enterprise from the AS-IS to the TO-BE condition.

Parent diagram    The diagram one level of detail above the decomposition diagram. The parent is the diagram on which the decomposed activity box appears.

Purpose of a model    Defines why the model is developed. The purpose statement appears on the top-most diagram in the model structure (the A-0 diagram), and is typically in the form of the statement “This model will be used to. . .” The purpose is defined at the outset of an IDEFO modeling effort.

Reader    A person who has been trained in the syntax and semantics of IDEFO, and who is capable of examining an IDEFO model and understanding its content. A reader may or may not be trained in the creation of models.

Scope of the model    The subject matter that is covered by the model. The scope includes the starting and stopping point, as well as the type of subject matter covered. For example, a model of product development may or may not include the point at which it is conceptualized, or it may be restricted to the manufacturing of the product only. The end of the model may include delivery to the customer, or it may go all the way through the maintenance and after-sale customer support. Also, the scope may or may not include the development of its documentation or be restricted to the manufacturing of the physical product only. The model scope is defined at the start of a new IDEFO modeling effort.

System    Any combination of interacting elements organized to produce a desired end result. The elements may be people, procedures, information, resources, raw materials, machinery, tools, activities, functions, processes, and so on. The result may be a service or a product. The system may be a company, an enterprise or coalition made up of many companies, or a portion of a company, such as a division or a product group. For the model of a system to be useful, the modeling method must depict all of its elements, including all factors needed to control it, plan its future development, or manage its change.

Text    Material that accompanies a completed IDEFO model and is used to high-light features of the diagram. The text may employ DREs that point to specific items on the diagram.

TO-BE    An IDEFO model that depicts the operation of the enterprise after the changes resulting from the reengineering effort are implemented.

Viewpoint    The perspective used when emphasizing or deemphasizing aspects of a topic, such as whether an item should be included in the model or how highly it should be placed (the higher in the model structure, the more emphasis). A viewpoint typically represents a group of people with a common background and education (a common “culture”) in an enterprise, such as personnel in financial, quality assurance, sales, computer software, or management areas. A single viewpoint should be taken for an entire model. Models from other viewpoints may be developed separately and then linked to each other using DRE expressions. Mixing viewpoints on a single model typically obscures the model’s communication ability.