UNIVERSITATEA PETROL-GAZE DIN PLOIEŞTI

Specializarea INGINERIA ŞI INFORMATICA PROCESELOR

CHIMICE ȘI BIOCHIMICE
- Învăţământ cu frecvenţă –

SISTEME INFORMATICE INTEGRATE

Suport de curs

Ploiești 2020
 Unitatea de învățare 7. Faza de analiză
7. 1. Introducere .................................................................................................................................. 2
7. 2. Analiza cerințelor......................................................................................................................... 3
7. 2. 1. Tipuri de cerințe .................................................................................................................. 3
7. 2. 2. Metode de reprezentare ..................................................................................................... 5
7. 2. 3. Activități tehnice.................................................................................................................. 5
7. 3. Documentul specificațiilor software ......................................................................................... 10
7. 4. Validarea cerințelor ................................................................................................................... 12

Durata: 4 ore

Cunoștințe și deprinderi
La finalul parcurgerii acestei unități de învățare veți înțelege:
- care sunt etapele ciclului de viață a unui program;
- care sunt principalele modele de dezvoltare ale unui produs software;
- care sunt avantajele și dezavantajele aplicării unui anumit model.

La finalul parcurgerii acestei unități de învățare veți putea să:

- explicați activitățile principale din fiecare etapă de dezvoltare a unui produs software;
- descrieți atât tipurile de modele de dezvoltare predictive, cât și adaptive;
- identificați situațiile în care se pretează folosirea unui anumit model de dezvoltare.

7. 1. Introducere

Principalele activități ale procesului de dezvoltare software sunt: analiza problemei și

specificarea cerințelor, proiectarea, implementarea (codarea, propriu zisă) și testarea. Faza de
analiză presupune înțelegerea problemei (CE dorește clientul) și are ca scop atât elaborarea
cerințelor utilizator, cât și a cerințelor software.
Această etapă a avut parte de multe ori de o atenție insuficientă în cadrul dezvoltării
unui proiect software ceea ce a dus la crearea multor proiecte vulnerabile ce nu îndeplineau
cerințele inițiale. Astfel, foarte multe companii alocă resurse semnificative (financiare și
umane) pentru a face o analiză a cerințelor eficientă.
Scopul acestei etape constă în transformarea cerințelor unui proiect (informații ce există
în mințile oamenilor care nu sunt organizate, nici complete sau coerente) în specificații formale
și coerente. Specificațiile sunt documente formale ce arată ce dorește, respectiv ce va primi
clientul.
Procesul cerințelor presupune identificarea nevoilor clientului și documentarea acestora
în următoarele etape [2]:
• Analiza cerințelor (Înțelegerea cerințelor) cuprinde găsirea clientului,
identificarea cerințelor, stabilirea limitelor aplicației etc.;
• Specificarea cerințelor, centralizarea acestora în documente formale;
• Validarea cerințelor.
 7. 2. Analiza cerințelor

Analiza cerințelor pune accent pe înțelegerea structurii problemei, identificarea

mediului în care această nouă aplicație se va integra și astfel stabilirea limitelor hardware și
software ale proiectului, precum și găsirea utilizatorilor ce vor folosi efectiv aplicația.
Identificarea cerințelor se realizează prin consultarea diferitelor grupuri de utilizatori
potențiali. Se recomandă ca cerințele să respecte principiul SMART (Specifice, Măsurabile,
Accesibile, Relevante, cu Termene de realizare):
• Specifice – cerințele să fie în legătură doar cu ce se dorește să realizeze proiectul;
• Măsurabile – cerințele să fie cuantificabile, să se poată realiza ulterior o analiză
statistică a rezultatelor;
• Accesibile – să poată fi realizate cu resurse și metode rezonabile;
• Relevante – cerințele să fie utile echipei de dezvoltare, fără detalii inutile;
• cu Termene de realizare – cerințele să aibă termene limită.

