Edukační okénko: Kvalita požadavků podle BABOK® aneb Jak nepsat vágní zadání

Posted by Martin Dostál
Můžete mít perfektně roztříděné požadavky i nastavenou matici trasovatelnosti. Pokud je ale samotný text požadavku napsaný vágně, vývojáři dodají něco úplně jiného a testeři nebudou vědět, co vlastně akceptovat. Podívejte se, jak pomocí standardu BABOK® Guide a jeho kritérií kvality proměnit nefunkční zadání v jednoznačnou specifikaci.

V předchozím okénku jsme si ukázali, jak rozřadit požadavky do 4 úrovní (BRQ, STK, FREQ/NFR, TRN) a propojit je trasováním. Jenže v praxi často narážíme na druhý problém: požadavek sice má správné ID i navázaný byznysový cíl, ale jeho samotné znění je pro realizaci nepoužitelné.

Když do specifikace napíšete „Systém bude rychle a přívětivě zobrazovat doporučené nabídky pro KAMa“, zakládáte si na nedorozumění. Co znamená „rychle“? Co přesně je „přívětivě“?

Není nutné spoléhat na subjektivní dojem. BABOK® Guide (kapitola 7.1 – Verify Requirements) definuje univerzální kritéria kvality požadavků (Quality Characteristics). Ta představují exaktní metr pro posouzení, zda je zadání připravené pro realizaci – bez ohledu na to, jakou metodikou projekt řídíte.

V tomto článku si podrobněji rozebereme 3 nejčastější prohřešky z praxe, přičemž kompletní přehled všech 9 kritérií kvality najdete v přiložené infografice.

3 hlavní hříchy při psaní požadavků (a jak je podle BABOK® opravit)

Na příkladu z našeho projektu B2B CVM Automation si ukážeme nejčastější chyby a jejich správné řešení:

1. Víceznačnost (Unambiguous)

  • ❌ Špatně: „CRM zobrazí obchodníkovi kampaňové nabídky v rozumném čase.“

  • ✔️ Správně (FREQ-002): „CRM systém zobrazí na kartě klienta maximálně 3 doporučené kampaňové nabídky vygenerované CVM enginem.“ (Případně doplněné o samostatný nefunkční požadavek NFR-001 na čas odezvy do 500 ms).

  • Proč: Slova jako rozumný, přívětivý, rychlý, dle potřeby interpretuje každý jinak. Požadavek musí mít pouze jeden jediný možný výklad.

2. Absence atomicity (Atomic)

  • ❌ Špatně: „Systém spočítá nákupní potenciál klienta, vygeneruje nabídku, pošle e-mail obchodníkovi a zapíše historii do databáze.“

  • ✔️ Správně: Rozdělení na samostatné, nezávislé požadavky (FREQ-001 výpočet potenciálu, FREQ-002 vygenerování nabídky v CRM, FREQ-003 notifikace obchodníka).

  • Proč: Požadavek má popisovat právě jednu schopnost nebo funkci. Pokud obsahuje spojku „a zároveň“, slučuje více věcí, které nelze samostatně měřit, prioritizovat ani realizovat.

3. Netestovatelnost (Testable)

  • ❌ Špatně: „Uživatel by měl mít možnost snadno filtrovat B2B zákazníky.“

  • ✔️ Správně (FREQ-004): „Systém umožní uživateli filtrovat seznam B2B zákazníků současně podle kritérií 'Obor podniku' a 'Roční obrat'.“

  • Proč: Požadavek sám o sobě musí být formulován tak, aby bylo možné jednoznačně ověřit (pomocí testu, inspekce či demonstrace), zda jej řešení splňuje či nikoli. Podrobné testovací scenáře (např. Given-When-Then) na požadavek pouze navazují, ale nenahrazují ho.

Tahák: Bad vs. Good Practice pro B2B CVM

Typ požadavku❌ Vágní / Špatné zadání✔ Kvalitní zadání (podle BABOK®)
Business Requirement„Chceme lepší CVM.“BRQ-02 : Zvýšit konverzní poměr cross-sell a up-sell kampaní u stávající B2B báze o 10 % do 12 měsíců.
Stakeholder Requirement„Obchodník chce vidět vše o klientovi.“STK-01 : KAM potřebuje mít před jednáním k dispozici přehled o skrytém potenciálu klienta a doporučených rozvojových produktech.
Solution Requirement Functional„Systém bude doporučovat produkty.“FREQ-001 : CVM engine vyhodnocuje data o spotřebě a pro každého B2B klienta určuje primární produkt pro up-sell.
Solution Requirement NonFunctional„Výpočty poběží v noci.“NFR-001 : Dávkový přepočet kampaňových modelů probíhá denně v čase od 02:00 do 06:00 AM.

Zkuste si to na svém projektu

Až budete připravovat specifikaci pro další fázi nebo revidovat požadavky před předáním realizačnímu týmu, proveďte rychlou kontrolu kvality (Peer Review) a u každé položky si položte 3 otázky:

  1. Je požadavek Atomický? (Popisuje opravdu jen jednu funkci/vlastnost, nebo je v něm schováno více věcí najednou?)

  2. Je Jednoznačný? (Vyhnuli jsme se vágním slovům jako „přívětivý“, „snadný“ nebo „dostatečný“?)

  3. Je Testovatelný? (Bude možné na konci bez dohadů říci ANO/NE, zda systém tuto vlastnost má?)

Kvalitně napsaný požadavek šetří desítky hodin vyjasňování během realizace a eliminuje drahé vícepráce při akceptačních testech.

Mějte pravidla kvality požadavků stále na očích

Chcete mít 9 kritérií kvality požadavků podle BABOK® Guide v3 i praktický workflow kontroly přímo u ruky při refinování backlogu nebo psaní specifikací?

Stáhněte si infografiku: 9 kritérií kvality požadavku, kde najdete kompletní přehled všech 9 vlastností kvality podle BABOK® Guide v3 (Atomic, Complete, Consistent, Concise, Feasible, Unambiguous, Prioritized, Testable, Understandable)

Tip: Vytiskněte si tahák do týmu nebo ho sdílejte s kolegy analytiky a product ownery – ušetří vám spoustu času při následném vývoji a testování!