Software Engineering Project

 Why User involvement?  Requirements Gathering statistics.  Ways of Gathering user requirements.  One-on-One Interviews.  How to Maximize the quality of the data gathered.  Next session. 12/4/20152Sarah A. Alkhudair

 User involvement is invaluable during the requirements-gathering phase of a project: Users' opinions and preferences help shaping the look and flow of an application during the design and coding phases. User training is easier when the application is based on workflow models and scenarios developed with the help of them. In the end, user acceptance helps guarantee the successful adoption of the finished application. 12/4/20153Sarah A. Alkhudair

 In fact, according to some statistics: poor requirements gathering is the cause of about 70% of today's technology project failures. Each badly defined requirement results in: ○ 10 bad design statements ○ which then can multiply out to 100 incorrect coding statements. 12/4/20154Sarah A. Alkhudair

 Surveys (usually for large organizations);  On-site workflow observation;  One-on-one user interviews;  Focus group,  Multiple-user sessions;  Combinations and variations of all of these. 12/4/20155Sarah A. Alkhudair

 The most common technique for gathering requirements is to sit down with the clients and ask them what they need.  The discussion should be planned out ahead of time based on the type of requirements you’re looking for.  There are many good ways to plan the interview, but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements 12/4/20156Sarah A. Alkhudair

12/4/20157Sarah A. Alkhudair

12/4/20158Sarah A. Alkhudair

 By understanding the vision, you'll stand a better chance of hitting the target. 12/4/20159Sarah A. Alkhudair

 An interview is not a conversation; it has structure.  Begin by gathering the strategic information while the contact is fresh and alert in the meeting, and end with the tactical, easy-to- answer questions, such as delivery details.  It must grow out of a set of prepared and insightful questions. Working from a list of questions: ○ allow you to demonstrate progress to the user. ○ let you skip more difficult questions until later in the interview and will help you recap near the end. 12/4/201510Sarah A. Alkhudair

 The interview can be a nerve-racking experience for users, so putting them at ease should be one of your prime concerns. 12/4/201511Sarah A. Alkhudair

 Unlike survey questions, interview questions should be open and structured to encourage examples and scenarios from the user by way of explanation rather than by yes/no answers. 12/4/201512Sarah A. Alkhudair

 put your own ego aside and acknowledge the fact that the clients are the experts on the tasks and processes that make up their jobs.  use their experience and suggestions to design a software application that will make their jobs easier and remove barriers to productivity. You are, in effect, asking them: "How can I make your job easier/safer/less stressful?“ 12/4/201513Sarah A. Alkhudair

 The solution clients say they need is not always the optimum one.  steer the client toward describing "what" they need to accomplish, not "how" they want something built.  analysts need to learn to leave the "how" to the designers and consider their job to be getting to the "what." 12/4/201514Sarah A. Alkhudair

12/4/201515Sarah A. Alkhudair

 To get the complete information you need, question fully and listen carefully for answers. 12/4/201516Sarah A. Alkhudair

 An interview is not an ordinary conversation. Your job is to listen while the person being interviewed speaks.  If you ask a question and there is a period of silence, it probably means the person being interviewed is carefully considering the answer. 12/4/201517Sarah A. Alkhudair

 "X must do Y," plain and simple, 100% of the time, no exceptions.  This helps us capture what's so easy to miss - the exceptions to the rule. 12/4/201518Sarah A. Alkhudair

 Express the user requirements in short, simple sentences with their associated exceptions.  Don't describe multiple requirements in one-sentence paragraphs. (confusion) 12/4/201519Sarah A. Alkhudair

 Don't solve the "problem" before you know WHAT it is. Don't jump to start shaping the solution to the client's needs before you really understand what those needs are.  Don't assume, ask. If you have any doubt about whether you understand something, ask for clarification to check your understanding. 12/4/201520Sarah A. Alkhudair

 As a wrap-up to the interview, verify the answers(Validate the findings) you have recorded and clear up any questions that may have been skipped earlier. "When I asked ____, you answered ___. Did I understand that correctly?"  After this review process, don't forget what is possibly the most important question: "What did I leave out that you would like to add?" 12/4/201521Sarah A. Alkhudair

 Be prepared for your project’s requirements gathering interview.  Start writing your Project Proposal. 12/4/201522Sarah A. Alkhudair