Analiza de business

Etapa principala este colectarea cerintelor. Exista anumite grupuri de interese(stackeholderi) care au niste cerinte.Stackeholderi externi

beneficiarii clienti utilizatori; terte parti ( organizatii care pot folosi aplicatia noastra pentru a furniza anumine

date, concurenta interni ce pot fi echipa de management, echipa de lucru

Cerintele sunt enumerari obtinute in mod direct – de la sursa ( ex prin interviu clasic - cu o singura persoana sau prin sesiuni colective )

Interviul e o metoda sincrona, dar poate sa fie si asincrona( prin chestionare) indirect ex:

o rapoarte, ai acces la produse oferite de altcinevao aplicatii similare ( demouri de ex) si cand avem acces la evaluari independente

sau facem noi evaluari propii ( CE E BINE SI CE NU?)

Analiza de oportunitateDintre toate cerintele care sunt importante?exemple: Analiza Parento ierarhizare in 80% 20% ( realizare primelor 80% din cerinte iti da un castig destul de mare. impactul celorlalte 20% cerinte este mic Analiza cost-beneficiu ( cost mic- beneficiu mare)

Analiza de business se realizeaza in 2 etape:1) inainte de semnarea contractului2) dupa semnarea contractului - cand de multe ori se realizeaza o analiza SWOT

S | Wpuncte tari | puncte slabe--------------------------------------------------O | TOportunitati | pericole( threats)

cee ce va fi pe prima coloana vor fi elemenete in favoarea aplicatiei, iar in coloana din stanga sunt riscurilepe a doua linie o sa apara elemente din afara organizatiei

Cerintele trebuie sa se transforme in specificatii ale aplicatieiExista 2 tipuri de cerinte:1) functionale - ce trebuie sa faca aplicatia? ( cantitativ)2) nefunctionale - cum trebuie sa se comporte aplicatia? ( calitativ)

Exemple de cerinte nefuntionale legate dea) calitatea aplicatiei:

portabilitate usability ( usurinta de utilizare, rapiditatea de a executa comenzile) disponibilitate (hard, functionarea anumitor servicii) securitatea performanta( timp, corectitudine, validarea datelor)

scalabilitate( numarul de uitlizatori, dezvoltare sau adaugare de module noi ) ce e inclusa in Modifiability

b) cerinte de business( timpul de finalizare a aplicatiei => costuri, buget)c) cerinte tehnologice( ex aplicatia trebuie sa fie pe o platforma, ce tip tip de alte programe folosesc utilizatorii, aplicatia sa se integreze cu altele sau sa semene cu altele; pot fi si cerinte ale echipei de a folosi o anumita tehnologie)d) prevederi legalee) reguli nescriseAr fi bine sa abordam la proiect si cerintele nefunctionale( hm...dar nu cred ca la etapa asta zic eu..de fapt nu sunt prea sigura)

Specificarea cerintelor:Specificarea cerintelor functionale - e sarcina echipei de analiza

- sub forma unor liste ierarhice intr-un mod exhaustiv, neredundant SAU

- sub forma unor cazuri de utilizareRaportul de analiza trebuie sa contina cazuri de utilizare si pe rolurile

atribuiteIN DEFINIREA CAZURILOR DE UTILIZARE TREBUIE VAZUTE SI

CAZURILE DE ESEC SAU PARTICULARESPECIFICAREA CERINTELOR NEFUNCTIONALE nu intra la analiza cerintelor de business - ele sunt pentru echipa de analiza tehnica sau proiectantul

Observatii!1) Pentru fiecare caz de utilizare -> rol -> intentia unui utilizator

la final => ceea ce doreste utilizatorulEXEMPLU: autentificarea unui utilizator NU e caz de utilizare, ci mai degraba un trigger

2) cazurile de uilizare sunt non-tehnice!!! nu fac referinta la interfata, trebuie tratate din punct de vedere functional