Week 3 - Requirements Elicitation

Structured Interview

where the interviewer has a *pre-defined set of questions* and is looking for answers.

Unstructured Interview

where, without any pre-defined questions, the interviewer and the interviewee *discuss topics of interest* in an open-ended way.

Advantages of Prototypes

+ A prototype allows for *early user interaction and feedback*. + can be an inexpensive means to quickly *uncover and confirm a variety of requirements.* + Supports users who are more comfortable and effective at articulating their needs by using pictures, as prototyping lets them *"see" the future system's interface.* + Provides a vehicle for designers and developers to learn about the users' interface needs and to evolve system requirements.

Advantages of Interviews

+ Allows the interviewer and participant to have *full discussions and explanations* of the questions and answers. + Personal contact allows responsiveness and adapting to what the user says. + Analyst can probe in *greater depth* than any other methods of elicitation + Allows interviewees to *express opinions in private* that they may be reluctant to express in public.

Advantages of Surveys

+ An *economical* and *quick* method of gathering data from a *large sample* + Can *reach many people with low resource* + Used for answering specific questions. + Can be *administered remotely* + Depending on how well it is designed, the results can be analysed easily by software applications. + Effective and efficient when stakeholders are not located in one location.

Advantages of Observation

+ Provides *first hand experience* of the way the current system works + Data is collected in *real time* and can have a high level of validity + Can be used to *verify information* from other sources or to look for exceptions + Baseline data about the performance of the existing system and of users can be collected

Advantages of Workshops

+ Workshop sessions are very successful in *reducing project development efforts and shortening the schedule.* + Used to *generate ideas* for new features or products. + To *reach consensus* on a topic or conflicting views. + Is able to gauge reaction to stimulus material (e.g. storyboards, screenshots). + A requirements workshop provides a *means for stakeholders to collaborate*, make decisions and *gain a mutual understanding of requirements*.

Surveys/Questionnaires

- A document containing a number of standard questions that can be sent to individuals to obtain information from a *large number of people* or when the people are geographically dispersed. - So, you could send these list of questions to your stakeholders asking them about the new system or the changes to the existing system - Can collect both quantitative and qualitative data. - They are also appropriate for systems that will be used by the general public and where the analyst has to investigate all the types of users of the system.

Prototype

- A prototype is an *initial working model* of a larger, more complex entity, usually a program with limited functionality that is built to test out some aspect of *how the final system will work (and look like)* and then present it to the stakeholders. - Prototypes may be constructed with various objectives in mind: -- To investigate user requirements -- To test specific concept or verify an approach -- To focus on human-computer interface --- Investigate input and output and its form --- Investigate most suitable interface

Storyboard/Wireframes (UI flos)

- A series of drawings used mostly for *identifying user interfaces*; screens that the software will display are drawn. - User interface-flow diagrams (Storyboards/Wireframes) offer a high-level view of the interface of a system, you can quickly gain an understanding of *how the system is expected to work*. It puts you in a position where you can *validate the overall flow* of your application's user interface. For example, does the flow make sense? - User interface-flow diagrams are typically used for one of the two purposes. First, they are used to *model the interactions* that users have with your software, as defined in a single use case. Second, they enable you to gain a *high-level overview of the user interface* for your application.

Workshop (Focus Groups)

- A technique used to expedite requirements elicitation, also referred to as "Joint Application Development" or "focused groups". - The objective is to compress all of the activities involved in other fact finding techniques into a shorter series of workshop sessions with users and project team members. - These sessions are usually conducted in special rooms with supporting facilities: overhead projector, a white board, flip charts, adequate workspace for the participants.

Workshop Fundamentals

- A workshop may be used to *scope, discover, define, refine, update, prioritize* and reach closure on *requirements* for the target system. - A workshop may be used to *generate ideas for new features or products*, to reach consensus on a topic or conflicting views, or to review requirements. - Organised process: uses techniques such as brain storming, top down analysis, etc. - Documented approach: output of each session is documented in such a way to make it easy to read and understand and agree upon.

Interview

- An interview is a systematic approach designed to *elicit information from a person or group of people* in an informal or formal setting by talking to an interviewee, asking relevant questions and documenting the responses. - In an interview, the interviewer formally or informally *directs questions to a stakeholder* in order to obtain answers that will be used to create formal requirements. - *One-on-one interviews* are typically most common. - In a *group interview* (with more than one interviewee in attendance) the interviewer must be careful to elicit responses from all attendees - The most widely used elicitation and fact finding technique and requires the most skill and sensitivity. - Conducting an interview requires good planning, good interpersonal skills and an alert and responsive frame of mind. - One of the key goals of interviewing is to ensure that the biases and predispositions of the interviewer do not interfere with a free exchange of information. - Used to explore issues and can collect some quantitative, but mostly qualitative data.

