Disciplină: Proiectarea Sistemelor Informatice de Gestiune

Capitolul nr. 3: Documentarea cerințelor software

Documentul cerințelor software și clasificarea cerințelor software

• Generalități privind cerințele software

• Cerințe de utlizare
• Cerințe de sitem
Cuprinsul secvenței • Cerințe funționale
• Cerințe non-funcționale
• Cerințe de domeniu
• Documentul cerințelor software

• Obiective ale acestui capitol sunt introducerea noțiunilor legate de

determinarea cerințelor software şi explicarea diferitelor moduri de
exprimare a acestor cerinţe.
• După ce veți citi acest capitol, veți:
Obiectivele secvenței • înţelege conceptele de cerinţele ale utilizatorilor şi cerințe de sistem
şi de ce aceste cerinţe ar trebui să fie scrise în moduri diferite;
• înţelege diferenţele dintre cerințele funcţionale şi non-funcţionale;
• înţelege modul în care cerinţe pot fi organizate într-un document al
cerințelor software.

• cerințe de sistem, cerințe non-funcționale, cerințe funcționale, cerințe

Cuvinte cheie de domeniu, documentul cerințelor software

31
3. Documentarea cerințelor software
3.1. Generalități privind cerințele software

Cerințele unui sistem sunt descrieri ale serviciilor oferite de acesta şi ale constrângerilor sale
operaționale. Aceste cerințe reflectă nevoile clienților pentru un sistem care ajută la
rezolvarea unor probleme cum ar fi controlul unui dispozitiv, plasarea unei comenzi sau
găsirea unor informații. Procesul prin care se găsesc, analizează, documentează şi se verifică
serviciile şi constrângerile este denumit ingineria cerințelor software (ICS).
Termenul “Cerinţă” nu este utilizat în industria IT într-un mod consistent. În unele cazuri, o
cerință este pur şi simplu un nivel înalt, abstract de definire a unui serviciu pe care sistemul ar trebui să-l ofere
sau o constrângere a sistemului. Există două puncte de vedere diferite. Pe de o parte cerințele trebuie să fie
scrise astfel încât cei care licitează pentru dezvoltarea aplicației să poată oferi diferite moduri de satisfacere a
clientului. Odată ce un contract a fost atribuit, contractantul trebuie să scrie un o definiție a sistemului pentru
client, oferind mai multe detalii, astfel încât clientul sa poată înțelege şi să poată valida ceea ce programul
informatic va face efectiv. Ambele aceste documente pot fi numite „document al cerințelor”. Unele dintre
problemele care apar în timpul procesului de inginerie a cerințelor sunt un rezultat al lipsei unei separații clare
între aceste niveluri diferite de descriere. Pentru a distinge între cele două vom folosi în continuare termenul
„cerințe de utilizare” să desemnăm cerințele abstracte de nivel înalt şi termenul „cerințe de sistem” pentru a
desemna descrierea detaliată a ceea ce ar trebui să facă efectiv sistemul.

3.2. Cerințe de utilizare

Cerințele de utilizare sunt declarații, într-un limbaj natural plus diagrame, a serviciilor furnizate
de sistem şi a constrângerilor în care acesta ar trebui să funcționeze.
Cerințele de utilizare pentru un sistem ar trebui să descrie cerințele funcționale și non-
funcționale astfel încât să fie ușor de înțeles de către utilizatorii sistemului, fără a poseda
cunoștințe tehnice detaliate. Acestea ar trebui să specifice numai comportamentul extern al
sistemului și ar trebui să evite, pe cât posibil, caracteristicile de proiectare și implementare ale acestuia. Cerințe
ar trebui scrise într-un limbaj simplu, cu tabele simple și diagrame intuitive.
Cu toate acestea, pot apărea diverse probleme atunci când cerințele sunt scrise în limbaj natural într-
un document text:
Lipsa de claritate: este uneori dificilă utilizarea limbajului într-o manieră precisă și lipsită de ambiguitate,
fără a face documentul foarte lung și dificil de citit.
Cerințe confuze: Cerințele funcționale, non-funcționale, obiectivele sistemului și informațiile legate de
design nu se pot distinge clar.
Combinarea cerințelor: mai multe cerințe diferite pot fi exprimate împreună ca o singură cerință.
Exemplu de enunț Cerință de utilizare: pentru a ajuta la poziționarea entităților de pe o diagramă, utilizatorul
poate afișa pe ecran o grilă, fie în centimetri sau inch, printr-o opțiune din meniul aplicației. Inițial, grila nu este
afișată. Grila poate fi afișată și ascunsă în orice moment în timpul unei sesiuni de editare și unitatea de măsură
poate fi schimbată între inch și centimetri în orice moment. O opțiune legată de grilă va fi oferită la vizualizarea
‚fit-to-page’, dar numărul de linii din grila afișată va fi redus, pentru a evita umplerea cu linii din grilă a diagramei
afișate pe un spațiu mai mic.
Prima propoziție confundă trei tipuri de cerinţe:
una conceptuală, funcțională care spune că sistemul de editare ar trebui să ofere o grilă. Se prezintă și
o justificare pentru aceasta.
una non-funcțională oferă informații detaliate despre unitățile de măsură folosite în aplicație (centimetri
sau inch).
o cerință de utilizare non-funcțională care definește modul în care grila este afișată și ascunsă de către
utilizator.

32
Cerința legată de grila de editor a fost rescrisă astfel încât să se concentreze doar pe caracteristicile de sistem
esențiale.
Exemplu de enunț modificat Cerință de utilizare: Editorul va oferi o facilitate de tip grid (o matrice de linii
orizontale și verticale) pentru fundalul ferestrei de editare. Gridul va avea un rol pasiv iar alinierea entităților va
cădea în sarcina utilizatorului. Motivație: un Grid permite utilizatorului să ordoneze diagrama prin spațierea
corectă a entităților.

3.3. Cerințe de sistem

Stabilesc, în detaliu, funcțiile sistemului, servicii şi constrângerile operaţionale. Documentul

cerințelor de sistem (uneori numit specificaţii funcţionale) ar trebui să fie precis. Acesta ar
trebui să definească exact ceea ce urmează a fi implementat efectiv. Acesta poate fi parte a
contractului încheiat între cumpărătorul sistemului software şi dezvoltatori.
Diferite niveluri ale specificațiilor sistemului sunt utile, deoarece acestea comunică informaţii
despre sistem către diferite tipuri de utilizatori de informație. În exemplul următor se ilustrează distincţia între
cerințele utilizatorilor şi cerinţele de sistem. Acest exemplu al unui sistem de bibliotecă arată cum o cerinţă de
utilizator poate fi extinsă în mai multe cerinţe de sistem. Puteţi vedea că cerința de utilizare este mai abstractă
şi cum cerinţele de sistem adaugă detalii, explicând ce servicii şi funcţii ar trebui să fie furnizate de către sistem
pentru a fi dezvoltat.
Cerințele de sistem sunt versiuni extinse ale Cerințelor de utilizare și sunt utilizate de către inginerii
software ca punct de plecare pentru proiectarea sistemului. Acestea adaugă detalii și explică modul în care
cerințele de utilizare trebuie să fie furnizate de către sistem. Acestea pot fi utilizat ca parte a contractului pentru
implementarea sistemului și ar trebui, prin urmare, să fie o specificație completă și coerentă a întregului sistem.
Cerințele de sistem ale unei aplicații software sunt adesea clasificate ca cerinţe funcţionale, cerințe non-
funcționale sau cerinţe de domeniu.

3.3.2. Cerințe funcționale

Acestea sunt enunțuri ale serviciilor pe care sistemul ar trebui să le furnizeze, modul în care
sistemul ar trebui să reacţioneze la anumite intrări şi modul în care sistemul ar trebui să se
comporte în anumite situaţii. În unele cazuri, cerinţele funcţionale pot, de asemenea, să
precizeze în mod explicit ceea ce sistemul nu ar trebui să facă.
Cerințele funcționale ale unui sistem descriu ce ar trebui să facă sistemul. Acestea depind de
tipul de software în curs de dezvoltare, utilizatorii viitori ai software-ului și abordarea generală
adoptată de către organizația care a scris cerințele. Cerințele de utilizare sunt, de obicei, descrise într-un mod
destul de abstract. Cu toate acestea, cerințele funcționale descriu în detaliu funcțiile sistemului, intrările sale,
ieșirile, excepțiile, și așa mai departe. Cerințe funcționale ale unui software pot fi exprimate într-o varietate de
moduri. Ca exemplu, urmează exemple de Cerinţe Funcţionale ale sistemului pentru o bibliotecă de facultate
(numit LIBSYS), folosit de studenţi şi de personalul facultății, pentru a comanda cărţi şi documente de la librării.
1. Utilizatorul va putea căuta fie în toate bazele de date sau doar într-o parte din acestea.
2. Sistemul va asigura instrumente de vizualizare (deschidere) adecvate pentru citirea tuturor publicațiilor din
bibliotecă.
3. Pentru fiecare căutare realizată de utilizatori, va fi alocat un identificator unic (ID-Căutare), pe care utilizatorul
poate să îl copieze în zona de semne de carte a contului.
Aceste cerințe funcționale definesc facilități specifice, care urmează să fie furnizate de către sistem. Acestea au
fost luate din documentul cerințelor de utilizare, și ilustrează faptul că cerințele funcționale pot fi scrise la diferite
niveluri de detaliere (nivelul contrastează pentru cerința 1 și 3).
Impreciziile din Documentul de Specificare a Cerințelor sunt cauza multor probleme care apar pe parcursul
procesului de dezvoltare software. Este firesc pentru un dezvoltator de sistem să interpreteze orice ambiguitate
astfel încât să-și simplifice munca de implementare. Adesea, însă, acest lucru nu este ceea ce clientul vrea.

33
Prin noi cerințe trebuie să fie stabilite și modificări aduse sistemului. Desigur, aceste modificări întârzie livrarea
sistemului și măresc costurile.
Luați în considerare cerința a doua din exemplul LibSys care se referă la oferirea de „instrumente de vizualizare
adecvate”. Sistemul de bibliotecă poate livra documente într-o varietate de formate (.doc, .pdf, .jpg, etc.), intenția
enunțată de această cerință este ca toate aceste formate să fie disponibile pentru utilizatori. Cu toate acestea,
cerința este enunțată ambiguu, și nu face clar faptul că pentru fiecare format de document ar trebui furnizate
programe de vizualizare. Un dezvoltator sub presiunea timpului ar putea oferi pur si simplu un vizualizator de
text și susține că au fost îndeplinite cerințele.
În principiu, Documentul de Specificare a Cerinţelor Funcţionale ale unui sistem ar trebui să fie atât complet cât
și coerent. Complet înseamnă că toate serviciile cerute de către utilizator ar trebui să fie definite. Coerența
înseamnă că cerințele nu trebuie să aibă definiții în contradicție.

3.3.3. Cerințe non-funcţionale

Acestea sunt constrângeri privind serviciile sau funcţiile oferite de sistem. Acestea includ
constrângerile de timp, constrângerile asupra procesului de dezvoltare software şi
constrângeri provenite din reglementări (de ex. legi).Cerințele non-funcţionale se aplică de
multe ori asupra sistemului privit ca un întreg. Ele nu se aplică, de obicei, doar la trăsăturile
individuale ale sistemului sau doar la anumite servicii.
Cerințele non-funcționale, după cum le sugerează și numele, sunt cerințele care nu sunt direct
preocupate de funcțiile specifice livrate de către sistem. Acestea pot să se refere la proprietăți de sistem cum ar
fi fiabilitatea, timpul de răspuns sau spațiul de stocare. Alternativ, se pot defini constrângeri de sistem, cum ar fi
capacitățile dispozitivelor de intrare/ieșire sau tipurile de date utilizate în interfețele sistemului.
Utilizatorii sistemului pot găsi, de obicei, modalități de a evita problemele ridicate de o funcționalitate de sistem
care nu respectă întru-totul nevoile lor. Pe de altă parte, ne-satisfacerea unei cerințe non-funcționale poate
însemna că întregul sistem este inutilizabil. De exemplu, dacă un sistem nu permite decât exportul fişerelor dar
nu și listarea acestora se pot găsi soluții. Dar dacă la un sistem de aeronave componenta de control în timp real
nu reușește să îndeplinească cerințele de performanță, controlul aeronavelor nu se va face la timp.
Cerințele non-funcționale apar din cauza nevoilor utilizatorilor, a constrângerilor legate de bugetul de dezvoltare,
a politicilor organizației care va folosi sistemul, a nevoii de interoperabilitate cu alte sisteme, sau din cauza unor
factori externi cum ar fi legile legate de siguranță sau accesul la datele utilizatorilor. Ca urmare aceste cerințe
pot proveni din funcționalitățile obligatorii ale software-ului (product requirements), organizația pentru care se
dezvoltă software-ul (organizational requirements) sau surse externe (external requirements).
Tipurile de cerințe non-funcționale sunt:
Cerințe de produs: Aceste cerințe specifică comportamentul produsului. Exemplele includ: Cerințe de
performanță cu privire la cât de repede sistemul trebuie să execute procesările și cât de mult spațiu de
memorie este nevoie; Cerințe de fiabilitate care prevăd ratele de eșec acceptabile; Cerințele privind
portabilitatea și Cerințe de uzabilitate.
o Exemplu cerință de produs: Interfața cu utilizatorul pentru LIBSYS va fi implementată ca HTML
simplu, fără cadre sau applet-uri Java.
Cerințe organizatorice: Aceste cerințe sunt derivate din politicile și procedurile din organizațiile clientului
și ale dezvoltatorului. Exemplele includ: Standardele de proces care trebuie să fie utilizate; Cerințe de
implementare, cum ar fi, limbajul de programare sau de design utilizat, precum și Cerințe de livrare,
care specifica când și cum trebuie să fie livrate produsul și documentația aferentă.
o Exemplu cerință organizațională : Procesul de dezvoltare a sistemului și a documentelor
aferente vor fi în conformitate cu procesul și rezultatele definite în Standardul 95.
Cerințele externe: Această rubrică largă acoperă toate cerințele care sunt derivate de la factori externi
ai sistemului și procesului de dezvoltare. Acestea pot include: Cerințele de interoperabilitate, care
definesc modul în care interacționează sistemul cu alte sisteme în aceeași organizație sau în alte
organizații,

34
 o Exemplu cerință externă: Sistemul nu trebuie să dezvăluie alte informații personale despre
utilizatorii sistemului, în afara numelui lor și a numărul legitimației de biblioteca, către personalul
bibliotecii care folosește sistemul.
Cerințe legislative care trebuie să fie urmate pentru a se asigura că sistemul funcționează în cadrul legii,
precum și Cerințe etice care sunt necesare pentru a se asigura că sistemul va fi acceptabil utilizatorilor
săi și publicului larg.
O problemă comună cu cerințele non-funcționale este faptul că acestea pot fi dificil de verificat. Utilizatorii sau
clienții afirma adesea că cerințele generale (cum ar fi ușurința de utilizare, capacitatea sistemului de a recupera
de la eșec sau răspuns rapid la solicitări) sunt realizate de sistem. Aceste obiective vagi pot cauza probleme
pentru dezvoltatorii de sisteme deoarece lasă loc de interpretare și dispută ulterior livrării sistemului. Pentru a
ilustra aceste probleme folosim exemplul următor:
Cerință de utilizare (neverificabilă): Sistemul trebuie să fie ușor de utilizat de controlorii cu experiență și
ar trebui să fie organizat în așa fel încât erorile de utilizare să fie reduse la minimum.
O cerință non-funcțională verificabilă: Operatorii cu experiență trebuie să poată folosi toate funcțiile
sistemului, după o perioadă de formare de două ore. După această pregătire, numărul mediu de erori
făcute de utilizatorii experimentați, nu trebuie să depășească două pe zi.
Ori de câte ori este posibil, cerințele non-funcționale ar trebui să descrise cantitativ, astfel încât acestea
să poată fi testate în mod obiectiv. Tabelul următor prezintă un număr de metrici posibil de utilizat pentru
a specifica cerințele non-funcționale asupra proprietăților de sistem. Puteți măsura aceste caracteristici
atunci când sistemul este testat pentru a verifica dacă este sau nu conform cu cerințele sale non-
funcționale.
Acuratețe Data de nastere trebuie sa fie mai mica decat data
curenta;
Disponibilitate Quiz-ul poate fi accesat in fiecare duminica de la ora
0.00 la ora 24.00;
Compatibilitate Fisierul continand notele exportate trebuie sa poata fi
deschis cu Excel 2003 sau ulterior;
Acces concurent Quiz-ul trebuie sa poata fi accesat de minim 30
utilizatori in acelasi timp;
Mentenanță Orice modificare a legii trebuie implementata cu minim
o luna inainte de a fi obligatorie;
Performanta Trecerea de la o intrebare la alta din Quiz trebuie sa
se faca in maxim o secunda.
Cerințele non-funcționale intră, de multe ori, în conflict și interacționează cu alte cerințe funcționale sau non-
funcționale. De exemplu, poate fi o cerință care specifică că maximul de memorie folosită de un sistem trebuie
să fie de 4 MB. O altă cerință ar putea fi faptul că sistemul ar trebui să fie scrise folosind limbajul de programare
Ada, (un limbaj de programare folosit pentru software-ul în timp real). Cu toate acestea, nu poate fi posibilă
compilarea unui program Ada cu funcționalitatea cerută în mai puțin de 4 MB. Există, prin urmare, nevoia
realizării unui compromis între aceste cerințe: un limbaj alternativ de dezvoltare sau adăugarea unei memorii
suplimentare în sistem.

3.3.4. Cerinţe de domeniu

Acestea sunt cerinţele care vin de la domeniul în cadrul căruia se aplică sistemul. Ele
reflectă caracteristicile şi constrângerile specifice fiecărui domeniu. Acestea pot fi atât
cerinţe funcționale cât și non-funcționale. Dacă aceste cerințe nu sunt îndeplinite,
construirea unui sistem care să funcționeze satisfăcător poate fi imposibilă. Sistemul
LIBSYS include un număr de cerinţe de domeniu:
1. Trebuie să fie implementată o interfață de utilizator standard pentru accesul la toate
bazele de date. Aceasta se bazează pe standardul X.

35
2. Din cauza restricțiilor privind drepturile de autor, unele documente trebuie să fie șterse imediat ce au fost
descărcate. În funcție de cerințele utilizatorului, aceste documente fie vor fi tipărite de imprimanta locală sau la
o altă imprimantă de rețea.
Prima cerință este o constrângere de proiectare. Aceasta specifică faptul că interfața cu utilizatorul care dă
acces la publicațiile din baza de date trebuie să fie implementată în conformitate cu un standard specific de
bibliotecă. Prin urmare, dezvoltatorii trebuie să afle despre acest standard înainte de a începe design-ul
interfeței. A doua cerință a fost introdus ca urmare a legilor drepturilor de autor care se aplică la materialele
folosite în biblioteci. Aceasta specifică faptul că sistemul trebuie să includă un sistem automat de ștergeți-la-
imprimare pentru anumite clase de documente. Acest lucru înseamnă că utilizatorii sistemul de bibliotecă nu pot
avea propria lor copie electronică a documentului.
O cerință de utilizare care să prescrie modul în care se fac calculele ar putea fi: LIBSYS trebuie să furnizeze și
ca un sistem de contabilitate financiară care menține înregistrări ale tuturor plăților efectuate la achiziționarea
cărților. TVA-ul aplicat la achiziție poate avea o cotă diferită de cea standard și se calculează prin împărțirea
costului cărții la valoarea 1+cota TVA.

3.4. Documentul Cerințelor Software

Documentul Cerințelor Software (SRS – Software Requirements Specification) este enunțarea

oficială a ceea ce dezvoltatorul sistemului ar trebui să implementeze. Aceasta ar trebui să
includă atât Cerințele de Utilizare pentru un sistem cât și o descriere detaliată a Cerințelor de
Sistem.
Documentul Cerințe are un set divers de utilizatori, de la seniori din managementul
organizației care este beneficiarul sistemului, până la inginerii responsabili pentru dezvoltarea software-ului.
Diversitatea utilizatorilor posibili înseamnă că Documentul de Cerințe trebuie să fie un compromis între a
comunica cerințele clienților, definirea cerințelor în detaliu pentru dezvoltatori și testeri, precum și comunicarea
de informații vagi cum ar fi de exemplu evoluția posibilă a sistemului. Nivelul de detaliu la care se scrie
Documentul de Cerințe depinde de tipul de sistem care este în curs de dezvoltare și de procesul de dezvoltare
folosit. Atunci când sistemul va fi dezvoltat de către un contractor extern, caietul de sarcini critice de sistem
trebuie să fie precis și foarte detaliat. Atunci când dezvoltarea se face in-house și procesul iterativ de dezvoltare
este utilizat, documentul de cerințe poate fi mult mai puțin detaliat, deoarece orice ambiguități pot fi rezolvate
operativ în timpul procesului de dezvoltare a sistemului.
Informațiile care sunt incluse într-un Document de Cerințe trebuie să depindă de tipul de software în curs de
elaborare și de abordarea care este folosită pentru dezvoltarea sistemului. De exemplu, în cazul în care o
abordare evolutivă este adoptată pentru un produs software, Documentul de Cerințe va lăsa pe dinafară multe
dintre capitole detaliate. Accentul va fi pus pe definirea cerințelor non-funcționale de utilizare la nivel înalt. În
acest caz, designeri și programatori folosesc judecata lor pentru a decide cum să procedeze pentru a îndeplini
cerințele utilizatorilor. Prin contrast, atunci când produsul informatic este parte a unui proiect mare de dezvoltare,
care include hardware și software care interacționează, este esențial să se definească cerințele de la un nivel
de detaliu. Acest lucru înseamnă că documentația privind cerințele vor fi foarte lungă și ar trebui să includă cele
mai multe, dacă nu toate capitolele standard.

3.5. Documentarea cerințelor de utilizare prin Diagrame Use-case

Ideea de bază a modelării prin Diagramele Cazurilor de Utilizare (use-case) este destul de
simplă: Pentru a ajunge la inima a ceea ce un sistem trebuie să facă trebuie să ne
concentrăm, în primul rând, pe cine (sau la ce) va folosi sistemul, şi cine (sau la ce) va fi
folosit de sistem. După lămurirea acestui aspect, trebuie determinat care sunt lucrurile
folositoare pe care trebuie să le facă sistemul pentru aceşti utilizatori.
Diagrama Use-case, include următoarele componente:

36
 Actorii: reprezintă oameni sau lucruri care interacţionează într-un fel cu sistemul. Prin definiţie, actorii
sunt în afara sistemului. Ne vom concentra pe actori pentru a ne asigura că sistemul face ceva util.Actorii
au un nume şi o scurtă descriere, şi sunt asociați cu cazurile de utilizare cu care aceştia interacţionează.
Cazuri de utilizare (Use-case): reprezintă lucrurile de valoare pe care sistemul le efectuează pentru
actorii săi. Cazuri de utilizare nu sunt funcţii sau caracteristici ale sistemului. Cazurile de utilizare au un
nume şi o scurtă descriere. Ele au, de asemenea, descrieri detaliate care sunt de fapt descrieri narative
despre modul în care actorii folosesc sistemul pentru a face ceva considerat de ei important, precum şi
ceea ce face sistemul pentru a satisface aceste nevoi.
Setul complet de actori și de Cazuri de Utilizare ale unui sistem reprezintă modelul cazurilor de utilizare
al sistemului. Mai multe cazuri de utilizare pot fi reprezentate grafic printr-o diagrama Use-case. În cadrul
Diagramelor Use-case actorii sunt reprezentați de pictograme tip omuleț şi cazurile de utilizare de ovaluri. Liniile
reprezintă relațiile dintre un actor și un Caz de Utilizare. Dacă se folosesc săgeți în loc de linii, acestea comunică
inițiatorul interacțiunii. Diagramele use-case oferă o vedere compactă, sumară în timp ce marea masă a
informației este stocată sub forma unui text structurat aferent fiecărui Caz de Utilizare. Pentru o specificare
corectă este nevoie atât de reprezentarea grafică (Diagrama Use-case) cât și descrierea textuală (Cazurile de
Utilizare).
Pentru simplificare, Diagramele Use-case se construiesc ierarhic. Motivul este că un sistem de
dimensiune medie are zeci sau sute de Cazuri de Utilizare iar reprezentarea tuturor acestora
într-un singur model/desen ar fi extrem dificil de înțeles. Soluția la această problemă este
construirea mai multor Diagrame Use-case, conectate între ele, și grupate pe nivele de detaliu.
De exemplu, un program de contabilitate are zeci de Cazuri de utilizare (cum ar fi: Introducere
facturi, Editare note contabile, Actualizare Plan de conturi, Vizualizare Balanță de Verificare,
Vizualizare Fișă de magazie, etc.). Pentru simplificare, se poate construi pentru început o Diagramă Use-case
care să reprezinte grafic faptul că cele mai importante funcționalități sunt de fapt legate de realizarea evidenței
Contabile, respectiv de ținerea evidenței patrimoniului organizației (Gestiune). O astfel de Diagramă Use-case
este prezentată în figura de mai jos.

Figura nr. 9 exemplu de diagrama a cazurilor de utilizare

Diagrama Use case va fi extinsă ulterior prin alte două Diagrame denumite Evidența Contabilă
respectiv Gestiunea patrimoniului, care la rândul lor vor putea fi extinse prin alte Diagrame
Use-case în funcție de nivelul de detaliere dorit.
Cazuri de utilizare sunt un foarte puternic instrument de modelare tehnică a cerințelor. Ele ne
oferă o modalitate standard de capturare, explorarea, documentarea a ceea ce ar trebui să
facă un sistem (Cerințele de sistem).
In concluzie: funcționalitățile sistemului (caracteristicile, trăsăturile acestuia) nu sunt Cazuri de utilizare, şi vice-
versa. Atunci ce sunt Cazurile de utilizare? Ele descriu comportamentul sistemului într-un mod suficient de
detaliat pentru a fi înțeles uşor. Ca urmare, ele modelează trei aspecte ale software-ului:

37
 evenimentele declanşate de actori şi de sistem în sine;
