IDEF6

IDEF6 (Integrated Definition for Design Rationale Capture) is a method to facilitate the acquisition, representation, and manipulation of the design rationale used in the development of enterprise systems. This method, that wants to define the motives that drive the decision-making process, is still in development.^[2] Rationale is the reason, justification, underlying motivation, or excuse that moved the designer to select a particular strategy or design feature. More simply, rationale is interpreted as the answer to the question, “Why is this design being done in this manner?” Most design methods focus on what the design is (i.e., on the final product, rather than why the design is the way it is).^[1]

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

When explicitly captured, design rationale typically exists in the form of unstructured textual comments. In addition to making it difficult, if not impossible to find relevant information on demand, lack of a structured method for organizing and providing completeness criteria for design rationale capture makes it unlikely that important information will be documented. Unlike design methods which serve to document WHAT a design is (Design Specification), the IDEF6 Design Rationale Capture Method is targeted at capturing:^[3]

• WHY a design is the way it is
• WHY it is not manifested in some other form, and
• HOW the final design configuration was reached.

IDEF6 was intended to be a method with the representational capability to capture information system design rationale and associate that rationale with the design models and documentation for the end system. Thus, IDEF6 attempts to capture the logic underlying the decisions contributing to, or resulting in, the final design. The explicit capture of design rationale serves to help avoid repeating past mistakes, provides a direct means for determining the impact of proposed design changes, forces the explicit statement of goals and assumptions, and aids in the communication of final system specifications.^[3]

IDEF6 will be a method that possesses the conceptual resources and linguistic capabilities needed ^[4]

• to represent the nature and structure of the information that constitutes design rationale within a given system, and
• to associate that rationale with design specifications, models, and documentation for the system.

The scope of IDEF6 applicability covers all phases of the information system development process, from initial conceptualization through both preliminary and detailed design activities. To the extent that detailed design decisions for software systems are relegated to the coding phase, the IDEF6 technique should be usable during the software construction process as well.^[4]

Design rationale becomes important when a design decision is not completely determined by the constraints of the situation. Thus, decision points must be identified, the situations and constraints associated with those decision points must be defined, and if options exist, the rationale for the chosen option and for discarding other options (i.e., those design options not chosen) must be recorded. The task of capturing design rationale serves the following purposes:

• Enables evolutionary integration of enterprise information systems.
• Enables the use of concurrent engineering methods in information systems development.
• Supports better integration among life-cycle artifacts.
• Facilitates business reengineering by capturing the rationale behind business case decisions.
• Enables efficient traceability of decisions.

Rationale capture is applicable to all phases of the system development process. The intended users of IDEF6 include business system engineers, information systems designers, software designers, systems development project managers, and programmers.

Design rationale (why and how), can be contrasted with the related notions of design specification (what), and design history (steps taken). Design specifications describe what intent should be realized in the final physical artifact. Design rationale describes why the design specification is the way it is. This includes such information as principles and philosophy of operation, models of correct behavior, and models of how the artifact behaves as it fails. The design process history records the steps that were taken, the plans and expectations that led up to these steps, and the results of each step.^[1]

• Design Rationale Phenomena : A general characterization of design rationale can be given as: “The beliefs and facts as well as their organization that the human uses to make (or justify) design commitments and to propagate those commitments.”
• Design Rationale Capture Issues : One reason for the loss of rationale is rooted in the long time lag between specification of the software artifact and completion of the artifact. There are also problems with developing a general understanding of what should constitute explicitly captured Design Rationale. That is, a notable difficulty with expressing design rationale is that the concept itself is not uniformly understood. It shares this characteristic with all other forms of “explanation” that Artificial Intelligence (AI) researchers continue to struggle with.

In IDEF6, the rationale capture procedure involves partitioning, classification/ specification, assembly, simulation/execution, and re-partitioning activities. The rationale capture procedure normally applied in the simulation/execution activity of the evolving design uses two phases: Phase I describes the problem and Phase II develops a solution strategy.^[1]

Design is an iterative procedure involving partitioning, classification/specification, assembly, simulation, and re-partitioning activities, see Figure. First, the design is partitioned into design artifacts. Each artifact is either classified against existing design artifacts or an external specification is developed for it. The external specification enables the internal specification of the design artifact to be delegated and performed concurrently. After classification/specification, the interfaces between the design artifacts are specified in the assembly activity (i.e., static, dynamic, and behavioral models detailing different aspects of the interaction between design artifacts are developed). While the models are developed, it is important to simulate use scenarios or use cases^[5] between design artifacts to uncover design flaws. By analyzing these flaws, the designer can re-arrange the existing models and simulate them until the designer is satisfied. The observed design flaws and the actions contemplated and taken for each are the basis of the design rationale capture procedure.^[1]

Identify problems

The designer identifies problems in the current design state by stepping through the use cases in the requirements model to validate that the design satisfies requirements and to verify that the design will function as intended. The designer records symptoms or concerns about the current design state. A symptom is an observation of an operational failure or undesirable condition in the existing design. A concern is an observation of an anticipated failure or undesirable condition in the existing design.^[1]

Identify constraints

The designer then identifies the constraints that the problems violate or potentially violate. These constraints include requirements, goals, physical laws, conventions, assumptions, models, and resources. Because the activities and processes in the use case scenarios map to requirements and goals, the failure of the design in any use case activity or process can be traced directly to requirements statements and goal statements.^[1]

Identify needs

The designer then identifies the necessary conditions or needs for solving the problems. A need is a necessary condition that must be met if a particular problem or set of problems is to be solved. It is possible that the needs statement will have to describe the essentiality for relaxing requirements and goal constraints governing the design.^[1]

Formulate goals and requirements

Once the needs for the design transition have been identified, the designer formulates^[1]

1. requirements that the solution must satisfy and
2. goals that the solution should attempt to satisfy.

A requirement is a constraint on either the functional, behavioral, physical, or method of development aspects of a solution. A design goal is a stated aim that the design structure and specifications must support.

Once the requirements and goals have been established, the design team formulates alternative strategies for exploration in the next major transition in the design.^[1]

Design strategies can be considered as “meta-plans” for dealing with frequently occurring design situations. They can be viewed as methodizations or organizations of the primitive design activities identified above (i.e., partitioning, classification/specification, assembly, simulation, and re-partitioning). The three types of design strategies considered in the IDEF4 rationale component include:

1. External-constraint-driven design—Design carried out under situations where the goals, intentions, and requirements are not characterized well, much less defined. These situations often result when the designer is brought into the product development process too early.
2. Characteristic-driven design—Design in a closely controlled situation where strict accountability and proof of adequacy are rigidly enforced. These design situations often involve potentially life-threatening situations.
3. Carry-over-driven design—Sometimes referred to as “routine” design.

In summary, design as a cognitive endeavor shares many characteristics with other activities such as planning and diagnosis. But, design is distinguished by the context in which it is performed, the generic activities involved, the strategies employed, and the types of knowledge applied. A major distinguishing characteristic is the focus of the design process on the creation (refinement, analysis, etc.) of a specification of the end product.^[1]