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

Definiţia cerinţei software

Elementul central în Analiză este, cu siguranţă, cerinţa software. În jurul cerinţelor se desfăşoară totul: cerinţele trebuie culese de la clienţi, cerinţele trebuie documentate, trebuie gestionate, dezvoltate, testate. În fond, modelul creat prin specificaţiile software este un model compus din cerinţe care trebuie să se transforme în produsul final.
Din acest motiv, vom insista asupra definiţiilor date cerinţelor software, poate chiar mai mult decât asupra definiţiilor Analizei software în sine.

În literatura de specialitate există o mulţime de definiţii. Toate încearcă însă să cuprindă următoarele elemente esenţiale: cerinţele sunt descrieri (specificaţii), într-un limbaj accesibil tuturor celor implicaţi a ceea ce un sistem informatic trebuie să poată acoperi, atât prin comportamente (behaviour) cât şi prin atribute ale sale.

Cea mai completă (şi, desigur, cea mai recunoscută) definiţie a cerinţei este dată de Institute of Electrical and Electronics Engineers (IEEE). Conform acestei organizaţii, prin standardul 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology, cerinţa software este definită astfel:

Cerinţa software este:

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;

3. un document – reprezentarea unei condiţii sau capabilităţi, aşa cum este descrisă la punctele 1 şi 2 de mai sus.


Mai înainte de a analiza această definiţie vom clarifica termenul "capabilitate" utilizat aici. Capabilităţile desemnează ceva ce un sistem software furnizează utilizatorilor, fie un anumit comportament fie un anumit atribut. Deşi termenul provine din englezescul "capability", limba română are aici privilegiul de a avea pentru capabilitate o descriere intuitivă: ea desemnează ceva ce un sistem este capabil să facă, ceva ce sistemul poate.

Printr-o capabilitate a unui sistem putem desemna fie un comportament fie un atribut. De pildă, o funcţionalitate de genul „sistemul validează formatul datei atunci când utilizatorul înregistrează factura în sistem” este un comportament al sistemului, în timp ce „poziţia unui buton pe ecran” este un atribut.
(Mai pe româneşte, în final, un câmp dintr-o bază de date sau o proprietate a unui obiect poate corespunde unui atribut al unei entităţi, în timp ce o metodă a unui obiect înseamnă comportament.)

Revenind la definiţia cerinţei, vom detalia pe scurt cele trei părţi ale definiţiei.

Prima parte, reprezintă punctul de vedere al utilizatorului. Centrul atenţiei este, la acest punct, utilizatorul care are nevoie ce ceva pentru a rezolva o problemă sau pentru a atinge un obiectiv. Această parte a definiţiei ne spune clar că dacă problema/obiectivul utilizatorului nu poate fi specificat, atunci cerinţa nu există. O cerinţă există atâta timp cât ea reprezintă soluţia pentru o problemă a utilizatorului.

A doua parte a definiţiei reprezintă punctul de vedere al dezvoltatorului. Aici "o condiţie sau capabilitate pe care un sistem trebuie să o realizeze" este ceea ce dezvoltatorul trebuie să realizeze. Aşa cum se poate vedea din definiţie, pentru el referinţa este un "document formal impus". Vom vedea în capitolele următoare că aici nu este vorba despre o descriere a funcţiilor aşa cum se dezvoltă ele în limbaj de programare ci sunt capabilităţi care pot fi înţelese, au o logică şi pot fi validate şi de către utilizatorul sistemului, fără ca acesta să ştie programare.

Partea a treia a definiţiei exprimă un punct de vedere comun, sau un punct de vedere general, o regulă de bază: primele două puncte de vedere nu pot exista dacă nu există documentul pe care ambele părţi să îl poată folosi ca referinţă. Dacă documentul nu există, cele două puncte de vedere, precum şi evoluţia lor în timp nu au un element comun palpabil şi fără echivoc, o referinţă acceptabilă.
Aşadar, conform punctului 3 din definiţia cerinţei, o cerinţă care nu este documentată nu există.

Observăm, din definiţia de mai sus, că cerinţa, privită din partea utilizatorului sistemului este ceva util pentru rezolvarea unei probleme, în timp ce, pentru dezvoltator cerinţa este ceva ce el trebuie să dezvolte, conform specificaţiei. Ca urmare, cerinţa trebuie exprimată în aşa fel încât să poată fi interpretată fără dubii de ambele părţi, pentru că ea este destinată în egală măsură ambelor părţi.
Pe de o parte, pentru utilizator este importantă rezolvarea propriilor probleme, fără ca detaliile tehnice ce ţin de rezolvarea lor să fie relevante. De cealaltă parte, dezvoltatorul are nevoie de o referinţă pentru a şti ce să dezvolte, în timp ce problemele utilizatorului au relevanţă mai scăzută. Aici, la mijloc între cei doi se situează Analistul software şi produsul munci sale: cerinţa software – un document care arată utilizatorului soluţia problemei lui iar dezvoltatorului ce trebuie să dezvolte.

Cerinţele software, între PROBLEMĂ şi SOLUŢIE

Aşa cum se vede în figura de mai sus, în cadrul evoluţiei de la Problemă la Soluţie, specificarea cerinţei este pasul intermediar: ea este, pentru utilizator, soluţia vizată a problemei lui, iar pentru dezvoltator este problema pe care o are de rezolvat.

După cum vom vedea şi în continuare, cerinţele exprimate în limbaj inteligibil, sub forma documentelor de specificaţii software, agreate de către client şi de către echipa de dezvoltare, constituie referinţa de bază pentru toţi cei implicaţi în proiectele software: pentru project manageri, în determinarea şi urmărirea task-urilor sau pentru inginerii de testare, în realizarea testelor.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Modele teoretice de abordare a problemelor. Abordarea iterativă
Articolul următor:  Nivelurile cerinţelor



  


  Adauga un comentariuSpune-ti parerea despre acest articol!