răspunsul sistemului sau a actorilor la aceste evenimente;
informațiile schimbate între actori şi sistem (intrările şi ieşirile sistemului).
Cu alte cuvinte, un caz de utilizare conţine descrierea a unui set de cerinţe software care sunt
prezentate sub formă de naraţiune, mai degrabă decât o listă detaliată (aşa cum se întâmplă
atunci când documentarea cerinţelor software este exprimată într-un format declarativ).
Un Caz de utilizare plasează cerinţele software pe care le conține în contextul unei descrieri a
‚ceva’ ce utilizatorul dorește să ‚facă’ în cadrul sistemului. Contextul oferit de Cazurile de
utilizare are multe beneficii atunci când e nevoie de capturarea, manipularea, verificarea,
gestionarea de cerințe. Din acest motiv, Cazurile de utilizare sunt mecanismul nostru preferat pentru captarea
și documentarea cerințelor software.
Există două concepții eronate comune referitoare la utilizarea Cazurile de utilizare care cauzează de
multe ori problemele celor care utilizează pentru prima dată această tehnică:
cazurile de utilizare sunt doar o modalitate de a surprinde cerințele funcționale ale unui sistem și nimic
altceva. Cerințele non-funcționale sunt toate capturate în altă parte. Având în vedere că un Caz de
utilizare, în sine, este un container care conține seturi de cerințe legate de software, cum poate el să se
ocupe de cerințele funcționale și nefuncționale? Cazurile de utilizare capturează cu ușurință seturi de
cerințe funcționale, ele descriu comportamentul sistemului care interacționează cu utilizatorii săi și alte
sisteme. Cazurile de utilizare plasează cerințele funcționale în contextul unui utilizator care face ceva
util. Cazurile de utilizare pot fi folosite forțat și pentru a captura cerințele nefuncționale. De exemplu,
următoarea cerință poate fi atașată Diagramei Use-case de mai sus: „Timpul de răspuns între
încheierea apelării și emiterea sunetelor de apel ale dispozitivului solicitat ar trebui să fie mai mic de 0,5
secunde în 95 la suta din toate cazurile, și în nici un caz mai mult de 1 secundă.”. Totuși, cerințele
nefuncționale sunt descrise cel mai bine cu ajutorul cerințelor declarative. Acestea sunt apoi atașate
sau urmărite până la cazurile de utilizare la care se aplică. Încercarea de a descrie cerințele
nefuncționale în textul cazurilor de utilizare este cel mai bun caz la confuz, iar în unele cazuri rezultatele
pot fi dezastruoase.
cazurile de utilizare sunt tot de ce ai nevoie pentru a captura cerințele unui sistem. De fapt, cazurile de
utilizare capturează o mare, de obicei, cel mai mare, subset al cerinţelor software pentru sistem. Modelul
Diagramelor Use-case în sine este un vehicul pentru organizarea cerinţele software-ul într-un mod uşor
de gestionat. Acesta permite părţilor interesate, clienţii, utilizatorii şi dezvoltatorii, să înţeleagă cerinţele
şi le permite acestora să comunice nevoile lor, într-un mod coerent, non-redundant. De asemenea,
permite dezvoltatorilor să împartă între ei munca de extragere a cerinţelor şi apoi de să utilizeze
rezultatele (în primul rând Diagramele Use-case), ca intrări atunci când analizează, proiectează,
implementează şi testează sistemul.
Pentru a utiliza un sistem, trebuie să avem un model mental al modului în care acesta funcţionează; acest
model mental ne ajută să ne formăm strategii legate de cum putem folosi sistemul pentru a realiza sarcini. Fără
un model mental, suntem în imposibilitatea de a folosi efectiv sistemul, şi cu cât este mai simplu modelul mental,
cu atât mai uşoară este utilizarea sistemul.

3.6. Documentarea cerințelor de sistem prin Cazuri de Utilizare

Vom utiliza un exemplu pentru a descrie structura unui Caz de Utilizare. Titlul cazului de
utilizare este "Împrumut" si se refera la modul in care se realizează împrumutul cărților dintr-
o biblioteca. Secvența de baza de desfășurare a evenimentelor este:
1. Un utilizator completează rubricile afectate numelui și prenumelui după care apasă butonul
"Trimita".
2. Sistemul stochează datele și verifica dacă utilizatorul este înregistrat ca abonat.
3. Sistemul afișează următoarea pagina, conținând formularul de împrumut.
4. Abonatul completează formularul de împrumut, cu titlul cărții, numele si prenumele autorului și codul ISBN al
cărții apoi apasă butonul "Trimite".

