Moduly

Požadavky jsou součástí správy při řízení projektu. O tom co všechno do agendy projektového řízení spadá, je více zde. Požadavky jsou navrženy tak, abyste pomocí nich dokumentovali zadání, mohli zpracovat analýzu i řídit zpracování celého projektu.

Vstupní a odvozené požadavky

Vstupní požadavky projektu jsou požadavky, které přicházejí z vnějšího prostředí, typicky od zákazníka, zadavatele projektu, nebo týmu, který projekt vymyslel. Říká se jim obecně uživatelské požadavky.

Naproti vstupním požadavkům jsou požadavky odvozené, tedy takové, které vznikly v projektu na základě analýzy, jak realizovat projekt. Odvozené jsou všechny požadavky, které vyplynuly ze vstupních požadavků, nebo jiného vstupu do projektu. Typickým vstupem, který generuje požadavky, je povinnost, metodika, jen výjimečně něco jiného.

Typy požadavků

Rozdělení na vstupní odvozené požadavky vyplývá z toho, jak požadavky vznikly. Většinou se používá pro odvozené požadavky podrobnější dělení, popsané dále. Samozřejmě v projektu mívají smysl jen některé typy požadavků v závislosti na tom, co je smyslem (produktem) projektu.

Uživatelské – už jsme si popsali. Vždy se jedná o vstupní požadavky
Systémové – požadavky, které se týkají celého řešení, systému (samozřejmě pouze pokud v projektu nějaký systém vzniká, tak je tomu i nadále)
Softwarové – Požadavky, které má/musí splnit software vytvářený v rámci projektu. Nejde o požadavky na software používaný pro realizaci projektu, ale vytvářený
Hardwarové – Požadavky, které má plnit elektronická část projektu, obecně hardware
Inženýrské – Požadavky, které má/musí splnit konstrukce v projektu vyráběné nebo vyvíjené. V závislosti na typu projektu může jít o vyvíjenou mechanickou součástku, nebo třeba připravovanou stavební realizaci
Procesní – Požadavky na proces realizace požadavku. Jde o specifické požadavky, jak se konkrétní činnost nebo etapa má realizovat, kdo se jí má účastnit apod. Pozor, neměly by opakovat metodiku, podle které je projekt realizován. Pokud tedy je požadavek na nějaký procesní úkon, např. revizi, který je dán metodikou, nemělo by být nutné jej znovu psát jako procesní požadavek (je možné jej najít jako povinnost nebo vzorový úkol v metodice).
Testy / Zkoušky – Požadavky na testy, ověřování a zkoušení jakýchkoli projektových výstupů. Požadavky by měly společně definovat vše, co má být provedeno pro ověření kvality díla. (Podle metodiky může zahrnovat i testy vstupních zařízení, např. kalibrace měřících zařízení. Většinou jsou ale tyto požadavky na kontrolu vstupů přímo součástí metodiky, nebo by měly být procesními požadavky, protože jde o kontrolu v procesu, nikoli kontrolu výstupu.)
Obchodní / Business – Požadavky vyplývající z obchodního aspektu projektu. Typicky jde o požadavky vyplývající z obchodních potřeb (mohou se týkat designu, výrobních nákladlů apod.). Pozor na rozlišení mezi požadavky a povinnostmi. Pokud je např. obchodním zadáním, aby vyvinutý výrobek měl výrobní náklady pod 10€, je dobré jej chápat jak povinnost, kterou musí projekt dodržet. Tato povinnost se promítá do všech činností od plánování projektu, po výběr dodavatelů, a nelze jednoznačně říci, že je něčím plněn.

Analýza požadavků

Pokud jsou požadavky a hlavně vyvíjený systém složitější, není možné vyvíjet / realizovat projekt přímo na základě uživatelských požadavků. Tyto požadavky je třeba promyslet, rozdělit, podle toho, kde, jak a kým budou realizovány a často podrobněji rozebrat. Těmto krokům se říká analýza. V rámci analýzy vznikají ze vstupních požadavků požadavky odvozené.

Analytické vztahy

Z uživatelských požadavků vznikají požadavky na systém (systémové)
Ze systémových požadavků vznikají požadavky na jednotlivé části systému, často už rozdělené podle toho, jakou podstatu ta která část systému má (inženýrský návrh – technologická část, software, hardware).
Požadavky na části systému se mohou dále rozpadat na dílčí, ale je lepší se tomu snažit vyhnout a nevytvářet další vrstvu. Pokud ale jde o velký systém, může to být potřeba
Požadavky na testování mohou být vstupními i odvozenými požadavky. Pokud jsou odvozené, jsou výsledkem analýzy, co je třeba ověřit, aby byla splněna typicky kvalitativní kritéria.

Jak dokumentovat vztahy

Vztahy se dokumentují vazbou stopa / trace. Vazba vede vždy z požadavku, na základě kterého vzniká požadavek nový, odvozený. Vazby se snadno vytvářejí pomocí příkazových tlačítek v detailu požadavku.

Stavy požadavků

Zpracování požadavku je řízeno stavy. Stavy požadavků jsou:

Nový – dosud není analyzován a čeká na zpracování
V analýze – probíhá analýza, ale není dosud dokončena
Analyzován – Analýza proběhla, ale měla by být ověřena.
Ověřen (verifikován) – Proběhla kontrola, jak byl analyzován. Požadavek se do kroku dostane pouze v případě, že jej analyzuje někdo jiný, než kdo za něj odpovídá (odpovědný pracovník je uveden v požadavku). Pokud je analyzován přímo odpovědným pracovníkem, krok ověření je přeskočen
Dokončen – Analýza byla dokončena. Stav dokončen neznamená, že je analyzované řešení realizováno, ale že je dokončena analýza, jak realizovat
V nepořádku – Požadavek není možné analyzovat, protože tomu něco brání. Typickými důvody, proč je požadavek v nepořádku jsou
- Požadavek je v rozporu s jinými požadavky a nelze tedy všechno splnit
- Požadavek je v rozporu s omezeními, které nelze změnit. Např. je v rozporu s obecně platnými předpisy nebo jej nelze realizovat v ceně díla
Zamítnut – požadavek byl ze zpracování vyřazen. U vyřazení by měl být vždy uveden důvod vyřazení. Typickými důvody vyřazení jsou:
- Požadavek je duplicitní s jiným požadavek, který je řešen
- Požadavek byl podán někým, kdo není oprávněn požadavek vznést
Zrušen – požadavek zrušil svým rozhodnutím zadavatel

Synchronizace požadavků do Enterprise Architect

Požadavky i další prvky analýzy je možné automaticky synchronizovat do modelu v Enterprise Architect. Synchronizace vám umožní spojit výhody webového přístupu k zadání pro celý projektový tým i plné analytické možnosti oblíbeného nástroje.