Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
22‐6‐2013
1
The Role of Goals in Design Reasoning
Roel Wieringa
University of Twente
The Netherlands
i‐star'13 Workshop © Roel Wieringa 18th june 2013 1
Outline
1. Goals
2. Design reasoning
i‐star'13 Workshop © Roel Wieringa 18th june 2013 2
22‐6‐2013
2
• Rethinking goals
• Background: Systems engineering, product design, marketing, some logic, some philosophy of science
i‐star'13 Workshop © Roel Wieringa 18th june 2013 3
Desire
• To live is to desire
• Designers produce objects of desire
i‐star'13 Workshop © Roel Wieringa 18th june 2013 4
22‐6‐2013
3
Fear
• To live is to have fears
• Designers produce objects of fear
i‐star'13 Workshop © Roel Wieringa 18th june 2013 5
• Desires and fears are feelings of stakeholders.
• A stakeholder is a biological or legal person affected by solving a problem
• Actors without desires or fears cannot be stakeholders
• Stakeholders have something to lose and to gain.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 6
22‐6‐2013
4
Stakeholder awareness and commitment
i‐star'13 Workshop © Roel Wieringa 18th june 2013 7
Not aware:Some possibility that
stakeholders are not aware of
Passively aware:Aware, but not important enough to do something
Aware & Committed:Resources committed to act for a
goal
Stakeholder makes resources (time, money) available
•Possibility to receive satellite TV in car
• We could upgrade car DVD player to TV
•Invest in car satellite TV
An event pushes the possibility into awareness
Bossworth. Solution Selling. Creating Buyers in Difficult Markets. 1995.
Possible worlds
• Technology is the creation of new possibilities
• Most stakeholders are not aware of most possibilities
– People would get stuck in livelock if they tried to consider allpossibilities for action every time they wanted to act
– We are creatures of habit and prejudice
i‐star'13 Workshop © Roel Wieringa 18th june 2013 8
22‐6‐2013
5
Value• Awareness of a possibility involves valuation of the possibility
– Also called utility
– Positive (desire), negative (fear) or indifferent
• Desires, fears, indifferences
– Desires to save energy, watch TV in a car, reduce travelingtime, …
– Fears to use more petrol, get car‐sick, get stuck on an airport, …
– Disinterested in saving energy, watching TV in a car, maintaining privacy, getting a small fine for speeding, socialnetworks, the latest gizmo, …
i‐star'13 Workshop © Roel Wieringa 18th june 2013 9
Anything can be the object of desire, fearor indifference
• Desires, fears and indifference are mental states: – They can be directed upon anything, whether real or imaginary– Every mental state is about something– They can even be about desire, fear or indifference
i‐star'13 Workshop © Roel Wieringa 18th june 2013 10
SW components, systems
HW components, systems
People attachpositive, negativeor zero value to …
Organizations
Business processes
Services Methods
TechniquesConceptualstructures
Values
Desires Goals
Norms
Resources
...Fears
22‐6‐2013
6
i‐star'13 Workshop © Roel Wieringa 18th june 2013 11
Artifact
SW component, system,HW component, system,Organization,Business process,Service,Method,Conceptual structure, ...
Problem context
SW components & systems, HW components & systems,
People,
Organizations,Business processes, Services,Methods, Techniques,Conceptual structures, Values, Desires, Fears, Indifferences, Goals, Norms, Resources, ...
Interaction
• Summary so far:
– A goal of a stakeholder is a desire for which the stakeholder has committed resources (time and money) toachieve it
– Anything can be the object of desire
– No goals without stakeholders
i‐star'13 Workshop © Roel Wieringa 18th june 2013 12
22‐6‐2013
7
Conflicts
i‐star'13 Workshop © Roel Wieringa 18th june 2013 13
The multitude of desires
• Any one stakeholder may have infinitely manypotential desires, fears and indifferences
– (most of which he is unaware)
• Two or more stakeholders may all have different desires, fears and indifferences
• Desires are usually bigger than reality
– They conflict
i‐star'13 Workshop © Roel Wieringa 18th june 2013 14
22‐6‐2013
8
Conflicting desires• Logical conflict:
– Analysis of the descriptions of the desires shows that both descriptionshave opposite meaning; they are logically inconsistent.
– Spend your money and keep it
– Stakeholder is incoherent
• Physical conflict: – Realization of one desire makes realization of the other physically
impossible.
– Add TV to a car and reduce weight without changing anything else
– Stakeholder lives in a phantasy world
• Technical conflict: – There is currently no technology to realize both desires in the same
artifact.
– Secure and user‐friendly system
– New technology may remove the conflict
i‐star'13 Workshop © Roel Wieringa 18th june 2013 15
Roel2
• Economic conflict
– Desire bigger than the budget
• Legal conflict
– Desire conflicts with legal norm
• Moral conflict
– Desire conflicts with moral norm
i‐star'13 Workshop © Roel Wieringa 18th june 2013 16
Slide 15
Roel2 give linguistic tests to distinguish these kinds of conflicts
can we identify the conflict using the dictionary and logic only?
No; and we can do nothing about it: physical conflict
Can we do something about it? (technical or social conflict)Roel Wieringa; 11-12-2012
22‐6‐2013
9
Summary of awareness levels
• Stakeholders are not aware of most of their possible desires and fears
• They will not act on most of their other desires and fears, because:
– Unable to choose between conflicting desires
i‐star'13 Workshop © Roel Wieringa 18th june 2013 17
Soft and hard goals
i‐star'13 Workshop © Roel Wieringa 18th june 2013 18
22‐6‐2013
10
• Desires are usually wishy‐washy
• Many goals too
i‐star'13 Workshop © Roel Wieringa 18th june 2013 19
Operationalization
• Operationalization of a concept is the definition of one or more indicators for it
• An indicator is a variable with a measurementprocedure
i‐star'13 Workshop © Roel Wieringa 18th june 2013 20
22‐6‐2013
11
Some examples of indicators
• Utility indicator: Opinion of stakeholder about utility• Accuracy indicator: domain dependent, e.g. spatial resolution• Interoperability indicator: effort to realize interface with a system• Security indicators: availability, compliance to standards• Compliance indicator: expert opinion about compliance• Reliability indicators: mean time between failure, time to recover• Usability indicators: effort to learn, effort to use• Efficiency (time or space) indicators: execution time, disk usage• Maintainability indicators: effort to find bugs, effort to repair, effort
to test• Portability indicators: effort to adapt to new environment, effort to
install, conformance to standards
i‐star'13 Workshop © Roel Wieringa 18th june 2013 21
See http://www.sqa.net/iso9126
Goal trees often contain operationalizations in the form of goal decompositions
i‐star'13 Workshop © Roel Wieringa 18th june 2013 22
Usability
Effort to learn Effort to use Number of calls to the helpdesk
22‐6‐2013
12
Criteria
• Criterion = set of desired values for an indicator
– Depending on the scale of the indicator, you may be ableto define degree of satisfaction of a criterion
i‐star'13 Workshop © Roel Wieringa 18th june 2013 23
Criteria are often added to goal trees too
• Adding criteria to a goal tree makes the tree semantics more complex: it adds info about values
i‐star'13 Workshop © Roel Wieringa 18th june 2013 24
Usable
Easy to learn Easy to use Small number of calls to the helpdesk
22‐6‐2013
13
• Making a budget available for a desire turns it into a goal
• This is a good occassion to operationalize it
– But this is not always done
i‐star'13 Workshop © Roel Wieringa 18th june 2013 25
• Operationalization is an occassion for a lot of politics
– Stakeholders try to bend indicators and criteria in theirfavor
i‐star'13 Workshop © Roel Wieringa 18th june 2013 26
22‐6‐2013
14
• Operationalization is an occassion for a lot of philosophy too
– What is the ``real’’ meaning of a concept?
– Paradox of analysis: A crisp operationalization cannot besynonynmous to a fuzzy concept.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 27
Goal decomposition
i‐star'13 Workshop © Roel Wieringa 18th june 2013 28
22‐6‐2013
15
• Anything can be a goal
– To be rich and famous
– To walk to Santiago de Compostella
– Owning a smartphone
– Owning a house
i‐star'13 Workshop © Roel Wieringa 18th june 2013 29
i‐star'13 Workshop © Roel Wieringa 18th june 2013 30
Current stateof theworld
Stakeholder S
W1Desirable stateof the world
W2Even more desirable state of the world
W3A desirable stateof the world
Has even higher value for S
Has higher value for Sthan the current state
Has anothervalue for S,higher than thatof current state,but incompatiblewith that of W2
Preference ordering among possible worlds
Conflict
22‐6‐2013
16
i‐star'13 Workshop © Roel Wieringa 18th june 2013 31
Current stateof theworld
W1Desirable stateof the world
W2Even more desirable state of the world
W3A desirable stateof the world
Has even higher value for S
Has higher value for Sthan the current state
Has anothervalue for S,higher than thatof current state,but incompatiblewith that of W2
Reachibility
Conflict
Stakeholder S
Stakeholder Si‐star'13 Workshop © Roel Wieringa 18th june 2013 32
Current stateof theworld
W1Desirable stateof the world
W2Even more desirable state of the world
W3A desirable stateof the world
Has even higher value for S
Has higher value for Sthan the current state
Has anothervalue for S,higher than thatof current state,but incompatiblewith that of W2
The goal
Conflict
GoalOf S
22‐6‐2013
17
Simplifications in this picture
• There is a preference ordering
– But: Preferences may emerge after we experience a possible world
– We ignore this.
• Preferences stay the same
– But: Many preferences are dynamic
– We ignore this
i‐star'13 Workshop © Roel Wieringa 18th june 2013 33
Three kinds of goal decomposition
• Decompose the meaning of the goal statement
– Use indicators
• Decompose the goal world
• Decompose the path to the goal world
i‐star'13 Workshop © Roel Wieringa 18th june 2013 34
22‐6‐2013
18
• Means‐end decomposition: Tasks to be performed to reachgoal
i‐star'13 Workshop © Roel Wieringa 18th june 2013 35
• Png file
i‐star'13 Workshop © Roel Wieringa 18th june 2013 36
22‐6‐2013
19
i‐star'13 Workshop © Roel Wieringa 18th june 2013 37
Another means‐end decomposition
i‐star'13 Workshop © Roel Wieringa 18th june 2013 38
Decomposition of goal world
To achieve the goal state, three objectsmust be achieved
22‐6‐2013
20
i‐star'13 Workshop © Roel Wieringa 18th june 2013 39
Goal worlddecomposition
• Goal world decomposition followed by means‐end decomposition
i‐star'13 Workshop © Roel Wieringa 18th june 2013 40
22‐6‐2013
21
i‐star'13 Workshop © Roel Wieringa 18th june 2013 41
At least three kinds of goal decomposition
• By indicators. – Variable‐based view of the world
– This decomposition defines a construct operationally
• By components. – Component‐based view of the world
– This shows us the elements of the goal that need to beachieved
• By means‐end. – Process‐based view of the world
– This tells us what to do to get there
i‐star'13 Workshop © Roel Wieringa 18th june 2013 42
22‐6‐2013
22
Other relations in the Tropos example
• Cause‐effect
– Change in X causes change in (probability distribution of) Y
– This is a scientific (mini)theory of the domain
• Contribution (+ or ‐) to a criterion
– If X gets closer/further away from its criterion, then(probably), Y gets closer/further away from its criterion.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 43
Conclusions so far
Goal model contains• Conceptual framework of the domain:
– Operational definitions (decomposition in terms of indicators)
– Decomposition of the goal state (also a kind of operationalization)
• Scientific theory of the domain: – Decomposition of the means‐end path to the goal state
– statements about cause/effect relations
• Statement of preferences: – criteria, contribution relations (+ or ‐)
• My unsollicited advice: Represent these in different models
i‐star'13 Workshop © Roel Wieringa 18th june 2013 44
22‐6‐2013
23
Outline
1. Goals
2. Design reasoning
i‐star'13 Workshop © Roel Wieringa 18th june 2013 45
Design reasoning
• Contribution argument
• Temporal ordering of design tasks
i‐star'13 Workshop © Roel Wieringa 18th june 2013 46
22‐6‐2013
24
Design
• What is design?
– Making a decision about what to do.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 47
Webster’s
transitive verb• 1 : to create, fashion, execute, or construct according to
plan : devise, contrive• 2a : to conceive and plan out in the mind <he designed the
perfect crime> • 2b : to have as a purpose : intend <she designed to excel in
her studies> • 2c : to devise for a specific function or end <a book
designed primarily as a college textbook> • 3 archaic : to indicate with a distinctive mark, sign, or name • 4a : to make a drawing, pattern, or sketch of • 4b : to draw the plans for <design a building>
i‐star'13 Workshop © Roel Wieringa 18th june 2013 48
22‐6‐2013
25
Webster’s
intransitive verb
• 1: to conceive or execute a plan
• 2: to draw, lay out, or prepare a design
i‐star'13 Workshop © Roel Wieringa 18th june 2013 49
Webster’s
• Origin of DESIGN
• Middle English, to outline, indicate, mean, from Anglo‐French & Medieval Latin; Anglo‐French designer to designate, from Medieval Latin designare, from Latin, to mark out, from de‐ + signare to mark —more at sign
• First Known Use: 14th century
i‐star'13 Workshop © Roel Wieringa 18th june 2013 50
22‐6‐2013
26
Elements of the concept of design
• Making a decision about what to do.
• Documenting that decision
• Decisions can be executed
• To achieve goals
i‐star'13 Workshop © Roel Wieringa 18th june 2013 51
Historical note
• 14th century architects were illiterate.
– But they could read a sketch
– And use the sketch to coordinate their work
• Designers were builders until Josiah Wedgwood separated the two roles in the late 18th century
– Mail order catalog of porcelain
– Reproducibility
i‐star'13 Workshop © Roel Wieringa 18th june 2013 52
22‐6‐2013
27
The contribution argument
• Artifact X Context ⇒Goals
i‐star'13 Workshop © Roel Wieringa 18th june 2013 53
stakeholder
goal
value
norm
desire
fear
Artifact
Otherartifact
Socialentity
Software entity
Hardware entity
Defeasible implication
The contribution argument
• Artifact X Context ⇒Goals
i‐star'13 Workshop © Roel Wieringa 18th june 2013 54
stakeholder
goal
value
norm
desire
fear
Artifact
Otherartifact
Socialentity
Software entity
Hardware entity
ContextInteraction
22‐6‐2013
28
The contribution argument
• Artifact X Context ⇒Goals
i‐star'13 Workshop © Roel Wieringa 18th june 2013 55
stakeholder
goal
value
norm
desire
fear
Artifact
Otherartifact
Socialentity
Software entity
Hardware entity
ContextInteraction
Example: Industrial design
• Design assignment:
– Given a context C and desired outcomes O
– Find an artifact such that Artifact X Context ⟿O
• Design deliverables:
– Artifact
– Contribution argument Artifact X Context ⇒ Desiredoutcomes
• E.g. design a dish washer for use in sailing boats
• Roozenburg & Eekels. Product design: Fundamentals and Methods. Wiley 1995.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 56
Causes
22‐6‐2013
29
Example: organization design
• Technological rule– In this class of problems in Context, use this type of Intervention,
which will produce through these Mechanisms these directOutcomes’.
• Van Aken. ``Management Research Based on the Paradigm of the Design Sciences: The Quest for Field‐Tested and Grounded Technological Rules’’. Journal of Management Studies 41:2 March 2004
• Pawson and Tilley. Realistic Evaluation. 1997.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 57
Context Artifact
Outcomes
Intervention = Inserting the artifact in the context
Mechanisms
that satisfy goals
Example: Software engineering
• W ∧ S ⇒ R• M ∧ P⇒ S• Gunter, Gunter, Jackson, Zave. ``A reference model for
requirements specifications’’ . IEEE Software, may/june 2000
i‐star'13 Workshop © Roel Wieringa 18th june 2013 58
W R S P M
World, Requirements, Specification, Program, Machine
Context ArtifactGoals
22‐6‐2013
30
KAOS
• Artifact X Context ⇒Goal
i‐star'13 Workshop © Roel Wieringa 18th june 2013 59
Goal
Context
Allocated toartifact
The contribution argument
• Artifact X Context ⇒Goals
– Widespread (universal?) design reasoning
– Artifact and Goals are actually part of Context
– ⇒ is defeasible: We may predict that goals will beachieved, but something else may happen
i‐star'13 Workshop © Roel Wieringa 18th june 2013 60
22‐6‐2013
31
• Design science looks not only for outcomes, but alsofor
– Mechanisms that produce them
– Goal satisfaction of outcomes
i‐star'13 Workshop © Roel Wieringa 18th june 2013 61
Extended conclusions
Goal model contains• Conceptual framework of the domain:
– Operational definitions of variables in terms of indicators
– Operational definjition of goal state of the goal state in terms of components
• Scientific theory of the domain: – Decomposition of the means‐end path to the goal state
– statements about cause/effect relations
– Mechanisms that produce outcomes
• Statement of preferences: – criteria, contribution relations (+ or ‐)
– Goal satisfaction of outcomes
i‐star'13 Workshop © Roel Wieringa 18th june 2013 62
Definitions
Value satisfaction
Causes, mechanisms
22‐6‐2013
32
Mechanisms
• Mechanism is interaction between components
– To identify a mechanism, you need a component‐basedconceptual model of the domain
• Contrast with causality
– Cause‐effect is a relation between variables
– Assumes a variable‐based view of the domain
• Mechanisms may explain cause‐effect relations
i‐star'13 Workshop © Roel Wieringa 18th june 2013 63
• Glennan ‐ ``Mechanisms and the nature of causation’’. 1996
i‐star'13 Workshop © Roel Wieringa 18th june 2013 64
22‐6‐2013
33
i‐star'13 Workshop © Roel Wieringa 18th june 2013 65
• Glennan ‐ ``Mechanisms and the nature of causation’’. 1996
• Bechtel & Abrahamsen – ``Explanation; a mechanistic alternative.’’ 2005
i‐star'13 Workshop © Roel Wieringa 18th june 2013 66
22‐6‐2013
34
• Bechtel & Abrahamsen –``Explanation; a mechanisticalternative.’’ 2005
i‐star'13 Workshop © Roel Wieringa 18th june 2013 67
• Mechanisms, defined in terms of components, canexplain cause‐effect relations between variables
• Some cause‐effect relations do not have knownmechanisms
– Gravity
i‐star'13 Workshop © Roel Wieringa 18th june 2013 68
22‐6‐2013
35
Elements of the concept of design
• Artifact X Context ⇒ Outcomes
– Effect theory: Theory of the mechanisms that producethese outcomes
– Value theory: Theory that predicts contribution (+ or ‐) of outcomes to goals
• Goal models often contain (fragments of) both kinds of theory
i‐star'13 Workshop © Roel Wieringa 18th june 2013 69
Design reasoning
• Contribution argument
• Temporal ordering of tasks
i‐star'13 Workshop © Roel Wieringa 18th june 2013 70
22‐6‐2013
36
Temporal ordering of tasks in creativedesign
• Cross. ``Design Cognition: Results From Protocol And Other Empirical Studies Of Design Activity’’ 2001
• Cross. ``Creative cognition in design: processes of exceptional designers’’. 2002.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 71
Problem goals Artifact requirements
Relevant first principles:• Principle of operation• Mechanisms• Theories
Solution conceptProblem frame
Time
Tension
Resolution
Feasibility
Explored to establish
Used to identify Realized in
To satisfy
• Context x Artifact⇒Goal
i‐star'13 Workshop © Roel Wieringa 18th june 2013 72
Initially knownvaguely as somegoal plus anintended context of use
Initially specifiedby means of a few requirements
Thenconceptualized
Then connectedand mechanized
Thenconceptualized
Problem understandingand artifact design are refined in parallel,
maintaining goal satisfaction
22‐6‐2013
37
i‐star'13 Workshop © Roel Wieringa 18th june 201373
Systems engineering
• Iteratively reduce uncertainty about the problem• Once the goals are clear enough, reduce risk of choosing the wrong treatment
Ill‐understood problem
Better understood problem
Treatment idea
Validation
Even betterunderstood problem
Treatment specification
Validation
Still betterunderstood problem
OperationalTreatmentspecification
Validation
Goals and requirementsOperational concept
Feasibility
Prototype
Time
Clear problem, clear goals Solution1 spec Validation Implementation1 Eval
Clear goals, risky treatment Solution2 spec Validation Implementation2 Eval
Clear goals, acceptable risk Solution3 spec Validation Implementation3 Eval
Early requirements Validation
i‐star'13 Workshop © Roel Wieringa 18th june 201374
Systems engineering
• Iteratively reduce uncertainty about the problem• Once the goals are clear enough, reduce risk of choosing the wrong treatment
Ill‐understood problem
Better understood problem
Treatment idea
Validation
Even betterunderstood problem
Treatment specification
Validation
Still betterunderstood problem
OperationalTreatmentspecification
Validation
Goals and requirementsOperational concept
Feasibility
Prototype
Time
Clear problem, clear goals Solution1 spec Validation Implementation1 Eval
Clear goals, risky treatment Solution2 spec Validation Implementation2 Eval
Clear goals, acceptable risk Solution3 spec Validation Implementation3 Eval
Early requirements Validation
Problem understandingand artifact design are refined in parallel,
maintaining goal satisfaction
22‐6‐2013
38
Agile development
• The same
i‐star'13 Workshop © Roel Wieringa 18th june 2013 75
Nonmonotonic refinement
• During the design process, the designer may revisebeliefs about the context, stakeholders and goals,
• And may revise his or her design
– Nonmonotonic process
• System development methods are a way to constrainand control nonmonotonicity.
i‐star'13 Workshop © Roel Wieringa 18th june 2013 76
22‐6‐2013
39
Rational reconstruction
• After the design is finished, you can present the contribution argument as if it has been conceivedlike that from the beginning.
– Rational reconstruction of history (Lakatos)
– Constructing accountability (Suchman)
– Faking rationality (Parnas)
i‐star'13 Workshop © Roel Wieringa 18th june 2013 77
Discussion
i‐star'13 Workshop © Roel Wieringa 18th june 2013 78
22‐6‐2013
40
Implications for GORE notations
• GORE notation as an artifact
– Used in which context?
– By whom?
– For which goals?
• Desire to include everything in the notation may bethe result of lack of clarity of about the goals of the notation
i‐star'13 Workshop © Roel Wieringa 18th june 2013 79
Implications for GORE notations
• If we know what the context of use is:
• What to express?
– Conceptual framework of the domain: definitions, operationalizations, decompositions
– Effect theory: statements about causes, mechanisms
– Value theory: criteria, preference ordering, contributions
• Cannot all be represented in the same model
i‐star'13 Workshop © Roel Wieringa 18th june 2013 80