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.