AxiobyteVisit Website →
← Back to blog

Cum se scrie o specificație de proiect software completă

August 28, 2026
Cum se scrie o specificație de proiect software completă

O specificație de proiect software, cunoscută și ca FRS (Functional Requirements Specification), este documentul care definește precis ce face sistemul și cum trebuie să se comporte. Minimal, trebuie să conțină cinci elemente: context și scop, cerințe funcționale, cerințe non‑funcționale, criterii de acceptare și resurse necesare, plus un istoric al reviziilor. Ghidul ANIS recomandă exact această structură pentru documentația de achiziție software, adaptabilă și în mediul privat.

Pe scurt:

  • O greșeală frecventă este formularea vagă a cerințelor non‑funcționale, ceea ce le face dificil de verificat și costisitor de ajustat ulterior.
  • Lipsa unei matrice de trasabilitate poate duce la pierderea legăturii între cerințe, funcționalități și teste, complicând gestionarea proiectului.
  • Actualizarea și validarea specificației cu toate părțile interesate înainte de începerea dezvoltării reduce riscul de conflicte și modificări costisitoare.
  • În proiecte complexe, toate capitolele și diagramele vizuale sunt esențiale pentru claritatea și trasabilitatea cerințelor.
  • Evitați formulările generale precum „sistemul trebuie să fie rapid și sigur”, deoarece acestea nu pot fi testate sau măsurate precis.

Cuprins

Cine folosește specificația de proiect software și când se scrie

O specificație bine făcută nu e un document birocratic pus la dosar, ci un instrument de lucru pe care mai multe roluri îl consultă zilnic. Momentul redactării ei nu e fix, la începutul proiectului, ci se întinde pe mai multe etape: o primă versiune apare după discuțiile inițiale cu clientul, urmată de revizii pe măsură ce echipa tehnică identifică ambiguități sau constrângeri noi.

Stakeholderii tipici implicați în procesul de specificare sunt:

  • Analistul de business (BA) transformă cerințele vagi ale clientului în formulări clare, testabile.
  • Project managerul urmărește impactul fiecărei cerințe asupra bugetului și termenului de livrare.
  • Dezvoltatorii validează fezabilitatea tehnică și semnalează riscurile de implementare.
  • Clientul sau product ownerul aprobă versiunea finală și prioritizează funcționalitățile.
  • Testerul QA derivă din specificație scenariile de testare și criteriile de acceptare.

Documentul rămâne conectat la alte livrabile ale proiectului, care nu îl înlocuiesc, ci îl completează: caietul de sarcini (pentru licitații sau contracte formale), backlogul de dezvoltare (pentru echipele agile) și prototipurile de interfață (pentru validarea vizuală înainte de codare). Actualizările specificației se fac la fiecare schimbare majoră de scop, nu ad hoc, altfel documentul își pierde utilitatea ca sursă unică de adevăr.

Cerințe funcționale versus non‑funcționale: reguli de redactare și exemple

Cerințele funcționale descriu ce face sistemul: acțiuni concrete, declanșate de un utilizator sau de un eveniment. O cerință funcțională bine scrisă are un titlu scurt, o descriere la persoana a treia și criterii de acceptare verificabile. De exemplu: „Sistemul permite resetarea parolei prin email” nu e suficient; varianta completă adaugă: „utilizatorul primește linkul în maximum 60 de secunde, linkul expiră după 30 de minute, iar parola nouă trebuie să respecte minimum 8 caractere cu o cifră și un caracter special”.

Cerințele non‑funcționale descriu calitatea comportamentului sistemului, nu funcția lui, și sunt frecvent tratate superficial. Cele mai importante categorii:

  • Performanță: timpul de răspuns maxim acceptat pentru o cerere (de exemplu, sub 2 secunde pentru 95% din request‑uri).
  • Securitate: cerințe de criptare, autentificare multi‑factor, gestionarea sesiunilor.
  • Confidențialitate: reguli de stocare și acces la datele personale, alinate la GDPR.
  • Testabilitate: fiecare cerință trebuie formulată astfel încât să poată fi verificată printr‑un test clar, nu printr‑o interpretare subiectivă.
  • Disponibilitate: procentul de uptime garantat (de exemplu, 99,5% lunar) și planul de recuperare în caz de incident.

Sfat profesional: Formulați fiecare cerință non‑funcțională cu o cifră atașată. „Sistemul trebuie să fie rapid” nu poate fi testat; „timpul de încărcare al paginii principale nu trebuie să depășească 2 secunde la o conexiune de 10 Mbps” poate.

