Plačiai taikoma, retai tikrinta: use case ir user story veiksmingumo įrodymų bazė

Anotacija

Kontekstas. Use case ir user story yra vieni plačiausiai taikomų reikalavimų inžinerijos metodų programinės įrangos kūrime. Abu kilo iš praktikos, o ne iš įrodymų, ir dabar yra mokomi, jiems kuriami įrankiai bei jie laikomi numatytuoju pasirinkimu.

Tikslas. Nustatyti, ar platų kiekvieno metodo taikymą pagrindžia jo veiksmingumo įrodymai. Tyrimai, kurie metodą išplečia arba matuoja, kas nutinka jį taikant vienu ar kitu būdu, šio klausimo neatsako: jie abu jau suponuoja sprendimą metodą taikyti. Reikšmingi yra įrodymai, kad metodo taikymas sukėlė rezultatą, kuris kitu atveju nebūtų atsiradęs.

Metodas. Iš naujo išanalizuojami du paskelbti duomenų rinkiniai: didžiausio sisteminio user story tyrimų žemėlapio klasifikacijos duomenys (190 įrašų, 2001–2021 m.) ir visas sisteminio use case poveikio pramonėje tyrimų žemėlapio pirminių tyrimų sąrašas (47 tyrimai, iki 2018 m.). Kiekvienam atitinkamos imties tyrimui taikomas dviejų lygių kriterijus. 1 lygis reikalauja, kad tyrimas matuotų metodo poveikį dominančiam rezultatui. 2 lygis papildomai reikalauja kontrafaktinio palyginimo: įrodymų, kad be metodo arba taikant alternatyvą rezultatas būtų buvęs kitoks.

Rezultatai. Du atvejai nepakankamumą rodo skirtingai, ir tai savaime yra informatyvu. User story atveju 80,5 proc. žemėlapyje esančių tyrimų kuria sprendimo artefaktus, o ne žinias apie patį metodą; iš 15 tyrimų, kuriuos pirminiai autoriai priskyrė aiškinamiesiems, šeši pasiekia 1 lygį, o nė vienas – 2 lygio. Kiekvienas 1 lygio tyrimas keičia metodo vidinę savybę, pirmiausia istorijos kokybę arba detalumo lygį, todėl matuojamas kitokio user story rašymo poveikis, o ne jų naudojimo poveikis. Use case atveju vaizdas stipresnis ir kitoks: 26 iš 47 pramoninių tyrimų pasiekia 1 lygį, daugiausia matuodami įverčių tikslumą, palyginti su faktiniais rezultatais, ir tik vienas pasiekia 2 lygį, lygindamas use case point įverčius su ekspertiniu vertinimu. Abu žemėlapiai taip pat neapima dalies vertinamųjų darbų, paskelbtų gretimose srityse, ir nė vienas necituoja 2009 m. žemėlapio, kuriame buvo apibendrinti 46 empiriniai reikalavimų specifikavimo metodų vertinimai.

Išvados. Ne, abiem atvejais. Nei vienas metodas nėra netirtas, o use case atveju matavimų literatūra yra gana didelė, tačiau beveik visa ji suponuoja metodo taikymą. Iš visų 237 tyrimų tik vienas tikrina metodą lygindamas su atskaitos tašku, kuriame jo nėra; jis paskelbtas 2002 m. ir susijęs su įverčiais. Šį rezultatą reikia vertinti kaip apatinę ribą: nė vieno iš dviejų žemėlapių klasifikavimo schemoje nėra kategorijos tokiam tyrimui, todėl negalima atmesti galimybės, kad yra ir kitų, kurių paieška neaptiko. Šis apribojimas pats savaime yra išvada, kurią siejame su 2004 m. evidence-based software engineering darbotvarke: apibendrinimo komponentas buvo institucionalizuotas, o ataskaitų teikimo standartai – ne.

Raktiniai žodžiai: reikalavimų inžinerija, use case, user story, empirinis vertinimas, evidence-based software engineering, tretinis tyrimas.

1. Įvadas

Paklauskite reikalavimų analitiko, kodėl komanda rašo user story arba use case, ir atsakymas dažniausiai bus maždaug toks: „nes taip čia daroma“. Abu metodai yra beveik universalūs, jų mokoma, jiems kuriami įrankiai ir jie laikomi numatytuoju pasirinkimu. Šiame straipsnyje keliamas vienas klausimas: ar tokį taikymą pagrindžia įrodymai, kad šie metodai yra veiksmingi?

Abu metodai tapo standartais prieš tai, kai buvo įvertinti, o vėliau aplink abu išaugo tyrimų literatūra. Toliau kiekvieną iš šių literatūros laukų nagrinėjame atskirai. Kadangi abu metodai atsirado maždaug trijų dešimtmečių skirtumu, iš skirtingų metodologinių tradicijų ir juos tiria skirtingos bendruomenės, taikydamos skirtingas antrinių tyrimų konvencijas, abiejuose aptinkamas dėsningumas vargu ar yra kurio nors vieno metodo savybė.

Mūsų indėlis:

1. Kriterijus, kas būtų laikoma metodo taikymą pagrindžiančiu įrodymu, atskiriant tai nuo daug didesnės darbų, kurie jau suponuoja metodo taikymą, visumos (2 skyrius).
2. Dviejų paskelbtų duomenų rinkinių, po vieną kiekvienam metodui, tyrimas iš naujo taikant šį kriterijų (5 ir 6 skyriai).
3. Atsakymas: vienas tyrimas iš 237 atitinka kriterijų (7 skyrius).
4. Šio atsakymo išlyga: srities apibendrinimo mechanizmai nebūtinai patikimai išryškintų tokius tyrimus, jei jie egzistuotų, todėl nustatytas skaičius yra neaiškaus tikslumo apatinė riba (8 skyrius).

2. Kas būtų laikoma įrodymu

Trys teiginiai įprastai traktuojami kaip vienas.

Taikymas (adoption) – mastas, kuriuo metodas naudojamas. Validacija (validation) – įrodymai, kad jis suteikia tam tikrą naudą. Kontrafaktiniai įrodymai (counterfactual evidence) – įrodymai, kad ta nauda nebūtų atsiradusi kitomis aplinkybėmis.

Tik trečiasis pagrindžia sprendimą metodą taikyti. Pirmasis pats savaime nieko nepagrindžia, nors dažnai pateikiamas taip, tarsi pagrįstų.

Praktiškai kiekvieną tyrimą vertiname pagal du lygius.

1 lygis. Tyrimas empiriškai matuoja metodo arba jo vidinės variacijos poveikį rezultatui, kurį galima iš anksto apibrėžti: įverčių tikslumui, reikalavimų suprantamumui, išsamumui, defektų skaičiui, pakeitimo kainai, testų išvedimo paprastumui, priežiūros pastangoms arba suinteresuotųjų šalių susitarimui. Apklausoje nurodyta suvokiama nauda neatitinka šio kriterijaus; taip pat neatitinka artefakto atitiktis jo paties šablonui, nes atitiktis šablonui nėra mus dominantis rezultatas.

2 lygis. Tyrimas papildomai nustato kontrafaktą. Išmatuotas rezultatas lyginamas su atskaitos tašku, kuriame metodo nėra, jis pakeistas kitu metodu arba taikomas kitaip taip, kaip realiai būtų buvę galima pasirinkti. Atskaitos taškas nebūtinai turi būti kitas įvardytas metodas; tinka ekspertinis vertinimas, sąlyga be pagalbinio metodo ar alternatyvus pateikimo būdas. Reikalaujama, kad tyrimas iš principo galėtų parodyti, jog metodas nepadeda.

Tik 2 lygis yra reikšmingas sprendimui dėl taikymo. 1 lygis žymi tyrimus, kurie matuoja realų dalyką, ir tai verta užfiksuoti, tačiau 1 lygio rezultatas atsako į klausimą, kuris prasideda jau priėmus sprendimą metodą taikyti. Literatūra gali būti didelė, griežta ir visiškai sudaryta iš 1 lygio tyrimų; tokiu atveju ji parodo, kaip metodas veikia, bet nesuteikia pagrindo spręsti, kodėl jį apskritai reikėjo pasirinkti. Viskas, kas yra žemiau 1 lygio, yra dar toliau nuo šio klausimo, ir mes tai klasifikuojame tik tam, kad parodytume, iš ko sudarytos tiriamos visumos.

Pažymime, kad 2 lygio reikalavimas programinės įrangos inžinerijoje yra griežtas dėl priežasčių, kurios nėra šios srities kaltė; prie to grįžtame 8.3 skyriuje.

3. Kontekstas

3.1. Du metodai, įdiegti tokiu pačiu būdu

Use case devintojo dešimtmečio pabaigoje pristatė Jacobsonas, remdamasis darbu „Ericsson“ telekomunikacijų sistemose, kai funkcijų sąrašą pakeitė aktoriaus ir sistemos sąveikos scenarijais. Įtraukimas į UML ir Rational Unified Process pavertė šį pasiūlymą standartu.

User story atsirado iš Extreme Programming dešimtojo dešimtmečio pabaigoje, kartu su anti-dokumentaciniu teiginiu: kortelė yra pažadas kalbėtis, o ne specifikacija. Išlikęs artefaktas yra Cohn 2004 m. išpopuliarintas šablonas; Lucassen ir kt. apklausoje 59 proc. respondentų nurodė jį naudojantys.

Nė vienas iš metodų nebuvo pristatytas remiantis vertinimu. Abiem atvejais seka buvo tokia: patirtis, tada knyga, tada sklaida, tada tyrimai. Tai savaime nėra neįprasta. Daugelis naudingų dalykų sukuriami prieš juos paaiškinant. Būtent todėl šie du atvejai yra palyginami.

3.2. Antrinė literatūra

Apie user story: Amna ir Poels parengė plačiausią žemėlapį, apimantį 2001–2021 m.; jo duomenų rinkinį analizuojame iš naujo. Raharjana ir kt. apžvelgė NLP taikymus. Sporsem ir kt. apibendrino 14 pramonės tyrimų į penkis teiginius ir padarė išvadą, kad teorinis user story naudojimo praktikoje supratimas tebėra ribotas.

