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 — tokios, kokios buvo pranešime. Ten, kur skaidrėje kažko nebuvo parašyta, o pasakiau žodžiu, po ja atspausdintas mano to meto už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 ir termino žmogmėnesis (man-month) autorius.
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ų.
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.
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.