Sunteți pe pagina 1din 24

Principalele 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 aţi citit capitol, veţi:

- înţelege conceptele de cerinţele ale utilizatorilor şi cerințe de system ş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ţ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 de software-ul î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. La cealaltă extremă, termenul „Cerință” se referă la o definiţie
detaliată, formală a unei funcţii a sistemului. Davis (Davis,1993) explică de ce există aceste diferenţe:
„Dacă o companie doreşte să lanseze un contract pentru un proiect mare de dezvoltare software, trebuie
să definească nevoile sale într-un mod suficient de abstract ca o soluţie să nu fie predefinită. Cerinţele
trebuie să fie scrise astfel încât cei care licitează pentru atribuirea contractului să poată oferti diferite
moduri de satisfacere a organizatiei client. 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 software-ul 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 eşuării
de a face o separare clară între aceste niveluri diferite de descriere. Pentru a distinge între cele două
vom folosi în continuare termenul „cerinţele de utilizarer” 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. Cerinţele utilizatorilor şi cerinţele de sistem pot fi definite după cum urmează:

1. 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.

2. Cerinţele 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ță utilizator: Sistemul LIBSYS va ţine evidenţa tuturor datelor solicitate de agențiile guvernamentale
care se ocupă cu licențele şi drepturile de autor.

Cerinţe de sistem:

1.1 La cererea unui document din sistemul LIBSYS, solicitantului trebuie să îi fie prezentat un formular
care cere înregistrarea detaliilor utilizatorului, precum şi cererea pe care acesta a făcut-o.

1.2 În sistemul LIBSYS formularele de cerere trebuie să fie stocate pentru o perioadă de cinci ani de la
data cererii.

1.3 Toate formularele de cerere trebuie să fie indexate după numele utilizatorului, apoi după numele
materialului solicitat.

1.4 LlBSYS păstrează un jurnal cu toate cererile care au fost făcute în sistem.

1.5 Pentru materiale în cazulul cărora se aplică drepturile de autor, detaliile de împrumut vor fi trimise
lunar, în mod automat, către agenţiile guvernamentale care se ocupă de licenţe şi drepturi de autor, care
au fost înregistrate în prealabil în LIBSYS.

Este nevoie ca cerinţele să fie scrise la diferite niveluri de detaliu pentru că diferite tipuri de cititori le
folosesc în moduri diferite. Figura 6.2 prezintă tipurile de cititori pentru cerințele de utilizare şi cerinţele
de sistem. Cititorii cerinţelor de utilizare nu sunt, de obicei, preocupați de modul în care sistemul va fi
implementat şi pot fi manageri care nu sunt interesaţi de facilităţile detaliate ale sistemului. Cititorii
cerințelor sistemului trebuie să ştie mai exact ce va face sistemul, fie pentru că sunt preocupaţi de modul
în care sistemul va sprijini procesele de afaceri, fie pentru că sunt implicați în implementarea sistemului.
Cerinţe funcţionale şi non-functionale

Cerinţe de sistem pentru software sunt adesea clasificate ca cerinţe funcţionale, cerințe non-functionale
sau cerinţe de domeniu:

1. Cerinţe funcţionale: Acestea sunt enunțuri ale serviciilo 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ă.

2. 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.

3. Cerinţe de domeniu: Acestea sunt cerinţele care vin de la domeniul în cadrul căruia se aplicareă
sistemul. Ele reflectă caracteristicile şi constrângerilespecifice fiecărui domeniu. Acestea pot fi atat
cerinţe funcţionale cât şi non-funcţionale.

În realitate, distincţia între diferitele tipuri de cerinţe nu este la fel de clară cum sugerează aceste
definiţii simple. O cerinţă de utilizare legată de securitate poate părea a fi o cerinţă non-funcţională. Cu
toate acestea, atunci când este dezvoltată în detaliu, această cerinţă poate genera alte cerinţe care sunt
în mod clar funcţionale, cum ar fi necesitatea de a include facilităţi de autentificare în sistem.

Cerinţele funcţionale

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-Cautare), pe care
utilizatorul poate să îl copieze în zona de semne de carte (bookmark) 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 de cerinţele 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ţor 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 simplifica munca de implementare. Adesea, însă, acest lucru nu este ceea
ce clientul vrea. Noi cerinţe trebuie să fie stabilite şi modificările aduse sistemului. Desigur, aceste
modificări întârzie livrarea sistemului şi măreşte 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, si 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. În practică, pentru
sisteme mari, complexe, este practic imposibil să se atingă coerenţa şi exhaustivitatea cerințelor. Un
motiv pentru aceasta este faptul că este uşor să se facă greşeli şi omisiuni când se scriu specificaţiile
pentru sistemele mari, complexe. Un alt motiv este faptul că diferite părţi interesate (stakeholders) au
nevoi diferite şi adesea inconsecvente. Aceste neconcordanţe nu pot fi evidente atunci când cerinţele
sunt specificate prima dată, astfel încât cerințe inconsistente sunt incluse în Documentul de Specificare a
Cerinţelor. Problemele pot fi fi găsite după o analiză mai profundă sau, uneori, după ce dezvoltarea este
completă şi sistemul este livrat clientului.

Cerinte Non-funcţionale

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.

