IDEF6 or 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.[1] 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).
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:[2]
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.[2]
IDEF6 will be a method that possesses the conceptual resources and linguistic capabilities needed [3]
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.[3]
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:
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 andexpectations that led up to these steps, and the results of each step.
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.
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 inthe 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[4] 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.
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.
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:
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.