Cap.

2


Ingineria cerinelor


Primul pas logic n dezvoltarea unui program este stabilirea precis a cerinelor clientului
(ceea ce clientul vrea ca programul s fac). Partea ce mai important a acestui proces o reprezint
comunicarea dintre client i echipa de dezvoltare. Cnd un inginer de programe lucreaz la
stabilirea cerinelor, el este numit inginer de cerine, analist de sistem sau analist.
Dezvoltarea unui program ncepe de obicei cu o idee a clientului despre un nou sistem sau
pentru mbuntirea unui sistem existent. Clientul angajeaz un analist cu care va lucra mpreun
pentru specificarea mai exact a cerinelor. Ideea iniial a clientului poate fi vag i prost definit,
dup cum poate fi clar i bine definit.
Stabilirea cerinelor este probabil cea mai important activitate n dezvoltarea produselor
program. Dac un client nu tie sau nu poate s stabileasc n urma unei discuii cu echipa de
dezvoltare n mod exact ce vrea ca produsul s fac, este inutil s angajeze o echip care s
programeze. O echip de programatori poate s scrie cel mai estetic program din punct de vedere al
tehnicilor de programare folosite, dar dac nimeni nu va dori s-l foloseasc, proiectul va fi un eec.
Multe programe nu se potrivesc cu cerinele clientului nu din motive de implementare
defectuoas, ci din cauz c cerinele nu au fost specificate corect de la nceput
Programatorii nu pot i nu au cum s cunoasc necesitile clienilor, mai ales dac nu
cunosc domeniul pentru care o anumit aplicaie este scris. Este responsabilitatea clientului de a
veni cu cereri exacte i pertinente. Este obligaia inginerului de cerine de a discuta cu clientul
pentru a clarifica cerinele i a ajuta clientul s-i fixeze prioritile.
Stabilirea precisa a cerinelor este primul pas n obinerea unui program care satisface
cerinele clientului. O specificaie bun este folosit i n fazele de validare i verificare.

De ce sunt cerinele utilizatorilor att de importante?

n 1994 compania Standish Group a supravegheat peste 350 de companii care au produs
peste 8000 de proiecte software i a observat c 31 de procente dintre proiecte au fost abandonate
nainte de a fi terminate. Mai mult, n marile companii, doar 9% au fost livrate la timp i la costul la
care au fost contractate, iar n companiile mici procentul s-a ridicat doar la 16%. n urma
cercetrilor efectuate s-a stabilit urmtorul clasament al factorilor care au dus la aceast situaie:
1. cerine incomplete (13.1%)
2. lipsa implicrii utilizatorilor (12.4%)
3. lipsa resurselor (10.6%)
4. ateptri nerealiste (9.9%)
5. lipsa suportului executivului (9.3%)
6. schimbarea cerinelor i a specificaiilor (8.7%)
7. lipsa planificrii (8.1%)
8. sistemele nu au mai fost cerute n ntregime (7.5%)

Lipsa prevederii n nelegerea , documentarea i managementul cerinelor duce la o
multitudine de probleme: construirea unui sistem care rezolv o problem pus greit, care nu
funcioneaz dup ateptri, sau care este greu de neles i de utilizat de ctre clieni. Mai mult, un
proces de extragere a cerinelor nesatisfctor poate fi scump. Boehm i Papaccio (1988) au artat
c dac gsirea i rezolvarea problemelor referitoare la cerine n faza de definire a cerinelor cost
1$ , aceeai operaie cost 5$ dac are loc n faza proiectrii, 10$ n faza scrierii codului, 20$ n faza
de testare i mai mult de 200$ dup livrarea sistemului.

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 30km/h. 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.
Controvers: este bine s facem specificarea lund n considerare felul n care sistemul va fi
implementat?
1. Nu folosim detalii de implementare. Motivaia: nu ne ateptm ca un client s tie lucruri
specifice dezvoltrii programelor, i deci nu poate s fie de acord n cunotin de cauz cu
stipulrile din specificaii. Secretarele care folosesc Excel tiu COM? E necesar s facem
constrngeri asupra programului nc din faza de concepere?
2. Folosim detalii de implementare. Cteodat nu este posibil s ignoram o implementare
existent. Dac facem un program pentru o bibliotec, studiem implementarea existent (tipul
fielor ce trebuie completate, fluxul de lucru, modul de organizare al mediilor de stocare a
informaiilor) i o copiem n program. Putem verifica dac o cerin este sau nu rezonabil din
punct de vedere tehnic. Pentru a putea estima timpul de dezvoltare i preul, trebuie luat n
considerare implementarea. Este o diferen ntre a programa n Visual Basic i a programa n C++.
Costurile iniiale la programarea n Visual Basic vor fi mai mici (timp de dezvoltare mai mic,
programatori mai ieftini), ns odat ce produsul necesit dezvoltarea peste o anumit limit a
complexitii, este posibil ca respectivele costuri s creasc (ntreinere greoaie, probleme de
performan).
n legtur cu specificaia pentru locomotiv, remarcm c indic cerine, nu mod de
implementare. Cerinele sunt testabile (cu instrumente de msur specifice) i sunt clare
(neambigue). Remarcm ns c este incomplet: nu specific nimic despre costul sau termenul
limit de realizare.
Ca s vedem dac o specificaie este bun ar trebui s ne ntrebam dac:
spune ce i nu cum
este clar
este suficient de detaliat
este complet
Pentru comparaie, considerm urmtorul exemplu de specificaie: Scriei un program
Pascal care ofer funcionalitatea unei agende telefonice personale. Ar trebui s implementeze
funcii pentru cutarea unui numr i pentru introducerea unui nou numr de telefon. Programul ar
trebui s ofere o interfa utilizator prietenoas.


2. Extragerea cerinelor

Presupunem c analistul i clientul lucreaz mpreun, fiecare ncercnd s neleag pe
celalalt. Esena procesului de obinere a cerinelor este comunicarea. Se disting trei activiti majore
care conduc la obinerea unei specificri a cerinelor:
Ascultare. n aceast faz analistul nregistreaz cerinele clientului
Gndire. n aceast faz 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 considera 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 care comand un program
care s fie utilizat de ctre angajaii si dorete ca acesta s conin module de monitorizare a
muncii angajailor.
O alt problema o reprezint literatura studiat de client, nainte de angajarea echipei de
dezvoltare. Clientul ateapt mult prea mult de la program i de la echipa de dezvoltare.
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
s documenteze cerinele
s negocieze i s obin o nelegere cu clientul.


3. Specificarea cerinelor

Produsul extragerii cerinelor i a analizei este un document de specificare a cerinelor
(specificaii). Specificaiile sunt de o importan crucial n dezvoltarea cu succes a unui produs.
Specificaiile sunt documente de referin cu ajutorul crora se evalueaz dezvoltarea programului.
Trebuie avute n vedere:
nivelul de detaliu
cui i este adresat documentul
notaia folosit

Este de preferat ca specificaiile s se restrng ct mai mult n preajma a ce, nu a cum
trebuie fcut. Ar trebui s surprind viziunea clientului asupra sistemului. Specificaiile trebuie
nelese de dou grupuri distincte de persoane: clieni i dezvoltatori. Fiecare dintre aceste grupuri
tind s aib jargoane, domenii de expertiz diferite. Membrii acestor grupuri vor ca specificaiile s
enune exact cea ce trebuie fcut, ns preferinele pentru limbajul n care se exprim aceste lucruri
sunt diferite. Clienii prefer de obicei limbajul natural, n timp ce analitii tind s foloseasc o
notaie precis (limbaj de modelare).
Notaiile folosite sunt de mai multe tipuri: informale, formale, semiformale.
n abordarea modern se fac dou seturi de documente. Un set este pentru clieni, iar un set
pentru dezvoltatori. Problema care apare este actualizarea acestor documente i meninerea lor
consistent.
Un document de specificaii bun ar trebui s mpart pe categorii n mod explicit cerinele n
una din urmtoarele clase:

Cerinele de capabilitate - definesc o operaie sau o secven de operaii corelate, pe care
sistemul trebuie s le ndeplineasc.
n faza definirii cerinelor software, cerinele de capabilitate vor fi analizate pentru a
produce setul de cerine funcionale.
Cerinele de capabilitate au urmtoarele atribute:
capacitatea - se refer la ct de mult din capabilitatea respectiv e necesar la orice
moment de timp.
Exemple: numrul de terminale, numrul de utilizatori, volumul de date ce va trebui
stocat
viteza - arat ct de rapid trebuie s se execute o operaie sau secven de operaii,
msurat n numr de operaii pe unitatea de timp.
Exemplu: 95% din tranzacii se vor executa n mai puin de o secund
acurateea unei operaii - este msurat prin diferena dintre ceea ce se intenioneaz s
execute o operaie i ceea ce execut ea n realitate.
Exemplu: Programul va prezice altitudinea satelitului n limitele (cu o eroare de ) a 10m
cu apte zile nainte.

Cerine privind datele - se refer la datele de intrare / ieire din sistem (format, dimensiuni)
i la datele stocate n interiorul sistemului.

Cerinele restrictive - impun restricii asupra ndeplinirii cerinelor de capabilitate.
Utilizatorul poate impune constrngeri asupra interfeelor privind comunicarea cu alte sisteme
(interfee hardware sau software) sau cu factorul uman (interfaa utilizator). El poate impune modul
n care trebuie realizate interaciunile cu alte sisteme dar ar trebui s lase echipei de dezvoltare
libertatea de a le defini pe cele interne (privind interaciunile dintre componentele software).
Cerinele pentru interfaa utilizator pot impune aspecte privind stilul acesteia (limbaj de
comand, sistemul de menuri, icons), formatul (coninutul rapoartelor i afiajelor ecran).
Utilizatorul poate impune constrngeri privind calitatea produsului software, prin
urmtoarele caracteristici:

adaptabilitate (flexibilitate) - posibilitatea unui sistem de a fi uor modificat.
Exemplu: Trebuie s fie posibil de a aduga noi comenzi fr a le mai testa pe cele
vechi.
Observaie: n ceea ce privete adaptabilitatea, orice schimbare presupune un risc i
modificri ale prilor sigure ale sistemului ar putea fi inacceptabile.
disponibilitatea - se refer la posibilitatea sistemului de a fi utilizat n timpul perioadei
sale de operare. Cerinele de disponibilitate ar putea specifica:
- capacitatea minim disponibil (exemplu: toate terminalele)
- timpul de nceput i de sfrit al disponibilitii (exemplu: de la 9.00 pn la
17:30, zilnic)
- n medie, perioada disponibilitii.
Exemplu: toate capabilitile eseniale ale sistemului vor fi disponibile n msur de
cel puin 98% n orice 48 ore i n msur de cel puin 75% n orice perioad
de 3 ore
Dac un sistem nu este disponibil (nu poate fi folosit), acest fapt se datoreaz
pierderii cel puin a uneia din capabilitile sale, pierdere numit cdere, fiind cauzat
de erori. Timpul mediu ntre apariiile erorilor interne sistemului software (bugs)
msoar sigurana sistemului.
Timpul mediu necesar pentru a fixa erorile sistemului msoar posibilitatea
sistemului de a fi ntreinut.
portabilitatea - reprezint posibilitatea unui sistem de a fi mutat dintr-un mediu n altul.
Exemplu: Software-ul va fi portabil ntre mediile X i Y
Portabilitatea poate fi msurat n numr de linii de cod i/sau numrul de module care
nu trebuie s se modifice n momentul portrii de pe un computer pe altul
securitatea - sistemul trebuie s fie protejat mpotriva propriilor erori ale utilizatorilor,
sau mpotriva unor activiti ilegale, sau mpotriva accesului unor utilizatori neautorizai.
sigurana - consecinele cderilor sistemului trebuie semnalate clar echipei de
dezvoltare. Informaiile manipulate de sistem trebuie protejate mpotriva unor erori ale
sistemului (software sau hardware).
Exemplu: Sistemul trebuie s asigure faptul c nici una din date nu se va pierde n
eventualitatea unei cderi de tensiune
standarde - specific documentele care definesc standarde:
- ale procesului (exemplu: standardele pentru asigurarea produsului)
- ale produsului (exemple: formate ale fiierelor pentru export, sau formate ale
rapoartelor)
resurse - reprezint resursele valabile pentru producerea i operarea sistemului, n
termeni financiari, de limitri materiale sau de resurse calculator (exemplu: memorie).
Probleme ce pot apare n legtura cu cerinele:

Cerine vagi: sistemul trebuie s fie prietenos
Cerine contradictorii: toate datele trebuie scrise pe disc; timpul de rspuns 1 s

Succesul unui proces de dezvoltare a unui program se bazeaz pe extragerea n mod
profesionist a cerinelor de la client.


4. Metode pentru specificarea cerinelor utilizatorilor

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.

Formalisme matematice

Formule matematice ar trebui folosite sau referite n DCU, pentru a clarifica o cerin. Toate
simbolurile folosite ntr-o expresie trebuie s fie definite sau referite.

Engleza structurat - 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
construcii repetitive

Engleza structurat este, n mod normal, folosit pentru a descrie procesele de baz ale
sistemului i e potrivit pentru exprimarea cerinelor de capabilitate.
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 procesarea cerinelor (verificarea
automat, o analiz automat, transformri i afiri) i se poate simplifica definirea testelor pentru
faza de verificare i validare a sistemelor.

Tabele

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

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.

Diagrame de context

Diagramele de context prezint intefeele externe ale sistemului, intrrile i ieirile sale.


5. Utilitare pentru identificarea cerinelor utilizatorilor

Chestionarul este principalul utilitar pentru un interviu. Pentru a obine informaii utile,
trebuie s se acorde o atenie deosebit coninutului i prezentrii sale.
Mediile CASE pot fi utilizate pentru analiz i proiectare, considernd studiul de
fezabilitate.
Similar, prototipul sistemului poate fi realizat folosind utilitare pentru o proiectare mai
detaliat.
Capturarea cerinelor utilizatorului pe baza unui sistem software existent ar putea implica
determinarea unor modele care descriu acest sistem (analiza structurat, SSADM). Utilitarele CASE
sunt potrivite pentru construirea acestor modele.


6. Utilitare pentru specificarea cerinelor utilizatorilor

Utilitarele pentru manipularea informaiilor - reprezint cerinele utilizatorului ar trebui s suporte
una sau mai multe din funciile urmtoare:
- inserarea unor noi cerine
- modificarea unei cerine
- tergerea unei cerine
- cross-referenierea
- cutri
- afiri n diverse formate
Pentru sistemele complexe, un sistem de manipulare a bazelor de date devine esenial n
coordonarea informaiilor.

Utilitare pentru crearea Documentului Cerinelor Utilizatorului (DCU) - sunt necesare utilitare
care permit crearea paragrafelor, seciunilor, tabelelor, cuprinsurilor, etc.
Sunt utile urmtoarele faciliti:
- un spell-checker
- afiarea documentului la diferite nivele de detaliu
- programe pentru compararea documentelor, care pot marca automat textele modificate
(foarte necesare n revizuirea documentelor)


7. 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 a 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 constrngerile impuse sistemului
s defineasc toate interfeele externe 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 Software
Engineering 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.
- 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.


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.

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.

Coninutul DCU

Structura general a unui DCU, recomandat de Standardul Ingineriei Software, este
prezentat n continuare:

1. Introducere
2. Descriere general
3. Cerine specifice
Seciunea 1 trebuie s prezinte 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 prezint:
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 a clasifica aceti utilizatori
i de a estima numrul 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 reprezint partea principal a DCU, prezentnd toate cerinele de capabilitate i
cerinele restrictive ale sistemului.
Validitatea sistemului software se va face pe baza acestor cerine.
Fiecare cerin trebuie unic identificat.
Fiecare cerin trebuie marcat 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.