Cerințe funcționale și nefuncționale: SEO

Cerintele functionale si nefunctionale reprezinta ansamblul functiilor principale sau nu pe care orice
program trebuie sa le indeplineasca, in acelasi mod serveste la constientizarea clientului asupra
functionalitatilor pe care programul le va indeplini. Aceste funcții sunt denumite aici în sistemul de
poziționare web (SEO)
Cerințe funcționale
 Îmbunătățiți poziționarea față de companiile concurente
 Efectuați actualizarea site-ului web
 Generați cuvinte cheie pentru site-ul web
 Generați adrese URL posibile
 Analizați conținutul tehnic al paginii web (prezența etichetelor și JavaScript sau flash)
 Calculați rata de respingere pentru a determina popularitatea site-ului
 Calculați numărul de cuvinte cheie pe pagină

Cerințe nefuncționale
 Sistemul trebuie să aibă o interfață ușor de utilizat (Interfață)
 Cunoașteți obiectivele companiei
 Menține site-ul web (software)
 Analizați timpul de încărcare a paginilor principale (performanță)
 Utilizați o bază de date care deține informațiile introduse (software)

CERINȚE FUNCȚIONALE
Nume Bază de date
Tip Cerinţă
Prioritate înalt
Descriere De fiecare dată când se creează un cont nou cu datele
fiecărui utilizator, acesta trebuie să fie stocat în baza de date
(fie în unitatea de stocare a PC-ului, fie în server)
Intrare Datele introduse de utilizator
Proces Salvați datele utilizatorului
Plecări Registrul de date
Tabelul 1: Cerințe funcționale - Baza de date

Nume Interfață de înregistrare a datelor

Tip Cerinţă
 Prioritate înalt
Descriere Sistemul va avea o interfață prietenoasă și intuitivă, astfel
încât utilizatorul să poată completa cu ușurință datele de
înregistrare.
Intrare Informații despre utilizator
Proces interfata de inregistrare
Plecări date înregistrate
Tabelul 2: Cerințe funcționale - Interfață de înregistrare a datelor

Nume sistem adaptabil

Tip Cerinţă
Prioritate înalt
Descriere Sistemul trebuie să aibă capacitatea de a se adapta oricărui
dispozitiv (calculatoare, telefoane mobile, tablete).
Intrare manager de continut
Proces Adaptare la dispozitivul gazdă
Plecări Utilizați managerul de conținut pe dispozitivul gazdă
Tabelul 3: Cerințe funcționale - Sistem adaptabil
Nume șablon de interfață
Tip Cerinţă
Prioritate înalt
Descriere Sistemul va avea un șablon, care permite utilizatorului să facă
modificări și să le adapteze după bunul plac.
Intrare șablon de sistem
Proces Model șablon de utilizator
Plecări Adaptarea șablonului la gustul utilizatorului
Tabelul 4: Cerințe funcționale - Șablon de interfață

Nume Compatibilitate browser

Tip Cerinţă
 Prioritate înalt
Descriere Sistemul trebuie să fie compatibil cu browserele de internet
actuale (Internet Explorer, Mozilla Firefox, Google Chrome).
Intrare manager de date
Proces Compatibilitate browser
Plecări Vizualizați în browser
Tabelul 5: Cerințe funcționale - Compatibilitate browser

CERINȚE NEFUNCȚIONALE

Nume atacuri de securitate

Tip Cerinţă
Prioritate înalt
Descriere Sistemul trebuie să fie capabil să prevină atacuri precum
injecția SQL, atacurile xss, Middleware, atacurile CSRF,
validarea formularelor.
Intrare Atacuri de injectare SQL, atacuri xss, Middleware, atacuri
CSRF, validare formular.
Proces detecta atacul
Plecări opri atacul
Tabelul 6: Cerințe nefuncționale - Atacuri de securitate

Nume operabilitate
Tip Cerinţă
Prioritate înalt
 Descriere Managerul de conținut trebuie să fie ușor de utilizat pentru
utilizatorii care nu au cunoștințe în dezvoltarea paginilor web
Intrare idee de site
Proces Proiectarea si configurarea paginii web de catre utilizator
Plecări Pagina web încheiată de utilizator
Tabelul 7: Cerințe nefuncționale - Operabilitate

Nume acces la cont

Tip Cerinţă
gPrioritate înalt
Descriere Accesul la conturi trebuie să se facă prin parole de cel puțin 6
cifre
Intrare Începutul secțiunii
Proces Solicitați codul de acces
Plecări Începeți secțiunea
Tabelul 8: Cerințe nefuncționale - Acces la conturi
Nume Vizualizare cu browsere
Tip Cerinţă
Prioritate înalt
Descriere Sistemul trebuie să fie vizibil în browserele actuale (Internet
Explorer, Mozilla Firefox, Google Chrome).
Intrare Proiect web în derulare
Proces Adaptare la browser
Plecări Vedeți proiectul curent
Tabelul 9: Cerințe nefuncționale - Vizualizare cu browsere
Nume Ora afișată
Tip Cerinţă
Prioritate Jumătate
Descriere Sistemul nu ar trebui să dureze mai mult de 6 secunde pentru
a afișa conținutul modificat în managerul de conținut.
 Intrare proiect site-ul web
Proces modifica conținutul
Plecări Modificări efectuate în managerul de conținut
Tabelul 10: Cerințe nefuncționale - Ora de afișare
Nume utilizabilitate
Tip Cerinţă
Prioritate înalt
Descriere Sistemul trebuie să prezinte mesaje de eroare care să
permită utilizatorului să identifice tipul de eroare
Intrare Problemă prezentată utilizatorului undeva în proiect.
Proces analiza problema
Plecări Determinați ce fel de problemă este și afișați pe ecran
Tabelul 11: Cerințe nefuncționale – Utilizabilitate
Nume Limitarea șablonului
Tip Cerinţă
Prioritate Jumătate
Descriere Sistemul va avea doar un șablon de bază care poate fi
modificat de utilizator
Intrare șablon de bază
Proces Modificați șablonul de bază al managerului de conținut
Plecări Șablon modificat pentru a se potrivi utilizatorului
Tabelul 12: Cerințe nefuncționale - Limitarea șabloanelor

Cerințe funcționale și nefuncționale, exemple și sfaturi

Dezvoltarea software este una dintre acele activități în care avem nume și categorii pentru orice. Și
mă refer la tot. Uneori, asta este redundant și inutil, dar uneori există concepte care sunt foarte bune
de cunoscut și de diferențiat. Un exemplu în acest sens este diferența dintre cerințele funcționale
(RF) și nefuncționale (RNF). Și deoarece cerințele de sistem software sunt clasificate (printre altele)
în acest fel, următoarele tehnici ar trebui luate în considerare pentru o identificare adecvată.
Cerințe funcționale

Cerințele funcționale sunt declarații ale serviciilor pe care sistemul le va furniza, în modul în care va
reacționa la anumite intrări. Când vorbim despre intrări, nu vorbim neapărat doar despre intrările
utilizatorilor. Pot fi interacțiuni cu alte sisteme, răspunsuri automate, procese predefinite. În unele
cazuri, cerințele funcționale ale sistemelor precizează, de asemenea, în mod explicit ceea ce sistemul
nu trebuie să facă. Este important să rețineți acest lucru: un RF poate fi și o declarație negativă.
Atâta timp cât rezultatul comportamentului său este un răspuns funcțional la utilizator sau la alt
sistem, acesta este corect. Și în plus, nu este doar corect, dar este necesar să îl definim. Și asta ne
duce la următorul punct.

Multe dintre problemele din ingineria software (vorbind despre procesul de dezvoltare în sine) încep
cu specificații inexacte ale cerințelor. Este firesc ca un analist de afaceri (sau oricine definește și
documentează cerințele de sistem) să ia unele ipoteze drept cunoștințe universale sau să ia un
comportament de la sine înțeles. Dar amintiți-vă, este și firesc ca un dezvoltator de sistem să
interpreteze o cerință ambiguă în cel mai simplu mod posibil, pentru a simplifica implementarea
acesteia. Un exemplu clar al acestor probleme poate fi găsit în funcțiile comune legate de Experiența
utilizatorului:
 Povestea utilizatorului: Ca utilizator, vreau ca aplicația să fie ușor de utilizat, astfel încât să nu
fiu nevoit să petrec mult timp învățând cum să o folosesc.
 Ce înseamnă să fii „ușor de utilizat”?
 Ușor pentru cine?
 Cum a fost măsurat?
 Cum îl urmărești?
 Cum este testat? Pe ce criterii?
Acesta nu este ceva împotriva dezvoltatorilor, ci mai degrabă împotriva comportamentului uman.
Dacă presupui ceva, alții pot presupune ceva diferit și e în regulă. Dar analistul este responsabil
pentru documentare, așa că ar trebui să fie același analist care încearcă să se asigure că nu există
lacune în înțelegere sau pete gri. Acesta este și motivul pentru care sesiunile de Pre-Planificare și
Prezentarea poveștii sunt foarte importante pentru a vă asigura că întreaga echipă este pe aceeași
pagină în ceea ce privește cerințele, obiectivul dvs. de afaceri și cum să le implementați. Revenind la
exemplul anterior, am putea împărți cerințele în mai multe altele noi, care sunt mai ușor de înțeles,
dezvoltat, testat, urmărit și livrat. Una dintre ele ar putea fi:
 Povestea utilizatorului: Ca utilizator, vreau să fie afișat un tutorial la prima conectare, astfel
încât să pot vedea pentru ce este folosită fiecare opțiune de ecran de pornire.
 Știi ce să arăți, un tutorial.
 Știți deja ce să verificați, ceea ce explică fiecare opțiune de pe ecranul de start.
 Știți când trebuie afișat, la prima conectare a utilizatorului (puteți explica mai târziu dacă
tutorialul poate fi sărit, afișat alteori, accesat dintr-o secțiune din meniu etc.)
Revenind la FR, în principiu, specificarea cerințelor funcționale ale unui sistem trebuie să fie
completă și consecventă. Complet înseamnă că toate serviciile solicitate de utilizator și/sau alt
sistem sunt definite. Consecvența înseamnă că cerințele nu au o definiție contradictorie.
cerințe nefuncționale

Acestea sunt cerințe care nu se referă direct la funcțiile specifice furnizate de sistem (caracteristicile
utilizatorului), ci la proprietățile sistemului: performanță, securitate, disponibilitate. Cu cuvinte mai
simple, ei nu vorbesc despre „ce” face sistemul, ci despre „cum” o face. Alternativ, ele definesc
constrângerile sistemului, cum ar fi capacitatea dispozitivelor de intrare/ieșire și reprezentarea
datelor utilizate în interfața sistemului.
Cerințele nefuncționale provin din nevoia utilizatorului, din cauza restricțiilor bugetare, politicilor
organizaționale, nevoii de interoperabilitate cu alte sisteme software sau hardware sau factori
externi precum reglementările de securitate, politicile de confidențialitate, printre altele.

Există diferite tipuri de cerințe și sunt clasificate în funcție de implicațiile lor.

 Cerințe de produs. Acestea specifică comportamentul produsului, cum ar fi cerințele de
performanță pentru cât de repede poate rula sistemul și cantitatea de memorie necesară,
cerințele de fiabilitate care stabilesc rata de eșec pentru ca sistemul să fie acceptabilă, cerințele
de portabilitate și cerințele de securitate.
 Cerințe organizaționale. Acestea sunt derivate din politicile și procedurile existente în
organizația client și în organizația dezvoltatorului: standarde în procesele care urmează să fie
utilizate; cerințe de implementare, cum ar fi limbaje de programare sau metoda de proiectare
care trebuie utilizată; și cerințele de livrare care specifică momentul în care produsul și
documentația acestuia vor fi livrate.
 Nevoi externe. Ele derivă din factori externi sistemului și procesului de dezvoltare a acestuia.
