TDT 4175 — Information Systems Spring 2006 This

TDT 4175 - Information Systems, Spring 2006 This week: Requirements elicitation techniques (ch 4 and 19, plus more) John Krogstie, IDI DFDreq. ppt 1

TDT 4175 - Information Systems, Spring 2006 Overview of the week l Summary of last week l Overview of elicitation techniques u l Based on Hawr. Ch 4 + some extra material More on specific techniques u u l Interviews (ch 19) Requirement workshops With practical examples 2

TDT 4175 - Information Systems, Spring 2006 Summary of last week n Ch 3, 4, 7: main lessons l l Connected to organization development l n System development must be anchored in strategy and business objectives From problem to solution, feasibility Requirements l Can be formulated on different levels u l Goal-design scale Different project types affect the choice of requirements approach u And what level of requirement is most appropriate 3

TDT 4175 - Information Systems, Spring 2006 Summary of last week (cont. ) n Goal-design scale (example: project support system) l l Domain-level req: ”…support cost recording and quotation with experience data” l Product-level req: ”…recording and retrieval functions for experience data” l n Goal-level req: ”…precalculations accurate to within 5%” Design-level req: ”…screen pictures as shown in app. XX” Requirements approaches (focus: functional requirements) l l Fast approach: domain-level requirements l n Traditional approach: product-level requirements Two-step approach: domain-level + design-level Choice depends on project type 4

TDT 4175 - Information Systems, Spring 2006 Project types and approaches Project models n Adapted from (Lauesen, 2002): Project type Trad Fast Twostep OK OK In-house development OK = good ? = dubious = not good * = variable price ? Product development ? Time and materials ? OK Acquire COTS business appl. ? OK Acquire COTS tech. tool OK OK OK Tender (with COTS) ? OK Tender (custom-build) ? OK* Contract (with COTS) ? OK Contract (custom-build) ? OK* Sub-contract OK Maintenance OK 5 OK*

TDT 4175 - Information Systems, Spring 2006 Overview of elicitation techniques n Asking questions l l n Interviews Questionnaires Observation l l n Unobtrusive / dialogue / participating Task demonstration Formal group sessions l Brainstorming l Focus group / workshops n Document studies n Modelling, simulation etc. n Prototyping, storyboarding and similar l l n Paper or code COTS acquisition: pilot experiments, demo versions Agile methods, e. g. XP 6

TDT 4175 - Information Systems, Spring 2006 Additional tasks n Not directly elicitation l n But may be necessary to get elicitation done Preparation l Stakeholder identification l Teambuilding n Negotiation / conflict resolution n Risk analysis n Completeness checking techniques l Goal-requirements tracing l Requirement taxonomies 7

TDT 4175 - Information Systems, Spring 2006 Challenges for elicitation n Stakeholders unable to express their needs l Selective memory (exaggerate recent problems) l Symptoms, not requirements n Difficult to explain tasks and motivations n Tendency to suggest solutions, not demands n Lack of imagination l New ways of doing things, consequences n Too many requirements! (some just nice-to-have) n Demands change over time n Conflicts among stakeholders n General resistance to change l Fear of losing job or losing power l Stress from needing to learn new technology 8

TDT 4175 - Information Systems, Spring 2006 When to use different techniques? n Depends on type of project, e. g. l COTS development: no customer to interview u l n 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. , l l Interviews for explicit knowledge, current situation l n Observation good for tacit knowledge, current situation Workshops for future situation Other indicators (and counter-indicators) l Situations where a technique is particularly useful u (or should not be used) 9

TDT 4175 - 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 10

TDT 4175 - Information Systems, Spring 2006 List of techniques for table previous slide S = Stakeholder analysis P = Prototyping I = Interview p = Pilot experiment O = Observation c = similar Companies T = Task demo A = Ask suppliers D = Document analysis N = negotiation Q = Questionnaires R = risk analysis B = Brainstorm C = Cost/benefit F = Focus groups G = Goal-domain analysis W = Domain workshop d = domain-requirement analysis w = Design workshop 11

