Séria: Ako písať dokumentáciu a manuály v IT projekte
V mnohých projektoch sa stretávame s vetami typu:
- „Systém musí byť rýchly.“
- „Systém musí byť bezpečný.“
- „Systém musí zvládnuť veľa používateľov.“
Na prvý pohľad to vyzerá ako normálne požiadavky.
Problém je, že nie je jasné:
- čo presne má systém robiť,
- ako sa to bude testovať,
- ani či je požiadavka splnená.
Veľká časť chaosu v projektoch vzniká práve tým, že tímy miešajú funkčné a nefunkčné požiadavky.
Funkčné požiadavky
Funkčné požiadavky opisujú správanie systému.
Teda čo má systém robiť.
Príklady:
- Používateľ môže vytvoriť objednávku.
- Systém vypočíta cenu objednávky.
- Administrátor môže zmeniť stav objednávky.
- Systém odošle potvrdenie e-mailom.
Tieto požiadavky sa najčastejšie objavujú v:
- user story
- akceptačných kritériách
- testovacích scenároch
- používateľských manuáloch
Ak sú zapísané jasne, tím presne vie:
- čo sa má implementovať,
- čo sa má testovať,
- čo sa má vysvetliť v dokumentácii.
Nefunkčné požiadavky
Nefunkčné požiadavky opisujú vlastnosti systému.
Teda ako dobre má systém fungovať.
Príklady:
- výkon
- bezpečnosť
- dostupnosť
- škálovateľnosť
- použiteľnosť
- kompatibilita
Typické formulácie:
- Stránka sa musí načítať do 2 sekúnd.
- Systém musí podporovať 10 000 súčasných používateľov.
- Komunikácia musí byť šifrovaná pomocou HTTPS.
- Systém musí byť dostupný 99,9 % času.
Tieto požiadavky sú základom pre:
- výkonnostné testovanie
- bezpečnostné testovanie
- SLA
- prevádzkové monitorovanie
Prečo sa tieto typy požiadaviek miešajú
V praxi sa často objavujú vety ako:
„Systém musí rýchlo spracovať objednávku.“
Na prvý pohľad to vyzerá ako jasná požiadavka.
V skutočnosti však obsahuje dve rôzne veci:
- funkciu – spracovanie objednávky
- vlastnosť – rýchlosť
Takéto formulácie spôsobujú problémy:
- tester nevie pripraviť presný test
- vývojár nevie, čo presne sa očakáva
- dokumentácia je nejednoznačná
Ako to oddeliť v praxi
Lepšie je tieto dve veci zapísať oddelene.
Funkčná požiadavka
Systém umožní používateľovi vytvoriť objednávku.
Nefunkčná požiadavka
Vytvorenie objednávky musí byť spracované do 2 sekúnd pri záťaži 1 000 súčasných používateľov.
Takto je jasné:
- čo systém robí
- aké má mať vlastnosti
- ako sa to bude testovať
Typické chyby v projektoch
Nejasné formulácie
„Systém musí byť rýchly.“
Bez merateľnej hodnoty to nie je testovateľná požiadavka.
Nefunkčné požiadavky skryté v user story
User story má opisovať správanie systému.
Požiadavky na výkon alebo bezpečnosť často patria skôr do:
- architektonických požiadaviek
- prevádzkových požiadaviek
- samostatných nefunkčných požiadaviek
Nefunkčné požiadavky sa objavia až na konci projektu
Tím vyvinie funkcionalitu a až potom zistí, že:
- systém nezvláda záťaž
- alebo nespĺňa bezpečnostné požiadavky.
Vtedy už býva oprava veľmi náročná.
Prečo je to dôležité pre testerov
Tester je často prvý človek v tíme, ktorý si všimne, že požiadavka je nejasná.
Ak nie je jasné:
- čo systém robí
- aké má mať vlastnosti
nedá sa pripraviť dobrý test.
Rozlíšenie funkčných a nefunkčných požiadaviek pomáha:
- vytvoriť presnejšie akceptačné kritériá
- pripraviť vhodné testovacie scenáre
- zabrániť nedorozumeniam medzi biznisom a vývojom
Prepojenie s akceptačnými kritériami
V predchádzajúcich článkoch série sme sa venovali tomu, ako písať testovateľné akceptačné kritériá a ako pomáha štruktúra Given–When–Then.
Ak sú však požiadavky nejasné alebo zmiešané, ani najlepšia štruktúra nepomôže.
Akceptačné kritériá totiž musia vychádzať z jasného zadania:
- funkčné požiadavky opisujú správanie systému
- nefunkčné požiadavky definujú podmienky, v ktorých má systém fungovať
Ak tieto dve veci nie sú oddelené, vznikajú:
- nejednoznačné testy
- nepresná dokumentácia
- konflikty medzi očakávaniami a realitou systému.
Zhrnutie
Funkčné požiadavky hovoria čo systém robí.
Nefunkčné požiadavky hovoria ako dobre to robí.
Ak sa tieto dva typy požiadaviek zmiešajú do jednej vety, vzniká nejasnosť, ktorá sa postupne prenesie do:
- implementácie
- testovania
- dokumentácie
- podpory používateľov
Preto má zmysel tieto typy požiadaviek vedome oddeľovať už pri písaní zadania.