ASCS.T6.Clasificarea Cerințelor

Tema 6.
Clasificarea cerințelor
ASCS, dr. ing. Pavel Chirev

Ø O cerinţă este o nevoie fizică sau funcțională
documentată singulară pe care un anumit design, produs
sau proces își propune să o satisfacă.
Ø Cerințele arată ce elemente și funcții sunt necesare pentru
un anumit proiect
Ø Cerințele sunt dezvoltate înainte de proiectare și
implementare a unui sistem informatițional.
ØUn set de cerințe este utilizat ca intrări în etapele de
proiectare și dezvoltarea de produse noi
Categorii de cerințe
• Categorii de cerinţe ale sistemelor informatice
• Definiție:
ü În dezvoltarea sistemelor informatice, o cerinţă defineşte un
deziderat pe care acesta trebuie să-l îndeplinească, ca
răspuns la necesităţile utilizatorilor săi.
ü o cerinţă reprezintă o parte a scopului pentru care se
dezvoltă un proiect informatic.
üCerinţele dictează şi modul în care sistemul trebuie să
răspundă la interacţiunea cu utilizatorul.

üAspecte legate de elaborarea cerinţelor unui sistem:
ØUtilizarea unui limbaj specific domeniului utilizatorului:

- cerinţele trebuie întotdeauna specificate în limbajul
utilizatorului, putând include aici şi vocabularul domeniului
analizat;
Ø Relaţia cerințelor cu obiectivele afacerii:

- fiecare cerinţă trebuie în mod clar legată de obiectivele
oamenilor de afaceri.
•
Ø Cerințe cunoscute
Ø Cerințe necunoscute
- cerințe prescriptive
- Cerințe descriptive
ØCerințe nedescrise și/sau nedeclarate
Categorii de cerințe
Cerințe cerințe nedescrise

Cerințe cunoscute
necunoscute și/sau nedeclarate
Cerințe Cerințe
prescriptive descriptive
• Cerințe cunoscute
• Cerințe cunoscute
• Se manifestă prin faptul că Pentru a fi utilizat în mod eficient, toate
programele scrise pentru calculator au nevoie de anumite
• Cerințe față componente hardware și/sau
• resurse software care trebuie să fie prezente pe un computer.
ØAceste premise sunt cunoscute sub numele de Cerințe de Sistem.
Ø Majoritatea software-ului definește două seturi de
cerințe de sistem: minim și recomandat.

ØOdată cu creșterea cererii de putere și resurse de procesare
mai mari în versiunile mai noi de software, cerințele de
sistem tind să crească.
ØAnaliștii din industria IT sugerează că această tendință joacă
un rol important în special pentru îmbunătățirea sistemelor
informatice existente.
ØUn al doilea sens al termenului Cerințe de Sistem este o
generalizare a acestei prime definiții, oferind cerințele care
trebuie îndeplinite în proiectarea unui sistem sau
subsistem.
•

• Cerințe hardware
• Cel mai comun set de cerințe definite de orice sistem de
operare sau aplicație software sunt resursele fizice ale
computerului, cunoscute și sub numele de hardware ,
• O listă de cerințe hardware este adesea însoțită de o listă
de compatibilitate hardware (HCL), în special în cazul
sistemelor de operare

• Arhitectură
• Putere de procesare
• Memoriacu acces aleatoriu (RAM)
• dispozitiv de stocare a datelor
• Adaptor pentru afișaj
• Hardware Periferice
•

• Cerințe software
• Cerințele software se referă la definirea cerințelor de
resurse software și a condițiilor prealabile care
trebuie instalate pe un computer pentru a asigura
funcționarea optimă a unei aplicații.
• Aceste cerințe sau condiții prealabile, în general, nu
sunt incluse în pachetul de instalare a software-ului
și trebuie instalate separat înainte de instalarea
unei aplicații.

• Printre Cerințele software pot fi:
• Platformă de operare
• API-uri și drivere
• browser web
• Conexiunea la internet (tip și viteză)

• Cerințe
necunoscute
• Cerințe necunoscute
La această categorie de cerințe pot fi atribuite cerințele
care sunt elaborate în cooperare cu stakeholder-ii
Ele sunt determinate de:
- Cerințele domeniului,
- Cerințele de afacere,
- Cerințele stakeholder-ilor
- Cerințele utilizatorilotr
• cerințe nedescrise
și/sau nedeclarate
• Cerințe nedescrise și/sau nedeclarate
• Funcționalități ale sistemului ce nu sunt descrise
în documentație:
I. Cerințe nedescrise- sunt cerințe ce nu au fost
vociferate de utilizator sau de beneficiar - cerințe
ratate – presupunere că sunt subânțelese, deci nu au fost
documentate
- Aceste cerințe ratate pot afecta calitatea
produsului IT
II. Cerințe nedeclarate
- Aceste Cerințe pot provoca mai multe probleme
Printre ele pot fi Cerințe de:
- a gestiona de la distanță sistemul,
- de a obține la distanță date de testare și
- de a instala patch-uri – care permit dezvoltatorilor să
economisească timp, efort și bani în etapa de
implementare experimentală sistemului.
- Aceste funcții Pot influența la securitatea
informațiilor și a Sistemului informațional.
• ASCS, dr. ing. Pavel Chirev
• Majoritatea clienților sunt conștienți de această
parte „gri” a procesului.
• Alt ceva dacă după finalizarea operațiunii de testare
și punere în funcțiune a produsului în exploatarea
industrială, toate aceste funcționalități sunt închise.
• De ce nu se întâmplă acest lucru întotdeauna?
este o întrebare destul de retorică.

Cerinţe necunoscute ale sistemelor informatice
Cerințe
necunoscute
Cerințe Cerințe
descriptive prescriptive

- Prin procesul de inginerie a cerinţelor se urmăreşte
culegerea, elaborarea, corectarea şi adaptarea unui volum
mare de specificaţii, care diferă în ceea ce priveşte scopul
şi modul de exprimare.
O astfel de diferenţiere se poate realiza între cerinţele:
a) prescriptive. Cerințe
necunoscute
b) descriptive;
Cerințe Cerințe
descriptive prescriptive

• Cerințele prescriptive, care oferă soluții de proiectare
sau operaționale,
- sunt utilizate ca ultimă soluție dacă alte cerințe nu pot
fi definite cu suficientă claritate pentru a fi
implementate ca funcționalități obligatorii în
sistemele informaționale.
- Verificare implementării, fie prin test, demonstrație,
inspecție sau analiză.

Cerinţele prescriptive - prezintă proprietăţi pe care
sistemul trebuie să le aibă indiferent de modul în care acesta
va funcţiona.
Astfel de proprietăţi sunt generate (reglementate), de

obicei, de legi sau de constrângeri fizice (de contextul
funcționării sistemului).

Exemple de specificaţii prescriptive:
- Acelaşi vehicul nu poate fi condus de doi șoferi în acelaşi

timp. – reglementare a codului rutier
- O cameră a hotelului ce este în renovare nu poate fi
ocupată. - constrângere fizică
- Un permis de portarmă poate fi eliberat dacă solicitantul
întrunește prescripțiile:
- Are mai mult de 18 ani, are certificat narcologic, are certificat
de la psiholog, are condiții de păstrare arme....
•
• Cerinţele descriptive -
descriu proprietăţile pe care se doreşte să le aibă
sistemul informatic - şi pe care acesta le îndeplineşte
sau nu, acest lucru depinde de modul în care
sistemul va funcţiona.

