techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Nivelurile cerinţelor

În capitolul Modele teoretice de abordare a problemelor prezentam un exemplu ipotetic al unei companii XYZ, al cărei director se plânge că nu îşi poate planifica corect aprovizionarea şi că pierde foarte mulţi bani din cauză că nu are întotdeauna suficientă marfă atunci când apar oportunităţi de vânzare sau, invers, pierde bani pentru că i se alterează cantităţi însemnate de marfă în stoc din cauză că s-a achiziţionat mai mult decât era necesar.

Prin descompunere, problema era spartă în sub-probleme astfel:
- sub-problema 1: cunoaşterea necesarului real:
    - sub-problema 1.1: cunoaşterea vânzărilor din trecut;
    - sub-problema 1.2: cunoaşterea comenzilor curente de la clienţi;
    - sub-problema 1.3: cunoaşterea stocului curent.
- sub-problema 2: urmărirea achiziţiilor astfel încât să se achiziţioneze exact atâta cât a decis că este necesarul real:
    - sub-problema 2.1: cunoaşterea cantităţilor deja comandate la furnizori;
    - sub-problema 2.2: determinarea diferenţelor dintre necesarul calculat şi comenzile trimise la furnizori.

Mergând cu decompoziţia încă un nivel mai jos constatăm că suntem deja în situaţia de a da soluţii destul de concrete pentru unele dintre problemele din structură. Sigur că soluţia finală şi cât se poate de concretă este software-ul însuşi, dar fiecare pas în detaliere înseamnă un nou pas către soluţia finală.

Cu acest nou pas vom obţine o structură precum cea din figura de mai jos:



Astfel sub-problema 1.1 Cunoaşterea vânzărilor din trecut se transformă în: Introducerea facturilor de vânzare în Sistem şi Generare raport de vânzări din Sistem (presupunem că rezolvând aceste două chestiuni se rezolvă complet problema cunoaşterii vânzărilor din trecut, chiar dacă în realitate lucrurile ar putea să fie mai complicate).

De la acest nivel de detaliere e clar că anumite probleme, şi anume cele de pe ultimul nivel de detaliere, nu mai sunt probleme pe care directorul companiei XYZ, sau chiar managerul de achiziţii, să le rezolve nemijlocit ci sunt task-uri adresate altui nivel de utilizatori.
Astfel, dacă task-ul determinării necesarului real şi al urmăririi achiziţiilor este destinat nivelului managerial, task-ul Introducerea facturilor de vânzare în Sistem este adresat unui alt utilizator, implicat direct în derularea business-ului.

Noul nivel adăugat însemnă nivelul la care este vizibilă interacţiunea dintre utilizatori şi Sistem. Pentru "Introducerea comenzilor în sistem" este evident că este necesară o funcţionalitate în Sistem, aferentă acestei probleme. În fond, pe acest nivel ajungem la cerinţele software pure, cele care se supun 100% definiţiei date la capitolul referitor la definiţia cerinţei: din punctul de vedere al utilizatorului trebuie rezolvat task-ul introducerii facturii în Sistem iar din punctul de vedere al dezvoltatorului trebuie dezvoltată funcţionalitatea aferentă.

Dacă ar fi să se detalieze din nou chestiunea „Introducerii comenzilor în sistem”, dar propunându-ne să ne modelăm deja viitorul sistem informatic (să ne imaginăm un flux complet de lucru cu Sistemul!) ar rezulta următoarele funcţionalităţi pretinse Sistemului: adăugare factură, modificare factură, ştergere/anulare factură:



Acesta este nivelul la care granularitatea maximă a problemelor din business-ul real ating nivelul la care poate fi conceput un sistem informatic: adaugă, calculează, şterge, modifică, selectează, compară etc.

Privind în sens invers, de jos în sus, aceste funcţionalităţi sunt acelea pe care utilizatorul, într-un flux de lucru cu Sistemul, le utilizează pentru rezolvarea task-urilor sale. Apoi, pe un nivel mai sus, din task-urile utilizatorilor sunt rezolvate problemele de business.


Prin urmare, se pot stabili următoarele niveluri ale cerinţelor software [1]:

A. Cerinţe de business: acestea sunt cerinţele de pe cel mai înalt nivel şi sunt obiectivele (sau problemele) de nivel înalt ale clientului. Aşa cum vom vedea în continuare aceste cerinţe sunt de obicei descrise într-un document denumit Vision & Scope.

B. Cerinţe utilizator: pe acest nivel sunt task-urile pe care utilizatorul le va putea îndeplini utilizând produsul software. Aceste cerinţe sunt specificate de obicei sub formă de use case-uri.

C. Cerinţe funcţionale: sunt cerinţele adresate direct viitorului Sistem, funcţionalităţile care trebuie dezvoltate pentru ca utilizatorii să îşi poată îndeplini task-urile. Acest nivel este nivelul cel mai apropiat de designul Sistemului.



În figura de mai jos se pot vedea atât nivelurile cerinţelor, cât şi nivelurile din business care le generează, precum şi documentele de specificaţii utilizate în general pentru acel nivel de cerinţe (săgeţile cu vârful în jos înseamnă de obicei descompunere):



Trebuie precizat că documentele de specificaţii au denumiri diferite, în funcţie de metodologie. De exemplu, în anumite metodologii documentul Vision & Scope este denumit Vision sau Specificaţie de business.

De asemenea, este important de precizat că decompoziţia prezentată în exemplul de mai sus are rol teoretic şi nu este întotdeauna un mod de lucru recomandat. Deşi este nu doar inevitabilă, ci şi normală, utilizarea descompunerii în Analiză, ea trebuie completată cu (sau derulată împreună cu) analiza pe fluxuri, concretizată prin utilizarea use case-urilor. În exemplul de mai sus, cerinţele corespunzătoare unor task-uri concrete trebuie detaliate şi analizate sub formă de use case-uri.
Pentru mai multe detalii vă recomand capitolul dedicat use case-urilor.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Definiţia cerinţei software
Articolul următor:  Unde se termină cerinţele clientului şi unde începe designul?



  


  Adauga un comentariuSpune-ti parerea despre acest articol!