II.

Analiza cerinelor software

Introducere
Aceast serie de articole este destinat tuturor persoanelor implicate n proiecte de dezvoltare de software:
efi de departament, efi de proiect, analiti (n primul rnd lor), arhiteci software, programatori sau specialiti
n asigurarea calitii. Un prim argument pentru a fi citite (dar i pentru a fi scrise :-)) este acela c, n
universitile occidentale aceste lucruri sunt predate tuturor studenilor care se pregtesc pentru o carier n IT.
Cartea conine, inevitabil, numeroase elemente de Inginerie software, utile oricrui specialist IT: despre ciclul
de dezvoltare n proiectele software, despre interaciunile dintre disciplinele implicate n proiect etc.
Un al doilea argument este acela c Analiza software este una dintre disciplinele cu impact foarte mare
asupra succesului sau insuccesului proiectului software. Statisticile arat peste 60-80% din costurile non-calitii
sunt cauzate de nelegerea, culegerea i managementul inadecvate ale cerinelor. Conform Software
Engineering Institute (SEI), primii doi factori care contribuie la eecul proiectelor, n privina respectrii
bugetelor i termenelor sunt: specificaiile inadecvate ale cerinelor i schimbrile necontrolate ale acestora. Aa
cum vom vedea mai departe, de aceste lucruri se ocup, n cea mai mare msur, Analiza.
Argumente

Aa cum arat statisticile principala cauz a eecului proiectelor software este insuficienta implicare a
clienilor. Buna nelegerea a problemelor clientului, neaprat legat de mprtirea unei viziuni comune ntre
echipa de dezvoltare i client sunt dou faete de baz ale implicrii clientului. Fr ele, echipa de dezvoltare nu
are referinele de baz pentru a putea ti dac ceea ce dezvolt este corespunztor sau nu i, prin urmare,
implicarea puternic a clientul n proiect i nelegerea comun a problemelor lui este vital.
Altfel, este ca i cum te-ai deplasa ntr-o direcie oarecare, fr s tii unde vrei s ajungi.
Mesajul acesta este adesea (i cel mai bine!) ilustrat printr-o caricatur despre diferena care apare adesea
n practic, ntre problema clientului, nelegerea problemei i ceea ce se realizeaz de fapt (vezi imaginea)

2.1 Despre Analiza cerinelor

Ce este Analiza cerinelor software
Analiza cerinelor software (pe care o vom numi n continuare Analiza Software) este aceea dintre
disciplinele existente n domeniul Software care determin ce trebuie fcut, prelund problema clientului i
exprimnd-o ntr-un inteligibil de ctre dezvoltator.
Mai detaliat, Analiza Software este aceea dintre disciplinele implicate n procesul de dezvoltare a
produsului software ale crei obiective sunt:
- nelegerea problemelor curente ale organizaiei client i a raiunii pentru care este dispus s investeasc
ntr-un produs software;
- asigurarea unei viziuni comune asupra problemelor i a viitoarei soluii pentru toi participanii n
proiect;
- culegerea i actualizarea cerinelor pentru viitorul produs software i traducerea cerinelor clientului n
cerine software pe care echipa de dezvoltare s le poat nelege i transforma n funcionaliti efective;
- definirea limitelor viitorului sistem (acesta este un element extrem de important n economia proiectului,
avnd n vedere c n proiectele reale exist ntotdeauna o presiune crescnd n direcia extinderii acestor
limite).
Activitatea de Analiz este, n acelai timp, aceea care furnizeaz elementele pentru negocierea i
renegocierea bugetului i pentru planificarea resurselor. Ea contureaz produsul i, prin urmare, proiectul.
Impactul Analizei asupra costurilor proiectului i, n general, asupra succesului acestuia este, aa cum am
prezentat deja, foarte mare.
Pentru a fi foarte concret, n activitatea unui Analist Software intr urmtoarele mari tipuri de activiti:
- interviuri la client;
- analiza propriu-zis a cerinelor;
- dezvoltare cerine (specificaie);
- managementul cerinelor.
Toate aceste elemente, care umplu orele de serviciu (i pe cele suplimentare) ale Analistului vor fi
detaliate n paginile urmtoare.
De asemenea, trebuie precizat i ce nu nseamn Analiza Software. Analiza Software nu nsemn UML
(Unified Modelling Language) sau Use Case-uri, aa cum se mai ntmpl s se cread. De asemenea, nu trebuie
confundat i nici amestecat Analiza Software cu Design-ul, Analiza avnd ca preocupare de baz gsirea
PROBLEMEI iar Design-ul avnd ca preocupare de baz gsirea SOLUIEI.
Analiza este datoare s determine cu precizie boala, cea ctre care trebuie s se ndrepte tratamentul, fiind
de la sine neles c este profund greit s tratezi, din superficialitate sau necunoatere, simptomele, ignornd
boala n sine.
De ce este nevoie de Analiz Software?
The Standish Group arta c primele trei cauze ale problemelor privind calitatea i livrarea la timp, n
proiectele software, sunt:
- insuficient input (contribuie) de la utilizatori;
- cerine i specificaii incomplete;
- schimbarea frecvent a cerinelor.
Ori, toate acestea sunt lucruri de care se ocup, n primul rnd, Analiza Software. De asemenea, trebuie s
fim contieni c schimbarea frecvent a cerinelor, de exemplu, nu este lucru accidental, care ntr-un proiect se
ntmpl, n altul nu dimpotriv, este un lucru care se ntmpl ntotdeauna. Prin urmare, nici nu se pune
problema ca ntr-un proiect software s nu i propui s controlezi un factor att de important.
De asemenea, Analiza, prin output-urile sale (adic Specificaiile software) rspunde la una dintre nevoile
fundamentale ale proiectelor: nevoia de comunicare a cerinelor ntre membrii echipei de proiect i de
formalizare a acestora.
Despre modul n care Analiza influeneaz celelalte discipline i activiti implicate n proiect gsii detalii
ntr-unul din paragrafele urmtoare.
2

2.2 Axiome ale dezvoltrii de software

Cea mai bun cale pentru a-i ndeplini visele este s te trezeti.
Paul Valery
n continuarea rspunsului la ntrebarea De ce este nevoie de Analiz Software? sunt prezentate o
serie de lucruri pe care practica le susine ca fiind, fr dubiu, nite adevruri i care, aa cum vom vedea
susin necesitatea existenei Analizei software.
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.
n continuare pentru a porni discuia privind locul exact al Analizei ntr-un proiect software, va fi
descris ciclul de dezvoltare al produsului software i se va vedea cum se integreaz Analiza cu restul
disciplinelor implicate ntr-un proiect.

2.3 Ciclul de dezvoltare al produsului software (SDLC)

Dei n limba englez este denumit Software Development Life Cycle (SDLC) s-a ales traducerea Ciclul
de dezvoltare al produsului software, chiar dac tendina ntlnit cel mai adesea este s se traduc prin Ciclul
de via al produsului software. (Nu mai vorbim c traducerea mot a mot ar fi i ea diferit.)
Rmne la latitudinea dumneavoastr s alegei traducerea preferat. n aceste articole, se va folosi
denumirea de Ciclul de dezvoltare al produsului software , pe scurt SDLC.
Ciclul de dezvoltare al produsului software este un model al apariiei produsului software, pornind de la
problema originar i ajungnd la un produs concret, care s rspund acelei probleme.
Cu siguran, acest model nu i arat utilitatea n condiiile unor proiecte mici, cu un programator
rspunznd la cerinele ad-hoc ale unui client, i asta n termen de cteva zile sau sptmni.
ns, n condiiile n care n proiectele software din zilele noastre sunt implicate echipe mari de
dezvoltatori, analiti, arhiteci software, designeri, manageri, n multe cazuri distribuii n ri sau pe continente
diferite, pe perioade de timp de ordinul lunilor sau anilor, acest model teoretic ncepe s aib utilitate.
El este un prim pas ctre separarea a ceea ce este n interiorul proiectului, din punct de vedere al tipurilor
de activiti i din punct de vedere temporal. Este, prin urmare, un prim pas ctre acel divide et impera care,
aa cum vom vedea, permite pstrarea controlului asupra proiectului.
3