Acestea includ cerințe de interoperabilitate care definesc modul în care sistemul interacționează
cu alte sisteme din organizație; cerințele legale care trebuie respectate pentru a se asigura că
sistemul funcționează în limitele legii; și cerințe etice. Acestea din urmă sunt impuse sistemului
pentru a se asigura că acesta va fi acceptat de utilizator.

Uneori, în practică, specificarea cantitativă a acestor tipuri de cerințe este dificilă. Nu este
întotdeauna posibil ca clienții să-și transpună obiectivele în cerințe cantitative. Pentru unele dintre
ele, cum ar fi întreținerea, este posibil să nu fie posibilă utilizarea vreunei valori; costul verificării
obiective a cerinţelor cantitative nefuncţionale poate fi foarte mare. Și de aceea este, de asemenea,
foarte important să fii foarte atent atunci când le documentezi. Un analist poate folosi sprijinul
echipei de dezvoltare și al echipei de testare pentru a defini criterii măsurabile pentru a ști când o
cerință poate fi marcată cu succes ca „Efectuat”.
Așa cum vorbim despre cerințe funcționale, generalizarea nu este niciodată bună, dar în acest caz
este și mai importantă. Deoarece? Deoarece rezultatul dezvoltării cerințelor nefuncționale poate să
nu fie explicit pentru utilizatorul final.
 Exemplu prost de RNF: sistemul trebuie să fie sigur.
 Cât de sigur este „sigur”?
 In ce situatii?
 Există un standard de urmat?
 În ce secțiuni?
 Ce ar trebui să se întâmple dacă sistemul nu poate funcționa la fel de repede cum este necesar?

În aceste cazuri, implementarea unei cerințe nefuncționale prost definite poate fi problematică,
costisitoare și consumatoare de timp. Tot pentru că de cele mai multe ori, un RNF nu este ceva la
care echipa lucrează izolat într-o perioadă fixă de timp. RNF poate fi abordat pe tot parcursul
proiectului (și chiar înainte de începerea sau după livrare, în faza de întreținere). Din nou, exemplul
de mai sus ar putea fi împărțit în mai multe cerințe care sunt mai ușor de urmărit și implementat.
 Exemplu RNF bun: Toate comunicațiile externe dintre serverele de date, aplicația și clientul de
sistem trebuie să fie criptate folosind algoritmul RSA.
 Știți ce fel de comunicații trebuie criptate.
 Știți ce algoritm să utilizați și să validați.

Cerințele funcționale și nefuncționale ar trebui să fie diferențiate în documentul de cerințe,

indiferent dacă este un SRS, un portofoliu de produse sau orice artefact pe care îl utilizați. În
practică, acest lucru poate fi dificil. Dacă o cerință nefuncțională este declarată separat de cerințele
funcționale, uneori este dificil de văzut relația dintre ele. Dacă RNF-urile sunt declarate cu cerințe
funcționale, este dificil să se separe condițiile funcționale de cele nefuncționale și să se identifice
cerințele care se referă la sistemul în ansamblu. Trebuie găsit un echilibru adecvat în funcție de tipul
de sistem sau aplicație specificată. De exemplu, dacă lucrați cu un Product Backlog, puteți avea
Povestiri utilizator separate pentru RNF-uri, dar adăugați un link către acestea în RF-uri care ar
putea fi afectate de acestea. Aceasta este o opțiune comună în majoritatea sistemelor de urmărire a
biletelor utilizate astăzi.

În orice caz, atât RF-urile cât și RNF-urile trebuie să fie întotdeauna documentate, chiar dacă este
dificil de stabilit relația dintre ele în artefacte. Acest lucru va ajuta echipa să reducă discuțiile dus-
întors, să economisească timp și, mai ales, probleme inutile cu clientul.

Cerințe funcționale: Exemple

Cerințele funcționale ale unui sistem sunt cele care descriu orice activitate pe care trebuie să o
desfășoare, cu alte cuvinte, comportamentul sau funcția particulară a unui sistem sau software
atunci când sunt îndeplinite anumite condiții.

De obicei, acestea ar trebui să includă funcții efectuate de anumite ecrane, descrieri ale fluxurilor
de lucru care urmează să fie efectuate de sistem și alte cerințe de afaceri, de conformitate, de
securitate sau alte cerințe.
În acest articol, vă prezentăm exemple de cerințe funcționale, legate de funcțiile business, date
care trebuie introduse pe ecranele sistemului (interfață grafică), cele legate de controlul accesului
sau emiterea de rapoarte solicitate de entitățile de reglementare, printre altele.

PMOInformatica prezintă: 40 Exemple de cerințe funcționale ale unui sistem.

Cum sunt descrise și clasificate cerințele funcționale

Cerințele funcționale ale software-ului sunt de obicei înregistrate în matricea de trasabilitate a
cerințelor și în specificația cerințelor software , aceasta din urmă documentează operațiunile și
activitățile pe care sistemul trebuie să le poată efectua.
Posibilele cerințe funcționale ale unui sistem includ:
 Descrieri ale datelor care urmează să fie introduse în sistem.
 Descrieri ale operațiunilor care trebuie efectuate de fiecare ecran.
 Descrierea fluxurilor de lucru efectuate de sistem.
 Descrierea rapoartelor de sistem și a altor rezultate.
 Definiția cine poate introduce date în sistem.
 Cum se va conforma sistemul cu sectorul aplicabil sau cu regulile și reglementările
generale.

Ca și alte tipuri de cerințe software, cum ar fi cerințele nefuncționale , cerințele funcționale pot fi
clasificate în funcție de scopul lor, cum ar fi cerințele de afaceri, cerințele care provin din aspecte
de reglementare și securitate, printre altele.

Mai jos prezentăm exemplele de cerințe funcționale , clasificate pe diferite domenii:

Exemple de cerințe funcționale ale procesului sau domeniului de afaceri
 Sistemul va trimite un e-mail atunci când se înregistrează oricare dintre următoarele
tranzacții: comandă de vânzare a clientului, expedierea mărfurilor către client, emiterea facturii
către client și înregistrarea plății clientului.
 Se va permite înregistrarea comenzilor de cumpărare cu date obligatorii incomplete, care
