Analýza požadavků není jen prosté přečtení toho co si zadavatel přeje

Analýza požadavků není něco světoborného, co by si někdo měl zvlášť objednávat. Je to však přirozená součást všech řešení. O to víc bývá podceňována. Přitom přirozeně předchází mnoha činnostem, které se snaží dosáhnout nějaké pozitivní změny v businessu firmy – od implementace nového CRM až po vstup na nové trhy.

Co analýza požadavků skutečně je?

Můžeme se na ni dívat několika způsoby. Tím prvním je, že se jedná o zapsaný a formulovaný soubor požadavků zadavatele. Prostě si s ním sednu, on povídá, já zapisuji a občas mu položím nějakou rafinovanou otázku, kterou ho tak trochu koučuji, abychom popsali business potřeby v celém komplexitě a třeba na něco nezapomněli.

Jde to i tak, mnoho analytiků to tak i dělá, ale i v relativně jednoduchých situacích to může být málo. Jak se tedy na analýzu požadavků dívat tak nějak šířeji?

V první řadě analýza požadavků má za úkol popsat požadavky na řešení, které bude naplňovat business potřeby zadavatele. Zdá se vám to totožné? Podobnost s předchozím přístupem tu je, ale je třeba, ale jen touto změnou úhlu pohledu nám vyskočí potřeba udělat poněkud více věci.

Co k analýze požadavků potřebujeme získat?

• Business case, z něho se dozvíme jaký je záměr a hlavně jaké jsou cíle
• Rozsah řešení, vymezení hranic toho co se á být řešením
• Přímé vyslovené (lépe sepsané) požadavky
• Projektový plán, alespoň jeho část týkající se plánu business analýzy.

Pokud něco z toho není k dispozici, což si nezastírejme, že je běžnou realitou, je součástí práce analytika pomoci tomu, aby to vzniklo.  Pokud si to uvědomí včas a zadavatel to včas přijme, předejde se překvapením v budoucnu. Hlavně tomu proč ta analýza tak dlouho trvá. No, aby netrvala, když nejsou pevné základy …

Jaké kroky musíme realizovat?

Prioritizace požadavků – je třeba říct co je opravdu důležité a co je spíš něco navíc, co když nebude, tak se svět nezblázní.

Organizační požadavky – může být požadováno, aby se hlavně nic neměnilo vůči lidem. To zní strašně, ale v rozsáhlých obchodních sítích, které jsou roky zaběhnuté a fungují dobře, jsou i malé změny velkou revolucí. S tím je třeba počítat tj. to vědět!

Definice předpokladů a omezení – vše platí pouze za daných požadavků. Je to jeden ze způsobů jak si zakotvit i rozsah realizace řešení a řídit budoucí změny. Je to základní předpoklad proto, aby člověk mohl garantovat své sliby.

Ověření a validace požadavků – zdě řešíme hlavně konzistenci požadavků vůči sobě, vůči business cílům, vůči aktuálnímu stavu organizace atd. Nebylo by dobré mít zpracované požadavky, gramaticky i formálně správně, ale ve stavu, kdy si vzájemně odporují nebo odporují očekávaným business cílům firmy, jejím hodnotám apod.

Jak si požadavky strukturovat?

Tak, aby to dávalo smysl tj. to bylo užitečné. To je rada jak od chytré horákyně, ale chci ji zdůraznit z jednoduchého důvodu – vše co napíšu dále je pro inspiraci, nikoliv pro to, aby bylo bezhlavě realizováno tou nejbyrokratičtější možnou cestou. Je to příklad, který lze dle potřeb rozšiřovat, měnit apod.

1. Business pravidla – jaká pravidla máme?
2. Data modeling – jaká data nám do analýzy vstupují a v jakých vztazích?
3. Popis aktuálního stavu – jak věci fungují nyní, nesnažme se dělat revoluci za každou cenu
4. Metriky a reporting – metriky pomáhají rozklíčovat účel požadavku a také v budoucnu umožní nalézt ty, které jsou kritické tj. klíčové a je třeba se na ně soustředit.
5. Nefunkční požadavky – to jsou takové, které kladou omezení na budoucí návrh, ale samy o sobě neplní nějakou funkci. Například požadovaný výkon obchodního systému – musí zvládnout víc jak 100 souběžně pracujících uživatelů.
6. Procesní požadavky – díky ním podchytíte souvislosti a vůbec vztahy.
7. Use case – konkrétní scénáře použití, kterým zadavatel nebo další zainteresované osoby jím pověřené většinou rozumí nejlépe. Pokud cílem má být aplikace, není špatné zde vložit se zadavatelem společně nakreslené wireframes.

Co je výstupem analýzy požadavků?

Výstupem je dokument specifikovaných a modelovaných požadavků, které jsou prioritizovány, strukturovány a hlavně ověřeny zadavatelem.  Znamená to použití definovaných formátů, struktur, úložišť atd., které musely být určeny již na začátku projektu.

Výstup musí odpovídat formálním požadavkům na dokumentaci tak, aby ho bylo možné sdílet napříč zadavateli, projektovým teamem a současně spravovatelené v případě budoucích změn.