n literatura de specialitate sunt descrise mai multe Cicluri de dezvoltare software. Dintre acestea, dou au
importan asupra a ceea ce se dorete a fi discutat n aceast carte i, din acest motiv, sunt prezentate numai
acestea dou. De asemenea, nu se dau toate detaliile acestor cicluri ci se prezint numai ceea ce este util din
punct de vedere al Analizei Software.
Ciclul de dezvoltare n cascad (n V)
Cel mai vechi model i cel mai cunoscut este ciclul n cascad (waterfall). El este o secven de stadii n
care finalul unui stadiu este nceputul altuia. Aceste stadii sunt (de notat c n unele cri apar mai multe, fiind
incluse studiul de fezabilitate, integrarea sau instalarea, stadii care pentru lucrarea de fa sunt mai puin
relevante i pe care nu le vom prezenta):

1. Analiz
n aceast etap a proiectului are loc definirea a ceea ce trebuie dezvoltat. Obiectivul aici este s se afle
nevoile clientului i s se defineasc foarte clar cerinele privind viitorul produs software.
2. Design
Aceast etap are ca obiectiv modelarea viitorului sistem, vzut ca soluie a problemelor determinate n
faza de analiz. Dac Analiza i propunea s determine ce trebuie fcut, faza de Design trebuie s arate cum
trebuie fcut.
n aceast faz sunt proiectate funcionalitile pe care viitorul sistem va trebui s le aib.
3. Dezvoltare
Aceast

faz

nseamn

scrierea

efectiv

codului,

dezvoltarea

efectiv

acestuia.

4. Testare
n aceast faz produsul este testat pentru descoperirea anomaliilor n funcionare, astfel nct la final s
corespund cerinelor definite n faza de Analiz.
n afar de aceste faze eseniale ale procesului de dezvoltare, mai trebuie totui menionate i deploymentul, acceptana i mentenana. Acceptana este faza (sau momentul) n care clientul recepioneaz sistemul
software, accept c acesta corespunde cerinelor lui i i d acordul pentru intrarea n faza de mentenan.
Intrarea n faza de mentenan nseamn ncetarea includerii oricror noi cerine n sistem i corectarea bugurilor (anomaliilor n funcionare). Aceast faz este important pentru c ea constituie adesea o faz
costisitoare, dar i prea adesea ignorat.
Modelul de mai sus este, cu siguran, un model mai degrab teoretic, el bazndu-se pe presupunerea
(evident fals) c cerinele definite n prima faz nu se vor schimba pn la sfritul proiectului. n realitate
schimbarea cerinelor este singurul lucru stabil n software. ntotdeauna, n decursul proiectului, cerinele se vor
schimba (axioma A1).
Marele rezultat al existenei acestui model este evident de ordin teoretic. El ne d imaginea clar a faptului
c anumite activiti nu pot fi executate dect dup finalizarea altora, de alt natur sunt dependente de ele.
4

Ciclul de dezvoltare iterativ (n spiral)

Asumarea realitii c ntotdeauna, n decursul proiectului, cerinele se vor schimba a condus la apariia
unui model de dezvoltare realist, care s fie adaptat acestei realiti i care s permit nglobarea schimbrii n
cel mai bun mod cu putin.
Ciclul de dezvoltare iterativ este o succesiune de cicluri n cascad (waterfall), fiecare iteraie producnd o
parte din ntregul produs, parte care reprezint intrarea pentru urmtoarea iteraie:

Dac la ciclul n cascad disciplinele implicate n proiect (Analiz, Design, Implementare, Testare) se
confundau cu fazele de proiect, n ciclul iterativ acestea nu mai pot fi privite ca faze ci ca ceea ce sunt ele de
fapt: discipline implicate mai mult sau mai puin n fiecare iteraie din proiect.
n acest ciclu, fiecare nou iteraie nseamn detalierea (sau clarificarea), adugarea, modificarea eventual
eliminarea unor elemente definite n iteraiile anterioare. De asemenea, fiecare iteraie permite i validarea a
ceea ce s-a fcut pn n acel moment.
Acest ciclu mai are i avantajul c permite implicarea clientului chiar i n fazele avansate de dezvoltare a
produsului, astfel nct s se obin un preios feed-back. Acest feed-back va putea fi integrat n produs n
iteraiile urmtoare.

2.4 Locul Analizei n proiectul de dezvoltare software

Povestea unui Proiect software
Modelele din articolele precedente sunt nite modele cluzitoare pentru lumea real. Aa cum rezult de
aici, Analiza Software este o disciplin care se afl n relaie de dependen cu celelalte discipline din proiect.
Concret, task-urile din proiectul software sunt condiionate unele de altele, iar task-urile specifice analizei sunt
task-uri fr de care ciclurile din cadrul iteraiilor nu pot avea loc.
S lum ca exemplu un proiect, pe care l vom numi n continuare proiectul ALPHA, cu o echip mare, cu
un termen de livrare de cel puin un an, cu o echip de dezvoltare de 20 de persoane i cu un client adesea
indecis, care i schimb cerinele de la o lun la alta (acestea nu sunt condiii excepionale, nemaintlnite ntrun proiect software, ci dimpotriv, sunt chiar condiiile reale cel mai des ntlnite n practic). Proiectul pornete
cu mult entuziasm i, n ciuda unor experiene trecute nu prea plcute, speranele sunt mari. eful de proiect este
(ce ans!) un tip simpatic ales dintre programatorii cei mai experimentai un ins serios i plin de caliti iar
echipa de programatori este o echip cu experien, sudat n proiecte grele din trecut.
Proiectul se ncepe efectiv printr-o ntlnire fa n fa ntre cei mai valoroi membrii ai echipei de
dezvoltare i eful de proiect din partea clientului, nsoit i el, bineneles, de civa dintre oamenii care au
responsabiliti legate de proiect. Dup manual ntlnirea se numete kick-off meeting i trebuie fcut ca s
avem un prim contact cu ei. ntlnirea decurge bine pentru c echipa noastr de proiect tie precis ce trebuie s
ntrebe i discuia este fructuoas: discutm despre cum s arate ecranul de introducere a datelor, cam care sunt
rapoartele de care au ei nevoie, le explicm c funcionalitatea X nu se poate face chiar aa cum credeau dar
putem rezolva altfel, n fine... colaborarea este OK i asta conteaz.
Se iau i notie i urmeaz ca pe baza lor s ncepem lucrul la specificaie. Cu ct ncepem lucrul la
specificaie mai devreme, c s obinem semntura clientului pe ea, cu att mai bine.
5