• Exemple de specificaţii descriptive sunt:
- Un abonat nu poate să împrumute mai mult de trei

cărţi în acelaşi timp.
- Un produs achiziționat trebuie livrat conform orarului
specificat de cumpărător.
- O piesă pentru asamblare a unui calculator trebuie
să aibă parametrii stabiliți de....
•
• Distincţia dintre cerinţele descriptive şi cele
prescriptive este foarte importantă în contextul
ingineriei cerinţelor, în sensul că:
- putem negocia, schimba sau găsi
alternative pentru cerinţele descriptive,
în timp ce
- pentru cele prescriptive aceste lucruri nu sunt
posibile.

În genrtal
Cerințele unui Sistem Informațional descriu
Ce dar nu și Cum
Vor fi realizate unele funcționalități și procese pentru a atinge
scopurile de afacere
Pentru aceasta:
Se produce un document amplu scris în limbaj natural
care conține o descriere a ceea ce va face sistemul
fără a descrie cum îl va face
Documentarea Cerințelor pentru Produsul
IT
• Documentarea Cerințelor pentru Produsul IT
- Una dintre problemele existente în industria IT este absența
unor definiții general acceptate ale termenilor pe care le
folosim pentru a descrie munca noastră.
- Diferiți experți, vorbind despre același document, îl
numesc:
- și cerințele utilizatorilor
- și cerințele pentru software
- și cerințele funcționale
- și cerințele de sistem
- și cerințele tehnologice
- și cerințele de afaceri
- și cerințele produsului.

• Caracteristicile (Unele particularități) interpretării cerințelor
IEEE Glosarul standard al terminologiei de inginerie sisteme și software
ISO/IEC/IEEE 24765- 2017, Systems and software engineering — Vocabulary
definește cerințele Ca:
1. Condiții sau caracteristici necesare pentru rezolvarea problemelor sau
atingerea obiectivelor;
2. Condiții sau capabilități pe care sistemul ar trebui să le posede sau
componente ale sistemului pentru a îndeplini un contract sau pentru a
respecta standardele, specificațiile sau alte documente formale;
3. Reprezentarea documentată a condițiilor sau a capabilităților pentru
alineatele (1) și (2).
Această definiție acoperă cerințele ambelor părți:
- atât pentru utilizatori (comportamentul extern al sistemului),
- cât și pentru dezvoltatorilor (careva parametri ascunși).

• V-om privi Cerințele ca proprietăți pe care produsul trebuie să le
posede pentru a reprezenta o anumită valoare pentru utilizatori.
• Definiția de mai jos confirmă diferențele dintre tipurile de cerințe
(Sommerville și Sawyer, 1997):
• Cerințe ...
Aceasta este o specificație a ceea ce ar trebui de realizat. În ele sunt
descrise: comportamentul sistemului, proprietățile sistemului sau
atributele acestuia. Ele pot fi limitate în Procesul de dezvoltare a
sistemului.
De menționat că- nu există o definiție universală a noțiunii
”cerințe”

• Niveluri de cerințe
Cerințele pentru produsele software constau din două blocuri
Cerințe funcționale și
Cerințe nonfuncționale
cu trei nivele :
- Cerințe de afaceri,
- cerințe utilizator și
- cerințe față de sistem (cerințe funcționale și nefuncționale).
Fig. De mai jos ilustrează modelul de reprezentare a acestor tipuri de
cerințe. De menționat că la fel ca toate modelele, nu este complet, dar
arată schematic organizarea cerințelor.
Ovalele indică tipuri de informații pentru cerințe și
dreptunghiuri - o modalitate de stocare a informațiilor (documente,
diagrame, baze de date).
Cerințe funcționale Cerințe nefuncționale
Cerințe busines
Document despre genul și

limitele proiectului
Reguli de busines
Cerințe utilizator
Parametri de
calitate
Document despre
variante utilizare
Interfață
externă Restricții
Cerințe față Cerințe
de sistm funcționale
Documentare specificare cerințe

față de sistemul informatic (SRS)

• Cerințele de afacere (cerințele business)
Domeniul de interes
Cerințele domeniului Afaceri

Cerințele de afafere
P1 Clienți (participanți)
P2
P3 Cerințe clienti
Cerițe față
de sistem
Determinarea extinderii sistemului și a cerințelor conform ISO/IEC 29148:2011

(Systems and software engineering — Life cycle processes — Requirements engineering)
• Cerințele utilizatorilor (user requirements)
Descriu obiectivele și sarcinile pe care le va rezolva sistemul
pentru utilizatorii.
Modalități excelente de a depune acest tip de cerințe includ
opțiuni de utilizare, scenarii și tabele "eveniment – consecințe".
Astfel, în acest document se indică ce vor putea să facă
utilizatorii cu ajutorul sistemului.
Un exemplu de utilizare este „Efectuarea unei comenzi”
pentru rezervarea biletelor de avion, închirierea unei mașini,
rezervarea unui hotel .... prin Internet.

• Cerințele funcționale (functional requirements)
-Definesc funcționalitatea software pe care dezvoltatorii
trebuie să o construiască pentru a permite utilizatorilor să
își îndeplinească sarcinile în cadrul cerințelor de afaceri.
- Uneori denumite cerințe comportamentale, acestea conțin
clauze cu tradiționalul „trebuie” sau „ ar trebui”:
- „Sistemul ar trebui să trimită utilizatorului o confirmare a
comenzii prin e-mail”.
- Cerințele funcționale descriu ceea ce dezvoltatorul trebuie
să implementeze.

• Termenul de Cerințe de sistem (system
requirements)
se referă la cerințele de nivel înalt pentru un produs care
conține multe subsisteme.
Când vorbim de un sistem, ne referim:
-la software și subsisteme,
- software și hardware,
- la fel și personalul (oamenii) fac parte din sistem, astfel
încât anumite funcții ale sistemului se pot extinde și
asupra personalului.

• Regulile de afaceri (business rules)
includ politici corporative, reglementări guvernamentale,
standarde industriale și algoritmi numerici.
De menționat în continuare că regulile de afaceri nu sunt cerințe față
de software, deoarece sunt în afara limitei oricărui sistem soft.
Cu toate acestea, ele impun constrângeri cu privire la cine poate
efectua specificări sau să dicteze ce funcții ar trebui să aibă sistemul,
impun respectarea reglementărilor relevante.
Uneori, regulile de afaceri devin sursa atributelor de calitate care sunt
implementate în funcționalități.
Prin urmare, putem urmări originea cerințelor funcționale specifice la
regulile lor comerciale corespunzătoare.

• Cerințele funcționale
- Sunt documentate în specificația cerințelor software (SRS),

care descrie pe cât de complet este necesar
comportamentul așteptat al sistemului.
- Specificația cerințelor software este utilizată în dezvoltarea,
testarea, asigurarea calității produselor, gestionarea
proiectelor și funcțiile legate de proiect.

