Requirements Elicitation Challenges PDF

The Challenge of Requirements Elicitation 1 Key Points Requirements elicitation is complicated by three endemic syndromes The “Yes, But” syndrome stems from human nature and the users’ inability to experience the software as they might a physical device...

The Challenge of Requirements Elicitation 1 Key Points Requirements elicitation is complicated by three endemic syndromes The “Yes, But” syndrome stems from human nature and the users’ inability to experience the software as they might a physical device Searching for requirements is like searching for “Undiscovered Ruins”; the more you find, the more you know remain The “User and the Developer” syndrome reflects the profound differences between these two, making communication difficult 2 Requirements Elicitation Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development. 3 Requirements Elicitation Requires collaboration of people with different backgrounds  Users with application domain knowledge  Developer with solution domain knowledge Bridging the gap between user and developer  Scenarios: Example of the use of the system in terms of a series of interactions between the user and the system  Use Cases: Abstraction that describes a class of scenarios 4 Requirements Process Requirements Elicitation  Definition of system in terms understood by customer (Problem Description) Requirements Analysis  Technical specification of the system in terms understood by developer (Problem Specification) 5 Requirements Engineering RReeqquire uiremmeenntstsEEngnginineeeering ring RReeqquuireiremmeents RReeqquuirem iremeenntstsAAnnaalysis lysis ntsEElicita licitation tion RReeqquire uiremmenentstsSp Speecifica cification tion RReeqquire uiremmenentstsVe Verifica rification tion RReeququirem iremeents ntsMMaannagageemmeentnt Why is requirements engineering difficult? Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. System stakeholders do not have clear ideas about the system support that they need. Requirements are often influenced by political and organizational factors that stakeholders will not admit to publicly. 7 Requirements change System requirements reflect the world outside of the system. As this is constantly changing then the requirements will certainly also change.  Technology changes  Organizational changes  Market changes  Economic changes  Political and legal changes 8 Barriers to Requirements Elicitation The "Yes, But" Syndrome The "Undiscovered Ruins" Syndrome The "User and the Developer" Syndrome 9 The "Yes, But" Syndrome For whatever reason, we always see two immediate, distinct, and separate reactions when the users see the system implementation for the first time. 1. "Wow, this is so cool; we can really use this, what a neat job" and so on. 2. "Yes, but, hmmmm, now that I see it, what about this... ? Wouldn't it be nice if... ? Whatever happened to... ?“ 10  Barriers to Elicitation – “Yes, But” Syndrome Users reactions are simply human nature, they haven’t seen your system before and didn’t understand what you described earlier. This is an integral part of application development and we should plan for it. Therefore, we need to employ techniques that get the “yes, buts” out early. 11 The “Yes, But” Syndrome Anticipate that there will be “yes, buts” and add time and resources to plan for feedback. Unlike mechanical devices software doesn’t become “real” to the users until it is finished. Get the “Buts” out early, elicit the “Yes, But” response early, and then invest majority of development efforts in software that has already passed this test. 12 The "Undiscovered Ruins" Syndrome Indeed, software development teams everywhere continually struggle to determine when they are done with requirements elicitation, that is, when have they found all the requirements that are material or when have they found at least enough? Unknown unknowns First scope the requirements elicitation effort by defining the problem or problems that are to be solved with the system. Employ techniques that help find some of those ruins and have the stakeholders buy-into the requirements. 13 The “Undiscovered Ruins” Syndrome How do you find requirements that no one has thought of? The more you find, the more you know exist. Nonuser stakeholders are often holders of otherwise undiscovered requirements Making sure to talk to all stakeholders is one way to address this. 14 The “User and Developer” Syndrome Communication gap between the user and the developer. Users and developers usually come from different worlds and speak different languages and have different backgrounds, motivations, and objectives. Few developers have had any training in elicitation techniques 15  The User and Developer Syndrome Reasons for this problem and some suggested solutions. Problem Solution Users do not know what they want, or they Recognize and appreciate the user as know what they want but cannot articulate domain expert; try alternative communication it. and elicitation techniques. Users think they know what they want until Provide alternative elicitation techniques developers give them what they said they earlier; storyboarding, role playing, wanted. throwaway prototypes, etc. Analysts think they understand user Put the analyst in the user’s place. Try role problems better than users do. playing for an hour or a day. Everybody believes everybody else is Yes, its part of human nature, so let’s get on politically motivated. with the program. 16 Key Points Requirements elicitation is complicated by three endemic syndromes The “Yes, But” syndrome stems from human nature and the users’ inability to experience the software as they might a physical device Searching for requirements is like searching for “Undiscovered Ruins”; the more you find, the more you know remain The “User and the Developer” syndrome reflects the profound differences between these two, making communication difficult 17 What is coming next!! 1) Requirements Elicitation Techniques a. Interviewing. b. Requirements Workshops. c. Brainstorming and Idea Reduction. d. Storyboarding. 2) The Features of a Product or System 18 The Features of a Product or System 19 Key Points The development team must play a more active role in eliciting the requirements for the system Product or system features are high-level expressions of desired system behavior System features should be limited to 25-99, with fewer than 50 preferred Attributes provide additional information about a feature 20 Stakeholder and User Needs Definition: a reflection of the business, personal, or operational problem (or opportunity) that must be addressed in order to justify consideration, purchase, or use of a new system Examples:  I need easier ways to understand the status of my inventory  I’d like to see a big increase in the productivity of sales order entry 21 Problem Domain & Solution Domain Needs – in user terms Problem Domain Features – a service provided by the system that fulfills a need Software requirements – more specific Solution Domain 22 Features Definition: a service the system provides to fulfill one or more stakeholder needs Sometimes in talking to users, they will discuss features not needs and can be hard to distinguish between them Features are a convenient way to describe the functionality without getting bogged down in detail Features are at a high level of abstraction 23 Examples of Features Application Domain Example of a Feature Elevator control system Manual control of doors during fire emergency Inventory control system Provide up-to-date status of all inventoried items Defect tracking system Provide trend data to assess product quality Payroll system Report deductions-to-date by category Home lighting automation Vacation settings for extended away system (HOLIS) periods Weapon control system Minimum of two independent confirmations of attack authorization required Shrink-wrap applications Windows XP compatibility 24 Managing Complexity Limit features to somewhere between 25-99 to avoid getting in the details Add attributes to the features to track additional information Example attributes:  Name or Unique identifier  Sponsor  History data  Allocated from  Traced to  Priority 25 Key Points The development team must play a more active role in eliciting the requirements for the system Product or system features are high-level expressions of desired system behavior System features should be limited to 25-99, with fewer than 50 preferred Attributes provide additional information about a feature 26 Interviewing 27 Key Points Interviewing is a simple and direct technique that can be used in most circumstances Context-free questions can help achieve bias-free interviews It may be appropriate to search for undiscovered requirements by exploring solutions Convergence on some common needs will initiate a “requirements repository” for use during the project A questionnaire is no substitute for an interview 28 Interviewing A simple, direct technique that can be used in virtually every situation Goal – make sure that the biases and predisposition of the interviewer do not interfere with the free exchange of information Sociology teaches us that it is extremely difficult to truly understand others because we each of us is biased by our own conceptual filter 29 Interviewing Steps – Part 1 Determine who to interview Establish objectives for the interview  Particular area(s) of focus, specific facts required  Ideas, suggestions to be gained Prepare for the interview  Question & topic list sent to interviewee days in advance  Collect relevant documents before the meeting 30 Interviewing Steps – Part 2 Conduct the interview  Introductions; Summarize objectives  Open-ended, context-free questions  Closed-ended, specific questions Summarize next steps Document the interview Evaluate the interview 31 Questions Context-Free Questions  Questions asking about the nature of the problem without context  Context-free questions force us to listen before attempting to invent or describe a potential solution  Helps us learn about the user  Examples Who is the user? Who is the customer? Are their needs different? Where else can a solution to this problem be found? Solutions-Context Questions  After context-free questions, then move to exploring the solution Template on page 104 of text 32 The Interview Tips for a successful interview  Prepare an appropriate context-free interview  If appropriate, prepare solution-context questions  Before the interview, research the background of the stakeholder, try to eliminate questions  Record the answers  Refer to the template to be sure you covered all the material  Allow the stakeholder to go off course, you may gain additional information  End interview with a summary key user needs discovered Record the top needs after each interview and record how many stakeholders mentioned that need Never do a questionnaire – too impersonal 33 Context-Free Questions – Part 1 Lead to a basic understanding of the problem  Who is behind the request for this work?  Who will use the solution?  What will be the economic benefit of a successful solution?  Is there another source for the solution that you need?  How does {a particular business process} work now? Focus on the effectiveness of the interview meeting  Are you the right person to answer these questions?  Are your answers “official”?  Are my questions relevant to the problem that you have?  Is there anyone else who can provide additional information?  Is there anything else that I should be asking you? 34 Context-Free Questions – Part 2 Gain a better understanding of the problem and the customer’s perspective about a solution  How would you characterize “good” output that would be generated by a successful solution?  What problem(s) will this solution address?  Can you show me or describe to me the environment in which the solution will be used?  Are there special performance issues or constraints that will affect the way the solution is approached? 35 Closed-Ended Questions Specific questions that limit or restrict a response  How many PC’s are there in this department?  Are most problems due to inadequate documentation or poorly trained users?  How quickly do you expect this screen to appear, within a 3 second range? 36 Effective interviewers Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. Prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’. Do it as a team, with prescribed Roles.  Questioner  Follow Question Generator  Note Taker (possibly Record if okay with customer) Recommend Changing Roles during interview. 37 37 Interviewing Continued... Give yourself enough time for the interview and plan for breaks. Role play if the user’s explanation is unclear.  Users cannot articulate the procedures they follow  The management says one thing, operational reality is completely different.  Impossible for you to ask every possible question and for any user to know questions the developer should be asking.  Enter data for an hour using their current system.  Discomfort factor with large groups. Draw simple diagrams or decision trees. Complex diagrams will turn off key non-technical users. Send a summary as soon as possible to the interviewees. 38 Interviewing – Continued Give yourself enough time for the interview and plan for breaks. Role play if the user’s explanation is unclear.  Users cannot articulate the procedures they follow  The management says one thing, operational reality is completely different.  Impossible for you to ask every possible question and for any user to know questions the developer should be asking.  Enter data for an hour using their current system.  Discomfort factor with large groups. Draw simple diagrams or decision trees. Complex diagrams will turn off key non-technical users. Send a summary as soon as possible to the interviewees. 39 HOLIS Case Study 15 interviews identified about 20 needs Homeowner’s perspective  Flexible and modifiable lighting control for entire house  “Futureproof” (As technology changes, I’d like compatibility with new technologies that might emerge.”)  Attractive, unobtrusive, ergonomic  Fully independent and programmable or reconfigurable switches for each room in the house  Additional security and peace of mind  Intuitive operations  A reasonable system cost, with low switch costs  Easy and inexpensive to fix  Flexible switch configuration (from 1 to 7 button per switch  Out of sight, out of mind  100% reliability 40 HOLIS Case Study Homeowner’s perspective (cont.)  Vacation security settings  Ability to create scenes, such as special housewide lighting settings for a party  No increase in electrical or fire hazards in the home  Ability, after a power failure, to restore the lights the way they were  Programmable by the homeowner, using an existing PC  Dimmers whereever the homeowner wants them  Programmable by the homeowner, without using a PC  Programmable by somebody else, so the homeowner doesn’t have to do it  Ability to turn on some lights maually if the systems fails  Interfaces to the home security system  Interfaces to other home automation (HVAC, audio/video, etc.) 41 HOLIS Case Study Distributor’s perspective  A competitive product offering  Some strong product differentiation  An easy way to train salespeople  Ability to demonstrate the system in the shop  High gross margins 42 Key Points Interviewing is a simple and direct technique that can be used in most circumstances Context-free questions can help achieve bias-free interviews It may be appropriate to search for undiscovered requirements by exploring solutions Convergence on some common needs will initiate a “requirements repository” for use during the project A questionnaire is no substitute for an interview 43