Cerintele software

Cerintele pentru un sistem sunt descrieri ale serviciilor furnizate de catre sistem si
constrangerile sale operationale. Aceste cerinte reflecta nevoile clientilor pentru un sistem care
sa ii ajute sa rezolve diferite probleme cum ar fi controlul unui dispozitiv,introducerea unei
comenzi sau gasirea de informatii. Procesul de a gasi, analiza, documenta si verifica aceste
servicii se numeste procesul ingineriei(RE). Cateva dintre problemele care apar in timpul
cerintelor procesului de inginerie apar datorita esecului de a face o separare clara intre aceste
diferite niveluri de descriere. istinctia intre ele se face utilizand termenul cerintele
utilizatorului insemnand cerintele abstracte de inalt!nivel si cerinte de sistem insemnand
descrierea detaliata a ceea ce sistemul ar trebui sa faca. Cerintele utilizatorului si cerinte de
sistem pot fi definite dupa cum urmeaza"
#. Cerintele utilizatorului sunt declaratii, intr!un limbaj natural plus diagrame, a ceea
ce sistemul este de asteptat sa furnizeze si imprejurarile in care acesta trebuie sa functioneze.
$. Cerintele de sistem seteaza functiile, serviciile si constrangerile operationale in
detaliu. ocumentatia cerintelor de sistem trebuie sa fie precisa. Ea trebuie sa defineasca e%act
ceea ce trebuie implementat. Poate fi parte a contractului dintre cumparatorul sistemului si
creatorii software.
iferitele nivele ale sistemului sunt utile deoarece ele comunica informatii despre sistem
catre diferite tipuri de cititori. &igura '.# ilustreaza diferenta dintre utilizator si cerinte de sistem.
Acest e%emplu din biblioteca sistemului arata cum o cerinta a utilizatorului poate fi impartita in
mai multe cerinte de sistem. (e poate vedea din &igura '.# ca cerinta utilizatorului este mai
abstracta, in timp ce cerintele de sistem ofera multe detalii, e%plicand serviciile si functiile care
trebuie furnizate de catre sistem pentru a fi dezvoltat.
Fig.6.1
Este nevoie sa scriem cerintele la diferitele nivele ale detaliilor deoarece deferitele tipuri
de cititori le folosesc in diferite moduri. &ig.'.$ arata tipurile de cititori pentru cerintele
utilizatorului si cele de sistem. Cititorii cerintelor utilizatorului nu sunt de obicei interesati de
cum va fi implementat si administrat sistemul. Cititorii cerintelor de sistem au nevoie sa stie
pr)cis ceea ce va face sistemul deoarece ei sunt interesati de modul in care acesta va suporta
procesele sau din cauza ca ei sunt implicate in implementarea sistemului.
6.1. Cerintele functionale si non-functionale
Cerintele sistemului software sunt adesea clasificate drept cerinte functionale, cerinte
non!functionale sau cerinte de domeniu"
#. Cerinte functionale. Acestea sunt declaratii despre cum sitemul ar trebui sa
reactioneze la anumite date de intrare si despre cum sistemul ar trebui sa se comporte in anumite
situatii.
$. Cerinte non-functionale. Acestea sunt constrangeri privind serviciile sau functiile
oferite de catre sistem. Ele include constrangeri de timp, constrangeri privind dezvoltarea
proceselor si standard. Cerintele non!functionale se aplica de multe ori la sistem ca un ansamblu.
*. Cerintele de domeniu. Acestea sunt cerinte care provin de la domeniul de aplicatii
al sistemului si reflecta caracteristicile si constrangerile domeniului. Acestea pot fi cerinte
functionale sau cerinte non!functionale.
Fig.6.2
6.1.1 Cerintele functionale
Cerintele functionale pentru un sistem descriu ceea ce sistemul trebuie sa faca. Aceste
cerinte depind de tipul programului care v!a fi dezvoltat si de abordarea generala adoptata de
catre organizatie cand scrie cerintele. Cand sunt e%primate ca cerinte ale utilizatorului, aceste
cerinte sunt descrise de obicei intr!un mod abstract. Cu toate acestea , functional cerintele de
sistem descriu functiile sistemului in detaliu, intrarile si iesirile sale, e%ceptiile etc.
Cerintele functionale pentru un sistem software pot fi e%primate in mai multe moduri.
Avem un e%emplu de cerinte functionale pentru sistem de biblioteca al unei universitati numita
+,-(.(, folosit de catre student si facultate pentru a comanda carti si documente de la alte
biblioteci.
#. /tilizatorul trebuie sa poata cauta fie toate datele initiale ale bazei de date sau o
subcategorie a acesteia.
$. (istemul trebuie sa ofere datele corespunzatoare catre utilizator pentru a citi
documentul din baza de documente.
*. &iecarei comenzi trebuie alocat un identificator unic (0RER1,), pe care
utilizatorul sa poate sa!l copieze in zona de stocare permanenta a conturilor.

6.1.2 Cerintele non-functionale
Cerintele non!functioanale, asa cum si numele o sugereaza, sunt cerinte care nu sunt
direct legate de functiile specifice furnizate de catre sistem. Aceste se pot referi la proprietatile
sistemului care apar cum ar fi fiabilitatea, timpul de raspuns. Alternative , acestea pot define
constrangerile sistemului cum ar fi capacitatile dispozitivelor ,20 si reprezentarile datelor
utilizate in interfata sistemului.
Fig.6.3
3ipurile de cerinte non!functionale sunt"
#. Cerintele produsului. Aceste cerinte specifica comportamentul produsului.
E%emplele includ cerinte de performanta despre cat de repede sistemul trebuie sa e%ecute
comenzile si de cata memorie are nevoie4 cerintele de fiabilitate care stabilesc rata de esec
acceptata4 cerintele de portabilitate4 cerintele de uzabilitate.
$. Cerintele organizatorice. Aceste cerinte deriva din procedurile si politica clientilor
si dezvoltatorilor. E%emplele includ procedurile standard care trebuie utilizate4 cerintele de
implementare cum ar limbajul de programare sau metoda de programare folosita4 cerintele de
livrare care specifica cand produsul si documentatia va fi livrata.
*. Cerintele externe. Aceasta rubrica larga acopera toate cerintele care sunt derivate
din factori e%terni sistemului si procesului sau de dezvoltare. Acestea pot include cerinte de
interoperabilitate care definesc cum interactioneaza sistemul cu alte sisteme din alte organizatii4
cerinte legislative care trebuie urmate de asigurarea ca sistenmul opereaza in cadrul legii4 cerinte
de etica. Cerintele de etica sunt cerinte introduse in sistem pentru a se asigura ca va fi acceptat
atat de utilizatorii sai cat si de publicul larg.

Fig.6.4
&igura '.5 arata e%emple de cerinte de la produs, de organizare si e%terne luate de la
sistemul de biblioteci +,-(.( ale caror cerinte ale utilizatorului au fost discutate in sectiunea
'.#.#. Cerinta de produs restrictioneaza libertatea proiectantilor +,6(.( in implementarea
interfetei sistemului cu utilizatorul. Ea nu spune nimic despre functionalitatea +,-(.( si
identifica in mai degraba o constangere a sistemului decat o functie a acestuia. Aceasta cerinta a
fost inclusa deoarece simplifica problema asigurarii sistemului de a functiona cu browsere
diferite.
Cerinta de organizare specifica faptul ca sistemul trebuie dezvoltat in conformitate cu
procesele standard ale companiei definite ca 7.8Co!(P!(3A6!9:. Cerintele e%terne provine
din necesitatea c sistemul sa se conformeze legislatiei de confidentialitate. Ea prevede ca
personalului bibliotecii nu ar trebui sa , se permita accesul la date, cum ar fi adresele
utilizatorilor sistemului.
0 problema care apare la cerintele non!functionale este aceea ca ele sunt dificil de
verificat. /tilizatorii sau cumparatorii adesea plaseaza aceste cerinte drept obiective generale
cum ar fi usurinta in utilizare, capacitatea sistemului de a!si reveni in urma unui esec sau
raspunsul rapid la comenzile utilizatorului. Aceste obiective vagi cauzeaza probleme
dezvoltatorilor de sistem deoarece ele lasa loc de interpretari odata ce sistemul a fost livrat. /n
e%emplu de astfel de problema este prezentat in &igura '.:
Fig.6.5
0ricand este posibil, ar trebui scrise un numar de cerinte non!functionale astfel incat sa
poata fi testate obiectiv. &igura '.' arata un numar de valori posibile pe care le putem folosi
pentru a specifica proprietatile non!functionaleale sistemului. (e pot masura aceste caracteristici
cand sistemul este in curs de testare pentru a vedea daca sistemul a indeplinit sau nu cerintele
sale non!functionale.
,n practica, totusi, clientii unui sistem pot gasi ca este practice imposibil sa traduca
obiectivele lor in cerinte cantitative. Pentru unele obiective, cum ar fi intretinerea sistemului, nu
au valori care pot fi folosite. ,n alte cazuri, c;iar daca specificatia cantitativa este posibila,
clientii nu vor putea e%pune nevoile lor acestor specificatii. ,n plus, costul verificarii in mod
obievtiv a cantitatii de cerinte non!functionale poate fi foarte mare, si clientii care platesc pentru
sistem nu vor gasi justificat sa plateasca aceste costuri in plus.
Prin urmare, documentele cu cerinte includ adesea declaratii de obiective impreuna cu
cerintele. Aceste obiective pot fi folositoare dezvoltatorilor deoarece ofera indicii despre
prioritatiile clientilor. Cu toate acestea, trebuie spus clientilor ca caestea pot suferi interpretari
gresite si ca nu pot fi verificate in mod obiectiv.
Cerintele non!functionale intra adesea in conflict si interactioneaza cu alte cerinte
functionale si non!functionale. e e%emplu, pot contine o cerinta prin care sa ceara ca memoria
ma%ima folosita de catre sistem sa nu fie mai mare de 5 <b=tes. 0 alta cerinta ar putea fi ca
sistemul sa fie scris folosind Ada, un limbaj de programare critic, program de dezvoltare in timp!
real. 3otusi, este posibil sa nu poata fi compilat un program Ada la parametrii impusi in mai
putin de 5<b=tes.
Este de ajutor daca avem posibilitatea de a diferentia cerintele functionale si cele non!
functionale in documentul de cerinte. ,n practica, acest lucru este dificil de realizat. aca
cerintele non!functionale sunt prezentate separate de cerintele functionale, este uneori dificil sa
vedem relatiile dintre acestea. aca sunt prezentate cu cerintele functionale, este dificil de
separate consideratiile functionale si non!functionale si de identificat cerintele care se refera la
sistem in ansamblu.
Cerintele non!functionale cum ar fi cerintele de siguranta si cele de securitate sunt foarte
importante pentru sistemele critice.
Fig.6.6
6.1.3 Cerintele de domeniu
Cerintele de domeniu rezulta mai degraba din domeniul de aplicare al sistemului decat
din nevoile specific ale utilizatorului sistemului. Ele include de obicei terminologii specializate
ale domeniului sau fac referire la conceptele domeniului. Acestea pot fi noi cerinte functionale
sau constrangeri asupra cerintelor functionale e%istente. eoarece aceste cerinte sunt
specializate, inginerii software inteleg cu dificultate cum aceste cerinte sunt legate de alte cerinte
ale sistemului.
Cerintele de domeniu sunt importante deoarece acestea reflecta lucrurile fundamentale
ale domeniului de aplicare. aca aceste cerinte nu sunt indeplinite, este imposibil sa facem ca
sistemul sa functioneze satisfacator. (istemul +,-(.( include un anumit numar de cerinte de
domeniu"
#. 3rebuie sa e%iste o interfata de utilizator standard pentru toate bazele de date care sa
se bazeze pe standardul 8*9.:>.
$. in cauza restrictiilor dreptului de autor, anumite documente sterse imediat la
sosire. ,n functie de cerintele utilizatorilor, aceste documente vor fi tiparite fiecare pe server!ul
sistemului local pentru o redirectionare manuala catre utilizator sau directionate intr!o retea a
imprimantei.
6.2 Cerintele utilizatorului
Cerintele utilizatorului pentru un sistem trebuie sa fie capabile sa descrie cerintele
functionale si non!functionale astfel incat sa fie intelese de catre utilizatorii sistemului fara
cunostinte te;nice detaliate. Acestea ar trebui sa specific numai comportamentul e%tern al
sistemului si trebuie sa evite, pe cat posibil, caracteristicile de proiectare ale sistemului, in
consecinta, daca scriem cerintele utilizatorului, nu trebuie sa folosim jargon software, notatii
oficiale, sau sa descriem cerinta folosindu!ne de descrierea implementarii sistemului.
Cu toate acestea, problem diverse pot aparea cand cerintele sunt scrise intr!un limbaj
natural intr!un document te%t"
#. Lipsa claritatii. /neori este dificil de folosit un limbaj precis si lipsit de
ambiguitate fara a face documentul dificil de citit.
$. Cerinte confuze. Cerintele functionale, cerintele non!functionale, obiectivele
sistemului si informatia de proiectare nu pot fi distinse in mod clar.
*. Cerinte comasate. <ai multe cerinte diferite pot fi e%primate impreuna ca o
singura cerinta.
Cerintele utilizatorului care include prea multe informatii restrang libertatea
dezvoltatorului sistemului de a furniza solutii inovatoare pentru problemele utilizatorilor si sunt
dificil de inteles. Cerinta utilizatorului trebuie sa se concentreze doar pe facilitatile esentiale care
urmeaza sa fie furnizate.
Pentru a minimiza neintelegerile cand sunt scrise cerintele utilizatorului, trebuie urmate
cateva instructiuni simple"
#. 3rebuie creat un format standard si sa ne asiguram ca toate definitiile cerintei
respecta acest format. e asemenea pot fi incluse informatii dspre cine a propus cerinta(sursa
cerintei) astfel incat sa stim unde sa cautam atunci cand cerinta a fost modificata.
$. Folosirea unui limba in mod constant. 3rebuie sa facem distinctia intotdeauna
intre cerintele obligatorii si cele facultative. Cerintele obligatorii sunt cerinte pe care sistemul
trebuie sa le accepte si sunt de obicei scrise folosind ?s;all@. Cerintele facultative nu sunt
esentiale si sunt scrise folosind ?s;ould@.
*. /tilizarea sublinierea te%tului(bold, italic sau colour) pentru a evidential cuvintele
c;eie ale cerintei
5. Evitarea, pe cat posibil, utilizarea jargonului din domeniul calculatorului, ,nsa,
inevitabil, detalierea termenilor te;nici se vor strecura in cerintel utilizatorului.
6.3 Cerintele sistemului
Cerintele sistemului sunt versiuni e%tinse ale cerintelor utilizatorului care sunt folosite de
catre inginerii software ca punct de plecare pentru proiectarea sistemului. Ele adauga detalii si
e%plica modul in care cerintele utilizatorului ar trebui sa fie furnizate de catre sistem.
,deal, cerintele sistemului pur si simplu ar trebui sa descrie comportamentul e%tern al
sistemului si constrangerile sale operationale. 6u ar trebui sa fie preocupate de modul in care
sistemul ar trebui sa fie proiectat sau implementat. Cu toate acestea, la nivelul de detaliere cerut
pentru a specifica in totalitate un sistem software comple%, este imposibil, in practica, sa fie
e%cluse toate informatiile de proiectare. E%ista mai multe motive pentru aceasta"
#. Este posibil sa fie nevoie sa se proiecteze o ar;itectura initiala a sistemului care sa
ajute la structurarea cerintelor specificate. Cerintele de sistem sunt organizate in functie de
diferite sub!sisteme care alcatuiesc sistemul.
$. ,n cele mai multe cazuri, sistemele trebuie sa interactioneze cu alte sisteme
e%istente. Acestea constrang proiectarea, iar aceste constrangeri impugn cerinte privind noul
sistem.
+imbajul natural este adesea folosit pentru a scrie specificatiile cerintelor de sistem
precum si cerintele utilizatorului. Cu toate acestea, din cauza faptului ca cerintele sistemului sunt
mai etaliate decat cele ale utilizatorului, specificatiile limbajului natural pot fi confuze si greu de
inteles"
#. ,ntelegerea limbajului natural se bazeaza pe specificatiile cititorilor si scriitorilor
folosind aceleasi cuvinte pentru acelasi concept. Acest lucru duce la neintelegeri din cauza
ambiguitatii limbajului natural.
$. (pecificarea cerintelor intr!un limbaj natural este fle%ibila. (e pot gasi aceleasi
lucruri dar in moduri complet diferite. Este la latitudinea cititorului pentru a afla cand cerintele
sunt aceleasi si atunci cand acestea sunt distincte.
Este esential ca cerintele utilizatorului sa fie scrise intr!un limbaj pe care nespecialistii sa!
l poata intelege. Cu toate acestea, se pot scrie cerintele sistemului folosond mai multi termini
stiintifici(&ig.'.A)
Fig.6.!
6.3.1 "pecificatiile limbaului structurat
+imbajul natural structurat este o metoda de scriere a cerintelor sistemului unde libertatea
cerintelor scriitorului este limitata si toate cerintele sunt scrise printr!o metoda standard.
Avantajul acestei abordari este aceea ca mentine majoritatea e%presivitatii si intelegerii
limbajului natural. 6otatiile limbajului structurat limiteaza terminologia care poate fi folosita si
foloseste sabloane pentru a specifica cerintele sistemului. Acestea pot contine constructii de
control derivate din programarea limbajelor si evidentierea grafica pentru a imparti caietul de
sarcini.
Ca sa putem folosi abordarea form!based pentru a specifica cerintele sistemului trebuie sa
definim una sau mai multe forme standard sau sabloane pentru a e%prima cerintele. Caietul de
sarcini poate fi structurat in jurul obiectelor manipulate de catre sistem. /n e%emplu de un
asemenea caiet de sarcini form!based este prezentata in &igura.'.B.
Fig.6.#. Caietul de sarcini al cerintelor sistemului folosind o forma
standard
Cand o forma standard este utilizata pentru a specifica cerintele functionale, informatiile
urmatoare trebuie incluse"
#. escrierea functiei sau a entitatii ce a fost specificata4
$. escrierea intrarilor sale si de unde vin acestea4
*. escrierea iesirilor sale si unde se duc4
5. ,ndicarea daca alte entitati sunt folosite(partea cu cerinte)4
:. escrierea actiunii care urmeaza a fi indeplinita4
'. aca o abordare functional este folosita, o preconditie care seteaza ceea ce trebuie
sa fie adevarat inainte ca functia sa fie apelata si o postconditie care specific ace
este adevarat dup ace functia este apelata4
A. escrierea efectelor secundare (daca e%ista) ale operatiei.
/tilizand specificatii formatate se inlatura cateva din problemele limbajului natural al
caietului de sarcini. Cariabilitatea caietului de sarcini este redusa si cerintele sunt organizate mai
efficient. 3otusi, este dificil sa se scrie cerintele intr!o cale ambigua, in mod special cand sunt
cerute calcule comple%e. (e poate vedea acest lucru in figura '.B, unde nu este afisat in mod clar
ce se intampla daca preconditia nu este indeplinita.
'.5. "pecificatiile interfetei
Aproape toate sistemele software trebuie sa opereze cu sistemele e%istente care au fost
deja instalate si implementate in mediu. aca noul sistem si sistemul e%istent trebuie sa lucreze
impreuna, interfata sistemului e%istent trebuie specificata precis. Aceste specificatii trebuie
definite devreme in proces si incluse in documentul specificatiilor.
(unt trei tipuri de interfete care trebuie definite"
#. ,nterfete procedurale unde programele e%istente sau sub!sistemele ofera o gama
larga de service ce pot fi accesate apeland procedurile interfetei.
$. (tructurile de date sunt transferate de la un sub!sistem la altul.
*. Reprezentarile de date(cum ar fi comanda bitilor) care au fost stabilite prentru un
sub!sistem e%istent. Aceste interfete sunt prezente mai ales in sistemele embedded si in sistemele
in timp real.
&igura '.9 este un e%emplu al unei definiti de interfata procedural definite in Dava. ,n acest
caz, interfata este o interfata procedural oferita de catre un server de imprimare. &igura '.9 este
un model abstract care nu evidentiaza nici un detaliu al interfetei.
Fig.6.$
6.5.%ocumentul cerintelor soft&are
ocumentul cerintelor software este declaratia oficiala a ceea ce dezvoltatorii software
trebuie sa implementeze. Ar trebui sa include atat cerintele utilizatorului pentru un sistem cat si o
specificare detaliata a cerintelor sistemului. ,n unele cazuri, cerintele sistemului si ale
utilizatorului pot fi incluse intr!o singura descriere. ,n alte cazuri, cerintele utilizatorului sunt
definite in introducerea caietului de sarcini al cerintelor sistemului, daca sunt prezente un numar
mare de cerinte, detalierea cerintelor sistemului poate fi prezentata intr!un document separate.
6ivelul de detaliere care trebuie inclus in documentul cerintelor depinde de tipul
sistemului care este in curs de dezvoltare si de procesul de dezvoltare utilizat. Cand sistemul va
fi dezvoltat de catre un contractor e%tern, specificatiile critice ale sistemului trebuie sa fie precise
si foarte detaliate.