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.