IDEF6 or Integrated Definition for Design Rationale Capture is a method to facilitate the acquisition, representation, and manipulation of the design rationale

Design Rationale

A Design Rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R...

 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

Theory of justification

Theory of justification is a part of epistemology that attempts to understand the justification of propositions and beliefs. Epistemologists are concerned with various epistemic features of belief, which include the ideas of justification, warrant, rationality, and probability...

 is the reason

Reason

Reason is a term that refers to the capacity human beings have to make sense of things, to establish and verify facts, and to change or justify practices, institutions, and beliefs. It is closely associated with such characteristically human activities as philosophy, science, language, ...

, justification

Justification

Justification may refer to:*Theory of justification, a part of epistemology that attempts to understand the justification of propositions and beliefs*Justification , defence in a prosecution for a criminal offense...

, underlying motivation

Motivation

Motivation is the driving force by which humans achieve their goals. Motivation is said to be intrinsic or extrinsic. The term is generally used for humans but it can also be used to describe the causes for animal behavior as well. This article refers to human motivation...

, or excuse that moved the designer

Designer

A designer is a person who designs. More formally, a designer is an agent that "specifies the structural properties of a design object". In practice, anyone who creates tangible or intangible objects, such as consumer products, processes, laws, games and graphics, is referred to as a...

 to select a particular strategy

Strategy

Strategy, a word of military origin, refers to a plan of action designed to achieve a particular goal. In military usage strategy is distinct from tactics, which are concerned with the conduct of an engagement, while strategy is concerned with how different engagements are linked...

 or design

Design

Design as a noun informally refers to a plan or convention for the construction of an object or a system while “to design” refers to making this plan...

 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 the what the design is (i.e., on the final product, rather than why the design is the way it is).

This method is part of the IDEF

IDEF

IDEF, an abbreviation of Integration Definition, refers to a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. These "definition...

 family of modeling language

Modeling language

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules...

s in the field of systems

Systems engineering

Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...

 and software engineering

Software engineering

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...

.

Overview

When explicitly captured, design rationale

Design Rationale

A Design Rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R...

 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.

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

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

Use case

In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...

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

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.

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.

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.

Formulate Goals and Requirements
Once the needs for the design transition have been identified, the designer formulates

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.

Formulate Solution Strategies

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:

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.