IDEF6

Last updated
IDEF6 model of IDEF4 Design Activities IIDEF4 Design Activities.jpg
IDEF6 model of IDEF4 Design Activities

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

Contents

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: [3]

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]

The predominant modes of design commonly found in information system development Modes of Design.jpg
The predominant modes of design commonly found in information system development

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

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:

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. [1]

Procedure developments

A design partition called Sys, showing its constituent static and dynamic models, as well as its associated requirements model. The requirements model contains an IDEF0 function model whose activities call out IDEF3 process scenarios. Static, Dynamic, and Requirements Models for Sys Partition.jpg
A design partition called Sys, showing its constituent static and dynamic models, as well as its associated requirements model. The requirements model contains an IDEF0 function model whose activities call out IDEF3 process scenarios.
Mapping between the analysis model's function and use scenarios and the requirements and goal statements. When the design fails to adequately support activities and use scenarios, the requirements model allows the designer to easily identify the requirements constraints or goal statements that have been violated. Functions and Use Scenarios Mapping to Requirements and Goals.jpg
Mapping between the analysis model’s function and use scenarios and the requirements and goal statements. When the design fails to adequately support activities and use scenarios, the requirements model allows the designer to easily identify the requirements constraints or goal statements that have been violated.

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.

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

Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by verification and validation. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to:

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">Spiral model</span> Software development process model

The spiral model is a risk-driven software development process model. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

<span class="mw-page-title-main">IDEF</span> Family of modeling languages

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is 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 and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

User-centered design (UCD) or user-driven development (UDD) is a framework of process in which usability goals, user characteristics, environment, tasks and workflow of a product, service or process are given extensive attention at each stage of the design process. These tests are conducted with/without actual users during each stage of the process from requirements, pre-production models and post production, completing a circle of proof back to and ensuring that "development proceeds with the user as the center of focus." Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively the first-time users of their design experiences, and what each user's learning curve may look like. User-centered design is based on the understanding of a user, their demands, priorities and experiences and when used, is known to lead to an increased product usefulness and usability as it delivers satisfaction to the user.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

The Information Services Procurement Library (ISPL) is a best practice library for the management of Information Technology related acquisition processes. It helps both the customer and supplier organization to achieve the desired quality using the corresponded amount of time and money by providing methods and best practices for risk management, contract management, and planning. ISPL focuses on the relationship between the customer and supplier organization: It helps constructing the request for proposal, it helps constructing the contract and delivery plan according to the project situation and risks, and it helps monitoring the delivery phase. ISPL is a unique Information Technology method because where most other Information Technology methods and frameworks focus on development, ISPL focuses purely on the procurement of information services. The target audience for ISPL consists of procurement managers, acquisition managers, programme managers, contract managers, facilities managers, service level managers, and project managers in the IT area. Because of ISPL's focus on procurement it is very suitable to be used with ITIL and PRINCE2.

<span class="mw-page-title-main">Structured analysis</span>

In software engineering, structured analysis (SA) and structured design (SD) are methods for analyzing business requirements and developing specifications for converting practices into computer programs, hardware configurations, and related manual procedures.

<span class="mw-page-title-main">Design rationale</span>

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. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to the political, collaborative process of addressing wicked problems.

Digital Prototyping gives conceptual design, engineering, manufacturing, and sales and marketing departments the ability to virtually explore a complete product before it's built. Industrial designers, manufacturers, and engineers use Digital Prototyping to design, iterate, optimize, validate, and visualize their products digitally throughout the product development process. Innovative digital prototypes can be created via CAutoD through intelligent and near-optimal iterations, meeting multiple design objectives, identifying multiple figures of merit, and reducing development gearing and time-to-market. Marketers also use Digital Prototyping to create photorealistic renderings and animations of products prior to manufacturing. Companies often adopt Digital Prototyping with the goal of improving communication between product development stakeholders, getting products to market faster, and facilitating product innovation.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

<span class="mw-page-title-main">IDEF4</span>

IDEF4, or Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language for the design of component-based client/server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation. It specifies design objects with sufficient detail to enable source code generation.

<span class="mw-page-title-main">Method engineering</span> Term

Method engineering in the "field of information systems is the discipline to construct new methods from existing methods". It focuses on "the design, construction and evaluation of methods, techniques and support tools for information systems development".

References

  1. 1 2 3 4 5 6 7 8 9 10 11 Richard J. Mayer (1995) et al. Information Integration for Concurrent Engineering (IICE) Compendium of methods report. Wright-Patterson Air Force Base, Ohio 45433-7604.
  2. ↑ Andrew P. Sage, William B. Rouse (2009). Handbook of Systems Engineering and Management John Wiley and Sons. ISBN   0-470-08353-0, p. 427.
  3. 1 2 IDEF6: A Design Rationale Capture Method Concept Paper Abstract. Accessed July 17, 2009.
  4. 1 2 Richard J. Mayer, Patricia A. Griffith & Christopher P. Menzel (1990-91) "IDEF6: A Design Rationale Capture Method Concept Paper" Archived 2007-04-02 at the Wayback Machine Defense Technical Information Center
  5. ↑ Ivar Jacobson, M. Ericsson & A. Jacobson (1994). The Object Advantage: Business Process Reengineering With Object Technology (ACM Press). Addison-Wesley, ISBN   0-201-42289-1
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.