Lecture Requirement engineering Chapter 3 Software elicitation

Lecture Requirement engineering Chapter 3 Software elicitation. This chapter presents the following content What is requirement elicitation? Participants in elicitation, risks of requirements elicitation, requirements elicitation techniques.

What is Requirement Elicitation? Participants in elicitation Risks of requirements elicitation Requirements elicitation techniques The most common causes of poor quality, cost overruns and late delivery of software: Incorrect, incomplete, or misunderstood requirement Requirements elicitation is “the process of discovering the requirements for a system by communicating with customers, system users and others who have a stake in the system development” Gather requirement from various sources: identify requirement providers: stakeholders Analyse the gathered information, looking for implications, inconsistencies or unresolved issues Confirm understanding of the requirements with the users Synthesize appropriate statements of the requirements  Requirement elicitation involves many people  Customer/Client: Person who pays for the software development Ultimately, has the final word on what will be the product  Software engineer: Expert who knows the technology and process -> produce the requirements specifications  The potential users: of the current system or future systems  indicate which functions to maintain or improve  Articulation problems: The user can’t express their needs The users may not aware of their needs or not understand how the technology may be able to help them The user may aware of a need but be afraid of express it Users and developers misunderstand concepts or relationships because they have different meanings for common terms(ex:implementation)  Communication Barriers: Users and developers come from different worlds and have different professional vocabularies The users have different concerns from those of developer (high-level attributes vs low-level technical issues) Different personality types and different value systems among people  Knowledge and cognitive limitations The users and developers don’t have enough domain or technical knowledge The users and developers don’t remember exactly what was said  may misinterpret that information late Try to simplify the propblem or ignore parts of problem  distort the problem State the problem in terms of favored solution  Human behavior issues: Requirement elicitations is a social process  human behavior issues are involved Conficts and ambiguities in the roles of stakeholders  lead to gap in requirements Fear the new system will necessitate the changes in behavior of individuals and group  withhold information  Technical issues The problems are becoming increasingly complex Requirements change over time There are many sources of requirements Two main activities: The Storm: Generating as many ideas as possible (quantity, not quality) – wild is good! Idea Selection : Filtering out of ideas (combine, clarify, prioritize, improve…) to keep the best one(s) – may require some voting strategy  Planning the Session Define the problem Identify participants Create groups out of the participants (just 3-4 members/group) Each group should consist of people from diverse and relevant backgrounds  Conducting the Session  After the Brainstorming Session Give a reward or recognize the participant follow-up and monitor the solution to closure An information gathering technique that allows the project team, users, and management to work together to identify requirements for the system JAD is a structured process 10 to 20 users meet together under the direction of facilitator skilled in JAD techniques Preparation Pre-session Planning Pre-work Conduction Summary the JAD session Pre-session Planning Evaluate project Identify contentious issues and scope of JAD session Select JAD participants Create preliminary agenda Determine deliverables for the working session Enable participants to prepare for the session Pre-work Planning Gather information Clear schedules for the working session Refine session agenda Finalize pre-session assignments Prepare material for session (flip-charts, presentations, marker ) Set-up stage Session leader welcomes participants, presents task to be discussed, establishes rules and what is on/off topic… Generate common understanding Achieve agreement on decisions Create the deliverables Identify open issues and questions Follow-up Resolve open issues and questions Evaluate the JAD process Follow-up on action items Re-evaluate project Discuss "lessons learned" Finalize deliverables  Facilitator - JAD expert Good with people skills, enthusiastic, sets tone of meeting Set the meeting agenda and guide the discussion Do not join in the discussion as a participant - not provide ideas or opinions on the topics under discussion to remain neutral during the session Must be an expert in both group process techniques and systems analysis and design techniques Others: Executive sponsor User representatives Information system representatives Specialists A new form of JAD called electronic JAD or e-JAD Each participant uses special software on a networked computer to send anonymous ideas and opinions to everyone else All participants can contribute at the same time, without fear of reprisal from people with differing opinions A software requirements prototype is a model or partial implementation of a software system Helps developers, users, and customers better understand system requirements Helps clarify and complete requirements Helps find new functionalities, discuss usability, and establish priorities Prototyping is effective in resolving uncertainties early in the development process Focus prototype development on these uncertain parts Encourages user participation and mutual understanding  Prototypes that focus on user-interface tends to lose the focus of demonstrating/exploring functionality  Prototypes can bring customers’ expectations about the degree of completion unrealistically up  Do not end-up considering a throwaway prototype as part of the production system Always clearly state the purpose before building it of each prototype ...What is Requirement Elicitation? Participants in elicitation Risks of requirements elicitation Requirements elicitation techniques The most common causes... cost overruns and late delivery of software: Incorrect, incomplete, or misunderstood requirement Requirements elicitation is “the process of discovering the requirements for a system by communicating... understanding of the requirements with the users Synthesize appropriate statements of the requirements  Requirement elicitation involves many people  Customer/Client: Person who pays for the software