Apie use case: Tiwari ir Gupta apžvelgė 119 use case specifikacijų tyrimų (1992–2014 m.) ir nustatė maždaug dvidešimt skirtingų siūlomų šablonų. Barros-Justo, Benitti ir Tiwari išanalizavo poveikį pramonėje ir iš 4431 rastos publikacijos atrinko 47 pirminius tyrimus; jų sąrašą taip pat analizuojame iš naujo. El-Attar ir Miller iš 84 tyrimų išvedė 21 antišabloną. Qazi ir kt. apžvelgė use case pagrįstą testavimą 45 tyrimuose. Santos ir kt. nagrinėjo kintamumo aprašymą tekstiniuose use case ir nurodė neradę eksperimentinio tyrimo, kuriame būtų lyginami nustatyti šablonai naudojimo paprastumo arba suprantamumo požiūriu.

Kalbant apie reikalavimų kokybę apskritai, Montgomery ir kt. atrinko 6905 publikacijas ir paliko 105, pažymėdami, kad tiriami artefaktai paprastai tiesiog vadinami „reikalavimais“, o konkretiems reikalavimų tipams skirta nedaug darbų.

Ypatingo dėmesio nusipelno ankstesnis darbas. Condori-Fernández ir kt. sudarė empirinių programinės įrangos reikalavimų specifikavimo metodų vertinimo žemėlapį, suskirstydami 46 pirminius tyrimus. Jie nustatė, kad dažniausiai vertintas aspektas buvo suprantamumas, dažniausias metodas – eksperimentas, o dažniausia aplinka – akademinė. Šis 2009 m. empirinių programinės įrangos tyrimų bendruomenėje paskelbtas darbas yra artimiausias egzistuojantis įrodymų apibendrinimas tam, ką siekiame apibūdinti. Nė vienas iš dviejų čia iš naujo analizuojamų žemėlapių jo necituoja.

4. Metodas

Tretinis tyrimas, atliekant dviejų paskelbtų duomenų rinkinių antrinę analizę.

Duomenų rinkinių gavimas. Amna ir Poels savo klasifikacijos duomenų rinkinį skelbia atvirai; gavome Clean datasource_SMS_4.xlsx ir atkūrėme jo pasiskirstymus. Barros-Justo ir kt. visą pirminių tyrimų sąrašą paskelbė I priede, o kiekvieno tyrimo aprašymus – rezultatų skyriuose; ištraukėme visas 47 nuorodas.

Požymio imties pasirinkimas. User story atveju pasirinkome Explanation rezultatų klasę, kurią pirminiai autoriai apibrėžė kaip tyrimus, aiškinančius stebimas problemas ir praktiką arba jų poveikį kitiems kintamiesiems; tai klasė, kurioje galėtų būti poveikio matavimų. Use case atveju paėmėme visus 47 tyrimus, nes ši visuma jau apribota pramoniniu taikymu ir yra pakankamai maža, kad ją būtų galima suklasifikuoti išsamiai.

Klasifikacija. Kiekvienas tyrimas pagal 2 skyrių įvertintas kaip T0, T1 arba T2. 15 user story tyrimų atveju gavome paskelbtas anotacijas ir, kai buvo laisvai prieinama, visą tekstą. 47 use case tyrimų atveju naudojome visas nuorodas ir pirminių autorių pateiktus kiekvieno tyrimo aprašymus rezultatų skyriuose. Abi klasifikacijos pateikiamos kaip papildomi failai.

Papildoma paieška. Be to, už abiejų žemėlapių ribų ieškojome vertinamųjų abiejų metodų tyrimų, naudodami iš anksto nustatytas užklausas ir citavimo grandines, kad patikrintume, ar žemėlapių aprėptis yra išsami. Ši paieška yra struktūruota ir atkuriama, tačiau nėra paremta duomenų bazėmis; jos pasekmės nurodytos 9 skyriuje.

5. A atvejis: user story

5.1. Kas yra tyrimų visumoje

Paskelbtame duomenų rinkinyje yra 190 įrašų; straipsnyje nurodyti 186 unikalūs tyrimai, o procentinės dalys atitinka 190 vardiklį. Skaičiuojame pagal 190.

Keturios artefaktus kuriančios klasės sudaro 153 tyrimus, arba 80,5 proc.; likę 37 priklauso aprašymo arba paaiškinimo klasėms. Tai atkartoja pirminių autorių nurodytą pasiskirstymą. Mūsų tikslui šie 153 tyrimai tiesiog nepatenka į nagrinėjamą sritį: naujas istorijų taškų vertinimo algoritmas arba nauja istorijų rašymo ontologija išplečia metodą ir suponuoja jo naudojimą, todėl negali atsakyti į klausimą, ar metodą apskritai reikėtų naudoti. Šią dalį nurodome tam, kad parodytume, kokia maža visumos dalis iš principo galėtų atsakyti į mūsų klausimą, ir toliau nagrinėjame būtent ją.

Pagal tyrimo tipą: validavimo tyrimai – 87 (45,8 proc.), sprendimo pasiūlymai – 53 (27,9 proc.), vertinamieji tyrimai – 50 (26,3 proc.). Šie skaičiai apibūdina, kaip nuodugniai indėlis buvo įvertintas, o ne kokio pobūdžio yra pats indėlis. Patvirtintas naujas algoritmas vis tiek lieka algoritmu.

