Design Rationale: Capture Methods, Representations, and Argumentation Models

Design Rationale: Capture Methods, Representations, and Argumentation Models

In the complex process of system development, understanding design rationale (DR)—the reasons behind why specific design decisions were made—is critical for long-term maintenance and iterative improvement. Design rationale provides the context that explains the "why" behind a solution, rather than just the "what." To effectively manage this information, designers must consider how rationale is captured, how it is represented, and how it can be utilized throughout the project lifecycle.

Key Facts

  • Rationale Capture is the process of acquiring design reasoning for management systems.
  • Representations range from informal (natural language) to formal (strict computer-readable formats), with semiformal acting as a hybrid.
  • Argumentation Models like Toulmin and IBIS provide structured ways to document the logic behind decisions.
  • Stakeholder Negotiation is a core component of models like the WinWin Spiral Model to ensure mutually satisfactory agreements.

Rationale Capture Methods

Capturing design rationale involves various strategies, each balancing the trade-off between the cost of capture and the richness of the data collected.

Manual and Observational Methods

  • Reconstruction: Rationales are captured in raw formats (e.g., video) and later structured. This avoids disrupting the designer but can be costly and prone to the bias of the person reconstructing the data.
  • Record-and-Replay: This method captures rationales as they happen, either synchronously via video conferencing or asynchronously through email and bulletin boards. It works best when informal or semi-formal representations are already in place.
  • Historian: A person or program observes all designer actions without offering suggestions, capturing the rationale during the active design process.

Systematic and Automated Methods

  • Methodological Byproduct: Rationales are captured following a specific schema during the design process. While low-cost, creating an effective schema is challenging.
  • Apprentice: Utilizing a pre-existing knowledge base (KB), the system captures rationale by asking the designer questions when it encounters confusing or disagreeing actions.
  • Automatic Generation: Rationales are generated from execution history. This ensures consistency and up-to-date records at a low capture cost, though the initial complexity of the machine-learning problems required to compile history is high.

[ไม่มีภาพประกอบ]

Rationale Representation

The way design rationale is represented determines how efficiently it can be used and interpreted. These representations are generally categorized by their degree of formality.

  • Informal Representation: Uses traditional media such as word processors, audio/video recordings, or handwriting. While easy to produce, these are difficult for computers to interpret automatically.
  • Formal Representation: Requires a strict format for computer interpretation. While powerful for automation, it is often intrusive for the designer and difficult for humans to read.
  • Semiformal Representation: A hybrid approach that uses templates or natural language descriptions to provide computer-processable data without being overly intrusive.

Argumentation-Based Models

Many semiformal representations use argumentation to structure the logic of design decisions. Several established models provide different frameworks for this process.

Foundational Models

The Toulmin model is one of the earliest argumentation frameworks, using six steps: making a claim, providing supporting data, establishing a warrant (evidence of relations), providing backing for the warrant, adding model qualifiers (e.g., "most" or "some"), and considering possible rebuttals. Its primary strength is the use of concepts easily understood by most people.

The Issue-Based Information System (IBIS) is an argumentative notation rather than a software system. It uses nodes—such as issues, positions, arguments, and resolutions—linked by relationships like "logical successor to" or "replaces." This was further extended by the Procedural Hierarchy of Issues (PHI), which introduced subissue relationships to handle noncontroversial issues where one resolution depends on another.

Analysis and Decision Languages

  • Questions, Options, and Criteria (QOC): Used for design space analysis, QOC identifies problems as questions and answers as options. It uses criteria to evaluate options, with links defined as assessments.
  • Decision Representation Language (DRL): Focuses on the decision-making process using elements like decision problems, alternatives, goals, claims, and groups.
  • RATSpeak: An evolution of DRL used in SEURAT, it incorporates functional and non-functional requirements and utilizes an Argument Ontology to categorize claim types.

Collaborative and Intent-Based Models

The WinWin Spiral Model integrates negotiation into the software development spiral. It identifies stakeholders and their "Win conditions." Conflicts between these conditions become Issues, which are resolved through Options and trade-offs, resulting in an Agreement. This process reduces capture overhead by embedding rationale collection within a defined negotiation process.

The Design Recommendation and Intent Model (DRIM), used in SHARED-DRIM, centers on proposals. A proposal includes the designer's intents, recommendations to satisfy those intents, and justifications. Even unaccepted recommendations are recorded, providing valuable data for future iterations or system maintenance.

[ไม่มีภาพประกอบ]

Summary of Design Rationale Models

Comparison of Common Design Rationale Frameworks
Model Primary Focus Key Elements
Toulmin Logical Argumentation Claims, Data, Warrants, Backing, Qualifiers, Rebuttals
IBIS Issue Discussion Issues, Positions, Arguments, Resolutions
QOC Design Space Analysis Questions, Options, Criteria, Assessments
DRL Decision Making Decision Problems, Alternatives, Goals, Claims
WinWin Stakeholder Negotiation Win Conditions, Issues, Options, Agreements
DRIM Designer Intent Intents, Recommendations, Justifications

Frequently Asked Questions

What is the difference between informal and formal rationale representation?

Informal representation uses natural media like text or video, making it easy for humans to create but hard for computers to analyze. Formal representation uses strict formats that computers can interpret easily, but it is often difficult for humans to read and can be intrusive to the design process.

How does the WinWin Spiral Model handle conflicts?

In the WinWin Spiral Model, conflicts between the "Win conditions" of different stakeholders are captured as Issues. Stakeholders then propose Options and explore trade-offs to reach a mutually satisfactory Agreement.

What are the advantages of the Reconstruction capture method?

The Reconstruction method allows rationales to be captured in a raw form (such as video) without disrupting the designer's workflow. The information is then structured later, allowing for a more careful capture of the reasoning.

What is the purpose of the QOC model?

The Questions, Options, and Criteria (QOC) model is specifically used for design space analysis. It helps designers identify key problems as questions, propose possible answers as options, and use specific criteria to evaluate those options through assessments.

How does the Apprentice method capture rationale?

The Apprentice method uses a pre-established knowledge base to monitor the designer. When the system encounters an action that is confusing or contradicts the knowledge base, it asks the designer questions to capture the underlying rationale.

References

  1. Kunz, W.; Rittel, H. (1970), Issues as elements of information systems. Working Paper 131, Center for Urban and Regional Development, University of California Berkeley
  2. Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Design Rationale for Software Engineering: A Survey", 25th Hawaii International Conference on System Sciences, 2, pp. 577-586
  3. Horner, J.; Atwood, M.E. (2006), "Effective Design Rationale: Understanding the Barriers", in Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering, Springer Berlin Heidelberg, pp. 73-90
  4. Lee, J. (1997). "Design Rationale Systems: Understanding the Issues". IEEE Expert 12 (3): 78–85
  5. Burge, J.E.; Brown, D.C. (2000), "Reasoning with Design Rationale", in Gero, J., Artificial Intelligence in Design '00, Netherlands: Kluwer Academic Publ., pp. 611–629