• +7 (812) 318-74-32
  • Новолитовская ул., дом 15Д, оф. 645
  • Понедельник-Пятница 9:00-18:00
Санкт-Петербург

IDEF0 methodology is an approach based on general description and function modeling of business processes methodology. It is based on the methodology of ICAM – Integrated Computer-Aided Manufacturing, which was used during the 1970s within U.S. Air Force Program for the development and creation of new types of aircrafts and spacecrafts.

Later the U.S. federal standard for Processing Technology – Federal Information Processing Standard, Publication 183, has been developed and put into effect in 1993 on that basis.
Currently, the standard is the basis for a general functional description and modeling of various business processes and is used in many enterprises and organizations that produce a wide variety of products and services.

IDEF0 is used to create a functional model that displays the structure and functions of the system, as well as the data and objects that inter-relate those functions.

The syntax of the graphic language IDEF0 is determined with absolute rigor; it is based on boxes and arrows connecting them to form a hierarchy of specified diagrams.

Figure 1. Hierarchy of diagrams in IDEF0.

Boxes represent some functions, defined as an activity, processes and transformations. Each function is described by a verb-based label placed in a box. There is a clear hierarchical numbering of blocks, which always allows identifying the location of each block in the overall set of diagrams.

There are four arrows classes: Input arrow, Output arrow, Control arrow, Mechanism arrow.

Figure 2. Classes of Arrows

Input and Output  – Inputs are shown as arrows entering the left side of the activity box while outputs are shown as exiting arrows on the right side of the box. Input and output represent the data, objects, materials, etc., relating to the functions performed by boxes. (these are usually recycled resources and results of the separate functions of boxes);

Mechanisms (are displayed as arrows entering from the bottom of the box) – represent a long-term resources needed to undertake relevant work (it may be specific workers, divisions of the organization, machinery, equipment, computer equipment, etc.);

Control (are displayed as arrows entering the top of the box ) – are the conditions, directives, guidelines, etc., managing the implementation of this function.

IDEF0 syntax – boxes, arrows, diagrams and rules.

Boxes represent functions, defined as an activity, process, operation or transformation. Arrows represent data or objects related to the functions. The rules define how to use components; the diagrams provide a format for graphical and verbal description of models. The format is the basis for model configuration management.

A Box describes a function. Within each box its name and number is placed. The name must be the verb or a verbal noun. The box number is placed in the lower right corner. Box numbers are used for their identification in the diagram and the corresponding text.

An Arrow is a directed line, composed of one or more arrow segments and an arrowhead at one end. Segments of the arrows can be straight or broken lines; in the latter case the horizontal and vertical arrow segments are conjugated with arcs having an angle of 90°. Arrows don’t represent a stream or sequence of events, as in traditional flow charts. They only show, which data or objects must be conveyed to the input of function in order this function to be performed.

Box syntax:

  • The size of the box should be sufficient to include the function name and number;
  • The box is a rectangle with right angles;
  • The box should be drawn by solid lines.

Arrow syntax:

  • Broken arrows change direction only at 90°;
  • Arrows should be drawn by solid lines. Lines of varying thickness can be used;
  • Arrows can only consist of vertical or horizontal segments; segments directed along the diagonal, are not permitted;
  • Ends of the arrows should touch the outer limit of the functional box, but should not cross it;
  • Arrows should touch the box on its sides. Joining in the corners is not allowed.

IDEF0-model consists of there types of documents:

  • Graphical diagrams,
  • Text,
  • Glossary.

These documents are cross-referenced to each other. The Graphical diagram is the main component of the IDEF0-model containing boxes, arrows, combination of boxes and arrows and their associated relationships. Boxes represent the basic functions of the object being modeled. These functions can be decomposed into its components and presented in the form of more detailed diagrams. Decomposition continues to the moment when the object is detailed enough to achieve the goals of the particular project.

Another concept of IDEF0 is a glossary. For each of the elements of IDEF0: diagrams, boxes, arrows, the existing standard means creation and maintaining a set of related definitions, keywords, and summaries, etc., which characterize the object displayed by this element. This set is a glossary and is a description of the nature of the item. A Glossary harmoniously complements the visual graphic language, providing diagrams with additional information.

Diagram of the top level provides the most general description of the modeling object. A series of child diagrams that provide a more detailed representation of the object follow below.

Each model must have the Top Level Context Diagram at which the modeling object is represented by a single block with boundary arrows. This diagram is called A-0 (A minus zero). The arrows in this diagram reflect the connection of the modeling object with the environment. As a single box represent the whole object, its name is common for the entire project. The same is true for all arrows in the diagram because they represent a complete set of external interfaces of the object. Diagram А–0 sets the modeling scope and its boundary.

Figure 3. Example of the Top level context diagram.

The context diagram A-0 should also contain brief statements, defining the point of view of an officer or a department, from a position of which a model was created, and the purpose this model was elaborated for. The purpose expresses the reason of the model creation, i.e. it contains a list of questions that must meet a model that determines its structure to the great extent. The most important properties of an object are usually detected in the top levels of hierarchy, as the top level function is being decomposed and split into sub-functions, these properties are specified. Each sub-function, in turn, is decomposed into elements of the next level, and decomposition is lasting until a structure that allows answering the questions posed in the purpose of modeling will be obtained. Each sub-function is modeled by a separate box. Every parent box is described in details by the child diagram at a lower level. All child diagrams must be within the top level context diagram.

Often there are cases where there is no sense to consider some arrows in child diagrams lower of a certain level in the hierarchy, or vice versa – some boxes have no practical meaning above a certain level. On the other hand, it is sometimes necessary to get rid of some “conceptual” arrows and do not detail them lower of a certain level. To solve these problems the concept of tunneling is provided by the IDEF0 standard. The notation “tunnel” in a form of two parentheses around the beginning of the arrow indicates that this arrow was not inherited from the parent functional box and appeared (from the “tunnel”) only in this diagram. In turn, the same symbol around the end of the arrow close to the receiving box means that in the diagram, which is a child for this box, this arrow will not be presented or considered. Most often some objects and corresponding interface arrows are not considered at some intermediate levels of the hierarchy – in this case they first “enter the tunnel” and then, if necessary, “return from the tunnel”.

Visibility of the graphical language IDEF0 makes the model quite readable, including those who did not participate in its creation, as well as efficient for demonstrations and presentations. Later, on the basis of the developed model new projects can be organized, targeting to changes in an enterprise (system).

In carrying out complex enterprise surveys, development of models in IDEF0 allows you to visualize and effectively convey the whole machinery of the company in the right perspective. But most importantly it is an opportunity to work collectively provided by IDEF0.