Spre finalul discuiei o doamn de la contabilitate i amintete c ea vrea neaprat un buton cu care
sistemul s fac automat importul facturilor din Excel. I se explic rapid c aceast funcionalitate necesit nite
dezvoltri care nu erau prevzute dar asta o nemulumete profund: se subnelege c sistemul trebuie s fac
asta pentru c altfel este inacceptabil. Ea nu are nevoie de acest sistem dac nu face atta lucru i c ea nu este
dispus s bage de mn facturile n sistem. Abil, eful nostru i promite c va cuta o soluie i micul conflict se
aplaneaz.
ntoars acas, echipa de dezvoltare ncepe organizarea. Este numit un responsabil cu scrierea
specificaiei care trebuie terminat n dou sptmni c s scpm de treaba asta i s ne apucm de lucru.
Scrierea specificaiei va fi bineneles supervizat de eful de proiect, cel mai n msur s fac asta (chiar ar
face el specificaia dar nu are timp).
n fine, dup alte trei edine cu clientul i dup o lun de efort, specificaia este gata, semnat i
parafat. Echipa poate ncepe s lucreze cu adevrat. Se mpart task-urile pentru programatori: tu te ocupi de
capitolul 1 din specificaie, tu de capitolul 2 i aa mai departe. Dac sunt neclariti programatorii sunt liberi s
ntrebe. Se fac edine sptmnale n care se gsesc soluii tehnice la diversele probleme. Din cnd n cnd
eful de proiect mai cere lmuriri la client n legtur cu o problem sau alta. Dac unele "lmuriri" se bat cap
n cap cu specificaia, se planific o ntlnire la client i se ia o decizie, de comun acord. Proiectul merge bine, n
direcia ateptat chiar dac apar din cnd n cnd bug-uri sau probleme de integrare (este interesant c aproape
toat lumea poate face astfel de evaluri, chiar dac "direcia ateptat" este definit vag i, de obicei, se
rezum la evoluia cantitii de cod scris).
Dup opt luni de la nceputul proiectului, echipa actual ncepe s realizeze c exist unele ntrzieri.
Pentru anumite module se pune problema c programatorul care a nceput treaba a plecat din echip, iar cel care
i-a luat locul nu nelege prea bine ce are de fcut i nici de ce s-a fcut ntr-un fel sau altul.
eful de proiect s-a sturat s tot pun ntrebri la client aa c rspunde la problemele ridicate de
programatori cu nite presupuneri logice, care, simte el c nu au cum s nu fie acceptate. Oricum, i n echipa
de proiect a clientului s-au fcut modificri i nimeni nu mai tie ce s-a cerut cu cteva luni n urm.
Actualizarea specificaiilor a fost abandonat demult pentru c nu mai era timp pentru aa ceva i oricum
s-a dovedit o activitate inutil.
Dup unsprezece luni i jumtate este clar c proiectul e n ntrziere. Dei s-a dezvoltat aproape tot, mai
sunt cteva probleme importante care nu au fost nc abordate din lips de timp, pentru care nu exist o soluie
sau soluia dat nu este acceptat de client i trebuie fcute dezvoltri complexe. Testarea, care acum merge n
plin, d foarte mult de lucru echipei de dezvoltatori care nu mai fac fa rezolvrii bug-urilor. edinele de
analiz cu eful de departament arat clar c principalul vinovat este clientul care nu tie prea bine ce vrea i
care i-a schimbat foarte mult cerinele. Evident, i echipa este puin vinovat pentru c nu a reuit s l in n
fru, dar acum clientul trebuie s neleag c proiectul nu se poate termina la termen.
Dup alte ase luni, eful de proiect din partea clientului l anun pe directorul su general c proiectul,
dei se afl n mare ntrziere, nu este deloc ceea ce se atepta s fie (dei, privind n urm putem vedea c
aceast ateptare nu a fost niciodat definit riguros), c responsabilii din departamente nu sunt mulumii de
sistem, iar unii au declarat c ei nu l pot folosi sub nici o form. La departamentul de producie este evident c
utilizarea sistemului ar produce un blocaj.
Se decide o nou ntlnire ntre pri, se analizeaz situaia, se iau msuri...

2.5 Modele teoretice de abordare a problemelor. Decompoziia

Dac gseti un drum fr obstacole, probabil c drumul acela nu duce nicieri.
J. F. Kennedy
Acest capitol reprezint o zon de consideraii teoretice, independente de domeniul Analizei, dar
importante pentru nelegerea lui. Modalitile teoretice de abordare a problemelor sunt universale i pot fi
folosite oriunde ns pentru domeniul nostru, este important s le contientizm i s le nelegem deoarece
activitatea de Analiz se bazeaz foarte puternic pe ele. De asemenea, vreau s precizez c nu am adus n
discuie toate modelele teoretice de rezolvare a problemelor i nici nu am inclus detalii nerelevante pentru
domeniul de care ne ocupm.
6

Decompoziia
Directorul companiei XYZ se plnge c nu i poate planifica corect aprovizionarea i c pierde foarte
muli bani din cauz c nu are ntotdeauna suficient marf atunci cnd apar oportuniti de vnzare sau, invers,
pierde bani pentru c i se altereaz cantiti nsemnate de marf n stoc din cauz c s-a achiziionat mai mult
dect era necesar.
Pentru a rezolva o asemenea problem, pe care foarte adesea oamenii o formuleaz, de exemplu sub forma
"probleme cu aprovizionarea" sau "nu se aprovizioneaz conform necesarului real" primele soluii care apar sunt
pe msura gradului de generalitate al descrierii (specificaiei) problemei i adesea sunt, dup caz, chiar hilare:
"s se aprovizioneze conform necesarului real" (soluia este o inversare a problemei: "nu se face cutare lucru",
devine "s se fac cutare lucru").
Dei asemenea soluii nu sunt greite n sine, ele nu ne sunt utile. Problema iniial, "nu se aprovizioneaz
conform necesarului real" transformat n soluia "s se aprovizioneze conform necesarului real" este n
continuare o problem. Cum s se aprovizioneze conform necesarului real i care este necesarul real?
Pentru a rspunde acestei probleme este, evident, nevoie ca ea s fie spart n buci mai mici adic,
tradiionalul divide et impera (pentru c noi romnii avem o tradiie n asta i suntem foarte buni la aa ceva,
tim foarte bine s fim divizai).
Pentru a se aproviziona conform necesarului real, domnul XYZ (dnsul este directorul companiei XYZ,
desigur) va trebui (1) s tie care este necesarul real i (2) s achiziioneze exact atta ct a decis c este
necesarul real.
Pentru a determina necesarul real trebuie, mai departe, s tie (1.1) ct a vndut n trecut, (1.2) ce comenzi
curente are i (1.3) ce cantitate de marf are n stoc.
Pentru a achiziiona exact atta ct a decis c este necesarul real trebuie s poat, n orice moment, (2.1) s
afle cantitile deja comandate la furnizori i (2.2) s poat determina diferenele dintre necesarul calculat i
comenzile trimise la furnizori:

Aa cum probabil v ateptai deja, n Analiza Software, decompoziia este utilizat foarte des. Este
aproape o legtur organic, definitorie ntre Analiz i descompunere. Pentru specialistul n software ns,
trebuie s fie foarte clar, de la nceput, c nu toate sub-problemele de business determinate prin descompunere
se vor rezolva prin soft. Mai multe amnunte n articolele urmtoare...

2.6 Modele teoretice de abordare a problemelor

Sinteza
Sinteza este o modalitate, prin care, din manifestri punctuale se determin problema real. Cel mai
simplu i clar exemplu este acela al medicului, care pe baza simptomelor pacientului, stabilete un diagnostic,
stabilete, de fapt, problema acelui pacient.
Pentru a limpezi utilitatea acestui procedeu, s ne nchipuim c medicul ar proceda cam ca echipa
proiectului ALPHA, tratnd fiecare simptom n parte, dar fr s determine boala n sine: pentru febra ar
administra antitermice iar pentru durerea de cap, antinevralgice. Cu siguran infecia care produce simptomele
ar rmne neatins sau chiar s-ar agrava din cauza tratamentului neadecvat, iar simptomele ar reveni n forme i
mai dure.
Determinarea unei probleme mari, prin sinteza celor mici, indic o aparent opoziie cu modelul de mai
sus. De ce ar fi util n Analiz o metod exact opus alteia? Aa cum vom vedea i n alte capitole ale crii,
determinarea unei probleme majore, care determin apariia unui proiect, este un pas esenial ctre succesul
proiectului.
Am ntlnit de multe ori exemple n care echipa de proiect nu avea aceeai imagine asupra problemei pe
care ncercau s o rezolve.
n Analiz, cele dou modele nu sunt n opoziie ci se completeaz unul pe cellalt. Ideea este c ele sunt
utilizate n stadii diferite ale evoluiei proiectului: n faza de culegere a cerinelor (interviuri, documentare etc.)
este utilizat cu precdere sinteza. Aceast faz duce la determinarea riguroas a problemei clientului (problema
pe care o soluionm aici este determinarea problemei clientului). Pentru a soluiona problema clientului, se face
decompoziia acesteia.
Aici este important de menionat c decompoziia nu este o imagine n oglind a sintezei: decompoziia
vizeaz elemente ale soluiei, altele dect cele care au intrat n procesul de sintez.
Pentru a pstra paralela de mai sus cu medicina, sinteza informaiilor culese (adic a simptomelor bolii)
duce la determinarea bolii iar stabilirea tratamentului se face prin descompunere (infecia o tratm cu
medicamentul X, inflamaia cu medicamentul Y i aa mai departe).
De exemplu, Ionel (aici vreau s dau un exemplu ca la coal iar Ionel este un nume cu o oarecare
rezonan didactic) se plnge c spaiul pe care l are pentru a i depozita crile este mprit n prea multe
module, ceea ce l face s se deplaseze mult pentru a cuta o carte i n plus i restricioneaz accesul la dulapul
cu dosare (Ionel lucreaz des cu dosare).
De asemenea accesul la imprimant este ngreunat din cauza crilor care stau peste tot n jurul acesteia.
Analiznd aceste mici probleme i desigur sintetizndu-le, putem spune c Ionel are o problem cu
depozitarea crilor i, cu un efort de gndire suplimentar, ne putem da seama c ar avea nevoie s i poat
depozita crile pe vertical. Prin urmare o posibil soluie pentru el (aici exprimm viziunea asupra viitoarei
soluii) ar fi o bibliotec, sau un raft, dau un dulap care s ocupe mai mult spaiu pe vertical i foarte puin pe
orizontal.
De aici ncepe partea de soluie la problema lui Ionel. Analizm: pentru a rezolva problema depozitrii
crilor pe vertical avem nevoie, minimal, (1) de nite rafturi prinse ntre ele sau de perete cu nite (2)
elemente de prindere (cuie, uruburi etc.). Iat aadar cum am demonstrat ceea ce era de demonstrat: elementele
rezultate din descompunere (rafturi, cuie, uruburi etc.) sunt complet diferite de elementele care au intrat n
procesul de sintez (cri mprtiate, efort irosit etc.).
8

Determinarea unui trunchi de baz

De foarte multe ori, n viaa real, o problem nu poate fi punctat dect cu un efort substanial sau chiar
deloc. Pur i simplu, obinerea unui model mintal al unei realiti foarte complexe este imposibil sau prea
riscant: nu tii de unde s ncepi, nu tii care elemente sunt relevante i care nu.
n aceste condiii, modul natural de abordare este s construieti o baz, un element sau un set de elemente
pe care s te poi baza i cu ajutorul cruia s poi construi mai departe. Altfel spus, s faci s existe un trunchi
pe care, mai apoi s poat crete ramurile i frunzele.
De exemplu, geometria ca disciplin pe care o cunoatem cu toii, este construit pe cteva axiome. De la
aceste axiome pornete totul, ele sunt baza, fr de care restul teoriei nu ar fi posibil.
Am cunoscut, n trecut, o companie n care necesitatea informatizrii era simit ca fiind important i
necesar dar simptomele de moment nu puteau conduce la aprobarea unui buget suficient de mare pentru o
abordare global. Pur i simplu, nu se tia dect c exist probleme pe alocuri, c unele lucruri ar putea fi
mbuntite dar nu se puteau aduce argumente decisive n favoarea unei investiii ntr-un sistem informatic.
Ideea avut de unul dintre responsabilii din companie, mi se pare grozav: pentru c elementele cele mai
importante cu care lucreaz compania sunt proiectele i oamenii i majoritatea problemelor noastre sunt legate
de proiecte i oameni, vom crea o baz de date n care vom gestiona proiectele i oamenii. Dup ce vom ti n
orice moment cte proiecte avem, care sunt ele, n ce stadiu sunt, ci oameni sunt alocai, pentru ct timp i
aa mai departe, vom ti mai bine ce vrem. La acestea ne va fi uor s adugm, pas cu pas, i alte lucruri, dar
cel mai important, ne vom apropia pas cu pas de problemele noastre reale.
Acesta a fost nceputul i s-a dovedit mai apoi c a fost un nceput bun. Sistemul dezvoltat a rezolvate
multe probleme reale ale companiei.
Abordarea iterativ
Pn acum oamenii n-au gsit alt drum spre adevr dect greeala.
Nicolae Iorga
Metoda iterativ presupune rezolvarea unei probleme cunoscute printr-o abordare iterativ, la fiecare
iteraie fcnd un pas ctre rezolvarea problemei (ceea ce nu nseamn neaprat rezolvarea integral a unei subprobleme, aa cum vedem la descompunere).
La aceast abordare, fiecare iteraie presupune ndeplinirea unui anumit obiectiv, obiectivul final fiind
rezolvarea problemei iniiale. Poate c aceast metod poate s fie vzut ca o descompunere pe obiective, ns
acest lucru este puin important, important fiind ideea de abordarea iterativ.
De pild, s analizm problema unui voievod medieval romn: trebuie s i batem pe turci cu o armat mai
puin numeroas. Prin descompunere aceasta nseamn (1) s le cunoatem poziia n teren, (2) s le cunoatem
numrul ct mai exact, (3) s i mpingem pe un teren mltinos care s i defavorizeze, apoi (4) ct timp sunt
blocai n mlatin s i atacm necontenit i (5) restul armatei s atace de pe dealul care mrginete mlatina.
ntr-o abordare iterativ, n prima iteraie voievodul i propune, trimind iscoade, s afle precis poziia
adversarilor n teren, s aib o evaluare grosier a numrul acestora.
n a doua iteraie, lansarea primului atac, ncepe mpingerea adversarilor ctre terenul mltinos (pornind
de la datele obinute n prima iteraie) dar se pstreaz obiectivul de a cunoate cu precizie poziia lor n teren,
precum i obinerea unor date mai precise privind numrul adversarilor i mprirea lor pe tipuri de arme.
La lansarea celui de-al doilea atac, adic la a treia iteraie, se pornete de la datele deja obinute: poziia
actual dup primul atac, numrul adversarilor i mprirea lor pe tipuri de arme. Atacul vizeaz poziionarea
mai precis a adversarului astfel nct s se poat declana atacul de pe deal.
La a patra iteraie se lanseaz atacul de pe deal dar se menine obiectivul de a poziiona adversarul n locul
cel mai potrivit.
Dac vrei un exemplu i mai clar (dar cam simplist), unul dintre tunarii voievodului trebuie s loveasc o
anumit int. Neavnd aparatur performan de ochire, el abordeaz problema iterativ: trage un foc, vede locul
unde a lovit, repoziioneaz tunul, tage din nou i aa mai departe pn cnd i atinge inta. Ceea ce trebuie spus
este c, n situaia lui, aceast abordarea este cea mai realist.
9

Probabil c metoda iterativ mprumut cte ceva de la fiecare dintre celelalte trei metode. Important, n
cazul ei, este urmtorul aspect: fiecare dintre iteraii rezolv atta ct este posibil n acel stadiu i creeaz baza
pentru ca n iteraia urmtoare s se poat face un nou pas. Fiecare etap trebuie s aduc echipei de proiect
rezolvarea acelor probleme, precum i suficient feed-back, nct etapa urmtoare s poat fi desfurat cu
efectul scontat i cu risc minim.
Evident, aceast metod nu trebuie confundat cu ciclul de dezvoltare iterativ deoarece sunt lucruri
diferite, chiar dac ea poate fi considerat baza teoretic pentru acest ciclu.

