Noi trebuie sa transpunem o nevoie care vine cu mai multe cerinte intr-o solutie care poate fi o

platforma, o aplicatie,un sistem, tooluri pentru dezvoltatori- acestea sunt solutii software care au aparut
in urma unei nevoi.
Ex- calendarul- nevoia de organizare.
Nevoia intotdeauna o sa apartina unui client, iar solutia o sa apartina intotdeauna echipei de
dezvoltare.In metodologia scrum ea se numeste developers.
Din echipa de dezvoltare fac parte si testerii si unul sau mai multi BA,etc.
Dezvoltatorii, testerii,oamenii tehnici simt nevoia sa li se spuna lucrurile mai straight-forward→ acesta
fiind motivul pentru care a aparut acest rol de bussiness analist .
In mod normal BA face parte din echipa de dezvoltare,dar in practica el este angajat de compania care
creeaza aceasta echipa de dezvoltare sa ca creeze solutii. In realitate, BA face parte si din echipa
clientului . In 90% din cazuri,desi clientul vine cu nevoia, el nu stie cu adevarat ce isi doreste .
De aceea la inceput de proiect trebuie sa ii punem suficient de multe intrebari de ce clientului si sa il
ajutam pentru a-si da seama cu adevarat de ce are nevoie.
Exista niste tehnici pe care le folosim in a-l ajuta pe client sa isi dea seama ce vrea cu adevarat si cum
reusim sa modelam cerintele acestea pentru a transmite mai departe echipei de dezvoltare ca sa fie
implementate. - Se numesc tehnici de elicitation.

Tipurile de companii unde avem aceste produse: Firme de consultanta (Deloitte Digital) care angajeaza
specialisti de la BA la dezvoltatori etc si creeaza echipe care vor lucra pentru un client extern.
Ex: vine un client X si spune ca vrea sa isi vanda produsele pe o platforma,iar Deloitte vine cu echipa
de mai sus pentru a crea platforma.

Varianta a doua- varianta de companie de produs unde compania de produs isi angajeaza specialistii
intern (nu contacteaza o companie de consultanta si vrea sa gestioneze totul intern): firmele care incep
ca start-upuri.

Avantaje si dezavantaje: in start-up: nu facem un singur lucru si o sa facem lucrurile cand e nevoie si
ce e nevoie.

Nu facem lucrurile ca la carte ca in firmele de consultanta unde lucrurile sun rafinate de ani de zile si
procesele sunt foarte bine puse la punct.
Intr-o firma de consultanta avem un set de responsabilitati clar.

AS IS-- trec si de pe slide

AS IS este un cadru in care descriem procesele actuale in care se afla proiectul pe care urmeaza sa il
dezvoltam

De ce e important: Ex de mai sus cu clientul care vrea sa isi vanda produsele pe o platforma online:
-Este foarte important sa intelegem cum se intampla lucrurile in prezent pentru ca in momentul in care
mergem sa dezvoltam o varianta digitala a businesului clientului nostru sa semene destul de mult cu
ceea ce se intampla in AS IS pentru ca noi nu cream aceasta platforma pentru clientul nostru,ci pentru
oameni care urmeaza sa foloseasca aplicatia.
Este foarte important ca noi sa intelegem care este comportamentul curent pentru ca noi sa cream
solutie care sa nu fie departe de ceea ce se intampla in momentul de fata.

De retinut: O aplicatie,un sistem,o platforma,etc- or sa fie de succes in momentul in care pe end-userul

nostru(utilizatorul final) o sa il punem sa gandeasca cat mai putin. Ca sa facem asta trebuie sa ne
folosim de experientele lui anterioare pe care le intelege deja.
EX: Plecam de la acest AS IS care nu este altceva decat un document in care noi incercam sa redactam
cat mai pe intelesul nostru sau al clientului ce se intampla in momentul de fata in bussinessul lui ca mai
departe sa definim nevoia sa reusim dupa sa cream acea solutie care sa nu fie departe de cum se
intampla lucrurile in prezent.

