Elicitarea cerințelor funcționale este un subiect frecvent vehiculat printre analiștii de business, dar întrebarea cea mai comună este: "De unde apar de fapt aceste cerințe?" Este destul de complicat să înțelegem și să colectăm cerințele funcționale ale unui sistem în condițiile în care explicațiile clienților sunt de regulă ambigue, variate și lipsite de terminologie tehnică.
Dar cum reușim să identificăm și să documentăm toate funcționalitățile cerute, rolurile implicate și acțiunile acestora? Răspunsul este destul de simplu - trebuie să facem analiza scenariilor de utilizare (engl. use case analysis) pentru a reuși să stabilim contractele dintre sistem și utilizatori și să rafinăm cazurile de utilizare ale sistemului pentru a obține o viziune cât mai organizată și mai completă.
Scrierea de scenarii de utilizare eficiente este una dintre cele mai importante responsabilități ale unui analist de business, deoarece oferă cerințelor funcționale obținute obiectivitate crescută, permițând o reprezentare adecvată a funcționalităților și a comportamentului produsului. Opusă reprezentării textuale, modelarea scenariilor de utilizare permite o descriere pas cu pas a acțiunilor - independente și interconectate - făcute de actorii definiți.
Odată scrise, scenariile de utilizare devin livrabile de uz larg, fiind utile mai multor participanți la procesul de livrare al unui produs software, precum: beneficiarii, analiștii de business, echipele de dezvoltare și testare, autorii tehnici, designerii UI/UX, arhitecții software și chiar și cei din management.
Pentru a avea un punct de pornire solid în ceea ce privește colectarea cerințelor funcționale ale unui produs, analistul de business trebuie să întrebe mai întâi cine va folosi sistemul, cine va obține valoare prin interacționarea cu el sau cine își va atinge un obiectiv de business prin intermediul acestor interacțiuni. Răspunsul este - ACTORII - anume persoanele sau produsele software care fac uz de sistem. Este recomandat să atribuim un nume și o scurtă descriere fiecărui actor, pentru a evita confuziile, suprapunerea de roluri și/sau ambiguitatea. Actorii sunt externi sistemului și pot fi de mai multe tipuri, ca de exemplu actorii principali ai unui scenariu, actorii secundari, sub-sisteme sau componente ale sistemului în cauză.
După ce a pus în evidență actorii, analistul identifică activitățile desfășurate de fiecare. Acestea se numesc cazuri de utilizare (engl. use cases) - și reprezintă modul în care actorii interacționează cu sistemul pentru a obține valoare de business. Aceste acțiuni trebuie să fie independente, având bineînțeles nume și descrieri scurte. Analistul trebuie să fie conștient că printe aceste activități va regăsi scenariile principale, sau pozitive (engl. happy day scenarios), scenariile alternative și cazurile de eroare și doar înțelegând profund domeniul de business va putea să le identifice și să le clasifice corect. Totodată, pentru a obține scenarii de utilizare reale, trebuie să acordăm atenție pre și post condițiilor aferente.
Prin urmare, scenariile de utilizare sunt nucleul unui produs software, întrucât descriu comportamentul și modul de utilizare al sistemului din perspectiva fiecărui actor. Scenariile de utilizare reprezintă o tehnică foarte puternică de modelare a scenariilor de business. Setul complet de actori și de scenarii se mai numește și system"s use case model. Acest model poate fi reprezentat fie ca un document scris fie ca diagramă, de regulă ambele, deoarece se pot surprinde nivele de detalii diferite. Actorii sunt reprezentați ca oameni, scenariile de utilizare ca elipse, iar relațiile prin săgeți, orientate dinspre actor înspre scenariu.
Să presupunem că avem un client al cărui domeniu de business constă în găzduirea de evenimente, de exemplu conferințe, în clădirea proprie.
Clădirea are trei săli de conferință, fiecare cu capacitatea de a acomoda 100, 150 și respectiv 200 de persoane. Clientul oferă servicii complete clienților săi, care includ:
Momentan, clientul menține informațiile folosind documente simple și dorește o soluție web care să-l ajute să își automatizeze serviciile.
Așadar, cum ar trebui să procedeze un analist de business pentru a înțelege cerințele funcționale efective ale produsului?
Puțin "domain knowledge" în ceea ce privește organizarea de evenimente ar ajuta, deoarece ar evidenția faptul că, de regulă, sălile pot fi partajate prin pereți falși astfel încât numărul de incinte devine variabil, în funcție de context. Pentru simplitate, să presupunem că de această dată nu este cazul.
Totodată, la o primă vedere, ne putem da seama că sălile nu au aceeași capacitate, drept pentru care pot avea și prețuri diferite.
Prin urmare, "domain knowledge" ne ajută din nou, întrucât politicile de overbooking intră în discuție.
În orice caz, nu trebuie să facem presupuneri, ci să formulăm întrebări despre toate aceste situații, în momentul în care ne vin în minte!
Astfel, în exemplul nostru, i-am adresat clientului un set de întrebări și am concluzionat că numărul de săli este fix (nu există posibilitatea să partajăm sălile dinamic), nu există politici de overbooking și într-adevăr, sălile au prețuri diferite pe care clientul dorește să le modifice, și voila, o cerință ascunsă - managementul prețurilor sălilor!
Cine sunt actorii? Câțiva dintre ei sunt evidenți: persoanele care fac, confirmă și anulează rezervările și clienții clientului nostru care trebuie să poată închiria sălile.
Dar este într-adevăr așa? Haideți să-l întrebăm pe client și să vedem! În momentul în care începem să întrebăm, ce credeți - se pare că totuși clienții clientului nostru nu folosesc niciodată sistemul, deoarece acesta nu pune la dispoziție mijloace de plată electronică, drept urmare este unul dintre angajații clientului nostru cel care prin intermediul sistemului va asocia efectiv săli de conferință clienților finali.
Așa că, actorii propriu-ziși sunt persoanele care participă (prin intermediul rezervărilor) la evenimente și angajații clientului.
Este foarte important să dăm acestor actori nume adecvate folosind termeni din domeniu! Nu am dori să numim o persoană care participă la aceste evenimente - Chef - care ar fi un nume potrivit pentru o aplicație destinată restaurantelor. Așadar, dacă întrebăm clientul, vom concluziona că el de regulă se referă la aceste persoane ca fiind Participanți - iar un actor s-ar numi Participant.
În regulă! Acum să vedem ce nume ar trebui să dăm angajaților care fac asignarea sălilor de conferințe pentru Participanți? Tot clientul nostru ne spune că ar trebui să îi numim Angajați - prin urmare o persoană s-ar numi Angajat.
După ce punem totul cap la cap, încercăm să facem o diagramă simplă, care să descrie aceste fapte, vezi Fig. 1
Primul lucru pe care-l identificăm este lipsa parității! Avem un scenariu "Asignează sala Participantului" dar ne lipsește cel de "De-asignează sala de la Participant".
Dar, surpriză! Când îl întrebăm pe clientul nostru despre acest scenariu, el spune că nu înțelege la ce anume ne referim!
Acesta este un pas important pentru noi, însemnând că începem să avem o înțelegere mai profundă asupra domeniului! După ce întrebăm clientul despre cum anume gestionează asignările de săli pentru clienții care au plătit, ne spune că nu face aceasta așa cum am presupus!
El creează un Eveniment pentru clientul său, cu nume și descriere și asignează o sală la acel eveniment. Și mai mult, niciodată nu face o de-asignare de sală, ci pur și simplu șterge evenimentul din agendă, odată ce acesta a avut loc!
Astfel, noi deducem că evenimentul trebuie să aibă și o dată, deci n-ar avea sens să lăsăm angajații să facă asignări pentru un eveniment care s-a întâmplat deja!
Clientul ne confirmă imediat că avem dreptate!
Încă o încercare de a face diagrama use case, produce rezultatul din Fig. 2.
Încă nu suntem mulțumiți de problema anterioară de paritate. Dar fiind analiști de business experimentați știm un lucru: Utilizatorii fac greșeli! Așa că, folosind documente simple, clientul nostru nu era conștient de faptul că există într-adevăr o cerință funcțională ascunsă :"De-asignarea sălilor de la un eveniment" care se întâmplă implicit prin simpla suprascriere sau ștergere a unui rând dintr-un table din document. În orice caz, din moment ce construim o soluție IT dedicată, trebuie să existe explicit scenariile de utilizare prin care Angajații pot să corecteze asignările eronate la săli.
Așa că, insistăm și clientul acceptă. Prin urmare:
Bineînțeles, nu vrem să intrăm în astfel de detalii decât atunci când este cazul, dar totuși trebuie să analizăm și problema definirii tipurilor de utilizatori autorizați în sistem! E un subiect generic, dar de regulă trebuie să existe un Administrator care poate să asigneze roluri altor persoane.
Așadar, e destul de simplu să plasăm pe diagramă și Administratorul care asignează rolurile Administrator și Angajat celorlaltor persoane, iar întrebarea care apare acum este: Cum se creează Participanții? Aceasta, ca și altele de până acum, e o întrebare la care doar clientul poate răspunde (dar nu o va face de la sine, fiind datoria noastră de analiști de business să-l întrebăm!)
Desigur, clientul ne răspunde că oricine ar trebui să poată să participe!
Prin urmare, Administratorul nu ar trebui să asigneze și roluri de Participant, deoarece oricine are acest rol din start, vezi Fig. 4!
Uitându-ne la diagrama scenariilor de utilizare, încercăm să ne dăm seama dacă am acoperit toate cazurile bazate pe informațiile inițiale oferite de client și ceva ne lipsește - evidențierea absențelor pentru rezervările neanulate în prealabil!
Clientul vrea să știe dacă cineva a făcut o rezervare la care nu s-a prezentat, fără să fi anulat rezervarea în prealabil. Ce bine ar fi dacă am avea o formă de a diferenția persoanele care s-au prezentat de cele care nu s-au prezentat!
Acum observăm că scenariul "Confirmă rezervarea" e lipsit de sens. Ce anume înseamnă să confirmi o rezervare? Se confirmă că locul tău pe scaun e rezervat pentru tine și nu-l vei pierde sau se confirmă că tu vei participa efectiv?
Clientul ne clarifică că intenția acestui scenariu ar fi de a specifica că cineva chiar s-a prezentat la un eveniment dat. În acest caz scenariul ar trebui redenumit "Confirmă participarea" în loc de "Confirmă rezervarea" și ar trebui să aparțină Angajatului, nu Participantului. Confirmarea unei rezervări nu are sens deoarece rezervarea unui loc fie nu ar reuși, din cauză că nu sunt locuri disponibile, fie ar reuși, din cauză că nu există politici de overbooking care ar putea anula o rezervare aparent reușită.
Așadar, vom analiza dacă acum acoperim toate scenariile de utilizare cerute inițial de client:
Ceea ce ne lipsește este capacitatea cuiva, probabil a Angajatului, de a vedea un raport de ne-participare care să arate persoanele care nu s-au prezentat deși nu și-au anulat în prealabil rezervările.
Îl întrebăm pe client și el confirmă! Așadar, avem nevoie de un scenariu de utilizare și pentru asta!
Totodată, cum rămâne cu ștergerea unui eveniment? Ștergem cu adevărat un eveniment sau doar îl marcăm ca petrecut astfel încât să nu se mai poată face alte rezervări pentru el? Contează, deoarece ne-ștergerea unui eveniment ne permite să-l marcăm ca încheiat, dar în același timp ne permite să rulăm rapoarte pe acel eveniment (cum ar fi raportul de ne-participare).
Ca de obicei, întrebând clientul, acesta confirmă că de fapt dorește ca evenimentul să rămână în istoricul sistemului și că scenariul ar trebui într-adevăr să fie numit "Închidere eveniment". Fiind închis, nicio rezervare nu poate fi făcută pentru acel eveniment. Totodată, odată închis, evenimentul nu mai poate fi redeschis deoarece închiderea ar trebui făcută doar după ce evenimentul s-a petrecut efectiv! Luând aceasta în calcul, îl întrebăm dacă închiderea nu ar trebui cumva să fie o acțiune automată executată de sistem la data evenimentului (rețineți că am descoperit anterior că pe lângă client, nume și descriere, evenimentul are și o dată).
Clientul aprobă bucuros ideea noastră, și prin urmare:
În sfârșit se pare că avem diagrama completă, cu toate scenariile pe care clientul le-a cerut, împreună cu funcționalități de automatizare și administrare.
Dar, să nu uitam de cerința noastră ascunsă: Managementul prețurilor sălilor!
Întrebând clientul, acesta ne spune ca prețurile se modifică foarte rar și nu dorește momentan implementarea acestui scenariu de utilizare în sistem!
Prezentăm diagrama noastră completă clientului, care este foarte mulțumit de rezultat!
În concluzie, analiza scenariilor de utilizare este extrem de importantă în sine, indiferent de livrabilele sale, care, bineînțeles sunt și ele extrem de valoroase. Este evident de ce livrabilele sunt valoaroase pentru că ele reprezintă esența funcționalității și comportamentului sistemului, fiind utilizate de o gamă foarte diversă de persoane de la analistul de business, arhitect, utilizator și așa mai departe pentru orice etapă, de la descrierea sistemului până la validarea arhitecturii. Dar de ce este însuși actul de a realiza analiza scenariilor de utilizare important? Pentru că ne permite o descompunere metodică a cerințelor de nivel înalt într-o înțelegere profundă și tot mai îndetaliată a domeniului care ne ajută să descoperim adevăratele cerințe! Doar prin aplicarea unei analize amănunțite a scenariilor de utilizare putem spera să descoperim modelul domeniului (engl. Domain Model) care stă la baza contextului și să dezvoltăm un sistem IT aliniat la adevăratele cerințe de business!
de Larisa Goța
de Alpar Torok