✎Exercițiul 1
Dați exemplu de o cerință SMART în cazul aplicației software MonitAer.
Persoana care face identificarea cerințelor trebuie să aibă abilități de comunicare și de
lucru cu oamenii, deoarece interacționează cu diferite grupuri de utilizatori, dar și cunoștințe de
programare pentru a ști dacă cerințele clientului sunt realizabile.
Ca tehnici de extragere a cerințelor pot fi enumerate:
• interviurile cu persoanele direct interesate în dezvoltarea sistemului software;
• studierea produselor software deja existente;
• realizarea unor scenarii de utilizare a produsului;
• crearea unor prototipuri ale viitorului sistem etc.

7. 2. 1. Tipuri de cerințe
Se identifică două mari categorii de cerințe utilizator:
1. cerințe funcționale (Capability Requirements), ce descriu ceea ce așteaptă
utilizatorii să facă produsul software;
2. cerințe non-funcționale surprind diferite constrângeri impuse asupra sistemului.
Cerințele funcționale cuprind precizarea serviciilor pe care trebuie să le ofere sistemul,
cum trebuie să reacționeze sistemul la intrări particulare și cum trebuie să se comporte sistemul
în situații particulare [11].
Exemple de cerințe funcționale pentru SatWatch - un ceas de mână care se actualizează
automat, exemplu preluat din [6] și [7].
• SatWatch este un ceas de mână ce utilizează sateliții GPS pentru a determina
locația curentă și a realiza actualizarea orei în mod automat.
 • SatWatch actualizează ora și data la schimbarea fusului orar sau a granițelor
politice. Proprietarul ceasului nu trebuie să îl reseteze niciodată, ca urmare
ceasul nu are butoane de control.
• SatWatch are aceleași limitări ca orice dispozitiv ce utilizează sateliții GPS
pentru determinarea locației curente (ex. incapacitatea de a determina locația la
anumite momente din zi, în regiunile muntoase). În timpul perioadelor de black-
out, SatWatch consideră că nu se schimbă fusurile orare sau regiunile politice,
dar imediat după terminarea unui interval de acest tip se realizează actualizările
aferente.
• SatWatch are un afișaj pe două linii, cea de sus indicând timpul (ora, minute,
secunde, fus orar), iar cea de jos data (zi din săptămână, data, luna, an).
• În cazul modificării granițelor politice, proprietarul poate actualiza softul
ceasului prin utilizarea dispozitivului WebifyWatch (oferit împreună cu ceasul)
și a unui calculator conectat la Internet.
Conform modelului FURPS+, există diferite tipuri de cerințe non-funcționale (de
calitate) [9][10]:
• Utilizabilitate (eng. usability)- cât de ușor un utilizator învață să opereze
sistemul, să pregătească datele de intrare, să interpreteze datele de ieșire ale
modulelor sau ale întregului sistem. De exemplu existența unui ghid detaliat de
utilizare, sau unui help online, a diferitelor convenții regăsite la nivelul
interfețelor grafice - logo-uri, scheme de culori, tipuri de fonturi etc;
• Performanță (engl. performance) – caracterizată prin timpul de răspuns al
sistemului la interogările utilizatorului, puterea de calcul, acuratețea rezultatelor,
disponibilitatea (măsura în care un sistem este operațional și accesibil atunci
când se dorește utilizarea lui);
• Fiabilitate (eng. reliability) – caracteristica sistemului de a îndeplini funcțiile
cerute în condițiile stabilite, pentru o anumită perioadă de timp. De exemplu,
precizarea unui timp mediu dintre momentele de eșec sau a unei proceduri
urmate în cazurile unor atacuri de securitate etc.;
• Suportabilitate (eng. suportability), include adaptabilitatea (eng. adaptability) -
abilitatea de a modifica sistemul pentru a opera cu noi concepte din domeniul
problemei, mentenabilitatea (eng. maintainability) - abilitatea de a schimba
sistemul pentru a opera cu noi tehnologii sau a repara defecte și
internaționalizarea (eng. internationalization) - abilitatea de a schimba sistemul
pentru a opera cu limbi/unități de măsură/formate numerice străine [7].
Pe lângă acestea, în cadrul modelului există descrise constrângeri suplimentare precum
[6]:
• Constrângeri de implementare, ce includ constrângerile de utilizare a anumitor
unelte, limbaje de programare sau platforme hardware;
• Constrângeri de interfață sunt constrângeri impuse de sisteme externe;
• Constrângeri privind modul de operare;
• Constrângeri de instalare;
 • Constrângeri legale ce cuprind prevederile legale privind licența și certificatul
de utilizare ale produsului software.
Exemple de cerințe de calitate și constrângeri pentru SatWatch:
• SatWatch trebuie să poată fi folosit de către orice utilizator ce știe să citească un
ceas digital și care cunoaște abrevierile legate de fusurile orare(cerință legată de
utilizabilitate);
• După o perioadă de black out, SatWatch trebuie să afișeze fusul orar corect în
maxim5 minute (cerință legată de performanță);
• Nu trebuie să apară nicio eroare care să necesite restartarea ceasului, deoarece
SatWatch nu dispune de butoane (cerință legată de fiabilitate);
• SatWatch trebuie să poată efectua upgrade-uri prin intermediul interfeței seriale
WebifyWatch (cerință legată de suportabilitate);
• Softul SatWatch va fi scris integral în Java, pentru conformanța cu standardele
companiei (constrângere de implementare);
• SatWatch se conformează interfețelor fizice, electrice și software definite de
WebifyWatch 2.0 (constrângere de interfață).

✎Exercițiul 2
Enumerați câteva cerințe non-funcționale pentru sistemul MonitAer.

7. 2. 2. Metode de reprezentare
Limbajul natural reprezintă cea mai intuitivă metodă de reprezentare a cerințelor
utilizator. Aceasta prezintă însă diferite neajunsuri, precum: ambiguitatea (utilizatorii și
dezvoltatorii trebuie să interpreteze aceleași cuvinte în același fel, ceea ce prin utilizarea
limbajul natural este dificil), supra-flexibilitate ( același lucru poate fi spus în mai multe moduri
în documente), lipsa modularizării ( structurile limbajului natural nu sunt adecvate structurării
cerințelor sistem).
Ca alternative ale reprezentării în limbaj natural, au fost dezvoltate diferite metode:
limbajul natural structurat, formule, tabele, diagrame de flux de date, elemente de modelare
UML: cazuri de utilizare, diagrame de cazuri de utilizare pentru delimitarea sistemului in
mediul său de operare, diagrame de secvență pentru descrierea scenariilor de utilizare a
sistemului etc [11].

7. 2. 3. Activități tehnice
Pentru utilizarea metodei elementelor de modelare UML sunt efectuate următoarele
activități tehnice:
• Identificarea actorilor;
• Identificarea scenariilor;
• Identificarea cazurilor de utilizare;
• Rafinarea cazurilor de utilizare;
 • Identificarea relațiilor între cazurile de utilizare;
