Tutorial Human Side of Systems Architecting - Gaud System
Transcript of Tutorial Human Side of Systems Architecting - Gaud System
Tutorial Human Side of Systems Architectingby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
Architects play a crucial role in creating systems that fit well in the human needs.The creation of these systems requires many human interactions between allstakeholders. The background of architects, however, is completely different,mostly technical. We bring insight in the human aspects of systems architectingand we provide an approach with related tools to address the human aspects.
Copyright c© 2008 by Gerrit Muller. Published and used by INCOSE with permission.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: plannedversion: 0.1
Figure Of ContentsTM
1. brainstorm human characteristics
2. HFI in Defense
V4aa
IO
design, brainstorm,
explain
Idea
think, analyse
listen, talk, walk around
Bla Bla
write, consolidate,
browse
present, meet, teach,
discuss
read, review
Design
Spec
Report
test, integrate
assist project leader with work breakdown,
schedule, risks
travel to customer, supplier,
conference
provide vision and leadership
3. Role Architect
root technical
knowledge
generalist technical
knowledge
business, application insight
process insight
psycho-social skills
4. Growth
Humans
Technology
Experience Sense, smell, feel
Emotions, Opinions
Engineering
have
use
requires
Analysis, Definition
Verification
Devices
Appliances Architecting
From Fuzzy to
SMART
5. Experience Transfer
verbal
message
non-verbal
message
idea to be expressed own interpretation
of idea
emotional state relation with the other the objective the situation age, status education cultural background
encoding based on
from: "Listening and communicating" by Lia Muller and Willemien
decoding based on
emotional state relation with the other
the objective the situation age, status education
cultural background
6. Interpersonal Skills
deaf cannot hear
blind cannot see
mute cannot speak
but in the team two can hear, two can see, and two can speak
7. Team Work
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
when in an impasse: provoke effective when used sparsely
especially recommended when new in a field: contribute to the team, while absorbing new know how
provide vision and direction, make choices risk: followers stop to give the needed feedback
take the viewpoint of the stakeholder acknowledge the stakeholders feelings, needs, concerns
investigate by asking questions
invite a few engineers and walk through the system operation step by step
first listen to the stakeholder and then explain cost and alternative opportunities
8. Styles
0
1
2
3
4
5
6
7
8
9
commun
icatio
n
teamwor
k
docu
mentat
ion
multi-ta
sking
flexib
le, op
en
auth
by ex
pertis
e
spec
ialist
gene
ralis
t
conc
eptua
l
prag
matic
cons
tructi
ve cr
itical
abso
rptio
n knh
w
creati
vity
manua
l skil
l
proc
ess i
nsigh
t
politi
cs in
sight
impr
ovem
ent
comple
tenes
s
sche
dule
monito
r pro
gres
s
initia
l cos
t
decis
ion m
aking
custo
mer va
lue
sales
featu
re
commer
cial in
sight
coac
hing
selec
tion
appr
aisal
motiva
tion
9. Profile
C ustomer objectives
A pplication F unctional C onceptual R ealization
L ife cycle operations maintenance upgrades
development manufacturing
installation
sales, service, logistics, production, R&D
10 CAFCR model
Customer What
Customer How
Product What
Product How
What does Customer need in Product and Why ?
story case analyse design
design analyse design
a priori solution know how market vision
C ustomer objectives
A pplication F unctional C onceptual R ealization
11 Story Telling
summary
Tutorial Human Side of Systems Architecting2 Gerrit Muller
version: 0.1October 28, 2018
TSAHSlogo
Brainstorm
What human characteristics
do you know
that impact the
use, specification and design
of systems?
Tutorial Human Side of Systems Architecting3 Gerrit Muller
version: 0.1October 28, 2018
TSAHSbrainstormQuestion
Overview of Human Aspects
individual
bilateral
heterogeneous cultures
group
networked groups homogeneous
culture
psychology
sociology
pedagogy didactics political science
group dynamics
criminology
psychiatry
medicine
ergonomics
cultu
ral d
iver
sity
networked society
number of involved humans
cultural anthropology
physiology
Tutorial Human Side of Systems Architecting4 Gerrit Muller
version: 0.1October 28, 2018
TSAHSaspectsOverviewDiagram
Human Factors in Defenseby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The defense industry has recognized the importance of human factors for systemdesign. Some processes and procedures are available to address these needs.In this paper we provide a brief overview of ongoing Human Factors or HumanSystems Integration activities in Defense.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: preliminarydraftversion: 0.1
Manpower
Personnel
Retention
Recruiting
Addresses all aspects of defining requirements for personnel as well as obtaining and retaining those individuals
Manpower
Personnel
Retention
Recruiting
Manpower
Personnel
Retention
Recruiting
Addresses all aspects of defining requirements for personnel as well as obtaining and retaining those individuals
Training Equips Warfighters with the Knowledge Skills & Abilities ( KSAs ) needed
Training Equips Warfighters with the Knowledge Skills & Abilities ( KSAs ) needed
Environment
System Safety
Occupational Health
Design features that minimize human error and reduce risk of injury
Environment
System Safety
Occupational Health
Environment
System Safety
Occupational Health
Design features that minimize human error and reduce risk of injury
Human Factors
Ensures that all aspects of the system are designed with full consideration of the inherent capabilities and limitations of the warfighter
Human Factors
Ensures that all aspects of the system are designed with full consideration of the inherent capabilities and limitations of the warfighter
Habitability
Ensures that all aspects of the living and working spaces are designed with the warfighter in mind
Habitability
Ensures that all aspects of the living and working spaces are designed with the warfighter in mind
Personnel Survivability
Provides that the warfighter will have all personal protection needed
Personnel Survivability
Provides that the warfighter will have all personal protection needed
Human Systems Integration in DoD Acquisition by Ms. Nancy Dolan CNO N125 https://acc.dau.mil/GetAttachment.aspx?id=25755&pname=file&aid=3181&lang=en-US
Human Systems Integration DoD Acquisition
Manpower
Personnel
Retention
Recruiting
Addresses all aspects of defining requirements for personnel as well as obtaining and retaining those individuals
Manpower
Personnel
Retention
Recruiting
Manpower
Personnel
Retention
Recruiting
Addresses all aspects of defining requirements for personnel as well as obtaining and retaining those individuals
Training Equips Warfighters with the Knowledge Skills & Abilities ( KSAs ) needed
Training Equips Warfighters with the Knowledge Skills & Abilities ( KSAs ) needed
Environment
System Safety
Occupational Health
Design features that minimize human error and reduce risk of injury
Environment
System Safety
Occupational Health
Environment
System Safety
Occupational Health
Design features that minimize human error and reduce risk of injury
Human Factors
Ensures that all aspects of the system are designed with full consideration of the inherent capabilities and limitations of the warfighter
Human Factors
Ensures that all aspects of the system are designed with full consideration of the inherent capabilities and limitations of the warfighter
Habitability
Ensures that all aspects of the living and working spaces are designed with the warfighter in mind
Habitability
Ensures that all aspects of the living and working spaces are designed with the warfighter in mind
Personnel Survivability
Provides that the warfighter will have all personal protection needed
Personnel Survivability
Provides that the warfighter will have all personal protection needed
Human Systems Integration in DoD Acquisition by Ms. Nancy Dolan CNO N125 https://acc.dau.mil/GetAttachment.aspx?id=25755&pname=file&aid=3181&lang=en-US
Human Factors in Defense6 Gerrit Muller
version: 0.1October 28, 2018
TSAHSacquisitionDoD
Human Engineering from Naval Perspective
1. Mission Analysis
2. Requirements Analysis
3. Function Analysis
4. Function Allocation
5. Task Design and Analysis
6. Human Interface and Team Development
7. Performance, Workload, and Training Level Estimation
8. User and Requirements Reviews
from ONR (Office of Naval Research)/SC-21 Manning Affordability Initiative www.hf.faa.gov/docs/508/docs/Human_System_Engineering_(NSWC).pdf
Human Factors in Defense7 Gerrit Muller
version: 0.1October 28, 2018
TSAHSnavalHumanEngineering
Human Views for MODAF
HV-A: Personnel Availability
HV-B: Quality Objectives and Metrics
HV-C: Human Interaction Structure
HV-D: Organisation
HV-E: Human Functions and Tasks
HV-F: Roles and Competencies
HV-G: Dynamic Drivers of Human Behaviour
from The Human View Handbook for MODAF www.hfidtc.com/MoDAF/HV Handbook First Issue.pdf
Human Factors in Defense8 Gerrit Muller
version: 0.1October 28, 2018TSAHShvMODAF
The Role and Task of the System Architectby Gerrit Muller Buskerud University Collge
e-mail: [email protected]
Abstract
The role of the system architect is described from three viewpoints: deliverables,responsibilities and activities. This description shows the inherent tension in thisrole: a small set of hard deliverables, covering a fuzzy set of responsibilities,hiding an enormous amount of barely visible day-to-day work.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: conceptversion: 2.0
V4aa
IO
design,
brainstorm,
explain
Idea
think,
analyze
listen, talk,
walk around
Blah Blah
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
Design
Sp
ec
Report
test,
integrate
assist project leader
with work breakdown,
schedule, risks
travel to
customer,
supplier,
conference
provide
vision and
leadership
Deliverables of the System Architect
Spec DesignReport
Re
po
rt
ReportDesign
Design
SpecSpec
The Role and Task of the System Architect10 Gerrit Muller
version: 2.0October 28, 2018RSAdeliverables
List of Deliverables
Customer and Life-Cycle Needs (what is needed)
System Specification (what will be realized)
Design Specification (how the system will be realized)
Verification Specification (how the system will be verified)
Verification Report (the result of the verification)
Feasibility Report (the results of a feasibility study)
Roadmap
The Role and Task of the System Architect11 Gerrit Muller
version: 2.0October 28, 2018
RSAdeliverablesSpecific
Responsibilities of the System Architect
system
subsystem
Balance Consistency
module
Overview
RequirementSpec
DesignRealization
Decomposition
Integration
modules
FunctionQ
uality
KISS
Elegance
Simple Integrity Fitting
satisfied
stakeholderssystem
context
The Role and Task of the System Architect12 Gerrit Muller
version: 2.0October 28, 2018
RSAresponsibilities
Examples of Secondary Responsibilities
responsibility
business plan, profit
schedule, resources
market, saleability
technology
process, people
detailed designs
primary owner
business manager
project leader
marketing manager
technology manager
line manager
engineers
The Role and Task of the System Architect13 Gerrit Muller
version: 2.0October 28, 2018
RSAsecondaryResponsibilities
What does the System Architect do?
V4aa
IO
design,
brainstorm,
explain
Idea
think,
analyze
listen, talk,
walk around
Blah Blah
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
Design
Sp
ec
Report
test,
integrate
assist project leader
with work breakdown,
schedule, risks
travel to
customer,
supplier,
conference
provide
vision and
leadership
The Role and Task of the System Architect14 Gerrit Muller
version: 2.0October 28, 2018
RSAactivities
From Detail to Overview
driving views
shared issues
touched details
seen details
real-world facts
10
102
104
107
infinite
Quantityper year
(order-of-
magnitude)
architect
time per
item
100 h
1 h
10 min
meetings
consolidation
in
deliverables
informal
contacts
product details
sampling
scanning
0.1105
0.5
1 sec106
1010
The Role and Task of the System Architect15 Gerrit Muller
version: 2.0October 28, 2018
RSAdetailHierarchy
Reality or Virtuality?
Abstractions only exist for concrete facts.
The Role and Task of the System Architect16 Gerrit Muller
version: 2.0October 28, 2018
Visible Output versus Invisible Work
V4aa
IOIdea
Bla Bla
Design
Sp
ec
Report
system
subsystem
module
Requirement
Spec
Design
Realization
modules
Fun
ctio
nQuality
KISS
Activities
Responsibilities
DeliverablesDec
reas
ing
Vis
ibili
ty
Spec DesignReport
Re
po
rt
Report
Design
Design
Spec
Spec
From Manager perspective
The Role and Task of the System Architect17 Gerrit Muller
version: 2.0October 28, 2018
RSApyramid
The Awakening of a System Architectby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The typical phases of a system architect development are described, beginningat the fundamental technology knowledge, with a later broadening in technologyand in business aspects. Finally the subtlety of individual human beings is takeninto account.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: conceptversion: 1.1
root
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
psychosocial
skills
Typical Growth of a System Architect
root
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
psychosocial
skills
The Awakening of a System Architect19 Gerrit Muller
version: 1.1October 28, 2018
MATsystemArchitectGrowth
Generalist versus Specialist
sp
ecia
list
generalist
root
knowledge
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect20 Gerrit Muller
version: 1.1October 28, 2018
MATgeneralistVsSpecialist
Generalists and Specialists are Complementary
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
generalistgeneralist
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect21 Gerrit Muller
version: 1.1October 28, 2018
MATcomplementaryExpertises
Spectrum from Specialist to System Architect
all-
rou
nd
sp
ecia
list systems architect
sp
ecia
list
root
knowledge
aspect
architect
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect22 Gerrit Muller
version: 1.1October 28, 2018
MATfromSpecialistToSystemArchitect
Architecting for Humans; How to Transfer Experience?by Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The ultimate goal of Product Creation is to create products which give the usera great experience. User experience is very intangible. Product engineeringfocuses on tangible requirements. Successfull product require both soundengineering as well as creative design. The question is how to obtain a workforce,which is capable of both activities?The education of successfull engineers is limited to engineering methods.Additional skills are acquired by experience. Unfortunately experience cannotbe transfered from one engineer to the next. Such a transfer is approximated byactive personal development.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: finishedversion: 1.3
A
B
C
D
To create an User Experience
Experience is not predictable and never garantueed
Design Experience is needed
Success requires feedback
engineers
architect project leader
Did you ever program a VCR or PVR?
A
B
C
depressed
desparate
hysteric
Architecting for Humans; How to Transfer Experience?24 Gerrit Muller
version: 1.3October 28, 2018
ETmultipleChoiceVCRprogramming
Product Creation Cycle
Product User
Engineers
Retailer or
ProviderFactory
designproduct
documentation
Product
manager
Architect
Project
Leader
Architecting for Humans; How to Transfer Experience?25 Gerrit Muller
version: 1.3October 28, 2018
ETproductCreationCycle
2 Levels of Experience
For Whom
What
User
Product
By Whom Engineers
Product manager
Architect
Project Leader
How design product
documentation
Product Creation Process
User
Experience
Creation
Experience
Architecting for Humans; How to Transfer Experience?26 Gerrit Muller
version: 1.3October 28, 2018
ETuserAndCreationExperience
Bridging the gap between Experience and Engineering
Humans
Technology
Experience Sense, smell, feel
Emotions, Opinions
Engineering
have
use
requires
Analysis, Definition
Verification
Devices
Appliances Architecting
From Fuzzy to
SMART
Architecting for Humans; How to Transfer Experience?27 Gerrit Muller
version: 1.3October 28, 2018
ETarchitecting
Example Time Shift recording
broadcast
20:00 21:00 22:00 23:00
phone rings
pause viewing
finish conversation
resume viewing
start
movie
end
movie
view viewtalk
record
play
Architecting for Humans; How to Transfer Experience?28 Gerrit Muller
version: 1.3October 28, 2018
ETexampleTimeShifting
Construction limits intrude in Experience
• number of tuners
• number of simultaneous streams (recording and playing)
• amount of available storage
• management strategy of storage space
Architecting for Humans; How to Transfer Experience?29 Gerrit Muller
version: 1.3October 28, 2018
What if?
broadcast
20:00 21:00 22:00 23:00
phone rings
pause viewing
finish conversation
resume viewing
start
movie
end
movie
view viewtalk
record
play
1. programmed recording
of other station
2. very long
phone call
play
3. Dad
zaps
Architecting for Humans; How to Transfer Experience?30 Gerrit Muller
version: 1.3October 28, 2018
ETexampleTimeShiftingWhatIf
OOTI workshop 2001
1.1 Software Requirements
1.1.1 Real-time data requirements
1.1.1.1 Access to the non-real-time data must be done in such a way that it does not interfere with the real- time data
1.1.1.2 There must be no disruptions in output of video signal during the operation of VCR
1.1.1.3 Responsiveness for non real-time data is less then 150ms (the time for writing a block on HDD) for 2KB of non-video data
1.1.2 Implementation detail 1.1.2.1 Management of HDD content must only be possible through the TOC in order to prevent unauthorized access to content of HDD
1.1.2.2 Visual feedback is provided to the user via On- Screen Display
1.1.2.3 User input is provided via the RC
1.1.3 Non-real time data requirements
1.1.3.1 User must be able to pause and unpause a title, played from HDD, while (s)he is watching it
1.1.3.2 User can jump forward and backward in a title, from HDD, during watching of this title
1.1.3.3 Names of titles should be derived from the information from the EPG (name of the program to be recorded, time and date of registration)
2.1.1 Real-time data requirements 2.1.2 Implementation detail
2.1.3 Non-real time data requirements
Requirements specification Many tables, mostly addressing details
Visual Basic Prototype:
enables "experiencing"
play pause record EPG
Architecting for Humans; How to Transfer Experience?31 Gerrit Muller
version: 1.3October 28, 2018
ETworkshopOOTIs
Factors influencing the User Experience
mental status
physical status
trauma emotional status
allergy handicap
religion taboo
preferences taste
social status
fashion
relation family
group influence
culture taboo cultural
location
time
education environmental factors
personal factors
Architecting for Humans; How to Transfer Experience?32 Gerrit Muller
version: 1.3October 28, 2018
ETexperienceFactors
How to ”SMART”en Experience?
• define
• measure
• predict
• verify
Architecting for Humans; How to Transfer Experience?33 Gerrit Muller
version: 1.3October 28, 2018
Infinite Experience Space
Number of People on earth
O(10 9 )
Human lifespan in seconds
O(10 9 )
Square meters of planet earth
O(10 14 )
People
Time
Location
*
*
* ... ... ...
Size of experience space
Architecting for Humans; How to Transfer Experience?34 Gerrit Muller
version: 1.3October 28, 2018
ETexperienceSpaceExplosion
It is not that bad :-)
Many nice and successfull products exist!
Architecting for Humans; How to Transfer Experience?35 Gerrit Muller
version: 1.3October 28, 2018
Key Success Factor: Feedback
Obtain feedback from real users:
- Observe - (Dare to) Listen
- Experiment - Use short development cycles
Don't stay in the development lab
Architecting for Humans; How to Transfer Experience?36 Gerrit Muller
version: 1.3October 28, 2018
ETfeedback
The world of the construction
Operating system
Computing hardware
Domain hardware
Domain specific
sw
Application software Compilers
Other SW tools
Case Tools
Procedures
Methods
Product oriented Means oriented
Architecting for Humans; How to Transfer Experience?37 Gerrit Muller
version: 1.3October 28, 2018
ETconstructionWorld
Engineers are educated in construction disciplines
• Programming languages
• Operating systems
• Algorithms
• Data structures
• Formal specification and verification techniques
• Analysis, simulation techniques
Architecting for Humans; How to Transfer Experience?38 Gerrit Muller
version: 1.3October 28, 2018
ETengineeringConstructionDisciplines
Product Creation is much more than Engineering
Product Creation
= Engineering + Known: Facts Notations Methods Tools Patterns
Creativity
Education Experience
Intuition Observation Trial and error Lateral thinking Collection of
references
Architecting for Humans; How to Transfer Experience?39 Gerrit Muller
version: 1.3October 28, 2018
ETengineeringPlusCreativity
Educational Material per education stage
Kindergarten
Elementary
school High
school University
On the job
training
Holistic
perfection
Ava
ilabl
e ed
ucat
iona
l m
ater
ial
Architecting for Humans; How to Transfer Experience?40 Gerrit Muller
version: 1.3October 28, 2018
ETeducationalMaterial
Changing Education model in time
Handbook Course material
Lectures: Explain Show examples
Exercise Practical training
apprentice- ship
Peer coaching
Seminars Workshops Conferences
Magazines Journals
Do
Interact and Listen
Read
time
Architecting for Humans; How to Transfer Experience?41 Gerrit Muller
version: 1.3October 28, 2018
ETeducationLifecycle
Increasing Initiative required
Handbook Course material
Lectures: Explain Show examples
Exercise Practical training
apprentice- ship
Peer coaching
Seminars Workshops Conferences
Magazines Journals
highly organized well specified small scope few (if any) stakeholders
initiative required uncertainty rules
large scope many stakeholders
Do
Interact and Listen
Read
time
Architecting for Humans; How to Transfer Experience?42 Gerrit Muller
version: 1.3October 28, 2018
ETeducationLifecycleAnnotated
Prerequisites for continuous successfull product creation
• Awareness of engineers of human aspects
• Active personal development drive of engineers
• Awareness of managers of education models
• Active motivation by managers
Architecting for Humans; How to Transfer Experience?43 Gerrit Muller
version: 1.3October 28, 2018
Architecting for Humans
A
B
C
D
To create an User Experience
Experience is not predictable and never garantueed
Design Experience is needed
Success requires feedback
engineers
architect project leader
Architecting for Humans; How to Transfer Experience?44 Gerrit Muller
version: 1.3October 28, 2018
ETdesignExperienceNeeded
Experience Transfer
Design experience is not transferable
Regular education = Transfer of Engineering methods + Training
Personal Development = On the job training + feedback + continuous personal education
Transfer is approximated by personal development
education is no substitute
Architecting for Humans; How to Transfer Experience?45 Gerrit Muller
version: 1.3October 28, 2018
ETtransferByPersonalDevelopment
Human Side: Interpersonal Skillsby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
We discuss in this paper a set of skills and techniques to cooperate effectivelybetween two individuals. We show the wonders of communication and then weaddress techniques such as investigation and acknowledgement, constructivefeedback, conflict management, appraisal, good practices in a conversation,searching for ideas.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: draftversion: 0.1
verbal
message
nonverbal
message
idea to be
expressedown interpretation
of idea
emotional state
relation with the other
the objective
the situation
age, status
education
cultural background
encoding
based on
from: "Listening and communicating" by Lia Charité, www.liacharite.nl
decoding
based onemotional state
relation with the other
the objective
the situation
age, status
education
cultural background
Active listening: the art of the receiver to decode the message
verbal
message
nonverbal
message
idea to be
expressedown interpretation
of idea
emotional state
relation with the other
the objective
the situation
age, status
education
cultural background
encoding
based on
from: "Listening and communicating" by Lia Charité, www.liacharite.nl
decoding
based onemotional state
relation with the other
the objective
the situation
age, status
education
cultural background
Human Side: Interpersonal Skills47 Gerrit Muller
version: 0.1October 28, 2018
CVCbilateralCommunication
Intense interaction needed for mutual understanding
person A
encoder
decoder
idea1
idea1"
- B's context
language
B's incentives
person B
encoder
decoder
idea2"
idea2
- A's context
language
A's incentives
idea2' idea1'
to calibrate:
repeat many times with different
examples, illustrations, and explanations
Human Side: Interpersonal Skills48 Gerrit Muller
version: 0.1October 28, 2018
CVCcodingCalibration
Mutual understanding as function of time
time
leve
l of
mu
tual
un
der
stan
din
g
intense
interaction
intense
interaction
no interaction
Human Side: Interpersonal Skills49 Gerrit Muller
version: 0.1October 28, 2018
CVCunderstandingInTime
The material for interpersonal skills
is based on a set of techniques
from a course
"Interpersonal Management Skills"
by
Hay Management Consultants
in 1998
Human Side: Interpersonal Skills50 Gerrit Muller
version: 0.1October 28, 2018
HSISacknowledgements
Investigate and Acknowledge
"This is too
expensive"
material $$
effort $$
investigate: What has been said and why?
acknowledge: Paraphrase what has been said and why?
i.e. use your own words
When a decision will be taken or an action will be started on the basis of exchanged information, opinions or suggestions or when the first reaction is to reject, ignore or contradict what you just heard.
Human Side: Interpersonal Skills51 Gerrit Muller
version: 0.1October 28, 2018
HSISinvestigate
Constructive Feedback
How + Indicate the strong points to be kept + Indicate the points to be improved + Search for solutions which build upon the strong points and improve the weak points
When You want to facilitate someone to improve his/her performance
Human Side: Interpersonal Skills52 Gerrit Muller
version: 0.1October 28, 2018
HSISfeedback
Conflict Management
How? define the positions: * indicate what is important for you and why * investigate and acknowledge what is
important for the other and why
When
in case of conflict
option A $$
option B elegance
Search for alternative solutions
Finish the conversation: * acknowledge the right to have a
different opinion * indicate your decision and why
IF
If you are willing and able to consider alternatives:
If you are not willing and able to consider alternatives, or no acceptable solution for
both parties can be found:
Human Side: Interpersonal Skills53 Gerrit Muller
version: 0.1October 28, 2018
HSISconflictManagement
Appraisal
How + Mention the performance very specific.
+ Mention the personal qualities which lead to this performance.
+ Describe which advantages arise for you,
the department or the organization.
When Someone’s performance is important for you * exceeding the expectations * meets expectations continuously * meets expectations, which exceed the normal
performance level of this person
Appraise only when authentic!
Human Side: Interpersonal Skills54 Gerrit Muller
version: 0.1October 28, 2018
HSISappraisal
Conversation Good Practices
When you open a conversation
formulate the purpose
When you finish the conversation
summarize the agreements and the actionplan
Human Side: Interpersonal Skills55 Gerrit Muller
version: 0.1October 28, 2018HSISconversation
Searching for Ideas
When asking for a suggestion
When supplying a suggestion
When you use or build
upon ideas of others
When you need new or
more creative ideas
give a reaction
ask for a reaction
mention the source of the
ideas
remove limitations temporarily
or add limitations
Human Side: Interpersonal Skills56 Gerrit Muller
version: 0.1October 28, 2018
HSISsearchingForIdeas
Human Side: Team Workby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The creation of products requires many different people to cooperate. The workis often organized in teams. The team members have complimentary skills andknowledge. In many management courses the need to design teams is empha-sized. Unfortunately, often these recommendations are ignored. We re-iteratein this paper the rationale for teams and the recommendations for designing theteam itself.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: draftversion: 0.2
deaf cannot hear
blind cannot see
mute cannot speak
but in the team two can hear, two can see, and two can speak
Teams consist of complementary people
deaf cannot hear
blind cannot see
mute cannot speak
but in the team two can hear, two can see, and two can speak
Human Side: Team Work58 Gerrit Muller
version: 0.2October 28, 2018HSTWthreeApes
Organization size and teams
1 2 4 8 16 32 64
room
floor
128 256
building
512
campus
Human Side: Team Work59 Gerrit Muller
version: 0.2October 28, 2018
BLOATorganization
Very simplistic team model
1-person team
eff = 100%
2-person team
eff = 75%
3-person team
eff = 50%
4-person team
eff = 25%
legend
productive work
communication
Human Side: Team Work60 Gerrit Muller
version: 0.2October 28, 2018
HSTWsimpleTeamModel
Hierarchical simplistic team model
2-person team
eff = 75%
3-person team
eff = 66%
4-person team
eff = 62.5%
legend
productive work
communication
9-person team
eff ~= 56%
Human Side: Team Work61 Gerrit Muller
version: 0.2October 28, 2018
HSTWhierarchicalModel
Many personality and role models are available
Myers-Briggs Type Indicators
Belbin's team roles
neutral facts
feeling instinctive
negative flaws
positive benefits
creative ideas
process meta
Six thinking hats by Edward de Bono
plant creative
resource investigator enthusiatic communicator
co-ordinator mature, chairman
shaper driver, dynamic
monitor evaluator sober, analytical
team worker co-operative, averts friction
implementer disciplined, conservative, do-er
completer finisher conscientious, painstaking
specialist single-minded, rare skills
E Extraversion
S Sensing
T Thinking
J Judging
Introversion I
iNtuition N
Feeling F
Perceiving P
Human Side: Team Work62 Gerrit Muller
version: 0.2October 28, 2018
HSTWroles
Process of creating and using a team
well-defined charter
What, When, Where, How, Whom
team owner
team
determines charter
with sufficient room for the
team to determine the way-of-working
output
to be respected by receivers
Human Side: Team Work63 Gerrit Muller
version: 0.2October 28, 2018
HSTWcharter
“War Room” is very effective
windows
desk
desk
desk
desk
windows
desk
cabi
nets
cabi
nets
table
tables
wal
l spa
ce
wall space
Human Side: Team Work64 Gerrit Muller
version: 0.2October 28, 2018HSTWwarRoom
Concurrency and Fragmentation lower efficiency
time
or
How many (semi-)concurrent tasks can a person handle?
Working in burst-mode (concentrating on one task for one day,
week or month) can increase efficiency.
six tasks in parallel: all results are late
six tasks sequential first result in 1/6 of time!
Human Side: Team Work65 Gerrit Muller
version: 0.2October 28, 2018
HSTWfragmentationAndConcurrency
One person will be member of multiple teams
design team product A
roadmapping team
Image quality team
process improvement
team
subsystem team
format compliance
team
It is quite normal to participate in many teams simultaneously.
However, a team can only function if the members are sufficiently available!
Human Side: Team Work66 Gerrit Muller
version: 0.2October 28, 2018
HSTWmultipleTeams
Critical Success Factors for teams
well defined charter
clear owner of the result
respect for the output of the team
freedom of way-of-working
housing and location
availability of team members
complementary roles
diversity, pluriformity
Human Side: Team Work67 Gerrit Muller
version: 0.2October 28, 2018
HSTWcriticalSuccessFactors
Architecting Interaction Stylesby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
A system architects needs skills to apply different interactions styles, dependingon the circumstances. This document discusses the following interaction styles:provocation, facilitation, leading, empathic, interviewing, white board simulation,and judo tactics.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: draftversion: 0.2
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
when in an impasse: provoke effective when used sparsely
especially recommended when new in a field: contribute to the team, while absorbing new knowledge
provide vision and direction, make choices risk: followers stop to give the needed feedback
take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
invite a few engineers and walk through the system operation step by step
first listen to the stakeholder and then explain cost and alternative opportunities
Architecting Styles
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
when in an impasse: provoke effective when used sparsely
especially recommended when new in a field: contribute to the team, while absorbing new knowledge
provide vision and direction, make choices risk: followers stop to give the needed feedback
take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
invite a few engineers and walk through the system operation step by step
first listen to the stakeholder and then explain cost and alternative opportunities
Architecting Interaction Styles69 Gerrit Muller
version: 0.2October 28, 2018
ASstyles
Function Profiles; The Sheep with Seven Legsby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The profile of a system architect is quantified for a large list of system architectrelated characteristics. For comparison the function profiles of related functionsare given as well. This profile is based on personal observations and experience.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: conceptversion: 1.0 co
mm
unic
atio
n te
amw
ork
docu
men
tatio
n m
ultit
aski
ng
flexi
ble,
ope
n au
thor
ity b
y ex
perti
se
spec
ialis
t ge
nera
list
conc
eptu
al
prag
mat
ic
cons
truct
ive
criti
cal
fast
abs
orpt
ion
of k
now
ledg
e cr
eativ
ity
man
ual s
kills
pr
oces
s in
sigh
t po
litic
al in
sigh
t im
prov
emen
t co
mpl
eten
ess
cust
omer
val
ue
sale
s fe
atur
es
com
mer
cial
insi
ght
coac
hing
se
lect
ion
appr
aisa
l m
otiv
atio
n
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing mon
itor p
rogr
ess
sche
dule
initi
al c
ost
System Architect
com
mun
icat
ion
team
wor
k do
cum
enta
tion
mul
titas
king
fle
xibl
e, o
pen
auth
ority
by
expe
rtise
sp
ecia
list
gene
ralis
t co
ncep
tual
pr
agm
atic
co
nstru
ctiv
e cr
itica
l fa
st a
bsor
ptio
n of
kno
wle
dge
crea
tivity
m
anua
l ski
lls
proc
ess
insi
ght
polit
ical
insi
ght
impr
ovem
ent
com
plet
enes
s
cust
omer
val
ue
sale
s fe
atur
es
com
mer
cial
insi
ght
coac
hing
se
lect
ion
appr
aisa
l m
otiv
atio
n
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing mon
itor p
rogr
ess
sche
dule
initi
al c
ost
Function Profiles; The Sheep with Seven Legs71 Gerrit Muller
version: 1.0October 28, 2018
FPsystemArchitect
Test Engineerco
mm
unic
atio
n te
amw
ork
docu
men
tatio
n m
ultit
aski
ng
flexi
ble,
ope
n au
thor
ity b
y ex
perti
se
spec
ialis
t ge
nera
list
conc
eptu
al
prag
mat
ic
cons
truct
ive
criti
cal
fast
abs
orpt
ion
of k
now
ledg
e cr
eativ
ity
man
ual s
kills
pr
oces
s in
sigh
t po
litic
al in
sigh
t im
prov
emen
t co
mpl
eten
ess
mon
itor p
rogr
ess
cust
omer
val
ue
sale
s fe
atur
es
coac
hing
se
lect
ion
appr
aisa
l m
otiv
atio
n
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing
sche
dule
initi
al c
ost
com
mer
cial
insi
ght
Function Profiles; The Sheep with Seven Legs72 Gerrit Muller
version: 1.0October 28, 2018
FPtestEngineer
Developer
com
mun
icat
ion
team
wor
k do
cum
enta
tion
mul
titas
king
fle
xibl
e, o
pen
auth
ority
by
expe
rtise
sp
ecia
list
gene
ralis
t co
ncep
tual
pr
agm
atic
co
nstru
ctiv
e cr
itica
l fa
st a
bsor
ptio
n of
kno
wle
dge
crea
tivity
m
anua
l ski
lls
proc
ess
insi
ght
polit
ical
insi
ght
impr
ovem
ent
com
plet
enes
s
mon
itor p
rogr
ess
cust
omer
val
ue
sele
ctio
n ap
prai
sal
mot
ivat
ion
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing
com
mer
cial
insi
ght
sche
dule
initi
al c
ost
sale
s fe
atur
es
coac
hing
Function Profiles; The Sheep with Seven Legs73 Gerrit Muller
version: 1.0October 28, 2018
FPdeveloper
Operational Leaderco
mm
unic
atio
n te
amw
ork
docu
men
tatio
n m
ultit
aski
ng
flexi
ble,
ope
n au
thor
ity b
y ex
perti
se
spec
ialis
t ge
nera
list
conc
eptu
al
prag
mat
ic
cons
truct
ive
criti
cal
fast
abs
orpt
ion
of k
now
ledg
e cr
eativ
ity
man
ual s
kills
pr
oces
s in
sigh
t po
litic
al in
sigh
t im
prov
emen
t co
mpl
eten
ess
mon
itor p
rogr
ess
cust
omer
val
ue
sele
ctio
n ap
prai
sal
mot
ivat
ion
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing
com
mer
cial
insi
ght
sche
dule
initi
al c
ost
sale
s fe
atur
es
coac
hing
Function Profiles; The Sheep with Seven Legs74 Gerrit Muller
version: 1.0October 28, 2018
FPoperationalLeader
Line Manager
com
mun
icat
ion
team
wor
k do
cum
enta
tion
mul
titas
king
fle
xibl
e, o
pen
auth
ority
by
expe
rtise
sp
ecia
list
gene
ralis
t co
ncep
tual
pr
agm
atic
polit
ical
insi
ght
impr
ovem
ent
com
plet
enes
s
mon
itor p
rogr
ess
cust
omer
val
ue
sale
s fe
atur
es
com
mer
cial
in
sigh
t co
achi
ng
sele
ctio
n ap
prai
sal
mot
ivat
ion
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing
sche
dule
initi
al c
ost
fast
abs
orpt
ion
of k
now
ledg
e co
nstru
ctiv
e cr
itica
l
man
ual s
kills
cr
eativ
ity
proc
ess
insi
ght
Function Profiles; The Sheep with Seven Legs75 Gerrit Muller
version: 1.0October 28, 2018
FPlineManager
Commercial Managerco
mm
unic
atio
n te
amw
ork
docu
men
tatio
n m
ultit
aski
ng
flexi
ble,
ope
n au
thor
ity b
y ex
perti
se
spec
ialis
t ge
nera
list
conc
eptu
al
prag
mat
ic
cons
truct
ive
criti
cal
fast
abs
orpt
ion
of k
now
ledg
e
polit
ical
insi
ght
impr
ovem
ent
com
plet
enes
s
cust
omer
val
ue
sale
s fe
atur
es
com
mer
cial
insi
ght
coac
hing
se
lect
ion
appr
aisa
l m
otiv
atio
n
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
deci
sion
mak
ing mon
itor p
rogr
ess
sche
dule
initi
al c
ost
man
ual s
kills
cr
eativ
ity
proc
ess
insi
ght
Function Profiles; The Sheep with Seven Legs76 Gerrit Muller
version: 1.0October 28, 2018
FPcommercialManager
The numbers behind the bars
9
6
6
5
5
5
9
9
5
5
4
5
8
4
9
5
4
9
com
mun
icat
ion
team
wor
k do
cum
enta
tion
mul
titas
king
fle
xibl
e, o
pen
auth
ority
by
expe
rtise
sp
ecia
list
gene
ralis
t co
ncep
tual
pr
agm
atic
co
nstru
ctiv
e cr
itica
l fa
st a
bsor
ptio
n of
kno
wle
dge
crea
tivity
m
anua
l ski
lls
proc
ess
insi
ght
polit
icsa
l ins
ight
im
prov
emen
t co
mpl
eten
ess
mon
itor p
rogr
ess
cust
omer
val
ue
sale
s fe
atur
es
com
mer
cial
insi
ght
coac
hing
se
lect
ion
appr
aisa
l m
otiv
atio
n
deci
sion
mak
ing
sche
dule
initi
al c
ost
9
5
6
8
6
9
8
6
8
8
6
8
9
4
7
4
4
4
9
4
4
9
4
8
9
5
6
5
5
8
9
8
6
4
5
8
3
4
9
2
7
2
9
7
3
6
4
5
9
4
6
4
6
7
7
9
8
9
5
9
3
9
7
3
2
2
7
6
6
9
9
4
7
4
5
9
6
4
3
3
7
9
4
5
8
6
5
7
5
9
4
3
3
5
3
9
6
2
2
5
9
4
5
2
3
6
9
2
5
4
7
9
4
5
5
4
4
5
9
4
2
3
6
9
4
2
5
3
8
9
4
5
8
3
4
9
4
8
4
2
2
3
3
9
3
2
2
6
9
2
7
4
2
8
9
8
test engineer
systems architect
developer
operational leader
line manager
commercial manager
Function Profiles; The Sheep with Seven Legs77 Gerrit Muller
version: 1.0October 28, 2018
FPtableWithValues
Short introduction to basic “CAFCR” modelby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The basic “CAFCR” reference model is described, which is used to describea system in relation to its context. The main stakeholder in the context is thecustomer. The question “Who is the customer?” is addressed.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: draftversion: 0.4
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
The “CAFCR” model
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
Short introduction to basic “CAFCR” model79 Gerrit Muller
version: 0.4October 28, 2018CAFCRannotated
Integrating CAFCR
Customer
objectives
Application Functional Conceptual Realization
intention
constraintawareness
objectivedriven
contextunderstanding
oppor-tunities
knowledgebased
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
Short introduction to basic “CAFCR” model80 Gerrit Muller
version: 0.4October 28, 2018
MSintegratingCAFCR
CAFCR can be applied recursively
System
(producer)
Customer
BusinessDrives
Enables
Customer's
Customer
BusinessDrives
Enables
ConsumerDrives
Enables
Value Chain
larger scope has smaller
influence on architecture
Short introduction to basic “CAFCR” model81 Gerrit Muller
version: 0.4October 28, 2018CAFCRrecursion
Market segmentation
geographical
business model profit, non profit
examples
economics
USA, UK, Germany, Japan, China
high end versus cost constrained
consumers youth, elderly
segmentation
axis
outlet retailer, provider, OEM, consumer direct
Short introduction to basic “CAFCR” model82 Gerrit Muller
version: 0.4October 28, 2018
BCAFCRcustomerSegmentation
Example of a small buying organization
decision maker(s) purchaser
maintainer
operator
user
CEO
CFO
CTO
CIO
department head
Who is the customer?
CMO
CEO: Chief Executive Officer
CFO: Chief Financial Officer
CIO: Chief Information Officer
CMO: Chief Marketing Officer
CTO: Chief Technology Officer
Short introduction to basic “CAFCR” model83 Gerrit Muller
version: 0.4October 28, 2018
BCAFCRwhoIsTheCustomer
CAFCR+ model; Life Cycle View
Customer
objectives
Application Functional Conceptual Realization
Life cycleoperations
maintenance
upgrades
development
manufacturing
installation
sales, service, logistics, production, R&D
Short introduction to basic “CAFCR” model84 Gerrit Muller
version: 0.4October 28, 2018
BCAFCRplusLifeCycle
Security as example through all views
ApplicationCustomer
objectives
Functional Conceptual Realization
sensitive
information
trusted
not trusted
selection
classificationpeople
information
authenticationbadges
passwords
locks / walls
guards
administrators
social contacts
open passwords
blackmail
burglary
fraud
unworkable procedures
cryptography
firewall
security zones
authentication
registry
logging
holes between
concepts
functions foradministration
authentication
intrusion detection
logging
quantification
bugsbuffer overflow
non encrypted
storage
poor exception
handling
missing
functionality
wrong
quantification
specific
algorithms
interfaces
libraries
servers
storage
protocols
desired characteristics, specifications & mechanisms
threats
Short introduction to basic “CAFCR” model85 Gerrit Muller
version: 0.4October 28, 2018
QNsecurityExample
Story How Toby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
A story is an easily accessible story or narrative to make an application live. Agood story is highly specific and articulated entirely in the problem domain: thenative world of the users. An important function of a story is to enable specific(quantified, relevant, explicit) discussions.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
October 28, 2018status: conceptversion: 1.2
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
From story to design
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
Story How To87 Gerrit Muller
version: 1.2October 28, 2018
SHTfromStoryToDesign
Example story layout
A day in the life of Bob
bla blah bla, rabarber music
bla bla composer bla bla
qwwwety30 zeps.
nja nja njet njippie est quo
vadis? Pjotr jaleski bla bla
bla brree fgfg gsg hgrg
mjmm bas engel heeft een
interressant excuus, lex stelt
voor om vanavond door te
werken.
In the middle of the night he
is awake and decides to
change the world forever.
The next hour the great
event takes place:
This brilliant invention will change the world foreverbecause it is so unique and
valuable that nobody beliefs the feasibility. It is great and WOW at the same time,
highly exciting.
Vtables are seen as the soltution for an indirection problem. The invention of Bob will
obsolete all of this in one incredibke move, which will make him famous forever.
He opens his PDA, logs in and enters his provate secure unqiue non trivial password,
followed by a thorough authentication. The PDA asks for the fingerprint of this little left
toe and to pronounce the word shit. After passing this test Bob can continue.
draft or sketch of
some essential
applianceca. half a page of
plain English text
Yes
or
No
that is the question
Story How To88 Gerrit Muller
version: 1.2October 28, 2018
SHTexampleStoryLayout
Points of attention
• purpose
• scope
• viewpoint, stakeholders
• visualization
• size (max 1 A4)
• recursive decomposition, refinement
What do you need to know for
specification and design?
“umbrella” or specific event?
Define your stakeholder and viewpoint
f.i. user, maintainer, installer
Sketches or cartoon
Helps to share and communicate ideas
Can be read or told in few minutes
Story How To89 Gerrit Muller
version: 1.2October 28, 2018
SHTattentionPoints
Criteria for a good story
• accessible, understandable
• valuable, appealing
• critical, challenging
• frequent, no exceptional niche
• specific
"Do you see it in front of you?"
attractive, important
"Are customers queuing up for this?"
"What is difficult in the realization?"
"What do you learn w.r.t. the design?"
names, ages, amounts, durations, titles, ...
"Does it add significantly to the bottom line?"
Customer
objectives
Application
Functional
Conceptual
Realization
Customer
objectives
Application
Application
Application
Story How To90 Gerrit Muller
version: 1.2October 28, 2018SHTcriterionsList
Example of a story
Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed
away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,
come and visit her every weekend, often with Betty’s grandchildren Ashley and Christopher.
As so many women of her age, Betty is reluctant to touch anything that has a technical
appearance. She knows how to operate her television, but a VCR or even a DVD player is
way to complex.
When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy
environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of
the frequency spectrum shows a loss of about 45dB. This is why she had problems
understanding her grandchildren and why her children urged her to apply for hearing aids two
years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing
aids’ batteries. Fortunately her children can do this every weekend.
This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folk’s
home. It’s summer now and the tables are outside. With all those people there it’s a lot of
chatter and babble. Two years ago Betty would never go to the bingo: “I cannot hear a thing
when everyone babbles and clatters with the coffee cups. How can I hear the winning
numbers?!”. Now that she has her new digital hearing instruments, even in the bingo
cacophony, she can understand everyone she looks at. Her social life has improved a lot and
she even won the bingo a few times.
That same night, together with her friend Janet, she attends Mozart’s opera The Magic Flute.
Two years earlier this would have been one big low rumbly mess, but now she even hears the
sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol also
has hearing aids, however hers only “work well” in normal conversations. “When I hear music
it’s as if a butcher’s knife cuts through my head. It’s way too sharp!”. So Carol prefers to take
her hearing aids out, missing most of the fun. Betty is so happy that her hearing instruments
simply know where they are and adapt to their environment.
source: Roland Mathijssen
Embedded Systems Institute
Eindhoven
Story How To91 Gerrit Muller
version: 1.2October 28, 2018
SHTexample
Value and Challenges in this story
Challenges in this story:
Intelligent hearing instrument
Battery life at least 1 week
No buttons or other fancy user interface on the hearing instrument,
other than a robust On/Off method
The user does not want a technical device but a solution for a problem
Instrument can be adapted to the hearing loss of the user
Directional sensitivity (to prevent the so-called cocktail party effect)
Recognition of sound environments and automatic adaptation (adaptive
filtering)
source: Roland Mathijssen, Embedded Systems Institute, Eindhoven
Conceptual
Realization
Customer
objectives
Application
Value proposition in this story:
quality of life:
active participation in different social settings
usability for nontechnical elderly people:
"intelligent" system is simple to use
loading of batteries
Story How To92 Gerrit Muller
version: 1.2October 28, 2018
SHTexampleCriteria