timp de citire: 9 minute

cerințele clar definite sunt semne esențiale pe drumul care duce la un proiect de succes. Ei stabilesc un acord formal între un client și un furnizor că ambii lucrează pentru a atinge același obiectiv. Cerințele de înaltă calitate și detaliate ajută, de asemenea, la atenuarea riscurilor financiare și la menținerea proiectului într-un program., Conform corpului de analiză de afaceri al definiției cunoștințelor, cerințele reprezintă o reprezentare utilizabilă a unei nevoi.

crearea cerințelor este o sarcină complexă, deoarece include un set de procese, cum ar fi provocarea, analiza, specificarea, validarea și gestionarea. În acest articol, vom discuta principalele tipuri de cerințe pentru produsele software și vom oferi o serie de recomandări pentru utilizarea acestora.înainte de a discuta despre modul în care sunt create cerințele, să diferențiem tipurile acestora.,

cerințe la nivel Înalt în cascadă în jos pentru detalii specifice

cerințe de Afaceri. Acestea includ declarații la nivel înalt de obiective, obiective și nevoi.

cerințe ale părților interesate. Nevoile grupurilor discrete de părți interesate sunt, de asemenea, specificate pentru a defini ceea ce așteaptă de la o anumită soluție.

Cerințe de soluție. Cerințele soluției descriu caracteristicile pe care un produs trebuie să le aibă pentru a satisface nevoile părților interesate și ale afacerii în sine.,

• cerințele nefuncționale descriu caracteristicile generale ale unui sistem. Ele sunt, de asemenea, cunoscute sub numele de atribute de calitate.
• cerințele funcționale descriu modul în care un produs trebuie să se comporte, ce caracteristici și funcții.

Cerințe de tranziție. Un grup suplimentar de cerințe definește ceea ce este necesar de la o organizație pentru a trece cu succes de la starea actuală la starea dorită cu noul produs.

să explorăm cerințele funcționale și nefuncționale în detaliu.,

cerințe funcționale și specificațiile lor

cerințele funcționale sunt caracteristici ale produsului sau funcții pe care dezvoltatorii trebuie să le implementeze pentru a permite utilizatorilor să își îndeplinească sarcinile. Deci, este important să le clarificăm atât pentru echipa de dezvoltare, cât și pentru părțile interesate. În general, cerințele funcționale descriu comportamentul sistemului în condiții specifice. De exemplu:

o caracteristică de căutare permite unui utilizator să vâneze între diverse facturi dacă dorește să crediteze o factură emisă.iată un alt exemplu simplu: ca oaspete, vreau o canapea pe care să pot dormi peste noapte.,

cerințele sunt de obicei scrise în text, în special pentru proiectele bazate pe Agile. Cu toate acestea, ele pot fi, de asemenea, vizuale. Aici sunt cele mai comune și formate de documente:

• Software requirements specification document
• cazuri de Utilizare
• povești de Utilizator
• work Breakdown Structure (WBS) (descompunere funcțională)
• Prototipuri
• Modele și diagrame

Software requirements specification document

Funcționale și nefuncționale cerințe pot fi formalizate în caietul de sarcini cerințele (SRS) document., (Pentru a afla mai multe despre documentația software, citiți articolul nostru pe acest subiect.) SRS conține descrieri ale funcțiilor și capabilităților pe care produsul trebuie să le furnizeze. Documentul definește, de asemenea, constrângeri și ipoteze. SRS poate fi un singur document care comunică cerințele funcționale sau poate însoți alte documentații software, cum ar fi poveștile utilizatorilor și cazurile de utilizare.nu recomandăm să compuneți SRS pentru întreaga soluție înainte de lansarea dezvoltării, dar ar trebui să documentați cerințele pentru fiecare caracteristică înainte de a o construi., După ce primiți feedback-ul inițial al utilizatorului, puteți actualiza documentul.

SRS trebuie să includă următoarele secțiuni:

scop. Definiții, prezentare generală a sistemului și fundal.

descriere generală. Ipoteze, constrângeri, reguli de afaceri și viziune de produs.

Cerințe specifice. Atribute de sistem, Cerințe funcționale, cerințe de bază de date.

este esențial ca SRS să fie lizibil pentru toate părțile interesate. De asemenea, ar trebui să utilizați șabloane cu accent vizual pentru a structura informațiile și pentru a ajuta la înțelegerea acestora., Dacă aveți cerințe stocate în alte formate de documente, conectați-le la ele pentru a permite cititorilor să găsească informațiile necesare.exemplu: dacă doriți să vedeți un document real, descărcați acest exemplu SRS creat la Michigan State University, care include toate punctele menționate mai sus, pe lângă prezentarea cazurilor de utilizare pentru a ilustra părți ale produsului.cazurile de utilizare descriu interacțiunea dintre sistem și utilizatorii externi care duce la atingerea anumitor obiective.fiecare caz de utilizare include trei elemente principale: actori., Aceștia sunt utilizatorii din afara sistemului care interacționează cu sistemul.

