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

Caracteristicile cerinţelor software

Atunci când sunteţi în situaţia de a culege, analiza şi specifica cerinţe (să zicem, de exemplu atunci când sunteţi analist software) trebuie să aveţi în vedere că, indiferent de forma în care o specificaţi, în limbaj natural, în UML sau în orice alt limbaj, sub formă de use case-uri sau full text, indiferent de tipul lor, cerinţele trebuie să aibă anumite caracteristici care le fac să fie cerinţe adevărate, corect specificate şi posibil de realizat, în parametrii bugetari şi de calitate determinaţi.

Înainte de a trece efectiv la enunţarea acestor caracteristici, vă invit să vă gândiţi la cerinţă aşa cum este definită în capitolul Definiţia cerinţei software:
1. o condiţie sau capabilitate necesar a fi îndeplinită de către un sistem, pentru ca un utilizator să poată rezolva o anumită problemă sau să atingă un anumit obiectiv; 2. o condiţie sau capabilitate pe care un sistem trebuie să o realizeze sau să o posede pentru a satisface un contract, standard, specificaţie sau alt document formal impus.

Aşadar, privită dintr-o parte cerinţa se vede ca o problemă a unui client, privită din cealaltă parte este o soluţie furnizată de un anumit sistem. De aceste două faţete ale ei depind caracteristicile de care vorbim în continuare.


Aceste caracteristici sunt, în principal, următoarele (depinzând de autor lista poate fi mai mare sau mai mică dar cele esenţiale sunt acestea):

1. Necesară

O cerinţă există dacă şi numai dacă este necesară. Amintind de prima parte a definiţiei de mai sus, putem spune că cerinţa există dacă există o problemă reală de la care porneşte. În caz contrar cerinţa nu există.

Această caracteristică este extrem de utilă pentru managementul cerinţelor, problema din spatele cerinţei fiind, în mod necesar, o frunză din decompoziţia problemei mari a proiectului (mai multe detalii în capitolul Nivelurile cerinţelor).

Doar pe baza problemei acesteia vom putea şti dacă o cerinţă se încadrează sau nu în proiect.
Pentru a demonstra că o cerinţă este necesară este nevoie de existenţa unei legături către cerinţele de pe nivelul superior (mai multe detalii în capitolul Nivelurile cerinţelor).

2. Corectă

Atunci când spunem că o cerinţă trebuie să fie corectă, ne apropiem deja de a doua parte a definiţiei de mai sus (sau mai degrabă le cuprindem pe amândouă). O cerinţă este corectă dacă faţeta denumită soluţie este, nimic altceva decât soluţia corectă la problema dată.

De exemplu, un use case care este gândit pentru realizarea unui anumit task este corect dacă înşiruirea paşilor descrişi conduce la realizarea, fără dubii, a task-ului.În caz contrar cerinţa descrisă astfel nu este corectă.

În general pentru a determina corectitudinea unei cerinţe este necesar să se facă referire la cerinţele de pe nivelul superior (mai multe detalii în capitolul Nivelurile cerinţelor).




3. Completă

O cerinţă este completă dacă reprezintă o soluţie completă pentru rezolvarea completă a problemei. Deşi cazurile de incompletitudine sunt greu de descoperit, organizarea de review-uri formale cu participarea oamenilor tehnici din echipa de dezvoltare, de obicei dă rezultate.

4. Consistentă

O cerinţă este considerată consistentă dacă nu intră în contradicţie cu altă cerinţă. De exemplu, următoarele cerinţe sunt inconsistente:
- autovehiculul se va deplasa cu viteza maximă de 100 km/h;
- autovehiculul va parcurge 200 de km în maximum o oră.

5. Verificabilă

O cerinţă este verificabilă (testabilă) dacă permite realizarea validarea fără echivoc a soluţionării ei prin măsurare sau testare. De exemplu, „sistemul va permite derularea optimă a activităţii”, „timpul de răspuns va fi cât mai mic cu putinţă” sau „sistemul va putea fi accesat de un număr mare de utilizatori simultan” sunt cerinţe care nu pot fi verificate în mod cert, fără dubii.
Oricând se poate pune întrebarea ce înseamnă derularea optimă a activităţii, când se poate spune că ţinta a fost atinsă?

6. Clară (fără ambiguităţi)

O cerinţă poate fi considerată lipsită de ambiguităţi atunci când poate fi interpretată într-un singur fel. Dacă mai mulţi cititori înţeleg lucruri diferite atunci cerinţa este ambiguă.

Pentru a ţine sub control fenomenul existenţei ambiguităţilor (axioma A4, care spune că niciodată oamenii implicaţi în proiect nu sunt perfecţi, ne spune că ele sunt inerente) trebuie organizate review-uri ale specificaţiei. De asemenea, specificaţiile vor fi folosite ca sursă primară pentru crearea planurilor de teste şi a manualului de utilizare.

7. Trasabilă

Trasabilitatea se referă la posibilitatea de a reface traseul pe care o cerinţă a luat naştere, pornind de la solicitarea iniţială a unui reprezentant al clientului. Acest mod de abordare asigură informaţia care justifică existenţa sau nu a cerinţei, precum şi posibilitatea de a reface drumul pe care a apărut o cerinţă, atunci când apar dubii asupra acesteia, asupra sursei sau asupra raţiunii ei.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Cerinţele nefuncţionale
Articolul următor:  Dezvoltarea şi Managementul cerinţelor



  


  Adauga un comentariuSpune-ti parerea despre acest articol!