in-theory.info

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.

Adrian Ionescu





Colecția:  🏅 Analiza cerinţelor software

Articolul precedent:  Modele teoretice de abordare a problemelor. Abordarea iterativă
Articolul următor:  Nivelurile 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