• Cerinţele funcţionale definesc funcţiile unui sistem
informatic
sau ale componentelor acestora, prin intermediul unor
mulţimi de intrări, ale comportamentului şi a ieşirilor.
În această categorie putem încadra calcule, detalii
tehnice, informaţii privind procesarea şi manipularea
datelor, precum şi alte funcţionalităţi care arată, de
exemplu, cum trebuie realizat un caz de utilizare.

• Cerințe non-funcționale
• care descriu obiectivele și atributele calității.
• Atributele de calitate (quality attributes) sunt descrieri suplimentare ale
caracteristicilor unui produs, exprimate printr-o descriere a
caracteristicilor sale, care sunt importante pentru utilizatori sau
dezvoltatori.
• Cerinţele non-funcţionale surprind criteriile care pot fi folosite pentru a
analiza aspectele legate de operaţionalitatea sistemului, şi nu de
comportamentul acestuia.
Acestea impun constrângeri la nivel de proiectare sau de implementare

asupra cerinţelor funcţionale (de exemplu, cerinţe legate de performanţă,
securitate sau fiabilitate sistemului).

Tipuri de cerinţe non-funcţionale

Cerinţele non-funcţionale sunt deseori referite
prin termenul de calităţi ale unui sistem,
dar pot fi menţionate şi ca atribute de calitate,
obiective de calitate, caracteristici de calitate sau
constrângeri.
Aceste caracteristici includ ușurința utilizării, ușurința mișcării, integritatea, eficiența
și toleranța la erori.
Alte cerințe non-funcționale descriu interacțiunile
externe dintre sistem și lumea exterioară, precum și
constrângerile de proiectare și implementare.
•
• Tipuri de Cerinţe non-funcţionale
A. Cerinţele de calitate
- definesc aspecte referitoare la ”cât de bine” trebuie să funcţioneze sistemul.
Acestea includ specificaţii legate de:
- Cerinţele de siguranţă care sunt cerinţe de calitate prin care se preîntâmpină
producerea unor accidente sau degradarea mediului.
- Cerinţele de securitate descriu măsuri de protecţie a sistemului împotriva unor
comportamente nedorite.
- Cerinţele de confidenţialitate arată că anumite informaţii nu pot fi divulgate
părţilor neautorizate.
- Cerinţele de integritate arată că anumite informaţii pot fi modificate dacă acest
lucru a fost realizat într-o manieră corectă şi autorizată.

Cerinţele de calitate (continuare)
- Cerinţele de disponibilitate se referă la faptul că anumite cerinţe
sau resurse pot fi folosite de către persoanele autorizate atunci când
este necesar.
- Cerinţele de fiabilitate constrâng sistemul informatic să
funcţioneze aşa cum este de aşteptat şi de dorit, pentru perioade
lungi de timp. Exceptând circumstanţele excepţionale, sistemul
trebuie să furnizeze servicii într-o manieră corectă şi robustă.
- Cerinţele de performanţă impun condiţii asupra modului în
care operează sistemul, cum ar fi, spre exemplu, timpul maxim
necesar pentru execuţia unei operaţii.
- Cerinţele de interfaţă arată cum interacţionează sistemul cu
mediul, utilizatorii, precum şi cu alte sisteme.

• Cerinţe non-funcţionale
B. Cerinţele de conformitate impun condiţiile necesare astfel încât
sistemul să funcţioneze în conformitate cu legile naţionale,
reglementările internaţionale, normele sociale, constrângerile politice
şi culturale, standarde etc.
C. Cerinţele arhitecturale impun constrângeri structurale asupra

sistemului informatic, astfel încât acesta să poată funcţiona
corespunzător în mediul unde va fi implementat. Oferă dezvoltatorilor
indicaţii privind tipul de arhitectură potrivită pentru sistem.
D. Cerinţele de dezvoltare sunt cerinţe non-funcţionale care constrâng

modul în care sistemul ar trebui dezvoltat, şi nu felul în care acesta ar
trebui să satisfacă cerinţele funcţionale. Sunt inlcuse aici cerinţe privind
costurile de dezvoltare, planul de livrare şi instalare, detalii referitoare la
mentenanţă, portabilitate etc.

Cerințele utilizatorului
- Cum le elicităm?

Soluție de Sistem
Informațional
Determinare
restricții
client Analist

• Cum noi Analiștii procedăm când e vorba de a
elicita cerințrle utilizatorului?
•
• În primul rând, gândiți-vă - cum veți planifica
activitățile de identificare a cerințelor pentru
proiect?
• De menționat că, un simplu plan ridică șansele de
succes în formalizarea cerințelor și face șă fie auzite
așteptările tuturor părților interesate.
• Doar formulând în mod clar cerințele de resurse, de
planificare și de livrare, ne poate scuti de rechemarea
utilizatorlilor pentru a corecta erorile sau alte lucrări.

• Ce trebuie să conțină acest plan?
• În Planul de elicitare a Cerințelor ar trebui să fie
reflecte:
I. Scopul identificării cerințelor, de exemplu:
- validarea datelor de piață,
- cercetarea cazurilor de utilizare sau
- dezvoltarea unui set detaliat de cerințe funcționale
pentru sistem;

II. Strategii și metode pentru identificarea
cerințelor, de exemplu:
sondaje, ateliere, întâlniri cu clienții, interviuri și
alte tehnici,
posibil folosind abordări diferite pentru diferite
grupuri de părți interesate;
•
III. Rezultatele identificării cerințelor, de exemplu:
o listă a cazurilor de utilizare a produselor software,
o specificație detaliată a cerințelor software,
o analiză a rezultatelor sondajului sau o specificație
a atributelor de calitate și performanță;
•
IV. Planificarea și estimarea resurselor
determinați care dintre dezvoltatori și clienți vor fi
implicați în diferite operațiuni pentru a identifica
cerințele;
estimați aproximativ efortul și timpul pentru
identificarea cerințelor;

V. Riscurile asociate cererii de solicitare
identificați factorii care pot interfera cu programul
de solicitare a cerințelor,
evaluați pericolul fiecărui factor și decideți cum să
îl atenuați sau să-l controlați
•
• Elicitarea cerințelor este:
- cea mai dificilă,
- Cea mai importantă,
- Este Locul unde se comit erori și
Cere o comunicare intensivă a Analistului cu Utilizatorul
După cum știți deja din Tema 2, această procedură se
poate dovedi a fi cu succes numai cu condiția cooperării
clienților și dezvoltatorilor.
Analistul trebuie să creeze o atmosferă propice
examinării produsului condiționat.
Dependeța decalajului de frecvența discuțiilor cu clientul (utilizatorul...)
ASCA
ASCS,
dr. ing.
dr. ing.
conf.
Pavel
Pavel
Chirev
Chirev 57
Soluție de Sistem
Informațional
Determinare
restricții
client Analist

• Cerințele de afaceri (business).
• Toate informațiile care descriu:
- relațiile financiare,
- Relațiile de piață sau
- Relațiile între parteneri de busines
- alte relații comerciale
pe care clienții sau dezvoltatorii intenționează să le
obțină prin utilizare produsul aparțin cerințelor
afacerii.

