On Business Requirements
Slides from a talk I gave to colleagues at Franmax on 20 December 2018. It started with a deceptively simple question: what exactly does „gathering business requirements“ mean? We use the term daily, yet when asked to say where a requirement ends and a solution begins, we start to mumble. The answer I went looking for is in Michael Jackson’s problem frames.
Where a slide left out something I said out loud, my speaker note is printed underneath it — in Lithuanian, as I wrote it at the time.
Š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.