Lucrarea practic nr.

1
TEMA: Specificarea cerinelor software
SCOPUL LUCRRII:
1. Formarea deprinderilor de a formula ntrebri concise i logice fa de client n cea ce privete
produsul solicitat i de a putea descrie rspunsul la aceste ntrebri sub forma unor cerine fa de
produsul soft.
2. Formarea abilitilor de a aduna cerinele ntr-un document al cerinelor utilizatorului (Specificaia
Cerinelor Software).

NOIUNI TEORETICE:
1. Cerina
Noiunea de cerin este mai veche dect dezvoltarea programelor. De exemplu, o cerin pentru o
locomotiv ar putea arta astfel: pe o cale ferat uscat, locomotiva trebuie s fie capabil s porneasc un
tren de 100 tone pe o pant de maxim 5% cu o acceleraie de cel puin 0,5 m/s 2. De remarcat c aceast
cerin spune ce vrea clientul. Nu spune nimic despre cum ar putea fi realizat. Nu se specific tipul
motorului (cu aburi, diesel, electric) sau materialul din care s se confecioneze roile.
Cea mai complet (i, desigur, cea mai recunoscut) definiie a cerinei este dat de Institute of
Electrical and Electronics Engineers (IEEE). Conform acestei organizaii, prin standardul 610.12-1990
IEEE Standard Glossary of Software Engineering Terminology, cerina software este definit astfel:
Cerina software este:
1. o condiie sau capabilitate necesar a fi ndeplinit de ctre un sistem, pentru ca un utilizator s
poat rezolva o anumit problem sau s ating un anumit obiectiv;
2. o condiie sau capabilitate pe care un sistem trebuie s o realizeze sau s o posede pentru a
satisface un contract, standard, specificaie sau alt document formal impus;
3. un document reprezentarea unei condiii sau capabiliti, aa cum este descris la punctele 1 i
2 de mai sus.
Mai nainte de a analiza aceast definiie vom clarifica termenul "capabilitate" utilizat aici.
Capabilitile desemneaz ceva ce un sistem software furnizeaz utilizatorilor, fie un anumit
comportament fie un anumit atribut. Dei termenul provine din englezescul "capability", limba romn
are aici privilegiul de a avea pentru capabilitate o descriere intuitiv: ea desemneaz ceva ce un sistem
este capabil s fac, ceva ce sistemul poate.
Printr-o capabilitate a unui sistem putem desemna fie un comportament fie un atribut. De pild, o
funcionalitate de genul sistemul valideaz formatul datei atunci cnd utilizatorul nregistreaz factura n
sistem este un comportament al sistemului, n timp ce poziia unui buton pe ecran este un atribut. (Mai
pe romnete, n final, un cmp dintr-o baz de date sau o proprietate a unui obiect poate corespunde unui
atribut al unei entiti, n timp ce o metod a unui obiect nseamn comportament.)
Revenind la definiia cerinei, vom detalia pe scurt cele trei pri ale definiiei.
Prima parte, reprezint punctul de vedere al utilizatorului. Centrul ateniei este, la acest punct,
utilizatorul care are nevoie ce ceva pentru a rezolva o problem sau pentru a atinge un obiectiv. Aceast
parte a definiiei ne spune clar c dac problema/obiectivul utilizatorului nu poate fi specificat, atunci
cerina nu exist. O cerin exist atta timp ct ea reprezint soluia pentru o problem a utilizatorului.
A doua parte a definiiei reprezint punctul de vedere al dezvoltatorului. Aici "o condiie sau
capabilitate pe care un sistem trebuie s o realizeze" este ceea ce dezvoltatorul trebuie s realizeze. Aa
cum se poate vedea din definiie, pentru el referina este un "document formal impus". Vom vedea n
capitolele urmtoare c aici nu este vorba despre o descriere a funciilor aa cum se dezvolt ele n limbaj
de programare ci sunt capabiliti care pot fi nelese, au o logic i pot fi validate i de ctre utilizatorul
sistemului, fr ca acesta s tie programare.
1

Partea a treia a definiiei exprim un punct de vedere comun, sau un punct de vedere general, o
regul de baz: primele dou puncte de vedere nu pot exista dac nu exist documentul pe care ambele
pri s l poat folosi ca referin. Dac documentul nu exist, cele dou puncte de vedere, precum i
evoluia lor n timp nu au un element comun palpabil i fr echivoc, o referin acceptabil.
Aadar, conform punctului 3 din definiia cerinei, o cerin care nu este documentat nu exist.
Observm, din definiia de mai sus, c cerina, privit din partea utilizatorului sistemului este ceva
util pentru rezolvarea unei probleme, n timp ce, pentru dezvoltator cerina este ceva ce el trebuie s
dezvolte, conform specificaiei. Ca urmare, cerina trebuie exprimat n aa fel nct s poat fi
interpretat fr dubii de ambele pri, pentru c ea este destinat n egal msur ambelor pri.
Pe de o parte, pentru utilizator este important rezolvarea propriilor probleme, fr ca detaliile
tehnice ce in de rezolvarea lor s fie relevante. De cealalt parte, dezvoltatorul are nevoie de o referin
pentru a ti ce s dezvolte, n timp ce problemele utilizatorului au relevan mai sczut. Aici, la mijloc
ntre cei doi se situeaz Analistul software i produsul munci sale: cerina software un document care
arat utilizatorului soluia problemei lui iar dezvoltatorului ce trebuie s dezvolte.
Cerinele pot fi mprite n urmtoarele categorii (niveluri) ale cerinelor software [1]:
A. Cerine de business: acestea sunt cerinele de pe cel mai nalt nivel i sunt obiectivele (sau
problemele) de nivel nalt ale clientului. Aceste cerine sunt de obicei descrise ntr-un document denumit
Vision & Scope.
B. Cerine utilizator: pe acest nivel sunt sarcinile pe care utilizatorul le va putea ndeplini utiliznd
produsul software. Aceste cerine sunt specificate de obicei sub form de use case-uri.
C. Cerine funcionale: sunt cerinele adresate direct viitorului Sistem, funcionalitile care trebuie
dezvoltate pentru ca utilizatorii s i poat ndeplini sarcinile. Acest nivel este nivelul cel mai apropiat de
proiectarea sistemului.
D. Cerinele nefuncionale: acestea pot fi cerine legate de atributele de calitate a produsului, cerine
privind performana, respectarea unor standarde, regulamente, contracte, interfee externe sau alte
constrngeri de design.

2. Extragerea cerinelor
Presupunem c analistul i clientul lucreaz mpreun, fiecare ncercnd s l neleag pe cellalt.
Esena procesului de obinere a cerinelor este comunicarea. Se disting trei activiti majore care conduc la
obinerea unei specificri a cerinelor:

Ascultare: analistul nregistreaz cerinele clientului;

Gndire: analistul ncearc s traduc cerinele clientului n limbaj tehnic i s se asigure de
pertinena cerinelor n acest context;
Scriere: analistul i clientul cad de acord asupra unor formulri ale cerinelor pe care analistul le
consider pertinente.

Aceste activiti sunt parte a unui proces iterativ, lung i complicat. Negocierea este foarte
important. Diferena cultural dintre client i analist este cteodat foarte mare. Exist situaii cnd exist
diferene semnificative ntre ateptrile utilizatorilor finali i ale clientului. Un exemplu concret al acestui
tip de conflict este cnd un patron ce comand un program care s fie utilizat de ctre angajaii si dorete
ca acesta s conin module de monitorizare a muncii angajailor. Aceasta ridic o dilem de natur etic
pentru inginerul programator: s anune angajaii c sunt spionai fr s tie sau s fie loial celui care l
pltete. O alt problem o reprezint literatura SF studiat de client, nainte de angajarea echipei de
dezvoltare. Clientul ateapt mult prea mult de la program i de la echipa de dezvoltare, nchipuindu-i c
programele se scriu ca n filme, ntr-o scen de dou minute, ca un amnunt dintr-un film de dou ore.
n concluzie, analistul trebuie:

s extrag i s clarifice cerinele clientului;

s ajute la rezolvarea diferenelor de opinie ntre clieni i utilizatori;
s sftuiasc clientul despre ce este tehnic posibil sau imposibil;
2

s documenteze cerinele;
s negocieze i s obin o nelegere cu clientul.

3. Metode pentru identificarea cerinelor utilizatorilor

Una sau mai multe din urmtoarele modele prezentate mai jos pot fi folosite pentru a identifica
cerinele utilizatorului:

Interviuri: Interviurile trebuie astfel structurate nct s poat aborda toate aspectele
implicate de sistemul software ce va trebui dezvoltat. Cnd exist foarte muli utilizatori, se
va selecta un set reprezentativ dintre acetia pentru a fi intervievai. Interviurile pot fi utile n
a asigura:
o completitudinea cerinelor utilizatorului;
o existena unei acceptri generale a cerinelor utilizatorului;
Studiul sistemelor software existente deja: De multe ori, noul sistem software este destinat
nlocuirii altui sistem existent. Investigarea caracteristicilor i bune i rele ale sistemului existent
poate ajuta n determinarea cerinelor pentru ceea ce se dorete. Examinarea manualelor
utilizatorilor, a documentelor cerinelor i a diverselor propuneri poate fi foarte folositoare;
Studiul de fezabilitate: Studiul de fezabilitate reprezint analiza i proiectarea principalelor
caracteristici ale sistemului n scopul de a determina dac implementarea este posibil;
Prototipul: Un prototip este un model executabil al unor aspecte selectate din sistemul propus.
Dac cerinele sunt neclare sau incomplete, ar putea fi util dezvoltarea unui prototip, bazat pe un
set de cerine de prob, pentru a identifica cerinele reale ale utilizatorilor.

4. Metode pentru specificarea cerinelor utilizatorilor

4.1. Limbajul natural
Modul evident de specificare a unei cerine este limbajul natural. Limbajul natural este foarte
accesibil dar inconsistent i ambiguu. De exemplu, afirmaia: Baza de date va conine o adres poate fi
interpretat dup cum urmeaz:
Va fi doar o singur adres
O parte din baza de date va fi desemnat ca o adres.
Va fi cel puin o adres n baza de date.
4.2. Formalismul matematic
Formule matematice pot fi folosite pentru a clarifica o cerin. Toate simbolurile folosite ntr-o
expresie trebuie definite sau referite.
4.3.

Engleza structurat

Engleza structurat este un limbaj de specificare care folosete un vocabular i o sintax foarte
limitate.
Vocabularul const doar din:

verbe imperative ale limbii engleze;

termeni definii ntr-un glosar;
cuvinte rezervate.
Sintaxa e limitat la urmtoarele posibiliti:

simple construcii declarative;

construcii decizionale;
3

construcii repetitive.
Engleza structurat este folosit de obicei pentru a descrie procesele de baz ale sistemului.
Exemple:

construcii declarative
GET RAW DATA
REMOVE INSTRUMENT EFFECTS
CALIBRATE CORRECTED DATA
construcii decizionale
IF SAMPLE IS OF NOMINAL QUALITY THEN
CALIBRATE SAMPLE ELSE
STORE BAD SAMPLE
construcii repetitive
FOR EACH SAMPLE
GET POINTING DIRECTION AT TIME OF SAMPLE
STORE POINTING DIRECTION WITH SAMPLE

Formaliznd engleza structurat se poate automatiza prelucrarea cerinelor (verificarea automat,

o analiz automat, transformri i afiri) i se poate simplifica definirea testelor pentru faza de
verificare i validare a sistemelor.
4.4.

Tabele

Tabelele reprezint o metod de descriere concis i complet a cerinelor. Aceast metod poate
rezuma anumite relaii, interaciuni ntre cerine mai eficient dect o prezentare textual.
4.5.

Diagrame bloc ale sistemului

Diagramele bloc reprezint modul tradiional de prezentare a proceselor dorite. Ele pot, de
asemenea, demonstra contextul n care sistemul va opera atunci cnd este o parte dintr-un sistem mai
mare.

5. Documentul cerinelor utilizatorului (DCU)

Acesta este documentul obligatoriu, produs n faza definirii cerinelor i trebuie s fie finalizat
nainte de proiectarea sistemului. DCU trebuie:

s furnizeze o descriere general ceea ce utilizatorul dorete s execute sistemul;

s conin toate cerinele cunoscute, ale utilizatorilor;
s descrie toate operaiile pe care le va executa sistemul;
s descrie toate restriciile impuse sistemului;
s defineasc toate interfeele externe ale sistemului sau s conin referine despre ele n alte
documente.

Costul modificrii cerinelor crete cu att mai mult cu ct proiectul nainteaz n fazele
urmtoare. n faza de testare a sistemului, verificarea se va face pe baza DCU. Standardele ingineriei
programrii recomand urmtoarele caracteristici ale stilului de prezentare a unui DCU:

DCU trebuie scris folosind un limbaj, vocabular i stil uor de neles de ctre toi utilizatorii.
DCU trebuie s fie clar, consistent, modificabil;
Un DCU este clar dac orice cerin este neambigu (are o singur interpretare) i este neleas
de toi participanii la proiect;
O cerin trebuie scris ntr-o singur propoziie iar justificrile trebuie separate de aceasta. Se
recomand ca cerinele corelate ntre ele s fie grupate. Structurarea cerinelor n document este
foarte important;
4