2.7 Definiia cerinei software

Elementul central n Analiz este, cu siguran, cerina software. n jurul cerinelor se desfoar totul:
cerinele trebuie culese de la clieni, cerinele trebuie documentate, trebuie gestionate, dezvoltate, testate. n
fond, modelul creat prin specificaiile software este un model compus din cerine care trebuie s se transforme
n
produsul
final.
Din acest motiv, vom insista asupra definiiilor date cerinelor software, poate chiar mai mult dect asupra
definiiilor Analizei software n sine.
n literatura de specialitate exist o mulime de definiii. Toate ncearc ns s cuprind urmtoarele
elemente eseniale: cerinele sunt descrieri (specificaii), ntr-un limbaj accesibil tuturor celor implicai a ceea ce
un sistem informatic trebuie s poat acoperi, att prin comportamente (behaviour) ct i prin atribute ale sale.
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.
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
10

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.

Aa cum se vede n figura de mai sus, n cadrul evoluiei de la Problem la Soluie, specificarea cerinei
este pasul intermediar: ea este, pentru utilizator, soluia vizat a problemei lui, iar pentru dezvoltator este
problema pe care o are de rezolvat.
Dup cum vom vedea i n continuare, cerinele exprimate n limbaj inteligibil, sub forma documentelor
de specificaii software, agreate de ctre client i de ctre echipa de dezvoltare, constituie referina de baz
pentru toi cei implicai n proiectele software: pentru project manageri, n determinarea i urmrirea task-urilor
sau pentru inginerii de testare, n realizarea testelor.

2.8 Nivelurile cerinelor

n capitolul Modele teoretice de abordare a problemelor prezentam un exemplu ipotetic al unei companii
XYZ, al crei director se plnge c nu i poate planifica corect aprovizionarea i c pierde foarte muli bani din
cauz c nu are ntotdeauna suficient marf atunci cnd apar oportuniti de vnzare sau, invers, pierde bani
pentru c i se altereaz cantiti nsemnate de marf n stoc din cauz c s-a achiziionat mai mult dect era
necesar.
Prin descompunere, problema era spart n sub-probleme astfel:
- sub-problema 1: cunoaterea necesarului real:
- sub-problema 1.1: cunoaterea vnzrilor din trecut;
- sub-problema 1.2: cunoaterea comenzilor curente de la clieni;
- sub-problema 1.3: cunoaterea stocului curent.
- sub-problema 2: urmrirea achiziiilor astfel nct s se achiziioneze exact atta ct a decis c este
necesarul real:
- sub-problema 2.1: cunoaterea cantitilor deja comandate la furnizori;
- sub-problema 2.2: determinarea diferenelor dintre necesarul calculat i comenzile trimise la furnizori.
Mergnd cu decompoziia nc un nivel mai jos constatm c suntem deja n situaia de a da soluii destul
de concrete pentru unele dintre problemele din structur. Sigur c soluia final i ct se poate de concret este
software-ul nsui, dar fiecare pas n detaliere nseamn un nou pas ctre soluia final.
Cu acest nou pas vom obine o structur precum cea din figura de mai jos:

11

Astfel sub-problema 1.1 Cunoaterea vnzrilor din trecut se transform n: Introducerea facturilor de
vnzare n Sistem i Generare raport de vnzri din Sistem (presupunem c rezolvnd aceste dou chestiuni se
rezolv complet problema cunoaterii vnzrilor din trecut, chiar dac n realitate lucrurile ar putea s fie mai
complicate).
De la acest nivel de detaliere e clar c anumite probleme, i anume cele de pe ultimul nivel de detaliere, nu
mai sunt probleme pe care directorul companiei XYZ, sau chiar managerul de achiziii, s le rezolve nemijlocit
ci sunt task-uri adresate altui nivel de utilizatori.
Astfel, dac task-ul determinrii necesarului real i al urmririi achiziiilor este destinat nivelului
managerial, task-ul Introducerea facturilor de vnzare n Sistem este adresat unui alt utilizator, implicat direct
n derularea business-ului.
Noul nivel adugat nsemn nivelul la care este vizibil interaciunea dintre utilizatori i Sistem. Pentru
"Introducerea comenzilor n sistem" este evident c este necesar o funcionalitate n Sistem, aferent acestei
probleme. n fond, pe acest nivel ajungem la cerinele software pure, cele care se supun 100% definiiei date la
capitolul referitor la definiia cerinei: din punctul de vedere al utilizatorului trebuie rezolvat task-ul introducerii
facturii n Sistem iar din punctul de vedere al dezvoltatorului trebuie dezvoltat funcionalitatea aferent.
Dac ar fi s se detalieze din nou chestiunea Introducerii comenzilor n sistem, dar propunndu-ne s ne
modelm deja viitorul sistem informatic (s ne imaginm un flux complet de lucru cu Sistemul!) ar rezulta
urmtoarele funcionaliti pretinse Sistemului: adugare factur, modificare factur, tergere/anulare factur:

12

Acesta este nivelul la care granularitatea maxim a problemelor din business-ul real ating nivelul la care
poate fi conceput un sistem informatic: adaug, calculeaz, terge, modific, selecteaz, compar etc.
Privind n sens invers, de jos n sus, aceste funcionaliti sunt acelea pe care utilizatorul, ntr-un flux de
lucru cu Sistemul, le utilizeaz pentru rezolvarea task-urilor sale. Apoi, pe un nivel mai sus, din task-urile
utilizatorilor sunt rezolvate problemele de business.
Prin urmare, se pot stabili urmtoarele 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. Aa cum vom vedea n continuare aceste cerine sunt de obicei descrise ntr-un
document denumit Vision & Scope.
B. Cerine utilizator: pe acest nivel sunt task-urile 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 task-urile. Acest nivel este nivelul cel mai apropiat de
designul Sistemului.

n figura de mai jos se pot vedea att nivelurile cerinelor, ct i nivelurile din business care le genereaz,
precum i documentele de specificaii utilizate n general pentru acel nivel de cerine (sgeile cu vrful n jos
nseamn de obicei descompunere):

13

Trebuie precizat c documentele de specificaii au denumiri diferite, n funcie de metodologie. De

exemplu, n anumite metodologii documentul Vision & Scope este denumit Vision sau Specificaie de business.
De asemenea, este important de precizat c decompoziia prezentat n exemplul de mai sus are rol
teoretic i nu este ntotdeauna un mod de lucru recomandat. Dei este nu doar inevitabil, ci i normal,
utilizarea descompunerii n Analiz, ea trebuie completat cu (sau derulat mpreun cu) analiza pe fluxuri,
concretizat prin utilizarea use case-urilor. n exemplul de mai sus, cerinele corespunztoare unor task-uri
concrete trebuie detaliate i analizate sub form de use case-uri.
Pentru mai multe detalii v recomand capitolul dedicat use case-urilor.
Unde se termin cerinele clientului i unde ncepe designul?
Urmrind capitolul anterior, probabil c fiecare dintre noi i-a ridicat problema "unde se termin aceast
descompunere?" sau "cnd se poate spune c detalierea este suficient?". Acest lucru ncerc s l clarifica n
capitolul de fa.
Urmrind descompunerea, de sus n jos, putem observa c la orice nivel ne-am situa, pe nivelul imediat
inferior avem o propunere de soluie. Astfel, Cunoaterea necesarului real (SP1) se poate rezolva prin
Cunoaterea vnzrilor din trecut (SP1.1), Cunoaterea comenzilor curente de la clieni (SP1.2) i Cunoaterea
stocului actual(SP1.3). Prin urmare, nivelul inferior este rspunsul la ntrebarea "CUM?" privitoare la nivelul
curent. Dac ne poziionm pe nivelul Cunoaterea vnzrilor din trecut (SP1.1) i ne punem ntrebarea "cum
rezolvm aceast problem?", rspunsul se gsete pe nivelul inferior: prin Introducerea facturilor de vnzare
(C1) i Generare raport de vnzri (C2). i aa mai departe.
Dac ne situm pe un nivel oarecare i privim de jos n sus putem vedea problema pentru care nivelul
respectiv reprezint o soluie. Nivelul superior este rspunsul la ntrebarea "CE?" privitoare la nivelul curent
14

(sau "ce se rezolv prin..."). De pild, Introducerea facturilor de vnzare (C1) este un element care ajut la
Cunoaterea vnzrilor din trecut (SP1.1).
Prin urmare, pornind de la problema iniial, fiecare nivel de descompunere reprezint o soluie, dar n
acelai timp o problem. Totui, la un anumit nivel trebuie s se gseasc soluia final.
Judecnd lucrurile practic, ar fi o eroare s ne nchipuim c putem s lungim lucrurile la nesfrit. Undeva
trebuie s se termine (aa cum bugetul alocat proiectului se termin sigur undeva).
PROBLEM vs. SOLUIE
Privind lucrurile din punctul de vedere al ntregului proiect, soluia ultim a problemei clientului este
desigur aplicaia software n sine, programul executabil livrat clientului. Din punctul de vedere al analistului
ns, programul executabil final este punerea n practic, ntocmai, a unui model (a unei specificaii), ceea ce
conduce la ideea c, pentru analist, dar nu numai pentru el, soluia ultim a problemei clientului se gsete ntr-o
specificaie, ce urmeaz a fi modelul pentru dezvoltarea executabilului altfel spus, proiectul viitorului
executabil.
Aadar, putem mpri spaiul dintre problema iniial a clientului i soluia, constnd n modelul viitoarei
aplicaii software n dou pri distincte: PROBLEMA i SOLUIA. n zona PROBLEMEI vom situa acele
specificaii care descriu problema clientului iar n zona SOLUIEI acele specificaii care descriu modul de
rezolvare a PROBLEMEI. Trebuie spus, din start c nu toate specificaiile din zona SOLUIEI sunt de
competena analistului. Dimpotriv, cea mai mare parte a soluiei este conceput i descris de ctre arhiteci
software sau designeri de soluii software.
De la cerinele clientului la cod
Probabil c, n continuarea exemplului de la capitolul anterior, detalierea pe nc un nivel ar nsemna
descrierea modului de rezolvare a problemelor prin soft, detalierea funciilor pe care viitorul sistem le va avea:

Acest nou nivel de detaliere ncepe deja descrierea propriu-zis a aplicaiei software. La acest nivel, dup
descrierea pe sub-nivele a PROBLEMEI, ncepe descrierea SOLUIEI.

15

2.9 Nivelurile cerinelor vs. documente de specificaii

Pentru diversele etape, att n privina evoluiei n timp a cerinelor ct i n privina detalierii informaiile
i documentele implicate sunt urmtoarele:

Pentru a elimina orice confuzie n legtur cu specificaiile funcionale, trebuie spus c acestea nu conin
detalierea a cum se dezvolt acestea, nu conin elemente de design ci sunt vzute ca funcionaliti pe care
Sistemul software trebuie s le posede pentru a permite realizarea task-urilor utilizatorilor. Sistemul este vzut
aici ca o cutie neagr tim ce funcii trebuie s ndeplineasc dar nu tim cum.
Mai trebuie spus c de la o metodologie de lucru la alta tipurile, coninutul documentelor sau chiar limitele
dintre PROBLEM i SOLUIE pot s difere. n unele cazuri PROBLEMA se ncheie cu specificarea use caseurilor (ceea ce nseamn acoperirea task-urilor utilizatorilor), n altele odat cu Specificaiile funcionale.
Personal, dei susin cu trie c analistul trebuie s se limiteze la zona de business v recomand cu cldur
s v inspirai din metodologiile "clasice": RUP, MSF etc. sau din standardele existente (de pild IEEE Std 8301993: IEEE Recommended Practice for Software Requirements Specifications). Aceasta v va ajuta s v
formai propria prere i s nelegei cum este mai bine s mprii sarcinile n organizaia dumneavoastr.
Problema clientului este legat ntotdeauna de business
n principiu, treaba analistului se termin acolo unde ncep s fie vizibile interaciunile dintre utilizatori i
viitorul sistem informatic. Din acest punct ncepe treaba arhitectului software.
n fond, specificaiile cerinelor se termin, logic, acolo unde clientul nu poate sau nu trebuie s impun
propriul punct de vedere.
16

De exemplu, structura bazei de date, variabile utilizate, componente software reutilizabile, mprirea pe
module nu sunt lucruri asupra crora clientul trebuie s se pronune (cu rare i nedorite excepii).
ntotdeauna se va avea n vedere c documentul de specificaii trebuie asumat i semnat de ctre client n
cunotin de cauz, n deplin nelegere a coninutului su, motiv pentru care nu i se poate pretinde asumarea
soluiilor tehnice sau validarea unor detalii care depesc capacitatea tehnic a acestuia.
n concluzie, documentaia care precede dezvoltarea propriu-zis a codului unei anumite aplicaii software
descrie, pe de o parte PROBLEMA, pe de alt parte SOLUIA. Rolul Analizei este s descrie ct mai corect i
complet PROBLEMA, restrngnd doar din punct de vedere al business-ului clientului spaiul SOLUIILOR
posibile, fr s introduc restricii tehnologice.
n general, PROBLEMA clientului este o problem de business nu o problem de tehnologie.

2.10 Riscuri legate de cerine

Daca vrei sa afli o cale spre mai bine, e nevoie sa privesti ndelung tot ce este mai rau.
Thomas Hardy
ntr-un articol anterior am descris un mic exemplu, ipotetic (exemplul cu proiectul ALPHA) al unui
proiect ratat. Spuneam acolo ca, printre altele, echipa de proiect nu a stiut sa abordeze chestiunile de Project
Mangement sau Analiza. Cu siguranta ca asa este, dar mai mult dect att, echipa proiectului ALPHA nu a
pornit la drum cu o viziune realista asupra a ceea ce este n lumea reala, a afacerilor, un proiect software si a
constrngerilor impuse unui proiect software.
Probabil ca ntr-o lume ideala, n care programatorii ar fi avut la dispozitie un buget nelimitat, termene
nelimitate, o echipa stabila si un set stabil de functionalitati, proiectul s-ar fi sfrsit cu bine. Asta nsemnnd ca
functionalitatile cerute ar fi fost cndva gata, la parametrii de calitate cerui.
n viata reala nsa, lucrurile nu sunt la fel de usoare (vedeti si capitolul Axiome ale dezvoltarii de
software!). Proiectul real porneste ntotdeauna cu un buget limitat si evolueaza ntotdeauna n directia adaugarii
de cerinte ct pentru trei bugete (axioma ntia), dar se termina de cele mai multe ori la un nivel de calitate mult
sub cel dorit.
Aici este, de fapt, ntreaga maiestrie: sa controlezi un proiect real, afectat de multimea de constrngeri, sa
controlezi schimbarile permanente, sa negociezi n permanenta succesul.
Acesta este si motivul pentru care adevaratii Project manageri, analisti, arhitecti software sau programatori
sunt att de bine platiti, ceea ce fac ei nu poate fi facut oricum si de catre oricine.
Succesul unui proiect software, pndit din toate partile de o sumedenie de constrngeri, probleme si riscuri
se masoara pe trei coordonate: functionalitati, calitate si buget. ncadrarea sau nencadrarea n limitele stabilite
de la nceput ne dau masura succesului proiectului, iar pastrarea acestei ncadrari nu se poate face, n contextul
schimbarilor permanente, dect pastrnd controlul asupra a ceea ce este important si prin negociere. Ori, doua
dintre aceste coordonate (functionalitati si calitate) precum si informatiile pentru a controla si decide asupra
schimbarilor provin din analiza. De aici deriva si importanta riscurilor aferente analizei, care atunci cnd se
transforma n probleme concrete au efecte devastatoare asupra ntregului proiect.
Pentru a analiza riscurile potentiale ale activitatii de analiza vom porni de la ceea ce ar trebui sa fie ntr-un
proiect. Lucrurile de la care pornim sunt problema clientului si resursele posibil de alocat pentru rezolvarea
acesteia:

17

Problema reala a clientului este, de obicei, foarte vasta, mai ales n raport cu bugetul alocat. De aceea,
ceea ce trebuie sa fie domeniul problemei pe care si propune, n mod realist, sa o rezolve un proiect trebuie
negociat astfel nct dezvoltatorul sa nu fie obligat sa lucreze n pierdere (lucru care de obicei degenereaza ntr-o
pierdere de ambele parti) iar clientul sa rezolve cu adevarat problema de baza.
ntr-o prima varianta clientul ntelege ca solutionarea problemei lui solicita o investitie mai mare si
accepta modificarea bugetului pna la acoperirea ntregului necesar:

n cealalt varianta clientul, constrns de probleme bugetare, nu poate mari suma alocata si mpreuna cu
consultantul sau decide sa reduca domeniul problemei la ceea ce si permite sa cheltiue (n urma unei analize de
impact, fie gaseste acele 20% dintre cerinte care rezolva 80% din problema, fie decide ce este mai important si
mai profitabil sa implementeze n acest proiect si ce se poate amna pentru un alt proiect viitor).

n orice caz, la sfrsitul acestei etape presupunem ca avem declarata, chiar n termeni vagi, o anumita
problema si avem alocat bugetul adecvat. Desi n realitate este putin probabil sa se ajunga aici, pentru noi
aceasta simplificare a modelului este utila pentru ntelegerea situatiilor care pot sa apra.
Prin urmare noi vom presupune ca la primul pas am definit (chiar daca destul de vag) domeniul problemei.
Urmatorul pas, culegerea cerintelor este o detaliere a problemei, si rezultatul ei final ar trebui sa fie tot o
suprapunere perfecta peste acel domeniu, numit de noi problema reala sau domeniul problemei. n realitate nsa
nu ne putem astepta la o suprapunere perfecta dar ne propunem, n mod realist, pastrarea unei diferente
minimale, controlata, care sa nu afecteze obiectivele de baza ale proiectului.
Situatiile nefavorabile care pot sa apara sunt urmatoarele:

18

A. n prima situatie, cerintele captate nu acopera problema n ntregime (anumite lucruri nu se vor rezolva)
nsa produce costuri considerabile prin includerea unor cerinte inutile sau a unor cerinte care ies din domeniul
initial al problemei (probleme reale dar care nu contribuie la rezolvarea problemei).
B. n a doua situatie, cerintele captate si acceptate a fi incluse n proiect depasesc posibilitatile bugetare
ale proiectului si va conduce la pierderi financiare, litigii n justitie sau la abateri grave de la calitate.
C. A treia situatie neplacuta, este rezolvarea incompleta a problemei prin omiterea unor cerinte sau
ntelegerea vaga si incompleta altora sau chiar a problemei.
La ce efecte negative ne putem atepta?
Prin urmare, oricare dintre variante poate conduce la urmtoarele efecte negative:
- dezvoltarea unor funcionaliti inutile;
- dezvoltarea unor funcionaliti utile dar n afara domeniului problemei, care ridic probleme de buget;
- omiterea unor funcionaliti necesare sau chiar eseniale.
Am numit aceste rezultate negative efecte negative pentru c lucrul ctre care trebuie s ne ndreptm
sunt de fapt cauzele de la baza ntregului fenomen negativ.
Recapitulnd, efectul ultim este nereuita proiectului n ceea ce privete atingerea obiectivelor legate de
funcionaliti, calitate i buget (simultan), iar din punct de vederea al analizei cerinelor aceasta pornete de la
dezvoltarea unor funcionaliti inutile, dezvoltarea unor funcionaliti necesare dar din afara domeniului
problemei i omiterea unor funcionaliti necesare. La rndul lor aceste fenomene pornesc de la un set de cauze,
aa cum sunt descrise n tabelul de mai jos:
Cauze
- nelegerea slab a problemei clientului, a raiunii
proiectului;
- insuficienta implicarea a clientului;
- cerine ambigue;
- adugarea necontrolat a unor cerine a cror raiune
este neclar;

Efect negativ
- dezvoltarea unor funcionaliti inutile;

- nelegerea slab a problemei clientului, a raiunii

- dezvoltarea unor funcionaliti necesare dar
proiectului;
din afara domeniului problemei;
- suprancrcarea proiectului cu cerine, din cauza
pierderii controlului asupra schimbrilor;
- nelegerea slab a problemei clientului, a raiunii
proiectului;
- insuficienta implicarea a clientului;
- cerine ambigue, specificaii incomplete;

- omiterea unor funcionaliti necesare;

ntre cauzele prezentate mai sus "nelegerea slab a problemei clientului", dei poate s par puin
surprinztoare este un fenomen foarte des ntlnit.
Pur i simplu, ntrebai membrii unei echipe de dezvoltare "de ce se dezvolt acest proiect?" sau "de ce
clientul d bani pe acest soft?".
Vei fi surprini s aflai c acel proiect se dezvolt pentru c "aa avem contract cu clientul" (pi nu...!?)
sau "nu tiu, dar dac clientul pltete... e treaba lui", ori "pentru c aa trebuie, nu poi s rmi n urm cu
tehnologia".
Cel mai dramatic este atunci cnd asemenea rspunsuri vin de la persoane care sunt analiti sau project
manageri, nct te ntrebi, firesc, cum se stabilesc acolo prioritile i pe ce baz se negociaz schimbrile?

19

Mai multe despre rolul clientului

nc de la primele articole spuneam c "insuficienta implicarea a clientului" este prima cauz pentru
problemelor privind calitatea i livrarea la timp, n proiectele software.
Altfel spus, situaia normal ar fi aceea n care clientul este actorul principal n definirea cerinelor
proiectul de dezvoltare fiind proiectul n primul rnd al lui, nu al echipei de dezvoltare. Nimic din ceea ce este
cerin pentru viitorul sistem nu trebuie presupus i de asemenea, nici-o schimbare a cerinelor nu se presupune
a fi acceptat fr consultarea clientului i explicarea impactului schimbrii.
n permanen analistul trebuie s fie primul care i dorete s obin feed-back de la client, chiar dac
acesta este negativ (doar feed-back-ul negativ i garanteaz corectarea traiectoriei atunci cnd ai pornit pe un
drum greit). Acesta este modul de lucru principal al analistului, mecanismul de corectare i de finisare a
specificaiei.
Dac ai lucra cu metal, lemn sau piatr ai avea, cu siguran instrumente specifice pentru corectarea
erorilor i pentru lefuirea materialului, atunci cnd lucrai cu informaie, instrumentul de care avei nevoie, se
cheam feed-back.
Cerinele ambigue sunt acelea care pot fi interpretate n mai multe feluri fr faultarea logicii.
Tuturor ne scap asemenea lucruri, pentru c noi tim ce vrem s spunem i "nelegem" chiar dintr-o
fraz pe care o construim prost. Mai mult, chiar n comunicarea ntre dou persoane se pot transmite lucruri
ambigue pentru c cel care recepioneaz un mesaj crede c a neles ceea ce trebuie. Atta timp ct el crede
sincer c a neles ce trebuie, e chiar dificil s depistezi ambiguitatea.
Totui, posibiliti de depistare a ambiguitilor exist. Folosii use case-uri, organizai review-uri formale
ale specificaiilor, trimitei responsabililor de la testare specificaia pentru crearea planului de teste, nainte de a
se dezvolta aplicaia i insistai s se scrie prima versiune a manualului de utilizare pe baza specificaiei.
Mai ales cerinele neclare, dificile, acelea de care i vine, mai degrab s scapi ct mai repede dect s
insiti pentru clarificarea lor, trebuie avute n vedere aici. Nici-o ambiguitate nu va scpa pn la sfrit
(acceptana!) orice datorie nepltit va fi pltit la un moment dat, dar cu o penalizare mult mai mare.
n privina chestiunii "adugrii necontrolate a unor cerine a cror raiune este neclar" putem spune c
orice cerin a crei raiune nu este clar, nu ar trebui, de fapt, s fie considerat cerin. La fel ca la raiunea
proiectului, dac rspunsul la ntrebarea "de ce?" este ceva de genul "pentru c aa vrea clientul ...", acea cerin
este incomplet neleas.
n acest grup intr cu succes unele funcionaliti de tip nice to have propuse de dezvoltatori sau de
utilizatori, precum "mbuntiri" ale interfeei utilizator, sau "mbuntiri" mnate de dorina utilizrii unei
tehnologii noi, proaspt descoperit de programator.
Ultima chestiune pus n discuie, "suprancrcarea proiectului cu cerine, din cauza pierderii controlului
asupra schimbrilor" nu este deloc cea din urm.
Dimpotriv, prin faptul c este o permanen n proiectele software (axioma A1: ntotdeauna cerinele se
schimb pe parcursul derulrii proiectului...), prin efectele devastatoare (apropo de axioma A6: nici un proiect
software nu dispune de un buget nelimitat...) aceast chestiune este una vital. Dac lucrai ntr-un proiect mare,
ignorai-o i vei pierde!
Vestea proast este c factorul care genereaz aceast problem, este schimbarea cerinelor, lucru care nu
poate fi evitat, i c impunerea controlului asupra schimbrii cerinelor este un lucru greu de realizat i nu se
poate face dect prin respectarea riguroas a unei proceduri de includere a schimbrilor n proiect. Pentru fiecare
schimbare trebuie evaluat impactul asupra ntregului (lucru care, n sine, cost) i trebuie decis dac cerina
poate fi inclus n proiect, dac este necesar modificarea sau eliminarea altor cerine, renegocierea bugetului
sau a termenelor.
De asemenea, procedura de control al schimbrii cerinelor trebuie respectat de ambele pri, att
dezvoltator ct i client. Nimeni nu poate schimba cerinele fr respectarea procedurii (dect, poate, n msura
n care schimb automat i bugetul i termenele la niveluri acoperitoare).

20

2.11 Cerinele nefuncionale

Una dintre greelile cele mai frecvente n specificaiile software este tratarea superficial a cerinelor
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.
Am ntlnit cu civa ani n urm un caz, zic eu, relevant. Aplicaia era o aplicaie pe web, destul de
obinuit de altfel, cu cerine privind performana destul de normale, chiar modeste.
Din pcate, specificaia ddea drept cerin ncrcarea a sute de pagini simultan, lucru greu de realizat cu
un server obinuit (la asemenea cerine, de altfel inutile, nu rspund nici site-urile mari de pe Internet). Nu e
cazul s mai spun c dei cerina fusese propus de ctre echipa de dezvoltare nu de ctre client, n ncercarea de
a o rezolva s-a pierdut timp, pentru ca n final, dificultile ridicate de o asemenea int s conduc la
rediscutarea
i
"renegocierea"
cu
clientul
a
cerinei
respective.
Tratarea cu superficialitate a cerinelor privind performana a condus, iat, la imposibilitatea respectrii
specificaiei.
n afara faptului c situaia a fost destul de jenant, cerndu-i-se clientului s renegocieze ceva ce echipa
de dezvoltate propusese i scrisese, de bun voie i nesilit de nimeni, n specificaie, au fost implicate i costuri
total nejustificate.
Determinarea cerinelor nefuncionale trebuie s urmeze un proces sntos, de la determinarea lor i pn
la specificare.
n primul rnd, determinarea acestor cerine este un lucru dificil, pentru c, n general utilizatorii nu sunt
interesai, i nici pui n tem, n legtur cu costurile cerinelor lor i au tendina s exagereze: "sistemul trebuie
s lucreze 24 de ore din 24", "timpul de rspuns?... pi sistemul trebuie s rspund instantaneu la orice
comand", "nu se admite nici un bug n funcionarea sistemului".
n realitate nu este deloc important, nici mcar util, s se arunce banii pe obinerea unor caracteristici care,
de fapt, sunt excepionale, ale produselor software. i asta pentru c nu toate aplicaiile software sunt folosite
pentru ghidarea navetelor spaiale sau pentru controlul centralelor nucleare.
Dimpotriv, am vzut cu toii site-uri de succes care nu rspund chiar instantaneu la solicitri, sau aplicaii
de calcul tabelar, extrem de utile i practice dealtfel, care nu pot gestiona fr pierderi de performan cantiti
foarte mari de date.
Prin urmare, ceea ce trebuie neaprat identificat sunt cerinele cu adevrat importante, specifice businessului respectiv, care pot produce pierderi sau dificulti reale. De pild, n unele cazuri, ar putea fi necesar
disponibilitatea sistemului 24 de ore din 24 pentru facturare, chiar dac sunt acceptabile unele deprecieri ale
timpului de rspuns n anumite intervale orare. n fiecare caz n parte exist un raport optim ntre performane i
costuri.
Cerinele nefuncionale includ cerinele de calitate precum:
- cerinele de performan (viteza de rspuns, disponibilitatea sistemului, timpul de recuperare n caz de
indisponibilitate temporar a sistemului, utilizarea resurselor);
- sigurana n funcionare (frecvena avariilor, uurina recuperrii);
- suportabilitatea (posibilitile de adaptare, posibilitile de extindere, configurabilitatea, compatibilitatea
cu alte sisteme, localizare);
- cerine de implementare (standarde, legislaie aplicabil, politici de securitate, limitri de resurse);
- uurina n utilizare (consistena interfeei utilizator, standarde de ergonomie aplicabile, documentaie,
help);
- constrngeri de design;
- cerine de interfaare cu alte sisteme.

2.12 Caracteristicile cerinelor software

Atunci cnd suntei n situaia de a culege, analiza i specifica cerine (s zicem, de exemplu atunci cnd
suntei analist software) trebuie s avei n vedere c, indiferent de forma n care o specificai, 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
21

aib anumite caracteristici care le fac s fie cerine adevrate, corect specificate i posibil de realizat, n
parametrii bugetari i de calitate determinai.
nainte de a trece efectiv la enunarea acestor caracteristici, v invit s v gndii la cerin aa cum este
definit n capitolul Definiia cerinei software:
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.
Aadar, 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 de care vorbim n
continuare.
Aceste caracteristici sunt, n principal, urmtoarele (depinznd de autor lista poate fi mai mare sau mai
mic dar cele eseniale sunt acestea):
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 (mai multe detalii n capitolul
Nivelurile cerinelor).
Doar pe baza problemei acesteia vom putea ti dac o cerin se ncadreaz sau nu n proiect.
Pentru a demonstra c o cerin este necesar este nevoie de existena unei legturi ctre cerinele de pe
nivelul superior (mai multe detalii n capitolul Nivelurile cerinelor).
2. Corect
Atunci cnd spunem c o cerin trebuie s fie corect, ne apropiem deja de a doua parte a definiiei de
mai sus (sau mai degrab le cuprindem pe amndou). 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.
n general pentru a determina corectitudinea unei cerine este necesar s se fac referire la cerinele de pe
nivelul superior (mai multe detalii n capitolul Nivelurile cerinelor).
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.
22

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 (axioma A4, care spune c niciodat oamenii
implicai n proiect nu sunt perfeci, ne spune c ele sunt inerente) 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.
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.

23