Zadávací dokumentace, Funkční požadavky a Technické okrajové podmínky¶

Úvod¶

AAF zavádí pro účely úvodních prací na projektu tři pojmy: Zadávací dokumentaci, Funkční požadavky a Technické okrajové podmínky. První je vstupem analytického procesu, druhé jeho prvním analytickým výstupem, třetí doplňují Funkční požadavky o technologický kontext s vlivem na funkční logiku.

Zadávací dokumentace je souhrn všech vstupních materiálů od zadavatele. Má libovolný formát — od jednostránkového e-mailu po rozsáhlou sadu PDF, Wordů, prezentací a tabulek. Je externí: analytik ji přebírá, ne vytváří. V Brownfieldu existuje historicky, v Greenfieldu vzniká pro daný projekt.

Funkční požadavky jsou analytický artefakt, který ze Zadávací dokumentace vzniká (viz dále — Postup tvorby Funkčních požadavků). Drží hrubé mantinely systému a slovní skicu toho, co systém má dělat. Nejsou úplným popisem chování; jsou rámem, uvnitř kterého se další analýza odehrává. Detaily se rozkrývají postupně přes zpracování BPM, Use Cases, scénáře a další zpracování detailů.

Klíčový rys: Funkční požadavky nemají být úplné, ale musí nahrubo vystihnout podstatu. Příklad: „Systém umí počítat výplaty lektorů automaticky." — to je Funkční požadavek. Vymezuje, co systém má dělat (mantinel: „bez automatického výpočtu výplat lektorů systém neakceptujeme"). Ale neříká, jak — kolik vstupních polí, jaká pravidla zaokrouhlování, kdo formulář schvaluje. To přijde v dalších vrstvách AAF.

Funkční požadavky slouží jako „sirup" — destilát ze Zadávací dokumentace, který analytik vytvoří jednou a dále pracuje s ním, ne s původními zdroji.

Technické okrajové podmínky jsou analytický artefakt, který drží technologická omezení s možným vlivem na funkční logiku systému. Vznikají vedle Funkčních požadavků a doplňují je o kontext, ve kterém budou Funkční požadavky realizovány. Nejsou totéž jako Nefunkční požadavky — drží jen tu podmnožinu technologického zadání, která může ovlivnit funkční logiku.

Ruční transformace Zadávací dokumentace na Funkční požadavky bývá pro analytika dlouhým úkolem; AAF ji formalizuje tak, aby se dala asistovat AI (Vibe Analysing™).

Zadávací dokumentace¶

Zadávací dokumentace je souhrn všech vstupních materiálů od zadavatele, ze kterých analytik čerpá při tvorbě Funkčních požadavků. Vzniká mimo AAF — analytik ji přebírá v té podobě, ve které ji zadavatel poskytl.

Materiály Zadávací dokumentace nemají v AAF předepsanou strukturu ani formát. Mohou to být textové dokumenty (Word, PDF), tabulky (Excel), prezentace, e-mailová korespondence, zápisy ze schůzek, screenshoty obrazovek, ukázky stávajícího systému, anebo libovolná jejich kombinace. Rozsah kolísá od jednostránkového e-mailu po rozsáhlé sady dokumentů v řádu stovek stran.

Zadávací dokumentace je autoritativní zdroj pro fázi tvorby Funkčních požadavků. Po jejich vzniku se k ní analytik dále nevrací — Funkční požadavky se stávají jediným pracovním vstupem dalších etap AAF.

Rozlišující znaky¶

Externí původ. Zadávací dokumentace vzniká mimo AAF. Analytik ji nevytváří, ale přebírá. Případné úpravy probíhají v komunikaci se zadavatelem, ne přímou editací.
Heterogenita. Materiály mají různé formáty, různá období vzniku, různé autory a často různou míru aktuálnosti.
Nekonzistence. Materiály se mohou rozcházet, opakovat anebo si protiřečit. Sjednocení a vyhodnocení rozporů provádí analytik při tvorbě Funkčních požadavků (viz Postup).
Smíšená rovina. Zadávací dokumentace obvykle obsahuje vedle analytických požadavků také technologii (preferované platformy, integrace), implementaci (existující kód, datový model) a organizaci (procesy ve firmě zadavatele). Oddělení analytické roviny od ostatních je úkolem analytika.
Greenfield × Brownfield. V Greenfieldu Zadávací dokumentace vzniká pro daný projekt a obvykle drží novější informace. V Brownfieldu existuje historicky — bývá rozsáhlejší, mladší dokumenty mají přednost, část informací nese také živý systém (jeho dokumentace, zdrojový kód, datový model).

Funkční požadavky¶

Funkční požadavky jsou analytický artefakt, který vzniká transformací Zadávací dokumentace. Drží hrubé mantinely systému a slovní skicu toho, co systém má dělat. Jsou autoritativním vstupem pro další analytické etapy AAF.

Strukturně jsou Funkční požadavky slovní výpis — soubor formulací, z nichž každá vyjadřuje jednu schopnost systému anebo jedno omezení vůči systému. Formulace jsou krátké, věcné, na analytické úrovni; neobsahují technologii, implementační detaily ani organizační kontext zadavatele.

Funkční požadavky nejsou úplným popisem chování systému. Drží hrubé vymezení, uvnitř kterého se další analýza odehrává. Konkrétní průběhy interakce uživatele se systémem, datové struktury, scénáře alternativních cest a chybové stavy patří do dalších vrstev AAF (BPM, Use Cases, Class Model, scénáře).

