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 altcineva
o 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 oportunitate
Dintre 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 contractului
2) dupa semnarea contractului - cand de multe ori se realizeaza o analiza SWOT

S | W
puncte tari | puncte slabe
--------------------------------------------------
O | T
Oportunitati | pericole( threats)

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

Cerintele trebuie sa se transforme in specificatii ale aplicatiei

Exista 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 de

a) 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 legale
e) reguli nescrise
Ar 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 utilizare
Raportul de analiza trebuie sa contina cazuri de utilizare si pe rolurile
atribuite
IN DEFINIREA CAZURILOR DE UTILIZARE TREBUIE VAZUTE SI
CAZURILE DE ESEC SAU PARTICULARE
SPECIFICAREA 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 utilizatorul
EXEMPLU: 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