• Identificarea cerințelor non-funcționale.
Identificarea actorilor permite delimitarea sistemului de mediul în care urmează să
activeze. Pentru acest lucru se încearcă să se răspundă la întrebări asemănătoare cu acestea:
• Care sunt grupurile de utilizatori care execută funcțiile principale ale sistemului?
• Care sunt grupurile de utilizatori care execută funcții secundare, precum cele de
întreținere sau administrare?
• Care sunt grupurile de utilizatori a căror activitate este suportată de sistem?
• Care sunt echipamentele hardware și sistemele software externe cu care sistemul
în dezvoltare va interacționa?
Pentru sistemul MonitAer actorul principal este responsabilul ce monitorizează
măsurarea valorilor parametrilor atmosferici și analiza calității aerului, iar pentru SatWatch se
pot identifica în rolul de actor atât proprietarul ceasului, cât și sistemele GPS și WebifyWatch.
Identificarea scenariilor
Pentru a avea o bază de înțelegere comună cu utilizatorii, dezvoltatorii creează diferite
scenarii de folosire a sistemului ce se dorește a fi implementat. Pentru aceasta, ei consultă
documentele rezultate din interviurile cu clienții și utilizatorii, diferite manuale ale unor sisteme
anterioare, manuale procedurale, standarde ale companiei, note etc. Întrebările al căror răspuns
ajută în această etapă pot fi:
• Care sunt acțiunile pe care clientul dorește să le execute sistemul?
• Care sunt informațiile la care are acces actorul? Cine creează aceste date? Pot fi
ele modificate sau șterse? De către cine?
• Care sunt modificările externe despre care actorul trebuie să informeze sistemul?
Cât de des trebuie să efectueze aceste notificări? Când?
• Care sunt evenimentele despre care sistemul trebuie să informeze actorul? Cu ce
periodicitate?
Exemple de scenarii pentru sistemul MonitAer au fost date în cadrul unității de învățare
UI4.
✎Exercițiul 3
Dați exemplu de scenarii pentru SatWatch.

Identificarea cazurilor de utilizare

Un scenariu reprezintă o instanță a unui caz de utilizare. Acesta este inițiat de către un
actor, dar pe parcursul fluxului de evenimente pot fi implicați și alți actori. Un caz de utilizare
reunește o serie de interacțiuni asemănătoare.
Pentru descrierea unui caz de utilizare se respectă, de obicei, următoarele reguli [6]:
• Numele cazurilor de utilizare trebuie să reflecte ce încearcă utilizatorul să
realizeze (ex. AfisareParametru, RaporteazaUrgență, AlocăResurse);
• Numele actorilor să fie exprimate prin substantive (ex. Responsabilul,
OfițerTeren, Proprietarul);
 • Un caz de utilizare trebuie să descrie o tranzacție completă (ex.: cazul Afișare
valoare index general descrie toți pașii, de la inițierea cererii de afișare și până
la primirea valorii indexului general pentru stația, data și ora dorită);
• Excepțiile se descriu separat;
• Frontiera sistemului trebuie să fie clară, distingându-se între acțiunile
utilizatorului și cele ale sistemului;
• Interacțiunile care definesc cazul de utilizare trebuie formulate la modul activ;
• Descrierea unui caz de utilizare nu trebuie să depășească două-trei pagini. În caz
contrar, cazul se descompune, folosind relațiile între cazuri de utilizare.
Exemplu pentru aplicația MonitAer, cazul de utilizare Afișarea valorii indicelui general
este prezentat în Tabelul 1,

Tabelul 1 Cazul de utilizare Afișarea valorii indicelui general

Nume Afișarea valorii indicelui general la o anumită oră

Participanți
Flux de evenimente
Condiții de intrare
Condiții de ieșire
Cerințe de calitate
Responsabilul
1. Responsabilul, care dorește să afișeze valoarea indexului
specific la o anumită oră, completează rubricile afectate datei și
orei cât și a stației de monitorizare dorite și apoi apasă butonul
“Afișare”;
2. Sistemul preia datele si verifica dacă stația există în lista stațiilor
de monitorizare, iar pentru data și ora cerute sunt valori
înregistrate;
3. Sistemul verifică datele introduse de Responsabil;
4. Sistemul caută valorile dorite;
5. Sistemul afișează valoarea indicelui general calculat la stația,
data și ora indicată de Responsabil.
Responsabilul a pornit cu succes aplicația.
Responsabilul a primit valoarea calculată pentru indicele general, SAU
o explicație privind motivul eșecului tranzacției.
Confirmarea validității stației, datei și orei introduse este efectuată în
maxim 10 de sec.
Răspunsul dorit ajunge în maxim 10 de sec. după ce a fost calculat.

Rafinarea cazurilor de utilizare