• Principalele afirmații ale utilizatorilor cu privire la
obiectivele lor sau obiectivele de afacere se numesc
variante de utilizare;
- Varianta de utilizare documentată se numește
scenariu.
• La identificarea cerințelor de afaceri - Utilizați variante de
utilizare sau scenarii.
• Colaborați cu utilizatorii pentru decompoziția
scenariilor de utilizare de la general la
scenarii mai concrete.
Cazurile de utilizare pot fi identificate prin descrierea și
modlarea funcționalităților și fluxului de lucru.
O altă modalitate de a identifica cerintele busines este de
a întreba clienții ce obiective își propun atunci când se
așează în fața terminalului.
• Un angajat care spune „Trebuie să fac asta și asta” cel
mai probabil va descrie un caz de utilizare specific,
cum ar fi:
I. "Trebuie să tipăresc o etichetă poștală pentru pachet";
II. „Trebuie să gestionez ”coada” probelor preluate pentru
analiză”;
III. "Trebuie să calibrez controlerul pompei."
• ASCS, dr. ing. Pavel Chirev
• Reguli de afaceri.
Dacă un client afirmă că numai anumite clase de
utilizatori pot efectua anumite acțiuni în anumite
condiții, atunci cel mai probabil el descrie reguli de
afaceri.
Exemplu:
„Un chimist poate comanda o substanță din Lista substanțelor chimice periculoase
de nivel 1 numai dacă: a) are autorizație (are certificat) să lucreze cu compuși
periculoși și b)dacă este inculs în lista angajaților ce efectuează operatii cu compuși
chimici periculoși.”
Verificarea Aceastei condiționări se efectuează prin
modelarea proceului de eliberare substanțe chimice
• De menționat că regulile de afaceri și cerințele de afaceri nu
sunt același lucru.
Iată câteva fraze prin care puteți conclude că utilizatorul descrie
exact regulile comerciale:
1 „Trebuie să fie în concordanță cu ”Reglementarea....” sau cu
”Politică corporativă”;
2. „Trebuie să respectе un anumit standard”;
3. „Dacă aceasta condiție este îndeplinită, atunci se întâmplă
asta și aia”;
4. „procesarea se efectuează conform următoarătorului
scenariu."
• Cerințe funcționale.
• Cerințele funcționale descriu comportamentul așteptat al
sistemului în anumite condiții și acțiuni pe care sistemul le va
permite utilizatorilor să efectueze.
• Cerințele funcționale derivă:
- din cerințele de sistem,
- din cerințele utilizatorului,
- din regulile de afaceri și
- alte surse care stau la baza unei specificații de cerințe produse
IT.
Exemple de cerințe funcționale:
1. „Dacă presiunea în conductă depășește 40,0 psi,
ar trebui să se aprindă lampa de control”;
2. "Utilizatorul trebui să poată sorta lista
proiectelor în ordine alfabetică înainte și inversă";
3. „Când cineva lansează o idee nouă, sistemul
generează un e-mail coordonatorului de idei.”

• Aceste declarații demonstrează modul în care utilizatorii
reprezintă de obicei cerințe funcționale,
• dar aceste declarații nu pot fi scrise direct într-o specificație de
cerințe software.
• În primul caz, înlocuiți „ar trebui să se aprindă” cu „ se aprinde”
pentru a identifica faptul că activarea avertismentului semnal
luminos este extrem de important.
• Al doilea exemplu arată cerințele utilizatorilor, nu cerință
funcșională. Cerința funcțională- aici oferă utilizatorului
funcția de a sorta.

• Indicatori de calitate.
• Afirmațiile privind cât de bine se încadrează un sistem într-un anumit
mod de funcționare sau permite utilizatorilor să efectueze acțiuni
specifice se numesc inicatori de calitate.
• Atenție deosebită cuvintelor pe care utilizatorii le folosesc
pentru a le descrie Caracteristicile dorite ale sistemului: rapid,
ușor, intuitiv, ușor de utilizat, tolerant la erori, fiabil și
eficient. Sunt termeni vagi
• Va trebui să colaborați cu utilizatorii pentru a înțelege exact ce înseamnă
acești termeni vagi și subiectivi și pentru a capta atribute de calitate
clare și verificabile,

• Cazuri de Utilizare sau Scenarii.
• Principalele afirmații ale utilizatorilor cu privire la
obiectivele lor sau obiectivele de afaceri se numesc
cazuri de utilizare;
• Variant documentată se numește scenariu.
• Colaborați cu utilizatorii pentru a reduce scenariile la
cazuri de utilizare mai generale.
• Pentru a identifica cazurile de utilizare cerețile
clienților să descrie fluxul lor de lucru.

• Cerințe de interfață externă.
• Cerințele din această clasă descriu modul în care
sistemul informațional comunică cu restul lumii.
• Specificațiile cerințelor software ar trebui să includă
secțiuni referitoare la interacțiunile cu utilizatorii,
hardware și alte sisteme software.

Pauză
•
•
•
Faza de Analiză a Cerințelor

1. Introducere
2. Metode de analiză
3. Tipuri de specificații
4. Documentul specificațiilor
cerințelor software
5. Validarea
6. Concluzii

1. Introducere
4. Documentul specificațiilor cerințelor
software
5. Validarea
6. Concluzii
• Analiza cerințelor - obiective
• Scopul analizei cerințelor este realizarea unui model al
sistemului (model de analiză, eng. Analysis model) corect,
complet, consistent și neambiguu
• Accentul este pus pe structurarea și formalizarea cerințelor
colectate în etapa de elicitare
• Formalizarea permite de a identifica:
- ambiguități,
- inconsistențe și
- incompletitudini în descrierea cerințelor,
Care ulterior sunt clarificate prin discuții cu clienții/utilizatorii și
modificarea specificației sistemului
• Colectarea și Analiza cerințelor sunt activități concurente, ele
se desfășoară iterativ-incremental
Procesul de analiza – vedere generală
Cerințele
doneniului Cerințe
generale
Cerințețe
de afacere
Punerea
UTILIZATORI problemei
Interveviera
utilizatorilor
Construirea
modelului Modelul
Experiența sistemului
proprie
Experiența din
Lunea reală
8/1/2022 9/1/2022 10/1/2022 11/1/2022 12/1/2022 1/1/2023