Cerințele non-funcţionale sunt rareori asociate cu caracteristicile individuale ale sistemului. Ele pot
specifica performanţa sistemului, cerințe de securitate, de disponibilitate, etc. Acest lucru înseamnă că
acestea sunt adesea mai critice decât cerinţele funcţionale individuale. 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ă un sistem de aeronave nu respectă cerinţele de fiabilitate, acesta nu
va fi certificat ca fiind sigur pentru funcţionare, sau dacă 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-functionale 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 acesul la datele utilizatorilor.
Figura de mai sus arată clasificarea cerințelor non-funcționale. Se poate observa că 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:

1. 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.
2. Cerinţe organizatorice: Aceste cerinţe sunt derivate din politicile şi procedurilor în 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 utilizate, precum şi Cerinţe de
livrare, care specifica când şi cum trebuie să fie livrate produsul şi documentaţia aferentă.

3. 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, 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.

Exemplu cerinţă de produs: Interfaţa cu utilizatorul pentru LIBSYS vor fi implementată ca HTML simplu,
fără cadre sau applet-uri Java.

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.

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ţa de produs de mai sus restrânge libertatea dezvoltatorilor LIBSYS de a implementa interfeţa pusă
la dispoziția utilizatorilor de sistem. Aceasta nu spune nimic despre funcţionalitatea LIBSYS şi identifică în
mod clar o constrângere de sistem, mai degrabă decât o funcţie. Această cerinţă a fost inclusă, deoarece
simplifică problema de a se asiguraarea funcţionării sistemului cu browsere internet diferite. Cerinţa
organizaţională de mai sus specifică faptul că sistemul trebuie să fie elaborate în conformitate cu un
standard intern al firmei. Cerinţa externă este derivată din necesitatea ca sistemul să fie conform cu
legislaţia de protecție a datelor personale. Se specifică faptul că personalul de bibliotecă nu ar trebui să li
se permită accesul la date neesențiale pentru realizarea sarcinilor de serviciu, cum ar fi adresele de
domiciliu ale utilizatorilor sistemului.

O problemă comună cu cerințele non-funcţionale este faptul că acestea pot fi dificil de verificat.
Utilizatorii sau clienţii afirma adesea ca 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
disputa 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ă un total de 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.
Acest exemplu arată modul tipic în care un utilizator îşi exprimă obiectivul pentru un sistem de control al
traficului aerian. Cerința a fost rescrisă pentru a arăta modul în care cerința poate fi exprimată astfel
încât aceasta să poată fi verificată la punerea în funcțiune a sistemului. Deşi este imposibil să se verifice
în mod obiectiv cerința enunțată înaintea finalizării sistemului, există posibilitatea realizării unor teste de
sistem pentru a număra erorile făcute de către operatorii de trafic în timp ce folosesc un prototip de
sistem.

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-functionale 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.

viteză Tranzacţii procesate pe secundă


Timp de răspuns pentru un Eveniment
Timp de de reîmprospătare (refresh) a ecranului
dimensiune K bytes
Numărul de chip-uri de memorie RAM
Uşurinţa în utilizare Timp de formare
Numărul de pagini de Help
încredere Valoarea medie de timp între două erori
Probabilitatea de indisponibilitate
Rata de defecte
Timp de disponibilitate sau in-disponibilitate
robusteţe Timpul necesar pentru a reporni sistemul după o eroare
Procentul de evenimente cauzatoare de eşec
Probabilitatea de corupere a datelor în caz de eşec
portabilitate Numărul de sisteme de destinație

În practică, însă, clienţii pentru un sistem pot găsi imposibilă traducerea obiectivele lor în cerinţe
cantitative. Pentru unele obiective, cum ar fi în întreţinere, nu există valori care pot fi utilizate. În alte
cazuri, chiar şi atunci când specificarea în mod cantitativ a cerințelor este posibilă, clienţii pot să nu fie în
măsură să adapteze aceste specificaţii la nevoile lor. Ei pot să nu înţelegă ce reprezintă o valoare care
cuantifică fiabilitatea minimă a sistemului (de exemplu), în termeni de experienţa lor de zi cu zi cu
calculatorul. În plus, costul ridicat de verificarea cantitativă non-functională poate fi mare, iar clienţii care
plătesc pentru sistem pot să credă ca aceste costuri nu sunt justificate.

Prin urmare, documentele de cerinţe includ, de multe ori obiective cuantificabile amestecate cu cerinţe
ne-măsurabile. Şi cerintele ne-cuantificabile pot fi utile pentru dezvoltatori, deoarece acestea dau
indicaţii legate de priorităţile clientului. Cu toate acestea, clienţii trebuie să fie conştienți ca ele sunt
deschise la interpretări greşite pentru că nu pot fi verificate în mod obiectiv.
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.

Este util dacă puteți diferenţia Cerinţe funcţionale de cele non-functionale în Documentul de Cerinţe. În
practică, acest lucru este deseori dificil. În cazul în care cerințele non-funcţionale sunt menţionate
separat de cele funcţionale este, uneori, dificilă găsirea relatiilor dintre ele. În cazul în care sunt
prezentate împreună cu cerinţe funcţionale, aţi putea găsi că este dificil să separați consideraţiile
funcţionale şi non-funcţionale şi să identificați cerinţele care se referă la sistem ca la un întreg. Cu toate
acestea, ar trebui să evidenţieze în mod explicit cel puțin cerinţele care sunt în mod clar legate de
proprietăţile de generale ale sistemului, cum ar fi performanța sau fiabilitatea.