Scopul acestei etape îl constituie identificarea unor posibile funcționalități neacoperite
de scenariile descrise (cazurile rare sau excepțiile) și remodelarea cazurilor de utilizare existente
sau introducerea unor noi cazuri. După identificarea inițială a actorilor și cazurilor de utilizare,
în această etapă se pune accent pe definirea frontierei sistemului, pe introducerea detaliilor
suplimentare cât și a constrângerilor asociate [7]. Se introduc detalii referitoare la informația
utilizată de către sistem, la interacțiunile dintre actori și sistem, la drepturile de acces ale fiecărui
actor, la cazurile de excepție etc. În Tabelul 2 este prezentată rafinarea cazului de utilizare
Afișarea valorii indicelui general.
 Tabelul 2 Rafinarea cazului de utilizare Afișarea valorii indicelui general

Nume Afișarea valorii indicelui general la o anumită oră

Participanți Responsabilul
Flux de evenimente 1. Responsabilul, care dorește să afișeze valoarea indexului specific la o
anumită oră, completează rubricile afectate datei și orei ,cât și a stației
de monitorizare dorite și apoi apasă butonul “Afișare”;
2. Sistemul preia datele si verifica dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Sistemul verifică datele introduse de Responsabil;
3a). Dacă stația de monitorizare nu este validă, se execută alternativa
“Stație invalidă”;
3b). Dacă data sau ora introduse nu sunt valide, se execută alternativa
“Dată sau oră invalidă”;
4. Sistemul caută valorile dorite;
4a). Dacă nu există minim trei valori măsurate pentru poluanții vizați se
execută alternativa “Imposibilitate de calcul”;
5. Sistemul afișează valoarea indicelui general calculat la stația, data și
ora indicată de Responsabil.
Alternativa „Stație invalidă”
Responsabilul primește mesajul: „Stația de monitorizare nu există în cadrul
rețelei de monitorizare. Introduceți o stație validă”.
Alternativa „Data sau ora invalidă”
Responsabilul primește mesajul: „Pentru data și ora selectată nu există
înregistrări în cadrul rețelei de monitorizare”.
Alternativa „Data sau ora invalidă”
Responsabilul primește mesajul: „Nu se poate calcula valoarea indexului
specific deoarece nu există valori măsurate pentru minim trei poluanți
atmosferici”.
Condiții de intrare Responsabilul a pornit cu succes aplicația.
Condiții de ieșire Responsabilul a primit valoarea calculată pentru indicele general, SAU o
explicație privind motivul eșecului tranzacției.
Cerințe de calitate Confirmarea validității stației, datei și orei introduse este efectuată în maxim
10 de sec.
Răspunsul dorit ajunge în maxim 10 de sec. după ce a fost calculat.

Identificarea relațiilor
Identificarea relațiilor dintre actori și cazurile de utilizare (comunicare, incluziune,
extindere, generalizare) permite reducerea complexității modelului, eliminarea redundanțelor
și a potențialelor inconsistențe [7].
Unele reguli urmate în această etapă includ:
• Modelarea comportamentului opțional sau de frecvență redusă utilizând relația
de extindere;
 • Factorizarea comportamentului comun mai multor cazuri de utilizare prin relația
de incluziune;
• Evitarea supra-structurării modelului funcțional prin utilizarea judicioasă a
relațiilor (Un singur caz de utilizare mai complex se poate dovedi a fi mai
inteligibil decât un număr prea mare de cazuri mai simple).
Identificarea cerințelor non-funcționale
Pentru a identifica cerințele non-funcționale aferente modelului FURPS+ pot fi utilizate
răspunsurile următoarelor întrebări, prezentate în Tabelul 3[6]:
Tabelul 3 Exemple întrebări pentru identificarea cerințelor non-funcționale

Categorie Exemplu de întrebări