Structura detaliată a unei specificații funcționale (FRS)

Un șablon de specificație funcțională urmează, de regulă, un cuprins standard pe care echipele îl adaptează în funcție de complexitatea proiectului. Iată cum se compune un FRS complet, capitol cu capitol:

  1. Introducere și context: descrie problema de business, obiectivele proiectului și publicul care va folosi sistemul.
  2. Definiții și glosar: clarifică termenii tehnici și acronimele folosite în restul documentului, esențial când în echipă sunt oameni din domenii diferite.
  3. Cerințe funcționale: enumeră actorii sistemului (roluri, tipuri de utilizatori) și descrie interacțiunile lor prin use cases sau user stories, în funcție de metodologia aleasă.
  4. Cerințe non‑funcționale: performanță, securitate, confidențialitate, scalabilitate, compatibilitate cu dispozitive și browsere.
  5. Criterii de acceptare: condițiile exacte în care o funcționalitate se consideră finalizată și livrabilă.
  6. Resurse necesare: echipa, tehnologiile, integrările cu sisteme externe și bugetul estimat.
  7. Istoricul reviziilor: cine a modificat documentul, când și de ce, esențial pentru trasabilitate în proiecte lungi.

Fiecare secțiune funcțională trebuie completată cu artefacte vizuale: diagrame de flux, wireframe‑uri sau prototipuri interactive, pentru că un text descriptiv fără reprezentare vizuală generează interpretări diferite între dezvoltatori și client. Pentru un proiect mic, un document de câteva pagini cu secțiunile 1, 3, 5 și 6 poate fi suficient. Pentru un proiect complex, cu integrări multiple și cerințe de conformitate, toate cele șapte capitole devin obligatorii, iar diagramele UML pentru use cases nu mai sunt opționale.

Cum colectați și validați cerințele înainte de a scrie documentul

Definirea corectă a cerințelor reduce semnificativ riscul de neînțelegeri și de întârzieri pe parcursul proiectului, iar documentația bine structurată funcționează ca ghid de referință pe toată durata dezvoltării. Trei metode acoperă majoritatea situațiilor practice:

  • Interviurile individuale funcționează bine când stakeholderii au perspective diferite sau conflictuale, greu de aliniat într‑un grup.
  • Workshopurile de tip user story mapping aduc toți actorii relevanți în aceeași sală (sau apel video) și clarifică fluxurile principale înainte de a scrie o singură linie de cod.
  • Prototiparea rapidă transformă cerințele abstracte în ecrane pe care clientul le poate testa cu mouse‑ul, nu doar le imaginează, iar rolul prototipării în dezvoltarea de aplicații e documentat ca metodă eficientă de reducere a ambiguităților.

Organizarea unui atelier de prioritizare cere o agendă strictă: 15 minute de recapitulare a obiectivelor, 45 de minute de brainstorming pe funcționalități, 30 de minute de prioritizare (metoda MoSCoW funcționează bine aici) și 15 minute de sumarizare a deciziilor. Fiecare decizie luată în atelier trebuie notată în documentul de specificație, cu data și persoana responsabilă, altfel discuțiile se repetă la următoarea întâlnire.

Sfat profesional: Nu lăsați deciziile de prioritizare „în aer”. Notați‑le imediat în specificație, cu un motiv scurt, pentru că cea mai mare sursă de conflict într‑un proiect e „am zis eu altceva la telefon acum două luni”.

User stories vs use cases: când folosiți fiecare și cum se completează

Diferența dintre cele două formate nu e doar de stil, ci de scop. User stories se concentrează pe valoarea adusă utilizatorului, într‑un format scurt de tipul „ca [rol], vreau [acțiune], pentru a [beneficiu]”, și sunt potrivite dezvoltării iterative, cu cicluri scurte de livrare. Use cases descriu pas cu pas interacțiunea dintre un actor și sistem, inclusiv fluxurile alternative și cazurile de eroare, fiind alese atunci când logica de business e complexă sau există cerințe de conformitate care impun detaliere formală.

Metoda practică recomandată de literatura de specialitate combină cele două formate, nu le pune în competiție:

  • Scrieți întâi use case‑urile pentru viziunea de ansamblu a fiecărui flux major.
  • Spargeți fiecare use case în user stories mai mici, potrivite unui sprint.
  • Legați explicit fiecare user story de use case‑ul din care provine, pentru trasabilitate.

