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.
Žádné komentáře:
Okomentovat