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.