Other elicitation techniques

- Apprenticing or Role Playing - Knowledge Acquisition techniques: -- protocol analysis and -- card sorting - Laddering - Document Analysis (analysing documents such as business plan, project charter, contracts, statement of work, emails, memos, etc) - Ethnography and Ethnomethodology - Goal Based Approaches - Scenarios - Viewpoints - Mixed techniques

Checklist (During the interview)

- Arrive on time and take responsibility for the agenda - Stick to the planned timetable, do not over-run - If you plan to tape the interview, ask the interviewees permission but take notes as well. - Probe for details by using different types of questions - Take thorough notes - Identify and document unanswered items or open questions

Guidelines for observation

- Ask enough questions to ensure that you have a complete understanding of the present system. - Document any procedures for handling exceptions - Consider each user who works with the system -- What information does that person receive from other people? -- What information does this person generate? -- How is this information communicated? -- How often do interruptions occur? -- How much down time occurs? -- How much support does the user require and who provides it?

Disadvantages of Interviews

- Can be *time consuming and costly* - Requires considerable commitment and involvement of the participants. - Interview *results have to be transcribed* and written and transcription and analysis of interview data can be complex and expensive. - Can be *subject to bias* - If conflicting information is given, it can be difficult to resolve and interviews are *not an ideal means of reaching consensus* across a group of stakeholders. - There is a risk of unintentionally leading the interviewee.

Interview guidelines

- Plan and organize - Start with high level general questions - Ask specific questions - Seek lead for more information from stakeholders - Keep it to 1-2 hours - Take and share meeting notes and minutes - Record following up and action items - Focus on "Project" and not the people - Ask, listen, probe, understand and record (ALPUR) - Avoid blaming, jargons, forcing your opinion

Disadvantages of Observation

- Could be very *time consuming* - Need to analyse *huge amounts of data* - Most people do not like to be observed and *may be disruptive* to the person being observed. - Requires trained and skilled observer to be most effective. - There may be *ethical problems* if the person being observed deals with sensitive private or personal data or directly with members of public. - There may be logistical problems if the staff being observed work shifts. - Unusual exceptions and critical situations that happen infrequently may not occur during the observation.

Disadvantages of Prototypes

- Depending on the complexity of the target system, using prototyping to elicit requirements can take *considerable time.* - A prototype may lead users to develop *unrealistic expectations* regarding the delivered system's performance, completion date, reliability and usability characteristics. This is because an elaborated, detailed prototype can look a lot like a functional system

Steps in an interview

- Determine the people/stakeholders to interview - Establish the objectives of the interview - Develop interview questions (topics of interview) - Prepare for the interview - Conduct the interview - Document the interview - Evaluate the interview

Disadvantages of Surveys

- Effective questionnaires are *hard to design* (e.g. leading questions, misinterpretation of questions). - Questions are usually *not answered completely* - The *response rates* for surveys *are often too low* for statistical significance. - There is no *automatic way of follow up* unless you do interviews later.

Open questions

- Encourage spontaneous and unstructured responses. - General questions establishing a viewpoint - Question that requires a full answer - Open-ended questions begin with the following words: why, how, what, describe, tell me about..., or what do you think about... - Examples of open-ended questions are: -- "What happened after I left?" -- "Why did Jim leave before Susan?" -- "Tell me about your day at work." -- "What do you think about the new season of this TV show?" -- "Is there anything else I should be asking you?" (Your last question of the interview)

Probes

- Follow up from a previous answer - "Why do you..." - "Where do you..." - "How often do you..."

Interview questions

- General -- What do you think of ... - Specific -- How many ... -- What do you do with... - Probes -- Why do you... - Most interviews use a combination of all three question types. The approach you take will depend on the type of interviewee

Present vs Future system

- Get a clear understanding of -- The overall objectives of the enterprise -- What do individual users of the system want to achieve in their job - Understand -- How the business is operating at present -- How people are working right now and what they cannot do with the existing system -- The problems with and inadequacies of the current system - Hence, discover the "new requirements" Many aspects of the current system will need to be carried forward into the new system, so it is important that information about what people are doing is gathered and documented. These are the requirements that are derived from the "current system". The motivation for the development of a new information system is usually problems with and inadequacies of the current system. So it is also essential to capture what it is that the users require of the new system that they cannot do with their existing system. These are "new requirements"

Workshop (requirements)

