Use Case Diagram

Tento diagram modeluje interakci mezi tzv. aktérem (actor) a systémem.  Digram je na pohled velmi jednoduchý, obsahuje aktéry propojené s případy užití (use case) a znázorněné hranice systému (system boundaries).

Aktér je role uživatele v systému. Aktérem tedy není konkrétní osoba jako je třeba pan Josef Novák, ale role v systému, například skladník, účetní, prodavač. Jedna konkrétní osoba může mít v systému více rolí. Danou roli může zastávat (a obvykle také zastává) více konkrétních osob. Je dobré také vědět, že pro účely tohoto diagramu chápeme aktéra jako jakoukoliv vnější entitu z pohledu vyvíjeného systému. Nedejte se proto zmást symbolem aktéra v diagramu (panáček). Externí systém, který nějakým způsobem využívá ten náš, je také aktér.

Každý případ užití má název. Název by měl být výstižný a jasný a měl by se vztahovat skutečně k činnosti prováděné informačním systémem.

Příklad:

"Generování dokumentu" -  není jasné o co se jedná. O jaký dokument jde? Co lze představit pod pojmem generování?


"Zaslání vytištěného dokumentu" - název zahrnuje činnosti, které jsou pravděpodobně mimo případ užití. Opravdu bude systém zasílat poštou vytištěný dokument? Systém pravděpodobně spíše dokument pouze vytiskne, zaslání bude prováděno patrně manuálně.

Pro přehlednost je dobré případy užití očíslovat, každému přiřadit unikátní identifikátor.  Lze se pak bavit o UC03 a všichni jednoznačně ví, o jaký případ užití se jedná. Diagram se dá mírně zkomplikovat s využitím vztahů include a extend, ale v zásadě je velmi jednoduchý a snadno pochopitelný i pro nezkušené uživatele a pro zákazníka.

Nejdůležitější je u případu užití popis - scénář případu užití, který specifikuje danou interakci a to obvykle následující formou:

1. Uživatel něco udělá.
2. Systém něco udělá.
3. Uživatel něco udělá.
4. Systém něco udělá.

Kromě hlavního scénáře, mohou existovat ještě alternativní scénář/scénáře, případně se hlavní scénář může rozvětvit o podmínky tak, aby byl v jednom scénáři zahrnut i alternativní průběh.  Já osobně používám obvykle jen jeden scénář, který pak vypadá třeba následovně:

1. Systém zobrazí výzvu k zadání uživatelského jména a hesla.
2. Uživatel zadá uživatelské jméno a heslo a zadané údaje potvrdí.
3. Systém ověří, zda je zadáno platné uživatelské jméno a zda heslo odpovídá platnému heslu pro zadané uživatelské jméno.
4. KDYŽ je ověření neúspěšné PAK systém zobrazí chybu "Přístup zamítnut." a pokračuje krokem 1.
5. Systém zobrazí úvodní obrazovku.

Dále je v některých případech vhodné zařadit do případu užití ještě vstupní podmínky. Ty definují, co musí být splněno, aby bylo možné případ užití provést. Například pro případ užití "Výběr hotovosti" musí být v bankomatu dostatečná hotovost. Naopak výstupní podmínky definují, co bude splněno po dokončení případu užití.

Diagramy a analýza

Jedno čínské přísloví prý tvrdí, že jeden obrázek nahradí tisíc slov. Pojďme se proto podívat, jaké diagramy business analytik využije a k čemu je možné je použít. Na úvod bych zmínil zkratku UML (Unified Modelling Language). UML je celosvětový standard pro modelování informačních systémů. Vznikl původně z různých metodik pro objektovou analýzu a vývoj informačních systémů. Tento standard definuje několik (ve verzi 2.x celkem 14) diagramů, z nich část je vhodná pro použití business analytikem. UML se postupně vyvíjí a rozšiřuje, momentálně je ve verzi 2.4, jeho vývojem se zabývá skupina OMG (Object Management Group).

Pro analytika je vhodné se se standardem UML seznámit a podrobněji prozkoumat možnosti a použití jednotlivých diagramů. Na znalost standardu UML je možné získat také cerfikaci a to ve třech stupních (Fundamental, Intermediate, Advanced), přičemž podmínkou certifikace na vyšší úroveň je zvládnout nižší úroveň certifikace. Otázkou je, zda má tato certifikace pro analytika smysl. Rozhodně je certifikace dobrá do CV (profesního životopisu), úspěšné absolvování prokazuje, že ho UML něco víte. Na druhou stranu si ale nemyslím, že by tato certifikace byla pro analytika nutná.