Cerinţe de domeniu

Cerinţe de domeniu sunt derivate din domeniul de aplicare a sistemului mai degrabă decât din nevoile
specifice ale utilizatorilor sistemului. Acestea includ, de obicei, terminologie din domeniul de specialitate
sau trimiteri la concepte din domeniu. Acestea pot fi duce la noi cerinţe funcţionale, constrânge cerinţe
funcţionale existente sau stabili modul în care calcule specifice trebuie să fie efectuate. Deoarece aceste
cerinţe sunt specializate, pentru inginerii software de multe ori este dificil de înţeles modul în care
acestea sunt legate de alte cerinţe de sistem.

Cerinţe domeniu sunt importante, deoarece ele reflectă adesea aspecte fundamentale ale domeniului în
care software-ul va funcționa. Dacă aceste cerinţe nu sunt îndeplinite, aceasta poate fi imposibilă
construirea unui sistem care să funcționeze satisfăcător. 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 239.50.

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.

Cerinţele de utilizare

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. Prin urmare, dacă scrieți cerinţele de
utilizare, nu trebuie să utilizaţi jargon software, notaţii structurate sau formale, sau să descrieți cerinţa
prin descrierea modului de implementare. 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:

1. 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.

2. Cerinţe confuze: Cerinţele funcţionale, non-funcţionale, obiectivele sistemului şi informațiile legate de


design nu se pot distinge clar.

3. Combinarea cerințelor: mai multe cerinţe diferite pot fi exprimate împreună ca o singură cerinţă.

Ca o ilustrare a unora dintre aceste probleme, luaţi în considerare cerinţa legată de efectuarea calculelor
prezetată mai sus. Această cerinţă include informaţii atât conceptuale cât şi detaliate. Se exprimă
conceptul conform căruia ar trebui să existe un sistem de contabilitate ca o parte inerentă a LIBSYS. Cu
toate acestea, aceasta specifică şi modul în care se face extragerea TVA din valoarea totală a achizitiei
(acest detaliu ar fi fost mai bine lăsat pentru specificare în cadrul cerinţelor de sistem).

Este o bună practică ca Cerinţele de utilizare să fie separate de Cerinţele de sistem într-un Document de
Cerinţe. În caz contrar, cititorii pot fi copleşit de detalii, care sunt într-adevăr relevant numai pentru
tehnicieni. În cerința următoare se ilustrează această confuzie. Acest exemplu este o cerinţă reală pentru
un instrument CASE care permite construirea de modele software (de ex. ERD) şi enunță cerința ca
utilizatorul să poată specifica faptul că o grilă să fie afişate, astfel încât entităţile să potă fi poziţionate cu
precizie într-o diagramă.

Cerință de utilizare: pentru a ajuta la pozitionarea entităţilor de pe o diagramă, utilizatorul poate afişa pe
ecran o grilă, fie în centimetri sau inchi, printr-o opţiune din meniul aplicației. Iniţial, grila nu este afişată.
Grila poate fi pornit şi oprit î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:

1. una conceptuală, funcţională care spune că sistemul de editare ar trebui să ofere o grilă. Se prezintă şi
o justificare pentru aceasta.

2. una non-funcţională oferă informaţii detaliate despre unităţile de măsură folosite în aplicație
(centimetri sau inchi).

3. o cerinţa de utilizare non-functională care defineşte modul în care grila este pornită şi oprită de către
utilizator.

Cerinţa de mai sus ofera, de asemenea, unele, dar nu toate informaţiile de iniţializare. Se defineşte că
grila este oprit iniţial, dar ea nu defineşte unităţile sale atunci când se afişează pentru prima dată.

Cerinţele utilizatorilor care includ prea multe informaţii restrâng libertatea dezvoltator de sisteme de a
furniza soluţii inovatoare pentru problemele ridicate de utilizator şi sunt dificil de înţeles. Cerinţele de
utilizare ar trebui să se concentreze doar pe cele mai importante funcționalități care urmează să fie
furnizate. Cerinţa legată de grila de editor a fost rescrisă astfel încât să se concentreze doar pe
caracteristicile de sistem esenţiale:

Cerință de utilizare: Editorul va oferi o facilitate de tip grid (o matrice de linii orizontale şi verticale)
pentru background-ul ferestrei de editare. Grid-ul 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.

Ori de câte ori este posibil, ar trebui să încercaţi să asociați o motivație fiecărei cerințe de utilizare.
Motivul este că ar trebui să se explice de ce cerinţa a fost inclusă în Documentul de Specificare a
Cerințelor şi deoarece este deosebit de utilă atunci când cerinţele sunt modificate.

Pentru a minirniza neînţelegerile atunci când scrieţi cerinţele utilizatorilor, se pot urma câteva
instrucţiuni simple:

1. Inventați un format standard şi asigurați-vă că toate definiţiile cerinţelor aderă la acest format.
Standardizarea formatului face mai puţin probabile omisiunile şi cerinţele sunt mai uşor de verificat. Un
exemplu de formatul prezinta cerinţa iniţială în bold, inclusiv o motivație pentru fiecare cerinţă de
utilizare şi o trimitere la cerințele de sistem mai detaliate. Se pot, de asemenea, include informaţii cu
privire la persoana care a propus cerinţa (sursa cerinţei) astfel încât să se ştie pe cine să se consulte în
cazul în care cerinţa trebuie să fie schimbată.