Utilizabilitate Care este nivelul de expertiză al utilizatorilor?
Ce standarde de interfețe sunt familiare utilizatorilor?
Ce tip de documentație trebuie pusă la dispoziția clienților?
Fiabilitate Cât de robust trebuie să fie sistemul?
În cazul unui eșec care este alternativa viabilă (ex. repornirea sistemului)?
Sunt admisibile pierderi de date? Dacă da, ce volum este permis?
Care este procedura de tratare a excepțiilor?
Există aspecte impuse privind siguranța?
Există cerințe privind securitatea?
Suportabilitate Cum se poate extinde sistemul?
Cine va întreține sistemul?
Există probabilitatea de a porta sistemul pe alte platforme hardware/software?
Performanță Există sarcini critice din punct de vedere al timpului?
Câți utilizatori conectați în același timp trebuie să suporte sistemul?
Ce dimensiuni se preconizează că va avea baza de date?
Care este cel mai slab timp de răspuns al sistemului acceptat de utilizatori?
Implementare Există limitări privind platforma hardware?
Există constrângeri impuse echipei de testare?
Există constrângeri impuse echipei de întreținere?
Interfață Cu ce alte sisteme va interacționa sistemul?
Cum sunt exportate/importate datele la nivelul sistemului?
Instalare Cine va instala sistemul?
Pe câte stații va fi sistemul instalat?
Există constrângeri de timp privind instalarea?
Operare Cine administrează sistemul după punerea în exploatare?
Legal Care este procedura de obținere a unei licențe?
Există posibile taxe rezultând din utilizarea anumitor componente / algoritmi?
 Sunt impuse anumite penalizări în cazul căderii sistemului?

7. 3. Documentul specificațiilor software

Documentul cerințelor este declarația oficială a ceea ce se cere de la dezvoltatorii

sistemului. Trebuie să includă atât o definiție a cerințelor utilizator cât și o specificație a
cerințelor sistem. NU este un document de proiectare. În măsura în care este posibil, trebuie
precizat CE, mai curând decât CUM, trebuie să facă sistemul [11].
Standardul IEEE definește o structură generică a unui document al specificațiilor
software, conform Tabelul 4.
Tabelul 4 Structura IEEE generică a unui document al specificațiilor

Capitol Subcapitol
Introducere Scopul documentului cerințelor
Obiectivele și criteriile de succes ale proiectului
Definiții, acronime, abrevieri
Referințe
Sumar al restului documentului
Descriere generală Perspectiva produsului
Funcțiile produsului
Caracteristicile utilizatorilor
Constrângeri generale
Premise și dependențe
Cerințe specifice Cerințe de interfață (Interfețe utilizator, Interfețe hardware, Interfețe
software, Interfețe de comunicare)
Cerințe funcționale (Modulul 1, Modulul 2, ..., Modulul n)
Cerințe non-funcționale (Cerințe de performanță, Constrângeri de design
etc)
Alte cerințe
Apendice
Index

Exemplu de conținut al unui document al specificațiilor, conform [11]:

• Prefață
o Cititorii vizați
o Istoria versiunilor sistemului, incluzând motivarea creării unei versiuni noi
o Rezumatul modificărilor făcute la fiecare versiune
• Introducere
o Necesitatea sistemului
 o Funcțiile descrise pe scurt
o Cum lucrează sistemul cu alte sisteme
o Cum se încadrează sistemul în obiectivele economice și strategice de ansamblu
ale organizației pentru care acesta este dezvoltat
• Glosar
o Definiții ale termenilor tehnici utilizați în document
• Definițiile cerințelor utilizator (notații inteligibile de către clienți)
o Serviciile furnizate utilizatorului
o Cerințe sistem non-funcționale
o Standarde de produs și de proces ce vor fi utilizate
• Arhitectura sistemului
o Descriere generală de nivel înalt a arhitecturii anticipată pentru sistem:
distribuirea funcțiilor pe modulele sistemului
o Componentele arhitecturale reutilizate: trebuie evidențiate (highlighted).
• Specificațiile cerințelor sistem
o Cerințe funcționale în detaliu
o Cerințe non-funcționale în detaliu
o Detalii suplimentare la cerințele non-funcționale: ex. Definiții ale interfețelor cu
alte sisteme.
• Modele ale sistemului
o Unul sau mai multe modele ale sistemului
▪ Modele ale obiectelor
▪ Modele ale fluxurilor de date
▪ Modele semantice ale datelor
o Relații între componentele sistemului
o Relații între sistem și contextul său
• Evoluția sistemului
o Premise fundamentale pe care se bazează sistemul
o Modificări anticipate datorate:
▪ Evoluției hardware-lui
▪ Necesităților în schimbare ale utilizatorului, etc.
• Apendice
o Informație specifică, detaliată referitoare la aplicația ce trebuie dezvoltată
o Exemple: descrieri cerințe pentru:
▪ Hardware: configurații minimale și optime
▪ Bază de date: organizarea logică a datelor, relații între date
 • Index (pot fi mai multe)
