Menu

Ako otestovať špecifikáciu softvérových požiadaviek (SRS)?

how test software requirements specification

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Ste si toho vedomý 'Väčšina z.' Ploštice v softvéri sú spôsobené neúplnými alebo nepresnými funkčnými požiadavkami? “ Nech je napísaný akokoľvek dobre, na softvérovom kóde nezáleží a ak sa v požiadavkách vyskytnú nejasnosti, nedá sa nič robiť.

Tento článok o špecifikácii softvérových požiadaviek (SRS) uvádza, že požiadavky musia byť jasné, konkrétne, merateľné a úplné bez rozporov.

Je lepšie zachytiť nejasnosti požiadaviek a opraviť ich v samotnom životnom cykle raného vývoja.

Ako otestovať špecifikáciu softvérových požiadaviek (SRS) _

Náklady na opravu chyby po dokončení vývoja alebo vydania produktu sú príliš vysoké. Je preto dôležité vykonať analýzu požiadaviek a zachytiť tieto nesprávne požiadavky pred návrhovými špecifikáciami a fázami implementácie projektu v SDLC.

Čo sa dozviete:

Ako merať funkčné dokumenty SRS?

Musíme zadefinovať niekoľko štandardných testov na meranie požiadaviek. Len čo každá požiadavka prejde týmito testami, môžete vyhodnotiť a zmraziť funkčné požiadavky.

Zoberme si príklad pracujete na webovej aplikácii. Požiadavka je nasledovná: „Webová aplikácia by mala byť schopná obsluhovať dotazy používateľov čo najskôr“.

Ako v tomto prípade zmrazíte požiadavku?

Aké budú vaše kritériá spokojnosti s požiadavkami? Ak chcete získať odpoveď, položte túto otázku zúčastneným stranám: Koľko času odozvy je pre vás v poriadku? Ak povedia, prijmeme odpoveď, ak je to do 2 sekúnd, potom je to požiadavka. Zmrazte túto požiadavku a postupujte rovnako pre ďalšiu požiadavku.

Práve sme sa naučili merať požiadavky a zmraziť ich vo fázach návrhu, implementácie a testovania.

Uveďme si ďalší príklad: Pracoval som na webovom projekte. Klient (zainteresované strany) špecifikoval požiadavky na projekt v počiatočnej fáze vývoja projektu. Môj manažér rozoslal všetky požiadavky v tíme na kontrolu. Keď sme začali diskusiu o týchto požiadavkách, boli sme šokovaní!

Každý mal svoju vlastnú predstavu o požiadavkách. V „podmienkach“ uvedených v dokumentoch s požiadavkami, ktoré boli neskôr zaslané klientovi na kontrolu / objasnenie, sme našli veľa nejasností.

Klient použil veľa nejednoznačných výrazov, ktoré mali veľa rôznych významov, čo nám sťažilo analyzovať presný význam. Ďalšia verzia dokumentu s požiadavkami od klienta bola dostatočne jasná, aby zamrzla pre fázu návrhu.

Z tohto príkladu sme sa dozvedeli, že „požiadavky by mali byť jasné a konzistentné“

Ďalším kritériom na testovanie špecifikácie požiadaviek je „Objavte chýbajúce požiadavky“, poďme sa na to pozrieť.

Objavte chýbajúce požiadavky

Mnohokrát nemajú návrhári projektu jasnú predstavu o každom konkrétnom module a vo fáze návrhu jednoducho prijmú určité požiadavky. Žiadna požiadavka by nemala vychádzať z predpokladov. Požiadavky by mali byť úplné a mali by pokrývať všetky aspekty vyvíjaného systému.

V špecifikáciách by sa mali uviesť obidva typy požiadaviek, t. J. Čo by mal systém robiť a čo nie.

Spravidla používam svoju vlastnú metódu na odhalenie nešpecifikovaných požiadaviek. Keď som čítal Dokument so špecifikáciami softvérových požiadaviek (SRS) „Poznamenávam svoje vlastné pochopenie požiadaviek, ktoré sú špecifikované, a ďalších požiadaviek, ktoré má dokument SRS pokrývať.

To mi pomáha klásť otázky o bližšie nešpecifikovaných požiadavkách, čím som sa ujasnil.

Na kontrolu úplnosti požiadaviek rozdeľte požiadavky na tri oddiely: „Musí sa implementovať“ požiadavky, požiadavky, ktoré nie sú špecifikované, ale sú „predpokladané“, a tretím typom je „fantázia“. Pred fázou návrhu softvéru skontrolujte, či sú vyriešené všetky typy požiadaviek.

Skontrolujte, či požiadavky súvisia s cieľom projektu

Zainteresované strany majú niekedy svoje vlastné odborné znalosti, od ktorých očakávajú, že sa dostanú do vyvíjaného systému. Ani si nemyslia, či by táto požiadavka bola relevantná pre daný projekt. Určite tieto požiadavky. Pokúste sa vyhnúť všetkým irelevantným požiadavkám počas prvej fázy vývojového cyklu projektu.

Ak to nie je možné, položte zainteresovaným stranám otázky typu: prečo chcete implementovať túto konkrétnu požiadavku? Toto podrobne popíše konkrétnu požiadavku, čím uľahčí návrh systému s ohľadom na budúci rozsah.

Ako však rozhodnúť, či sú požiadavky relevantné alebo nie?

Jednoduchá odpoveď: Stanovte cieľ projektu a položte túto otázku: Ak nebude implementácia tejto požiadavky spôsobovať problém pri dosahovaní nášho stanoveného cieľa? Ak nie, potom je to irelevantná požiadavka. Opýtajte sa zainteresovaných strán, či skutočne chcú implementovať tieto typy požiadaviek.

Stručne povedané, dokument Specification Requirements Specification (SRS) by sa mal zaoberať týmto:

ako inicializovať zoznam v
  • Funkčnosť projektu (Čo by sa malo robiť a čo sa nemá robiť).
  • Softvér, hardvérové ​​rozhrania a používateľské rozhranie.
  • Kritériá správnosti, bezpečnosti a výkonu systému.
  • Problémy s implementáciou (riziká), ak existujú.

Záver

Pokryl som takmer všetky aspekty merania požiadaviek. Aby som bol konkrétny ohľadom požiadaviek, zhrniem testovanie požiadaviek do jednej vety:

„Požiadavky by mali byť jasné a konkrétne bez akejkoľvek neistoty, požiadavky by mali byť merateľné z hľadiska konkrétnych hodnôt, požiadavky by mali byť testovateľné s určitými hodnotiacimi kritériami pre každú požiadavku a požiadavky by mali byť úplné bez akýchkoľvek rozporov.“

Testovanie by sa malo začať vo fáze požiadaviek, aby sa zabránilo ďalším chybám súvisiacim s požiadavkami. Komunikovať stále viac spolu so svojimi zainteresovanými stranami objasnite všetky požiadavky pred začatím projektovania a implementácie.

Máte nejaké skúsenosti s testovaním softvérových požiadaviek?

Neváhajte ich zdieľať v komentároch nižšie.

Odporúčané čítanie

^