TDT 4175 - Information Systems, Spring 2006 Techniques, indicators (Davis, 2003) n + positive sides, ? challenges, - don’t use when n Group sessions: strongly recommended l l n + all project types, many stakeholders, creativity ? dominant persons, conflicts Interview: often used l l n + find new info, background knowledge, conflicts ? Misunderstandings, tacit knowledge Observation: l + low burden on users, existing system, politics l + tacit knowledge 12

TDT 4175 - Information Systems, Spring 2006 Techniques, indicators (cont. ) n Models: strongly recommended l l n +: support communication, organize info, discover missing info ? Directly w/stakeholders or background activity Requirements taxonomies l l n +: Ensure that all types of requirements are included ? : do not directly find requirements, must combine w/ other technique Issues list l n +: avoid digressions w/other techniques, remember Conflict resolution: l The more important the bigger the project 13

TDT 4175 - Information Systems, Spring 2006 Techniques, indicators (cont. ) n Less preferred techniques: l Analyse existing system u l Prototyping (as elicitation technique) u l ? : too bound, overlook other possibilities -: ”don’t use rapid prototyping unless you really believe it’ll be rapid!” Questionnaires u u l +: concrete problems, market studies, external customers ? : limited information content XP u u l +: problem domain is quickly changing ? : heavy burden on customer, project type limitations Formal specifications u ? : Hard to understand for stakeholders 14

TDT 4175 - Information Systems, Spring 2006 Interviews, strategy n Often used elicitation technique n But not always the best n Must fit into a bigger knowledge search strategy l n Cf Figure 19. 1 Top-down approach, Fig 19. 2 l Start with management u u n Goals, key performance indicators u l Overall view of the system Access to people on lower levels Looking at detailed operations Build models while interviewing 15

TDT 4175 - Information Systems, Spring 2006 Interview planning n Who should be interviewed? l E. g. , use organizational chart n Sequence of interviews n Interview plan for each stakeholder l Normally need more interviews person l One interview max 45 -60 minutes 16

TDT 4175 - Information Systems, Spring 2006 Types of questions n Planned or improvised n Open questions l l n Establish viewpoints Generally expecting long answers Closed questions l n Requires a direct (and shorter) answer Probes l Follow-up questions for a previous answer 17

TDT 4175 - Information Systems, Spring 2006 Interview quality (Kvale, 1996) n 6 quality criteria (Kvale, 1996) l l Short questions, long answers l The interviewer follows up and clarifies relevant aspects of the answers l The degree of interactive interpretation l The interviewer attempts to verify her/his interpretations of the subjects answers l n The extent of rich, specific and relevant answers The interview is self-communicating Becoming a good interviewer mainly requires training 18

TDT 4175 - Information Systems, Spring 2006 Qualification criteria (Kvale, 1996) n A good interviewer must be l Knowledgeable (but not boasting) l Structuring (introduce purpose and procedure) l Clear (easy questions, distinct speech) l Gentle (easy-going, tolerant) l Sensitive (hears nuances & emotions) l Open (to new aspects & priorities) l Steering (interrupting digressions) l Critical (not take everything at face value) l Remembering (relate current statement with previous) l Interpreting (give feedback to confirm understanding) 19

TDT 4175 - Information Systems, Spring 2006 Guidelines for performing the interview n Structure guidelines l n Content guidelines l n What issues to pursue? What questions to ask? Style guidelines l n What different parts does the interview consist of? How to phrase these questions? Social guidelines l How to encourage the respondent to talk freely, and maintain a good interpersonal relationship? 20

TDT 4175 - Information Systems, Spring 2006 Structure guidelines n A macro-structure is shown in Fig 19. 3 l n Below are some additional guidelines Prepare a list of questions in advance l l Leave space below questions (for emerging topics) l n Leave space between questions (for answers) Don’t be too bound by this list Micro-structure (within body of interview): l n Ask, listen, feed back your understanding Thank the respondent for her / his time! 21