pot fi completate ulterior prin modificarea comenzii. Înainte ca detaliile comenzii să poată fi
aprobate, acestea trebuie să fie complete.
 La aprobarea unei comenzi, cererea va trece la pasul următor al fluxului de lucru de
aprobare (flux de lucru) configurat în sistem.
 Sistemul va permite utilizatorilor autorizați să introducă planuri și programe de proiect .
 Sistemul vă va permite să aprobați, să modificați sau să actualizați planurile și graficele de
proiect .
 Sistemul va permite trimiterea automată a scrisorilor de livrare a comenzilor direct la
depozit.
 Fiecărei comenzi i se va atribui un identificator unic, care va fi folosit pentru a o identifica în
toate procesele ulterioare efectuate asupra acesteia.
 La introducerea comenzilor de livrare, orice comandă de livrare va fi asociată cu o comandă
de vânzare.
 Facturarea comenzilor de vânzare se va efectua în loturi, printr-un ecran de comenzi de
facturare în așteptare, care va afișa comenzile nefacturate. Odată facturate comenzile nu vor fi
afișate în această listă.
 Sistemul va permite, de asemenea, înregistrarea facturilor manuale neasociate comenzilor,
însă acestea vor necesita autorizarea grupului de Manageri înainte de a fi postate.
 Procesul de cumpărare în sistem va acoperi următorii pași și tranzacții: Introducerea cererii,
emiterea cererii de ofertă și emiterea comenzii de cumpărare.
 Elementele cererii de ofertă vor fi aceleași cu cele ale rechiziției asociate, precum și cu cele
ale comenzii de cumpărare. Sistemul va permite emiterea cererilor de cotatie si a comenzilor
partiale de achizitie.
 Înregistrarea facturilor de vânzări și a tranzacțiilor cu facturi de cumpărare poate fi
configurată pentru a fi efectuată automat în evidența dumneavoastră, sau manual în loturi (Proces
de lot).
 Software-ul trebuie să fie capabil să emită următoarele situații financiare: Bilanț, Situația
profitului și pierderii, Situația fluxurilor de numerar. În plus, trebuie să poată emite o listă de registru
general și registru analitic.
 Comenzile de achiziție care depășesc sumele stabilite în fluxul de eliberare a comenzilor
configurat trebuie să treacă prin aprobările stabilite în fluxul de aprobare menționat.

Exemple de cerințe funcționale ale interfeței grafice

 Soluția va valida automat clientul asociat unei comenzi cu sistemul de gestionare a

contactelor.
 Câmpul sumă acceptă numai valori numerice cu două zecimale.
 Câmpul pentru data tranzacției acceptă numai date anterioare zilei de astăzi (ziua curentă).
 Câmpul de nume acceptă numai caractere alfabetice.
 Câmpul de adresă acceptă caractere alfabetice, numerice și speciale.
 Câmpul de țară va consta dintr-o listă de preselecție. Țara asociată cu o adresă trebuie să
fie înregistrată în prealabil în sistem.
 Câmpul de stat, provincie sau departament va consta dintr-o listă de preselecție.
Utilizatorilor li se vor prezenta numai statele asociate cu țara selectată anterior. Departamentul sau
provincia de selectat trebuie să fie înregistrată în funcționalitatea corespunzătoare.
 Câmpul material articol din ecranul de solicitare de achiziție va fi o listă de preselecție, care
va afișa numai materialele înregistrate în masterul de materiale.
 Câmpul pentru data înregistrării acceptă numai date care corespund perioadelor de
înregistrare deschise în sistem.
 Ecranul de înregistrare a plății poate imprima datele de pe ecran către imprimantă.
 Vor fi afișate numele, dimensiunea totală, spațiul disponibil și formatul unui pen drive sau
flash drive conectat la portul USB al computerului.
Exemple de cerințe funcționale legale sau de reglementare

 Sistemul va controla accesul și îl va permite numai utilizatorilor autorizați.

 Baza de date va fi implementată cu piste de audit.
 Foile de calcul vor securiza datele folosind semnături electronice.
 Sistemul va permite întocmirea și emiterea raportului de reglementare XX, conform
cerințelor stabilite în reglementări și legislația aplicabilă.
 Carnetele de vânzare-cumpărare vor fi emise în formatul stabilit de organele fiscale ale
materiei respective.

Exemple de cerințe de securitate

Sistemul va controla accesul și îl va permite numai utilizatorilor autorizați. Utilizatorii trebuie să se

conecteze la sistem cu un nume de utilizator și o parolă.
 Sistemul va trimite o alertă administratorului de sistem atunci când are loc oricare dintre
următoarele evenimente: Înregistrarea unui cont nou, autentificarea clientului, 2 sau mai multe
încercări eșuate de introducere a parolei utilizatorului și schimbarea parolei utilizatorului.
 Membrii grupului de utilizatori analiști pot introduce cereri, dar nu le pot aproba sau șterge.
 Membrii grupului de utilizatori manageri pot introduce și aproba solicitări, dar nu le pot
șterge.
 Membrii grupului de utilizatori administratori nu pot introduce sau aproba cereri, dar le pot
șterge.
 Orice schimb de date prin Internet efectuat de software va fi realizat prin protocolul https
criptat.

Exemple de cerințe de interfață externă (hardware și software)

 Software-ul poate fi utilizat pe sistemele de operare Windows, Linux și OSX.
 Aplicația ar trebui să poată fi utilizată fără a fi nevoie să instalați niciun alt software
suplimentar decât un browser web.
 Aplicația trebuie să fie utilizabilă cu browserele web Chrome, Firefox și Internet Explorer.

Despre cerințele funcționale

Cerințele funcționale trebuie scrise în așa fel încât cititorul să poată înțelege funcționarea
sistemului fără a avea cunoștințe tehnice speciale despre funcționarea acestuia.
Important este să definiți o modalitate standard de exprimare a cerințelor și să fie consecventă cu
aceasta în toate documentele.
La fel, cerințele funcționale nu trebuie neapărat definite sub formă de narațiuni scrise, ci pot fi
folosite și diagrame sau fluxuri de proces, care sunt incluse în specificația funcțională a software-
ului sau a sistemului de dezvoltat.
Pentru a identifica și documenta cerințele funcționale ale software-ului, sunt urmați doi pași, în
primul rând, sunt aplicate tehnici de colectare a cerințelor , cum ar fi observarea, interviurile,
observația, printre altele.

