in-theory.info

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.

Adrian Ionescu





Colecția:  🏅 Analiza cerinţelor software

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



👍 Topul celor mai citite articole

1. Analiza cerinţelor software. Introducere
Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, şefi de proiec...

2. Despre Analiza cerinţelor
Analiza cerinţelor software (pe care o vom numi în continuare Analiza de business sau Analiză software) este aceea dintre disciplinele existente î...

3. Axiomele dezvoltării software
Adevăruri ale dezvoltării software care susțin nevoia Analizei cerințelor. Unul dintre ele este: "Întotdeauna, într-un proiect software apar si...

4. Ciclul de dezvoltare al produsului software (SDLC)
Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chi...

5. Ciclul de dezvoltare iterativ
Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, ca...

6. Locul Analizei în proiectul de dezvoltare software
Analiza Software este o disciplină care se află în relaţie de dependenţă cu celelalte discipline din proiect. Concret, task-urile din proiectul ...

7. Modele teoretice de abordare a problemelor. Decompoziţia
Modalităţile teoretice de abordare a problemelor sunt universale şi pot fi folosite oriunde însă pentru domeniul nostru, este important să le co...

8. Modele teoretice de abordare a problemelor. Sinteza
Sinteza este o modalitate, prin care, din manifestări punctuale se determină problema reală. Cel mai simplu şi clar exemplu este acela al mediculu...

9. Modele teoretice de abordare a problemelor. Crearea unui trunchi de bază
De foarte multe ori, în viaţa reală, o problemă nu poate fi punctată decât cu un efort substanţial sau chiar deloc. Pur şi simplu, obţinerea ...

10. Modele teoretice de abordare a problemelor. Abordarea iterativă
Metoda iterativă presupune rezolvarea unei probleme cunoscute printr-o abordare iterativă, la fiecare iteraţie făcând un pas către rezolvarea pr...



📜 Căutare după etichetă:

Analiza Business
Baze de date
C#
Cerințe software
CSS
Dictionar IT
Glossary
HTML
Information Theory
Information Theory Basics
MySQL
PHP
Riscuri
SDLC
Specificații software
SQL
UML