Un DCU este consistent dac nu exist conflicte ntre cerine. Folosirea mai multor termeni pentru
a specifica acelai lucru este un exemplu de inconsisten;
Un DCU este modificabil dac orice modificare a cerinelor poate fi documentat uor, complet i
consistent.
5.1. Evoluia DCU

Modificrile inevitabile ale DCU sunt responsabilitatea utilizatorului. E necesar pstrarea unei
istorii a modificrilor efectuate. Problema actualizrii ntregii documentaii va fi rezolvat cnd va fi
stabilit o arhitectur electronic standard pentru documente. Dac schimbrile cerinelor sunt rezolvate
direct n faza de implementare, fr a mai fi prinse n documentaie, aceasta poate provoca serioase
probleme n faza de ntreinere a sistemului. Iniiatorul proiectului ar trebui s monitorizeze tendina n
apariia unor noi cerine ale utilizatorului. O tendin cresctoare va periclita succesul proiectului.
5.2. Responsabiliti
Se pun n eviden urmtoarele recomandri:

definirea clar a tuturor responsabilitilor nainte de nceperea DCU;

utilizatorii reali ai sistemului sunt responsabili pentru determinarea cerinelor de
capabilitate;
inginerii software trebuie s ia parte la formarea DCU pentru a-i ajuta pe utilizatori;
indiferent de organizare, utilizatorii nu trebuie s dicteze soluii iar echipa de dezvoltare nu trebuie
s dicteze cerine.
5.3. Coninutul DCU

Structura general a unui DCU, recomandat de standardul ingineriei programrii, este prezentat
n continuare:
1. Introducere
2. Descriere general
3. Cerine specifice
Seciunea 1 trebuie s descrie pe scurt scopul sistemului software, listele de definiii pentru
termeni utilizai n document, lista de referine bibliografice identificate prin autor, titlu i date, i o
trecere n revist a restului documentului.
Seciunea 2 se refer la:

capabilitile generale ale sistemului i de ce sunt ele necesare;

constrngerile generale i motivul pentru care au fost impuse;
caracteristicile generale ale utilizatorilor sistemului (nivelul educaiei lor, limbajul, experiena lor
tehnic pot impune importante constrngeri asupra software-ului) din fazele de operare i
ntreinere ale sistemului. Este important clasificarea acestor utilizatori i estimarea numrului
lor, n fiecare categorie;
mediul extern n care sistemul va opera, prin diagrame de context pentru a evidenia interfeele
externe i prin diagrame bloc pentru a evidenia activitile din ntregul sistem;
situaiile de risc evideniate n urma analizei riscurilor.

Seciunea 3 este partea principal a DCU, prezentnd toate cerinele de capabilitate i cerinele
restrictive ale sistemului. Validitatea sistemului software se va face pe baza acestor cerine. Se recomand
urmtoarele caracteristici:
5

Fiecare cerin trebuie unic identificat;

Fiecare cerin trebuie marcat n funcie de importana sa (unele pot fi extrem de importante,
altele inacceptabile, altele suspendate pn la obinerea unor resurse necesare, altele sunt
prioritare, instabile);
Fiecare cerin trebuie s fie verificabil. O afirmaie trebuie s conin o singur cerin. O
cerin e verificabil dac exist o metod ce demonstreaz obiectiv c ea este asigurat de sistem.
(Afirmaii ca: interfaa utilizator va fi prietenoas, sistemul va merge bine, nu sunt verificabile
deoarece termenii bine, prietenos nu au interpretri obiective). Dac nu exist o metod pentru
verificarea acestei cerine, aceasta este invalid.

6. Caracteristicile cerinelor software

