This week: Requirements elicitation techniques ch 4 and 19, plus more

1
This weekRequirements elicitation
techniques(ch 4 and 19, plus more)

• John Krogstie, IDI

2
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
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
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
Project types and approaches
Project models

• Adapted from (Lauesen, 2002)

OK good ? dubious not good variable
price
6
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
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
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
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
Techniques vs elicitation need (Lauesen, 2002)
The darker, the better. For list of techniques,
see next slide
11
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
Techniques, indicators (Davis, 2003)

• positive sides, ? challenges, - dont 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
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
Techniques, indicators (cont.)

• Less preferred techniques
• Analyse existing system
• ? too bound, overlook other possibilities
• Prototyping (as elicitation technique)
• - dont use rapid prototyping unless you really
  believe itll 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
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
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
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
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
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
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
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)
• Dont 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
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 stakeholders work to business objectives
• Elicit critical success factors
• Show the respodents how they can benefit

23
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 (CSFs)
• 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 CSFs apply to this activity?
• (and similarly, if info, CSF, decision, is
  mentioned first)

24
Style guidelines

• Keep questions brief and clear
• Avoid leading questions
• ..and premature suggestions for solutions
• Use the stakeholders 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
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
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
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
Requirements workshop roles

• Facilitator
• A requirements engineer
• Scribe
• Also a requirements engineer
• Participants
• User and customer representatives
• Domain experts
• Possibly Designers, testers

29
How to run a workshop (1)

• Lauesen (2002) suggests
• Invite participants
• Open meeting
• Brainstorm bad experiences
• Brainstorm ideal future (wishes)
• List the issues, group similar ones
• Prioritize the issues
• Review the list
• Then process the list, formulate requirements

30
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
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. RE03
• 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