dezvoltare de Software poate fi un proces interesant de rezolvare a problemelor creative, proiectare și inginerie. Dar sub aplicațiile strălucitoare și paginile web lustruite se află schela mai puțin sexy, dar atât de importantă, care face posibile rezultate bune ale software-ului: documentația.

documentația asigură că echipele și părțile interesate individuale sunt pe aceeași pagină în ceea ce privește obiectivele, domeniul de aplicare, constrângerile și cerințele funcționale ale unui produs sau ale unei aplicații software.din păcate, procesul de creare și Documentare a acestor cerințe poate fi obositor, confuz și dezordonat.

documentele cerințelor Software pot deveni rapid documente lungi, greoaie, grele de text, făcându-le deosebit de vulnerabile la erori, inconsecvențe și interpretări greșite. Din această cauză, scrierea și utilizarea acestor documente pot necesita mult timp și pot duce la erori de proiectare costisitoare (și evitabile).

deci, ce ar trebui să facă managerii de produse, echipele de software și liderii de afaceri?

deși nu există o regulă unică pentru abordările de dezvoltare software, există modalități de a reduce erorile, de a economisi timp și de a genera rezultate eficiente.

mai jos vom trece prin obiectivele și beneficiile documentelor de cerințe software și câteva bune practici care vă vor ajuta să unghii procesul de la început până la sfârșit.

ce sunt documentele cerințelor software?

un document de cerințe software (denumit și specificații de cerințe software) este un document sau un set de documentație care prezintă caracteristicile și comportamentul intenționat al unei aplicații software.

cu alte cuvinte, documentul de cerințe software (SRD) descrie înțelegerea de către COMPANIE sau organizație a nevoilor și dependențelor utilizatorului final (de obicei ale CLIENTULUI), precum și orice constrângeri asupra sistemului.

ce este inclus într-un SRD?

în timp ce SRD funcționează ca un plan pentru gestionarea domeniului de aplicare al unui proiect, în cele din urmă definește doar cerințele funcționale și nefuncționale pentru un sistem. Documentul nu prezintă soluții de proiectare sau tehnologie. Aceste decizii sunt luate ulterior de dezvoltatori.

un SRD bine scris ar trebui:

• să împartă problema în părți gestionabile.
• servesc ca referință pentru testare și validare.
• informează specificațiile de proiectare (de exemplu, documentul de referință sectorial trebuie să includă suficiente informații cu privire la cerințele software-ului pentru a face o proiectare eficientă).
• oferiți feedback Clientului (Utilizatorului final).SRD demonstrează clientului că organizația dvs. înțelege problema pe care doresc să o rezolve și cum să abordeze aceste probleme prin soluții software. Deoarece clienții sunt adesea părți interesate directe, este deosebit de important să se elaboreze documentația în mod clar în termeni laici (evitând jargonul tehnic).

  Din nou, modul în care scrieți SRD-ul dvs. va depinde de abordarea și metodologia la care se abonează echipa sau organizația dvs. Cu toate acestea, organizația de standarde IEEE recomandă SRD tipice ar trebui să acopere următoarele subiecte:

  • interfețe
  • capabilități funcționale
  • niveluri de performanță
  • structuri de date/elemente
  • siguranță
  • fiabilitate
  • securitate/confidențialitate
  • calitate
  • constrângeri și limitări

  dacă fiecare dintre aceste subiecte este abordată în mod clar și prezentate în documentația, veți avea o imagine mai completă a informațiilor necesare pentru a vă dezvolta aplicația.

  cum să fixați documentul cu cerințele software

  indiferent de abordarea pe care o luați în ceea ce privește documentația, urmați aceste bune practici pentru a crea un SRD eficient și eficient.

  păstrați-l organizat

  numele jocului este organizarea. Înainte de a începe documentarea efectivă, asigurați-vă că începeți cu o strategie de organizare pentru toate documentele, inclusiv unde sunt stocate documentele dvs., cum să asigurați coerența și modul în care colaboratorii și colaboratorii pot păstra cu ușurință documentele actualizate. Pentru a fi eficient, un document de cerințe software ar trebui să fie organizat și clar. Multe organizații se bazează pe șabloane de casă pentru a menține coerența între proiecte. Șabloanele sunt o modalitate excelentă de a economisi timp (trebuie doar să completați secțiunile pre-organizate) și să rămâneți consecvent în procesul de documentare.

  cu toate acestea, șabloanele de documente întăresc adesea problema cerințelor lungi, pline de text. Pentru a evita să vă împotmoliți în paginile de text, luați în considerare completarea procesului de documentare cu date vizuale.

  

  asigurați-vă că cerințele sunt complete

  pentru ca o cerință să fie „completă”, ar trebui să includă toate informațiile necesare pentru implementarea cerinței. Aceasta înseamnă că atunci când designerii și dezvoltatorii merg să construiască funcția, nu sunt lăsați să facă presupuneri sau presupuneri cu privire la cerință.

  de exemplu, să presupunem că dezvoltați o pagină web. Una dintre cerințele prezentate este ceea ce ar trebui să se întâmple în caz de eroare. O cerință incompletă ar putea spune ceva de genul „în caz de eroare, sistemul ar trebui să iasă fără probleme.”

  în acest caz, „lin” nu este definit și este lăsat la latitudinea interpretării. Această ambiguitate ar putea duce la o interpretare greșită a rezultatelor dorite (și mai multă muncă pentru a reveni și a o remedia).

  pentru a evita acest lucru, scrieți o cerință completă care definește cum arată o funcție de succes:

  „în caz de eroare, sistemul trebuie să afișeze o pagină de eroare cu următorul mesaj:

  Uh-oh! Se pare că ceva a mers prost. Vă rugăm să încercați din nou în câteva minute. Dacă problema persistă, contactați echipa noastră de asistență la [email protected]. ”

  prin definirea unei cerințe complete, există mai puțină ambiguitate și un rezultat clar pentru ca echipa de dezvoltare să lucreze.

  asigurați cerințele testabile

  acesta este un standard destul de omniprezent, dar prea des organizațiile nu reușesc să scrie cerințe care îndeplinesc pe deplin această regulă.

  cerințele trebuie să fie verificabile. În caz contrar, nu există o modalitate obiectivă de a ști dacă cerința a fost implementată în mod satisfăcător.

  pentru fiecare cerință pe care o scrieți, asigurați-vă că este validată prin unul sau mai multe dintre următoarele moduri:

  • inspecție
  • demonstrație
  • Walk-through
  • testare

  cerințele de nivel înalt sunt adesea supuse inspecției sau testării utilizatorului, astfel încât acestea se bazează de obicei pe specificații mai generale. Dar cerințele de nivel inferior care sunt supuse testării software vor avea nevoie probabil de specificații mai detaliate.

  aplicați cerințe funcționale neutre în implementare

  după cum am menționat mai devreme, un SRD nu este un document de proiectare. Nu definește și nu ar trebui să definească modul în care cerințele funcționale trebuie implementate din punct de vedere al proiectării.

  prin urmare, toate cerințele funcționale ar trebui să fie neutre din punct de vedere al implementării. Cu alte cuvinte, cerințele ar trebui să precizeze ce ar trebui să facă sistemul, dar nu cum ar trebui să o facă.

  există mai multe avantaje pentru cerințele neutre de implementare, inclusiv:

  • un proces de proiectare mai eficient
  • cerințe modificabile care nu depind de un design specific de implementare
  • mai puțin conflict între cerințele rezultate din detaliile de implementare opuse

  orice constrângeri privind implementarea ar trebui rezervate cerințelor nefuncționale ale sistemului.

  evaluați documentația cu părțile interesate

  când toate cerințele software au fost documentate, solicitați tuturor părților interesate relevante să evalueze documentația finală înainte de începerea dezvoltării.părțile interesate ar trebui să includă designeri și dezvoltatori, testeri care vor valida cerințele, ingineri, reprezentanți ai utilizatorilor finali și clientul.

  punând toate părțile interesate să revizuiască și să aprobe documentația înainte de a începe dezvoltarea, îmbunătățiți satisfacția în cadrul echipelor și creșteți probabilitatea ca cerințele să răspundă nevoilor lor.

  ajutați dezvoltatorii de software și echipele lor să rămână pe aceeași pagină cu diagrame care trasează eficient și elegant specificațiile cerințelor software. Căutați o soluție de diagramă care vă poate ajuta:

  • Organizați-vă cerințele într-o diagramă de flux pentru a vă menține componentele distincte, dependențele clare și părțile interesate aparente.
  • folosiți înotătoare pentru a descrie vizual care Echipe sunt responsabile pentru fiecare set de cerințe.
  • modifica rapid cerințele sau alte date ca nevoile proiectului evolua.
  • Link date (inclusiv documente suplimentare) pentru a sprijini și informa proiectul în curs de desfășurare.
  • partajați documentația (și orice modificări) instantaneu cu părțile interesate relevante.

  documentația nu trebuie să fie o corvoadă. Cu Lucidchart, puteți documenta cu ușurință procesele, poveștile utilizatorilor și cerințele software într-o singură locație. Prin definirea vizuală a specificațiilor cerințelor dvs., dvs. și echipa dvs. veți putea găsi și acționa rapid asupra informațiilor, reducând în același timp oportunitățile de erori, inconsecvențe și interpretări greșite.

  

  începeți documentarea

  obțineți vizibilitate în sistemele tehnice existente cu Lucidchart astăzi.

  Aflați cum