dfdreq.ppt1 tdt4175 - information systems, spring 2006 this week: r equirements elicitation...
TRANSCRIPT
DFDreq.ppt 1
TDT4175 - Information Systems, Spring 2006
This week:
Requirements elicitation techniques(ch 4 and 19, plus more)
John Krogstie, IDI
2
TDT4175 - Information Systems, Spring 2006
Overview of the week
Summary of last week
Overview of elicitation techniques
Based on Hawr. Ch 4 + some extra material
More on specific techniques
Interviews (ch 19)
Requirement workshops
With practical examples
3
TDT4175 - Information Systems, Spring 2006
Summary of last week
Ch 3, 4, 7: main lessons
System development must be anchored in strategy and business objectives
Connected to organization development
From problem to solution, feasibility
Requirements
Can be formulated on different levels
Goal-design scale
Different project types affect the choice of requirements approach
And what level of requirement is most appropriate
4
TDT4175 - Information Systems, Spring 2006
Summary of last week (cont.)
Goal-design scale (example: project support system)
Goal-level req: ”…precalculations accurate to within 5%”
Domain-level req: ”…support cost recording and quotation with experience data”
Product-level req: ”…recording and retrieval functions for experience data”
Design-level req: ”…screen pictures as shown in app.XX”
Requirements approaches (focus: functional requirements)
Traditional approach: product-level requirements
Fast approach: domain-level requirements
Two-step approach: domain-level + design-level
Choice depends on project type
5
TDT4175 - Information Systems, Spring 2006
Project types and approaches
Adapted from (Lauesen, 2002):
Project type Trad Fast Two-step
In-house development ? OK OK
Product development ? OK
Time and materials ? OK OK
Acquire COTS business appl. ? OK
Acquire COTS tech. tool OK
Tender (with COTS) ? OK
Tender (custom-build) ? OK* OK*
Contract (with COTS) ? OK
Contract (custom-build) ? OK* OK*
Sub-contract OK
Maintenance OK
Project models
OK = good? = dubious = not good
* = variable price
6
TDT4175 - Information Systems, Spring 2006
Overview of elicitation techniques
Asking questions Interviews Questionnaires
Observation Unobtrusive / dialogue / participating Task demonstration
Formal group sessions Brainstorming Focus group / workshops
Document studies Modelling, simulation etc. Prototyping, storyboarding and similar
Paper or code COTS acquisition: pilot experiments, demo versions
Agile methods, e.g. XP
7
TDT4175 - Information Systems, Spring 2006
Additional tasks
Not directly elicitation But may be necessary to get elicitation done
Preparation Stakeholder identification
Teambuilding
Negotiation / conflict resolution
Risk analysis
Completeness checking techniques Goal-requirements tracing
Requirement taxonomies
8
TDT4175 - Information Systems, Spring 2006
Challenges for elicitation
Stakeholders unable to express their needs Selective memory (exaggerate recent problems) Symptoms, not requirements
Difficult to explain tasks and motivations Tendency to suggest solutions, not demands Lack of imagination
New ways of doing things, consequences
Too many requirements! (some just nice-to-have) Demands change over time Conflicts among stakeholders General resistance to change
Fear of losing job or losing power Stress from needing to learn new technology
9
TDT4175 - Information Systems, Spring 2006
When to use different techniques?
Depends on type of project, e.g.
COTS development: no customer to interview
But can potentially involve market or support personnel
COTS acquisition or tender: XP or prototyping pointless
Also depends on what you want to elicit, e.g.,
Observation good for tacit knowledge, current situation
Interviews for explicit knowledge, current situation
Workshops for future situation
Other indicators (and counter-indicators)
Situations where a technique is particularly useful
(or should not be used)
10
TDT4175 - Information Systems, Spring 2006
Techniques vs elicitation need (Lauesen, 2002)
What to elicit? S I O T D Q B F W w P p c A N R C G d
Present work
Present problems
Goals, key issues
Future sys ideas
Realistic possib.
Consequences, risks
Commitment
Conflict resolution
Requirements
Priorities
Completeness
The darker, the better. For list of techniques, see next slide
11
TDT4175 - Information Systems, Spring 2006
List of techniques for table previous slide
S = Stakeholder analysis
I = Interview
O = Observation
T = Task demo
D = Document analysis
Q = Questionnaires
B = Brainstorm
F = Focus groups
W = Domain workshop
w = Design workshop
P = Prototyping
p = Pilot experiment
c = similar Companies
A = Ask suppliers
N = negotiation
R = risk analysis
C = Cost/benefit
G = Goal-domain analysis
d = domain-requirement analysis
12
TDT4175 - Information Systems, Spring 2006
Techniques, indicators (Davis, 2003)
+ positive sides, ? challenges, - don’t use when
Group sessions: strongly recommended
+ all project types, many stakeholders, creativity
? dominant persons, conflicts
Interview: often used
+ find new info, background knowledge, conflicts
? Misunderstandings, tacit knowledge
Observation:
+ low burden on users, existing system, politics
+ tacit knowledge
13
TDT4175 - Information Systems, Spring 2006
Techniques, indicators (cont.)
Models: strongly recommended +: support communication, organize info, discover
missing info
? Directly w/stakeholders or background activity
Requirements taxonomies +: Ensure that all types of requirements are included
?: do not directly find requirements, must combine w/ other technique
Issues list +: avoid digressions w/other techniques, remember
Conflict resolution: The more important the bigger the project
14
TDT4175 - Information Systems, Spring 2006
Techniques, indicators (cont.)
Less preferred techniques:
Analyse existing system
?: too bound, overlook other possibilities
Prototyping (as elicitation technique)
-: ”don’t use rapid prototyping unless you really believe it’ll be rapid!”
Questionnaires
+: concrete problems, market studies, external customers
?: limited information content
XP
+: problem domain is quickly changing
?: heavy burden on customer, project type limitations
Formal specifications
?: Hard to understand for stakeholders
15
TDT4175 - Information Systems, Spring 2006
Interviews, strategy
Often used elicitation technique
But not always the best
Must fit into a bigger knowledge search strategy
Cf Figure 19.1
Top-down approach, Fig 19.2
Start with management
Overall view of the system
Goals, key performance indicators
Access to people on lower levels
Looking at detailed operations
Build models while interviewing
16
TDT4175 - Information Systems, Spring 2006
Interview planning
Who should be interviewed?
E.g., use organizational chart
Sequence of interviews
Interview plan for each stakeholder
Normally need more interviews per person
One interview max 45-60 minutes
17
TDT4175 - Information Systems, Spring 2006
Types of questions
Planned or improvised
Open questions
Establish viewpoints
Generally expecting long answers
Closed questions
Requires a direct (and shorter) answer
Probes
Follow-up questions for a previous answer
18
TDT4175 - Information Systems, Spring 2006
Interview quality (Kvale, 1996)
6 quality criteria (Kvale, 1996)
The extent of rich, specific and relevant answers
Short questions, long answers
The interviewer follows up and clarifies relevant aspects of the answers
The degree of interactive interpretation
The interviewer attempts to verify her/his interpretations of the subjects answers
The interview is self-communicating
Becoming a good interviewer mainly requires training
19
TDT4175 - Information Systems, Spring 2006
Qualification criteria (Kvale, 1996)
A good interviewer must be
Knowledgeable (but not boasting)
Structuring (introduce purpose and procedure)
Clear (easy questions, distinct speech)
Gentle (easy-going, tolerant)
Sensitive (hears nuances & emotions)
Open (to new aspects & priorities)
Steering (interrupting digressions)
Critical (not take everything at face value)
Remembering (relate current statement with previous)
Interpreting (give feedback to confirm understanding)
20
TDT4175 - Information Systems, Spring 2006
Guidelines for performing the interview
Structure guidelines
What different parts does the interview consist of?
Content guidelines
What issues to pursue? What questions to ask?
Style guidelines
How to phrase these questions?
Social guidelines
How to encourage the respondent to talk freely, and maintain a good interpersonal relationship?
21
TDT4175 - Information Systems, Spring 2006
Structure guidelines
A macro-structure is shown in Fig 19.3
Below are some additional guidelines
Prepare a list of questions in advance
Leave space between questions (for answers)
Leave space below questions (for emerging topics)
Don’t be too bound by this list
Micro-structure (within body of interview):
Ask, listen, feed back your understanding
Thank the respondent for her / his time!
22
TDT4175 - Information Systems, Spring 2006
Content guidelines
Give the respondent a starting-point for talking
specific context rather than ”work in general”
Initially, broad questions
Day-to-day work and problems
What the stakeholder does, information used, …
Focus on critical tasks
When is the stakeholder under stress?
When is it important that something is 100% correct?
Find out why (activities performed / info needed)
Relate stakeholder’s work to business objectives
Elicit critical success factors
Show the respodents how they can benefit
23
TDT4175 - Information Systems, Spring 2006
Content guidelines (cont.)
Follow-up questions, typical patterns
Adding questions about where, what, when, who (did something), for whom (something is done), how, why
choose the 1-3 most relevant
Pursuing the relationship between activities, information, decisions, problems, and critical success factors (CSF’s)
E.g., if the user mentioned an activity:
What info do you need in this activity?
What decisions take place in this activity?
What problems have you had performing this activity?
What CSF’s apply to this activity?
(and similarly, if info, CSF, decision, … is mentioned first)
24
TDT4175 - Information Systems, Spring 2006
Style guidelines
Keep questions brief and clear
Avoid leading questions
..and premature suggestions for solutions
Use the stakeholder’s terminology
Avoid translation, avoid advanced ICT terminology
Choose the right mix of open & closed questions
Cf textbook, pp 463-465
Use diagrams where appropriate
But simple, informal syntax
Draw interactively, and/or
…encourage user to contribute / change the model
25
TDT4175 - Information Systems, Spring 2006
Social guidelines
Clarify your mandate and purpose
Appear as competent Be cautious with humour / irony
Be polite, yet at ease
Be sympathetic to users’ problems But cautious about down-talking current system!
Show interest and respect Body language, cues, nodding, etc.
Be sensitive to different personality types E.g., generally shy, ”ICT-shy”, talkative, intellectualizing,
manipulative
”Why” is a dangerous word with some respondents Rather use ”when?”
26
TDT4175 - Information Systems, Spring 2006
Special info about the interview exercise
Done with group pairs Tuesday (17-19): Group A is customer, B interviews
Thursday (12-14): opposite
Each interview: 25 minutes The rest of the customer group observes
The rest of the consultant group is not present
Read instructions and make preparations in advance, bring Pencil and paper
Preferrably with some planned questions
Customer group: evaluation forms
Watch (to keep the time)
Recording equipment not compulsory, but strongly recommended
Write up the interview results as soon as possible after the interview
i.e., before you forget the details
27
TDT4175 - Information Systems, Spring 2006
The requirements workshop
Structured group session to identify requirements
In industry: may last 2-5 days
Often better than interviews for finding requirements
Gather all the important stakeholders at once
Avoid several interviews finding overlapping requirements
Opportunities for immediate conflict resolution, prioritization, etc.
Fosters creativity
28
TDT4175 - Information Systems, Spring 2006
Requirements workshop: roles
Facilitator
A requirements engineer
Scribe
Also a requirements engineer
Participants
User and customer representatives
Domain experts
Possibly: Designers, testers
29
TDT4175 - Information Systems, Spring 2006
How to run a workshop (1)
Lauesen (2002) suggests:
1. Invite participants
2. Open meeting
3. Brainstorm bad experiences
4. Brainstorm ideal future (wishes)
5. List the issues, group similar ones
6. Prioritize the issues
7. Review the list
Then process the list, formulate requirements
30
TDT4175 - Information Systems, Spring 2006
How to run a workshop (2)
Alexander (2002) suggests (after planning): First morning:
Define various user groups Teach about organizing req.spec. Let participants define structure & responsibilities Split group in several interests, fill structure in parallel Teach about review, perform reviews Update material based on reviews
Then, repeat until exhaustion: Backroom clean-up Distribute, review, redraft
After workshop: Clean up requirements Send out draft for further comments
31
TDT4175 - Information Systems, Spring 2006
References
Søren Lauesen: ”Software Requirements: Styles and Techniques”, Addison-Wesley, 2002
Ann Hickey and Alan M. Davis: ”Elicitation technique selection: How do experts do it?”, Proc. RE’03
Steinar Kvale: ”Interviews: An introduction to qualitative research interviewing”, Sage, 1996
Ian F. Alexander and Richard Stevens: ”Writing Better Requirements”, Addison-Wesley, 2002
Suzanne and James Robertson: ”Mastering the Requirements Process”, Addison-Wesley, 1999