38
5. Sistemul preia datele și caută cartea.
6. Sistemul înregistrează împrumutul.
7. Sistemul afișează datele necesare împrumutului.
Calea Alternativă 1: "Acces neautorizat":
La pasul 2: Utilizatorul nu este înregistrat ca abonat și atunci sesiunea este încheiată de sistem cu un mesaj în
care utilizatorul este invitat să se înregistreze.
Calea Alternativă 2: "Împrumutul nu este posibil"
La pasul 5:
5a) Cartea nu este găsită. Sistemul afișează un mesaj și sesiunea este încheiată.
5b) Cartea este găsită dar abonatul a împrumutat deja numărul admis de cărți. Sistemul afișează un mesaj și
încheie sesiunea.
Pot exista variații în privința descrierii Cazurilor de utilizare. De exemplu, o descriere mai exacta a Cazului de
utilizare anterior este reprezentat mai jos.

Actori: Abonat, Sistem

Scop: Împrumutul unei cărți
Descriere generală: Un abonat accesează pagina Web a sistemului de
gestiune electronică a cărților din bibliotecile
existente in tara. El își introduce identitatea și datele
de identificare ale cărții pe care dorește să o
împrumute. Sistemul validează identitatea
abonatului și caută cartea. Dacă cartea există și
abonatul are dreptul sa obțină un nou împrumut
atunci sistemul autorizează împrumutul.
Pre-condiție: Daca este necesar, abonatul trebuie să execute mai
întâi procedura de acces la sistem (log-in).
Post-condiție: În baza de date a sistemului există o înregistrare a
împrumutului către abonat
Cazuri de utilizare referite: Înregistrarea unui nou abonat

Pre-condiția exprimă condiția care trebuie sa fie satisfăcută înainte de începerea Cazului de utilizare. Post-
condiția exprimă condiția care este satisfăcută după execuția cazului de utilizare (conform descrierii secvenței
tipice!).
Descrierea unui caz de utilizare trebuie sa precizeze:
cum și când începe si se termina cazul de utilizare - evenimente care marchează începutul și sfârșitul
cazului;
când au loc interacțiunile cu actorii și informațiile schimbate (comunicate între actori - sistem) în timpul
fiecărei interacțiuni;
fluxul de baza (comportamentul de baza) si alternativele fiecărei interacțiuni. Repetările de
comportament, care pot fi descrise prin formulări de tipul: „ciclu …….activități…., sfârșit ciclu” sau „cât
timp ….., sfârșit cat timp”
pre-condiții si post-condiții;

39
 Exerciții

1. Identificați și descrieți, pe scurt, cele patru tipuri de cerințe care pot fi definite pentru un software.
2. Găsiți ambiguități sau omisiuni în următoarea declarație de Cerințe pentru o parte a unui sistem de emitere
de bilete:
„Un automat de bilete, din cadrul sistemul de emitere, vinde bilete de transport feroviar. Utilizatorii selectează
destinația lor și introduc un card de credit și un PIN. Biletul de tren este emis și card-ul de credit debitat. Atunci
când utilizatorul apasă butonul de pornire, un afișaj de tip meniu arată potențialele destinații, împreună cu un
mesaj care cere utilizatorului să selecteze o destinație. Odată ce o destinație a fost selectată, utilizatorii sunt
rugați să introducă cardul lor de credit. Valabilitatea acestuia este verificată și apoi utilizatorului îi este solicitată
introducerea PIN-ului. Când tranzacția a fost validată, biletul este emis.”
3. Rescrieți descrierea de mai sus folosind o abordare structurată descrisă în acest capitol. Rezolvați
ambiguitățile identificate în mod adecvat.
4. Folosind tehnica sugerată pe parcursul capitolului, în cazul în care limbajul natural este prezentat într-un mod
standard, scrieți Cerințe de utilizare plauzibile pentru următoarele funcții:
a) funcția de eliberare de numerar a unui ATM;
b) funcția de verificare și corectare a ortografiei într-un procesor de text;
c) o pompă de benzină nesupravegheată (automată), care include un cititor de card de credit. Clientul
trece cardul prin cititor și specifică, apoi, cantitatea de combustibil necesară. Combustibilul este livrat și
contul clientului debitat.
5. Descrieți patru tipuri de cerințe non-funcționale, care pot fi plasate într-un sistem. Dați exemple din fiecare
dintre aceste tipuri de cerințe.
6. Scrieți un set de cerințe non-funcționale pentru sistemul de eliberare a biletelor, având în vedere fiabilitatea
și timpul de răspuns la cererile utilizatorilor.
7. Argumentați de ce este important să se facă o distincţie între dezvoltarea cerinţele utilizatorilor şi a cerinţelor
de sistem în procesul de specificare a cerinţelor.
8. Realizați diagrama cazurilor de utilizare pentru o aplicație contabilă (de exemplu SAGA), modulul de facturare,
apoi detaliați cazul de utilizare de introducere a unei facturi de vânzare.

40