V následujících příspěvcích bych chtěl představit základní diagramy standardu UML, které analytik využije:                                                              

• Use Case Diagram 
• State Machine Diagram
• Activity Diagram
• Class Diagram

Samozřejmě se jedná o můj výběr diagramů. Netvrdím, že analytik nemůže použít i jakýkoliv diagram ze 14 diagramů, které jsou zahrnuty ve standardu UML, nebo že je chyba pokud v analýze nepoužívá některý z vyjmenovaných.

Ono se to nějak přizpůsobí...

Způsoby dosažení cíle, který spočívá ve vytvoření nového informačního systému,jsou různé. Jednou z možností je využití typového aplikačního software. Je to celkem silné lákadlo. Typový aplikační software už část požadované funkčnosti  obsahuje. Navíc za ním většinou stojí nějaká velká, známá a bohatá firma. Zdá se tedy, že rizika implementace nejsou tak vysoká jako při vývoji úplně nového systému.

Obchodníci potenciálního dodavatele tvrdí, že tento typový software je ideální řešení Vašich potřeb, které už při základním nastavení pokrývá toto řešení 80% funkcionality a zbytek se během několika týdnů přizpůsobí na míru. Něco bude potřeba možná doprogramovat, ale bude toho opravdu jen málo... Tento systém používají ty největší celosvětové firmy a teď má i Vaše firma jedinečnou možnost začít používat "powerfull solution", které je "enterprise worldwide standard". Lze to podpořit celou řadou prezentací, kde jsou pěkné barevné grafy se strmě rostoucí výnosy, nebo naopak se strmě klesajícími náklady firem, který tento software již používají. Vypadá to skvěle.

Někdy se až v průběhu implementace zjistí, že typový software pokrývá jen menší část požadované funkcionality. Část funkcionality řešení v nějaké formě také obsahuje, ale je třeba provést přizpůsobení potřebám firmy, což je drahé a časově náročné. Případně se zvolenému řešení musí přizpůsobit procesy firmy, což může být problém, zvlášť pokud musíte vysvětlovat zákazníkům, že "takhle to bohužel nejde, protože takhle to nemůžu zadat do počítače".

Proto je i v případě typového software potřeba důkladná analýza požadavků, která určí, co firma potřebuje ve svém informačním systému provádět a zda to nabízený typový software skutečně umožňuje a jak. Zkrátka typový software rozhodně není řešení pro ty, kteří nevědí co vlastně chtějí a potřebují, ale spíš pro ty, kteří si jsou jisti, že chtějí to, co typový aplikační software nabízí.    

Zpracování požadavků (pokračování)

Zaznamenáním požadavků práce analytika nekončí. Je třeba:

1) ověřit obsah požadavků

Ověření požadavků by mělo odpovědět na otázku, zda analytik pochopil požadavky správně. Ověření požadavků se provádí na analytických schůzkách a také akceptací analytických dokumentů. Důležité je, aby další práce probíhala nad poslední verzí daného požadavku, kterou zadavatel akceptoval. Zní to jako samozřejmost, ale není.

Volal mi jeden z uživatelů. Změnu stavu soudního řízení nelze uložit, pokud nezadá datum nabytí právní moci. A to je špatně a představuje to výrazný problém... Volám proto dodavateli s tím, že v poslední akceptované specifikaci požadavku je uvedeno, že změnu stavu bude možné uložit i bez vyplnění data nabytí právní moci a to na straně 54.  Na straně 54 podle dodavatele údajně nic takového není, naopak na straně 45 je, že při uložení musí být vyplněné datum právní moci. Ve specifikaci požadavku, kterou mám k dipozici já, je ovšem na straně 45 něco úplně jiného, co s daným problémem nesouvisí. Takže zjišťuji, že poslední akceptovaná verze je 1.4 a implementace probíhala nad verzí 1.6, kterou ovšem nikdo ze zadavatelů neodsouhlasil.

2) ověřit prioritu jednotlivých požadavků

Priorita požadavku se může časem měnit. Je proto dobré po získání všech požadavků provést ověření priority. Může se také stát, že daný požadavek je už neaktuální, jen o tom analytika nikdo neinformoval.                    

3) vyřešit vzájemnou závislosti požadavků

