Rationale captures the motivation behind a decision, and consists of:
- The issue to be decided
- Alternatives that were considered
- The criteria used to judge alternatives
- Argumentation for and against various alternatives
- Decisions made as a result of discussions
12.3.1 - Centralized Traffic Control
12.3.2 - Defining the Problem: Issues
12.3.3 - Exploring the Solution Space: Proposals
12.3.4 - Evaluating the Solution Space: Criteria and Arguments
12.3.5 - Collapsing the Solution Space: Resolutions
12.3.6 - Implementing Resolutions: Action Items
12.3.7 - Examples of Issue-Based Models and Systems
Issue-Based Information System
Decision Representation Language
Questions, Options, and Criteria
The NFR Framework
12.4.1 - CTC System Design
12.4.2 - Capturing Rationale in Meetings
12.4.3 - Capturing Rationale Asynchronously
12.4.4 - Capturing Rationale when Discussing Change
12.4.5 - Reconstructing Rationale
12.5.1 - Documenting Rationale
12.5.2 - Assigning Responsibilities
- Minute Taker
- Rationale Editor
- Reviewer
- Heuristics:
- One minute taker per team
- One rationale editor per project
- Increase number of reviewers after delivery. ( Reassign developers while rationale is still fresh in their heads. )
12.5.3 - Heuristics for Communicating about Rationale
- Name issues consistently
- Centralize issues
- Cross-reference issues and system elements
- Manage change
12.5.4 - Issue Modeling and Negotiation
The Harvard method for negotiation tries to reduce antagonism by the following heuristics:
- Separate developers from proposals. A judgement about a proposal should not be seen as a judgement of the developer who made it.
- Focus on criteria, not proposals. Once everyone can agree on criteria, the criteria will determine the best proposal.
- Take into account all criteria, instead of maximizing a single one.
12.5.5 - Conflict Resolution Strategies
Five Examples:
- Majority wins
- Owner has last word
- Management is always right
- Expert is always right
- Time decides