Rezultatul colectării cerințelor este documentat în documentul cu cerințele software. Vă împărtășim

un șablon mai jos:
> Documentul privind cerințele software

După sondaj, se aplică tehnici de analiză a cerințelor pentru a revizui informațiile obținute în
sondaj și a pregăti specificația funcțională, unele dintre aceste tehnici sunt descompunerea
funcțională, modelarea proceselor, cazurile de utilizare și altele.
Referințe

Erikson, U. Cerințe funcționale versus nefuncționale. Postat în ReqTest.

Erikson, U. Diferența dintre cerințele funcționale și nefuncționale. . Postat în ReqTest.

Ofni Systems. Cerințe funcționale

ReqView. Exemple de documentație

Cerințe nefuncționale: Exemple

Prezentăm partea a treia a seriei privind cerințele nefuncționale, cu câteva exemple care pot servi
drept ghid în definirea acestora.

Cerințele nefuncționale reprezintă caracteristici generale și restricții ale aplicației sau sistemului
care se dezvoltă.

Ele prezintă de obicei dificultăți în definirea lor, dat fiind că conformitatea sau neconformitatea lor
ar putea face obiectul unei interpretări libere, pentru care este recomandabil să se însoțească
definiția lor cu criterii de acceptare care pot fi măsurate.

Printre exemplele de cerințe nefuncționale prezentate, le avem pe cele care se referă la atribute
precum eficiența, securitatea, fiabilitatea și capacitatea de utilizare a sistemului. De asemenea,
prezentăm exemple de cerințe organizaționale și externe nefuncționale.
Care sunt cerințele nefuncționale și cum sunt ele clasificate?

Dacă căutați mai multe informații despre conceptul de cerințe nefuncționale, vă recomandăm prima
parte a acestei serii Cerințe non-funcționale: de ce sunt importante

La un prim nivel, cerințele nefuncționale pot fi clasificate în cerințe de produs, organizaționale și

externe, așa cum vă arătăm în articolul despre clasificarea cerințelor nefuncționale .

La un al doilea nivel, cerințele de produs pot fi clasificate în cerințe de utilizare, eficiență, fiabilitate
și securitate. La rândul lor, cerințele organizaționale pot fi clasificate în cerințe de mediu,
organizaționale și de dezvoltare. De asemenea, cerințele externe pot fi clasificate în cerințe de
reglementare, etice și legislative.

Când sunt efectuate fazele de colectare și analiză a cerințelor, cerințele nefuncționale pot fi
înregistrate într-un document de cerințe software. Aici împărtășim un șablon:

Câteva exemple de cerințe nefuncționale

După cum arătăm în articolul despre clasificarea cerințelor nefuncționale , la un prim nivel
acestea pot fi clasificate în cerințe de produs, organizaționale și externe.

La un al doilea nivel, cerințele de produs pot fi clasificate în cerințe de utilizare, eficiență, fiabilitate
și securitate. La rândul lor, cerințele organizaționale pot fi clasificate în cerințe de mediu,
organizaționale și de dezvoltare. De asemenea, cerințele externe pot fi clasificate în cerințe de
reglementare, etice și legislative.

Mai jos vă prezentăm exemple de cerințe nefuncționale, clasificate pe aceste zone diferite.

Exemple de cerințe de produs nefuncționale

Eficienţă

 Sistemul trebuie să poată procesa N tranzacții pe secundă. Acest lucru va fi măsurat cu

ajutorul instrumentului SoapUI aplicat la Testarea Software a serviciilor web .
 Toate funcționalitățile sistemului și tranzacțiile comerciale trebuie să răspundă utilizatorului
în mai puțin de 5 secunde.
 Sistemul trebuie să fie capabil să funcționeze în mod adecvat cu până la 100.000 de
utilizatori cu sesiuni simultane.
 Datele modificate din baza de date ar trebui să fie actualizate pentru toți utilizatorii care
accesează în mai puțin de 2 secunde.

Securitatea logică și a datelor

Permisiunile de acces la sistem pot fi modificate numai de administratorul de acces la date.
 Noul sistem trebuie dezvoltat aplicând modele și recomandări de programare care
sporesc securitatea datelor .
 Toate sistemele trebuie să facă backup la fiecare 24 de ore. Backup-urile trebuie să fie
stocate într-o locație sigură, situată într-o clădire diferită de cea în care se află sistemul.
 Toate comunicațiile externe dintre serverele de date, aplicația și clientul de sistem trebuie să
fie criptate folosind algoritmul RSA.
 Dacă sunt identificate atacuri de securitate sau încălcări ale sistemului, sistemul nu va
continua să funcționeze până când nu va fi deblocat de către un administrator de securitate.

Securitate industrială

 Sistemul nu va continua să funcționeze dacă temperatura exterioară este mai mică de 4

grade Celsius.
 Sistemul nu va continua să funcționeze în caz de incendiu. (de exemplu. Un lift).

utilizabilitate

 Timpul de învățare al sistemului de către un utilizator ar trebui să fie mai mic de 4 ore.
 Rata erorilor comise de utilizator trebuie să fie mai mică de 1% din totalul tranzacțiilor
executate în sistem.
 Sistemul trebuie să aibă manuale de utilizare structurate corespunzător.
 Sistemul trebuie să furnizeze mesaje de eroare informative și destinate utilizatorului final.
 Sistemul trebuie să aibă un modul de ajutor online.
 Aplicația web trebuie să aibă un design „Responsive” pentru a garanta o vizualizare
adecvată pe mai multe computere personale, tablete și smartphone-uri.
 Sistemul trebuie să aibă interfețe grafice bine formate.

fiabilitatea

 Sistemul trebuie să fie disponibil 99,99% din timpul când un utilizator încearcă să îl
