Sloučení stavů a API v systémové analýze

Syntéza artefaktů systémové analýzy: stavový model, use cases a API v jednotné struktuře

V systémové analýze slouží uživatelské příběhy (User Stories) jako výchozí požadavky. Na jejich základě se vyvíjejí stavové modely, API a scénáře použití (Use Cases). Klasický přístup však často vytváří rozptýlené artefakty: obchodní týmy se zaměřují na scénáře, vývojáři na koncové body (endpointy) a testerové na testovací případy. Navrhovaný přístup tyto prvky sjednocuje do jednotného stavového modelu s jasným mapováním na API — tak vznikne společná, srozumitelná vizualizace celého procesu pro všechny role.

Pro ilustraci si vezmeme syntetický příklad systému pronájmu cloudové infrastruktury. Zákazník nejprve odhadne náklady, pak podá žádost, projde automatickým hodnocením rizika (scoringem), provede platbu a nakonec získá přidělené prostředky.

Klíčové uživatelské příběhy

Zainteresované strany poskytly následující uživatelské příběhy:

| Č. | Název | Popis |

|---|----------|----------|

| US-1 | Odhad nákladů na infrastrukturu | Jako potenciální zákazník chci odhadnout náklady na cloudovou infrastrukturu podle svých požadavků, abych zjistil, zda mi tento poskytovatel vyhovuje a zda se vejdou do mého rozpočtu |

| US-2 | Podání žádosti na základě odhadu | Jako registrovaný a ověřený zákazník chci podat žádost o nasazení infrastruktury na základě dříve vytvořeného odhadu, abych nemusel znovu zadávat parametry a mohl rychle přejít k platbě |

| US-3 | Automatické hodnocení rizika a schválení žádosti | Jako systém fakturace chci automaticky hodnotit rizika nových žádostí a rozhodnout, zda je nutné ruční schválení, abych zrychlil zpracování důvěryhodných zákazníků a minimalizoval riziko nesplacení |

| US-4 | Vystavení faktury a platba | Jako zákazník, který podal schválenou žádost, chci získat fakturu a zaplatit ji pohodlným způsobem, abych aktivoval objednanou infrastrukturu a mohl ihned začít pracovat |

| US-5 | Automatická aktivace infrastruktury | Jako systém poskytovatele cloudové infrastruktury chci automaticky nasadit prostředky po potvrzení platby, aby zákazník získal přístup bez prodlev a bez nutnosti ručního zásahu |

Tyto příběhy definují aktory a cíle a tvoří základ pro stavový model.

Stavový model procesu

Na základě uživatelských příběhů jsou identifikovány stavy životního cyklu žádosti:

• QUOTE_CREATED — Odhad nákladů uložen, komerční nabídka vytvořena.
• ORDER_SUBMITTED — Žádost podána, čeká na hodnocení rizika.
• UNDER_REVIEW — Žádost je na ručním schválení manažera.
• APPROVED — Žádost schválena (automaticky nebo manažerem).
• REJECTED — Žádost zamítnuta (s uvedením důvodu).
• INVOICE_ISSUED — Faktura vytvořena a odeslána zákazníkovi.
• PAID — Platba úspěšně přijata.
• EXPIRED — Faktura nezaplacena v termínu, žádost zrušena.
• PROVISIONING — Probíhá nasazování infrastruktury.
• ACTIVE — Infrastruktura je aktivní, přístupová práva přidělena.
• FAILED — Chyba při nasazování, v systému podpory vytvořen ticket.

Stavy tvoří „kostru“ artefaktu a skupinově shrnují funkční scénáře.

Scénáře použití a jejich integrace

Use Cases zabalují funkcionalitu fakturačního systému. Jejich integrace spojuje scénáře se stavy a API koncovými body. Struktura artefaktu zahrnuje:

• Obchodní logiku: Postup kroků scénářů podle stavů.
• Stavy systému: Stavový model jako základní rámec.
• Technickou implementaci: Přiřazení koncových bodů k jednotlivým Use Cases.

Příklad mapování: přechod ze stavu ORDER_SUBMITTED do APPROVED pomocí volání POST /score-order, následně PUT /approve-order.

Výhody jednotné integrace

Tento artefakt řeší problém rozptylu abstrakcí mezi jednotlivými týmy:

• Pro obchodní týmy: Vizuální prezentace scénářů ve stavech, sledování kroků a přechodů během demo setkání.
• Pro vývojáře: Kontext API v rámci životního cyklu, propojení scénářů použití se stavy a technickými specifikacemi.
• Pro testery: Základ pro testovací případy – pokrytí přechodů mezi stavy i koncovými body, včetně alternativních toků.
• Pro manažery: Kontrolní seznam implementace – označení dokončených API a stavů.

Co je klíčové

• Jednotná integrace stavů, scénářů použití a API harmonizuje chápání procesu mezi všemi rolemi bez nutnosti dalších nástrojů.
• Stavový model funguje jako kostra, která sdružuje obchodní scénáře i technické koncové body.
• Artefakt urychluje návrh testů, vývoj i akceptační testování a minimalizuje rozdrobenost dokumentace.
• Je vhodný pro projekty s komplexní logikou — nepodléhá nahrazení existujících artefaktů, ale je s nimi propojuje.
• Praktické zkušenosti potvrzují jeho užitečnost při setkáních se zainteresovanými stranami i interními týmy.

Praktická implementace

Artefakt se vytváří jako strukturovaná tabulka nebo graf v nástrojích jako Draw.io, Confluence nebo Markdown. Začíná se uživatelskými příběhy, postupně se přidávají stavy, mapují se scénáře použití a API. V reálném projektu jsme ho použili k harmonizaci zainteresovaných stran: dokument jsme otevřeli, prošli jsme řetězcem stavů a postupně označovali implementované části. To snížilo míru nedorozumění o 30–40 % podle subjektivního hodnocení týmu.

— Editorial Team