Zadávací dokumentace a její destilát (Funkční požadavek, Technologický požadavek, Mimo, Neurčeno)¶

Úvod¶

AAF zavádí pro úvodní práce na projektu Zadávací dokumentaci jako vstup a její destilát jako první analytický výstup. Destilace je řízený převod vstupních materiálů zadavatele na strukturovaný výpis, se kterým analytik dále pracuje místo původních zdrojů — metafora „sirup": destilát se vytvoří jednou a dál se čerpá z něj, ne z původní dokumentace.

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.

Destilace každou formulaci ze Zadávací dokumentace zařadí dvouúrovňovou logikou určeno / neurčeno:

Určeno — u formulace lze jednoznačně rozhodnout, kam patří. Má tři výsledky: Funkční požadavek, Technologický požadavek, Mimo.
Neurčeno — jednoznačně rozhodnout nelze (spor mezi zdroji, nejednoznačnost, otevřená otázka zadání). Formulace se nezařadí silou — stane se otázkou pro Product Ownera.

Ze čtyř výsledků jsou požadavky dva — Funkční a Technologický. Zbývající dva drží to, co k požadavkům nepatří: Mimo (s jistotou mimo rozsah systému) a Neurčeno (nerozhodnuté, čeká na člověka).

Oba typy požadavků se rozlišují podle úrovně abstrakce (viz kapitola o úrovni abstrakce AM/Design):

Funkční požadavek vyjadřuje, co systém dělá — čistou logiku užitku na úrovni analytického modelování (AM).
Technologický požadavek vyjadřuje, v čem a jak systém běží — realizaci, provozní rámec a technologická omezení na straně Design. V běžné praxi se mu říká nefunkční požadavek; AAF volí pozitivní název podle toho, co pojem je, ne co není.

Neurčeno je pojistka determinismu destilace. Destilace slibuje jednoznačný výsledek; když ho u konkrétní formulace dát nemůže, nevymýšlí si — otázku viditelně předá člověku. Je to obdoba výjimky (Error) v programu: raději hlášená otázka než tichý dohad.

Ruční transformace Zadávací dokumentace na destilát 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ě destilátu. 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 destilace. Po vzniku destilátu se k ní analytik dále nevrací — destilát (především Funkční požadavky) se stává 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 destilaci — spor, který nelze rozhodnout, se stává Neurčeno.
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 technologické a od okolí je právě úkolem destilace (rozklad na Funkční požadavek, Technologický požadavek, Mimo).
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žadavek¶

Funkční požadavek je položka destilátu na straně čisté logiky užitku. Jedna položka vyjadřuje jednu schopnost systému anebo jedno omezení vůči systému, na analytické rovině. Souhrn Funkčních požadavků drží hrubé mantinely systému a slovní skicu toho, co systém má dělat.

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).

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 akceptace: „bez automatického výpočtu výplat lektorů systém neakceptujeme"). Neříká ale jak — kolik vstupních polí, jaká pravidla zaokrouhlování, kdo formulář schvaluje. To přijde v dalších vrstvách AAF.

Rozlišující znaky¶

Mantinel, 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. Vystihuje podstatu krátkou slovní formulací. Nedetailizuje vstupní pole, výpočetní pravidla ani uživatelské role.
Analytická rovina (AM). Funkční požadavky popisují užitky systému ve smyslu VBM — co systém přináší zadavateli a uživatelům. Realizace (v čem a jak se systém postaví) do Funkčního požadavku nepřechází — patří do Technologického požadavku.
Byznysová podmínka je funkční, i když větví. Podmínka, kterou si systém sám vede (podpis smlouvy, storno, stav rezervace či přihlášky), je čistá logika — Funkční požadavek — i když obsahuje „pokud" a větvení. Nespadá do Technologického požadavku jen proto, že „zní technologicky" nebo obsahuje větvení.
Soběstačnost. Funkční požadavky jsou po potvrzení autoritativním vstupem dalších etap. 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ího požadavku — je očekávaným stavem.

Technologický požadavek¶

Technologický požadavek je položka destilátu na straně realizace a technologie (Design). Jedna položka vyjadřuje jeden požadavek technologického rázu — vlastnost realizace, provozní mantinel nebo omezení prostředí, které systém musí splnit, aby byl akceptovatelný. Odpovídá na otázku „v čem a jak systém běží, za jakých technologických podmínek".