acceseze.
 Timpul de pornire sau repornire a sistemului nu poate fi mai mare de 5 minute.
 Rata timpului de defecțiune a sistemului nu poate fi mai mare de 0,5% din timpul total de
funcționare.
 Durata medie a defecțiunilor nu poate fi mai mare de 15 minute.
 Probabilitatea de defectare a sistemului nu poate fi mai mare de 0,05.

Alte exemple de cerințe de produs

 Sistemul va fi dezvoltat pentru platformele PC și Macintosh.

 Aplicația trebuie să fie compatibilă cu toate versiunile de Windows, începând cu Windows
95.
 Aplicația trebuie să consume mai puțin de 500 Mb de RAM.
 Aplicația nu poate ocupa mai mult de 2 GB de spațiu pe disc.
 Noua aplicație ar trebui să gestioneze fonturile alfabetului în engleză, limbi latine (spaniolă,
franceză, portugheză, italiană), arabă și chineză.
 Interfața cu utilizatorul va fi implementată pentru browserele web numai cu HTML5 și
JavaScript.

Exemple de cerințe organizaționale nefuncționale

 Procedura de dezvoltare software care trebuie utilizată trebuie să fie definită în mod explicit
(în manualele de procedură) și trebuie să respecte standardele ISO 9000.
 Metodologia de dezvoltare software va fi Behaviour Driven Development (BDD) susținută
de Cucumber .
 Sistemul trebuie dezvoltat folosind instrumentele CASE XYZ.
 Procesul de dezvoltare va fi gestionat prin intermediul unui anumit instrument web pentru
a gestiona procesul de dezvoltare software .
 Trebuie specificat un plan de recuperare în caz de dezastru pentru ca sistemul de dezvoltat.
 La fiecare două săptămâni ar trebui elaborate rapoarte de management care să arate efortul
investit în fiecare dintre componentele noului sistem.
 Testarea software-ului va fi gestionată cu un instrument de management al testării
software .
 Testele software vor fi executate folosind Selenium și Ruby ca instrument și limbaj de
scripting pentru automatizarea testării software.

Exemple de cerințe externe nefuncționale

 Sisteme de date medicale: Noul sistem și procedurile sale de întreținere a datelor trebuie să
respecte legile și reglementările privind protecția datelor medicale.
 Noul sistem va adera la regulile licențelor publice generale (GNU), adică va fi gratuit, open
source în care oricine poate schimba software-ul, fără brevete și fără garanții.
 Paginile web care urmează să fie dezvoltate trebuie să respecte legea privind egalitatea de
tratament pentru persoanele cu dizabilități.
 Sistemul nu va dezvălui operatorilor săi alte date personale ale clienților, altele decât
numele și numerele de referință.

Cerințe nefuncționale și cerințe funcționale

Cerințele nefuncționale sunt de obicei exprimate într-un mod general și fără a se referi la vreun
modul, tranzacție sau caracteristică a sistemului, altfel ar deveni cerințe funcționale .

De exemplu:

Sistemul trebuie să se asigure că datele sunt protejate împotriva accesului neautorizat.

Este recomandabil să însoțiți definițiile cerințelor nefuncționale cu criterii de acceptare care pot fi
măsurate.
Cerințele nefuncționale pot duce la rândul lor la cerințe funcționale, luând ca exemplu cele de mai
sus:

Sistemul va include o procedură de autorizare a utilizatorului, în care utilizatorii trebuie să se

identifice folosind un nume de utilizator și o parolă. Doar utilizatorii autorizați în acest fel vor putea
accesa datele sistemului.

Scrisă în acest fel, cerința devine funcțională.

Cu toate acestea, nu toate cerințele nefuncționale pot fi derivate în cerințe funcționale, așa că este
foarte important să se definească criteriile de acceptare.

Exemple de definire a cerințelor funcționale

> Cerințe funcționale ale unui sistem de vânzări

> Exemple de cerințe funcționale

10 tipuri de teste nefuncționale
Testele nefuncționale se concentrează pe validarea unui sistem sau a unei aplicații prin cerințele
sale nefuncționale , adică modul în care funcționează sistemul și nu prin comportamente
specifice.

Caracteristicile nefuncționale ale unui sistem sau aplicație sunt adesea cuantificate pe scări
diferite, cum ar fi timpii de răspuns la testele de performanță.

ISTQB afirmă că omiterea testelor nefuncționale poate duce la probleme de calitate potențial
catastrofale după producție, cu toate acestea, aceste tipuri de teste sunt costisitoare, astfel încât
riscurile ar trebui evaluate înainte de angajarea resurselor proiectului.

În acest articol vă prezentăm 10 tipuri de teste nefuncționale, în special teste de utilizare,

securitate, încărcare, stres, volum, configurație, performanță, scalabilitate, recuperare și
mentenanță.

10 tipuri de teste nefuncționale

Iată o listă nelimitată de 10 tipuri de teste nefuncționale pe care le puteți include în planul dvs. de
testare a software-ului .

1. - Teste de sarcină

Testarea de încărcare constă în simularea cererii pentru o aplicație software și măsurarea

rezultatului. Aceste teste sunt efectuate în condiții de cerere așteptată și, de asemenea, în condiții
de suprasarcină (vârfuri de cerere).
Rularea acestor teste necesită utilizarea unor instrumente de testare de simulare a sarcinii, cum
ar fi SoapUI .

Testele de încărcare ajută la identificarea capacității operaționale maxime a unei aplicații, precum
și la identificarea blocajelor și a cauzelor posibilei degradări a performanței.

Când sarcina de testare crește peste parametrii așteptați, aceste teste sunt cunoscute ca teste de
stres.

2. - Teste de stres

Sunt teste de sarcină care se efectuează cu solicitări mai mari decât capacitatea operațională,
frecvent până la atingerea punctului de rupere.

Acest tip de testare software este utilizat pentru a determina stabilitatea unui sistem sau a unei
aplicații, cu accent pe disponibilitate și tratarea erorilor atunci când se confruntă cu supraîncărcare.

În ceea ce privește testele de încărcare, sunt necesare instrumente care simulează cererea,
SoapUI este unul dintre aceste instrumente care permite simularea solicitărilor pentru serverele de
aplicații web.

Aici împărtășim un tutorial SopaUI .

Cu testele de stres puteți identifica punctele de rupere, limitele pentru utilizarea în siguranță a
aplicației, confirmați specificațiile de proiectare, identificați modalitățile în care sistemul eșuează,
printre alte aspecte.

3. - Teste de volum

Testarea volumului constă în validarea funcționării aplicației cu anumite volume de date.

De exemplu, dacă doriți să vedeți comportamentul unei aplicații cu o anumită dimensiune a bazei
de date, extindeți dimensiunea bazei de date la acei parametri și apoi efectuați interogări, procese
sau funcționalități ale aplicației, măsurându-i performanța.

Subiectul de testare nu se limitează la baze de date, poate fi folosit și de exemplu pentru a măsura
performanța unei interfețe atunci când fișierul de interfață (un fișier text, xml etc.) depășește o
anumită dimensiune.

Obiectivul este de a vedea dacă, având în vedere anumite volume de date, aplicația funcționează
normal, care sunt limitele maxime de volume de date pentru operare și de a identifica condițiile de
defecțiune.

4. - Teste de configurare
Mai degrabă decât testarea performanței unei aplicații din perspectiva încărcării, testele de
configurare sunt folosite pentru a valida ce efecte au anumite modificări de configurare asupra
performanței.

Un exemplu tipic al acestei situații este experimentarea cu diferite metode de echilibrare a sarcinii
și observarea răspunsului aplicației la niveluri similare de suprasarcină.

Un alt exemplu este verificarea dacă sistemul este capabil să funcționeze corect în diferite versiuni
sau configurații ale mediilor hardware și software, cum ar fi diverse browsere de internet, versiuni
de browser, printre altele.

5. - Teste de utilizare

În testele de utilizare, testerii de software se concentrează pe validarea cât de ușor de utilizat

este o anumită aplicație.

Caracteristicile evaluate în utilizare includ:

Ușurință de învățare: cât de ușor este pentru utilizatori să îndeplinească funcțiile de bază prima
dată când folosesc aplicația.
 Eficiență: cât de repede își pot îndeplini sarcinile utilizatorii cu experiență.
 Memorare: Cât de ușor este să memorezi utilizarea aplicației, adică atunci când un
utilizator trece mult timp fără să folosească aplicația, își poate aminti suficient pentru a o utiliza
eficient data viitoare sau trebuie să înceapă să învețe din nou.
 Erori: câte erori de proiectare face utilizatorul, cât de grave sunt acestea și cât de ușor este
să vă recuperați.
 Satisfacție: cât de mult îi place (sau nu îi place) utilizatorului să folosească sistemul.

6. - Teste de securitate

Constă în testarea atributelor sau caracteristicilor de securitate ale sistemului, dacă este un sistem
securizat sau nu, dacă poate fi încălcat, dacă există control acces prin conturi de utilizator, dacă
aceste accesări pot fi încălcate.

Testele de securitate servesc, de asemenea, pentru a valida dacă echipa de dezvoltare software a
respectat practicile de securitate recomandate în programarea sa .

Printre caracteristicile de securitate ale unui sistem se numără confidențialitatea, integritatea,

autentificarea, autorizarea și disponibilitatea.

7. - Teste de rezistenta

Testarea de anduranță implică supunerea unui sistem sau aplicație la o anumită sarcină pentru o
perioadă de timp, pentru a determina modul în care funcționează după o utilizare prelungită.
Un sistem informatic se poate comporta normal în primele ore, cu toate acestea, după un timp,
probleme precum scurgerile de memorie cauzează adesea defecțiuni.

Aceste defecte în dezvoltarea software-ului nu pot fi identificate în cadrul testării funcționale

normale, așa că este adecvat să se implice testarea rezistenței între tipurile de testare software .

8. - Teste de scalabilitate

Testele de scalabilitate constau în verificarea capacității unei aplicații de a scala oricare dintre
caracteristicile sale nefuncționale, cum ar fi încărcarea pe care o suportă, numărul de tranzacții,
volumele de date, printre altele.

La proiectarea cazurilor de testare de scalabilitate , se recomandă să le luați în considerare în

blocuri incrementale, având în vedere dificultatea de a prezice sarcina reală pe care o va avea o
aplicație după ce va fi implementată în producție.
Testarea în blocuri incrementale înseamnă, de exemplu, mai întâi testarea cu niveluri de cerere
scăzute, apoi creșterea la niveluri de cerere medii și, în final, testarea cu niveluri de sarcină
ridicate. În acest fel puteți determina că scala și aplicația și problemele care încep să apară la
diferite niveluri.

Pentru ca rezultatele să fie de încredere, mediile de testare și setările acestora trebuie menținute
constante.

9. - Teste de recuperare

Testarea de recuperare este efectuată pentru a verifica cât de repede și cât de bine se
recuperează o aplicație după ce se confruntă cu o defecțiune hardware sau software.

Prin urmare, efectuarea testelor de recuperare necesită forțarea eșecului și apoi verificarea dacă
recuperarea are loc corect.

De exemplu, atunci când o aplicație funcționează, deconectați cablul de rețea sau, într-o aplicație
mobilă, întrerupeți conexiunea cu rețeaua Wi-Fi sau cu operatorul, apoi restabiliți conexiunea.

10. - Teste de menţinere

Ele constau practic în evaluarea cât de ușor este să întreținem un sistem sau o aplicație. Aceasta
înseamnă cât de ușor este să analizați, să schimbați și să testați aceste modificări.

Pentru realizarea acestui test trebuie evaluat modul în care este implementată aplicația, urmând
bune practici de inginerie software. Adică, sunt respectate modelele recomandate de inginerie
software și că nu sunt introduse din greșeală anti-modele, adică nu sunt făcute erori comune de
programare .
Somerville împarte cerințele nefuncționale în trei tipuri mari: cerințe de produs, cerințe
organizaționale și cerințe externe.

Cerințe nefuncționale ale produsului

De obicei se referă la limite sau restricții ale comportamentului sistemului, motiv pentru care
stabilește limite și restricții asupra a ceea ce pot face designerii (arhitecții software) și inginerii
software.

Unele dintre aceste cerințe pot fi ușor de cuantificat, cum ar fi performanța și fiabilitatea, dar altele
sunt mai dificile, cum ar fi capacitatea de utilizare și adaptabilitatea.

Cerințele produsului pot fi clasificate în (Sommerville):

 Cerințe de utilizare: Utilizabilitatea este definită ca efortul pe care un utilizator trebuie să îl

facă pentru a învăța, utiliza, introduce date și interpreta rezultatele obținute din software-ul
aplicației. În ultima vreme, gradul de utilizare a devenit foarte important, mai ales odată cu cererea
de dezvoltare a software-ului pentru dispozitive mobile și tablete .

 Cerințe de eficiență: legate de performanță în ceea ce privește timpul de răspuns, numărul

de operații pe secundă, printre alte măsurători, precum și consumul de memorie, procesor, spațiu
pe disc sau resurse de rețea.

Un instrument util pentru a verifica eficiența unui sistem este SoapUI, care permite teste de
încărcare sau de stres pe servicii web. Aici împărtășim articole pe acest subiect:

 Cerințe de fiabilitate: cuprinde mai multe atribute

o Disponibilitate: Disponibilitatea sistemului de a furniza serviciul corect.
o Fiabilitate: Continuitatea serviciului furnizat de sistem.
o Siguranța industrială: Absența consecințelor catastrofale pentru utilizator sau
mediu.
o Integritate: Absența modificărilor necorespunzătoare ale sistemului.
o Mentenabilitatea: Posibilitatea de a face modificări sau reparații la un proces fără a
afecta continuitatea serviciului.

 Cerințe de securitate: Capabilități funcționale sau nefuncționale pe care un sistem trebuie

să le aibă pentru a îndeplini atribute în domeniul securității tehnologiei informației, securitatea
datelor, securitatea logică, controlul accesului la informații (restricții de acces), autenticitatea
informațiilor, confidențialitatea, printre alte aspecte.

Luarea în considerare a cerințelor produsului este vitală pentru a realiza integrarea continuă a
aplicațiilor și dezvoltarea unor schimbări rapide, dar durabile în timp.

Această nouă paradigmă este necesară pentru a implementa noi tehnologii informaționale și
aplicații software, cum ar fi mobilitatea, Internetul obiectelor, analiza avansată a datelor (Big
Data), evoluția sistemelor către cloud și tehnologia informației scalabilă.
Cerințe organizaționale nefuncționale

Acestea sunt derivate din politicile și procedurile organizației, cum ar fi standardele de proces sau
cerințele de implementare.

Acestea pot include metodologii de dezvoltare software, standarde de programare (codificare) și

instrumente de suport pentru dezvoltarea software (de exemplu, instrumente CASE) care trebuie
utilizate (urmând politicile organizației), de asemenea rapoarte către conducere care trebuie
furnizate, printre altele.

Instrumentele de management al dezvoltării software pe care le cunoaștem sunt definite ca

cerințe organizaționale nefuncționale.
Cerințele organizaționale pot fi clasificate în (Sommerville):

 Cerințe de mediu: Descrieți mediul de operare în care trebuie dezvoltat sistemul.

 Cerințe operaționale: Proceduri de operare care descriu modul în care sistemul va fi
utilizat în contextul organizației.
 Cerințe de dezvoltare: limbaj de programare de utilizat, standarde de codare, modele de
proiectare și programare (și anti-modeluri) , instrumente pentru gestionarea dezvoltării
software, mediu de dezvoltare software (mediu de dezvoltare), mediu de testare software (teste de
mediu), printre alte aspecte.

Unul dintre aspectele care sunt documentate ca cerințe funcționale organizaționale sunt mediul,
în special procedurile de întreținere și administrare a mediului de dezvoltare software .

Această administrare include, de asemenea , proceduri pentru gestionarea mediilor de testare

end-to-end .

Cerințe externe nefuncționale

Acestea derivă din mediul organizațional (nu mediul tehnic) în care este dezvoltat sistemul și se
pot face atât pe produs (software-ul dezvoltat), cât și pe procesul de dezvoltare software.

Aceste tipuri de cerințe includ limitări de natură economică, interacțiune sau necesitate ca sistemul
să interoperați cu alte sisteme, cerințe de reglementare în domeniul sănătății, siguranței industriale
sau protecției datelor, cerințe legale privind licențele, reglementările sau certificările necesare de
produs în funcție de industria în care lucrează, printre altele.

Somerville, la rândul său, clasifică aceste cerințe ca:

Cerințe de reglementare: Legile și reglementările care stabilesc ce trebuie să facă sistemul și

cum trebuie să le facă pentru a le respecta. Obiectivul unui sistem sau al unei noi funcționalități
poate fi exclusiv conformarea unui regulament.
 Cerințe etice: cerințe care asigură că sistemul va fi acceptabil pentru utilizator, publicul larg
și se adaptează la obiceiurile societății în care operează sau căreia îi furnizează servicii.
 Cerințe legislative: Caracteristici pe care sistemul trebuie să le îndeplinească pentru a se
conforma legii, de exemplu în domeniul contabilității (reglementări contabile și standarde
financiare), cerințe de securitate industrială (pentru sisteme critice), printre alte aspecte.

Importanța clasificării cerințelor nefuncționale

Specificarea cerințelor nefuncționale într-un mod incomplet sau inexact poate duce la eșecul
proiectului dumneavoastră de inginerie software.

De fapt, negestionarea cerințelor nefuncționale este una dintre greșelile clasice de management
al dezvoltării software definite de Steve McConnell .
A fi capabil să clasifice corect fiecare cerință nefuncțională identificată este foarte important pentru
a garanta acest proces.

https://www.youtube.com/user/codigofacilito
https://www.youtube.com/channel/UC4CEqh4d3-6RcyyJxhFCMGg
https://marvelapp.com/ .