Atunci cnd sunt culese, analizate i specificate cerinele trebuie s se ia n consideraie c,
indiferent de forma n care sunt specificate, n limbaj natural, n UML sau n orice alt limbaj, sub form
de use case-uri sau full text, indiferent de tipul lor, cerinele trebuie s aib anumite caracteristici care le
fac s fie cerine adevrate, corect specificate i posibil de realizat, n parametrii bugetari i de calitate
determinai.
Privit dintr-o parte cerina se vede ca o problem a unui client, privit din cealalt parte este o
soluie furnizat de un anumit sistem. De aceste dou faete ale ei depind caracteristicile cerinelor
software.
Aceste caracteristici sunt, n principal, urmtoarele:
1. Necesar
O cerin exist dac i numai dac este necesar. Amintind de prima parte a definiiei de mai sus,
putem spune c cerina exist dac exist o problem real de la care pornete. n caz contrar cerina nu
exist.
Aceast caracteristic este extrem de util pentru managementul cerinelor, problema din spatele
cerinei fiind, n mod necesar, o frunz din decompoziia problemei mari a proiectului.
2. Corect
O cerin este corect dac faeta denumit soluie este, nimic altceva dect soluia corect la
problema dat.
De exemplu, un use case care este gndit pentru realizarea unui anumit task este corect dac
niruirea pailor descrii conduce la realizarea, fr dubii, a task-ului. n caz contrar cerina descris
astfel nu este corect.
3. Complet
O cerin este complet dac reprezint o soluie complet pentru rezolvarea complet a problemei.
Dei cazurile de incompletitudine sunt greu de descoperit, organizarea de review-uri formale cu
participarea oamenilor tehnici din echipa de dezvoltare, de obicei d rezultate.
4. Consistent
O cerin este considerat consistent dac nu intr n contradicie cu alt cerin. De exemplu,
urmtoarele cerine sunt inconsistente:
- autovehiculul se va deplasa cu viteza maxim de 100 km/h;
- autovehiculul va parcurge 200 de km n maximum o or.
5. Verificabil
O cerin este verificabil (testabil) dac permite realizarea validarea fr echivoc a soluionrii ei
prin msurare sau testare. De exemplu, sistemul va permite derularea optim a activitii, timpul de
rspuns va fi ct mai mic cu putin sau sistemul va putea fi accesat de un numr mare de utilizatori
simultan sunt cerine care nu pot fi verificate n mod cert, fr dubii.
Oricnd se poate pune ntrebarea ce nseamn derularea optim a activitii, cnd se poate spune c
inta a fost atins?
6. Clar (fr ambiguiti)
O cerin poate fi considerat lipsit de ambiguiti atunci cnd poate fi interpretat ntr-un singur
fel. Dac mai muli cititori neleg lucruri diferite atunci cerina este ambigu.
Pentru a ine sub control fenomenul existenei ambiguitilor trebuie organizate review-uri ale
specificaiei. De asemenea, specificaiile vor fi folosite ca surs primar pentru crearea planurilor de teste
i a manualului de utilizare.
6

7. Trasabil
Trasabilitatea se refer la posibilitatea de a reface traseul pe care o cerin a luat natere, pornind de
la solicitarea iniial a unui reprezentant al clientului. Acest mod de abordare asigur informaia care
justific existena sau nu a cerinei, precum i posibilitatea de a reface drumul pe care a aprut o cerin,
atunci cnd apar dubii asupra acesteia, asupra sursei sau asupra raiunii ei.

Axiomele dezvoltrii de software:

A1. ntotdeauna cerinele se schimb pe parcursul derulrii proiectului. ntotdeauna clientul cere
mai mult dect la nceput i tinde s extind proiectul peste bugetul iniial.
Clientul nu tie cu precizie ce vrea i este nclinat s i modifice cerinele. Pentru a i clarifica
propriile gnduri ateapt s vad mai nti aplicaia.
A2. ntotdeauna, ntr-un proiect software apar situaii neprevzute. Situaiile neprevzute nu sunt o
abatere de la regul ci sunt chiar regula.
A3. Niciodat oamenii implicai n proiect nu sunt perfeci. Toi fac greeli: programatorii produc
bug-uri, analitii erori de analiz iar project managerii, erori de management.
Cea mai mare parte dintre bug-urile dintr-un produs software de dimensiuni mari (unii spun
c peste 70%) sunt introduce n fazele de analiz i design. Cu ct un bug exist pentru mai mult
timp ntr-o aplicaie, cu att este mai costisitoare detectarea lui i rezolvarea va fi mai puin
corespunztoare.
A4. De regul, clientul nu citete specificaiile software sau le citete superficial. Mai mult dect
att, feed-back-ul primit de la client n faza de dezvoltare a proiectului este insuficient i incomparabil
mai puin consistent dect feed-back-ul primit dup depirea termenului final al proiectului.
A5. Nici un proiect software nu dispune de un buget nelimitat. Toate proiectele software au bugete
insuficiente.

SARCINA LUCRRII:
1.
2.
3.
4.
5.

Formularea ntrebrilor logice fa de client.

Extragerea cerinelor pentru un produs soft.
Specificarea cerinelor clientului.
Documentarea cerinelor utilizatorului.
Elaborarea unei specificaii a cerinelor software.

NTREBRI DE CONTROL:
1. Care sunt activitile majore care conduc la obinerea unei specificri a cerinelor?
2. Care sunt metodele folosite pentru specificarea cerinelor utilizatorilor?
3. Ce trebuie s conin documentul cerinelor utilizatorilor?