Acest AS IS trebuie sa se duca in TO BE care va descrie cum o sa arate solutia pe care noi vrem sa o
implementam. Varianta cea mai simpla de a le vizualiza pe acest AS is si TO BE este o diagrama in
care punem step by step ce se intampla in procesul in care un client (un end-user) isi atinge obiectivul
(in cazul de mai devreme,de a-si cumpara un anumit produs pe care il vinde clientul care ne-a angajat.

Rolul BA- vine la el un client care poate fi o familie,o firma care vrea sa isi construiasca o cladire iar
primul pas pe care il face arhitectul in astfel de context- trebuie sa afle cum vrea sa fie cladirea sau casa
respectiva si motivele pentru care isi doreste acest lucru.
Pe baza experientei argitectului si a ceea ce au mai facut si altii si de asemenea si a cerintelor clientului
vine cu un plan- sa arate asa, cum sa fie dormitoarele- si vine din nou se intalneste cu familia si el
prezinta ceea ce are ca un prim output dupa discutia pe care am mai avut-o. Dupa care lucrurile vin cu
feedback

Stakeholderi

Sunt parti interesate de produsul nostru,dar sunt oamenii catre care clientul merge ca sa adune cerinte si
ulterior sa valideze diverse lucruri.

Daca ei sunt gestionati de client- de ce sunt imp pt noi ca BA?

R: Pt ca o sg pers in pers clientului nu poate sa le vada pe toate.

PO- poate sa fie direct pers car vine cu banii si nevoia(pers care vrea sa faca acea aplicatie sau acel
magazin online,dar exista si varianta in care "sponsorul" deleaga o pers care sa se ocupe si sa fie owner
de produs,sa gestioneze aceasta nevoie,toate cerintele care vin de la stakeholderi.
PO- este legatura noastra directa cu clientul ca BA
PO- este de partea clientului,
BA- face parte din developers

Categorii de stakeholderi:
Clientii - cei mai importanti- cei care urmeaza sa foloseasca aplicatia,nu la clientul care plateste sa o
faca. Utilizatori finali
Angajatii - cream si o zona de administrare pe care o vor folosi si angajatii companiei.
Investitorii- investesc in aplicatie
Suppliers- Furnizori pt ca nu intotdeauna proiectele sunt stand-alone -ne mai integram cu diversi (ex-
vanzarea de produse = Fan curier)
Comunitatile- trebuie sa mergem sa strangem informatii de acolo pentru ca acolo deja se formeaza
pareri de care avem nevoie
Gouvernment- sa ne asiguram ca totul este in concordanta cu standardele legale
Chiar daca Stakeholderii sunt gestionati de PO , ei sunt f importanti si pentru noi ca BA pentru ca pt
PO este destul de greu sa aiba in vedere toate lucrurile si este important sa ii cunoastem sa mergem
catre ei.

Analiza Stakeholderilor:

Realizam o lista cu cei mai importanti stakeholderi si care sunt interesele lor, incercam sa le definim
puterea si influenta
Realitatea din teren: cu cine sa ne purtam cu manusi,cui trebuie sa ii dam mai multa importanta
Trebuie sa stim sa punem intrebarile potrivite,sa gestionam oamenii
-sa gasim raspunsurile potrivite pt fiecare stakeholder
Incercam sa anticipam cat mai multe riscuri
Firmele de consultanta- clientul este extern si el vine cu bugetul si cu o nevoie sau exista varianta in
care clientul in agnajeaza oamenii proprii

Trebuie sa il facem constient de faptul ca nu cel care vine cu nevoia/banii foloseste aplicatia

Alta varianta de analiza a stakeholderilor: RACI matrix

Diferenta dintre Responsible si accountable:
R: pers care face lucruri,le efectueaza
A: pers care raspunde ca a fost facut acel lucru de pers responsabila

Noi ca BA trebuie sa ne ducem deja catre unele cerinte care sunt similare si care sunt de fapt
competitia noastra.

In definirea cerintelor se foloseste conceptul de SMART

Specific-
Measurable-
Achievable-
Realistic-
Timely-limitate intr-o perioada de timp ( din slide)

MVP - Minimum Viable Product

In procesul de adunare de cerinte nu punem limitari in momentul in care ii intrebam pe stakeholderi

ce vor,iar in momentul in care am aflat ce vor impreuna cu PO-ul va trebui sa stabilim acel minim de
functionalitati pentru care produsul meu sa functioneze.
Acest MVP il ajuta mai mult pe client sa isi dea seama ca are un nucleu de functionalitati care ii
produce valoare si valideaza ca acea nevoie prinde contur.
La inceputul unui proiect va trebui sa selectam din toata lista cu nevoile stakeholderilor acest MVP

Criterii functionale din slide

Skilluri pe care le imbunatatim in timp:
Slide

Coordonare
Prezentari pentru a expune rezultatele analizei pe care am facut-o( sa gasim acel ceva pentru ca oamenii sa ne
asculte si sa interactioneze cu noi)
Organizare(office,Jira, Confluence)

Atlassian - o platforma care se foloseste in companii pt gestionarea taskurilor, management de documentatie.

Aici exista mai multe aplicatii
Jira- management de taskuri in dezvoltarea softwarului
Confluence - pentru organizarea de documentatie pe care noi o vom scrie(slide)

JIRA:

Roadmap: Cele cu mov sunt modulele pe care noi in Jira le numim Epice.
E un tip de task care e un fel de parinte care are mai multi copii.
Pot sa vad modulele aplicatiei pe un timeline
Fiecare modul in parte este spart in taskuri mai mici : USER STORY : tichete care descriu ceea ce urmeaza sa fie
implementat
Backlog: o lista cu toate lucrurile pe care trebuie sa le implementez pt produsul meu
Board: Tichetele din backlog po sa le vad in functie de statusul lor

Confluence:

e caun drive pt proiectul nostru, stakeholders analysis,, requirements,diagrame

Lucrurile sunt conectate intre ele

AGILE vs WATERFALL

Doua mari abordari in implementarea proiectelor-modul in care noi facem management pentru cum dezvoltam
un proiect.

WATERFALL (CASCADA) inseamna ca etapele prin care trecem noi proiectul se intampla progresiv una dupa
alta si nu ne mai intoarcem la un modul la care am lucrat deja. La final intram in zona de deplyment care
inseamna ca ceea ce am implementat noi pe un mediu de test va fi pus pe un mediu de productie unde
utilizatorii finali sa poata sa aiba acces.
Este o tehnica mai invechita si astazi de foloseste in proiectele mai mici

AGILE
In proiectele complexe si mari o sa vreau intotdeauna sa am iteratii mai mici care sa imi valideze mie si sa imi
dea voie sa ma adaptez pe parcurs la schimbari
Imi aleg sa lucrez la o parte( fac requirements analysis,design ,implementez,testez si fac deploy) ii arat PO -ului
meu la ce am lucrat, el poate sa ajusteze pe parcurs. Asa ii castigam increderea clientului pentru ca ii aratam ca
ceea ce lucram este ceea ce isi doreste el si asa lucram la un alt modul pana in pucntul final

In antiteza cu Waterfall, rezultatul final nu o sa il mai gasesc o singura data la finalul proiectului, ci o sa vina in
outcome-uri la fiecare final de iteratie si in final o sa fie suma outcomurilor pe care le am la fiecare final de
iteratie

Iteratii- SPRINTURI( SLIDE) ====

Sub metodologia AGILE avem mai multe frameworkuri: SCRUM, KANBAN, safe- AVEM MAI MULTE ECHIPE
scrum CARE LUCREAZA LA UN PRODUS

SCRUM FRAMEWORK

Roluri:
SCRUM TEAM:
PO - Reprezentantul clientului
Developers - echipa de dezvoltare
SCRUM Master- servant al echipei SCRUM TEAM el trebuie sa se asigure ca metodologia de lucru este
indeplinita,el ii ajuta pe oameni sa ia decizii.
In practica,palaria o poarta ori un PO ori un Business Analyst

1. Product backlog
Prima sedinta in cadrul echipei pe care o numim Sprint Planning- sedinta in care pe baza estimarilor si prioritati
ne alegem setul de functionalitati la care ne asumam ca o sa lucram in urmatorul sprint
ari008

Easy retro- retospectiva

TEHNICI DE ELICITARE- 00010 24 MIN

Dupa ce adunam cerintele de la Stakeholderi si PO ne facem in cap clar care sunt modulele si avem pasrte de
mai multe discutii pana sa le facem in Jira. Acest proces se numeste Elicitation

Elicitation este procesul in care eu adun cerinte, eu ca BA.

In acest proces e un lucru pe care foarte putini oameni il fac si tin cont de el: focusul nostru trebuie sa fie sa
rezolvam propblema corecta in detrimentul rezolvarii corecte a unei probleme oarecare.
Tendinta e de a gasi o problema si a-i gasi o solutie.

slide() pasi si documente

Tehnici de elicitare slide:

DIAGRAME

Functional decomposition- scopul este de a imparti in module si apoi dand titluri sugestive in functionalitatile
pe care le are modulul respectiv.
Doua situatii:
1. La inceput de proiect si vrem sa proiectam cum va arata
2. Exista deja o aplicatie si facem asta pt a intelege mai bine ce e in aplicatia respectiva(adaugam,schimbam
etc)

UML Diagrams

UML= Un limbaj pe care noi il folosim ca sa realizam aceste diagrame, este un standard care ne ajuta sa le
realizam
2 categ:

1.Diagrame care sunt menite sa descrie stuctura aplicatiei slide

2. Diagrame de comportament maj pe care le folosim si ne arata cum se comporta aplicatia:

cele mai imp:

STATE MACHINE DIAGRAM- de stare = ma ajuta sa vad care este comportamentul

USECASE DIAGRAM
ACTIVITY DIAGRAM

Slide:clase,entitati