requirements elicitation.ppt

ECRequirements ElicitationOriginally developed by Michael Madigan, StorageTek Manager, PAL Engineering For ECEN4033/5033 Software Engineering of Standalone Programs University of Colorado, BoulderRequirements Engineering Requirements ElicitationnStandish Group listed “Lack of User Input” as most common factor of challenged projects.nRequirements 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.1nDevelopment teams have to take the initiative.2Challenges of Requirements Elicitation2nThe “Yes, But” syndrome stems from human nature and the users inability to experience the software as they might a physical device.nThe Undiscovered Ruins, the more you find, the more you realize still remainn“User and Developer” syndrome reflects the profound differences between the two, making communication difficult.n“The sins of your predecessors” syndrome where marketing (user) and developers do not trust each other based on previous interactions, so marketing wants everything and developers commit to nothing.The “Yes, But” SyndromenFirst time users see the system the first reaction is either, “wow this is so cool” or “Yes, but, hmmmmm, now that I see it, what about this…? Wouldn’t it be nice …?nUsers reaction is simply human naturenNeed to employ techniques that get the “yes, buts” out early.nAnticipate that there will be “yes, buts” and add time and resources to plan for feedback.nTends to be User Interface centric, these tend to be the touch points of the system by the users.The “Undiscovered Ruins” SyndromenTeams struggle with determining when they are done with requirements elicitation.–Is done when all the requirements are elicited or have they found at least enough?–Like asking an archeologist “how many undiscovered ruins are there?”nFirst scope the requirements elicitation effort by defining the problem or problems that are to be solved with the system. nEmploy techniques that help find some of those ruins and have the stakeholders buy-into the requirements.The “User and the Developer” SyndromenUsers do not know what they want, or they know what they want but cannot articulate it.nUsers think they know what they want until developers give them what they said they wanted.nAnalysts think they understand user problems better than users do.nEverybody believes everybody else is politically motivated.nRecognize and appreciate the user as domain experts; try different techniques.nProvide alternative elicitation techniques earlier; storyboard, role playing, prototypes, and so on.nPut the analyst in the users place. Try role playing for an hour or a day.nYes, its part of human nature, so lets get on with the program.CharacteristicResponseThe “Living with the Sins of your Predecessors” syndromenLike it or not your users (marketing) and developers remember what happened in the past.–Quality programs that promised things would be different.–The last project where requirements were vague and/or were delivered short of expectations. nThe team “unilaterally” cut important features out of the last release.nNeed to build trust, slowly. Do not over commit to features, schedule, or budget. nBuild success by delivering highest priority features early in the process. ECRequirements Elicitation TechniquesRequirements Elicitation TechniquesnInterviewing and questionnairesnRequirements workshopsnBraining Storming and idea reductionnStoryboardsnUse CasesnRole PlayingnPrototypingTechnique: InterviewingnSimple direct techniquenContext-free questions can help achieve bias-free interviews – See course web site for examplesnThen, it may be appropriate to search for undiscovered requirements by exploring solutions.nConvergence on some common needs will initiate a “requirements repository” for use during the project.nA questionnaire is no substitute for an interview.Interview: Context free questionnGoal is to prevent prejudicing the user’s response to the questions. nExamples:–Who is the user?–Who is the customer?–Are their needs different?–Where else can a solution to this problem be found? nContext-free questions also parallel the questions salespeople are taught to ask as part of a technique called “solutions selling.” nAfter context-free questions are asked, suggested solutions can be explored.Interview: Show timenEstablish Customer or User ProfilenAssessing the ProblemnUnderstanding the User EnvironmentnRecap the UnderstandingnAnalyst’s Inputs on Customer’s ProblemsnAssessing Your Solution (if applicable)Technique: Requirements WorkshopnThe requirements workshop is perhaps the most powerful technique for eliciting requirements.nIt gathers all keykey stakeholders together for a short but intensely focused period.nThe use of an outside facilitator experienced in requirements management can ensure the success of the workshop.nBrainstorming is the most important part。