2. Folosiți un limbaj în mod consecvent. Trebuie să faceți distincţia între cerințele obligatorii şi cerinţele
de dorit. Cerinţe obligatorii sunt cerinţele care sistemul trebuie să sprijine şi sunt, de obicei, introduse cu
sintagma "vor fi". Cerinţe de dorit nu sunt esenţiale şi sunt introduse cu sintagma "ar trebui".

3. Utilizaţi evidenţierea textului (bold, italic sau fundalul de culoare) pentru a atrage atenția asupra
părţilor cheie ale cerinţei.

4. Evitaţi, pe cât posibil, utilizarea jargonului din domeniul calculatorului. Inevitabil, însă, detalii tehnice
se vor regăsi în cerinţele de utilizare.

Cerinţele de sistem

Cerinţe 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.

În mod ideal, cerinţele de sistem ar trebui să descrie pur şi simplu comportamentul extern al sistemului şi
constrângerile sale operaţionale. Nu ar trebui să fie preocupate de modul în care sistemul ar trebui să fie
proiectat sau implementat efectiv. Cu toate acestea specificarea detaliilor necesare pentru a specifica
complet un sistem software complex, este imposibilă, în practică, excluderea tuturor informaţiilor de
proiectare. Există mai multe motive pentru aceasta:

1. Este posibil să aveţi nevoie de o arhitectura iniţială a sistemului pentru a ajuta la structurara
specificării cerințelor. Astfel, cerinţele de sistem sunt organizate în funcţie pentru diferitele sub-sisteme
care alcătuiesc sistemul.

2. În majoritatea cazurilor, sistemele trebuie să interopereze cu alte sisteme existente. Acestea


constrânge design-ul sistemului dezvoltat, iar aceste constrângeri impun noi cerinţe de sistem.

Limbajul natural este adesea folosit pentru a specifica cerinţele de sistem precum şi cerinţele de utilizare.
Cu toate acestea, deoarece cerinţele de sistem sunt mai detaliate decât cerinţele utilizatorului,
specificaţiile în limbaj natural pot fi confuze şi greu de înţeles:

1. Înţelegerea limbajului natural se bazează pe faptul că cei care citesc cerințele şi cei care le scriu,
folosesc aceleaşi cuvinte pentru acelasi concepte. Acest lucru duce la neînţelegeri din cauza ambiguităţii
limbajului natural.
2. Specificaţia în limbaj natural este mult prea flexiblă. Puteţi spune acelaşi lucru în moduri complet
diferite. Ramâne la latitudinea celui care citeşte să decidă când cerinţe sunt aceleaşi şi când acestea sunt
distincte.

3. Deoarece limbajul natural nu este modularizat este dificilă găsirea tuturor cerinţelor care au legătură
între ele. În cazul unei modificări, trebuie parcurse toate cerinţele, mai degrabă decât doar un grup de
cerinţe care au legătură.

Este esenţial să se scrie cerinţe de utilizare într-o limbă care poate fi înțeleasă de non-specialişti. Cu toate
acestea, puteţi scrie cerinţele de sistem, în notaţii mai specializate. Acestea includ limbajul stilizat
structurat natural, modele grafice ale cerințelor cum ar fi use-case-urile (cazurile de utilizare), şi până la
specificații matematice formale.

Limbajul structurat natural

Limbajul structurat natural este o modalitate de a scrie cerinţele de sistem în cazul în care libertatea celui
care scrie cerințele este limitată şi toate cerinţele sunt scrise într-un mod standard. Avantajul acestei
abordări este că se menţine cea mai mare expresivitate şi înţelegere a limbajului natural, dar se asigură
că un anumit grad de uniformitatea se impune în cadrul specificațiilor. Notaţiile structurate limitează
terminologia care poate fi utilizată şi foloseşte şabloane pentru a preciza cerinţele de sistem. Acestea pot
include constructiile de control provenite de la limbaje de programare şi evidenţierea grafică cu scopul
de a împărţi specificațiile în blocuri logice.

Exemplu de use-case structurat

Un proiect de timpuriu, care a folosit un limbaj structurat natural pentru a preciza cerinţele de sistem
este descris de Heninger (Heninger, 1980). Formulare speciale au fost concepute pentru a descrie
intrările, ieşire şi funcţiile unui sistem software de operare a unui avion. Când un format este folosit
pentru specificarea cerințelor funcționale acesta ar trebui să conțină următoarele paragrafe:

1. Descriere a funcţiei sau a entității de specificat;

2. Descrierea intrărilor sale şi de unde provin acestea;

3. Descrierea ieşirilor sale şi unde sunt acestea folosite;

4. Indicarea altor entităţi ce sunt folosite (introduse prin sintagma ‚necesită’);

5. Descrierea acţiunilor care urmează să fie executate;


6. În cazul în care o abordare funcţională este folosită, o pre-conditie care stabileşte ce trebuie să fie
adevărat înainte de executarea funcţiei şi o post-condiţie specificând ceea ce este adevărat, după
executarea funcţiei;

7. Descrierea efectelor adiacente (dacă există) ale operaţiunii.