Požadavek R1 koliduje s požadavkem R2. Realizace požadavku R3 nemá smysl bez realizace R2. Je tedy třeba určit co s tím a závislosti mezi požadavky zaevidovat (ideálně v CASE nástroji).

4) zajistit "trasovatelnost"  požadavku

Požadavek by měl být vysledovatelný v průběhu celého vývoje informačního systému. Používá se pro to pojem "trasovatelnost". Požadavek je rozpracován formou analytických modelů, na které navazují testovací scénáře a implementace požadavku v informačním systému. V ideálním případě to funguje tak, že pro každý kus kódu informačního systému je možné najít požadavek,na základě kterého byl vytvořen.

Pracoval jsem na analýze poměrně komplexního systému pro velkou banku. Systém byl nasazen a úspěšně využíván více než rok. Po roce si jeden ze zadavatelů všiml, že jedno z pravidel implementovaných v daném systému nedává příliš smysl. A bohužel se objevila i snaha přenést problém na dodavatele tj. na mě a moje kolegy. Díky trasovatenosti požadavků ovšem nebyl žádný problém nalézt na základě jakého požadavku bylo pravidlo implementováno, kdo a kdy ho zadal a dokonce nalézt původní email, kde tento zadavatel požaduje implementaci daného pravidla.  

5) spolupráce s vývojáři, testery, dokumentaristy

Analytik má informace, které zaznamenal formou modelu a analytických dokumentů. Ovšem nikdy nic není úplně dokonalé. Je potřeba počítat s tím, že i k té nejdokonalejší analýze budou existovat dotazy. Analytik by měl v průběhu vývoje spolupracovat s vývojáři, testery i dokumentaristy. Pokud analytik mizí z projektu (obvykle na jiný projekt) ve chvíli, kdy vývojáři teprve začínají zjišťovat, co mají dělat, lze čekat problémy.  

Zpracování požadavků

Po analytické schůzce následuje zpracování získaných požadavků. Cílem je, zpracovat požadavky tak, aby bylo i osobám, které se analytické schůzky nezúčastnili zcela jasné:

1) k čemu daný požadavek slouží
Jde o identifikaci toho, co daný požadavek z business pohledu řeší. Jde o identifikaci potřeby.


Například požadavek "Systém by měl evidovat číslo mobilního telefonu zákazníka." může být vyvolán potřebou zvýšit informovanost zákazníků o sezónních marketingových akcích. Díky tomu, že analytik ví, proč je daná věc požadována může zvážit i jiné možnosti řešení dané potřeby. Například lze navíc i informace o marketingových akcích zveřejňovat prostřednictvím sociálních sítí, zasílat zákazníkům prostřednictvím emailu.

2) co je jeho obsahem
Obsah požadavku je obvykle poměrně obtížné přesně specifikovat. Na nejvyšší úrovni si vystačíme s popisem "Systém by měl umožnit zákazníkovi zadat objednávku zboží". Pro detailnější zpracování požadavku bude třeba specifikovat:

• jak probíhá komunikace uživatele se systémem (use case model)
• jak probíhá zpracování objednávky (activity diagram)
• jaké jsou stavy objednávky a jaké jsou mezi nimi přechody (state chart)
• ...

3) souvislost s ostatními požadavky
Požadavek může být závislý na realizaci jiném požadavku, může s nějakým požadavkem souviset (aniž by byl závislý na jeho realizaci), případně může být  jiným požadavkem v rozporu. .

4) priorita daného požadavku
Priorita je důležitá věc, zejména v případě, pokud se zjistí, že požadavků je moc a zdrojů (peněz, lidí) případně času je málo. Osobně jsem ještě nikdy nepracoval na projektu, kde by tato situace nenastala.

Rozumné je členění požadavků do tří kategorií:

• must have - bez těchto požadavků nemá realizace daného systému smysl
• should have - důležité požadavky, bez kterých ale může systém nějakým způsobem fungovat 
• could have - požadavky, které by bylo dobré implementovat, ale lze se bez nich obejít bez větších potíží

Problémem občas bývá, že zadavatel považuje naprosto všechny pořadavky za must have. Vhodné je pak použít metodu párového srovnání a vytvořit pořadí požadavků podle jejich důležitosti.

5) kdo daný požadavek zadal
Evidence toho, kdo požadavek zadal může vypadat jako samozřejmost, ale v realitě tato informace mnohdy chybí. Těžko se pak zjišťuje, zda je daný požadavek ještě aktuální.

