DFDreq.ppt1 TDT4175 - Information Systems, Spring 2006 This week: R equirements elicitation techniques (ch 4 and 19, plus more) John Krogstie, IDI

DFDreq.ppt 1

TDT4175 - Information Systems, Spring 2006

This week:

Requirements 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

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


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)

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


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, - 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


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)

-: ”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


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)

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


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


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


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


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:

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


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. 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

Documents

DFDreq.ppt1 TDT4175 - Information Systems, Spring 2006 This week: R equirements elicitation techniques (ch 4 and 19, plus more) John Krogstie, IDI