Pagal laiką: 6 tyrimai 2001–2007 m., 35 – 2008–2014 m., 149 – 2015–2021 m. Sritis jauna ir sparčiai plečiasi.

5.2. Aiškinamosios dalies vertinimas

Penkiolika tyrimų, ankstyviausias – 2014 m.

Šeši tyrimai pasiekia 1 lygį. Nė vienas nepasiekia 2 lygio.

1 lygio grupės sudėtis yra esminė išvada. Kiekvienas iš šešių tyrimų keičia kažką metodo viduje: istorijų kokybę S52 ir S151, detalumą S140, pagalbinį artefaktą S164, modeliavimo užduotį S28. S151 tyrime abiem grupėms pateikiamos user story; vienai grupei pateikiamas pradinis variantas, kitai – patobulintas naudojant QUS sistemą. Šie tyrimai matuoja kitokio user story rašymo poveikį. Nė vienas nematuoja jų naudojimo poveikio.

S9 nusipelno atskiro komentaro, nes jo pavadinimas „The use and effectiveness of user stories in practice“ žada tai, ko kitai visumai trūksta. Jo įrodymai yra apklausų ir interviu duomenys apie suvokiamą veiksmingumą. Jį klasifikuojame kaip T0 ne todėl, kad kritikuojame tyrimą, kuris pats tokio teiginio neteikia, o todėl, kad suvokimas nėra rezultatas, dėl kurio sprendžia praktikas.

6. B atvejis: use case

6.1. Kas yra tyrimų visumoje

Barros-Justo ir kt. iš 4431 rastos publikacijos atrinko 47 pirminius tyrimus, iš viso 5805 įskaičiavus paiešką pagal citavimo grandines; jie apima use case taikymą pramonėje iki 2018 m. rugsėjo. Jų pačių klasifikacijoje: 22 tyrimai (47 proc.) yra vertinamieji, 16 – sprendimų pasiūlymai, 9 – patirties ataskaitos. Jie nustatė aštuonias pranašumų kategorijas, iš kurių dažniausios buvo įverčiai (18 tyrimų), analizė (13) ir automatizavimas (8), taip pat keturias trūkumų kategorijas, iš kurių dažniausios – nenuoseklus scenarijų detalumas ir standartizuoto formato nebuvimas.

Ši visuma nuo A atvejo skiriasi svarbiu aspektu. Ji buvo sudaryta specialiai pramoniniam poveikiui nustatyti, todėl iš anksto nukreipta į tyrimus, kurie realioje aplinkoje ką nors matavo.

6.2. Visumos vertinimas

Dvidešimt šeši tyrimai pasiekia 1 lygį. Dvidešimt yra T0. Tik vienas pasiekia 2 lygį.

1 lygio grupėje dominuoja įverčiai. Keturiolika iš 26 tyrimų matuoja įverčių tikslumą, palyginti su faktiniais rezultatais: kūrimo pastangas, priežiūros pastangas, testų vykdymo pastangas, testų rinkinio dydį, projekto dydį, kainą. Tai yra tikras rezultatų matavimas, turintis aiškią faktinę reikšmę, ir tai yra stipresnė empirinė bazė nei bet kas A atvejyje. Likę tyrimai matuoja defektų duomenis iš pramoninių use case, suprantamumą ir specifikacijos kokybę, testų generavimo rezultatus arba klasių išvedimą.

Vienintelis 2 lygio tyrimas yra SP11 – Anda 2002 m. atliktas palyginimas, kuriame pastangų įverčiai, gauti naudojant use case points, lyginami su ekspertiniais įverčiais. Jis atitinka kriterijų, nes ekspertinis vertinimas yra atskaitos taškas, kurį buvo galima pasirinkti vietoje šio metodo, ir tyrimas iš principo galėjo parodyti, kad use case points yra prastesni. Kiek mums žinoma, tai vienintelis tyrimas abiejose visumose, kuriame metodui realiai kyla rizika būti pripažintam nenaudingu.

6.3. Šablono problema

Platesnėje use case literatūroje matomas atskiras dėsningumas. Tiwari ir Gupta 119 tyrimų nustatė maždaug dvidešimt skirtingų siūlomų šablonų, o šablonų naudojimo patogumas buvo lygintas tik viename, akademinėje aplinkoje atliktame tyrime. Santos ir kt., tyrę kintamumo aprašymą tekstiniuose use case, nurodo neradę eksperimentinio tyrimo, kuriame devyni nustatyti šablonai būtų lyginami pagal naudojimo paprastumą arba suprantamumą.

Dvidešimt variantų, vienas palyginimas. Tai yra proliferacijos be atrankos dėsningumas, kuris taip pat būdingas 80,5 proc. sprendimų daliai A atveju, tik pasiekiamas kitu keliu.

6.4. Dvi pirminių autorių pastabos