o Alfabetic
o Diagrame
o Funcții, etc.

7. 4. Validarea cerințelor

După elaborarea documentelor specificațiilor, acestea sunt supuse etapei de validare. Se

urmărește dacă acestea sunt complete, consistente, clare, corecte.
Specificarea cerințelor se consideră a fi:
• Completă, dacă surprinde toate aspectele precizate de către clienți, au fost
precizate toate scenariile posibile, inclusiv cele de excepție;
• Consistentă, dacă nu există două cerințe ce se contrazic reciproc;
• Neambiguă, dacă nu există o cerință ce poate fi interpretată în diferite moduri
pentru sistemul analizat;
• Corectă, dacă reprezintă fidel interesele clientului și ale dezvoltatorilor, fără a
include elemente nedorite.
Ca o posibilitate de validare a documentului specificațiilor pot fi folosite răspunsurile
următoarelor întrebări [2]:
• Sunt incluse toate resursele hardware?
• Sunt definiți timpii de răspuns ai funcțiilor?
• Sunt definite toate interfețele externe și de date?
• Sunt specificate toate funcțiile dorite de client?
• Este testabilă fiecare cerință?
• Este definită starea inițială a sistemului?
• Sunt specificate răspunsurile la condiții excepționale?
• Sunt specificate posibilele modificări ulterioare?
Bibliografia UI
1. Moldoveanu F., Ingineria programării- notițe de curs, UPB, Facultatea de Automatică și
Calculatoare, secția Calculatoare și Tehnologia Informației 2014,
http://andrei.clubcisco.ro/cursuri/anul-3/semestrul-2/ingineria-programelor.html, accesat 1
august 2017
2. Leon, F., Ingineria programării, notițe de curs, Facultatea de Automatica si
Calculatoare Iași, 2016, http://florinleon.byethost24.com/curs_ip.htm?i=1, accesat 12
iulie 2017
3. Iftene, A., Ingineria programării, notițe de curs Facultatea de Informatica, Iasi, 2016,
https://profs.info.uaic.ro/~adiftene/studenti.html, accesat 12 iulie 2017
4. Ududec Novac, C., Ingineria sistemelor de programe, Editura Alma Mater, Bacău,
2011
5. Anderson,R., Software engineering- course, University of Cambridge, 2015,
https://www.cl.cam.ac.uk/teaching/1516/SWEng/, accesat 20 iulie 2017
6. Bruegge, B., Dutoit A., Object-Oriented Software Engineering Using UML, Patterns,
and Java™ Third Edition, Pearson Hall, 2010
7. Lazar, I., Ingineria sistemelor soft, notițe de curs, Universitatea Babeș Bolyai,
Facultatea de Matematică şi Informatică, specializarea Inginerie Software, 2014
8. Wood, J., Silver D., Joint Application Design, Wiley, New York, 1989
9. Grady, R., Practical software metrics for Project Management and process
improvement, Prentice Hall, Englewood Cliffs, NJ, 1992
10. ***, Institute of Electrical and Electronics Engineers, IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York, NY,
1990
11. Sommerville, I., Software Engineering, Pearson, 2015