Modele grafice sunt mai utile atunci când aveţi nevoie să arătați modul în care au loc modificările de
stare sau în cazul în care aveţi nevoie să descrieți o secvenţăde acţiuni. Figura 6.14 ilustrează secvenţa de
acţiuni atunci când un utilizator doreşte să retragă numerar de la un ATM. Ar trebui să citiţi o diagramă
de secvenţă de sus în jos pentru a vedea ordinea în care acţiunile au loc. În figura 6.14, există trei sub-
secvente de bază:

1. Validare card: utilizatorul este validat prin verificarea numărul de card şi a PIN-ului;

2. Procesarea cerererii: utilizatorului realizată de către sistem. Pentru o retragere, baza de date trebuie
să fie interogată pentru a verifica soldul contului utilizatorului şi a sumei retrase. Observaţi excepţia aici
dacă solicitantul nu are suficienti bani în contul;

3. Finalizare tranzacţie: card-ul este returnat şi, când este ridicat de utilizator, numerarul şi chitanța sunt
livrate.
Specificarea interfeței 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
ce) va folosi sistemul, şi cine (sau 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:

a) 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ă.

b) 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 în esenţă, 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 use-case-uri ale unui sistem reprezintă modelul cazurilor de utilizare al
sistemului. Un singur caz de utilizare poate fi reprezentat grafic printr-o diagrama a cazurilor de utilizare.
În cadrul diagramelor use-case actorii sunt reprezentati de pictograme tip omuleț şi cazurile de utilizare
de ovaluri. Liniile reprezintă relațiile dintre un actor şi un use-case. 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 care este asociat diagramei.
Pentru o specificare corectă este nevoie atât de reprezentarea grafică cât şi descrierea textuală.

Un scurt exemplu a unei diagrame use-case:

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
(cerintele de sistem). Deci, ce nivel de detaliere a cerinţelor sistemului reprezinta cazurile de utilizare?

Cazurile de utilizare de mai sus pare a avea nume care ar putea fi aplicate la funcționalitățile sistemului.
Avem un caz de utilizare "Realizare apel local", care sună ca o funcționalitate a sistemului: Oamenii se
pot realiza apeluri locale, folosind sistemul. Chiar şi o examinare sumară a sistemului de telefonie şi o
selecţie a caracteristicilor sale demonstrează diferenţa dintre funcționalități şi cazurile de utilizare
precum şi natura relaţiei dintre ele. Un număr de lucruri ar trebui să fie evident aici:

1. Numele de cazuri de utilizare sunt active şi se exprimă ca obiective ale actorilor: Sunati folosind planul
local (Place local call), Vizualizați istoricul apelurilor (Get call history), şi regăsirea de informaţii de
facturare client (Retrieve customer billing information). Principalele funcționalități sunt descrise pasiv şi
se exprimă ca şi caracteristici ale sistemului: sistemul permite realizarea de apeluri locale, sistemul
asigură un istoric al apelurilor pentru toate conturile, sistemul trebuie să fie disponibil 24 de ore pe zi,
şapte zile pe săptămână.
2. Granularitatea funcționalităților şi a cazurilor de utilizare este foarte diferită. Deşi setul de cazuri de
utilizare poate pare a fi un set rezonabil de caracteristici, invers nu este neapărat adevărat: Nu toate
caracteristicile ar reprezenta de cazuri de utilizare corecte.

3. Pot fi mai multe funcționalități oferite de un singur caz de utilizare, sau o funcționalitate ar putea fi
furnizată de către mai multe mult de un singur caz de utilizare.

In concluzie: funcționalitățile software-ului (caracteristicile, trăsăturile acestuia) nu sunt cazuri de


utilizare, şi vice-versa. Atunci ce sunt use-case-urile? 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:

a) evenimentele declanşate de actori şi de sistem în sine;

b) răspunsul sistemului sau a actorilor la aceste evenimente;

c) 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 de o descriere a ceva pe
care utilizatorul doreşte să realizeze.Contextul oferit de cazuri de utilizare are multe beneficii atunci când
capturarea, manipularea, verificarea, gestionarea şi cerinţele. Din acest motiv, cazurile de utilizare sunt
mecanismul nostru preferat pentru captarea şi documentaţia de cerinţele software.

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 un model use-case se ocupe de cerinţele funcţionale şi nefuncţionale? Use-case-
urile capurează cu uşurinţă seturi de cerinţe funcţionale, ele descriu comportamentul sistemului care
interacţionează cu utilizatorii săi şi alte sisteme de a face ceva util pentru utilizatorii săi. Use-case-urile
plasează cerinţele funcţionale în contextul unui utilizator care face ceva util. Cazurile de utilizare pot fi,
de asemenea, folosite pentru a captura cerinţele nefuncţionale, care sunt specifice pentru un caz de
utilizare. De exemplu, următoarea cerinţă poate fi ataşat la use-case-ului 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ă.”.

Cerinţele nefuncţionale sunt descrise cel mai bine cu ajutorul cerinţele 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.

Există două concepţii eronate comune referitoare la utilizarea use-case-urilor care cauzeaza de multe ori
problemele oamenilor atunci când 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 nefuncţionale sunt toate capturate în altă parte.
• cazuri de utilizare sunt tot 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. Această relaţie este arătată în figura următoare. Modelul 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. Metafora foii de calcul electronic este
puternică, deoarece are un model mental simplu: foaia de calcul pe suport de hârtie. Procesor de text pe
care il folosim pentru a scrie acest capitol are un alt model simplu mental. Modul de funcționare internă
a acestor două tipuri sisteme nu sunt reprezentate ca model mental de un utilizator, dar model mental
legat de utilizarea Excel sau Word este totuşi esenţial pentru utilizarea eficientă a programelor. De
asemenea, modelul mental este unul comun indiferent de implementarea efectivă (de ex. Microsoft
Office sau Open Office).

