Co je zadaní s požadovanou funkcionalitou? A proč ho potřebujete?

Když zákazník mluví o svých požadavcích, může se stát, že vynechá podstatné detaily. Uvedeme si to na příkladu - zákazník požaduje v mobilní aplikaci autorizaci uživatele pomocí telefonního čísla a hesla, která bude propojená se sociálními sítěmi. Na schůzce zákazník pouze sdělí, že potřebuje autorizaci a neřekne k tomu žádné další podrobnosti nebo požadavky, jak to má být přesně provedeno. V důsledku toho vývojář udělá autorizaci pomocí e-mailu a hesla. Klient je ve výsledku nespokojen a vývojář nechápe proč.

Abyste předešli takovým situacím, všichni členové týmu musí rozumět tomu, jakého výsledku potřebujete dosáhnout. Proto potřebujete vytvořit podrobné zadání s požadovanou funkcionalitou (dále FZ), ve kterém se popíšou veškeré možnosti a požadavky vyvíjené aplikace nebo systému. Zadání s požadovanou funkcionalitou potřebujete pro:

• vytvoření plného zadání projektu a technické dokumentace, ve kterém se přesně popíše, jak bude daná aplikace nebo systém fungovat.;
• vytvoření podrobného návrhu a wireframů;
• chápání toho, jak všechno funguje;
• zhodnocení a plánování vývoje;
• testování;
• případné předání projektu jinému týmu.

Co očekáváme od zadání s požadovanou funkcionalitou?

Dokumentování možností a funkcí produktu ve formě zadaní má poskytnout týmu jasnou představu o něm. Pro vývojáře jsou úkoly přesně formulovány a mají svůj pořádek, což optimalizuje vývojový proces. Tester pomocí FZ může vytvořit kontrolní seznam - podrobný seznam funkcí, které je třeba testovat, a buď si ověří, že aplikace funguje přesně podle dokumentu, nebo najde chyby. Dále, při vývoji a podpoře produktu, tester doplňuje všechny změny do FZ a aktualizuje dokument. Pokud se zákazník najednou rozhodl zvolit jiného dodavatele, FZ pomůže předat projekt novému týmu jednodušeji a rychleji.

V praxi neexistuje žádná standardní šablona pro vytvoření zadání s požadovanou funkcionalitou. Zadání by mělo být výstižné, protože nikdo nechce číst zbytečné informace. Zároveň by tým neměl mít k dokumentu otázky, protože obsah by měl být jasný, jednoznačný a měl by týmu přinášet užitek.

Jak vypadá dokument, který nikdo nepotřebuje?

Tím, že neexistuje standardní šablona na tvorbu kvalitního zadání a projekt je tak tvořen ve volném stylu, často se stává, že vznikne rozsáhlý dokument, ve kterém jsou jednotlivé funkce popsány do sebemenšího detailu. V zadání neexistuje jednotná struktura, a tak dojde k tomu, že zadání napříč všemi projekty jsou odlišná. Zároveň se nikdo nechce zabývat takto rozsáhlým dokumentem: odborníci raději komunikují s analytikem nebo manažerem a testeři si píšou vlastní kontrolní seznamy od nuly, protože doba testování podle sepsaného zadání se několikrát zvyšuje.

Nehledě na to, že samotný produkt se postupem času vyvíjí a doplňuje o novou funkcionalitu. Kvůli tomu je potřeba dokumentaci aktualizovat. A pokud sepsaný dokument nikdo nepoužívá, nemá smysl jej ani aktualizovat, jelikož by to byla ztráta času. Dokument se tak stává nepotřebným a zbytečným.

Jak tedy na zadaní s požadovánou funkcionalitou?

Abychom vyřešili problém, zkusíme změnit formát zadání. Každé zadání by mělo obsahovat tzv. Superstories a Stories. Pod Superstory si můžete představit kapitolu, kterou můžete rozdělit na podkapitoly, nebo-li Stories. Charakteristickou vlastností Superstories je, že zobrazuje hlavní cíle koncového uživatele. Například v online obchodě chce uživatel vidět katalog, objednat oblíbený produkt a sledovat jeho dodání. Superstories tak budou katalog, osobní účet a objednání zboží. Každý z těchto Superstories má svou vlastní hodnotu pro uživatele a je relativně soběstačný.

Superstory stanovuje nejobecnější hranice všech částí aplikace, proto dalším krokem bude rozdělení superstory na menší části - stories.

Jednotlivé stories popisují krátkými větami funkcionalitu z pohledu uživatele. Zahrnují uživatele, funkce, které používá a cíle uživatele. Pro internetový obchod z příkladu mohou stories vypadat takto:

• “Jako zákazník můžu použít vyhledávání v katalogu a rychle najít produkt, který potřebuji”,
• “Jako zákazník můžu přidat produkt do oblíbených, abych se mohl rychle vrátit k výrobkům, které se mi líbí”.

Superstories a Stories tvoří “kostru” zadání a v rané fázi projektu to stačí. Ve fázi návrhu je dokument kompletně dokončen a objevují se kritéria přijetí (acceptance criterium) - jedná se o krátké pokyny, které podrobně popisují funkcionalitu.

Pro internetový obchod z příkladu mohou kritéria přijetí vypadat takto:

• mohu najít produkt podle názvu;
• mohu najít produkt podle čárového kódu;
• vidím prázdnou obrazovku, pokud katalog neobsahuje žádnou položku.

Kritéria přijetí nezohledňují počet obrazovek, umístění tlačítek, jejich barvu a jiné konstrukční prvky.
Takto sepsané zadání bude jednodušší a rychleji sepsané. Pro tým je snadné porozumět požadavkům díky detailnímu popisu - krátké a jednoduché věty jsou pro lidi snadněji přijatelné.
Zadaní s požadovanou funkcionalitou informuje o tom, co může uživatel s aplikací dělat. Technické informace, požadavky na rozhraní a architekturu aplikace je třeba umístit do technického zadání, se kterým Vám pomůže dodavatel.

Pokud chcete ve výsledku dostat aplikaci, která bude zcela odpovídat Vašim představám, dodejte jasně definované zadání s požadovanou funkcionalitou. Technické zadání, analýzu, detailní návrh a promyšlený vývoj Vám zajistí iQuest.