7/22/2022 1/20/2023
• Faza de analiză
• Analiza este primul pas al metodologiilor tehnicii de modelare şi are
ca scop construirea unui model precis, concis şi concret al lumi reale.
• În figură este prezentată o vedere generală asupra procesului de
analiză.
• Analistul, cel care efectuează analiza problemei, începe cu definirea
problemei, aşa cum este ea formulată de potenţialii utilizatori.
Analistul va construi un model, care poate fi incomplet, pe baza unor
cerinţe incomplete. De aceea, modelul ulterior va fi rafinat.
• Primul pas în definirea problemei este specificarea cerinţelor.
• Se va stabili
• ceea ce trebuie să facă aplicaţia şi nu cum, şi anume se vor defini:
- scopul problemei;
- necesităţile;
- contextul aplicaţiei;
- diverse presupuneri;
- performaţele necesare;
• În partea de proiectare şi implementare se vor urmări:
- algoritmi;
- structurile de date;
- arhitectura;
- optimizările
• Această fază defineşte cerinţele sistemului, independent de modul în
care acestea vor fi îndeplinite. Acum se defineşte problema pe care
clientul doreşte să o rezolve.
• Rezultatul acestei faze este documentul care conţine specificarea
cerinţelor şi care trebuie să precizeze clar ce trebuie construit.
• Documentul încearcă să redea cerinţele din perspectiva clientului,
definind scopurile şi interacţiunile la un nivel descriptiv înalt,
independent de detaliile de implementare, cum ar fi, de exemplu:
formularea problemei, aşteptările clientului sau criteriile pe care
trebuie să le îndeplinească produsul.
• Graniţa dintre descrierile de nivel înalt şi cele de nivel scăzut nu este
foarte bine trasată.
•
• Faza de analiză poate fi văzută ca o rafinare a detaliilor.
• Distincţia dintre detaliile de nivel înalt şi cele de nivel scăzut sunt puse
mai bine în evidenţă de abordările top-down (unde se merge către
detaliile de nivel scăzut) şi bottom-up (care tind către detaliile de
nivel înalt).
• Documentul cerinţelor, numit specificarea cerinţelor poate fi realizat
într-o manieră formală, bazată pe logică matematică, sau poate fi
exprimat în limbaj natural.
• În mod logic, prima etapă în realizarea unui produs software
constă în stabilirea cu precizie a ceea ce utilizatorul doreşte
de la sistem.
• Dominanta în această etapă o constituie comunicarea dintre
beneficiar (numit utilizator) şi inginerul Analist- Inginerul
care se ocupă de stabilirea cerinţelor utilizatorului, ceea ce
de fapt reprezintă analiza sistemului.
• Totul începe odată cu ideea utilizatorului de a avea un sistem
nou. El colaborează cu analistul pentru definirea cerinţelor şi
specificaţiilor de proiectare ale sistemului.
• Utilizatorul poate să aibă o idee foarte vagă despre ceea ce
doreşte sau, din contra, el poate să ştie foarte exact.
• Teoremă pentru ingineria software
• S-a vorbit în paragrafele precedente despre erorile care apar

în sistemele software mai ales atunci când acestea sunt de
complexitate mare.
• Mai mult, dimensiunea acestora are influenţă directă asupra
costurilor de realizare ale software-ului.
• Să presupunem că avem o măsură pentru dimensiunea unei
probleme P, notată cu M(P), iar costul scrierii unui program
pentru problema P este C(P).
• Dacă P şi Q sunt două probleme pentru care avem M(P) > M(Q) atunci între
costuri există relaţia C(P) > C(Q).
• Deci, cu alte cuvinte costul elaborării programelor, într-o primă aproximaţie
este o funcţie monoton crescătoare de dimensiunea programelor.
• Fie acum două probleme separate şi distincte, notate P şi Q, şi vrem să creem

un program combinat.
• Luând împreună cele două probleme vom obţine o problemă nouă P+Q,
a cărei dimensiune este M(P+Q) > M(P) + M(Q).
Între costuri va exista relaţia : C(P+Q) > C(P) + C(Q)
• Rezultă că este mai uşor de creat două programe mici decât unul mare care
cumulează funcţiile ambelor programe.
• Aceasta se explică prin luarea în consideraţie a complexităţii programelor.
• Pe măsură ce complexitatea creşte, la sigur vor aparea şI mai multe erori,
generate şi de interacţiunea dintre programe.
Fenomenul menţionat este caracteristic tuturor domeniilor în care se rezolvă

probleme
• În toate cazurile la o uşoară creştere a complexităţii unei probleme
(plecând de la o problemă simplă) se remarcă o creştere uşoară a
numărului de erori.
• Mai devreme sau mai târziu însă, numărul de erori începe să crească
foarte repede.
• Tocmai această relaţie dintre elementele problemei şI generarea
erorilor justifică inegalitatea C(P +Q) > C(P) + C(Q).
• Aceasta înseamnă că în cazul problemelor mari pentru a învinge
complexitatea cu un cost mai redus trebuie să se recurgă la
descompunerea problemei în module mai mici şi cvasiindependente.
• Făcând o substituţie în relaţia de mai sus se obţine:
• C(P) > C(P’) + C(P’’) numită teorema fundamentală a ingineriei
programării,
• în care P’ şi P’’ sunt două subprobleme independente prin a căror
rezolvare se soluţionează la un cost mai scăzut problema P.
• Dacă cele două probleme nu sunt chiar independente, atunci trebuie
soluţionată şi interferenţa dintre ele
Relaţiile cost-dimensiune modul şi cost-număr module
• Procesul de analiză este:
- Pentru a identifica caracteristici noi: nu există metode stabilite, cerințele
trebuie vizualizate, necesită creativitate
Pentru clarificarea unor cerințe nevociferate:
- Informațiile există în mințile oamenilor
- - Nu sunt organizate
- Specificații informale, neorganizate, incomplete, incoerente
Scopul fazei
- Elaborare Specificații formale, complete, coerente
- Elaborare unui set de recomandări
De menționat că - Analiza nu se poate automatiza

• Importanța specificațiilor
--Specificațiile sunt documente formale care arată ce dorește / ce va
primi clientul
- Calitatea specificațiilor este vitală
- Specificațiile sunt o formă de comunicare
- Trebuie să aibă volumul potrivit
- Importanța crește cu dimensiunea proiectului
- Împiedică uitarea informațiilor

• Specificațiile fac informațiile:
 Mai sigure
- Când pleacă din proiect programatori experimentați
- Împiedică presupunerile diferite
 Accesibile
- Când intră în proiect programatori noi
 Mai precise
- Ușurează identificarea problemelor

• Schimbarea cerințelor
 Paralizia analizei
- Încercarea de a identifica toate cerințele prea devreme
 Cerințele au o durată limitată
- Mediul comercial se modifică
- Cunoștințele se învechesc
- Limitele psihologice ale echipei privind numărul de cerințe ce pot fi
luate în calcul la un moment dat
- Implementarea cerințelor dintr-o iterație influențează detalierea
cerințelor din iterația următoare

• Abstracția cerințelor
 Cerințele trebuie înțelese de toți în același fel

Granularitatea cerințelor:
ØDeterminată de audiență
v- Nivel general
ØPentru comunicare, estimarea costurilor, prioritizare
vNivel detaliat
ØPentru proiectare și implementare
ØDetaliere pentru o singură iterație
vFormalism
ØSpecificare informală (programare extremă)
ØSpecificare formală (aprobări reglementate, audit, licitații)

●
Faza de analiză
●
1. Introducere
4. Documentul specificațiilor cerințelor software
5. Validarea
6. Concluzii

Procesul cerințelor conține:
 Analiza cerințelor și Înțelegerea cerințelor
 Specificarea cerințelor și Includerea într-un document
 Validarea cerințelorprin aprobare
Tranziția de la analiză la specificare este dificlă
Analiza și specificarea au obiective diferite

- Analiza pune accent pe înțelegerea structurii problemei
- Specificarea arată ce trebuie să facă sistemul, pune accent pe
comportamentul exterior
 Analiza crește gradul de înțelegere și ajută indirect specificarea

 Specificațiile trebuie să conțină toate informațiile necesare în final
unui dezvoltator
 Analiza și proiectarea au obiective diferite
 Analiza – domeniul problemei (CE?)
 Proiectarea – domeniul soluției (CUM?)
• Aplicarea Metodologie SMART la definirea cerințelor
Specifice: Cerințele trebuie să fie legate doar de problemele pe