Use-case-urile ne ajută să explorăm, formăm şi rafinăm model mental a modului în care sistemul va
funcţiona. În cazul în care dorim ca un sistem să fie utilizabil, este esenţial ca acesta să aibă un model
simplu, mental, care este aplicat în mod consecvent în întreaga proiectare. Utilizatorii şi constructorii
sistemului trebuie să împărtăşească acest model mental pentru ca sistemul să fie util. Pentru sisteme
simple, realizarea unei viziuni comune nu este atât de dificilă, dar complexitatea creşte cerinţele şi
şansele de a împărtăşi in mod natural viziunea asupra sistemului scade. Când sunt scrise corect, cazurile
de utilizare pot deveni un catalizator pentru a crea acest model mental al sistemului.
Descrierea desfăşurării evenimentelor în cadrul unui use-case:

Vom utiliza un exemplu pentru a descrie structura unui use case. Titlul cazului de utilizare este
"Imprumut" si se refera la modul in care se realizeaza imprumutul cartilor dintr-o biblioteca. Secventa de
baza de desfasurare a evenimentelor este:

1. Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul "Submit".
2. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
3. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
4. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si
codul ISBN al cartii apoi apasa butonul "Submit".
5. Sistemul preia datele si cauta cartea.
6. Sistemul inregistreaza imprumutul.
7. Sistemul afiseaza datele necesare imprumutului.

Calea Alternativa: "Acces ne-autorizat":

La pasul 2: Utilizatorul nu este inregistrat ca abonat si atunci sesiunea este incheiata de sistem cu un
mesaj in care utilizatorul este invitat sa se inregistreze.
Calea Alternativa: "Imprumutul nu este posibil"

La pasul 5:
5a) Cartea nu este gasita. Sistemul afiseaza un mesaj si sesiunea este incheiata.
5b) Cartea este gasita dar abonatul a imprumutat deja numarul admis de carti. Sistemul afiseaza un
mesaj si incheie sesiunea.

Pot exista variatii in privinta descrierii cazurilor de utilizare. De exemplu, o descriere mai exacta a cazului
de utilizare anterior este:
Actori: Abonat, Sistem
Scop: Imprumutul unei carti
Descriere generala: Un abonat acceseaza pagina Web a
sistemului de gestiune electronica a
cartilor din bibliotecile existente in tara.
El isi introduce identitatea si datele de
identificare ale cartii pe care doreste sa o
imprumute. Sistemul valideaza identitatea
abonatului si cauta cartea. Daca cartea
exista si abonatul are dreptul sa obtina un
nou imprumut atunci sistemul autorizeaza
imprumutul.
Pre-conditie: Daca este necesar, abonatul tebuie sa
execute mai intai procedura de acces la
sistem (log-in).
Post-conditie: In baza de date a sistemului exista o
inregistrare a imprumutului catre abonat
Cazuri de utilizare referite: Inregistrarea unui nou abonat
1. Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul
"Submit".
2. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
3. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
4. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si
codul ISBN al cartii apoi apasa butonul "Submit".
5. Sistemul cauta cartea.
5a) Daca sistemul nu gaseste cartea, se executa alternativa "Cartea nu exista".
5b) Daca autorul are deja imprumutat numarul maxim de carti admis, se executa alternativa
"Restrictia numarului de carti imprumutate".
6. Sistemul inregistreaza imprumutul.
7. Sistemul afiseaza utilizatorului datele necesare imprumutului.

Alternativa "Acces ne-autorizat"


1. Sistemul afiseaza un mesaj prin care invita utilizatorul sa se inregistreze ca abonat apoi incheie
sesiunea.

Alternativa "Cartea nu exista"


1. Sistemul afiseaza mesajul "Cartea solicitata nu ese inregistrata in bibliotecile noastre", apoi incheie
sesiunea.
Analog pentru alternativa 5b.

Pre-conditia este un predicat (in cazul de fata exprimat ne-formal) care exprima conditia care
trebuie sa fie satisfacuta inainte de inceperea cazului de utilizare. Post-conditia exprima conditia care
este satisfacuta dupa executia cazului de utilizare (conform descrierii secventei tipice!).

Descrierea unui caz de utilizare trebuie sa precizeze:


- cum si cand incepe si se termina cazul de utilizare - evenimente care marcheaza inceputul si
sfarsitul cazului;
- cand au loc interactiunile cu actorii si informatiile schimbate (comunicate intre actori - sistem) in
timpul fiecarei interaciuni;
- fluxul de baza (comportamentul de baza) si alternativele fiecarei interactiuni. Repetarile de
comportament, care pot fi descrise prin formulari de tipul: „ciclu …….activitati…., sfarsit ciclu” sau „cat
timp ….., sfarsit cat timp”