Barros-Justo ir kt. nurodo, kad nė viena iš 47 atrinktų publikacijų nesuteikė prieigos prie pirminių duomenų, o tai, jų teigimu, smarkiai sumažino galimybę tyrimus pakartoti. Jie taip pat išvadose siūlo, kad žurnalų redaktoriai galėtų daryti įtaką autoriams, reikalaudami, kad prieš publikaciją būtų pateikta grėsmių validumui ataskaita. Abu aspektai tiesiogiai susiję su 8 skyriumi.

7. Ką abu atvejai turi bendro ir kuo skiriasi

7.1. Jie nepatiria tos pačios nesėkmės

Kyla pagunda teigti, kad visur trūksta įrodymų. Duomenys to nepalaiko.

A atveju yra nedidelė poveikio literatūra ir nėra kontrafaktinės literatūros. B atveju yra didelė poveikio literatūra, paremta įverčių tikslumu, kai egzistuoja faktinė reikšmė, ir vieno tyrimo kontrafaktinė literatūra. A atvejo problema ta, kad dauguma tyrimų kuria įrankius; B atvejo problema ta, kad dauguma tyrimų matuoja metodo rezultatus, niekada nekeldami klausimo, kas būtų nutikę kitaip.

Tyrimų visumos taip pat skiriasi taip, kad jų tiesioginis lyginimas būtų ribotas, todėl jo neatliekame. B atvejis iš anksto atrinktas pagal pramoninį poveikį, todėl jo 1 lygio dalis dėl pačios atrankos yra didesnė ir neįtraukiami akademiniai eksperimentai, kuriuose koncentruojasi kontroliuojami tyrimų planai. A atvejis apima platesnį temų spektrą ir ilgesnį naujesnį laikotarpį.

7.2. Ką jie turi bendro

Tris dalykus.

Pirma, abiem trūksta kontrafakto. Iš 237 tyrimų dviejose visumose tik vienas tyrimas tikrina metodą lygindamas su atskaitos tašku, kuriame jo nėra. Jis paskelbtas 2002 m.

Antra, abiejuose žemėlapiuose neįtraukti vertinamieji darbai, paskelbti gretimose srityse. Mūsų papildoma paieška aptiko tyrimų, vertinančių reikalavimų notacijas konceptualiojo modeliavimo, programų supratimo ir empirinių programinės įrangos tyrimų leidiniuose; nė vieno jų nėra nė viename iš dviejų žemėlapių, taip pat nė vienas žemėlapis necituoja 2009 m. Condori-Fernández apibendrinimo, kuriame buvo 46 tokie vertinimai. Abu žemėlapiai metodologiškai kruopštūs; Barros-Justo komanda įvertino savo protokolą pagal Petersen kriterijus ir gavo 9 iš 11. Šis neįtraukimas nėra neatsargumo rezultatas.

Trečia, ir tai sieja pirmuosius du punktus: nė viena klasifikavimo sistema neturi kategorijos tam tyrimui, kurio norėtų praktikas. Amna ir Poels klasifikuoja pagal tyrimo rezultatų tipą, todėl kontrafaktinis vertinimas natūraliai nėra nei algoritmas, nei modelis, nei sistema, nei prototipas, nei aprašymas, nei paaiškinimas. Barros-Justo ir kt. klasifikuoja pagal pranašumų ir trūkumų kategorijas, o tai suponuoja, kad metodas jau buvo naudojamas, ir klausia, kas po to nutiko. Nė viena schema nėra klaidinga pagal savo paskirtį. Tačiau abi daro kontrafaktinį klausimą nematomą, ir tai įvyksta nepriklausomai viena nuo kitos.

8. Diskusija

8.1. Ką reiškia atsakymas

Tai nereiškia, kad kuris nors metodas yra neveiksmingas. Tai taip pat nereiškia, kad tyrimai yra prasti; didelė jų dalis yra kruopšti, o use case įverčių literatūra yra ypač solidi matavimų visuma.

Tai reiškia, kad abiejų metodų taikymas remiasi kažkuo kitu nei įrodyta nauda, palyginti su jų netaikymu, ir kad vėliau išaugusi literatūra to iš esmės neįrodė. Kai poveikis matuojamas, dažniausiai matuojamas praktikos, kurios taikymas jau laikomas savaime suprantamu, variacijų poveikis.

Praktikams išvada siaura, bet reali. Publikacijų skaičius nėra metodo taikymo įrodymas, kaip nėra toks įrodymas ir didelės, kruopščios literatūros egzistavimas, jei ši literatūra niekada neužduoda klausimo, dėl kurio priimamas sprendimas.

8.2. Kodėl šis skaičius yra apatinė riba

2004 m. EBSE straipsnyje buvo pasiūlyti trys infrastruktūros elementai: empirinių rezultatų apibendrinimo metodika, tyrimų atlikimo ir ataskaitų teikimo gairės bei įrodymų pateikimas praktikams.

Pirmasis elementas buvo išsamiai institucionalizuotas. 2007 m. Keele gairės ir Petersen ir kt. žemėlapių metodika tapo standartais, o abu čia iš naujo analizuojami duomenų rinkiniai buvo sukurti pagal juos.