care încearcă să le rezolve proiectul
Măsurabile: Sunt preferabile cerințele cuantificabile, cantitative,
deoarece sunt mai precise, pot fi agregate, sunt mai ușor de validat și
permit ulterior o analiză statistică a rezultatelor,
Accesibile: Cerințele trebuie să poată fi îndeplinite cu costuri
rezonabile prin metode corespunzătoare,
Relevante: Cerințele trebuie să fie utile echipei de dezvoltare.
O detaliere nesemnificativă îngreunează înțelegerea nevoilor
reale ale clientului
cu Termene de realizare: Cerințele trebuie să aibă termene limită

•Prototipizarea
 Sistem parțial, construit pentru creșterea înțelegerii
 Prototip abandonabil (engl. “throw-away”)
- Se va renunța la el după înțelegerea cerințelor și se va construi
un sistem nou, posibil în alt limbaj
 Prototip evolutiv (engl. “evolutionary”)
- Va fi completat cu alte funcționalități, pentru a deveni sistemul
final

• Prototipul
 Se concentrează de obicei pe:
- Interfața cu utilizatorul
- Funcțiile noi
- Funcțiile care ar putea fi nefezabile
- Funcțiile la care clienții se răzgândesc des
 Conține numai funcții valoroase pentru client
 Nu pune accent pe calitate (excepții, recuperarea datelor și
standardele)
 Prototipizare poate fi:
- orizontală (de exemplu interfața cu utilizatorul) sau
- verticală (o parte a sistemului este construită complet)
 Costul unui prototip abandonabil poate fi nu mai mare de10% din
costul total
- Dar, de fapt, beneficiile reduc costul total

Avantaje prototipizare
-Permite dezvoltatorilor să elimine lipsa de
claritate a cerințelor
- Oferă clienților șansa de a schimba cerințele
într-un mod care nu afectează drastic durata de
dezvoltare
- Facilitează instruirea utilizatorilor finali înainte
de terminarea produsului

●
Faza de analiză
●
1. Introducere
4. Documentul specificațiilor cerințelor
software
5. Validarea
6. Concluzii
Tipuri de specificații

Specificații pentru
subsisteme Specificatii
de proectare
Arhitecturi de SubSuis 1
proectare Plan de
Specificatii
subsisteme testare
de testsre
Specificatiile Specificatii
Specificatii
arhitecturale funcționale de proectare
SubSuis 2
Specificatii
Specificatiile Specificatiile Specificatiile Specificatii de testsre
necesare funcționale de proectare funcționale
Specificatii
UI de proectare
Specificatii
specificații SubSuis 3
funcționale Specificatii
de testsre
Specificatii
de testare
Plan de testare
componente și
produs final
Arhitecturi de Specificații pentru
proectare subsisteme
subsisteme Specificatii
Specificatii de de proectare
performanță SubSuis 1
Plan de
Specificatii
testare
de testsre
Specificatii Specificatii
Specificatii
arhitecturale funcționale de proectare
SubSuis 2
Specificatii
Specificatiile Specificatii Specificatii Specificatii de testsre
necesare funcționale de proectare funcționale
Specificatii
UI de proectare
Specificatii
specificații SubSuis 3
funcționale Specificatii
de testsre
Specificatii
de testare
Plan de testare
componente și
produs final
• Specificații funcționale Specificatiile
Descriu comportamentul observabil: funcționale
 Pentru produsul general
 Pentru fiecare component (specificații individuale)
Conțin:
 Interfețele publice
 Structurile de date și formatele externe
 Dependențele dintre componente
Unele cerințe critice pot fi dublate în paralel,
redundant, cu aceleași interfețe (de exemplu NASA)

• Un vehicul de explorare a planetei Venus a fost pierdut
• Deoarece programul primit de pe Pământ pentru rectificarea orbitei
conţinea instrucţiunea 'DO 3 I = 1.3’;
• instrucţiunea corectă în limbajul FORTRAN ar fi trebuit să
conţină virgulă în loc de punct;
vSpecificațiile arhitecturii Specificatiile
arhitecturale
ØModelul fizic
- Client-server distribuit, aplicație desktop
ØComponentizarea software
- Decizii
“build vs. buy”: ce părți vor fi realizate, ce părți se pot
cumpăra
ØConcurență
-Fluxuri de execuție (decompziția sistemului și executarea în paralel de diferite
echipe)
ØStocarea datelor
-Structura bazelor de date

Specificațiile interfeței cu utilizatorul UI
specificații
Cum se prezintă sistemul utilizatorilor, cum arată și cum
reacționează
Imaginea prezentată utilizatorului poate fi diferită de implementare
- Sistem distribuit cu o interfață unitară
- Funcționalitate redusă pentru o versiune mai ieftină
Conține:
- Descrieri text, imagini, diagrame
- Capturi ecran (dacă există un prototip)
- Stări, tranziții
- Toate ecranele (ferestrele)
- Timpi de răspuns
- Cazuri de eroare

• Atunci când sistemul de alarmă este lansat și senzorul este
declanșat,
• utilizatorul va putea introduce codul de acces numeric
pentru a dezarma sistemul
•
sistemul va furniza feedback utilizatorului
pentru a introduce codul de acces
sistemul va emite un ton audibil după ce utilizatorul
va introduce fiecare cifră a codului de acces
sistemul va da un ton de 1000 Hz la un volum de 75 db timp de

0,5 sec după ce utilizatorul va introduce fiecare cifră a codului
Nivel de detalizare Sistemul trebuie să conțină un generator de sunet capabil

să producă sunet constant în diapazonul 100-2000 Hz
volumul între 70-90 Db
Sistemul trebuie să conțină un difuzor de un inch

Exemplu de specificare interfeață cu utilizatorul capabil să producă sunet în diapazonul 80-8000 Hz
cu o putere între 0.5 – ϯ͘ Ϭwat

Specificatiile
Specificații de proiectare de proectare
ØProiectarea internă – cum vor fi implementate specificațiile funcționale

- API intern (Application Program Interface)
- Algoritmi, interacțiunile fluxuri de execuție
- Limbaje de programare, instrumente de dezvoltare
ØSincronizarea permanentă cu programul scris este dificilă
ØSe recomandă generarea automată a documentației

• Analiză vs. Proiectare - de la abstract la detaliere
de ce sa lansat proiectul (obiective de afaceri)
ce va putea face utilizatorul cu acest produs

(funcționalități, procese, fluxuri)
Ce va construi dezvoltatorul (caracteristici,

cerințe funcționale, caracteristici ale produsului)
componentele sistemului și modul în care se potrivesc

Descreșterea abstractizării (arhitectura produsului, arhitectura UI)
comportamentul individual al componentelor (proiectare

detaliată module sau a clasei, proiectarea bazelor de date,
proiectarea interfeței cu utilizatorul)
Implementarea fiecărei componente

(algoritmi, interfață utlitizator)

Specificatii
• de testare
• Specificații de testare
- Conținlista tuturor testelor, pașii urmați, rezultate
așteptate
- Pentru teste de nivel înalt se folosesc scripturi
- Pentru testele la nivel de cod, testarea unităților, nu se
recomandă specificații
- Codul de test însuși reprezintă documentația strategiei
de testare