TDT 4175 - Information Systems, Spring 2006 Content guidelines n Give the respondent a starting-point for talking l n specific context rather than ”work in general” Initially, broad questions l l n Day-to-day work and problems What the stakeholder does, information used, … Focus on critical tasks l l n When is the stakeholder under stress? When is it important that something is 100% correct? Find out why (activities performed / info needed) l l n Relate stakeholder’s work to business objectives Elicit critical success factors Show the respodents how they can benefit 22

TDT 4175 - Information Systems, Spring 2006 Content guidelines (cont. ) n Follow-up questions, typical patterns l Adding questions about where, what, when, who (did something), for whom (something is done), how, why u l choose the 1 -3 most relevant Pursuing the relationship between activities, information, decisions, problems, and critical success factors (CSF’s) u E. g. , if the user mentioned an activity: u u What decisions take place in this activity? u What problems have you had performing this activity? u u What info do you need in this activity? What CSF’s apply to this activity? (and similarly, if info, CSF, decision, … is mentioned first) 23

TDT 4175 - Information Systems, Spring 2006 Style guidelines n Keep questions brief and clear n Avoid leading questions l n Use the stakeholder’s terminology l n Avoid translation, avoid advanced ICT terminology Choose the right mix of open & closed questions l n . . and premature suggestions for solutions Cf textbook, pp 463 -465 Use diagrams where appropriate l But simple, informal syntax l Draw interactively, and/or l …encourage user to contribute / change the model 24

TDT 4175 - Information Systems, Spring 2006 Social guidelines n Clarify your mandate and purpose n Appear as competent l Be cautious with humour / irony n Be polite, yet at ease n Be sympathetic to users’ problems l n Show interest and respect l n But cautious about down-talking current system! Body language, cues, nodding, etc. Be sensitive to different personality types l E. g. , generally shy, ”ICT-shy”, talkative, intellectualizing, manipulative l ”Why” is a dangerous word with some respondents u Rather use ”when? ” 25

TDT 4175 - Information Systems, Spring 2006 Special info about the interview exercise n Done with group pairs l l n Tuesday (17 -19): Group A is customer, B interviews Thursday (12 -14): opposite Each interview: 25 minutes l l n The rest of the customer group observes The rest of the consultant group is not present Read instructions and make preparations in advance, bring l Pencil and paper u Preferrably with some planned questions u Customer group: evaluation forms l Watch (to keep the time) l Recording equipment u n not compulsory, but strongly recommended Write up the interview results as soon as possible after the interview l i. e. , before you forget the details 26

TDT 4175 - Information Systems, Spring 2006 The requirements workshop n Structured group session to identify requirements n In industry: may last 2 -5 days n Often better than interviews for finding requirements l Gather all the important stakeholders at once l Avoid several interviews finding overlapping requirements l Opportunities for immediate conflict resolution, prioritization, etc. l Fosters creativity 27

TDT 4175 - Information Systems, Spring 2006 Requirements workshop: roles n Facilitator l n Scribe l n A requirements engineer Also a requirements engineer Participants l User and customer representatives l Domain experts l Possibly: Designers, testers 28

TDT 4175 - 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 29

TDT 4175 - Information Systems, Spring 2006 How to run a workshop (2) Alexander (2002) suggests (after planning): n First morning: l l Teach about organizing req. spec. l Let participants define structure & responsibilities l Split group in several interests, fill structure in parallel l Teach about review, perform reviews l n Define various user groups Update material based on reviews Then, repeat until exhaustion: l l n Backroom clean-up Distribute, review, redraft After workshop: l Clean up requirements l Send out draft for further comments 30

TDT 4175 - Information Systems, Spring 2006 References n Søren Lauesen: ”Software Requirements: Styles and Techniques”, Addison-Wesley, 2002 n Ann Hickey and Alan M. Davis: ”Elicitation technique selection: How do experts do it? ”, Proc. RE’ 03 n Steinar Kvale: ”Interviews: An introduction to qualitative research interviewing”, Sage, 1996 n Ian F. Alexander and Richard Stevens: ”Writing Better Requirements”, Addison-Wesley, 2002 n Suzanne and James Robertson: ”Mastering the Requirements Process”, Addison-Wesley, 1999 31