Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : MA: Sběr a správa požadavků
MA: Sběr a správa požadavků
Kód úlohy

Standardní kód úlohy v MBI.

:
U466F
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Franek, O. (etnetera)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.3
Charakteristiky úlohy

Charakteristiky úlohy

1. Obsah úlohy
  • Průběh softwarového projektu nelze přesně předpovědět. Jakmile uživatelé, ale i zadavatelé projektu uvidí první verze prototypu aplikace, přijdou s novými nápady a jejich požadavky se mění.
  • Agilní techniky se nesnaží udělat všechna rozhodnutí o podobě aplikace najednou, ale raději je rozdělit do menších částí , které se pravidelně opakují v průběhu celého projektu. Tato disciplína navazuje na předchozí uživatelský výzkum , účelem úlohy sběru a správy požadavků je:
    • Porozumět problémům, které máme řešit,
    • Pochopit potřeby všech zúčastněných stran,
    • Definovat omezení aplikace.
2. Formulace požadavků
  • Formulace požadavků na software je komunikační problém . Ti, co chtějí získat nový software, musí komunikovat s těmi, kteří ho budou vyvíjet. Na jedné straně tak jsou zástupci zákazníka, uživatelů a další, kteří se na software dívají byznysovým pohledem. Na druhé straně stojí technický tým . Za vhodný formát požadavku se považuje user stories , běžné ve světě agilního vývoje. Formulace požadavků formou user stories tyto dvě odlišné strany podílející se na realizaci softwarového projektu sbližuje. Zákazník si dokáže představit hodnotu, kterou dostane, a vývojář rozumí, co je cílem požadavku. Formát user story zároveň povzbuzuje obě strany k další diskuzi a vyjasnění požadavku.
  • User story by měla vycházet z následujícího formátu : Jako uživatel chci funkcionalitu, abych dostal byznysovou hodnotu. Tento formát má za úkol vytvořit v hlavě obrázek, popisovat příběh. Zároveň klade důraz na hodnotu pro uživatele a formulaci problému z jeho pohledu. Oproti jiným formám požadavků se soustředí na dvě otázky: kdo a proč . Formát user story funguje velmi efektivně v kombinaci s předem specifikovaným modelem uživatele – personou .Tím, že požadavek zformulujeme z pohledu jasně specifikované persony, můžeme otestovat, že je pro ni skutečně relevantní . Důležitým aspektem v projektu popsaném pomocí user stories je zapojení zákazníka a uživatelů během celého projektu . Nové user stories totiž mohou vznikat v průběhu celého projektu.
2.1. Formulace nefunkčních požadavků jako user story
  • Agilní týmy mají často problém s formulací nefunkčních požadavků ve formě user stories. Mike Cohn (2008) uvádí, že nefunkční požadavky jsou omezení , která klademe na vyvíjený systém. Z tohoto pohledu nefunkční požadavky omezují designové alternativy, kterými se můžeme při vyvíjení aplikace vydat.
  • Zadavatelem nefunkčních požadavků je obvykle zákazník , pro kterého je aplikace vyvíjena. Příklad nefunkčního požadavku formulovaného z pohledu zákazníka: „Jako zákazník chci, aby aplikace fungovala na chytrých telefonech s verzí operačního systému Android 4.0 a vyšší, aby si ji mohli stáhnout i uživatelé se staršími zařízeními.“ Účelem tohoto formátu je uvědomit si, kdo dané omezení požaduje a proč.
