in-theory.info

Cerinţele nefuncţionale


Una dintre greşelile cele mai frecvente în specificaţiile software este tratarea superficială a cerinţelor nefuncţionale.
Acestea pot fi cerinţe legate de atributele de calitate a produsului, cerinţe privind performanţa, respectarea unor standarde, regulamente, contracte, interfeţe externe sau alte constrângeri de design.


Am întâlnit cu câţiva ani în urmă un caz, zic eu, relevant. Aplicaţia era o aplicaţie pe web, destul de obişnuită de altfel, cu cerinţe privind performanţa destul de normale, chiar modeste.
Din păcate, specificaţia dădea drept cerinţă încărcarea a sute de pagini simultan, lucru greu de realizat cu un server obişnuit (la asemenea cerinţe, de altfel inutile, nu răspund nici site-urile mari de pe Internet). Nu e cazul să mai spun că deşi cerinţa fusese propusă de către echipa de dezvoltare nu de către client, în încercarea de a o rezolva s-a pierdut timp, pentru ca în final, dificultăţile ridicate de o asemenea ţintă să conducă la rediscutarea şi "renegocierea" cu clientul a cerinţei respective.
Tratarea cu superficialitate a cerinţelor privind performanţa a condus, iată, la imposibilitatea respectării specificaţiei.

În afara faptului că situaţia a fost destul de jenantă, cerându-i-se clientului să renegocieze ceva ce echipa de dezvoltate propusese şi scrisese, de bună voie şi nesilită de nimeni, în specificaţie, au fost implicate şi costuri total nejustificate.


Determinarea cerinţelor nefuncţionale trebuie să urmeze un proces sănătos, de la determinarea lor şi până la specificare.

În primul rând, determinarea acestor cerinţe este un lucru dificil, pentru că, în general utilizatorii nu sunt interesaţi, şi nici puşi în temă, în legătură cu costurile cerinţelor lor şi au tendinţa să exagereze: "sistemul trebuie să lucreze 24 de ore din 24", "timpul de răspuns?... păi sistemul trebuie să răspundă instantaneu la orice comandă", "nu se admite nici un bug în funcţionarea sistemului".

În realitate nu este deloc important, nici măcar util, să se arunce banii pe obţinerea unor caracteristici care, de fapt, sunt excepţionale, ale produselor software. Şi asta pentru că nu toate aplicaţiile software sunt folosite pentru ghidarea navetelor spaţiale sau pentru controlul centralelor nucleare.

Dimpotrivă, am văzut cu toţii site-uri de succes care nu răspund chiar instantaneu la solicitări, sau aplicaţii de calcul tabelar, extrem de utile şi practice dealtfel, care nu pot gestiona fără pierderi de performanţă cantităţi foarte mari de date.
Prin urmare, ceea ce trebuie neapărat identificat sunt cerinţele cu adevărat importante, specifice business-ului respectiv, care pot produce pierderi sau dificultăţi reale. De pildă, în unele cazuri, ar putea fi necesară disponibilitatea sistemului 24 de ore din 24 pentru facturare, chiar dacă sunt acceptabile unele deprecieri ale timpului de răspuns în anumite intervale orare. În fiecare caz în parte există un raport optim între performanţe şi costuri.


Cerinţele nefuncţionale includ cerinţele de calitate precum:
- cerinţele de performanţă (viteza de răspuns, disponibilitatea sistemului, timpul de recuperare în caz de indisponibilitate temporară a sistemului, utilizarea resurselor);
- siguranţa în funcţionare (frecvenţa avariilor, uşurinţa recuperării);
- suportabilitatea (posibilităţile de adaptare, posibilităţile de extindere, configurabilitatea, compatibilitatea cu alte sisteme, localizare);
- cerinţe de implementare (standarde, legislaţie aplicabilă, politici de securitate, limitări de resurse);
- uşurinţa în utilizare (consistenţa interfeţei utilizator, standarde de ergonomie aplicabile, documentaţie, help);
- constrângeri de design;
- cerinţe de interfaţare cu alte sisteme.

Adrian Ionescu





Colecția:  🏅 Analiza cerinţelor software

Articolul precedent:  Riscuri legate de cerinţe, partea a II-a
Articolul următor:  Caracteristicile cerinţelor software



👍 Topul celor mai citite articole

1. Analiza cerinţelor software. Introducere
Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, şefi de proiec...

2. Despre Analiza cerinţelor
Analiza cerinţelor software (pe care o vom numi în continuare Analiza de business sau Analiză software) este aceea dintre disciplinele existente î...

3. Axiomele dezvoltării software
Adevăruri ale dezvoltării software care susțin nevoia Analizei cerințelor. Unul dintre ele este: "Întotdeauna, într-un proiect software apar si...

4. Ciclul de dezvoltare al produsului software (SDLC)
Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chi...

5. Ciclul de dezvoltare iterativ
Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, ca...

6. Locul Analizei în proiectul de dezvoltare software
Analiza Software este o disciplină care se află în relaţie de dependenţă cu celelalte discipline din proiect. Concret, task-urile din proiectul ...

7. Modele teoretice de abordare a problemelor. Decompoziţia
Modalităţile teoretice de abordare a problemelor sunt universale şi pot fi folosite oriunde însă pentru domeniul nostru, este important să le co...

8. Modele teoretice de abordare a problemelor. Sinteza
Sinteza este o modalitate, prin care, din manifestări punctuale se determină problema reală. Cel mai simplu şi clar exemplu este acela al mediculu...

9. Modele teoretice de abordare a problemelor. Crearea unui trunchi de bază
De foarte multe ori, în viaţa reală, o problemă nu poate fi punctată decât cu un efort substanţial sau chiar deloc. Pur şi simplu, obţinerea ...

10. Modele teoretice de abordare a problemelor. Abordarea iterativă
Metoda iterativă presupune rezolvarea unei probleme cunoscute printr-o abordare iterativă, la fiecare iteraţie făcând un pas către rezolvarea pr...



📜 Căutare după etichetă:

Analiza Business
Baze de date
C#
Cerințe software
CSS
Dictionar IT
Glossary
HTML
Information Theory
Information Theory Basics
MySQL
PHP
Riscuri
SDLC
Specificații software
SQL
UML