Todėl mūsų atsakymui reikalinga išlyga. Apibendrinimas paveldi tai, ką pirminė literatūra padaro randama, o literatūra, neturinti konvencijos, pagal kurią būtų aiškiai nurodyta, kas buvo keičiama, koks buvo atskaitos taškas ir koks rezultatas buvo iš anksto nustatytas, kontrafaktinių tyrimų randamų nepadaro. Jokia apžvalgos metodikos griežta tvarka neatgaus to, ko paieška nemato. Barros-Justo ir kt. tą pačią problemą nurodo savo tyrimų visumoje: nė vienas iš 47 tyrimų neturėjo pirminių duomenų. Todėl mūsų nustatytas vieneto skaičius yra apatinė riba, ir negalime pasakyti, kiek ji yra tiksli.

Klinikiniuose tyrimuose ataskaitų teikimo standartas atsirado anksčiau nei naudingas apibendrinimas būtent dėl šios priežasties. CONSORT nepagerino atskirų klinikinių tyrimų; jis padarė jų tyrimų planus suprantamus, o būtent suprantamumas leidžia sisteminę apžvalgą atskirti nuo paprasto skaičiavimo. Programinės įrangos inžinerija pirmiausia sukūrė apibendrinimo pusę ir du dešimtmečius taikė ją nestruktūruotiems duomenims.

8.3. Kontrafaktą čia iš tiesų sunku nustatyti

Nenorime pateikti 2 lygio kaip standarto, kurio sritis tiesiog tingiai atsisakė laikytis.

Kitchenham, Dybå ir Jørgensen įvardijo dvi šiai sričiai būdingas kliūtis. Individualūs kūrėjų gebėjimų skirtumai yra tokie dideli, kad gali užgožti metodo poveikį; klinicisto gebėjimai vaisto poveikio taip neužgožia. Be to, metodo pasekmės dažnai išryškėja tik po metų per priežiūros sąnaudas, o tyrimai trunka savaites, todėl matuojama tai, kas telpa į tyrimo laiką.

Kontrafaktiniam reikalavimų metodo testui reikia neleisti jo taikyti panašiame projekte, o tai yra brangu, pramonėje nepatogu etiniu požiūriu ir yra supainiojama būtent su tais gebėjimų skirtumais, kuriuos įvardijo Kitchenham. Vienintelis mūsų rastas 2 lygio tyrimas šią problemą apeina naudodamas įverčius, kuriuose egzistuoja bazinis metodas, o faktinė reikšmė atsiranda savaime. Tikėtina, kad todėl vienintelis kontrafaktinis tyrimas abiejose visumose yra įverčių tyrimas; tai taip pat rodo, kur būtų galima ieškoti kitų.

8.4. Prašymas, išsakytas tris kartus

Mechanizmas, kuris suveikė klinikiniuose tyrimuose, buvo žurnalų politika. Programinės įrangos inžinerijoje jo nepriklausomos komandos prašė bent tris kartus.

2002 m. Kitchenham ir kolegos savo empirinių tyrimų gaires užbaigė ragindami žurnalų redakcines kolegijas rekomendacijas paversti recenzentų gairėmis ir publikavimo politika.

2019 m. Barros-Justo, Benitti ir Tiwari pasiūlė, kad žurnalų redaktoriai galėtų reikalauti grėsmių validumui ataskaitos kaip būtinos publikavimo sąlygos.

2020 m. Dalpiaz ir Sturm paragino vertinti reikalavimų notacijas pagal užduotis ir pateikti notacijos pasirinkimo įrodymus; tam reikia literatūros, kurioje tokie vertinimai galėtų būti deklaruojami ir randami.

Bendras standartas nebuvo sukurtas. Pažymime šio reikalavimo pasikartojimą per aštuoniolika metų, nebandydami jo paaiškinti; kliūtis akivaizdžiai nėra tai, kad ši idėja nebuvo išsakyta.

9. Grėsmės validumui

Konstrukto validumas. Lygių sistema yra mūsų sukurta. Ypač 2 lygis galėtų būti apibrėžtas liberaliau, pavyzdžiui, į kontrafaktus įtraukiant manipuliacijas metodo viduje; tuomet keli A atvejo tyrimai būtų perkelti į aukštesnį lygį. Skirtumą tarp praktikos variacijos ir testo, ar ją apskritai pasirinkti, laikome tuo, kurio reikia praktikui, tačiau pasirinkimas yra diskutuotinas, todėl pateikiame pirmines klasifikacijas, kad jas būtų galima pakeisti.

Vidinis validumas, A atvejis. Klasifikacijai naudotos paskelbtos anotacijos ir, kai buvo viešai prieinamas, visas tekstas. Keli iš 15 tyrimų lieka už mokamos prieigos ribų, todėl jie klasifikuoti pagal anotaciją ir metaduomenis.

Vidinis validumas, B atvejis. Tai silpnesnė klasifikacija. Naudojome visas nuorodas ir pirminių autorių pateiktus kiekvieno tyrimo aprašymus rezultatų skyriuose, o ne pirminius tekstus. 1 lygio įverčių tyrimų klasifikacija yra patikima, nes įverčių tikslumas yra tai, ką šie tyrimai nagrinėja. Likusių kategorijų klasifikacija mažiau užtikrinta, todėl negalima atmesti praleisto 2 lygio tyrimo. Būtinas kitas žingsnis – visų 47 tyrimų patikrinimas pagal visą tekstą.

