Chapter 26--Design rationale Overview • Documenting design rationale – reasoning or rationale behind software design – why the product is the way it is – benefits to new team members, design team members, end users; can aid reuse – methodologies to control how much is captured (e.g., important or contentious decisions) • Three approaches to documenting design rationale –IBIS – Design Space Analysis – Claims Analysis IBIS (Issue-Based Information System) • Captures design decisions as by-product of the design process • Deliberation about pros and cons of alternative answers to questions –issues: questions – positions: answers – arguments: pros and cons for or against position • Process begins with root issue. Positions and arguments then put forward. Can generate secondary issues, etc., eventually reaching a solution. • Issues and relationships charted on issue map IBIS issue maps relationships • more general than Where should the walls be • similar to located? • replaces temporal similar • temporal successor of successor • logical successor of Where should the doors be located? IBIS problems • Dependencies not handled: whether the answer to one question relied on the answer to another • Only questions that become issues (e.g., are deliberated) are represented on issue map IBIS implementations • New versions of IBIS developed (hypertext) – PHI (Procedural Hierarchy of Issues) • represents all issues • introduces hierarchy in relationships – notion of which issues serve the current issue and which issues does it serve • arguments not categorized as “pro” or “con” issue • restricts order in which issues can be raised – generate hierarchy top-down (starting with “prime) – perform sub-issue generation breadth first – gIBIS (graphical IBIS) Design Space Analysis • Exploration of alternatives • QOC: Questions, Options, and Criteria C: Criterion 1 O: Option A Q: Question? C: Criterion 2 O: Option B C: criterion 3 Positive relationship Negative relationship Q: Consequent question? QOC notation C: Attractive display O: many C: Fast loading Q: How many graphics? O: few C: High-tech image C: Useful information Claims Analysis • Claim: relates some aspect of system’s design with an important consequence for the user • Claims analysis – create scenarios of system’s use – analyze them for claims – include core tasks and key errors – identifies positive support for user and tradeoffs – Example: cash machine design. What claims about system’s use, its users, and its environment does the cash machine design embody? • Claims analysis concentrates on refining one design.