1 / 11

ASSUMPTIONS IN DESIGN AND IN DESIGN RATIONALE

ASSUMPTIONS IN DESIGN AND IN DESIGN RATIONALE. DAVID C. BROWN Computer Science Department WPI, Worcester, MA 01609, USA dcb@cs.wpi.edu. Definition: An Assumption is…. An assuming that something is true A fact or statement (as a proposition, axiom, postulate, or notion) taken for granted

Download Presentation

ASSUMPTIONS IN DESIGN AND IN DESIGN RATIONALE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ASSUMPTIONS IN DESIGN AND IN DESIGN RATIONALE DAVID C. BROWN Computer Science Department WPI, Worcester, MA 01609, USA dcb@cs.wpi.edu

  2. Definition: An Assumption is… • An assuming that something is true • A fact or statement (as a proposition, axiom, postulate, or notion) taken for granted • Something which is accepted in the absence of evidence to the contrary

  3. Motivation • Designers make both explicit and tacit assumptions • Decisions can be based on assumptions • Design reuse and modification can violate assumptions • Violated assumptions cause failure

  4. Motivation • Help the designer avoid failures by making assumptions more visible • Collect/infer and record assumptions • Retrieve/infer and use assumptionsto alert designer • Use assumptions to evaluate design decision reliability • At design, redesign, or reuse time

  5. Causes • Lack of knowledge • e.g., no knowledge of temperature of part, assume no thermal expansion of part • Simplify problem & constrain design space • e.g., assume friction is negligible • e.g., assume right-handed user • Standardize the problem • e.g., with “standard” NFRs • e.g., with Reqs from similar projects

  6. Causes • Make a general statement rather than a specific one • e.g., assume that differences are not significant • Different tools inherit/encourage different assumptions • e.g., sketching vs. CAD vs. flowcharting • e.g., models with no mass, no friction

  7. Causes • Cultural pressure • e.g., design trends/fads, such as “streamlining”, bring assumptions about preferences • The arrogance of experts • e.g., familiarity, old technology, and continued successful deployment, hide past assumptions

  8. Causes • Ambiguity in Requirements • e.g., assumptions about what the requirements mean • Rules, norms and conventions • e.g., rules have applicability assumptions,so rule use adopts those assumptions

  9. Causes • Desire to break away from routineness • e.g., deliberately made, perhaps incorrect, assumptions might take the design into a different search space, leading to creative results • Assumptions are the norm in everyday activity • e.g., life would be too complex if we didn't make them

  10. Detection & Capture • Sample detection methods • Noticing mismatches between actual and intended behaviours • Challenging assumptions by using “what if” questions • Inference using design rationale • Sample capture methods • direct (explicit capture) • by inference (implicit capture)

  11. DR for Decisions & Assumptions • Explicit assumptions can be part of rationale for decision • e.g., select due to low cost & high strength, where low cost is assumed to be important • Similarly for inferred tacit assumptions • Assumptions themselves may have rationale • e.g., low cost is assumed, as it was important last time this was designed

More Related