Samozřejmě tohle jsou jen základní informace týkající se požadavků. Na větších projektech bude třeba evidovat v jaké fázi řešení je daný požadavek (rozpracovaný, schválený, implementovaný, otestovaný, nasazený), o jakou verzi požadavku se jedná, které části systému se požadavek týká, kdo na něm pracuje a další informace.

Mylné představy o vývoji informačních systémů

Mylných představ ohledně vývoje informačního systému existuje poměrně dost. Pro ilustraci uvádím několik takových představ z praxe i s komentářem:

1) "Analýzu nepotřebujeme, víme co chceme, dodáme naprosto jasné zadání."
Příklad naprosto jasného zadání: "Systém pro podporu procesu XYZ." Zadavatelé vědí, co daný proces řeší a jak. Možná  mají proces nějakým způsobem popsaný a mají obecnou představu, co by měl podporovat budoucí informační systém. Pro vývoj informačného systému je ovšem potřeba přesná specifikace. Většinou stačí několik konkrétních otázek a analytik zjistí, že naprosto jasné zadání není jasné ani zadavatelům.
                                                                   
2) "Na analytické schůzky nemáme čas, potřebujeme to dodat co nejdřív."
I na tento přístup lze narazit. Zadavatelé si nemají čas "jen tak povídat" o tom co by měla aplikace dělat. Je třeba začít co nejdřív programovat, aby se vše včas stihlo. Důležité je, zda je hlavním problémem vytížení zadavatelů požadavků jinou prací, nebo je problém ve velmi krátkém termínu dodání. V případě, že zadavetelé nemají čas, je třeba, aby si zadavatelská firma jasně určila priority - tedy zda je důležitější nový systém nebo něco jiného. V případě velmi krátkého termínu dodání je třeba rychle určit, co je kritická funkcionalita, kterou je potřeba do určeného termínu zanalyzovat a nasadit.

3) "Zpracování požadavků trvá zbytečně moc dlouho, vždyť je to úplně jednoduché.
Zadavatelé požadavku obvykle neznají všechny důsledky požadované změny. Například z pohledu uživatelského rozhraní může změna vypadat velmi jednoduše. Tato změna ale může mít dopady do dalších částí systému, může vyžadovat obsáhlé testování, migraci dat, integraci s ostatními systémy. Požadovanou změnu také obvykle není možné nasadit kdykoliv, obvykle se změny nenasazují po jedné, ale ve větších celcích. Proto může zdánlivě jednoduchá změna trvat dlouho.
                                         
4) "Požadavek je třeba nasadit co nejdřív a když to nebude fungovat, tak se to pak nějak upraví."
Ano, takto to může fungovat. Otázka je jaké chyby v tomto případě mohou nastat, jaké mohou být jejich důsledky a co budeme dělat, pokud nastanou. Pokud jde například systém pro řízení jaderné elektrárny, tento přístup bych nepoužil.        

5) "Musíte nám zaručit, že to bude na 100% bez chyb."
Zaručit, že v software není na 100% žádná chyba nelze. Ano, testováním lze pravděpodobnost chyby snížit. Čím déle testování probíhá, tím méně chyb testeři objeví - náklady na objevenou chybu tedy časem stoupají, pravděpodobnost neodhalené chyby klesá. Obvykle je rozumné testování v určité fázi ukončit, protože náklady by při pokračujícím testování byly příliš vysoké a doba do dodání systému příliš dlouhá.

6) "Nevíme co přesně budeme potřebovat, proto chceme, aby byl systém plně parametrizovatelný."
Často si zadavatelé nejsou jisti zadáním. Ví co potřebují nyní, neví co budou potřebovat v budoucnu. Raději tedy udělejme vše parametrizovatelné, ať to jde jednoduše změnit. Není to špatný nápad, jediný problém je cena a čas. Pokud bude vše parametrizovatelné, bude systém universálněji použitelný, ale bude výrazně dražší a jeho vývoj bude trvat déle.  

7) 14 dní před nasazením "Potřeboval bych ještě jednu drobnou úpravu ..."
Zadavatel často nechápe, že 14 dní před nasazením je (obvykle) skoro vše hotovo. Probíhá  testování, opravují se poslední chyby. Drobná úprava z hlediska zadavatele požadavků může mít rozsáhlé dopady do vyvíjeného systému.

Realizace analytické schůzky

Realizace analytické schůzky je poměrně složitá věc, ačkoliv se to nemusí na první pohled zdát. Na úvod několik rad:

1. Je třeba mít předem jasně vymezeno, co je předmětem řešení a co už není předmětem řešení není. 

Na jednom ze svých prvních projektů jsem dostal za úkol provést sběr požadavků pro relativně jednoduchý informační systém evidující požadavky na servisní podporu. Jeden z manažerů mi pak nastínil rozsah řešení, jak ho chápe on: požadavky na servisní podporu v důsledku vytěžují programátory, analytiky a testery. Je třeba, aby systém umožňoval automatické přidělování úkolů těmto pracovníkům, evidoval disponibilní čas pracovníků (včetně plánovaných dovolených ), podporoval schvalovací proces (akceptování přidělení úkolu nadřízeným pracovníka, akceptování vytvořeného řešení), sledoval odpracovaný čas a výkonnost jednotlivých zaměstnanců, sledoval náklady na zpracování jednotlivých požadavků, uměl poskytovat reporty. Z malého systému se tak stal komplexní informační systém pro řízení celé firmy.  Přitom jsem měl na analýzu pouhých 20 MD (mandays - člověkodny). 

Zásadní problém byl, že jsem si nejprve jednoznačně se zadavatelem nevymezil rozsah řešení. Všechno sice souvisí se vším, nicméně není třeba vyřešit všechno v rámci daného projektu.

2. Je třeba se zaměřit na to co je požadováno a ne na konkrétní implementační detaily.

Budoucí uživatel systému má konkrétní představu o řešení. Snaží se analytikovi pomoct a přijít hned s řešením, které ale nemusí být vždy správné. Většinou se jedná o poměrně detailní  řešení typu "na obrazovku 547 Detail účtu je potřeba dolů přidat pole Typ smlouvy". Dobrý analytik by nejprve měl zjistit, co uživatel opravdu potřebuje a proč to potřebuje. Nakonec se může ukázat, že uživatel vlastně potřebuje něco úplně jiného...

3. Netrvejte za každou cenu na svém. 

Po několika prvních schůzkách má business analytik obvykle již jistou představu, co zákazník požaduje. Někdy ovšem  může být tato představa mylná a zákazník požaduje něco trochu jiného.  Buďte flexibilní a netrvejte za každou cenu na svém, naslouchejte zákazníkovi. Mohlo by se zdát, že rada 3 je v přímém rozporu s radou 2, ale není tomu tak.

4. Rozlišujte požadavky, které informační systém musí nezbytně splnit (must have) a které jsou navíc (nice to have).

Některé požadavky jsou nezbytně nutné - anglicky "must have" (například systém bude generovat fakturu), některé nezbytně nutné nejsou (systém bude zasílat zákazníkovi email o dostupnosti zboží), ty lze označit jako "nice to have". Rozlišujte tyto dva typy požadavků. Až zákazník zjistí, kolik bude výsledný systém stát a jak dlouho bude trvat vývoj, možná se vzdá realizace části požadavků "nice to have", případně budou tyto požadavky přesunuty do další verze.

5. Nerozšiřujte zbytečně rozsah požadavků.

Analytika občas napadne, že by bylo dobré, kdyby systém kromě toho, co zadavatel požadoval, uměl ještě něco navíc. A dá se to v podstatě zahrnout pod některý z požadavků zadavatele, tak proč to nezahrnout... Tímto způsobem dojde k narůstání požadavků a zvyšování pracnosti a tedy i doby realizace a ve výsledku ceny systému. Důležité je samozřejmě to slovo "zbytečně". Pokud analytika napadne něco, co zákazník nechtěl, ale zákazník je z nápadu nadšený a požadavek si vezme za vlastní, tak proč ne. Slovem "zbytečně" jsem měl na mysli požadavky u kterých se po nasazení systému zjistí, že je zákazník vlastně ani nepotřebuje.

6. Dávejte pozor na to, co prezentujete a komu. 

Jedna velká finanční instituce najala na analýzu proveditelnosti konzultační firmu. Jednalo se o náhradu zastaralého informačního systému. Tento systém se v dané firmě používal přes 20 let. Systém byl udržovaný a rozšiřovaný týmem postarších vývojářů z nichž někteří se systému věnovali od samého začátku. Na první schůzku si konzultanti připravili prezentaci v PowerPointu a hned první snímek obsahoval obrázek rakve a text "Systém XYZ končí!". Důsledkem bylo, že na základě této prezentace ukončilo několik vývojářů z daného týmu okamžitě pracovní poměr, protože se jich prezentace osobně dotkla. Úsměvná historka. Nicméně daný systém byl nahrazen až za několik let a po tu dobu by se těch několik vývojářů dané firmě hodilo. 