Technologický požadavek je širší než jen omezení, která zasahují do funkční logiky. Pokrývá celou stranu Design — vše, co po hranici AM/Design neprojde jako čistá analytická logika a přitom je to skutečný požadavek v rozsahu (ne otevřená otázka).

Příklad provozního rámce, který zasahuje do funkční logiky: 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. To je Technologický požadavek (provoz a prostředí, dostupnost). 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 a fallback do offline režimu — chování, které z čistého Funkčního požadavku není zjevné, ale z Technologického požadavku vyplývá.

Subškatulky¶

Každý Technologický požadavek je zařazen do právě jedné subškatulky z pevného (řízeně rozšiřitelného) výčtu, nebo do ventilu Nezařazeno:

Výkon a kapacita — rychlost, odezva, SLA; objem a růst dat; limity CPU/RAM/I/O; škálovatelnost.
Dostupnost a spolehlivost — vysoká dostupnost, failover, redundance; odolnost proti chybám; zálohy a obnova.
Bezpečnost a soulad — šifrování, řízení identit a přístupu, auditní stopa, ochrana proti útokům; soulad s předpisy (GDPR, ISO, NÚKIB, eIDAS).
Integrace a konektivita — technický způsob propojení s okolními systémy (API, messaging); typy sítí a propustnost.
Architektura a nasazení — vrstvení a moduly, cloud versus on-premise, virtualizace a kontejnery, databázová architektura, způsob nasazení a migrace, konfigurovatelnost.
Provoz a prostředí — provozní režim (nepřetržitý, dávkový, v reálném čase), monitoring a logování, geografické a síťové rozmístění.
Kompatibilita prostředí — podporované operační systémy, prohlížeče a zařízení, responzivita, offline režim.
Kvalita a udržovatelnost — testovatelnost, udržovatelnost a modularita, verzování a rollback.
Ekonomické limity — náklady, licence, provoz (TCO); energetická náročnost; životnost a obměna.
Nezařazeno — technologický požadavek, který zatím nesedí do žádné škatulky (ventil, ne chyba).

Rozlišující znaky¶

Strana Design. Technologický požadavek se týká realizace a provozního rámce, ne logiky užitku.
Mantinel akceptace. Podmínka technologického rázu, bez jejíhož splnění systém neakceptujeme.
Skica nahrubo. Krátká formulace; konkrétní hodnoty (limity, verze, prahy) jsou technologický detail, ne součást formulace.
Jedna věta zdroje může dát schopnost i obálku. Z jedné věty mohou vzniknout dvě samostatné položky vedle sebe — schopnost (Funkční požadavek) a její technologická obálka (Technologický požadavek). Například „hromadné přihlášení v řádu tisíců" → Funkční požadavek „umí hromadné přihlášení" a Technologický požadavek „musí unést objem tisíců".
Některé technologické požadavky zasahují do funkční logiky. Provozní rámce jako výpadky konexe, timeouty nebo selhání brány se v BPM projeví jako gateway, větvení, alternativní toky a časové eventy. BPM bez zohlednění těchto Technologických požadavků by modeloval jen „šťastnou cestu". Proto analytik čte při návrhu BPM Funkční i Technologické požadavky společně.

Mimo¶

Mimo je formulace ze Zadávací dokumentace, o které destilace s jistotou ví, že nepatří do rozsahu systému — patří okolí, ne našemu systému. Typicky: motivace a marketing, cizí činnost nebo cizí systém či oddělení, budoucí rozšíření mimo tuto verzi, odkaz na jinou kapitolu zadání.

Mimo je rozhodnutý výsledek (strana určeno), ne „nevím". Z pohledu požadavků je to balast — ale balast, o kterém destilace s jistotou ví, že je balast. Formulace se nezahazuje: eviduje se se zněním a původem, jen mimo rozsah. Tím se liší od Neurčeno, kde destilace poctivě neví.

Rozlišující znaky¶