2.2. Psaní user stories
  • User stories sepisuje v ideálním případě tým lidí, kteří mají blízko k zákazníkovi i uživatelům . To má dva hlavní důvody (Cohn 2004):
    • Každá user story musí být napsaná v jazyku byznysu, a ne v technickém žargonu. Zákazník tak významu user story rozumí a může jí přidělit hodnotu.
    • Zákaznický tým lépe zná vizi produktu a umí tak lépe popsat, jak by se měl produkt chovat.
  • Příklad user story psané v jazyce byznysu se zapojením konkrétní persony může vypadat například takto: „Jako Martina Kettnerová chci být upozorněna na blížící se začátek vysílání mého oblíbeného pořadu, abych ho nezmeškala.“. Kdyby byla user story napsaná v technickém žargonu , rozuměl by jí dobře vývojář, ale zákazník už moc ne. Příklad nevhodně psané user story: „Jako primary_user chci dostat push notifikaci o blížícím začátku live streamu, abych ho nezmeškal.“ Tento způsob zápisu je zároveň velmi sugestivní – skrývá v sobě kromě požadavku uživatele také konkrétní technologii a způsob implementace. I když tým k tomuto řešení možná dospěje, měla by formulace požadavků být těchto detailů prostá, aby si tým nechával otevřené dveře pro alternativní způsoby řešení.
2.3. INVEST

Každá user story by měla ideálně splňovat 6 kritérií, jejichž první písmena skládají v originálních anglických názvech slovo INVEST (Wake 2002):

  • Nezávislá (Independent) - každá user story by měla být nezávislá na dalších user stories. Závislost mezi user stories vytváří problémy při jejich prioritizaci a plánování iterací,
  • Podněcující diskuzi (Negotiable) - user stories nejsou závazné požadavky. Jejich formát má podporovat diskuzi mezi zákazníkem a vývojáři. User story také nemá být příliš detailní, aby nesváděla k vynechání diskuze,
  • Hodnotná pro uživatele nebo zákazníky (Valuable to users or customers) - z formulace user story by mělo být patrné, jakou přinese hodnotu pro uživatele nebo zákazníka. User story, která je formulovaná v technickém jazyce nebo například definuje vlastnosti systému, je pro uživatele těžko uchopitelná. Pro zástupce uživatelů je v takovém případě obtížné user story přiřadit prioritu a porovnat ji s jinými požadavky,
  • Odhadnutelná (Estimatable) - je důležité, aby vývojáři byli schopní odhadnout pracnost user story. Vývojáři obvykle nejsou schopni pracnost odhadnout z některého z těchto důvodů:
    • Vývojáři nemají dostatečné znalosti v dané byznysové doméně,
    • Vývojáři nemají dostatečné technické znalosti,
    • User story je příliš velká.
  • Malá (Small) - user story by měla být tak velká, aby ji vývojář mohl dokončit v řádu jednotek dní. Pokud je user story příliš velká, špatně se odhaduje její pracnost a hůře se o ní diskutuje mezi vývojářem a zákazníkem. Malé user stories umožňují vývojářům rychleji dodávat nové kusy funkcionality, která se tak dříve dostane k zákazníkovi. Menší user stories tak zrychlují proces získávání zpětné vazby od uživatelů,
  • Testovatelná (Testable) - jak se pozná, že je user story hotová? Tím, že user story úspěšně projde testem, dokazuje, že byla úspěšně vyvinuta. Netestovatelné user stories často skrývají požadavky nefunkční povahy, např.: „Uživatel musí systém považovat za jednoduše použitelný.“, Uživatel nikdy nesmí čekat dlouho na načtení obrazovky.“. Takto zapsané user stories nemohou být otestovány – není možné zkontrolovat správnost jejich implementace. Alternativní zápis umožňující otestování by mohl vypadat třeba takto: „Uživatel, který nemá se systémem žádnou zkušenost, je schopen dokončit běžné úkoly bez předchozího zaškolení.“ „Obsah obrazovky se v 95 % případů načte během 2 vteřin.“.
3. Poznámky, reference:
  • Franek, O. (etnetera): Proces tvorby zadání a správy požadavků pro vývoj mobilní aplikace, VŠE, Praha. 2018,
  • COHN, Mike, 2008. Non-functional Requirements as User Stories. Mountain Goat Software [online] [vid. 2017-12-04]. Dostupné z: https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories
  • COOPER, Alan, 2014. About face: the essentials of interaction design, 4th edition. 4th edition. Indianapolis, IN: John Wiley and Sons. ISBN 978-1-118-76657-6