Visumų neekvivalentiškumas. Dvi visumos sudarytos skirtingais tikslais, todėl jų lygių dalys nėra tiesiogiai palyginamos. B atvejis iš anksto atrinktas pagal taikymą pramonėje, todėl jo 1 lygio dalis dėl pačios atrankos yra didesnė ir neįtraukiami akademiniai eksperimentai, kuriuose koncentruojasi kontroliuojami tyrimų planai.

Paieškos išsamumas. 7.2 skyriaus teiginiai grindžiami struktūruota, bet ne duomenų bazėmis paremta paieška, atlikta naudojant bendrą interneto paieškos sistemą, o ne Scopus, IEEE Xplore, ACM DL, Web of Science ir Springer su eksportuojamais rezultatų rinkiniais. To pakanka parodyti, kad abu žemėlapiai neįtraukia reikšmingų darbų; tačiau tai neleidžia nustatyti, kiek darbų trūksta. Šį apribojimą, būdingą straipsniui apie ataskaitų teikimo standartus, atvirai nurodome, o ne vadiname paiešką sistemine.

Patikimumas. Klasifikaciją atliko vienas vertintojas, be antro koduotojo; tarp vertintojų sutapimo mato nėra. Abi suklasifikuotos imtys pateikiamos, todėl vertinimą galima pakartoti ir ginčyti.

Priskyrimas. 7.2, 8.2 ir 8.4 skyriuose pateikiami mechanizmai ir stebėjimai, o ne išvados. Neturėjome prieigos prie atrankos įrašų ar redakcinių sprendimų.

Išorinis validumas. Kiekviena pakartotinė analizė perima savo žemėlapio apribojimus: paieškos eilutes, leidinių aprėptį, anglų kalbos apribojimą ir atitinkamai 2018 bei 2021 m. ribas.

Duomenų rinkinio neatitikimas. User story duomenų rinkinyje yra 190 įrašų, o straipsnyje nurodyti 186 unikalūs tyrimai; šio neatitikimo išspręsti nepavyko, o pasikartojančių pavadinimų nėra. Use case straipsnyje nurodoma, kad iš pradinių 48 tyrimų buvo pašalintas vienas dublikatas. Nė vienas neatitikimas neturi įtakos vertintoms imtims.

10. Išvada

Klausimas buvo, ar platų use case ir user story taikymą pagrindžia įrodymai, kad jie yra veiksmingi. Atsakymas abiem atvejais yra ne.

Taip yra ne todėl, kad šie metodai netirti. Du sisteminiai žemėlapiai kartu apima 237 tyrimus, ir didelė jų dalis yra kruopšti. Tačiau beveik visa ši literatūra suponuoja sprendimą metodą taikyti. User story atveju didžioji visumos dalis kuria metodo įrankius, o šeši tyrimai, matuojantys poveikį, matuoja kitokio user story rašymo poveikį. Use case atveju yra didelė matavimų visuma, sutelkta į įverčių tikslumą, kai faktinė reikšmė lengvai prieinama, tačiau ji matuoja tai, kas atsiranda naudojant metodą, o ne tai, ar jo naudojimas buvo naudingas.

Vienas iš 237 tyrimų metodui suteikia realią galimybę būti pripažintam nenaudingu, palygindamas use case point įverčius su ekspertiniu vertinimu. Jis paskelbtas 2002 m.

Šis skaičius yra apatinė riba, kurios tikslumas nežinomas. Nė vieno žemėlapio klasifikavimo schema neturi kategorijos tyrimui apie tai, ar metodą reikėtų taikyti, todėl tokie tyrimai nebūtų patikimai rasti net jei jie egzistuotų, o mūsų papildoma paieška aptiko vertinamųjų darbų gretimose srityse, kurių nėra nė viename žemėlapyje. Kontrafaktą taip pat iš tiesų sunku patikrinti dėl 8.3 skyriuje nurodytų priežasčių, todėl jo nebuvimas nėra vien paprasčiausias aplaidumas.

Abi išlygos rodo tą pačią kryptį. Prieš sritis galėdama pasakyti, kiek egzistuoja metodo taikymo įrodymų, ji turi turėti pirminius tyrimus, kuriuose būtų nurodyta, kas buvo keičiama, su kokiu atskaitos tašku lyginta ir kokio iš anksto nustatyto rezultato siekta, kad apžvalga galėtų juos rasti. Tai buvo antrasis iš trijų 2004 m. pasiūlytų elementų; nuo to laiko to iš žurnalų buvo prašyta bent tris kartus, tačiau jis nebuvo priimtas.

Kol taip nėra, antriniai tyrimai ir toliau ras mažai įrodymų, tačiau negalės pasakyti, ar taip yra todėl, kad jų mažai egzistuoja, ar todėl, kad jų paieškos priemonės jų negali rasti.

Duomenų prieinamumas