Určeno, s jistotou. Do Mimo patří jen to, co je mimo rozsah s jistotou (proti potvrzenému předmětu systému).
Není požadavek. Není Funkční ani Technologický požadavek — patří ven, ne do modelu systému.
Není zahozeno. Je evidováno (znění, původ, krátký důvod), aby bylo dohledatelné, proč věc do systému nevstoupila.
Hranice s Neurčeno. Když si destilace není jistá, zda věc patří dovnitř nebo ven (nerozhodnutý rozsah), není to Mimo — je to Neurčeno a rozhodne Product Owner.

Neurčeno¶

Neurčeno je otázka, u které algoritmus destilace poctivě neumí rozhodnout, a proto ji předává člověku (Product Ownerovi). Je to výjimka (Error) algoritmu determinismu: systém slibuje jednoznačný výsledek, a když ho dát nemůže, nevymýšlí si — vyhodí otázku. Neurčeno je viditelný signál „tady si netroufám, rozhodni ty".

Zahrnuje spor mezi zdroji, nejednoznačnost, případy, kdy zadání samo věc nechává otevřenou („zatím nerozhodnuto", „je otázkou"), a hraniční případy, kdy je jedna a tatáž formulace dvojznačná mezi Funkčním a Technologickým požadavkem (dva analytici by se přeli).

Neurčeno není formulace se zněním — je to otázka. Proto nese popis otázky (ne doslovné znění položky; někdy je to poznámka o zadání, například „specifikace je neúplná"), stav (otevřeno / vyřešeno) a původ pro dohledatelnost.

Rozlišující znaky¶

Nevím, ne balast. Neurčeno = „nevím, rozhodni ty". Liší se od Mimo („vím, že je to mimo") i od tří určených výsledků, kde destilace verdikt má.
Není požadavek. Je to otázka, ne přijatý požadavek — do modelu systému nevstupuje, dokud ji Product Owner nerozhodne.
Determinismus se nefalšuje. Hraniční a sporné se nezařazuje náhodně jen proto, aby „něco vyšlo". Nevím se nepředstírá.

Nejčastější chyby¶

Zbytnělá Zadávací dokumentace. Velké množství vět mimo zadání IS (popisují okolí nebo nesouvisející věci). Destilace je zachytí jako Mimo, ale jejich objem signalizuje chybu na straně Product Ownera. Analytik upozorní a nechá zadání pročistit — jinak Zadávací dokumentace ztrácí význam a hrozí kolize v akceptacích.
Funkční požadavek jako úplná specifikace. Pokus o úplný popis chování systému už ve fázi destilátu. Důsledek: předčasná detailizace vede k nesrovnalostem mezi prvky. Konzistenci zajišťují až další fáze AAF (BPM, Use Cases, Class Model, scénáře).
Míchání úrovní abstrakce ve Funkčním požadavku. Realizace, technologie nebo implementace vepsaná do formulace Funkčního požadavku (preferovaná platforma, framework, propojení). Náprava: není to balast k zahození — patří do Technologického požadavku. Funkční požadavek drží čistou logiku užitku (AM).
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 nebo Class Modelu. Důsledek: zpomalení prací a návrat do případných nekonzistencí zdrojů. Přichází se tak o výhodu destilovaného vstupu.
Předstírané rozhodnutí místo Neurčeno. Násilné zařazení sporné nebo dvojznačné formulace do Funkčního nebo Technologického požadavku, jen aby „něco vyšlo". Náprava: hraniční a sporné patří do Neurčeno jako otázka pro Product Ownera. Determinismus destilace se nefalšuje dohadem.
Záměna Mimo a Neurčeno. Formulace, u které destilace neví, zda patří do systému, zařazená jako Mimo (nebo naopak). Náprava: Mimo je „vím, že je to mimo"; Neurčeno je „nevím, rozhodni ty". Rozhoduje míra jistoty, ne podobnost formulace.

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.
2.0 — přechod na dvouúrovňovou logiku destilátu určeno / neurčeno. Pojem Technická okrajová podmínka nahrazen širším pojmem Technologický požadavek (celá strana Design se subškatulkami; dřívější „okrajová podmínka" je jen jeden z jeho projevů — technologický požadavek zasahující do funkční logiky). Zavedeny pojmy Mimo (s jistotou mimo rozsah) a Neurčeno (otázka pro Product Ownera, výjimka determinismu). Řez Funkční × Technologický požadavek postaven na hranici abstrakce AM/Design.