Requirements Engineering Requirem ents Engineering Unit 3: - PowerPoint PPT Presentation

9/ 22/ 2009 | 1 9/ 22/ 2009 | 2 Course outline Requirements Engineering Requirem ents Engineering Unit 3: Requirem ents Engineering process Requirements elicitation Requirem ents elicitation › Department of Computer Science / Peng Liang Requirem ents docum entation Requirem ents Requirem ents › Rijksuniversiteit Groningen (RUG) negotiation analysis Requirem ents m anagem ent › http:/ / www.cs.rug.nl/ ~liangp/ teaching/ courses/ RE2009Fall/ Requirem ent validation Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 3 9/ 22/ 2009 | 4 Last Unit Course project Requirem ents › The progress of the REWiki documentation will be Engineering along with the progress of the course content. process This Unit › Recommended schedule • identify project scope, feasibility issues, risks, stakeholders Requirem ents (Week 38) elicitation • decompose goals into sub-goals, and elicit scenarios, document major functional and non-functional requirements (Week 39) Next Unit • analyse requirements, prioritize requirements (Week 40) Requirem ents • negotiate, validate requirements and RE iterations (Week 41, 42, and 43) m odeling Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 5 9/ 22/ 2009 | 6 Course project Course project (Group 4 recruiting) › [Group 1]: Ruurd Krekt, Pim van der Waak, Henk van › Every group can also proceed with your own speed Ramshorst, Ralph van Brederode, Johan van der Geest (5) › Evaluation of the course project will be determined by › [Group 2]: Erwin Vast, Fernand Geertsema, Marco Hak, Jop Verhagen, Mattijs Meiboom, Zaki Juma (6) the final quality of the deliverables › [Group 3]: Anton Jongsma, Dirk Nederveen, Karsten Westra, Thomas Edward Spanjaard, Mark Scheeve, Edwin-Jan Harmsma (6) › [Group 4]: Eelco Hooghiem, Gertjan Dalstra, Samuel Esposito, Artemios Kontogogos, Abarajithan Parameswaran (5) › [Group 5]: Gerhard Boer, Jeroen de Groot, Tim van Elteren, Rudy Schoenmaker, Wilrik Mook, Pieter Stavast (6) › [Group 6]: Jochem Pastoor, Stef van Grieken, Jan Wijma, Wilco Wijbrandi, Joris de Keijse (5) Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 7 9/ 22/ 2009 | 8 Assignment for a good understanding Contents › Hundreds of methods are collected › Why requirement elicitation? • Interviews ( requirem ents elicitation m ethod ) › Requirements elicitation activities • Questionnaires › Requirements elicitation techniques • Storyboard • Prototyping • Use cases ( requirem ents representation m ethod ) • Workshop ( organization m ethod ) • Joint application design • … Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 9 9/ 22/ 2009 | 10 Why requirement elicitation? “Yes, but … ” syndrome › “Wow, this is so cool and nice; we really want to use › Typical requirement syndromes this.” • “Yes, but … ” › “Yes, but, hmmm, • “Undiscovered requirements” • What about this part … ? • “Customer/ user and developer” • Wouldn’t it be nice if … ? • … ? Intangible nature of software system › D. Leffingwell and D. Widrig . Managing Softw are Requirem ents: A Use Case Approach. Addison-Wesley, 2003. Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 11 9/ 22/ 2009 | 12 “Undiscovered requirements” syndrome “Yes, but … ” solution › Get the “buts” out AE(earlier)AP › “The more you find, the more you need to know” › Elicit the “buts” response early › When have we found enough requirements? Oh, I found it, but w here should I go next? To shows users the prototypes or demos earlier Requirements elicitation, and regularly never completed task Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 13 9/ 22/ 2009 | 14 “Undiscovered requirements” solution “User and developer” syndrome › Scoping your system › Communication gap between user and developer › Identify the stakeholders in three worlds • From different world • Speak different language • Different background, motivations, objectives Living in different world Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 15 9/ 22/ 2009 | 16 “User and developer” solution › Better communication to mitigate the risk • Role playing Embrace the users • User observation • Storyboarding • Prototypes • Teach/ echo back • … Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 17 9/ 22/ 2009 | 18 Steps of requirements elicitation Example › HAS (home automation system) 1 2 Application Problems domain to be solved Stakeholder needs and Business constraints context 4 3 Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 19 9/ 22/ 2009 | 20 Elicitation activities Elicitation activities › (Step1) Application domain understanding › (Step2) Problem understanding • The trend in HAS (home automation system) • For the easy life at home • The state-of-art technology used in HAS • Security at home • Domain concepts in HAS • Heating, air conditioning control • … • Household management Climate control • … Sensor Human HAS Intervention Controller Safeguard Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 21 9/ 22/ 2009 | 22 Elicitation activities Elicitation activities › (Step3) Business understanding › (Step4) Understanding the specific needs and constraints of system stakeholders • Target market of HAS • Profit strategy of HAS Stakeholders • Selling points of HAS • … any person or organization who can be positively or negatively The ultimate goal of RE impacted by, or cause an impact on the actions of a system. “minimize risk” “add business value” “satisfy the user” Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 23 9/ 22/ 2009 | 24 Who are they? Stakeholders identification › Who they are? • From three world • usage, development, environment › M. Glinz and R.J. Wieringa. Stakeholders in Requirem ents Engineering . IEEE Software, 24(2):18-20, 2007. Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 25 9/ 22/ 2009 | 26 Stakeholders identification › How important they are? (HAS) • Critical: decide the project ( Custom er ) Eliciting requirements from • Major: significant negative impact on the system stakeholders ( Thief ) • Minor: marginal impact on the system ( Neighborhood ) Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 27 9/ 22/ 2009 | 28 Elicitation techniques › Traditional techniques Good requirements is not readily › Collaborative techniques available from users › Contextual approaches › Representation-based approaches Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall

9/ 22/ 2009 | 29 9/ 22/ 2009 | 30 Traditional techniques Reading existing documents › Reading existing documents › Sources of project information › Analyzing “hard data” • Company reports ( business context ) › Interviews • Organization charts ( potential stakeholders ) › Introspection • Policy manuals ( regulations ) › Surveys & questionnaires • Job descriptions ( potential requirem ents, problem s, and business process ) • Existing systems documentation ( reusable requirem ents ) Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 9/ 22/ 2009 | 31 9/ 22/ 2009 | 32 Elicited requirement info from business context Business context example › “Intellibuild wants to offer a pioneering product › Business goal that will revolutionize the market of infotainm ent . › To provide infotainment product These services will replace the existing m odel , › Risk e.g. going to the information desk or getting the › To be a pioneering product is a risk in market information before reaching the location. › Problem Furthermore, it will implement new services that › To replace the existing information broadcasting have not been offered before, e.g., real-tim e model notification of schedule changes.” › Requirement › To provide real-time notification of schedule change Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall