Unitatea de studiu 5

Studierea sistemului existent

şi determinarea cerinţelor noului sistem

Obiective:
x Descrierea componentelor sistemului existent (ieşiri, intrări, stocarea datelor, procese de prelucrare), pentru
identificarea punctelor tari şi slabe din sistem
x Înţelegerea evenimentelor la care sistemul trebuie să reacţioneze prin funcţiile de prelucrare, precum şi a
modalităţii de identificare a lor
x Identificarea principalelor categorii de cerinţe ale noului sistem
Competenţe dobândite:
x Identificarea componentelor sistemului existent
x Elaborarea documentaţiei sistemului existent
x Întocmirea documentaţiei privind cerinţele unui nou sistem informaţional financiar-contabil
Timpul mediu necesar asimilării: 8 ore

Capitolul de faţă se concentrează asupra activităţilor specifice etapei de analiză, în care este studiat
sistemul existent şi se identifică cerinţele noului sistem informaţional.
În timpul cercetării şi stabilirii cerinţelor, se vor obţine detaliile privind procesele şi activităţile
desfăşurate la nivelul sistemului curent, pe măsura intervievării, observării utilizatorilor sau analizei
documentelor şi procedurilor de lucru existente. În acest mod, se încearcă obţinerea unei imagini cât mai
clare şi obiective asupra problemelor cărora trebuie să le răspundă noul sistem.
În etapa de anaiză se realizează legătura cea mai strânsă cu utilizatorii şi se câştigă încrederea lor,
pentru că se fac o serie de recomandări şi sugestii asupra modului în care se vor satisface cerinţele lor
informaţionale. Şi asta pentru că, în timpul analizei, „se merge unde trebuie şi se discută ce trebuie” 1 cu
utilizatorii care participă la desfăşurarea operaţiunilor economice, ceea ce face mult mai facilă acceptarea
schimbării sistemului. Altfel, e posibil ca echipa de analiză să fie văzută ca un intrus, care nu înţelege
problemele cu care se confruntă cei care exploatează sistemul.
Aproape toate metodologiile de dezvoltare a sistemelor specifică şi descriu activităţi similare pentru
etapa de analiză, diferenţele rezultând, de cele mai multe ori, din tehnicile recomandate pentru
desfăşurarea lor sau din denumirea dată. Însă, toate ar trebui să conducă la atingerea aceloraşi obiective:
înţelegerea deplină a modului de funcţionare a sistemului existent, determinarea cerinţelor informaţionale
şi modelarea noului sistem. Faza de analiză presupune definirea mult mai detaliată a ceea ce trebuie să
facă sistemul informaţional, pentru a genera beneficiile economice şi avantajele tehnologice specificate în
timpul etapei de planificare a proiectului, oferindu-se mai multe soluţii, din care cea mai bună va fi
supusă proiectării.
Activităţile specifice analizei sunt complementare şi, de obicei, se pot desfăşura simultan. De
exemplu, analistul culege informaţii despre sistemul existent, definind în acelaşi timp cerinţele
informaţionale pentru cel nou, pe tot parcursul etapei şi nu numai la începutul ei. Principalele întrebări la
care trebuie să se găsească răspunsul în timpul etapei de analiză sunt:
* ce se realizează în sistemul existent şi care sunt intrările, ieşirile şi procesele de prelucrare
specifice?
* care sunt punctele tari, de păstrat în noul sistem, respectiv punctele slabe, care trebuie înlocuite
sau transformate în puncte tari?
* care sunt cerinţele noului sistem?
* ce variante pot fi luate în considerare pentru dezvoltarea noului sistem, pentru a răspunde cât mai
bine cerinţelor identificate?
* ar trebui continuată proiectarea şi implementarea noului sistem?
Principalele activităţi desfăşurate în timpul etapei de analiză sunt:

1
. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition, Course
Technology, Thomson Learning, Boston, 2002, p. 108.
1. Studierea sistemului existent, care presupune, în primul rând, identificarea punctelor tari şi slabe ale
sistemului, respectiv a acelor elemente care au generat apariţia problemelor, pe baza unor analize
orientate spre principalele componente ale sistemului informaţional.
2. Determinarea cerinţelor informaţionale ale noului sistem. Activitatea implică identificarea
persoanelor care au nevoie de informaţii, momentele şi forma în care acestea sunt solicitate. Analiştii
trebuie să lucreze foarte îndeaproape cu utilizatorii. Cerinţele informaţionale se referă la:
* tipul, formatul, conţinutul, volumul şi frecvenţa fiecărei intrări/ieşiri, timpul de răspuns;
* procesele de prelucrare necesare transformării intrărilor în ieşiri;
* corectitudinea, exactitatea şi securitatea intrărilor, stocării, prelucrărilor şi ieşirilor sistemului.
Pentru aceste două prime activităţi, analiştii de sistem au la dispoziţie o serie de tehnici sau metode,
grupate în două mari categorii, respectiv:
a. metodele tradiţionale de culegere a informaţiilor
x interviuri individuale;
x anchete realizate prin chestionare;
x intervievarea grupurilor de oameni cu interese comune;
x observarea personalului în momente bine definite pentru a vedea modul în care sunt folosite
informaţiile pentru exercitarea sarcinilor de serviciu;
x studierea documentaţiei firmei pentru a se cunoaşte conţinutul rapoartelor, al politicilor,
regulamentelor, precum şi direcţiile spre care se îndreaptă prelucrarea datelor.
b. metode moderne de determinare a cerinţelor sistemului:
x JAD (Joint Application Design)
x RAD (Rapid Application Development)
x prototipizarea.
3. Structurarea sau modelarea cerinţelor sistemului urmăreşte crearea unor imagini ale sistemului,
prin intermediul unor modele, după cum urmează:
* modelul descompunerii funcţionale are ca scop evidenţierea principalelor funcţii, procese,
subprocese, proceduri de prelucrare a datelor etc. din cadrul sistemului. De fapt, modelul
prezintă, sub formă de diagramă, structura ierarhică a prelucrărilor din sistemul analizat;
* modelul proceselor, prin care se reprezintă principalele procese de prelucrare şi legăturile
existente între sistemul analizat şi celelalte sisteme sau componente organizatorice ale firmei,
respectiv cu sistemele externe, prin intermediul fluxurilor de date. Modelul proceselor este
construit prin intermediul diagramelor fluxurilor de date, care redau, sub formă grafică, sursa
fiecărui flux de date, procesele de prelucrare la care sunt supuse, precum şi destinaţia fluxurilor
de informaţii obţinute în urma prelucrărilor. Sursa şi destinaţia pot fi alte sisteme/aplicaţii,
persoane, componente organizatorice, parteneri de afaceri, locuri de stocare/păstrare a datelor
(fişiere, baze de date, dosare etc.);
* modelul logicii proceselor presupune descrierea acestora astfel încât să poată fi convertite în
programe, prin intermediul limbajelor de programare, dar nu se va respecta structura sau sintaxa
unui anumit limbaj (aceasta se va realiza într-o etapă ulterioară, proiectarea);
* modelul datelor, realizat prin intermediul diagramelor entitate-relaţie, reliefează obiectele sau
lucrurile din lumea reală, sub forma entităţilor de date, despre care trebuie păstrate date în cadrul
sistemului, o lungă perioadă de timp. Entităţile de date sunt componentele unui sistem care au
cea mai lungă perioadă de viaţă şi sunt cele mai persistente.
4. Întocmirea raportului analizei de sistem reprezintă sinteza activităţilor anterioare şi va conţine:
* lista problemelor şi restricţiile existente în sistemul curent;
* cerinţele noului sistem;
* rezultatele modelării conceptuale;
* recomandări privind proiectarea noului sistem.
5. Analiza recomandărilor împreună cu reprezentanţii conducerii, care trebuie informaţi cu privire
la evoluţia proiectului, urmărindu-se luarea deciziei de continuare sau nu a acestuia, alegerea celei
mai bune variante de proiectare a sistemului, precum şi aprobarea bugetului şi planurilor calenda-
ristice revizuite pentru finalizarea proiectului.
 5.1 Studierea sistemului existent
Studierea sistemului este una din cele mai importante activităţi din ciclul de viaţă al dezvoltării, iar
în primii ani ai informatizării sistemelor nu exista nici o limită în desfăşurarea acestei activităţi. În timp,
atât specialiştii, cât şi utilizatorii ajunseseră la concluzia că alocarea unei perioade de timp mai mici
pentru studierea sistemului existent nu ar afecta calitatea noului sistem, pentru că se pornea de la ideea că,
de cele mai multe ori, vechiul sistem trebuia înlocuit şi nu ar mai fi fost necesară studierea lui. Dar, în
ultimii ani, s-a demonstrat că multe dintre sistemele dezvoltate, în special cele cu forţe proprii (dar nu
numai), au generat numeroase probleme, mai ales în timpul etapei de întreţinere, datorită inexistenţei unei
documentaţii complete privind caracteristicile şi funcţiile sistemului, generând costuri semnificative
pentru refacerea activităţii de analiză şi documentare. În plus, multe dintre sisteme trebuie integrate cu
altele, ceea ce înseamnă că efortul de studiere a sistemului existent este mai mare, pentru a asigura un
grad cât mai înalt de integrare şi compatibilitate.
Ca urmare, unii specialişti au ajuns la concluzia că trebuie să se găsească un echilibru între eforturile
şi timpul necesar pentru studierea sistemului existent şi cele de determinare a cerinţelor noului sistem,
pentru că reprezintă principala cale de identificare a nevoilor informaţionale.
Mai mult, sunt destul de rare cazurile când specialiştii în dezvoltarea sistemelor pot crea imaginea
noului sistem doar pe baza cunoştinţelor sau experienţelor pe care le deţin, de obicei, fiind nevoiţi să
apeleze atât la discuţii cu utilizatorii şi la observarea modului în care aceştia îşi desfăşoară activitatea, cât
şi la analiza documentaţiei sistemului existent, care poate include rapoarte şi ecrane, diagrame ale
fluxurilor de date, diagrame entitate-relaţie etc. Aşadar, şi în condiţiile în care sistemul curent este
înlocuit în totalitate, analiştii au nevoie de informaţii despre funcţiile îndeplinite de acesta.
Principalele elemente supuse analizei în timpul studierii sistemului existent sunt:
x informaţiile de ieşire obţinute din actualul sistem şi de care au nevoie persoanele din unitate
pentru exercitarea sarcinilor ce le revin;
x datele de intrare în sistem vehiculate în unitate pentru fiecare loc de muncă (descrierea lor,
volumul, mărimea, periodicitatea ş.a.);
x modul în care sunt stocate şi păstrate datele;
x procesele de prelucrare la care sunt supuse datele, ordinea prelucrărilor şi dependenţa dintre
datele trecute prin diverse procese. De asemenea, se au în vedere evenimentele marcante şi
momentele declanşării lor, prin care se schimbă valoarea datelor.
În continuare, vom prezenta pe rând aceste elemente.

5.1.1 Analiza informaţiilor de ieşire

Principalele informaţii care se obţin în cadrul unui sistem apar sub forma listelor, situaţiilor de ieşire,
documentelor, ecranelor, a răspunsurilor la întrebări, toate încadrate în termenul generic de rapoarte.
Un raport este un document economic, în care sunt incluse date predefinite, folosit exclusiv pentru a
fi citit sau vizualizat.
Dintre obiectivele prezentării detaliate a ieşirilor obţinute cu ajutorul sistemului existent pot fi
enumerate:
1. Determinarea formatului şi conţinutului ieşirilor
În funcţie de aceste elemente, se va constata, din discuţiile purtate cu utilizatorii, dacă sunt mulţumiţi
de ieşirile generate de sistem sau ele trebuie modificate, fie din punct de vedere al conţinutului, fie al
formei.
De exemplu, dacă un raport privind comenzile primite de la clienţi, într-o perioadă de timp, este
generat în mai multe exemplare şi conţine informaţii pe care o parte din utilizatori nu le folosesc, este
necesară regândirea conţinutului raportului, fie prin eliminarea acelor informaţii, fie prin proiectarea a
două tipuri de rapoarte, unul detaliat şi unul sintetic.
O altă situaţie poate fi cea în care raportul se obţine pe suport de hârtie, deşi el este utilizat o singură
dată, după care este arhivat, fără a se mai apela la conţinutul lui. O soluţie ar fi generarea lui în format
electronic, fără a mai fi tipărit.
Ca urmare, analiştii trebuie să urmărească dacă toate câmpurile din conţinutul raportului sunt utile
tuturor utilizatorilor, dacă suportul de prezentare este cel mai eficient mod de a pune la dispoziţie
informaţiile solicitate sau dacă ar trebui modificat din punct de vedere al formei (de exemplu, din raport
de tip tabel în raport de tip grafic, din raport detaliat într-unul de tip drill-down etc.)
 2. Identificarea momentului elaborării rapoartelor
Obiectivul se referă la identificarea frecvenţei cu care se obţin ieşirile, criteriu în funcţie de care se
pot obţine următoarele categorii de rapoarte, prezentate şi în capitolul 1:
x rapoarte programate (la termen) ;
x rapoarte neprogramate, cu rol special (rapoarte ad-hoc) ;
x rapoarte declanşate de excepţii;
x rapoarte la cerere.
Prin acest obiectiv se doreşte evaluarea eficienţei generării rapoartelor în funcţie de modul de
sprijinire a procesului decizional şi de control. De obicei, rapoartele generate la termen sunt solicitate mai
mult pentru respectarea obligaţiilor legale, în timp ce altele sunt răspunsuri la cererile managerilor. În
aceste condiţii, se poate determina cât de flexibil este sistemul la nevoile de informare ale utilizatorilor
interni şi externi, indiferent de tipul raportului solicitat. Astfel, este necesar să se identifice toţi utilizatorii
informaţiilor şi să fie încadrate în una din categoriile menţionate pentru a vedea dacă sunt satisfăcute
cerinţele lor, dacă sunt necesare şi alte tipuri de rapoarte.
3. Identificarea circuitului informaţiilor de ieşire la nivelul organizaţiei
Obiectivul se poate realiza răspunzând la următoarele întrebări:
x cine este beneficiarul listei/situaţiei, ecranului sau răspunsului la întrebare? Se identifică
locul/locurile din firmă unde sunt necesare informaţiile. De exemplu, situaţia comenzilor primite
de la clienţi poate fi solicitată de cei de la depozite, în vederea pregătirii produselor pentru livrare,
de cei de la producţie, pentru a planifica producţia, de marketing, pentru a analiza tendinţele
pieţei, de salarizare, pentru a calcula salariile agenţilor de vânzări etc. În această situaţie, este
important să se determine dacă este eficientă obţinerea unui singur raport, în mai multe
exemplare, care să fie transmis tuturor celor interesaţi sau e mai bine să fie generate rapoarte cu
conţinut diferit, în funcţie de nevoile fiecărui beneficiar.
x câte persoane folosesc sau văd listele/situaţiile, ecranele sau răspunsurile la întrebări? Se
determină numărul exact al exemplarelor în care trebuie obţinut raportul, pentru că un tip de
beneficiar ar putea fi format din mai multe persoane. De exemplu, marketingul e posibil să fie
reprezentat de mai mulţi analişti ce urmăresc aspecte diferite în cadrul aceluiaşi raport: o
persoană este interesată de evoluţia generală a comenzilor pentru un anumit produs, o alta de
tendinţa unui client de a se axa pe anumite produse sau anumite perioade de cumpărare etc.
x unde sunt transmise listele/situaţiile, ecranele sau răspunsurile la întrebări? Unele rapoarte,
potrivit regulamentelor interne sau legislaţiei în vigoare, trebuie să aibă semnătura uneia sau mai
multor persoane pentru asigurarea corectitudinii şi validităţii informaţiilor pe care le conţin. De
exemplu, bilanţul contabil trebuie să poarte semnătura directorului economic, a unui expert
contabil şi a directorului firmei pentru a certifica exactitatea datelor. Acest lucru înseamnă că,
până a ajunge la destinaţie (preşedintele consiliului de administraţie, adunarea generală a
acţionarilor sau asociaţilor, direcţia finanţelor publice), bilanţul trebuie analizat şi verificat de mai
multe persoane. Astfel de aspecte sunt importante pentru a se asigura transmiterea la timp a
rapoartelor la fiecare beneficiar.
x când este solicitată obţinerea ieşirilor de fiecare beneficiar? Chiar dacă, la un moment dat,
conţinutul şi forma unei ieşiri sunt identice, există situaţii când fiecare beneficiar solicită
rapoartele la perioade diferite de timp. Ca urmare, sistemul trebuie să fie capabil să genereze
informaţiile în funcţie de cererile existente. De exemplu, situaţia comenzilor primite de la clienţi
este necesară producţiei la sfârşitul fiecărei săptămâni, pentru planificarea producţiei din
următoarea săptămână, în timp ce marketingul cere lunar această situaţie, pentru stabilirea
acţiunilor promoţionale ale lunii următoare.
x în ce scop sunt utilizate ieşirile? Este o întrebare în funcţie de care se determină dacă informaţiile
din structura ieşirii sunt suficiente sau nu, prea detaliate sau prea sintetice. De exemplu, situaţia
comenzilor primite de la clienţi ar putea fi folosită pentru luarea deciziei de a creşte sau diminua
producţia pentru anumite produse, caz în care sunt necesare informaţii sintetice privind cererile
de produse. Dacă situaţia este folosită pentru a controla activitatea de livrare, atunci informaţiile
sunt mult mai detaliate, cuprinzând cantitatea de produse cerută, perioada de livrare, adresa
pentru livrare, clientul căruia i se face livrarea etc.
 5.1.2 Analiza datelor de intrare
Activitatea de analiză a datelor de intrare urmăreşte toate aspectele legate de documentele sau datele
care sunt supuse prelucrării în sistemul existent (intră în sistem). Abordarea datelor se realizează separat,
în următoarele două situaţii:
1. pentru documentele (inclusiv orice tip de raport) intrate în sistem pe suport de hârtie, când se
recurge la culegerea datelor conţinute de acestea, de către un operator;
2. pentru informaţiile provenite, în format electronic, din alte sisteme/ aplicaţii, care presupun
retratarea sub aspectul compatibilităţii cu formatul datelor existente în aplicaţiile sistemului
analizat.
1. Analiza documentelor de intrare
Din punct de vedere al documentelor, analiza trebuie să reliefeze o serie de aspecte cu privire la
gradul de optimizare a circuitului lor, momentul în care documentul este emis şi cel al prelucrării efective
a datelor, precum şi cu privire la necesitatea culegerii datelor de pe documente pentru a fi supuse
prelucrărilor. Astfel, se va pune accent pe următoarele elemente:
a) locul de provenienţă a documentelor (emitentul), indicându-se atât locurile din interiorul organizaţiei,
cât şi cele externe;
b) data emiterii documentului şi data preluării datelor în sistem, pentru a se şti care este intervalul de
timp dintre momentul apariţiei sursei datelor de intrare şi cel al prelucrării efective;
c) numărul de exemplare în care se întocmeşte fiecare document şi circuitul fiecărui exemplar al
documentului, pentru a se depista eventualele locuri în care documentul ar putea fi supus aceloraşi
tipuri de prelucrări;
d) frecvenţa de apariţie a documentelor, în funcţie de care se va determina timpul necesar pentru
prelucrarea datelor, precum şi stabilirea tipului prelucrării (pe loturi sau on-line);
e) locul de arhivare a documentelor şi momentul în care intră în acest proces, pentru a se stabili dacă
arhivarea este un proces al sistemului sau aparţine altui sistem (cu alte cuvinte, dacă documentul
rămâne sau nu în sistemul analizat);
f) datele preluate din documente pentru a fi supuse prelucrării, astfel încât să se determine dacă sunt
suficiente sau prea detaliate în raport cu nevoile de informare;
g) criteriile de clasificare şi grupare a documentelor, mai ales în condiţiile în care prelucrarea datelor se
face pe loturi, pentru a şti care este ordinea de prelucrare şi care este criteriul după care se face
prelucrarea. Astfel, pot exista situaţii când prelucrarea se face după data emiterii documentelor, după
emitent sau operaţia economică pe care o reflectă. De exemplu, facturile primite de la furnizori pot fi
grupate după data primirii lor, după furnizor sau după conţinutul facturilor (facturi pentru materii
prime şi materiale, facturi pentru prestări servicii, facturi pentru achiziţia de mijloace fixe);
h) codificările utilizate pentru înregistrarea datelor în documente, urmărind să existe concordanţă între
codurile utilizate în documente şi cele existente în sistem, pentru a uşura procesul de prelucrare. De
exemplu, existenţa corespondenţei între codificarea personalului folosită de sistemul de personal-
salarizare şi codificarea folosită de secţiile de producţie, în cadrul fişelor normelor de muncă pentru
fiecare salariat;
i) verificările sau controlul la care sunt supuse documentele, din punct de vedere al legalităţii,
completitudinii şi corectitudinii lor, vizează:
x semnarea documentelor de către persoanele responsabile;
x identificarea eventualelor neconcordanţe între valorile înregistrate şi cele stabilite prin lege;
x completarea tuturor câmpurilor sau explicarea situaţiilor în care nu se solicită această operaţiune;
x verificarea câmpurilor calculate, pentru a se elimina orice sursă de eroare;
j) durata medie a timpului de aşteptare al unui document pentru a fi supus prelucrării, precum şi durata
medie a prelucrării;
k) dependenţele existente între documente pentru a fi supuse proceselor de prelucrare. Cu alte cuvinte,
de stabilit dacă un document poate fi supus prelucrării numai atunci când un alt document este deja
introdus în sistem. De exemplu, factura primită de la furnizor nu poate fi prelucrată până nu au fost
preluate datele de pe notele de intrare-recepţie.
2. Analiza intrărilor din alte sisteme, în format electronic
Referitor la intrările care provin din aplicaţiile altor sisteme, este necesar să se urmărească:
a) identificarea datelor care intră din aplicaţiile altor sisteme, pentru a determina formatul de intrare, de
exemplu sub forma unor fişiere temporare;
b) compatibilitatea structurii datelor, în sensul stabilirii tipului atributelor, a mărimii acestora şi a
formatului, astfel încât datele transmise să nu fie supuse unor retratări, ci direct procesului de
prelucrare;
c) momentele în care sistemul analizat solicită date de la aplicaţiile altor sisteme şi cele în care sunt
oferite efectiv, pentru a se identifica potenţialele întârzieri datorate unor deficienţe ale aplicaţiilor din
alte sisteme sau din sistemul analizat. În situaţia prelucrărilor automate, trebuie urmărite tipurile de
prelucrări (pe loturi sau on-line), platformele pe care rulează aplicaţiile, pentru a fi rezolvată
problema compatibilităţii procedurilor de prelucrare;
d) identificarea datelor care trebuie supuse unor procese de pregătire (regrupări, reordonări sau sortări,
în funcţie de necesităţile sistemului care este supus analizei) şi a celor ce pot fi prelucrate direct.

5.1.3 Analiza modului în care sunt stocate, accesate

şi păstrate datele
Prin această activitate se urmăreşte:
1. modul de organizare a datelor (fişiere, baze de date), astfel încât să se identifice dacă este necesară
conversia datelor din formatul fişier în cel specific bazelor de date sau dintr-un format al bazelor de
date în altul;
2. descrierea atributelor, cu specificarea lungimii, formatului şi tipului fiecărui atribut din fişierele şi
bazele de date ale sistemului, relaţiile de dependenţă şi de calcul dintre ele;
3. codificarea utilizată pentru entităţile de date din fişiere şi baze de date, pentru a observa dacă este
necesară o recodificare a datelor înscrise în documente sau a celor existente în înregistrările din
fişiere sau baze de date;
4. identificarea datelor necesare prelucrărilor care nu se regăsesc în fişierele sau bazele de date ale
sistemului. Această situaţie poate fi determinată de faptul că unele date sunt rezultatul altor
prelucrări (de exemplu, calculul valorii unei comenzi), când nu este necesară memorarea lor, sau
date care nu au fost preluate în sistem, dar ale căror valori trebuie incluse în prelucrări, ceea ce
impune modificarea structurii fişierelor sau bazelor de date;
5. frecvenţa operaţiunilor de introducere, restaurare, ştergere, modificare a datelor, pentru
determinarea timpului necesar prelucrării, a performanţelor pe care trebuie să le aibă echipamentele
de calcul;
6. timpul necesar pentru obţinerea unor răspunsuri prin interogarea fişierelor sau a bazelor de date;
7. identificarea frecvenţei cu care utilizatorii realizează copii de siguranţă pentru fişierele cu care
lucrează, precum şi suportul pe care se păstrează acestea;
8. protecţia şi securitatea datelor, prin prezentarea drepturilor de acces ale utilizatorilor la fişiere şi
baze de date (cine, ce drepturi are), procedurile de asigurare a integrităţii datelor, de realizare a
copiilor de siguranţă.

5.1.4 Analiza proceselor de prelucrare a datelor

Un proces reprezintă o secvenţă de proceduri intercondiţionate sau acţiuni ce stau la baza finalizării
unei prelucrări. Aceste proceduri sunt, adesea, interdependente, având un flux de date sau structuri de
control bine definite de la o procedură la alta sau de la o acţiune la alta.
O procedură reprezintă un set de acţiuni organizate pentru a atinge un scop anume, cum ar fi:
culegerea datelor de pe un document, adăugarea unei înregistrări într-o tabelă a unei baze de date,
interogarea unui baze de date pentru obţinerea unei liste, calculul unei valori, verificarea dreptului de
acces la o informaţie etc.
O funcţie de prelucrare reprezintă un grup de procese şi proceduri prin care se constituie o
componentă funcţională a sistemului. Pentru fiecare funcţie identificată se specifică procesele şi
procedurile ce trebuie realizate, de una sau mai multe persoane, din unul sau mai multe domenii
funcţionale ale firmei.
Procesele de prelucrare pot fi grupate în mai multe categorii, în funcţie de scopul pe care îl urmăresc,
cum ar fi:
x preluarea datelor de pe documentele sursă, provenite de la componentele organizaţionale,
parteneri externi sau alte sisteme;
x preluarea datelor din alte procese de prelucrare ale sistemului, fie direct, fie prin intermediul unor
locuri de stocare (fişiere sau baze de date), printr-o procedură specifică de citire a datelor;
 x efectuarea de calcule, prin citirea sau preluarea unor date din sistem sau a celor introduse de pe
documentele sursă şi aplicarea relaţiilor de calcul specifice;
x adăugarea, ştergerea şi modificarea înregistrărilor din bazele de date;
x verificarea şi validarea datelor prelucrate;
x detectarea şi corectarea erorilor;
x pregătirea ieşirilor care urmează a fi supuse unor prelucrări ulterioare;
x generarea ieşirilor solicitate de componentele organizaţionale, parteneri sau alte sisteme ş.a.
Din punct de vedere al rezultatului obţinut, procesele de prelucrare pot fi de tipul tranzacţiilor sau
transformărilor, cu următoarele particularităţi:
1. tranzacţiile constau în evaluarea datelor de intrare, în funcţie de care se vor declanşa prelucrările.
De obicei, rezultatul acestei categorii de prelucrări constă în actualizări ale bazelor de date, în
sensul că fiecare intrare va declanşa o tranzacţie de adăugare de noi înregistrări, o tranzacţie de
modificare a valorilor unor înregistrări sau o tranzacţie de ştergere a înregistrărilor. De exemplu,
un sistem informaţional bancar prelucrează operaţiuni bancare de genul: depuneri în cont,
retrageri din cont, calculul şi înregistrarea dobânzilor etc. Toate au ca rezultat adăugări de
înregistrări (crearea unui nou cont), modificări ale valorii înregistrărilor (creşterea soldului unui
cont, printr-o nouă depunere), ştergeri ale înregistrărilor (lichidarea unui cont). Sistemul
informaţional de gestiune a stocurilor prelucrează datele privind recepţiile de materii prime şi
materiale, consumul de materii prime şi materiale, darea în folosinţă a obiectelor de inventar,
scoaterea din uz a obiectelor de inventar, transferuri de bunuri de la o gestiune la alta, vânzarea de
produse etc., care au ca rezultat actualizări ale bazei de date.
2. transformările presupun obţinerea informaţiilor din datele existente, fără a avea ca rezultat
modificări la nivelul înregistrărilor din baza de date. Sistemul de calcul al drepturilor salariale
reprezintă un exemplu tipic pentru acest tip de prelucrări: pe baza numărului de ore lucrate
(intrarea în sistem) se calculează drepturile salariale, prin efectuarea diferitelor calcule privind
tariful orar, sporurile şi reţinerile prevăzute, în final obţinându-se statul de plată şi centralizatorul
statelor de salarii. Un alt exemplu îl reprezintă sistemul de contabilitate generală, a cărui funcţie
principală o constituie înregistrarea cronologică şi sistematică a mişcărilor de valori ce au loc în
firmă. Notele contabile, preluate de la sistemele de evidenţă analitică, sunt transcrise, mai întâi, în
registrul jurnal, apoi ele sunt prelucrate şi sistematizate în cartea mare, pe baza căreia se va
întocmi balanţa de verificare, prin aplicarea regulilor de transformare cunoscute. În final, se va
obţine bilanţul, ce reprezintă principala ieşire a sistemului de contabilitate generală.
La nivelul unui sistem se regăsesc ambele categorii de procese (tranzacţii şi transformări), numai că
unele sunt orientate cu preponderenţă spre tranzacţii, iar altele spre transformări.
În cazul sistemelor automatizate, identificarea proceselor de prelucrare se realizează, relativ uşor,
prin citirea documentaţiei aplicaţiilor (dacă există) sau prin analiza aplicaţiei. Astfel, pentru studierea
modului de descompunere a sistemului, se urmăresc opţiunile meniurilor şi submeniurilor din care sunt
constituite aplicaţiile. Fiecare opţiune va fi analizată din perspectiva acţiunilor pe care le realizează, pe
baza citirii codului sursă sau a documentaţiei utilizatorului.
În cazul sistemelor manuale, procesele de prelucrare trebuie identificate plecând de la persoanele
implicate, în sensul analizei acţiunilor pe care le realizează asupra documentelor, ţinând cont de etapele
ciclului prelucrărilor datelor, descris într-un capitolul anterior. Astfel, se va urmări modul în care are loc
transcrierea unor câmpuri de pe anumite documente în alte documente, sub forma centralizatoarelor,
însumarea câmpurilor ce solicită o astfel de operaţiune, aplicarea unor formule de calcul pentru obţinerea
şi completarea unor câmpuri de pe documentul pe care îl folosesc ş.a.m.d.
De exemplu, în cazul prelucrării manuale a comenzilor primite de la clienţi, se pot desfăşura
următoarele procese:
x preluare, prin telefon sau poştă, a comenzilor de către o persoană de la vânzări;
x scrierea datelor pe un formular specific de comandă sau completarea celui primit cu alte date
necesare prelucrărilor ulterioare, cum ar fi codul clientului, codul produselor, preţul de vânzare;
x căutarea şi citirea informaţiilor (de pe documente centralizatoare sau de altă natură) privind stocul
de produse existent (din fişa de magazie) şi limita de creditare acordată clientului (din fişa de cont
analitic);
x generarea notei de confirmare a comenzii;
x gruparea comenzilor în funcţie de codul clientului, data comenzii, codul produselor etc.;
x centralizarea datelor privind produsele solicitate şi transmiterea lor la producţie şi/sau depozite;
 x arhivarea comenzilor în funcţie de codul clientului sau de dată;
x preluarea informaţiilor privind facturile emise pentru fiecare comandă;
x compararea facturilor cu comenzile primite (cantităţi livrate, ce a mai rămas de livrat);
x întocmirea rapoartelor necesare analizei comenzilor primite şi onorate şi a altor categorii de ieşiri.
Despre identificarea proceselor de prelucrare ale unui sistem vom discuta detaliat în paragraful
următor.
*
* *
Pe un plan mai general, în urma acestor activităţi de studiere a sistemului existent, se va realiza o
documentaţie privind:
x modul în care au loc activităţile de culegere, prelucrare, stocare şi transmitere a informaţiilor;
x modul de utilizare a echipamentelor, softului (dacă este cazul), a resurselor umane;
x dimensiunile şi natura schimbării, determinate prin analiza punctelor tari şi slabe ale sistemului.
Exemple de puncte slabe: inoportunitatea sau inexactitatea informaţiilor obţinute de sistem,
organizarea ineficientă a datelor, costuri mari de stocare a datelor, slaba pregătire a personalului în
utilizarea tehnicii de calcul, slaba organizare a fluxurilor informaţionale.
Pe baza elementelor identificate şi descrise prin studierea sistemului existent, urmează modelarea lui,
cu ajutorul diagramelor fluxurilor de date, diagramelor entitate-relaţie, diagramele stărilor de tranziţie
etc., pentru a crea imaginea grafică a sistemului. Activitatea de modelare este obligatorie în situaţia în
care nu există nici o documentaţie, altfel se folosesc specificaţiile existente. Modelarea va fi prezentată în
capitolele următoare.

Teste de autoevaluare
TA 5.1
1. Care sunt elementele supuse cercetării în timpul studierii sistemului existent?
2. Enumeraţi elementele ce sunt supuse analizei din punct de vedere al documentelor
de intrare sau documentelor sursă.
Răspuns:

5.2 Identificarea proceselor de prelucrare ale sistemului

Aşa cum am văzut, un rol important în analiza sistemului îl are studiul proceselor de prelucrare,
plecând de la evenimentele ce au loc într-o anumită perioadă de timp şi într-un anumit loc, ce ar trebui
memorate de sistem. Evenimentele sunt cele care determină sau declanşează procesele de prelucrare pe
care le execută un sistem, ceea ce înseamnă că este necesară inventarierea şi analiza lor, atenţia fiind
concentrată asupra următoarelor aspecte2:
x mediul în care a avut loc evenimentul, extern sau intern firmei;
x modul de reflectare a evenimentelor prin scopul şi funcţiile sistemului;
x interfeţele cu utilizatorii şi cu alte sisteme, utilizatorii fiind cei mai în măsură să descrie nevoile
informaţionale din punct de vedere al evenimentelor la care trebuie să răspundă sistemul.

2
. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Second Edition, Course
Technology, Thomson Learning, Boston, 2002, pp. 153-157.
 O astfel de analiză permite descompunerea sistemului în componente, pentru a fi studiate separat,
mai uşor de înţeles şi gestionat, fiind una dintre căile cele mai sigure de atingere a obiectivelor de către
noul sistem.
La firma analizată de noi, câteva dintre evenimentele identificate pentru sistemul de gestiune a
clienţilor sunt prezentate în Caseta 5.1.

5.2.1 Tipuri de evenimente

În analiza unui sistem, pentru identificarea funcţiilor de prelucrare, pot fi avute în vedere trei mari
categorii de evenimente: externe, temporale, de stare.
Un eveniment extern reflectă o operaţiune ce are loc în afara sistemului, fiind iniţiat de un agent,
actor sau entitate externă (o persoană, un departament din interiorul firmei sau altă firmă), care furnizează
date sistemului sau primeşte informaţii de la el. Aici nu trebuie să se facă confuzia între entităţile externe
sistemului şi cele externe firmei, pentru că atenţia se orientează spre ceea ce poate să declanşeze
prelucrarea datelor în cadrul sistemului.
Caseta 5.1 – Exemple de evenimente ale sistemului de gestiune a clienţilor la firma ABC
Principalele evenimente de la care se poate pleca pentru identificarea proceselor de prelucrare din
cadrul sistemului de gestiune a clienţilor:
x solicitarea de cataloage de către clienţii potenţiali şi cei existenţi;
x transmiterea de către clienţi a comenzilor;
x livrarea comenzilor de către firmă;
x returnarea produselor de către clienţi;
x încasarea contravalorii produselor vândute.
Principalele date care ar trebui memorate de sistem, generate de evenimentele enumerate, sunt cele
privind clienţii, cataloagele transmise, produsele comandate şi livrate, dar şi cele care nu au putut fi
onorate, debitarea şi creditarea contului clienţilor.
Procesele de prelucrare pe care trebuie să le asigure sistemul se bazează pe evenimentele enumerate
anterior, trei dintre ele fiind declanşate de clienţi (debitarea contului prin livrarea produselor, creditarea lui
prin încasarea valorii produselor vândute sau returnarea produselor, modificări ale datelor privind clienţii
prin transmiterea comenzilor sau a solicitărilor de cataloage). Alte trei procese sunt declanşate de factorul
timp (generarea de rapoarte lunare, transmiterea de înştiinţări clienţilor, generarea de rapoarte sintetice
săptămânale).
De exemplu, entitate externă sistemului de gestiune a aprovizionărilor este furnizorul, care livrează
materiile prime şi materiale, pentru că declanşează prelucrarea datelor privind facturile primite. Însă, şi
comisia de recepţie este entitate externă sistemului de aprovizionare, pentru că oferă informaţii privind
eventualele diferenţe ce apar între datele înscrise în facturile furnizorilor şi cele identificate la verificarea
faptică a cantităţilor primite, reflectate într-un document specific (nota de intrare-recepţie) ce va fi
prelucrat de sistem.
Un alt exemplu de entitate externă îl reprezintă clientul, care poate transmite o comandă, prin care
solicită unul sau mai multe produse. Un astfel de eveniment este esenţial pentru un sistem de gestiune a
clienţilor, dar lui îi sunt asociate şi alte evenimente, în sensul că un client poate să returneze un produs, să
plătească factura pentru comanda onorată ş.a.
Ca urmare, pentru analiza sistemului se vor identifica acele entităţi externe care ar putea solicita
informaţii de la sistem sau care pun date la dispoziţia lui.
Evenimentele externe stau la baza stabilirii principalelor funcţii de prelucrare ale sistemului. La
descrierea lor este indicat să fie folosite denumiri cât mai sugestive, astfel încât entitatea externă să fie
mai uşor de identificat, precum şi acţiunile realizate de aceasta şi care pot afecta sistemul. De exemplu,
operaţiunea Transmiterea comenzii de către client descrie entitatea externă (Clientul) şi acţiunea pe care o
realizează (Transmiterea comenzii), ce va determina preluarea şi prelucrarea comenzilor, reprezentând
una din funcţiile de bază ale sistemului de gestiune a clienţilor.
Evenimentele externe pot fi declanşate şi de nevoile informaţionale ale unor persoane sau
componente organizaţionale din interiorul firmei, cum ar fi solicitarea unor informaţii privind încasarea
facturilor emise clienţilor, pentru actualizarea conturilor. Majoritatea evenimentelor externe pot fi
încadrate în una din următoarele categorii generale:
x entităţile externe transmit date, ca rezultat al unei operaţii economice;
x entităţile externe solicită anumite informaţii pentru derularea unor operaţii economice, fără a se
cunoaşte momentul solicitării;
 x datele memorate, în urma unor evenimente anterioare, trebuie actualizate.
Evenimentele temporale sunt cele care au loc ca rezultat al atingerii unui moment dintr-o perioadă de
timp bine determinată. Multe sisteme generează informaţiile de ieşire la intervale bine definite, cum ar fi
statele de plată emise de sistemul de salarizare, chenzinal sau lunar, lista achiziţiilor pe luna x, generată
de sistemul de aprovizionare ş.a.m.d. Uneori, ieşirile sunt rapoarte pe care conducerea doreşte să le
primească periodic, cum ar fi rapoartele privind eficienţa unei activităţi sau rapoarte cu titlu de excepţie.
Evenimentele temporale sunt diferite de cele externe, prin faptul că sistemul poate să genereze
automat informaţiile solicitate fără să i se specifice ce are de făcut. Cu alte cuvinte, nici un agent extern
sau entitate externă nu declanşează funcţiile de prelucrare ale sistemului, ci factorul timp, entităţile
externe urmând doar să primească informaţia. Identificarea acestui tip de eveniment se poate face plecând
de la găsirea răspunsurilor la o serie de întrebări de genul: Ce informaţii trebuie obţinute la anumite
perioade de timp? Ce prelucrări ar putea fi solicitate în acele momente?
De exemplu, în cazul sistemului de salarizare, procesul prin care se obţin statele de salarii ar putea fi
denumit astfel: Generarea chenzinală/lunară a statelor de plată, ceea ce evidenţiază informaţiile pe care
ar trebui să le prelucreze sistemul şi perioada de timp la care ar trebui să realizeze funcţia respectivă.
Aceste tipuri de evenimente nu este obligatoriu să fie declanşate la date calendaristice fixe, ci pot fi
declanşate şi la îndeplinirea anumitor condiţii, dependente de perioade calendaristice. O situaţie de acest
fel se întâlneşte atunci când un client nu-şi plăteşte factura la data prevăzută, iar sistemul poate genera o
înştiinţare privind întârzierea plăţii, după 15 zile de la expirarea termenului de plată.
A treia categorie de evenimente este cea de stare. Ele apar când se întâmplă ceva în sistem sau este
îndeplinită o condiţie ce declanşează o prelucrare. De exemplu, dacă vânzarea unui produs are ca rezultat
scăderea stocului sub un anumit nivel, atunci este necesar să se emită o comandă de reaprovizionare, iar
evenimentul ar putea fi denumit Emitere comandă de reaprovizionare. Adesea, evenimentele de stare sunt
similare celor temporale, cu excepţia faptului că nu sunt cunoscute momentele de timp când trebuie
declanşate procedurile de prelucrare şi depind de evenimentele externe, fiind executate şi ca rezultat al
altor prelucrări.
Trebuie remarcat faptul că evenimentele temporale şi de stare presupun, în principal, transpunerea
datelor memorate în sistem într-o formă solicitată de diferiţii utilizatorii ai informaţiei, spre deosebire de
cele externe care implică adăugări, modificări sau ştergeri de date.

5.2.2 Identificarea evenimentelor

Definirea evenimentelor care afectează un sistem nu este un demers uşor, dar sunt câteva
recomandări generale ce ar putea ajuta la identificarea şi analiza lor, dintre care mai importante sunt:
x analiza condiţiilor şi răspunsurilor sistemului la anumiţi factori ce ar putea declanşa procesele de
prelucrare;
x urmărirea secvenţei de derulare a operaţiilor economice;
x dependenţa de tehnologie şi posibilităţile de realizare a prelucrărilor;
x analiza fiecărui eveniment independent de altele.
În unele cazuri, este dificil de făcut diferenţa dintre un eveniment şi o serie de acţiuni sau condiţii
care pot conduce la declanşarea lui. Se va lua exemplul unui client care cumpără dintr-un magazin un
produs. Din perspectiva clientului, această cumpărare presupune o lungă secvenţă de evenimente. Un
prim eveniment ar putea fi acela că el avea nevoie de un bun, motiv pentru care va merge la un magazin,
va studia oferta de produse. Pentru că nici unul nu corespunde cerinţelor sale va intra în alt magazin până
va găsi produsul dorit. În final, clientul va cumpăra acel obiect de care are nevoie. Dar analistul trebuie să
gândească o astfel de secvenţă din momentul în care evenimentul afectează sistemul. În exemplul dat,
sistemul va reacţiona numai atunci când clientul a intrat în magazin, a ales produsul şi spune „vreau să
cumpăr acest produs”. Tot ceea ce a fost descris până la achiziţia lui reprezintă doar o secvenţă de condiţii
ce ar putea declanşa un eveniment şi nu evenimentul ca atare.
În alte situaţii, nu este uşor să se distingă între un eveniment extern şi răspunsul sistemului. De
exemplu, după ce clientul s-a hotărât să cumpere produsul, i se solicită să îl achite, iar clientul va putea
opta pentru plata cu card sau în numerar. Este această acţiune un alt eveniment? În acest caz, nu, pentru
că face parte din interacţiunea care are loc pentru finalizarea operaţiunii iniţiale de cumpărare a
produsului.
Modalitatea prin care s-ar putea determina dacă o acţiune este un eveniment sau o succesiune în
cadrul acelui eveniment constă în găsirea răspunsului la întrebarea: Poate fi finalizat procesul de
prelucrare fără să fie întrerupt? sau Sistemul este pregătit pentru următoarea operaţiune sau aşteaptă
prelucrarea în continuare a datelor generate de evenimentul curent? Din momentul în care clientul doreşte
să cumpere produsul, procesul continuă până când achiziţia este finalizată, sistemul putând să intre în
perioada de aşteptare a următoarei operaţiuni, deci a unui nou client care să cumpere un produs şi să
plătească pentru el.
Pe de altă parte, pot să apară situaţii când acţiunile, prezentate ca făcând parte din acelaşi eveniment,
să fie tratate distinct, cum este cazul achiziţiilor pe bază de credit comercial. Se pune întrebarea: Când
clientul plăteşte mai târziu, la sfârşitul lunii, se poate considera că acţiunea face parte din evenimentul de
cumpărare a produsului? În acest caz, nu, pentru că sistemul prelucrează operaţiunea de cumpărare, după
care, până la sfârşitul lunii, când poate avea loc încasarea, prelucrează alte date. Nu se poate opri sistemul
din prelucrarea datelor, generate de alte tipuri de evenimente, până când are loc încasarea. În acest caz,
putem avea două evenimente externe: Cumpărarea, care declanşează procesul de prelucrare Emitere
factură, respectiv Efectuarea plăţii de către client, prin care se declanşează procesul Încasarea facturii, şi
un eveniment temporal care conduce la Generarea situaţiei lunare a contului clientului.
Pentru identificarea evenimentelor este util să se analizeze secvenţa lor, plecând de la entitatea
externă care le declanşează sau este afectată de către acestea. În cazul sistemului de gestiune a clienţilor
de la firma ABC, analistul ar trebui să se gândească la toate evenimentele posibile care ar putea să aibă
loc în legătură cu un client. În primul rând, clientul poate solicita un catalog de produse sau anumite
informaţii despre disponibilitatea unui produs, determinând adăugarea unei noi înregistrări în baza de date
cu numele şi adresa clientului, dacă el este un client nou. Apoi, clientul ar putea să transmită o comandă,
să modifice comanda (de exemplu, să solicite o altă mărime a produselor sau un nou articol), după care
doreşte să urmărească starea comenzii şi momentul livrării. Este posibil ca acel client să-şi schimbe
adresa, ceea ce înseamnă înregistrarea noii adrese la care urmează a fi livrate produsele sau cataloagele
firmei. În final, clientul ar putea să returneze anumite produse care i-au fost livrate. O astfel de abordare a
secvenţei de derulare a evenimentelor poate ajuta la identificarea celor ce trebuie luate în considerare la
prelucrarea datelor.
În caseta 5.2 sunt prezentate cele mai importante evenimente în firma ABC şi pe care sistemul de
gestiune a clienţilor trebuie să le surprindă.
Câteva comentarii asupra termenilor utilizaţi.
Un semnal transmis sistemului atunci când un eveniment a avut loc poartă denumirea de
declanşator. Pentru un eveniment extern, declanşatorul îl reprezintă primirea datelor pe care sistemul
trebuie să le prelucreze. De exemplu, când un client transmite o comandă, detaliile din noua comandă sunt
intrări în sistem. De asemenea, este important să se identifice sursa datelor (entitatea externă
declanşatoare), care, în exemplul dat, este clientul. Însă, declanşatorul poate să-l constituie şi un alt proces
de prelucrare, care transmite o serie de date pentru a fi supuse altor prelucrări. De exemplu, în urma
introducerii datelor de pe comenzile primite de la clienţi, se transmite un flux de date în procesul de
verificare a situaţiei contului clienţilor, pentru a vedea dacă noile comenzi se mai încadrează în limita de
creditare acordată.
Pentru un eveniment temporal, declanşatorul este dat de momentul dintr-o perioadă de timp bine
delimitată când sistemul trebuie să obţină sau să prelucreze ceva. De exemplu, la sfârşitul fiecărei zile,
sistemul trebuie să genereze rapoartele privind operaţiile economice desfăşurate în acea zi cu clienţii
firmei.
Caseta nr. 5.2 – Evenimentele specifice sistemului de gestiune a clienţilor la firma ABC

Sistemul de gestiune a clienţilor implică o mare varietate de evenimente, multe dintre ele similare deja
celor prezentate. Ca evenimente externe au fost identificate:
x verificarea de către client a disponiblităţii unui produs;
x transmiterea unei comenzi de către client;
x modificarea sau anularea de către client a unei comenzi;
x solicitarea de către client sau conducere a informaţiilor necesare verificării stării unei comenzi;
x livrarea/onorarea comenzii;
x returnarea produselor de către client (defecte, shimbarea părerii despre produs, returnare totală sau
parţială);
x solicitarea cataloagelor de produse de către potenţialii clienţi;
x solicitarea din partea departamentului de marketing de a transmite materiale promoţionale
clienţilor;
x schimbarea politicii de creditare a clienţilor (creşterea limitei de creditare, acordarea de
discounturi, reducerea penalităţilor etc.);
x obţinerea unor noi produse, modificarea caracteristicilor produselor existente sau a preţurilor;
 x lansarea de acţiuni promoţionale pentru anumite produse sau anumiţi clienţi.
Se poate observa că multe dintre evenimente au ca entitate externă declanşatoare clientul, în timp ce
altele implică apariţia chiar a departamentelor sau conducerii firmei. Analistul trebuie să dezvolte o listă a
evenimentelor externe, urmărind toate persoanele sau componentele organizaţionale care pot declanşa o
anumită operaţiune de prelucrare sau care solicită anumite răspunsuri din partea sistemului.
Sistemul de gestiune a clienţilor include câteva procese temporale, declanşate de factorul timp,
respectiv:
x generarea rapoartelor privind comenzile primite;
x generarea rapoartelor privind comenzile onorate;
x obţinerea de rapoarte privind potenţialii clienţi;
x generarea rapoartelor privind producerea şi distribuirea de cataloage.
Multe dintre aceste rapoarte sunt periodice, fiind destinate diferitelor compartimente, ceea ce
înseamnă că analistul trebuie să studieze toate rapoartele şi situaţiile pe care sistemul trebuie să le genereze
la anumite perioade de timp.
Pe măsura dezvoltării listei evenimentelor, analistul trebuie să observe şi noteze orice informaţie
suplimentară care poate prezenta interes, prin construirea unui tabel al evenimentelor, în care pe linii sunt
reprezentate evenimentele, iar pe coloane detaliile fiecăruia. Un exemplu de astfel de tabel pentru
evenimentul Solicitare informaţii disponibilitate produs este redat în figura C5.1.

Ce agent/actor extern

generată de sistem?
primeşte ieşirea
Destinaţia:
cazul) ar trebui să fie
generată de sistem?
Ce ieşire (dacă este

Destina?ia
Destinaţia

Client
Răspunsul:

Detalii privind
R?spunsul
sistemului
Răspunsul
sistemului

produsul
stoc
sursa pentru introducerea

existenţeiînînstoc
produs
agentul extern reprezintă

sistemului

Căutareprodus
sistemului

verificarea
Ac?iunea
Acţiunea

?işiverificarea
Pentru un eveniment
extern, actorul sau

existen?ei
datelor în sistem.

Cautare

când un eveniment
Ce face sistemul
Sursa:

Sursa

Acţiunea:
Client

areloc?
Declanşator
Declan?ator
declanşatorul constă în datele

evenimentele temporale, este

pentru un
Cum ştie sistemul că a avut

Cererea
introduse în sistem. Pentru

produs
momentul ce declanşează
loc un eveniment? Pentru
evenimentele externe,

prelucrarea în sistem.

produs
disponibilitateprodus
informa?ii
Declanşatorul:

Solicitareinformaţii
Eveniment

disponibilitate
Solicitare
Ce determină
Evenimentul:

efectueze o
sistemul să

acţiune?

Fig. C5.1 Exemplu de tabel pentru descrierea unui eveniment

(prelucrare după Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing
World, Second Edition, Course Technology, Thomson Learning, Boston, 2002, p. 161)
 În legătură cu întrebarea „Ce trebuie să facă sistemul când un eveniment are loc sau care este reacţia
sistemului la eveniment?”, se va identifica acţiunea pe care trebuie să o execute. Acţiunea reprezintă
prelucrările pe care sistemul le desfăşoară când a avut loc un eveniment şi se concretizează într-o ieşire
sau rezultat bine delimitat. De exemplu, când un client transmite o comandă, sistemul execută procesul de
prelucrare Înregistrare comandă nouă, prin care sunt preluate detaliile din comanda primită şi se adaugă
o nouă înregistrare în tabela de comenzi. Atunci când trebuie să se genereze un raport privind tranzacţiile,
sistemul execută o procedură numită Generare raport tranzacţii zilnice.
În final, trebuie să se identifice rezultatul/răspunsul obţinut de sistem în urma acţiunilor desfăşurate,
acesta fiind o ieşire a sistemului. Când sistemul generează rapoartele privind tranzacţiile zilnice, înseamnă
că se obţin ieşirile sistemului, dar printr-o acţiune se pot genera mai multe rapoarte. De exemplu, când
sistemul creează o înregistrare nouă în fişierul de comenzi, sistemul poate transmite clientului o
confirmare a comenzii, iar detaliile privind comanda sunt trimise depozitelor pentru pregătirea livrării.
Destinaţia este locul unde răspunsul sistemului (ieşirea) este transmis, reprezentată de un agent sau actor
extern. Tot ca destinaţie sunt considerate şi locurile de stocare în care sunt înregistrate datele rezultate în
urma prelucrărilor.
Uneori, o acţiune a unui sistem este posibil să nu genereze imediat un răspuns. De exemplu, dacă un
client doreşte să-şi actualizeze informaţiile privind adresa, ele vor fi modificate în baza de date, dar nu
este necesar ca sistemul să dea un răspuns clientului la această acţiune. Înregistrarea informaţiilor în baza
de date reprezintă însă o parte a acţiunii sistemului la evenimentul de transmitere de către client a noilor
date, ce vor fi folosite la apariţia altor evenimente.
Se poate spune că tabelul evenimentelor este un mijloc eficient de a culege o parte din infomaţiile
necesare stabilirii cerinţelor informaţionale ale sistemului.
În cazul sistemului de gestiune a clienţilor, tabelul evenimentelor este redat în caseta 5.3:
Caseta 5.3 – Tabelul evenimentelor pentru sistemul de gestiune a clienţilor la firma ABC

Eveniment Declanşator Sursa Acţiunea Rezultat Destinaţie

Solicitare Cererea pentru Client Căutare existenţă Detalii privind Client
informaţii un produs produs în stoc produsul solicitat
disponibilitate
produs
Transmitere de Comandă Client Crearea unei Date client Birou (credit
către client a unei comenzi noi comercial)
comenzi Confirmare comandă Client
Detalii comandă
Date tranzacţii Depozit
Bancă
Modificare sau Cerere Client Actualizare Confirmare modificare Client
anulare comandă modificare/ comandă Detalii privind
anulare modificările Depozit
comandă Date tranzacţii
Bancă

Solicitare rapoarte Sfârşit de Proceduri Generare Rapoarte privind Conducere

privind comenzile să tămână, automate rapoarte privind comenzile
primite lună, trimestru, comenzile
an primite
Solicitare rapoarte Sfârşitul zilei Proceduri Generare Rapoarte privind Contabilitate
tranzacţii automate rapoarte tranzacţiile zilei
tranzacţii
Verificare stare Solicitare Client sau Urmărirea Detalii privind starea Client sau
comandă informaţii Conducere traseului comenzii Conducere
privind starea comenzii
comenzilor
Onorare/ livrare Notificare de Depozit Înregistrarea Date produse livrate Tabela comenzi
comandă onorare a onorării comenzii
comenzii
Returnarea de Notificare de Client Crearea unei Confirmare returnare Client
către client a returnare comenzi pentru Date tranzacţii
produselor returnare Bancă
Solicitare rapoarte Sfârşit de Proceduri Generare Rapoarte privind Conducere
privind comenzile săptămână, automate rapoarte privind comenzile onorate
onorate lună, trimestru, comenzile
an onorate
 Solicitare de către Cererea pentru Client Preluarea Catalog Client potenţial
clienţi a catalog potenţial informaţiilor
cataloagelor de privind catalogul
produse
Solicitare Detalii privind Marketing Distribuire Pachet promoţional Clienţi şi potenţiali
transmitere acţiunile informaţii clienţi
materiale promoţionale promoţii
promoţionale
Schimbare Ajustarea Conducere Modificarea Notificare de ajustare Client
politică de contului contului Date tranzacţie
creditare a clientului clientului Bancă
clienţilor
Modificare Detalii privind Birou Actualizare date Date cataloage Tabela cataloage
preţuri, modificările la cataloage cataloage modificate
caracteristici nivelul
produse, tipuri cataloagelor
produse

Teste de autoevaluare
TA 5.2
1. Descrieţi categoriile de evenimente luate în considerare la analiza sistemului.
2. Definiţi conceptele de declanşator şi acţiune în legătură cu evenimentele dintr-un
sistem informaţional.
Răspuns:

5.3 Determinarea cerinţelor pentru noul sistem

O cerinţă a sistemului informaţional sau cerinţă informaţională reprezintă o funcţie sau o
caracteristică a noului sistem, un comportament cuantificabil şi verificabil pe care sistemul trebuie să-l
aibă, precum şi restricţiile sub influenţa cărora va fi exploatat, toate pentru a răspunde obiectivelor unei
organizaţii şi pentru a rezolva un set de probleme.
Cerinţa mai este definită şi din următoarea perspectivă3:
x condiţia sau abilitatea necesară unui utilizator pentru a rezolva o problemă sau pentru a atinge un
obiectiv;
x condiţia sau capacitatea pe care trebuie să o deţină un sistem sau o componentă a sistemului
pentru a satisface un contract, un standard, o specificaţie sau alt document;
x reprezentarea documentată a unei condiţii sau capacităţi/abilităţi, aşa cum a fost definită la
punctele 1 şi 2.
Cerinţele nu constau doar din funcţii ale unui sistem sau ale unei componente, ci trebuie urmărite
mai multe caracteristici ale acestora, astfel încât să fie exploatat pentru a răspunde eficient unei probleme
sau unui domeniu de activitate.
Am văzut că pe parcursul etapei de planificare a sistemului se identifică scopul sistemului, adică
principalele funcţii şi caracteristici pe care trebuie să le deţină, detaliate în timpul analizei.

3
. Christel, M., Kang, K.C. – Issues in Requirements Elicitation, Technical Report, CMU/SEI-92-TR-012, ESC-TR--92-012,
1992, p. 2.
 Dintr-o perspectivă generală, la nivelul unui proiect de dezvoltare se identifică două categorii majore
de cerinţe ale unui sistem: funcţionale şi nefuncţionale sau tehnice. Însă, se întâlnesc şi alte tipuri, văzute
din perspectiva utilizatorilor sau a managementului de proiect.
Activitatea de determinare a cerinţelor este considerată una din cele mai complexe din faza de
analiză, datorită dificultăţii de evaluare a necesarului de informaţii. În unele situaţii, utilizatorii pot fi
subiectivi când sunt chestionaţi pe o astfel de temă, iar în alte situaţii nu îşi dau seama care sunt
informaţiile de care au nevoie sau le identifică în mod eronat.
La această problemă se adaugă şi diversitatea surselor de informare: de la utilizatorii sistemului
curent, prin observarea a ceea ce fac aceştia, până la studierea documentelor primare, a rapoartelor, a
procedurilor folosite.
Cauzele care determină apariţia problemelor în procesul de culegere a cerinţelor sunt grupate astfel:
x cauze legate de scop – graniţele sistemului sunt greşit stabilite sau utilizatorii/beneficiarii sistemului
specifică detalii tehnice inutile, care mai mult derutează decât să clarifice obiectivele sistemului;
x cauze privind dificultatea înţelegerii dorinţelor utilizatorilor, de unde necesitatea bunei cunoaşteri
de către echipa de analiză a domeniului sistemului, pentru că utilizatorii:
– nu sunt foarte siguri asupra elementelor de care au nevoie;
– nu cunosc îndeajuns de bine performanţele şi limitele mediului lor de lucru;
– nu înţeleg în totalitate domeniul problemei;
– au probleme în comunicarea nevoilor;
– omit informaţii pe care le consideră „implicite”, „normale”;
– cerinţele specificate pot intra în conflict cu nevoile altor utilizatori;
– percep greu limbajul echipei de analiză, mai ales dacă se foloseşte un limbaj pur tehnic;
– formulează cerinţe ambigue sau netestabile.
x cauze legate de volatilitatea informaţiilor. Cerinţele, de cele mai multe ori, se modifică în timp.
Descrierile anterioare au evidenţiat faptul că multe dintre greutăţile care apar se datorează
comunicării dificile între utilizatori şi echipa de dezvoltare a sistemului. Neînţelegerile dintre ei pot duce
la grave probleme în dezvoltarea sistemului, fie prin eforturi umane şi financiare ineficiente, fie prin
nerezolvarea cerinţelor reale ale sistemului propus pentru dezvoltare, aşa cum se poate vedea şi din figura
5.1.
Prin determinarea şi analiza cerinţelor se urmăreşte gruparea şi organizarea lor în seturi
interdependente, identificarea relaţiilor dintre o cerinţă cu altele şi asigurarea corespondenţei dintre ele,
depistarea eventualelor omisiuni sau ambiguităţi, precum şi ierarhizarea cerinţelor în funcţie de nevoile
utilizatorilor.
5.3.1 Tipuri de cerinţe
În timpul analizei, cerinţele pot fi grupate în trei mari categorii, în funcţie de percepţia pe care o au
4
utilizatorii asupra celor prezentate de analist, şi anume :
x cerinţe normale (obligatorii), prezentate de analist în timpul întâlnirilor cu utilizatorii,
considerate ca fiind obişnuite pentru un sistem care se dezvoltă. Exemple de astfel de cerinţe se
referă la tipurile şi formatele de ecrane pentru culegerea datelor, prezentarea funcţiilor de
prelucrare specifice noului sistem, descrierea performanţelor pe care le poate asigura noul sistem;
x cerinţe dorite de utilizatori, considerate implicite pentru un sistem, motiv pentru care utilizatorii
nici nu mai consideră necesară prezentarea lor atunci când sunt întrebaţi. Însă, nedeclararea
acestora poate determina o puternică nemulţumire. Exemple de astfel de cerinţe ar putea fi
descrierea interfeţelor-utilizator, corectitudinea şi siguranţa prelucrărilor, instalarea lejeră a
aplicaţiilor etc.;
x cerinţe „surpriză” , care vin în întâmpinarea aşteptărilor utilizatorilor şi oferă o mare satisfacţie
atunci când sunt prezentate de către analist. Exemple: posibilitatea de a avea la dispoziţie utilitare
incluse în aplicaţia nouă, care, în mod normal, sunt specifice softului de sistem, disponibilitatea
sistemului pentru configurarea de către utilizator a propriilor rapoarte, pe baza instrucţiunilor clar
definite în cadrul aplicaţiei.

4
. Pressman, R.S. – Software Engineering. A Practioner’s Approach. European Adaptation, Fifth Edition, McGraw Hill, London,
2000, pp. 273-274.
 Cum este propus sistemul de Cum a fost „vândut” conducerii
reprezentantul utilizatorilor

Cum a fost planificat de Cum a fost aprobat de comitetul

echipa de dezvoltare de conducere

Cum a fost modelat de analişti Cum a fost scris de programatorii

de aplicaţii

Cum a fost instalat la utilizatori Ce vroiau cu adevărat utilizatorii

Fig. 5.1 Modul de interpretare şi comunicare a informaţiilor

între utilizatori şi echipa de dezvoltare

Din punct de vedere al cerinţelor urmărite în etapele următoare de dezvoltare a sistemului, de către
membrii echipei proiectului, se pot identifica două mari categorii de cerinţe, şi anume:
1. cerinţe funcţionale;
2. cerinţe nefuncţionale sau tehnice;
[Link] Cerinţele funcţionale
Această categorie reflectă necesităţile de modificare a unor funcţii existente sau de dezvoltare a
unora noi. Cerinţele funcţionale sunt oferite, de cele mai multe ori, de către utilizatorii finali.
Cerinţele funcţionale sunt activităţile pe care sistemul trebuie să le desfăşoare, adică funcţiile,
procesele, procedurile de prelucrare, ca răspuns la operaţiunile economice care au loc5. De exemplu, dacă
se dezvoltă un sistem de salarizare, el ar putea include funcţii cum sunt: calculul sumei de plată,
pregătirea fluturaşilor, calculul impozitului pe venitul global, actualizarea informaţiilor despre salariaţi,
obţinerea fişelor fiscale etc. Cerinţele funcţionale se determină plecând de la principalele componente ale
sistemului, şi anume6:

5
. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., pp. 112-113.
6
. Romney, M.B., Steinbart, P.J. – op. cit., p. 591.
 1. intrări – prezentarea unui exemplar din fiecare intrare (document sursă, ieşirea altui sistem),
descrierea conţinutului, sursei şi a persoanei responsabile cu preluarea lor, momentul culegerii;
2. prelucrări – descrierea tuturor proceselor de prelucrare ale noului sistem, respectiv ce va face
sistemul şi de către cine va fi folosit;
3. ieşiri – crearea unui exemplar din fiecare ieşire a sistemului, descrierea scopului, frecvenţei,
destinaţiei şi stabilirea momentului generării;
4. date elementare – definirea datelor elementare (atributele intrărilor, ieşirilor sau locurilor de
stocare) din perspectiva numelui, dimensiunii, formatului, sursei şi semnificaţiei;
5. structuri de date – reprezentarea modului în care datele elementare vor fi organizate din punct de
vedere al înregistrărilor logice;
6. documentaţie – descrierea modului de exploatare şi întreţinere a sistemului;
7. restricţii – definirea constrângerilor legale de care trebuie să se ţină cont în funcţionarea
sistemului, din perspectiva prelucrărilor, intrărilor şi ieşirilor;
8. controale – definirea procedurilor de control, prin care se vor asigura corectitudinea şi încrederea
în date, prelucrări şi informaţii.
În unele cazuri, cerinţele funcţionale sunt bine documentate (regulile şi procedurile existente pentru
desfăşurarea activităţilor economice) şi sunt mult mai uşor de identificat şi descris. Un exemplu ar putea fi
„Toţi salariaţii trebuie să completeze un formular în care să fie înregistrate informaţiile necesare
sistemului de salarizare, cum ar fi ora intrării/ieşirii în/din unitate, cantitatea de produse obţinută,
activităţile prestate etc.”.
În schimb, sunt unele situaţii când regulile economice sunt destul de ambiguu formulate sau dificil
de identificat. Un astfel de exemplu este: „Un comision suplimentar de 2% va fi acordat tuturor
salariaţilor pentru promoţiile speciale adăugate la comenzile preluate de la clienţi”. Din această formulare
se ridică o serie de întrebări: Promoţiile speciale sunt cele care reflectă produsele complementare vândute
de agenţii de vânzări? Comisionul suplimentar se adaugă la valoarea veniturilor (include comisioanele
normale) sau se calculează la salariul de bază?
De asemenea, există posibilitatea ca unele reguli să fie stabilite de către manageri, fără însă să existe
vreun document care să ateste existenţa lor, iar includerea în setul de cerinţe funcţionale depinde de
managerii respectivi, dacă îşi aduc aminte să le menţioneze. Descoperirea regulilor de acest gen este
esenţială pentru proiectarea finală a sistemului, pentru că e posibil ca noul sistem să nu reflecte cele mai
importante cerinţe, cu efecte negative asupra activităţilor economice desfăşurate în firmă.
Plecând de la aceste consideraţii, pot fi amintite cele mai importante cerinţe pentru noul sistem:
x cerinţe de modificare a circuitului informaţional, în sensul eliminării sau adăugării de noi fluxuri
informaţionale, în funcţie de nevoile reale ale utilizatorilor şi de cele de prelucrare ale sistemului,
ca rezultat al apariţiei unor noi reguli sau activităţi economice;
x cerinţe de modificare a structurii datelor, în funcţie de nevoile de organizare a datelor, cum ar fi
trecerea de la un model de organizare la altul, compatibilizarea structurilor de date ale sistemului
cu ale altor sisteme, între care urmează să se stabilească anumite interfeţe;
x cerinţe privind datele elementare, prin adăugarea, eliminarea sau modificarea celor existente,
plecând de la nevoile de generare a unor noi ieşiri, de preluare şi memorare a unor noi date de
intrare;
x cerinţe de schimbare a anumitor proceduri de prelucrare, prin adăugarea sau eliminarea unor
procese, pornind de la cerinţele de informare ale utilizatorilor sau de integrare cu alte sisteme.
Cerinţele funcţionale se regăsesc, cel mai adesea, în reprezentarea sistemului cu ajutorul diferitelor
modele construite în timpul analizei.
[Link] Cerinţele nefuncţionale
Prin cerinţele nefuncţionale, numite şi tehnice, sunt urmărite mai multe obiective operaţionale legate
de mediul hardware şi software în care urmează să funcţioneze noul sistem. Analistul determină aceste
cerinţe, într-o anumită măsură, plecând de la cele funcţionale. Cerinţele nefuncţionale specifică
proprietăţile sistemului, cum ar fi restricţiile de implementare, performanţa, dependenţa de o anumită
platformă de dezvoltare, mentenabilitatea, extensibilitatea şi siguranţa exploatării. Siguranţa se referă la
caracteristici cum ar fi: disponibilitatea, acurateţea, timpul dintre căderile sistemului, defectele la 1000 de
linii de cod, defectele pe clasă de prelucrări. Cerinţele de performanţă fac trimitere la eficienţa cu care se
execută procesele de prelucrare, cum ar fi viteza, timpul de răspuns şi memoria folosită.
Dintre cele mai importante cerinţe formulate de echipa tehnică pot fi amintite:
x disponibilitatea datelor, confidenţialitatea şi integritatea lor;
 x viteza şi timpul de răspuns pentru obţinerea unei informaţii;
x modul de organizare şi stocare a datelor;
x calitatea informaţiilor de ieşire, din punct de vedere al momentului obţinerii lor, al formei de
prezentare şi al modului de transmitere;
x introducerea unor noi tehnologii informaţionale, cum ar fi înlocuirea sistemului de prelucrare de
tip file/server cu arhitectura client/server, trecerea la prelucrările de date bazate pe tehnologia
orientată-obiect, implementarea unei soluţii EDI ş.a.
x platformele de lucru privind sistemele de operare, sistemele de gestiune a bazelor de date, softul
de reţea etc.
De obicei, cerinţele nefuncţionale sunt prezentate în etapa de analiză sub formă narativă, urmând a fi
detaliate în timpul proiectării sistemului.

5.4 Răspunsuri la testele de autoevaluare

TA 5.1 1) Informaţiile de ieşire obţinute din actualul sistem; datele de intrare în sistem; modul în care
sunt stocate şi păstrate datele; procesele de prelucrare la care sunt supuse datele. 2) Locul de provenienţă
a documentelor; data emiterii documentului şi data preluării datelor în sistem; numărul de exemplare;
frecvenţa de apariţie a documentelor; verificările sau controlul la care sunt supuse documentele; criteriile
de clasificare şi grupare a documentelor etc.

TA 5.2 1) Evenimente externe, temporale şi de stare. 2) Declanşator - semnalul transmis sistemului

atunci când un eveniment a avut loc; Acţiune - reprezintă prelucrările pe care sistemul le desfăşoară când
a avut loc un eveniment şi se concretizează într-o ieşire sau rezultat bine delimitat.

5.5 Lucrare de verificare

A. Alegeţi varianta/variantele corectă/e de răspuns:
1) Elementele supuse analizei in timpul studierii sistemului existent sunt:
a) procesele de prelucrare a datelor
b) planul de realizare a sistemului
c) modul in care sunt stocate datele
d) modelul de ciclu de viaţă utilizat pentru dezvoltarea sistemului
2) Care dintre urmatoarele cerinte se inscriu in categoria celor nefunctionale?
a) constrangerile legale de care trebuie sa se tina cont in functionarea sistemului
b) cerintele de modificare a circuitului informational
c) disponibilitatea datelor
d) timpul de raspuns pentru obtinerea informatiilor
3) La descrierea detaliata a iesirilor din sistemul existent (in timpul studierii sistemului existent) se urmaresc:
a) continutul iesirilor
b) momentul elaborarii iesirilor
c) indexarea iesirilor
d) prelucrarile efectuate in vederea obtinerii iesirilor

B. Răspundeţi la următoarele întrebări şi probleme:

1. Ce obiective se urmăresc prin analiza sistemului existent?
2. Enumeraţi aspectele/obiectivele prezentării detaliate a ieşirilor sistemului curent.
3. Ce se urmăreşte la analiza intrărilor provenite din aplicaţiile altor sisteme?
4. Ce se evidenţiază prin analiza modului de stocare, accesare şi păstrare a datelor?
5. Care sunt detaliile ce trebuie evidenţiate în timpul analizei proceselor de prelucrare?
6. Enumeraţi principalele categorii de cerinţe funcţionale ale unui sistem.
7. Firma Turism pentru Studenţi (TS) face rezervări pentru tabere studenţeşti la diferite agenţii de turism.
În timpul semestrului de vară, agenţiile trimit firmei informaţii despre hotelurile disponibile, camerele şi capacitatea
lor, preţul pentru petrecerea unei săptămâni din vacanţa de iarnă. Fiecare agenţie prezintă oferte pentru un număr
diferit de săptămâni în fiecare sezon, precum şi preţuri diferite pentru camere, în funcţie de săptămâna pentru care se
face rezervarea. De obicei, agenţiile oferă o mare varietate de camere, cu capacităţi diferite, astfel încât studenţii pot
să-şi rezerve camera pe care o doresc. Familiile pot rezerva apartamente sau camere de două persoane.
În septembrie, firma Turism pentru Studenţi generează o listă a agenţiilor, săptămânile disponibile, preţul
camerelor, listă pe care o transmite secretariatelor de la facultăţi. Când un grup de studenţi depune o cerere de
rezervare pentru o anumită săptămână şi o anumită agenţie, TS atribuie studenţilor camere cu suficiente locuri şi
transmite fiecărui student o notă de confirmare. Cu o săptămână înainte de cea pentru care au fost făcute rezervările,
TS trimite fiecărei agenţii lista studenţilor pentru care s-au făcut rezervările pe fiecare cameră. Studenţii fac plata la
hotelurile unde şi-au făcut rezervările atunci când ajung. Agenţiile trimit comisioanele direct sistemului contabil al
firmei TS, sistem separat de cel care ţine evidenţa rezervărilor.
Se cer:
a. identificarea evenimentelor la care sistemul de rezervări de la TS trebuie să asigure declanşarea
prelucrărilor;
b. crearea unui tabel complet al evenimentelor, care să conţină evenimentul, declanşatorul, sursa, acţiunea
sistemului, răspunsul, destinaţia. Atenţie la evenimente, pentru a nu le surprinde pe cele care sunt
declanşate pentru a fi prelucrate de sistemul contabil al TS sau al agenţiilor.

5.6 Bibliografie
1. Oprea, D., Meşniţă, G., Dumitriu, F., Analiza sistemelor informaţionale, Ed. Universităţii “Al. I.
Cuza” Iaşi, 2005, pp. 151-173, 286-332
2. Romney, M.B., Steinbart, P.J., Accounting Information Systems, Pearson Education Inc., New
Jersey, 2003, pp. 590-594
3. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002, p.108-113, 153-163