Oblast Analýza hodnotí analytické procesy a kvalitu specifikace. Nevychází z kódu, ale z projektové dokumentace — Confluence i docs-as-code (Markdown v repozitáři).

Zdroj a rozsah

Vyhodnoceno z Confluence prostoru „TF Platform" a ze specifikace v repozitáři (docs-as-code). Položky typu „dodržování v praxi" (provázání tiketů se specifikací, reálný přístup klienta) vyžadují navíc přístup k Jira a rozhovor — u nich uvádíme ➖. U auditu vašeho systému by šlo o obdobný přístup k vaší Confluence a Jira.

📊 Skóre (analytické procesy)

Stav	Počet
🟢 OK	3
🟠 Částečně	5
🔴 Špatně	1
➖ Mimo rozsah (Jira/rozhovor)	1

Celkově: analytické procesy jsou nadprůměrně formalizované — popsaný proces změnového řízení s odpovědnou osobou, standard funkční specifikace i konvence psaní. Specifikace navíc existuje pro všechny hlavní aplikace a u nejlépe zpracovaných částí je velmi kvalitní. Hlavní mezery: zcela chybí nefunkční požadavky a není verzování specifikace.

🔍 Co jsme hodnotili — procesy

#	Položka	Stav
1	Odpovědný analytik / owner specifikace	🟢
2	Popsaný proces změnového řízení	🟢
3	Popis rolí a oprávnění	🟢
4	Změny ve specifikaci označované a verzované	🟠
5	Odkaz na grafické podklady + platná verze designu	🟠
6	Specifikace revidovaná, odpovídá stavu systému	🟠
7	Single source of truth + přístup týmu/klienta	🟠
8	Soulad obsahu specifikace s metodikou/standardem	🟠
9	Nefunkční požadavky součástí specifikace	🔴
10	Každý tiket na vývoj má odkaz na specifikaci	➖

📋 Kvalita specifikace

Samostatný rozbor kvality obsahu funkční specifikace (nezávisle na procesu):

#	Kritérium kvality	Stav
S1	Pokrytí — specifikace existuje pro všechny hlavní aplikace	🟢
S2	Provázanost a dohledatelnost (oprávnění, design, křížové odkazy)	🟢
S3	Úplnost struktury (slovník, doménový model, role, procesy)	🟠
S4	Detail obrazovek (wireframe, procesy, data, validace)	🟠
S5	Aktuálnost obsahu (datováno, published, odpovídá systému)	🟠

📌 Klíčové nálezy

🟢 Formalizovaný proces změnového řízení

Existuje kompletně popsaný proces zadávání a schvalování požadavků (zadání přes Slack/Jira „Change request" → vyhodnocení odpovědnou osobou → sepsání dokumentace a implementačního ticketu → nacenění → předání vývoji), včetně povinné struktury zadání (KDE / PROČ / JAK). Analýzu má na starosti jmenovaná osoba.

🟢 Specifikace existuje a je dobře provázaná

Funkční specifikace pokrývá všechny tři klíčové aplikace (TF-ADM, TF-ERP, TF-HUB) — u převzatých systémů vzácnost. Je i dobře provázaná: oprávnění jsou centralizovaná na jedné stránce, na kterou se jednotlivé obrazovky odkazují, a stránky odkazují na grafické podklady (Balsamiq).

🟠 Kvalita obsahu je nerovnoměrná — vzorem je TF-ADM

Nejlépe zpracovaná je TF-ADM: úplná funkční specifikace (slovník pojmů, doménový model, role a práva, hlavní procesy) doplněná o ~20 detailních stránek jednotlivých obrazovek. Každá stránka drží stejnou kostru — wireframe, validace, popis procesů a datová tabulka (pole, typ, poznámka) — je datovaná a ve stavu published (07/2026). To je ukázková úroveň funkční specifikace.

Oproti tomu TF-ERP má obsahově slušnou, ale méně strukturovanou specifikaci (Confluence, 04/2026) a TF-HUB je znatelně slabší a starší (2024). Kvalita tedy silně závisí na aplikaci — chybí jednotná úroveň detailu napříč produktem.

🟠 Chybí verzování změn

Změny ve specifikaci nejsou verzované nad rámec nativní historie stránek (žádný changelog / „co a proč se změnilo", u designu není označena platná verze). U předávaného systému to ztěžuje pochopení vývoje rozhodnutí.

🔴 Nefunkční požadavky zcela chybí

Standard funkční specifikace neobsahuje nefunkční požadavky (výkon, bezpečnost, škálovatelnost, dostupnost) — žádná z povinných částí je nepokrývá a nejsou ani ve vzorových stránkách. Významná mezera pro předatelnost i pro odhad rizik.

➖ Provázání tiketů se specifikací — nutno ověřit z Jira

Proces uvádí zakládání implementačních ticketů, ale reálné provázání „každý vývojový tiket → analýza" lze ověřit jen v Jira.

✅ Doporučení

Priorita	Doporučení
Vysoká	Doplnit nefunkční požadavky do standardu i do specifikací klíčových modulů.
Vysoká	Sjednotit úroveň detailu specifikace napříč aplikacemi (dotáhnout ERP a zejm. HUB na úroveň TF-ADM).
Střední	Zavést verzování specifikace (changelog / označení platné verze designu).