sistem. Sistemul este descris prin cerințe funcționale care definesc un comportament intenționat al produsului.

obiective. Scopurile interacțiunii dintre utilizatori și sistem sunt prezentate ca obiective.există două formate pentru a reprezenta cazuri de utilizare:

• specificația cazului de Utilizare structurată în format textual
• diagrama cazului de Utilizare

o specificație a cazului de utilizare reprezintă secvența evenimentelor împreună cu alte informații care se referă la acest caz de utilizare., Un caz tipic de utilizare caietul de sarcini modelul include următoarele informații:

• Descriere
• Pre – și Post – interacțiunea condiție
• interacțiune de Bază cale
• cale Alternativă
• Excepție de cale

Exemplu:

caz de Utilizare caietul de sarcini template

Un caz de utilizare diagrama nu conțin o mulțime de detalii. Acesta prezintă o imagine de ansamblu la nivel înalt a relațiilor dintre actori, diferite cazuri de utilizare și sistem.

diagrama cazurilor de utilizare include următoarele elemente principale:

cazuri de Utilizare., De obicei, desenate cu ovale, cazurile de utilizare reprezintă diferite scenarii de utilizare pe care actorii le-ar putea avea cu sistemul (conectați-vă, faceți o achiziție, vizualizați articole etc.).)

limitele sistemului. Limitele sunt subliniate de caseta care grupează diferite cazuri de utilizare într-un sistem.

actori. Acestea sunt cifrele care descriu utilizatorii externi (persoane sau sisteme) care interacționează cu sistemul.

asociații. Asociațiile sunt desenate cu linii care arată diferite tipuri de relații între actori și cazuri de utilizare.,

Exemplu:

caz de Utilizare diagrama de exemplu,

povești de Utilizator

O poveste de utilizare este o descriere documentată de o funcție a software-ului văzut de vedere al utilizatorului final. Povestea utilizatorului descrie exact ce dorește utilizatorul să facă sistemul. În proiectele Agile, poveștile utilizatorilor sunt organizate într-un jurnal, care este o listă ordonată a funcțiilor produsului. În prezent, poveștile utilizatorilor sunt considerate a fi cel mai bun format pentru elementele restante.,

Un utilizator tipic de poveste este scris ca aceasta:

<tip de utilizator>, Vreau <un scop> astfel încât <motiv>.ca administrator, vreau să adaug descrieri la produse, astfel încât utilizatorii să poată vizualiza ulterior aceste descrieri și să compare produsele.poveștile utilizatorilor trebuie să fie însoțite de criterii de acceptare., Acestea sunt condițiile pe care produsul trebuie să le îndeplinească pentru a fi acceptate de un utilizator, de părțile interesate sau de un proprietar de produs. Fiecare poveste de utilizator trebuie să aibă cel puțin un criteriu de acceptare. Criteriile eficiente de acceptare trebuie să fie testabile, concise și complet înțelese de toți membrii echipei și de părțile interesate. Ele pot fi scrise ca liste de verificare, text simplu, sau prin utilizarea dat/când/apoi format.

exemplu:

Iată un exemplu de listă de verificare a criteriilor de acceptare pentru o poveste de utilizator care descrie o caracteristică de căutare:

• un câmp de căutare este disponibil în bara de sus.,
• o căutare este pornită atunci când utilizatorul face clic pe Trimitere.
• substituentul implicit este un text gri Tip numele.
• substituentul dispare atunci când utilizatorul începe să tasteze.
• limba de căutare este engleza.
• utilizatorul nu poate introduce mai mult de 200 de simboluri.
• nu acceptă simboluri speciale. Dacă utilizatorul a introdus un simbol special în intrarea de căutare, acesta afișează masajul de avertizare: intrarea de căutare nu poate conține simboluri speciale.,în cele din urmă, toate poveștile utilizatorilor trebuie să se potrivească modelului de calitate INVEST:
  • I – Independent
  • N – negociabil
  • V – valoros
  • E – Estimabil
  • S – mic
  • T – testabil

  Independent. Aceasta înseamnă că puteți programa și implementa fiecare poveste de utilizator separat. Acest lucru este foarte util dacă implementați procese de integrare continuă.

  negociabil. Aceasta înseamnă că toate părțile sunt de acord să acorde prioritate negocierilor asupra specificației. Acest lucru înseamnă, de asemenea, că detaliile vor fi create constant în timpul dezvoltării.

  valoros., O poveste trebuie să fie valoroasă pentru client. Ar trebui să vă întrebați din perspectiva clientului „de ce” trebuie să implementați o anumită caracteristică.

  Estimabil. O poveste de utilizator de calitate poate fi estimată. Acest lucru va ajuta un program de echipă și va acorda prioritate implementării. Cu cât este mai mare povestea, cu atât este mai greu să o estimezi.

  mic. Poveștile bune ale utilizatorilor tind să fie suficient de mici pentru a planifica lansări scurte de producție. Poveștile mici permit estimări mai specifice.

  testabil. Dacă o poveste poate fi testată, este suficient de clară și suficient de bună., Poveștile testate înseamnă că cerințele sunt făcute și gata de utilizare.

  descompunere funcțională sau structuri de descompunere a muncii (WBS)

  o descompunere funcțională sau WBS este un document vizual care ilustrează modul în care procesele complexe se descompun în componentele lor mai simple. WBS este o abordare eficientă pentru a permite o analiză independentă a fiecărei părți. WBS ajută, de asemenea, captura imaginea completă a proiectului.vă sugerăm următoarea logică a descompunerii funcționale:

  1. găsiți cea mai generală funcție.
  2. găsiți cea mai apropiată funcție sub.,
  3. Găsiți următorul nivel de sub funcție.
  4. verificați diagrama.

  Sau procesul de descompunere poate arata astfel:

  Nivel Ridicat Funcție ->Sub-funcție -> Procesul -> Activitate

  caracteristici ar trebui să fie descompus în punctul în care nivelul cel mai de jos părți nu pot fi descompuse mai departe.,

  Exemplu:

  

  Un exemplu de o descompunere funcțională

  Software prototipuri

  Software prototip este un termen generic pentru diferite forme de stadiu incipient rezultate care sunt construite pentru a prezenta modul în care cerințele nu trebuie să fie puse în aplicare. Prototipurile ajută la eliminarea lacunelor de viziune și permit părților interesate și echipelor să clarifice domenii complicate de produse în dezvoltare. În mod tradițional, prototipurile reprezintă modul în care soluția va funcționa și oferă exemple despre modul în care utilizatorii vor interacționa cu aceasta pentru a-și îndeplini sarcinile.,prototipurile pot fi reprezentări vizuale ieftine și rapide ale cerințelor (prototipuri de aruncare) sau mai complexe (prototipuri evolutive). Acestea din urmă pot deveni chiar versiunile timpurii ale produsului care au deja câteva bucăți din Codul final. Efectiv, prototipurile evolutive se pot transforma chiar în MVP-uri pe care le-am descris într-un articol separat.

  documente de proiectare și prototipuri

  cerințele de proiectare sunt de obicei colectate și documentate folosind trei formate principale care se transformă unul în altul:

  Wireframes., Wireframes sunt structuri grafice cu fidelitate scăzută ale unui site web sau ale unei aplicații. Acestea ajută la maparea diferitelor pagini de produse cu secțiuni și elemente interactive.

  Machete. Odată ce wireframe-urile sunt gata, ele sunt transformate în machete, modele vizuale care transmit aspectul produsului final. În cele din urmă, machetele pot deveni designul final al produsului.

  prototipuri de proiectare. Aceste documente conțin elemente vizuale și permit unele interacțiuni ale interfeței, cum ar fi derularea, clic pe link-uri sau completarea formularelor., Prototipurile de proiectare pot fi construite de la zero folosind HTML și CSS, dar majoritatea echipelor UX folosesc servicii de prototipuri precum InVision.pentru a afla mai multe despre modul în care sunt gestionate procesele de proiectare UX, verificați studiul nostru de caz despre construirea unei soluții de management al călătoriilor pentru Cornerstone, un furnizor SaaS corporativ, în care am utilizat toate cele trei tipuri de cerințe de proiectare.

  cerințe nefuncționale

  cerințele nefuncționale descriu modul în care un sistem trebuie să se comporte și să stabilească constrângeri ale funcționalității sale. Acest tip de cerințe este, de asemenea, cunoscut sub numele de atribute de calitate ale sistemului.,să aruncăm o privire atentă la cerințele tipice nefuncționale.Usability definește cât de dificil va fi pentru un utilizator să învețe și să opereze sistemul. Utilizabilitatea poate fi evaluată din diferite puncte de vedere:

  eficiența utilizării: timpul mediu necesar pentru a atinge obiectivele unui utilizator, câte sarcini poate finaliza un utilizator fără ajutor, numărul de tranzacții finalizate fără erori etc.

  intuitivitate: cât de simplu este să înțelegi interfața, butoanele, titlurile etc.,

  volumul de muncă scăzut perceput: câte încercări sunt necesare utilizatorilor pentru a îndeplini o anumită sarcină.exemplu: cerințele de utilizare pot lua în considerare barierele lingvistice și sarcinile de localizare: persoanele care nu înțeleg limba franceză trebuie să poată utiliza produsul. Sau s-ar putea stabili cerințele de accesibilitate: Tastatura utilizatorii care naviga un site web folosind <tab>, trebuie să fie în măsură să ajungă la „Adauga in cos” buton de pe o pagina de produs, în termen de 15 <tab> clicuri.,

  securitate

  cerințele de securitate asigură că software-ul este protejat împotriva accesului neautorizat la sistem și la datele stocate. Acesta ia în considerare diferite niveluri de autorizare și autentificare în diferite roluri ale utilizatorilor. De exemplu, confidențialitatea datelor este o caracteristică de securitate care descrie persoanele care pot crea, vedea, copia, modifica sau șterge informații. Securitatea include, de asemenea, protecție împotriva virușilor și atacurilor malware.exemplu: permisiunile de acces pentru anumite informații de sistem pot fi modificate numai de administratorul de date al sistemului.,fiabilitatea definește cât de probabil este ca software-ul să funcționeze fără eșec pentru o anumită perioadă de timp. Fiabilitatea scade din cauza erorilor din cod, a defecțiunilor hardware sau a problemelor cu alte componente ale sistemului. Pentru a măsura fiabilitatea software-ului, puteți număra procentul de operațiuni care sunt finalizate corect sau puteți urmări perioada medie de timp în care sistemul rulează înainte de a eșua.

  exemplu: procesul de actualizare a bazei de date trebuie să returneze toate actualizările aferente atunci când orice actualizare eșuează., performanța este un atribut de calitate care descrie capacitatea de reacție a sistemului la diferite interacțiuni ale utilizatorilor cu acesta. Performanța slabă duce la o experiență negativă a utilizatorului. De asemenea, pune în pericol siguranța sistemului atunci când este supraîncărcat.exemplu: timpul de încărcare pe prima pagină nu trebuie să depășească 2 secunde pentru utilizatorii care accesează site-ul web utilizând o conexiune mobilă LTE.

  disponibilitate

  disponibilitatea este măsurată de perioada de timp în care funcționalitatea și serviciile sistemului sunt disponibile pentru utilizare în toate operațiunile., Deci, perioadele de întreținere programate influențează direct acest parametru. Și este important să se definească modul în care impactul întreținerii poate fi minimizat. La scrierea cerințelor de disponibilitate, echipa trebuie să definească cele mai critice componente ale sistemului care trebuie să fie disponibile în orice moment. De asemenea, trebuie să pregătiți notificările utilizatorului în cazul în care sistemul sau una dintre părțile sale devine indisponibilă.

  exemplu: implementarea noului modul nu trebuie să afecteze prima pagină, paginile produsului și să verifice disponibilitatea paginilor și nu trebuie să dureze mai mult de o oră., Restul paginilor care pot întâmpina probleme trebuie să afișeze o notificare cu un cronometru care să arate când sistemul va fi din nou.

  scalabilitate

  cerințele de scalabilitate descriu modul în care sistemul trebuie să crească fără o influență negativă asupra performanței sale. Aceasta înseamnă să deservești mai mulți utilizatori, să procesezi mai multe date și să faci mai multe tranzacții. Scalabilitatea are implicații atât hardware, cât și software. De exemplu, puteți crește scalabilitatea adăugând memorie, servere sau spațiu pe disc. Pe de altă parte, puteți comprima date, puteți utiliza algoritmi de optimizare etc.,

  exemplu: limita de participare la site-ul web trebuie să fie suficient de scalabilă pentru a suporta 200.000 de utilizatori simultan.

  cuvinte finale

  toate proiectele software includ limitele de informații care descriu produsul și obiectivele proiectului. Aceste limite sunt trasate în cerințele și specificațiile proiectului. Valoarea creării specificațiilor cerințelor software este în optimizarea procesului de dezvoltare. Specificațiile cerințelor Software răspundeți la toate întrebările dezvoltatorului despre produsul care este necesar pentru a începe lucrarea., Specificația funcțională este aprobată de client și se asigură că dezvoltatorii construiesc ceea ce dorește clientul.