Meniu

Cum se testează specificațiile cerințelor software (SRS)?

how test software requirements specification

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ești conștient de asta 'Cele mai multe dintre Gandaci în software se datorează unor cerințe funcționale incomplete sau inexacte? ” Oricât de bine este scris, codul software nu contează și nu se poate face nimic dacă există ambiguități în cerințe.

Acest articol despre Specificațiile cerințelor software (SRS) specifică că cerințele trebuie să fie clare, specifice, măsurabile și complete, fără contradicții.

Este mai bine să prindeți ambiguitățile cerințelor și să le remediați chiar în ciclul de viață al dezvoltării timpurii.

Cum se testează specificațiile cerințelor software (SRS) _

Costul remedierii erorii după finalizarea dezvoltării sau lansării produsului este prea mare. Deci, este important să aveți o analiză a cerințelor și să prindeți aceste cerințe incorecte înainte de specificațiile de proiectare și fazele de implementare a proiectului SDLC.

Ce veți învăța:

Cum se măsoară documentele SRS funcționale?

Ei bine, trebuie să definim câteva teste standard pentru a măsura cerințele. Odată ce fiecare cerință este trecută prin aceste teste, puteți evalua și îngheța cerințele funcționale.

Să luăm o exemplu, lucrați la o aplicație bazată pe web. Cerința este următoarea: „Aplicația web ar trebui să poată răspunde întrebărilor utilizatorilor cât mai curând posibil”

Cum veți îngheța cerința în acest caz?

Care vor fi criteriile dvs. de satisfacție a cerințelor? Pentru a obține răspunsul, puneți această întrebare părților interesate: Cât timp este bun pentru dvs.? Dacă acestea spun, vom accepta răspunsul dacă este în termen de 2 secunde, atunci aceasta este măsura dvs. de cerință. Înghețați această cerință și efectuați aceeași procedură și pentru următoarea cerință.

Tocmai am învățat cum să măsurăm cerințele și să le înghețăm în fazele de proiectare, implementare și testare.

cum să adăugați lucruri la o matrice Java

Să luăm acum un alt exemplu: Lucram la un proiect bazat pe web. Clientul (părțile interesate) a specificat cerințele proiectului în faza inițială a dezvoltării proiectului. Managerul meu a distribuit toate cerințele în echipă pentru revizuire. Când am început discuția cu privire la aceste cerințe, am fost doar șocați!

Toată lumea avea propria concepție despre cerințe. Am găsit o mulțime de ambiguități în „termenii” specificați în documentele de cerință, care ulterior au fost trimise clientului pentru examinare / clarificare.

Clientul a folosit mulți termeni ambigui, care aveau multe semnificații diferite, ceea ce ne făcea dificil să analizăm sensul exact. Următoarea versiune a documentului de cerință de la client a fost suficient de clară pentru a îngheța pentru faza de proiectare.

Din acest exemplu, am aflat că „Cerințele ar trebui să fie clare și coerente”

Următorul criteriu pentru testarea specificației cerințelor este „Descoperiți cerințele lipsă”, să aruncăm o privire.

Descoperiți cerințele lipsă

De multe ori, proiectanții nu au o idee clară despre fiecare modul specific și pur și simplu își asumă unele cerințe în faza de proiectare. Orice cerință nu ar trebui să se bazeze pe ipoteze. Cerințele trebuie să fie complete, acoperind fiecare aspect al sistemului în curs de dezvoltare.

Specificațiile ar trebui să conțină ambele tipuri de cerințe, adică ce sistem ar trebui să facă și ce nu ar trebui să facă.

În general, îmi folosesc propria metodă pentru a descoperi cerințele nespecificate. Când am citit Document de specificații pentru cerințele software (SRS) , Notez propria mea înțelegere a cerințelor specificate, plus alte cerințe pe care se presupune că le acoperă documentul SRS.

Acest lucru mă ajută să pun întrebări despre cerințele nespecificate, făcându-l astfel mai clar.

Pentru verificarea exhaustivității cerințelor, împărțiți cerințele în trei secțiuni, cerințele „Trebuie să implementați”, cerințe care nu sunt specificate, dar care sunt „asumate”, iar al treilea tip este cerințele „imaginației”. Verificați dacă toate tipurile de cerințe sunt abordate înainte de faza de proiectare a software-ului.

Verificați dacă cerințele sunt legate de obiectivul proiectului

Uneori părțile interesate au propria lor expertiză, pe care se așteaptă să o aducă în sistemul în curs de dezvoltare. Nici măcar nu se gândesc dacă această cerință ar fi relevantă pentru proiectul în cauză. Asigurați-vă că identificați astfel de cerințe. Încercați să evitați toate cerințele irelevante în timpul primei faze a ciclului de dezvoltare a proiectului.

Dacă nu este posibil, adresați-vă întrebărilor părților interesate, de ce doriți să implementați această cerință specifică? Aceasta va descrie în detaliu cerința specială, facilitând astfel proiectarea sistemului având în vedere domeniul de aplicare viitor.

Dar cum să decidem dacă cerințele sunt relevante sau nu?

Răspuns simplu: Setați obiectivul proiectului și puneți această întrebare: Dacă nu implementarea acestei cerințe va cauza vreo problemă în atingerea obiectivului specificat? Dacă nu, atunci aceasta este o cerință irelevantă. Întrebați părțile interesate dacă doresc cu adevărat să implementeze aceste tipuri de cerințe.

Pe scurt, documentul cu specificațiile cerințelor (SRS) ar trebui să abordeze următoarele:

  • Funcționalitatea proiectului (Ce trebuie făcut și ce nu trebuie făcut).
  • Software, interfețe hardware și interfața cu utilizatorul.
  • Criterii de corectitudine, securitate și performanță ale sistemului.
  • Probleme de implementare (riscuri), dacă există.

Concluzie

Am acoperit aproape toate aspectele legate de măsurarea cerințelor. Pentru a fi specific despre cerințe, voi rezuma testarea cerințelor într-o frază:

„Cerințele ar trebui să fie clare și specifice, fără incertitudine, cerințele ar trebui să fie măsurabile în termeni de valori specifice, cerințele ar trebui să poată fi testate având anumite criterii de evaluare pentru fiecare cerință și cerințele ar trebui să fie complete, fără contradicții”

Testarea ar trebui să înceapă din faza cerințelor pentru a evita alte erori legate de cerințe. Comunica din ce în ce mai mult cu părțile interesate pentru a clarifica toate cerințele înainte de a începe proiectarea și implementarea proiectului.

Aveți experiență în testarea cerințelor software?

Vă rugăm să nu ezitați să le împărtășiți în comentariile de mai jos.

Lectură recomandată

^