Cercetarea academică asupra integrării celor două metode descrie exact această procedură de „tăiere” a use case‑urilor în felii mai mici, utilă mai ales echipelor hibride, care combină rigoarea planificată cu ritmul agile.

Un use case pentru „plasarea unei comenzi online” poate fi spart în user stories separate: „ca utilizator, vreau să adaug un produs în coș”, „ca utilizator, vreau să introduc adresa de livrare” și „ca utilizator, vreau să confirm plata cu cardul”. Fiecare devine o sarcină distinctă în backlog, dar toate rămân legate de același use case părinte.

Documentația formală, cu use case‑uri complete și diagrame UML, devine necesară în proiecte reglementate (financiar, medical, achiziții publice). Pentru un produs digital obișnuit, user stories urmate de criterii de acceptare clare acoperă majoritatea nevoilor, fără birocrația unui use case complet pentru fiecare buton din interfață.

De la cerințe la teste: acceptare, UAT și trasabilitate

O cerință fără criteriu de acceptare e o promisiune vagă, nu o specificație. Un criteriu bine scris urmează format Given/When/Then: „Dat fiind că utilizatorul are cont activ, când introduce parola greșită de trei ori, atunci contul se blochează 15 minute și primește notificare pe email”. Trei pași transformă o listă de cerințe într‑un proces de validare solid:

  1. Scrieți criteriile de acceptare imediat după fiecare cerință, nu la final, ca să evitați formulări generice adăugate în grabă.
  2. Planificați testarea de acceptanță a utilizatorului (UAT) cu stakeholderii reali, nu doar cu echipa QA internă, pentru că percepția clientului asupra „funcționează corect” diferă frecvent de cea a dezvoltatorului.
  3. Construiți o matrice de trasabilitate care leagă fiecare cerință de user story‑ul sau use case‑ul din care provine, de codul care o implementează și de testul care o verifică.

Matricea de trasabilitate devine indispensabilă în proiecte cu peste 50 de cerințe, unde e ușor să pierzi șirul: fără ea, o schimbare târzie de scop poate lăsa cerințe orfane, netestate, sau teste care verifică o funcționalitate deja eliminată din produs.

Template‑uri și metoda Axiobyte pentru specificații aplicate

Un template de FRS bun nu e universal valabil, ci un punct de start pe care îl adaptați la mărimea proiectului. Pentru proiecte simple, păstrați secțiunile esențiale (context, cerințe funcționale, criterii de acceptare); pentru proiecte complexe, completați integral structura din capitolul anterior, inclusiv anexele cu diagrame.

Spațiu de lucru tehnic minimalist cu instrumente de scris și tabletă

La Axiobyte, procesul de lucru transformă specificația dintr‑un document static într‑un instrument viu, actualizat pe parcursul întregului proiect. Descrierea completă a acestui proces, de la primul brief la livrarea finală, e detaliată în pagina despre cum lucrăm. Rezultatele concrete ale acestei abordări pot fi verificate în portofoliul și studiile de caz ale agenției, unde specificațiile inițiale se pot compara direct cu produsul livrat. Pentru proiecte care implică și componente de identitate vizuală, integrarea cerințelor de design în FRS urmează logica descrisă în articolul despre strategia de brand versus identitatea vizuală.

Perspectiva Axiobyte: greșeli frecvente și recomandări finale

Cea mai frecventă greșeală pe care o vedem în specificațiile scrise în grabă e formularea vagă: „sistemul trebuie să fie rapid și sigur” nu ajută pe nimeni, pentru că nu poate fi testată. A doua greșeală e ignorarea cerințelor non‑funcționale până în ultima săptămână, când corectarea lor devine costisitoare. A treia: confundarea unui use case detaliat cu o user story, ceea ce duce la backloguri fie prea stufoase, fie prea sărace în context.

Perspectiva Axiobyte: greșeli frecvente și recomandări finale — overview diagram

A patra greșeală, subestimată des: lipsa unei matrice de trasabilitate, care face aproape impposibil de urmărit ce cerință a generat ce funcționalitate atunci când proiectul crește. A cincea: tratarea specificației ca document „bătut în cuie” de la început, când, de fapt, natura software‑ului cere adaptare continuă, nu rigiditate.

Recomandarea noastră practică: revizuiți specificația cu toate părțile interesate înainte de a considera dezvoltarea „pornită”, nu după. Un document validat de client, dezvoltatori și QA în aceeași ședință previne mai multe conflicte decât orice proces ulterior de gestionare a schimbărilor.

— Axiobyte

Surse

Recomandat