- Goal and Agenda -- Elicitation, Review, Sign Off workshops - Who...10-15 people max. - Location and time - Facilitator - Subscriber - Tools - Food - Ice breaker - Follow-up

Observation

- In this approach, the analyst *observes* the actual execution of *existing processes* by the users (study a stakeholder's work environment), usually without direct interference. - Seeing the environment and domain where the system will be situated in action gives additional perspectives and a better understanding of system functionalities. - Observe system *as it actually behaves*. - Observation also allows us to *verify statements* made in interviews and surveys to determine whether the procedures within the domain really operate as they were described. - Through observation you might discover that neither the system documentation nor the interview statements are accurate. - Direct gathering of information rather than through description. - Be aware that individual behaviour maybe altered because they know they are being studied. - Avoid disturbing users from their normal activities. - Two types of Observations: -- Passive: You don't ask questions, simply observe and make notes. -- Active: You observe and have a dialog with the users/stakeholders while they are performing their work.

Elicitation requirements (Techniques)

- Interview - Questionnaires/Survey - Observation - Prototyping - Requirements Workshop

Investigate the current system

- Is the existing system a manual one, based on paper documents, forms and files? - Is it already computerised? (a legacy system?) - Is it a combination of manual & computerised? - If it has evolved over the years, what sections are still usable and what sections do not meet the needs of users? - Answering these questions leads to defining the boundary of the new system and its interface to the existing system

Situation for observation

- It can *verify or disprove assertions* made by interviewees/stakeholders. - It is *useful in situations where different interviewees have provided conflicting information* about the way existing system works. - Observation is essential for gathering some quantitative and mostly qualitative data about people's jobs

Interview (DONTS)

- Never show aggression nor create an impression of apportioning blame. -- "I've been told there are some major issues in this area and it's my job to fix them" -- "Conducting a study to identify how we can provide you with better support for your work..." - Do not force solutions on users- play role of an advisor and facilitator - Explain limitations of the system in user terms - Describe how system will help users in their work - Do not ask leading questions, ask for suggestions for improvement and follow them up -- Not many yes no questions - they are usually leading questions

Workshop Guidelines

- Participants must be selected carefully representing different classes of stakeholders. - Ensure that all stakeholders participate and have their input heard. - Must have a skilled facilitator (you as a BA). - You should remain neutral and promote discussion. - Meeting room should have all the necessary facilities and the environment be conducive to hold effective meetings - Need visual aids (e.g. flip charts, whiteboard, large screens, GUI)

Closed questions

- Question that can be answered by single word (yes or no) or a short phrase. - They are used to obtain facts and specific pieces of information. - Limit or restrict the response requiring specific answer such as a number, explanation of a report, reason for an action" - Examples of closed-ended questions are: -- "Who will you choose?" -- "What brand of car do you own?" -- "Did you speak to Bob?" -- "Did Susan leave with Jim?"

Disadvantages of Workshops

- Risk involved in speeding up the decisions. Sometimes the decisions made about the requirements are not optimal. - May suffer from *dominance and submission.* - At times, details are inappropriately defined or missed altogether.

Checklist (After the interview)

- Thank interviewees for their time. Offer to provide them with a copy of your notes for them to validate. Make an appointment for further interviews if needed. - Review and transcribe your tapes or notes ASAP after the interview while the content is still fresh in your mind. - Review your notes for accuracy, completeness, consistency and understanding. - Transfer information to appropriate models and documents. - Identify areas needing further clarification. - Send interviewees your notes and update your notes to reflect their comments.

Elicitation Process

- Understanding the application domain & the properties of the existing system - Identifying the sources of requirements - Identifying and analyzing all the relevant stakeholders (we did this last week) - Selecting the approaches, techniques and tools for elicitation - Eliciting the requirements from the stakeholders and other sources using the selected techniques, approaches and tools

Types of questions (Surveys/Questionnaires)

- Yes/No questions: e.g. "Do you print reports from existing system?" Yes No (please circle one) - Multiple Choice questions: e.g. How many clients do you obtain in a year? a) 1-10 b) 11-20 c) 21-30 d) 31 + - Scaled Questions: e.g. How satisfied are you with the response time of the stock update? (please circle one option) 1. Very satisfied 2. Satisfied 3. Dissatisfied - Open-ended questions e.g. What additional reports would you require from the system?

Checklist (Before the interview)

-- Establish the objective for the interview -- Determine relevant users to be involved -- Determine project team members to participate -- Build a list of questions and issues to be discussed -- Review related documents and materials -- Set the time and location -- Inform all participants of objective, time and location