Naplánování a organizace analytické schůzky

Naplánování analytické schůzky vypadá na první pohled jednoduše. Otevřu Microsoft Outlook, přepnu se do kalendáře, zvolím Novou událost a pak už jen vyberu účastníky schůzky, vyberu čas a místo a je to. Ovšem před tím musím vyřešit několik poměrně důležitých otázek:

• Jaké téma schůzky zvolit?
• Koho vybrat jako zástupce klíčových uživatelů?
• Kolik lidí pozvat na schůzku?

Na úvodních schůzkách je vhodné začít obecnějšími tématy. Začít od potřeb (anglicky needs), tedy od toho, co by měl daný informační systém vyřešit. Potřeby umožní vymezit, co je předmětem řešení a co už ne. Postupem času se lze dopracovat k detailnějším oblastem a začít uvažovat třeba nad tím, jak přesně má vypadat případ užití UC0157 výdej zboží. Tenhle přístup se nazývá top - down. Začínáme s globálním pohledem na systém a postupně se dostáváme do větší hloubky s větší úrovní detailu.

Se zvoleným tématem schůzky a s danou úrovní detailu souvisí i to, koho pozvat. K obecnějším tématům se bude nejspíše vyjadřovat management firmy, k detailům pak spíše zástupci uživatelů. Správný výběr konkrétních lidí, kteří budou spolupracovat s business analytikem a v rámci projektu se účastnit analytických schůzek je také dost obtížný. Pokud má dané znalosti ve firmě pouze jediný člověk, je předem dané, že se analytických schůzek bude účastnit právě on. Pokud je v dané kategorii uživatelů na výběr, pak by měl ideální kandidát splňovat následující předpoklady:

• měl by být dostatečně dobře seznámený s danou problematikou,
• měl by reprezentovat danou skupinu klíčových uživatelů,
• měl by být schopen vše jasně a srozumitelně vysvětlit,
• měl by být časově dostupný.

Samozřejmě tohle je ideální stav. Ten nejzkušenější pracovník bude obvykle i ten nejvytíženější a tudíž nejméně časově dostupný.

Pro business analytika je obtížné ověřit, zda je pracovník dostatečně dobře seznámený s danou problematikou a zda skutečně reprezentuje danou skupinu uživatelů. Někteří lidé nepřiznají, že něco nevědí nebo si tím nejsou jisti. Daný uživatel také nemusí reprezentovat většinový názor skupiny uživatelů. Dělá v zásadě stejnou práci, ale z nějakého důvodu se setkává s jinými problémy nebo používá jiné postupy než ostatní uživatelé.

Pracoval jsem na analýze požadavků pro jeden informační systém, který se měl využívat na 10 různých pracovištích v různých městech ČR. Všechna tato pracoviště zpracovávala stejné případy, každé mělo svého vedoucího a bylo na ostatních pracovištích nezávislé. Vzhledem k tomu, že jedno z těchto pracovišť bylo umístěno v Praze, probíhaly analytické schůzky s pracovníky z Prahy. Při představení výsledků analýzy se pak ukázalo, že by navržený informační systém plně vyhovoval jen pracovišti v Praze. Důvodem bylo, že ostatní pracoviště používali odlišné pracovní postupy. Pracovníci pražského pracoviště tedy nereprezentovali celou skupinu uživatelů.

Jak takové situaci předejít? Důležité informace je třeba ověřit z více zdrojů. Je to často časově náročné, nicméně vyplatí se to.

Pokud jde o časovou dostupnost, je vhodné dohodnout rozsah spolupráce klíčových uživatelů s managementem firmy. Bez spolupráce klíčových uživatelů nemá analytik šanci kvalitně provést svojí práci. Je proto třeba, aby byla dostupnost těchto pracovníků garantována jejich nadřízeným a jejich účast na projektu chápána ve firmě jako priorita.

Na schůzku je potřeba pozvat přiměřený počet lidí. Za přiměřený počet osobně  považuji maximálně 5 účastníků schůzky (včetně business analytika). Samozřejmě mám zkušenost i s větším počtem účastníků  schůzky, ovšem takové schůzky nebývají příliš efektivní, protože každý z účastníků se zaměřuje na jinou oblast.

Tolik k přípravě analytické schůzky. Příště se podíváme na realizaci schůzky.