Specificații de performanță
Specificatii de
ØArată „cât de bun” este sistemul în performanță
termeni obiectivi și măsurabili
Ø Atribute de performanță:
- Sunt propuse de părțile interesate
- Se pot specifica în mod cantitativ
- Sunt variabile
- Pot fi complexe, compuse din mai multe atribute elementare
- Pot fi prioritizate: compromisuri (de ex. timp de execuție vs. memorie)
Ø Tipuri de atribute:
- De calitate (care este rata de erori)
- De economisire a resurselor (cât se economisește în comparație cu versiunile
anterioare sau cu alte sisteme)
- De capacitate (cât de mult poate face: prelucrare, stocare)

Scrierea specificațiilor
ØSelectarea unui format (engl. “template”) pentru document
Ø Scrierea propriu-zisă (partea grea)
ØRecenzia documentului
ØVersionarea și punerea în circulație
ØCererile de modificare

• Recomandări pentru gestionarea specificațiilor
• Un singur autor pentru un document
- Un document complex se poate descompune în mai multe
părți
• Autorul trebuie să fie persoana potrivită
- Să cunoască problema și să fie capabil să scrie
• Fiecare document trebuie să aibă un proprietar
responsabil
- Proprietarul de la un moment dat poate fi diferit de autorul
inițial

ØRecomandări pentru redactare
üSunt utile exemple de bune practici existente
ü Variantele de lucru (engl. “drafts”) trebuie marcate conform
statutul documentului,
ü Recenzia verifică dacă documentul este corect și bine
prezentat,
ü După terminarea fazei de analiză, specificațiile trebuie
revizuite în mod continuu, în funcție de modificările apărute

• Recomandări lingvistice
ØDocumentele se scriu la prezent, persoana a III-a
ØConvenții pentru terminologie (( conform RFC 2119 (OASISebXML
Messaging Services Version 3.0: Part 1, Core Features,))
üTrebuie (must): cerință absolută

üNu trebuie (must not): interzicere absolute
üAr trebui (should): cerință opțională
üNu ar trebui (should not): recomandare de evitare
üPoate (may): complet opțional
ü “can” Nu se recomandă ()

• The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL,
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119.
•
• 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
• 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
• 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course.
• 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full implications
should be understood and the case carefully weighed before implementing
any behavior described with this label.
•
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One
vendor may choose to include the item because a particular marketplace requires it or
because the vendor feels that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular option MUST be prepared
to interoperate with another implementation which does include the option, though perhaps
with reduced functionality. In the same vein an implementation which does include a
particular option MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the option provides.)
•
6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo
must be used with care and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has potential for causing
harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a
particular method on implementors where the method is not required for interoperability.
•
7. Security Considerations These terms are frequently used to specify behavior with
security implications. The effects on security of not implementing a MUST or SHOULD, or
doing something the specification says MUST NOT or SHOULD NOT be done may be very
subtle. Document authors should take the time to elaborate the security implications of not
following recommendations or requirements as most implementors will not have had the
benefit of the experience and discussion that produced the specification.
• Proceul de scriere a specificațiilor
Ø Scrierea specificațiilor necesită timp și efort
- Este o investiție
-Talent de Analist nu înseamnă și talent literar
-Trebuie scrise doar documentele necesare
Ø Cine nu are timp să scrie specificații, nu are timp
să scrie nici cod de calitate !!!

●
Faza de analiză
●
1. Introducere
4. Documentul specificațiilor cerințelor software
5. Validarea
6. Concluzii

• Importanța SRS
 Documentul specificațiilor cerințelor software engl. “Software
Requirements Specifications”, SRS
- Specificațiile încearcă să depășească bariera de comunicare între
clienți, utilizatori și dezvoltatori
- Specificațiile sunt parte a contractului, altfel, clientul poate
refuza în mod nejustificat produsul
- SRS este o referință pentru validarea produsului final, îi ajută pe clienți să verifice
respectarea cerințelor
- Un SRS de calitate este necesar pentru un produs software de calitate (reduce costul
de dezvoltare)
- Probabilități de detectare a erorilor de analiză: 40% la proiectare, 10% la
implementare, 40% la recepție, 10% în timpul funcționării
- Specificațiile trebuie să fie complete
- Modelarea trebuie să fie suficientă,

• Introducere
• 2. Metode de analiză
• 3. Tipuri de specificații
• 4. Documentul specificațiilor cerințelor
software
• 5. Validarea
• 6. Concluzii
•Etapele procesului de validare
•În general, Procesul de validare al oricărui produs IT se
efectuează la fiecare fază a ciclului de dezvoltare al unui
produs, de la elaborare cerințe până la utilizare și
întreținere.
•Prin urmare, procesul de validare al produsuli IT este în
conformitate cele 5 faze ale Ciclului de de dezvoltare.
•
Elaborare și Validare funcționalități
Testare și
analiză SRS Acceptare sistem
Modelare Testare
sistem sistem
Proiectare Validare arhitectură

Integrare și
arhitectură testare
Proiectare
T/V module
module
Scriere Validare cod T/V cod

cod
Ciclul de dezvoltare Sistem Informațional

• Verificare vs validare
• Aici să înțelegem clar diferența dintre activitățile de „Verificare”
și „Validare”.
- ”Verificare” - Este procesul de evaluare a sistemuluo și software-ului
în funcție de setul dat de cerințe și specificații, care este realizat în
interior pe sistemului dezvoltat de către dezvoltatori și testeri.
• Pe când
- „Validare” sunt procese de verificări de asigurare a calității -
procese efectuate de clienții externi, proprietari, furnizori asupra
produsului care le este livrat, pentru a verifica adecvarea înainte
de a accepta sau achiziționa produsul.
Activitățile de validare se desfășoară în cea mai mare parte la locul de
producție.
•
Procese de validare
Proceul de verificare
Prin urmare, la dezvoltatra

produselor IT, echipa Ops este
cea care desfășoară activitățile
de validare pentru Sistem și
software elaborat.
Mai mult găsiți:

https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
• Verificarea este doar atunci când încă nu ați consumați
produsul, dar verificați câteva lucruri, examinând
produsul.
• Validarea este atunci când consumați efectiv produsul
pentru a vedea dacă caracteristicele percepute la verificare
snt cele așteptate.
• Verificarea răspunde la întrebarea „ Сonstruiм sistemul
potrivit?” în timp ce
• Validările răspunde la întrebarea, „Am construit corect
sistemul?”
Construiesc eu Construiesc eu
corect produsul? produsul
potrivit?
• V&V în diferite etape ale ciclului de viață al
dezvoltării unui produs TI
• Verificarea și validarea se efectuează la fiecare dintre fazele ciclului
de viață al dezvoltării unui produs TI
• Să aruncăm o privire.
#1) V & V tasks – Planning
 Verification of contract.
 Evaluation of Concept document.
 Performing risk analysis.
#2) V & V tasks – Requirement phase
 Evaluation of software requirements.
 Evaluation/analysis of the interfaces.
 Generation of the systems test plan.
 Generation of Acceptance test plan.
#3) V&V tasks – Design Phase
 Evaluation of software design.
 Evaluation / Analysis of the Interfaces (UI).
 Generation of Integration test plan.
 Generation of the Component test plan.
 Generation of test design.

