6 pași pentru scrierea unui document SRS care funcționează + șablon
documentele de specificații Software sunt uneori văzute ca artefacte care au sens doar pentru dezvoltatori. Cu toate acestea, un document SRS poate merge mai departe și poate deveni un ghid pentru specialiștii în marketing, părțile interesate, echipele de proiectare și chiar utilizatorii.
acest articol va explica de ce contează documentația software și cum să scrieți documentul SRS pentru a-l face un ghid practic pentru toți specialiștii echipei.
Ce este un document SRS și de ce contează?
un document SRS (software requirement specification) este un artefact care conține cerințele, așteptările și standardele pentru un produs viitor. Poate acoperi documente text, foi de calcul, scheme, precedente și alte elemente care clarifică viziunea produsului. Cu alte cuvinte, un document SRS oferă o descriere detaliată a modului în care ar trebui să funcționeze un produs și a modului în care echipa de dezvoltare a produsului ar trebui să îl implementeze.
Imaginați-vă cum ar fi construirea unei nave. Aveți o viziune a catargului sau a pânzei și vă puteți imagina chiar cum călătorește prin valuri. Cu toate acestea, aveți nevoie de detalii mai stricte pentru a pune nava pe apă.
același lucru este valabil și pentru dezvoltarea produsului. Puteți avea o viziune clară a unei aplicații pe care doriți să o construiți cu toate caracteristicile, elementele de design și butoanele. Cu toate acestea, o descriere verbală a caracteristicilor nu este suficientă pentru ca dezvoltatorii să implementeze ideea.
pentru ca rezultatul să se potrivească cu imaginea din cap, trebuie să explicați pe hârtie exact cum ar trebui să funcționeze o caracteristică. Un document SRS este un instrument excelent pentru descrierea unor astfel de detalii tehnice.
.jpg)
cine scrie un document SRS?
scrierea unui document SRS înseamnă transferul descrierilor generice ale caracteristicilor, sarcinilor și obiectivelor către planul detaliat al implementării lor tehnice.
documentele SRS sunt de obicei scrise de manageri de produs și de proiect sau analiști de afaceri, care comunică direct cu clienții sau care fac cercetări ale utilizatorilor (care lucrează și la wireframes și știu cum ar trebui să se comporte produsul) și adună cerințele produselor viitoare.
între timp, acest document. Un document SRS bun nu este doar tehnic, deoarece acoperă și obiectivele de afaceri, valorile, problemele utilizatorilor, persoanele utilizatorilor etc.
3 motive pentru care un document SRS este Important
deci, valoarea totală a unui document SRS este clară. Iată motivele pentru care documentele de specificație a cerințelor software sunt esențiale:
SRS este un punct de comunicare
ca document viu, un document SRS servește ca platformă de comunicare între toți specialiștii: Dezvoltatori, specialiști în marketing și cofondatori.
explicând detaliile într-un document SRS, formal sau informal, managerii sunt de acord cu clienții cu privire la așteptările rezultatelor. Între timp, dacă modificările sunt aduse cerințelor, un client și/sau un proprietar de produs le poate verifica și valida în document. Iar dezvoltatorii sunt responsabili pentru îndeplinirea acestor așteptări.
descrierea finală a caracteristicilor
SRS documentează versiunile finale ale software-ului care au provenit din ipotezele discutate anterior cu clienții. În timpul întâlnirilor și apelurilor, testelor utilizatorilor și interviurilor, versiunile produsului se pot schimba foarte des. Uneori, chiar și managerii de produse pot fi copleșiți de iterațiile existente ale produselor. Fișierul SRS ajută la unificarea tuturor acestor cerințe într-un singur standard și la eliminarea oricărei confuzii cu privire la cerințele produsului.
SRS este un ghid Standard pentru dezvoltatorii de produse
pe lângă descrierea cerințelor produsului, documentul SRS ghidează echipa de dezvoltare cu privire la pașii pe care trebuie să îi urmeze pentru a construi un produs pe care un client îl dorește.
în funcție de organizarea proiectului, dezvoltatorii pot sau nu pot fi implicați în partea analitică a proiectului. În ambele cazuri, trebuie să concluzioneze modul în care sistemul ar trebui să funcționeze, să definească cerințele și parametrii de cod pentru a se potrivi.
în mod similar, profesioniștii AC trebuie să înțeleagă toate aspectele tehnice care se află în spatele conceptului produsului. Astfel, documentația SRS servește ca standard pentru planificarea și rularea testelor QA.
în cele din urmă, proiectanții obțin informații despre proiect prin documente SRS pentru a se potrivi designului cu cazul de utilizare.
6 pași pentru scrierea unui document SRS bun
cerințele funcționale și nefuncționale iau o mare parte din orice document SRS. Managerii de produse nu iau pur și simplu aceste cerințe de nicăieri. Acestea sunt rezultatul unei comunicări exacte cu clienții și al unei cercetări aprofundate a utilizatorilor și a cercetării tehnice. Iată pașii principali de scriere a documentației SRS excelente:
Pasul 1. Comunicarea cu părțile interesate
eliminăm primul strat de incertitudine întrebând părțile interesate despre așteptările lor de la produs. Sigur, un astfel de interviu oferă doar o mică înțelegere a cerințelor. Cu toate acestea, acesta este încă un punct de plecare excelent pentru cercetare.
la Uptech vorbim în primul rând cu clientul la apelul de Pre-vânzare și de lansare atunci când încercăm să ne dăm seama dacă ne potrivim reciproc. Încercăm să cristalizăm cele mai mici detalii despre client pentru a-și înțelege ideea.
cu toate acestea, comunicarea simplă nu oferă suficiente informații despre publicul țintă al produsului și despre dorințele și nevoile acestuia. Așa că mergem mai departe cu etapa de descoperire pentru a clarifica.
Pasul 2. Etapa de descoperire
etapa de descoperire este critică în scrierea documentației SRS. În această etapă, avem ocazia să explorăm problema pe care produsul ar trebui să o rezolve, interesele și nevoile. Scopul nostru aici este de a identifica problemele utilizatorilor și de a defini ipoteze ale soluțiilor posibile pentru a le aborda. Cu o astfel de abordare, putem face aplicația valoroasă pentru utilizator.
cazuri de Utilizare vs povești de utilizator
toate datele de utilizator devine o parte a unui document SRS ca cazuri de Utilizare și povești de utilizator. Diferența dintre aceste două categorii este larg dezbătută în rândul comunității de dezvoltare a produselor.
mai simplu spus, poveștile utilizatorilor se concentrează mai mult pe rezultat și beneficiile pe care le obține un utilizator în timp ce folosește o caracteristică. În timp ce cazurile de utilizare descriu mai granular funcția în sine.
de exemplu, după mai multe interviuri cu utilizatorii la proiectul Yaza, am ajuns la concluzia că aplicația ar trebui să aibă un chat. Deci, povestea utilizatorului pentru un astfel de caz ar suna ca: „ca utilizator, vreau să discut cu un potențial proprietar de casă.”
între timp, Cazul de utilizare pentru această poveste ar descrie fiecare pas al unui utilizator pentru realizarea acestui obiectiv – „ca utilizator, trebuie să adaug un contact în lista mea de chat și să-i trimit un mesaj, astfel încât…”.
Pasul 3. Construiți structura
odată ce descoperirea este finalizată, continuăm să scriem documentația SRS. În primul rând, avem nevoie de o scurtă structură a documentului. Conținutul unui document SRS poate varia semnificativ, dar structura tipică a documentației SRS ar arăta astfel:
1. Introducere
introducerea prezintă un rezumat al conținutului documentului. Se presupune că răspunde la următoarele întrebări:
- scurtă descriere a conținutului documentului;
- cititorii intenționați ai acestui document;
- ideea software-ului pe care îl dezvoltați;
- cititorii intenționați.
1.1 obiective de afaceri
configurați o listă de obiective pe care doriți să le atingeți în cadrul proiectului, cum ar fi crearea unui MVP, crearea unei aplicații mobile multiplatform sau lansarea unui site web.
în plus, această secțiune ar trebui să reflecte obiectivele și valorile de succes ale afacerii dvs. Deși unii pot exclude această parte din document, este esențial să se indice aceste lucruri, deoarece acestea influențează direct cercetarea și dezvoltarea.
1.3 utilizare preconizată
cum vă imaginați că o persoană va folosi produsul dumneavoastră? Care sunt funcțiile pe care le furnizați pentru acest tip de utilizare? Descrieți toate modurile posibile în care o persoană poate utiliza produsul dvs. în orice rol de utilizator acționează.
1.4 domeniu de aplicare
această parte va descrie domeniul de activitate pe care trebuie să îl efectuați pentru a vă aduce ideea la viață.
1.5 definiții și acronime
acesta va stabili definițiile termenilor pe care îi utilizați în document pentru a asigura o înțelegere completă de către utilizatori.
2. Descriere generală
iată partea în care explicați ideea aplicației, de unde a venit și de ce poate fi interesantă pentru utilizatori.
2.1 nevoile utilizatorului
o bucată de software care este construit pentru toată lumea servește nimeni. Dar dacă știți exact cine este publicul dvs. țintă, unde lucrează și durerile lor, veți avea șanse mai mari de a oferi o aplicație adoptată pe scară largă de utilizatori.
3. Caracteristici de sistem și cerințe
acum este timpul pentru a sublinia cerințele tehnice ale software-ul viitor. Descrieți caracteristicile pe care le va include produsul dvs., împreună cu standardele care definesc calitatea acestor produse.
3.1 cerințe funcționale
cerințele funcționale sunt specificații de sistem, fără de care software-ul nu va funcționa corect. Definiția pe care o veți da caracteristicilor software-ului dvs. va determina modul în care acestea vor fi implementate în continuare.
3.2 Cerințe nefuncționale
în timp ce cerințele funcționale definesc care va fi funcția sistemului, cerințele nefuncționale determină modul în care sistemul va implementa aceste caracteristici, de exemplu, viteza de finalizare.
3.3 Tech Stack
un tech stack este un grup de soluții tehnice utilizate pentru a crea și rula software-ul sau un proiect. Este esențial să o indicați în documentul SRS, deoarece definește toate celelalte detalii tehnice.
.jpg)
Pasul 4. Faceți o descriere generală
înainte de a intra în detaliile produsului dvs., oferiți o prezentare generală a principalelor caracteristici ale aplicației. Pur și simplu explicați scopul aplicației, caracteristicile acesteia și modul în care acestea rezolvă problema utilizatorului.
Pasul 5. Definirea cerințelor funcționale și nefuncționale
nucleul documentului SRS va consta, de obicei, în cerințele funcționale și nefuncționale ale produsului. Cu astfel de specificații, adăugați mai multe detalii la prezentarea generală și, astfel, ghidați echipa prin specificul tehnic al aplicației dvs.
diferența dintre cerințele funcționale și cele nefuncționale este un alt punct important în comunitatea de dezvoltare a produselor. Am împărtășit expertiza noastră pe această temă în acest articol.
Pasul 6. Asigurați-vă că clientul de pe aceeași pagină
aprobarea este o parte mult așteptată a dezvoltării. Cu toate acestea, modificările clientului pot nega uneori întreaga cantitate de muncă, finalizată la un anumit moment al proiectului.
pentru a evita presiunea, vă recomandăm să acceptați părți mici ale documentației SRS completate, mai degrabă decât să trimiteți un întreg pachet de documente simultan. Acest lucru ajută la rezolvarea rapidă a anumitor probleme și este mai puțin supărător.
Sfaturi Expert pe scris documentație SRS mare
este nevoie de timp pentru a perfecționa abilitatea de a scrie o documentație SRS excelentă. Am tras o listă de sfaturi de experți cu privire la scrierea documentației SRS din experiența noastră. Deci, aici sunt câteva intuiții care va face documentația SRS eficiente:
faceți-o simplă
acesta nu este un secret, dar lucrurile simple guvernează lumea. Acest lucru este valabil pentru orice tip de documentație la care lucrați. SRS este o descriere unificată a viitorului produs pentru întreaga echipă. Aceasta înseamnă că limba, structura și formulările documentului SRS ar trebui să fie cât mai laconice posibil.
includ obiectivele de afaceri
deși un document SRS se concentrează în primul rând pe caracteristicile tehnologice, inclusiv obiectivele de afaceri este o bună practică. Un document SRS este o instrucțiune pentru echipa de dezvoltare și rezumatul produsului pentru specialiștii non-tehnologici legați de produs. Mai mult, includerea cerințelor de afaceri, cum ar fi valorile și scopurile, va face din SRS un instrument unificat pentru întreaga echipă.
Adăugați date de utilizator
etapa de descoperire dezvăluie de obicei cele mai valoroase informații despre un utilizator. Adăugarea acestor informații la documentul SRS îl va face o lucrare utilă pentru echipa de proiectare și dezvoltare.
tratați SRS ca pe un Document viu
documentul SRS nu trebuie să fie static, chiar dacă ați compilat toate pachetele necesare pentru proiectul dvs. În ecosistemele Agile, proiectele merg în jurul dobândirii de noi caracteristici cu fiecare iterație care trece. Toate aceste modificări și modificări trebuie transmise în documentul SRS și convenite cu clientul.
concluzie
scrierea documentelor SRS necesită cercetări, analize și eforturi profunde. Cu toate acestea, un document SRS cuprinzător care acoperă caracteristicile afacerii, detaliile tehnice și datele utilizatorilor va da roade cu un produs uimitor care satisface atât așteptările clienților, cât și ale utilizatorilor.
Uptech are cinci ani de experiență în construirea de produse pentru startup-uri înfloritoare. Știm cum să explorăm nevoile utilizatorului și să facem din SRS document un instrument eficient de gestionare a proiectelor, mai degrabă decât un teanc de hârtii acoperite de praf.
F. A. Q.
ce este SRS?
un SRS este un document care acoperă o descriere detaliată a specificațiilor și cerințelor tehnice ale unei aplicații sau ale unui software. Un SRS instruiește, de asemenea, dezvoltatorii cu privire la modul de implementare a ideii produsului pentru a se potrivi așteptărilor clientului.
care este scopul unui document SRS?
scopul unui document SRS este de a oferi descrierea tehnică a caracteristicilor unui produs, de a furniza cerințe tehnice și non-tehnice și de a ghida echipa de dezvoltare cu privire la implementare.
cine scrie documente SRS?
în funcție de componența echipei, documentele SRS sunt de obicei scrise de:
- Manager de produs;
- Manager de proiect;
- analist de afaceri;
- inginer tehnic.