Přeskočit na hlavní obsah

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.

Komentáře

Populární příspěvky z tohoto blogu

10 způsobů jak se naučit programovat samostatně.

Programování je jednou z nejcennějších dovedností pro profesní růst, osobní rozvoj a vytváření něčeho úžasného. Je čas popsat deset tipů pro ty, kteří právě začínají svou cestu do programovacího světa. 1. Zjistěte, proč chcete programovat Zvolený směr ve výuce bude záviset na tom, proč se chcete naučit programovat a jak dlouho jste ochotni věnovat tomuto procesu. Pokud chcete být programátorem, je třeba začít s odborným kurzem (společnost Google sestavila seznam dovedností a kurzů pro ty, kteří chtějí být programátorem). Pokud chcete vytvářet hry a webové stránky pro zábavu ve svém volném čase, interaktivní kurzy jsou nejlepší volbou. Bloc vytvořil srovnávací tabulku kurzů v závislosti na zatížení, nákladech a důvodech k osvojení si programování. 2. Vyberte správný jazyk programování Neexistuje nejlepší programovací jazyk. Jakmile se naučíte jeden, nebude pro vás problém zvládnout další. Takže se nemusíte koncertovat na volbu pouze jednoho jazyka. Nicméně předpokládá s

14 tipů pro návrh ikon mobilních aplikací.

Ikona mobilní aplikace je malý obrázek, který prezentuje aplikaci v mobilním světě , na zařízení uživatele a na obchodech s aplikacemi. Pokud budete brzy vytvářet svoji mobilní aplikaci a návrh ikonky k tomu, přečtěte si tyto tipy. Pomohou vám vyhnout se chybám, se kterými se nováčci mohou setkat. Grafik by se měl soustředit na vzhled ikony, protože se uživatelé často pří výběru aplikace řídí právě vzhledem ikony. Proto nabízíme následující tipy pro vytvoření návrhu ikony mobilní aplikace. Postupujte podle pokynů mobilních výrobců Ikony neexistují samy o sobě, ale uvnitř grafického obalu určitého systému . Měly by se harmonicky vejít do rozhraní aplikace, nevypadat zvláštně vedle ikon jiných aplikací, ale současně být jedinečné. Proto vývoj ikony aplikace začíná seznámením se s příručkou výrobce systému. Zde jsou příručky, se kterými byste měli začít: Oficiální stránka věnovaná Material Design pro Android . Zde si můžete přečíst o stylu, animaci, komponente

Metody vývoje aplikací. Waterfall, V-model, Inkrementální model

Existuje několik osvědčených metod pro vývoj software, tzv. best practices. Volba konkretní metody závisí na specifikaci projektu, rozpočtu, subjektivní preferenci a dokonce i temperamentu vedoucího. V tomto článku krátce popíšeme základní metody vývoje webových a mobilních aplikací. «Waterfall Model» (model vodopádu) Jedna z nejstarších metod, zahrnuje postupné procházení etap, z nichž každá musí být plně dokončena, než se začne další. Pomocí modelu vodopádu je snadné řídit projekt. Vývoj je rychlý, náklady a doba trvání jsou předem definovány. Má to ovšem i druhou stránku. Vodopádový model poskytne vynikající výsledek pouze v projektech s jasnými a předem definovanými požadavky a způsoby jejich realizace. Není zde možnost udělat krok zpět, testování začne až poté, co je vývoj ukončen nebo téměř dokončen. Kdy použít model vodopádu? Pouze tehdy, když jsou požadavky známé, jasné a pevně stanovené. Rozporné požadavky neexistují. Nejsou žádné problémy s dost