Apie verslo reikalavimus
Skaidrės iš pranešimo, kurį 2018 m. gruodžio 20 d. skaičiau kolegoms Franmax. Viskas prasidėjo nuo apgaulingai paprasto klausimo: ką iš tiesų reiškia „rinkti verslo reikalavimus”? Terminą vartojame kasdien, bet paprašyti pasakyti, kur baigiasi reikalavimas ir prasideda sprendimas, imame mikčioti. Atsakymo ieškojau Michaelo Jacksono problemų rėmuose (problem frames).
Skaidrės angliškos ir tokios, kokios buvo 2018-aisiais — jų neredaguoju. Po jomis spausdinamas užrašas skaitytojui: kas buvo pasakyta žodžiu ten, kur skaidrėje to nėra, paaiškinimas ten, kur vien skaidrės neužtenka, o kur skaidrė nurodo šaltinį — nuoroda į jį. Po paskutine skaidre — visų šaltinių sąrašas.
Šiandien noriu pristatyti savo business requirements tyrimą ir mintis šia tema.
Tema buvo man aktuali AMM projekte. Nors šiuo metu didžioji veiklos analitiko produkcijos dalis yra User Storiai, bet BR reikalingi a) krypčiai nustatyti b) apibrėžti ir komunikuoti projekto ar darbo apimtį.
Business Requirements ruošimas projekte man pačiam yra pakankamai nauja tema. Paskutinius 10 metų, kai dirbu veiklos analitiku (business analyst), didžiąja dalimi BRq gaudavau jau paruoštus ir jų pagrindu ruošdavau specifikacijas programuotojams. Paskutinėje darbovietėje vykdėme vidinį projektą, kurio tikslas buvo pagerinti projektų vykdymo metodiką, tame tarpe ir BRq paruošimą pagal kliento užsakymą. Šiek tiek gilinausi į taip vadinamą goal-oriented requirements engineeringą bei ruošiau DSL‘o (domain specific language) notaciją UML‘u. Žmonių kalba – notaciją goal modelių paišymui. Bendroje sumoje tam skyriau apie 2 mėn full time.
Tos patirties užteko, kad pradėčiau šiek tiek orientuotis temoje, bet neužteko tam, kad galėčiau be papildomo gilinimosi aprašyti BRq aprašymo metodiką.
Taigi atlikau nedidelį tyrimą, šiek tiek apgalvojau surinktą medžiagą ir, man atrodo, sugalvojau visai priimtiną BRq formulavimo ir aprašymo būdo pagrindinę idėją. Darbas toli gražu nėra baigtas. Vienas iš prezentacijos tikslų – gauti feedbacką, ar pasirinkta kryptis atrodo perspektyvi.
Reikalavimų svarba suprasta seniai ir išlieka aktuali iki šiol.
Boehm‘as 1981 metais pasakė, kad vėlyvas ištaisymas gali būti iki 200 kartų brangesnis. Boehm – estimavimo metodo Constructive Cost Model (COCOMO) kūrėjas; terminas žmogmėnesis (man-month) yra Brookso, iš jo 1975 m. knygos „The Mythical Man-Month“.
Barry Boehm's 1981 book Software Engineering Economics documents his Constructive Cost Model (COCOMO). It relates software development effort for a program, in Person-Months (PM), to Thousand Source Lines of Code (KSLOC).
Brooks 1987 – hardest, most important function of SE is the iterative extraction & refinement of requirements. Brooks‘as savo metu IBM‘e vadovavo System/360 ir OS/360 kūrimui ir šiaip labai nusipelnęs SE veikėjas.
1996 metais Europos Software Instituto tyrimas parodė, kad req specifikacija yra pagrindinė software problema – daugiau nei 50 proc. respondentų.
Šaltiniai: [1] van Lamsweerde, Goal-Oriented Requirements Engineering: From System Objectives to UML Models to Precise Software Specifications, ICSE 2003; ten cituojamas Brookso straipsnis – No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987.
Measuring the Impact of Changing Requirements on Software Project Cost.
Veiklos analitikas yra fronto linijoje formuluojant biznio reikalavimus.
Requirements Engineering – atskira Software Engineering sritis, subdisciplina.
Šaltinis: [3] Nuseibeh ir Easterbrook, Requirements Engineering: A Roadmap, ICSE 2000, p. 35–46.
Rasti – suprasti tikslą
Identifikuoti poreikius
Dokumentuoti
Analizuoti
Komunikuoti
Valdyti – aš pats pridėjau
Vienžo, reikalavimų formulavimas yra rimtas iššūkis ir jį yra bandoma spręsti.
Šaltinis: [4] Zhi Li, Progressing Problems from Requirements to Specifications in Problem Frames, daktaro disertacija, The Open University. Paveikslas ten nepakeistas paimtas iš Robertsonų Volere reikalavimų specifikacijos šablono.
Šaltinis: A KAOS Tutorial, Respect-IT, 2007.
Šaltinis: [6] Espada, Goulão ir Araújo, Measuring Complexity and Completeness of KAOS Goal Models, CITI, Universidade Nova de Lisboa.
Šaltinis: [5] van Lamsweerde, Goal-Oriented Requirements Engineering, Luveno universitetas, 2003, cituojant Jacksoną (1995) ir Parnasą (1995).
Klausimas skaidrės viršuje yra viso šito palyginimo ašis. Programinėje įrangoje mašina akivaizdi – tai programa, kurią rašome. Versle ji neakivaizdi: jei reikalavimas kalba apie procesą, kas yra ta mašina, kuri procesą valdo ir kurios specifikaciją mes rašome?
Kairėje – atsakymas pavyzdžiu. Žuvies ašaka su „Bad Coffee“ čia nėra priežasčių analizė, nors būtent taip ji paprastai naudojama. Ji čia yra svertų sąrašas: jei nori, kad kavos darymo procesas elgtųsi kitaip, gali paveikti tik keturis dalykus – žmones, procedūras, medžiagas ir įrangą. Vadinasi, proceso mašina nėra vienas daiktas, o šitas ketvertas.
Dešinėje atsakymo nėra, ir tai sąmoninga. Maximos procesams mašiną dar reikėjo įvardyti, ir kiekvienam procesui ji bus kita. Promo kompensacijų procese, apie kurį kalba ankstesnės skaidrės, ja pasirodė esanti SAP kartu su sutarčių registravimo tvarka: specifikacija „visi promo kompensacijų skaičiavimai atliekami SAP“ yra būtent tos mašinos aprašymas.
Visi skaidrėse cituoti šaltiniai vienoje vietoje.
[3] Nuseibeh ir Easterbrook, Requirements Engineering: A Roadmap, ICSE 2000, p. 35–46.
[7] Jackson, A Tutorial on Software Development Problem Frames, 2006.
A KAOS Tutorial, Respect-IT, 2007.
Robertson ir Robertson, Volere reikalavimų specifikacijos šablonas.
Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987.