Supporting Non-Functional Requirements Elicitation with Templates
Total Page：16
File Type：pdf, Size：1020Kb
Pozna´nUniversity of Technology Institute of Computing Science SUPPORTING NON-FUNCTIONAL REQUIREMENTS ELICITATION WITH TEMPLATES Sylwia Kopczy´nska A dissertation submitted to the Council of the Faculty of Computing in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Supervisor Jerzy Nawrocki, PhD, Dr Habil. Auxiliary supervisor Mirosław Ochodek, PhD Pozna´n,Poland 2018 ABSTRACT Non-functional requirements (NFRs) state conditions under which functionality is useful (they concern perfor- mance, security, availability, etc.). Unfortunately, they are frequently neglected, especially those NFRs that are difficult to write or seem ostensibly obvious. Such behavior is an important risk factor in software projects as, in many cases, improper management of NFRs is one of the root causes of project failures. One of the approaches to support elicitation of NFRs is using a catalog of templates. Templates are natural lan- guage statements with some parameters (gaps) to fill in and optional parts to select during elicitation. Many authors say that templates improve consistency and testability of requirements, and that they reduce am- biguity. Although experts formulate these claims, some recent studies show that practitioners are afraid of using NFR templates in their projects. It is not clear for them what are the benefits and costs of using NFR templates. In the traditional approaches to software development, the necessity to elicit NFRs seemed rather obvious. Re- cently, agile approaches have gained popularity but it would be vain to look for agile practices that explicitly refer to NFRs. Therefore, a question arises whether NFRs are still important. Another issue is user feedback left in online app stores. This feedback has been found a promising source of func- tional requirements. Thus, it would be valuable to check, if user feedback can also be useful for elicitation of NFRs. The aim of the thesis is to provide knowledge that would allow managers of software projects to make an in- formed decision whether to use or not to use a catalog of NFR templates. The focus is on the following research questions: RQ1. How important is it for agile practitioners to have NFRs specified in their software projects? We have conducted a survey to get to know how agile practitioners perceive the importance of NFRs. It has proved that ¶ having NFRs specified in a software project is perceived by 77% of agile practitioners as an important development practice. Moreover, · the more experienced the practitioners, the higher the opinion on the importance of NFRs. RQ2. What is the usefulness of catalog of NFR templates? Usefulness of NFR templates was evaluated in two studies: (1) a case study with 7 software projects, and (2) a con- trolled experiment with 107 people eliciting NFRs for a fictitious e-commerce application. In the case study ¸ the percentage of initially elicited NFRs that remained valid till the end of each project was above 80% for all but one project, ¹ the percentage of final NFRs that were elicited at the beginning of each project was for almost all the projects above 80%, º the percentage of initially elicited NFRs that have been derived from the templates was for almost all the projects above 60%. From the controlled experiment it follows that » using template-supported elicitation inexperienced elicitors provided NFRs that were less ambiguous, more detailed, more testable and more complete than those elicited with the ad hoc approach for both individuals and teams. In both studies ¼ over 80% of respondents who used template-supported elicitation regarded NFR templates as useful. RQ3. How the benefits and costs of using catalog change during catalog evolution? When an organization runs a sequence of projects, their catalog should be updated at the end of each project whenever missing or ’too narrow’ templates are identified. We analyzed how catalog characteristics concerning its benefits and costs change in the evolution driven by the mentioned updates. In the study 41 requirements specifi- cations with the total of 2,231 NFRs were used, coming from industry software projects. One of the main observations is that after ”learning" templates from about 40 projects one can expect ½ at least 75% of NFRs of the next project to be derived from the templates of such catalog, and up to 10% of the templates may need to be modified or added. RQ4. To what extent user feedback in app stores is a good source of NFRs and their templates? User reviews of software applications stored in three app stores (Apple App Store, Google Play, and Amazon App- store) were analyzed. ¿ Over 45% of the user reviews left in the app stores concerned non-functional aspects and they could be used as a basis for formulating NFRs and their templates. From the presented results it follows that NFRs are important even in agile projects. Their elicitation is a difficult task, especially for inexperienced elicitors. In this context, a catalog of NFR templates can be really useful. Creating such a catalog according to the evolutionary paradigm seems very practical. However, only mature catalog can bring full benefits, i.e., high coverage of requirements by the templates, and little maintenance effort. It seems that about 40 projects are needed to make a catalog of NFR templates mature. Moreover, when working on new releases of a software product, it could be beneficial to take into consideration user feedback left in online app stores. Politechnika Pozna´nska Instytut Informatyki WSPOMAGANIE POZYSKIWANIA WYMAGAN´ POZAFUNKCJONALNYCH Z WYKORZYSTANIEM SZABLONÓW WYMAGAN´ Sylwia Kopczy´nska Rozprawa doktorska Przedłozono˙ Radzie Wydziału Informatyki Politechniki Pozna´nskiej Promotor dr hab. inz.˙ Jerzy Nawrocki, prof. nadzw. Promotor pomocniczy dr inz.˙ Mirosław Ochodek Pozna´n2018 STRESZCZENIE Wymaganie pozafunkcjonalne (ang. non-functional requirement, w skrócie NFR) opisuje warunek, który ma by´c spełniony, aby funkcje realizowane przez system były uzyteczne˙ (moze˙ dotyczy´cwydajno´sci,bezpiecze´nstwa, dost˛ep- no´sci itp.). Niestety NFRy s ˛acz˛estolekcewazone,˙ w szczególno´scite, które s ˛atrudne do wyspecyfikowania lub wydaj ˛a si˛eoczywiste. Takie zachowanie to istotny czynnik ryzyka, poniewaz˙ nieprawidłowe zarz ˛adzanie NFRami wielokrotnie okazało si˛ejedn ˛az głównych przyczyn niepowodze´nprojektów informatycznych. Jednym z podej´s´c, które wspiera pozyskiwanie NFRów jest katalog szablonów. Szablon NFRa jest to wzorzec zdania w j˛ezyku naturalnym, który zawiera parametry (puste miejsca) do wypełnienia i cz˛e´sciopcjonalne, czyli fragmenty do wyboru. Wielu ekspertów twierdzi, ze˙ szablony poprawiaj ˛aspójno´s´cwymaga´n,zwi˛ekszaj˛ałatwo´s´cich testowania oraz zm- niejszaj ˛aich wieloznaczno´s´c.Mimo to—jak wynika z ostatnich bada´n—praktycy obawiaj ˛asi˛estosowania szablonów NFRów. Nie jest dla nich jasne jakie s ˛akorzy´sci i koszty zwi ˛azane z korzystaniem z szablonów. W tradycyjnych podej´sciach do wytwarzania oprogramowania konieczno´s´czbierania NFRów w zasadzie nie podle- gała dyskusji. Jednakze˙ ostatnio zwinne podej´sciazyskuj ˛ana popularno´scii prózno˙ byłoby szuka´cw´sród zalecanych przez nie praktyk tych, które bezpo´srednio odnosz ˛asi˛edo NFRów. Powstaje zatem pytanie, czy NFRy s ˛anadal istotne. Innym waznym˙ zgadnieniem s ˛aopinie zostawiane przez uzytkowników˙ sklepów on–line z aplikacjami. Okazały si˛e one obiecuj ˛acym´zródłem wymaga´nfunkcjonalnych. Warto by było dowiedzie´csi˛e, czy te opinie mog ˛aby´ctakze˙ pomocne przy formułowaniu NFRów. Celem pracy jest dostarczenie wiedzy, która pozwoliłaby kadrze zarz ˛adzaj˛acejpodejmowa´c´swiadomedecyzje doty- cz ˛acestosowania (lub nie stosowania) katalogu szablonów NFRów w projektach informatycznych. W pracy skupiono si˛ena nast˛epuj˛acych pytaniach badawczych: RQ1. Jak wazne˙ dla praktyków jest specyfikowanie NFRów w zwinnych projektach informatycznych? Przeprowadzili´smyankiet˛e, aby dowiedzie´csi˛e, jak praktycy postrzegaj ˛aznaczenie NFRów w zwinnych projektach in- formatycznych. Dowiedzieli´smysi˛e, ze˙ ¶ specyfikowanie NFRów w zwinnym projekcie informatycznym jest postrze- gane jako wazne˙ przez 77% praktyków . Co wi˛ecej, · im bardziej do´swiadczeni praktycy, tym bardziej pozytywn ˛a mieli opini˛ena temat przydatno´sci tej praktyki. RQ2. Jaka jest uzyteczno´s´ckatalogu˙ szablonów NFRów? Uzyteczno´s´cszablonów˙ NFRów została oceniona w: (1) studium przypadku z 7 projektami informatycznymi i (2) eksperymencie kontrolowanym ze 107 osobami z małym do´swiadczeniem, które pozyskiwały wymagania dla systemu typu e-commerce. W naszym studium przypadku ¸ procent pocz ˛atkowo pozyskanych wymaga´n, które pozostały wazne˙ do ko´nca pro- jektu był na poziomie 80%, ¹ procent ko´ncowych wymaga´n, które pojawiły si˛ena pocz ˛atku projektu, był powyzej˙ 80% w prawie wszystkich projektach, º procent pocz ˛atkowo pozyskanych NFRów, które zostały wywiedzione z szablonów był powyzej˙ 60% w prawie wszystkich projektach. Z naszego eksperymentu wynika, ze˙ » przy uzyciu˙ szablonów osoby dostarczyły wymagania, które s ˛amniej niejed- noznaczne, bardziej szczegółowe, lepsze z punktu widzenia testowalno´scii bardziej kompletne niz˙ te pozyskane ad hoc zarówno je´slipracowały one same, jak i w zespole. W obu badaniach ¼ ponad 80% ankietowanych osób, które pozyskiwało NFRy ze wsparciem szablonów postrzegało je jako uzyteczne.˙ RQ3. Jak si˛ezmieniaj ˛azyski i koszty zwi ˛azane z katalogiem NFRów w trakcie jego ewolucji? Gdy organizacja realizuje sekwencj˛eprojektów, ich katalog szablonów NFRów powinien