- pre-conditii si post-conditii;
Pentru a rezuma:
• 90% din modelul use-case este sub suprafaţa diagramelor use-case, schemele de sine sunt doar
prezentări generale ale comportamentului sistemului.
• Cea mai importantă parte a unui caz de utilizare este descrierea detaliată.
• Cea mai importantă parte a descrierii cazului de utilizare este fluxul de evenimente.
• Fluxul de evenimente are o structură bine definită care se învârte în jurul conceptelor de ‚flux de bază’
şi de ‚fluxuri alternative’.
• Fluxul de bază descrie modul normal de a realiza obiectivele cazului de utilizare.
• Fluxurile alternative extind fluxul de bază pentru a răspunde la variații şi excepţii.
• Sub-fluxurile pot fi folosite pentru a face un flux complex de evenimente mai uşor de citit.
• Cazuri de utilizare nu trebuie să pornească de la starea inițială a sistemului, dar se pot face presupuneri
cu privire la starea sistemului în momentul în care acestea încep.
• Pre-condiţiile si post-conditiile pot fi folosite pentru a clarifica domeniul de aplicare al unui caz de
utilizare şi documentează orice ipoteze făcute de autorii cazurilor de utilizare legate de starea sistemului.

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. În unele cazuri, cerințele de
utilizare şi cerințele de sistem pot fi integrate într-o singură descriere. În alte cazuri, cerințele de utilizare
sunt definite într-o introducere la specificaţia cerinţelor de sistem iar cerinţele de sistem detaliate sunt
prezentate într-un document separat.

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 posibile înseamnă că documentul 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 informaţii,
inclusiv despre evoluţia posibilă a sistemului. Informaţii cu privire la schimbările anticipate pot ajuta
designerii să evite deciziile restrictive de proiectare şi pot ajuta inginerii de sistem care trebuie să
adapteze sistemul la noile cerinţe.

Nivelul de detaliu pe care ar trebui să includă într-un Document 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, precum şi orice ambiguităţi rezolvate în timpul procesului de
dezvoltare a sistemului.

Un număr de organizaţii mari, cum ar fi Departamentul Apărării al SUA şi IEEE, au definit standardele de
documente Cerinţe. Standardul cel mai cunoscuteste IEEE ANSI 830-1998 (IEEE, 1998). Acest standard
IEEE sugerează următoarea structură pentru documente Cerinţe:
1. Introducere

1.1 Scopul documentului Cerinţe

1.2 Domeniul de aplicare al produsului software

1.3 Definiţii, abrevieri şi acronime

1.4 Referinţe

1.5 Privire de ansamblu asupra restului documentului

2. Descriere generală

2.1 Perspectiva asupra produsului

2.2 Funcţiile produsului

2.3 Caracteristicile utilizatorilor

2.4 Constrângeri generale

2.5 Ipoteze şi dependenţe

3. Cerinţele specifice acoperă cerinţele funcţionale, non-funcţionale şi de interfaţă. Aceasta este,


evident, partea cea mai substanţială a documentului, dar din cauza largii variații din practica
organizaţională, nu este necesar să se definească o structură standard pentru această secţiune. Cerinţele
pot documenta interfeţele externe, descrie functionalitățile sistemului şi performanţa lui, specifica din
punct de vedere logic cerinţele de baze de date, constrângerile de proiectare şi caracteristicile de
calitate.

4. Anexe

5. Index

Desigur, 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. În cazul în
care o abordare evolutivă este adoptată pentru un produs software (să zicem), Documentul de Cerințe
va lăsa pe dinafară mulţe dintre capitole detaliate sugerat mai sus. Accentul va fi pus pe definirea
cerinţelor non-funcţional de utilizare la nivel înalt. În acest caz, designeri si programatori folosesc
judecata lor pentru a decide cum să procedeze pentru a îndeplini cerinţele utilizatorilor.

Prin contrast, atunci când software-ul este parte a unui proiect mare de dezvoltare, care include
hardware şi software care interacţionează, este adesea 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 lungi şi ar trebui să
includă cele mai multe, dacă nu toate, capitolele prezentate mai sus.
Documentul Cerinţelor este esenţial atunci când un contractor extern este cel care dezvoltă sistemul. Cu
toate acestea, metodele Agile de dezvoltare susţin că cerinţele se schimbă atât de rapid ca un document
de cerinţe este învechit de îndata ce este scris, astfel efortul de este în mare parte timp pierdut. Mai
degrabă decât un document oficial, abordările cum ar fi Extreme Programming (Beck, 1999) propune ca
cerinţele utilizatorilor ar trebui să fie colectate progresiv şi scrise pe cartonaşe. Utilizatorul prioritizează,
apoi cerinţele pentru implementare în cadrul iterației următoare a sistemului.

Structura unui Document de Specificare a Cerințelor:

prefaţa Această parte ar trebui să definească pentru cititori utilitatea preconizată a documentului.
Ar mai trebui să descrie istoricul de versiuni, inclusiv o justificare pentru crearea
unei noi versiuni şi un rezumat al modificărilor făcute în fiecare versiune.
introducere Această parte ar trebui să descrie necesitatea sistemului. Ar trebui descrise, pe scurt,
funcţiile sale şi explica modul în care va funcţiona împreună cu alte sisteme. Acesta ar
trebui să descrie modul în care sistemul se potriveşte în general în mediul de afaceri sau
obiectivele strategice ale organizaţiei atinse de punerea în funcțiune a software-ului.
glosar În această parte ar trebui să se definească termenii tehnici folosiți în document.
Nu ar trebui să se facă presupuneri legate de experienţa sau expertiza cititorului.
Cerinţele Serviciile oferite utilizatorilor, atât funcționale cât şi non-funcţionale, şi
utilizatorilor definiţiile cerinţelor de sistem ar trebui să fie descrise în această
secţiune. Descrierea poate folosi un limbaj natural, diagrame sau alte notaţii care
sunt uşor de înţeles de către clienţi. Standardele de proces care vor fi urmate ar trebui să
fie specificate.
Arhitectura de Acest capitol ar trebui să prezinte o imagine de ansamblu, la nivel înalt, a
sistem sistemului anticipat care arată distribuţia funcţiilor software-ului pe module de
sistem. Componentele arhitecturale care sunt refolosite ar trebui să fie evidenţiate.
Specificaţia Acest capitol ar trebui să descrie cerinţele funcţionale şi non-funcţionale în mai mare
cerinţelor de detaliu. Dacă este necessar, detalii suplimentare pot fi, de asemenea, adăugate la
sistem cerinţele non-funcţionale (de exemplu, interfeţele cu alte sisteme pot fi definite).
Modele de In acest capitol trebuie să se stabilească unul sau mai multe modele de sistem care
sistem prezintă relaţiile dintre componentele sistemului şi relația dintre sistem şi
mediul său Acestea ar putea fi modelele de obiecte, modele de flux de date şi
modele semantice de date.
Evoluţia Acest capitol ar trebui să descrie ipotezele fundamentale pe care sistemul se
sistemului bazează şi să se anticipeze schimbările datorate de evoluţia hardware, nevoile în
schimbare ale utilizatorilor, etc
Anexe Acestea ar trebui să furnizeze informaţii detaliate, specifice
legate de sistemul care este în curs de dezvoltare. Exemple de anexe care pot
fi incluse sunt hardware-ul şi descrieri ale bazei de date . Cerinţele hardware definesc
configuraţii minime şi optime pentru sistem. Baza de date defineşte organizarea logică
a datelor utilizate de sistem şi relaţiilor dintre date.
Index Mai mulți indecşi pot fi incluşi în document. Pe lângă un index alfabetic normal,
mai poate fi creat un index de diagrame, un index de funcţii, etc.
PUNCTE CHEIE

- Cerinţe pentru un sistem software stabilesc ce ar trebui să facă sistemul şi definesc constrângeri
asupra operării şi implementării acestuia.
- Cerinţe funcţionale sunt enunțuri ale serviciilor pe care sistemul trebuie să furnizeze sau sunt
descrieri ale modului în care unele calcule trebuie să fie efectuate. Cerinţe de domeniu sunt
cerinţe funcţionale, care sunt derivate din caracteristicile domeniului de aplicare.
- Cerințele non-funcţionale constrâng sistemul în curs de dezvoltare şi proces de dezvoltare care
ar trebui să fie utilizat. Acestea pot fi: cerinţe de produs, cerinţe de organizație sau cerinţe
externe. Acestea se referă la sistem ca la un întreg.
- Cerinţele utilizatorilor sunt destinate utilizării de către persoane implicate în utilizarea şi achiziția
sistemului. Acestea trebuie să fie scrise folosind în limbaj natural, cu tabele şi diagrame care sunt
uşor de înţeles.
- Cerinţe de sistem sunt destinate să comunice, într-un mod precis, funcţiile pe care sistemul
trebuie să ofere. Pentru a reduce ambiguitatea, ele pot fi scrise într-o formă structurată de
limbaj natural completată de tabele şi modele de sistem.
- Documentul cerinţelor software este declaraţia, agreată în comun între beneficiar şi dezvoltator,
a cerinţelor de sistem. Ar trebui să fie organizat astfel încât atât clienţii cât şi dezvoltatorii de
software să-l poată folosi.
- Standardul IEEE pentru Documente de Specificare a Cerinţelor Software este un punct de plecare
util pentrumai multe implementări specifice.
EXERCIȚII

6.1 Identificați şi descrieţi, pe scurt, cele patru tipuri de cerinţe care pot fi definite pentru un software.

6.2 Discutați problemele de utilizare a limbajului natural pentru definirea cerinţelor de utilizare şi de
sistem, şi aratați, folosind exemple mici, cum structurarea limbajului natural poate ajuta la evitarea
unora dintre aceste dificultăţi.

6.3 Găsiți ambiguităţi sau omisiuni în următoarea declaraţie de Cerinţe pentru o parte a unui sistem de
emitere de bilet:

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ă seleceze 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ţiea a fost validată,
biletul este emis.

5.4 Rescrieți descrierea de mai sus folosind o abordare structurată descrisă în acestcapitol. Rezolvați
ambiguităţile identificate în mod adecvat.

6.5 Desenați o diagrama de secvenţă care arată acţiunile efectuate în sistemul de eliberare a biletelor. Se
pot face orice presupuneri rezonabile despre sistem. Acordaţi o atenţie deosebită specificării erorilor
făcute de utilizator.

6.6 Folosind tehnica sugerată pe parcursul capitolului, în cazul în care limbajul natural este prezentat
într-un mod standard, scrieți Cerinţ 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.

6.7 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.8 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.

6.9 Sugerați moduri în care un designer responsabil pentru dezvoltarea cerinţelor de sistem ar putea ţine
evidenţa relaţiilor dintre cerinţele funcţionale şi non-funcţionale.