Interviewing Sriram Mohan

Outline Mistakes to avoid Before the interview Questions Requirements workshop

Most Common Mistake Lack of preparation Bias Interviewing is the simplest and the most direct technique for obtaining requirements. It can be used in almost every situation and it gets us up close and personal with the client. There are some problems however with this method, the developer might inadvertently bias the answers provided by the client. Having done a lot of work in this area, one might think they know what the problem is and start thinking in terms of solution

Context Free Questions Who is the user? Who is the customer? Are their needs different? Where else can a solution to this problem be found? Ask general questions, this helps avoid probing for a solution at once. These are questions to which the answer is not obvious and forces the developer to listen to the user and get away from the habit of looking for solutions without getting the entire context in. Once we are past this phase, we can focus on getting into the context.

Outline Mistakes to avoid Before the interview Questions Requirements workshop

Where Should You Hold an Interview? Non-threatening environment Customer's turf Room large enough for group Free from distractions

Interview Preparation Do some research Prepare questions Prepare agenda Select roles: Leader Note taker Questioners Don’t stop the user when they are trying to answer a question, don’t just follow the script, try and establish a rapport.

Interview Phases Establish user profile Assess the problem Understand the environment Recap for understanding Analyst's inputs Assess solution Assess opportunity Assess reliability, performance Other requirements Wrap-up 1. Establish User Profile - do some research first; determine background of interviewee; find out what will constitute success or failure 2. Assess the Problem - Find out what the problems are; how are problems addressed now? 3. Understand the Environment - find out about the users; find out about the computing environment; how much help will users need? 4. Recap for Understanding - paraphrase what you have heard so far; is anything missing? 5. Analyst's Inputs - ask about problems that you would expect to be present; rank these problems relative to others 6. Assess Solution - “What if…”; “How important would it be to…?” 7. Assess Opportunity - determine the market for the solution, determine the value of the solution 8. Assess Reliability and Performance - Determine nonfunctional needs (e.g. reliability, performance, support) 9. Other Requirements - Any external requirements? Any other requirements not already mentioned? Other legal and regulatory requirements 10. Wrap-up - What should we have asked? How can we follow up?

Outline Mistakes to avoid Before the interview Questions Requirements workshop

1. Establish User Profile Do some research first Determine background of interviewee Find out what will constitute success or failure

Personas - Extra Credit Personas or personae are fictitious characters that are created to represent the different user types within a targeted demographic that might use a site or product. Used in HCI, Will they be useful for us? Why, If yes How? Turn it in using the drop box in Angel (Week 01 – Day 04 – Extra Credit Drop Box).

2. Assess the Problem Find out what the problems are How are problems addressed now? Why does the problem exist? How do you solve it now? How would you like to solve it

3. Understand the Environment Find out about the users Find out about the computing environment How much help will users need? Use this to find information about users, their educational/computer experience, platforms they use, expectations of usability, training time, documentation

4. Recap for Understanding Paraphrase what you have heard so far Is anything missing?

5. Analyst's Inputs Ask about problems that you would expect to be present Rank these problems relative to others For each problem, ask if it is something you should be worried out, why that problem exists, how they would like to solve it, priority – very similar to problem assessment, except these might be based on your experience developing such systems.

6. Assess Solution What if ... How important would it be? Use this to list some features and ask the client to rank importance

7. Assess Opportunity Determine the market for the solution Determine the value of the solution

8. Assess Reliability and Performance Determine nonfunctional needs: reliability performance support Installation, configuration requirements, security requirements, licensing the product, labeling and packaging

9. Other Requirements Any external requirements? Any other requirements not already mentioned? Legal, standards, regulations

10. Wrap-up What should we have asked? How can we follow up? Summarize based on your interview, the clients expectations.

Why Not A Questionnaire Instead?... …After all, they can be done so much more efficiently! But Difficult to follow-up on responses Relevant questions cannot always be designed in advance. Advantages of interviews: Personal Contact Interaction/Follow-ups The way the questions are structured shows an inherent bias, it is difficult to follow up on unclear responses or use the user response to explore new domains. Let’s Plan on an interview session with me as the client.

Outline Mistakes to avoid Before the interview Questions Requirements workshop

Benefits of Requirements Workshop All stakeholders get their say May expose political issues Helps form effective team (developers and stakeholders)

What should you do before? Sell the concept. Prepare Set the stage Choose the facilitator Make sure that people know that you are serious about what you are doing, it is natural that a certain element of “oh, here we go again” may develop.. Prepare for the workshop, take care of the logistics, send some preparation material(make sure you don’t send it too soon, just send it a week before).

Workshop Facilitator Establish proper tone Introduce goals and agenda Keep team on track Facilitate decision making Make sure all voices are heard

Sample One-Day Agenda Introduction 0.5 hours Context 1.5 hours Brainstorming 2.0 hours Lunch 1.0 hours Brainstorming 1.0 hours Feature definition 1.0 hours Idea reduction 1.0 hours Wrap-up 1.0 hours Intro – review agenda, rules Context – present project status, market needs and current status Brainstorm – feature analysis Define each feature Idea pruning Summarize and assign action items and address parking lot items See Table 11-1, page 114 of text for more information. Note that the book forgot mid-morning and mid-afternoon breaks!

Bag of Tricks Manage Time Grandstanding/keeping quiet Negative comments Make sure everybody follows the time, penalty for being late to start of sessions, have a 5 minute position statement, have great idea coupons to help shy people express their opinions, 1 cheap shot.