Rozlišující znaky¶

Mantinely, ne výčet. Funkční požadavek vyjadřuje, co systém musí umět, aby byl akceptovatelný. Není výčtem všeho, co systém dělá — je výčtem podmínek akceptace.
Skica nahrubo. Funkční požadavek vystihuje podstatu krátkou slovní formulací. Nedetailizuje vstupní pole, výpočetní pravidla ani uživatelské role.
Analytická rovina. Funkční požadavky popisují užitky systému ve smyslu VBM — co systém přináší zadavateli a uživatelům. Technologie, implementace a organizace ze Zadávací dokumentace do Funkčních požadavků nepřecházejí.
Soběstačnost. Funkční požadavky jsou autoritativním vstupem dalších etap. Po jejich vzniku analytik dále nečerpá ze Zadávací dokumentace.
Iterativnost upřesnění. Detaily, které ve Funkčních požadavcích chybí, se rozkrývají v dalších vrstvách AAF. Chybějící detail není defekt Funkčních požadavků — je očekávaným stavem.

Technické okrajové podmínky¶

Technické okrajové podmínky jsou analytický artefakt, který drží technologická omezení s možným vlivem na funkční logiku systému. Vznikají vedle Funkčních požadavků a doplňují je o kontext, ve kterém budou Funkční požadavky realizovány.

Příklad: mobilní platba se odehrává v podmínkách nestabilní konexe. Mobil může být dočasně offline, platební brána může selhat, klient nemůže neomezeně čekat. Toto je technická okrajová podmínka. Vede k tomu, že Funkční požadavek „Systém umí přijmout platbu" se v BPM rozkládá na proces s gateway pro timeout, retry, fallback do offline režimu — chování, které z čistého Funkčního požadavku není zjevné, ale z technické okrajové podmínky vyplývá.

Technické okrajové podmínky nejsou totéž jako Nefunkční požadavky. Nefunkční požadavky jsou celé technologické zadání (cílová platforma, třívrstvá architektura, výkonové parametry, bezpečnostní pravidla). Technické okrajové podmínky jsou jejich užší podmnožinou — jen ta omezení, která mohou ovlivnit funkční logiku.

Rozlišující znaky¶

Možný vliv na funkční logiku. Okrajová podmínka je zajímavá tehdy, kdy z ní plyne změna v BPM, Use Case scénáři anebo Class Modelu. Pokud technologické omezení žádný vliv na funkční logiku nemá (například volba programovacího jazyka, barevné schéma UI), do Technických okrajových podmínek nepatří.
Modální tvar — „může". Okrajová podmínka popisuje možnost, ne jistotu („konexe může vypadnout", „platba může selhat", „uživatel může odejít před dokončením"). Funkční logika se připravuje na scénáře, kdy okrajová podmínka nastane.
Zdroj v Zadávací dokumentaci. Technické okrajové podmínky se extrahují ze Zadávací dokumentace, kde bývají formulované volně, někdy jen naznačené. Analytik je vytahuje stejným způsobem jako Funkční požadavky — destilací.
Vazba na Funkční požadavky. Každá Technická okrajová podmínka se vztahuje k jednomu anebo více Funkčním požadavkům. Bez vazby na Funkční požadavek je okrajová podmínka osamocená a do analýzy nezasahuje.
Vstup do BPM. Technické okrajové podmínky se v BPM projeví jako gateway, větvení, alternativní toky a časové eventy. BPM bez zohlednění Technických okrajových podmínek by modeloval pouze „šťastnou cestu".

Nejčastější chyby¶

Formulace v Zadávací dokumentaci nejsou zadáním. Je to chyba PO. Analytik by měl upozornit a nechat opravit. Věty se netýkají zadání pro IS, ale popisují okolí anebo jiné nesouvisející věci. Důsledek: Zadávací dokumentace ztrácí v těcot větách svůj význam, může to vést ke kolizím v akceptacích.
Funkční požadavky jako úplná specifikace. Pokus o úplný popis chování systému ve fázi Funkčních požadavků. Důsledek: Detailizace v této fázi vede k nesrovnalostem mezi prvky. Musí se postupovat dalšími fázemi AAF, které zajišťují konzistenci vyvíjeného systému.
Popis technologie a implementace. Přenos preferovaných platforem, integrací a kódových konstrukcí ze Zadávací dokumentace do Funkčních požadavků. Důsledek: Nezadává se "co se požaduje" jako funkcionalita, ale technologické "jak se implementuje". Dokument bobtná balastem.
Návrat ke Zadávací dokumentaci v pozdějších etapách. Použití Zadávací dokumentace jako pracovního vstupu v BPM, Use Cases, Class Modelu vede ke zpomalování prací a k návratu do případných nekonzistencí v Zadávací dokumentaci. Přichází se tak o výhody zpracovaného "destilovaného" dokumentu Funkční požadavky.
Záměna Technických okrajových podmínek s Nefunkčními požadavky. Přenos celého technologického zadání (cílové platformy, architektury, výkonových parametrů) do Technických okrajových podmínek. Důsledek: Artefakt bobtná balastem bez vlivu na funkční logiku. Do Technických okrajových podmínek patří jen ta omezení, ze kterých plyne změna v BPM, Use Case scénáři anebo Class Modelu.

Vazby¶

TBD

Verze a změny¶

1.0 — první verze kapitoly, zavedení pojmů Zadávací dokumentace, Funkční požadavky a Technické okrajové podmínky.