page_title: IDEF6
section_title: Procedure Developments
hierarchical_section_title: IDEF6 / IDEF6 topics / Procedure Developments
caption_attribution_description: English: 85. Functions and Use Scenarios Mapping to Requirements and Goals
context_page_description: 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.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.
  IDEF6 is part of the IDEF family of modeling languages in the field of systems and software engineering.
context_section_description: 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 cases 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
  requirements that the solution must satisfy and
  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.
caption: 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.
exif: {}