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. 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.

Overview 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:

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.

IDEF6 will be a method that possesses the conceptual resources and linguistic capabilities needed

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. 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.

IDEF6 topics

Basic concepts 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.

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.

Procedure developments

… excerpt ends here. Continue reading the full article.