•
#4) V&V Tasks – Implementation Phase
 Evaluation of source code.
 Evaluation of documents.
 Generation of test cases.
 Generation of the test procedure.
 Execution of Components test cases.
#5) V&V Tasks – Test Phase
 Execution of systems test case.
 Execution of the acceptance test case.
 Updating traceability metrics.
 Risk analysis
#6) V&V Tasks – Installation and checkout phase
 Audit of installation and configuration.
 The final test of the installation candidate build.
 Generation of the final test report.
•
#7) V&V Tasks – Operation Phase
 Evaluation of new constraint.
 Assessment of the change proposed.
#8) V&V Tasks – Maintenance Phase
 Evaluation of the anomalies.
 Assessment of migration.
 Assessment of the retrial features.
 Assessment of the proposed change.
 Validating the production issues.
•
Componentele activităților de validare pentru un Sistem informațional
trebuie să demonstreze că „sistemul este pregătit pentru a fi consumat
de către utilizatori” și să verifice în principal: instalarea cu succes a
sistemului, urmată de funcționalitate și operabilitate.
Oualification
Qualification
Qualification
Qualification
Qualification
Architecture
Reqirimemt
Module
4. MQ -
Sistem
3. AQ -
1. RQ -
5. CQ -
2. SQ
Cod
5 cerințe de calitate ce se verifică în
procesul de validare a produsului
• Abordarea 5Q, RQ-SQ-AQ- MQ- CQ este urmărit ca parte a validării și
va fi realizat de echipa de operațiuni, care sunt responsabili în cele
din urmă pentru implementarea sistemului în producție.
Lansare
Qalificare
text
• Șablonul, planul și orice alte documente care sunt introduse pentru
realizarea 5Q-urilor, vor fi prezentate de echipa de dezvoltare a
sistemului și include abordarea detaliată, sarcinile / activitățile /
testele care vor fi efectuate ca parte a acestor valdări alături cu
rezultatele testului.
• Rapoartele de sinteză vor fi predate echipei Operaționale în timpul
predării sistemului, împreună cu sursa cod și alte livrări.
• În general, scopul realizării 5Q-urilor este de a se asigura că sistemul
poate fi implementat cu succes și că toate funcționalitățile pot fi
utilizate fără blocaje.
• Recenzia cerințelor
 Cea mai des întâlnită formă de validare
- Trebuie să implice clienții și utilizatorii, dar și alte persoane din
echipă sau din organizație
- Listă de verificare:
- 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?
• Teste de utilizabilitate
- Utilizatorul gândește cu voce tare, iar
observatorul aude monologul intern
- Observatorul nu interferează cu explorarea și
descoperirea funcționalităților produsului
software de către utilizator
- Trebuie creată o atmosferă în care este testat
produsul software, nu utilizatorul
• Metrici de calitate
 Numărul de erori descoperite
 Se poate estima statistic distribuția defectelor
 Prea puține erori: SRS foarte bun sau recenzie de slabă
calitate
 Prea multe ambiguități în SRS: se impune continuarea
analizei sau construirea unui prototip
 Frecvența cererilor de modificare
 Măsură a stabilității pentru fazele ulterioare
 Frecvența trebuie să scadă în timp. Dacă nu, analiza nu a
fost făcută bine
• Concluzii
 Faza de analiză specifică CE dorim să construim
 Se referă la domeniul problemei
 Există trei activități principale în această fază:
 Analiza cerințelor
 Specificarea cerințelor
 Validarea cerințelor
 Documentul specificațiilor cerințelor software (SRS)
reprezintă o mulțime de cerințe convenite între client
și echipa de dezvoltare
Literatură:
• - CORNELIA NOVAC UDUDEC. INGINERIA SISTEMELOR DE PROGRAME. EDITURA ALMA MATER BACĂU, 2011
• Exact Difference Between Verification and Validation with Examples
https://www.softwaretestinghelp.com/what-is-verification-and-validation/
• Формализация требований на практике. В. В. Кулямин, Н. В. Пакулин, О. Л.
Петренко, А. А. Сортов, А. В. Хорошилов
{kuliamin,npak,olga,sortov,khoroshilov}@ispras.ru
• Элизабет Халл, Кен Джексон, Джереми Дик, Разработка и управление
требованиями. Практическое руководство пользователя
• METHOD FOR THE IDENTIFICATION OF REQUIREMENTS FOR
DESIGNING REFERENCE PROCESSES
M. Wilmsen 1, , K. Gericke 2, M. Jäckle 1 and A. Albers 1. DESIGN METHODS
1175 INTERNATIONAL DESIGN CONFERENCE – DESIGN 2020
https://doi.org/10.1017/dsd.2020.301
• An Effective Requirement Engineering Process Model for Software Development and
Requirements Management. Dhirendra Pandey . U. Suman, A. K. Ramani
1.Strategie de produs nou - Inovatorii și-au definit clar obiectivele și
obiectivele pentru noul produs.
2.Generarea de idei - Idei colective de brainstorming prin surse interne și
externe.
3.Screening - Condensați numărul de idei de brainstormed.
4.Testarea conceptului - Structurați o idee într-un concept detaliat.
5.Analiza afacerii - Înțelegeți costul și profiturile noului produs și stabiliți dacă
acestea îndeplinesc obiectivele companiei.
6.Dezvoltare de produs - Dezvoltarea produsului.
7.Testarea pieței - Mixul de marketing este testat printr-o încercare a
produsului.
8.Comercializare - Prezentarea produsului publicului.
9.Evaluare - Implică cercetarea pentru a monitoriza progresul ofertei de
servicii noi în raport cu obiectivele organizaționale.
•
Până aici!

ASCS.T6.Clasificarea Cerințelor

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ASCS.T6.Clasificarea Cerințelor

Încărcat de

Drepturi de autor:

Formate disponibile

Tema 6.

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ØUtilizarea unui limbaj specific domeniului utilizatorului:

Ø Relaţia cerințelor cu obiectivele afacerii:

Cerințe cerințe nedescrise

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

Astfel de proprietăţi sunt generate (reglementate), de

ASCS, dr. ing. Pavel Chirev

- Acelaşi vehicul nu poate fi condus de doi șoferi în acelaşi

ASCS, dr. ing. Pavel Chirev

- Un abonat nu poate să împrumute mai mult de trei

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

Document despre genul și

Documentare specificare cerințe

ASCS, dr. ing. Pavel Chirev

Cerințele domeniului Afaceri

Determinarea extinderii sistemului și a cerințelor conform ISO/IEC 29148:2011

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

- Sunt documentate în specificația cerințelor software (SRS),

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

Acestea impun constrângeri la nivel de proiectare sau de implementare

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

C. Cerinţele arhitecturale impun constrângeri structurale asupra

D. Cerinţele de dezvoltare sunt cerinţe non-funcţionale care constrâng

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

ASCS, dr. ing. Pavel Chirev

8/1/2022 9/1/2022 10/1/2022 11/1/2022 12/1/2022 1/1/2023

• S-a vorbit în paragrafele precedente despre erorile care apar

• Fie acum două probleme separate şi distincte, notate P şi Q, şi vrem să creem

Fenomenul menţionat este caracteristic tuturor domeniilor în care se rezolvă

ASCS, dr. ing. Pavel Chirev