User story duomenų rinkinį Amna ir Poels skelbia adresu https://github.com/anisamna/SMS_UserStory. Use case pirminių tyrimų sąrašas yra Barros-Justo ir kt. I priede, o jų duomenų ištraukimo forma pateikiama adresu http://doi.org/10.6084/m9.figshare.7959425. Abi įvertintos klasifikacijos pateikiamos kaip papildomi failai.

Literatūra

1. Jacobson, I. Object-oriented development in an industrial environment. Proc. OOPSLA, 1987.
2. Jacobson, I. Use cases: Yesterday, today, and tomorrow. Software and Systems Modeling, 3, pp. 210–220, 2004.
3. Cohn, M. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
4. Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., Brinkkemper, S. The use and effectiveness of user stories in practice. Proc. REFSQ, 2016, pp. 205–222.
5. Amna, A. R., Poels, G. Systematic literature mapping of user story research. IEEE Access, 10, pp. 51723–51746, 2022. doi: 10.1109/ACCESS.2022.3173745.
6. Barros-Justo, J. L., Benitti, F. B. V., Tiwari, S. The impact of Use Cases in real-world software development projects: A systematic mapping study. Computer Standards and Interfaces, 66, 103362, 2019. doi: 10.1016/j.csi.2019.103362.
7. Tiwari, S., Gupta, A. A systematic literature review of use case specifications research. Information and Software Technology, 67, pp. 128–158, 2015. doi: 10.1016/j.infsof.2015.06.004.
8. Santos, I. S., Andrade, R. M. C., Neto, P. A. S. How to describe SPL variabilities in textual Use Cases: A systematic mapping study. Proc. SBCARS, 2014, pp. 64–73.
9. El-Attar, M., Miller, J. Constructing high quality Use Case models: A systematic review of current practices. Requirements Engineering, 17, pp. 187–201, 2012.
10. Qazi, A. M., Rauf, A., Minhas, N. M. A systematic review of Use Cases based software testing techniques. International Journal of Software Engineering and Its Applications, 10, pp. 337–360, 2016.
11. Montgomery, L., Fucci, D., Bouraffa, A., Scholz, L., Maalej, W. Empirical research on requirements quality: A systematic mapping study. Requirements Engineering, 2022.
12. Sporsem, T. E., Dingsøyr, T., Stol, K.-J. User stories as boundary objects in agile requirements engineering: A theoretical literature review. Journal of Systems and Software, 233, 112693, 2026. doi: 10.1016/j.jss.2025.112693.
13. Raharjana, I. K., Siahaan, D., Fatichah, C. User stories and natural language processing: A systematic literature review. IEEE Access, 9, pp. 53811–53826, 2021.
14. Condori-Fernández, N., Daneva, M., Sikkel, K., Wieringa, R., Dieste, O., Pastor, O. A systematic mapping study on empirical evaluation of software requirements specifications techniques. Proc. ESEM, 2009, pp. 502–505. doi: 10.1109/ESEM.2009.5314232.
15. Anda, B. Comparing effort estimates based on Use Case points with expert estimates. Proc. EASE, 2002.
16. Liskin, O., Pham, R., Kiesling, S., Schneider, K. Why we need a granularity concept for user stories. Proc. XP, LNBIP 179, 2014, pp. 110–125.
17. Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., Brinkkemper, S. Improving user story practice with the Grimm Method: A multiple case study in the software industry. Proc. REFSQ, 2017.
18. Wautelet, Y., Gielis, D., Poelmans, S., Heng, S. Evaluating the impact of user stories quality on the ability to understand and structure requirements. Proc. PoEM, LNBIP 369, 2019, pp. 3–19.
19. Dalpiaz, F., Sturm, A. Conceptualizing requirements using user stories and use cases: A controlled experiment. Proc. REFSQ, LNCS 12045, 2020, pp. 221–238. doi: 10.1007/978-3-030-44429-7_16.
20. Tsilionis, K., Amna, A. R., Heng, S., Poelmans, S., Poels, G. Controlled experiments on user stories’ modeling: Past, present, and future. CEUR Workshop Proceedings, 3134, 2022.
21. Kitchenham, B., Dybå, T., Jørgensen, M. Evidence-based software engineering. Proc. ICSE, 2004.
22. Kitchenham, B. A., Pfleeger, S. L., Pickard, L. M., Jones, P. W., Hoaglin, D. C., El Emam, K., Rosenberg, J. Preliminary guidelines for empirical research in software engineering. IEEE Transactions on Software Engineering, 28(8), pp. 721–734, 2002.
23. Kitchenham, B., Charters, S. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE-2007-01, Keele University, 2007.
24. Petersen, K., Vakkalanka, S., Kuzniarz, L. Guidelines for conducting systematic mapping studies in software engineering: An update. Information and Software Technology, 64, pp. 1–18, 2015.
25. Wieringa, R., Maiden, N., Mead, N., Rolland, C. Requirements engineering paper classification and evaluation criteria: A proposal and a discussion. Requirements Engineering, 11, pp. 102–107, 2006.
26. Cochrane, A. L. Effectiveness and Efficiency: Random Reflections on Health Services. Nuffield Provincial Hospitals Trust, 1972.
27. Moher, D., Schulz, K. F., Altman, D. G. The CONSORT statement. The Lancet, 357, 2001.