Pro šťastné vykročení (do projektu) - nástroje pro evidenci a analýzu požadavků

Jaké chyby vznikají na základě specifikace požadavků?

• Některé zadavatelovy požadavky nejsou realizovány.
• Požadavky jsou realizovány špatně.
• Některé požadavky jsou realizovány pozdě.
• Dva subsystémy informačního systému jsou ve vzájemném rozporu.
• Subsystémy na sebe nenavazují.

Proč tyto chyby vznikají?

• Zadavatel a řešitel hovoří rozdílným jazykem V době tvorby specifikace požadavků není ještě řešitel zcela obeznámen s věcnou problematikou reálného systému. Zadavatel používá vlastní sadu výrazových prostředků.
• Zadavatel nedisponuje schopností přesně vyjádřit požadavky na systém Text dodaný zadavatelem často bývá velmi rozsáhlý, nestrukturovaný. Jednotlivé požadavky jsou v něm určeny nejednoznačně a zamlženě. Nejsou odděleny podstatné nároky od méně důležitých.
• Řešitel není schopen kvalitně rozpoznat jednotlivé požadavky Řešitel nepoužívá vhodnou metodiku, na jejímž základě by vznikla strukturovaná specifikace požadavků, která splňuje kritéria takového dokumentu (viz níže).
• Jednotlivým požadavkům nejsou přiřazeny atributy Zadavatel a řešitel přiřazuje požadavkům rozšiřující kvalitativní a kvantitativní atributy, které umožňují rozlišovat skupiny požadavků a rozdělovat je dle jejich vlastností. Nejsou-li tyto atributy definovány (popř. jsou-li definovány vágně) nelze rozeznat důležitost jednotlivých požadavků.
• Nejsou stanoveny jasné kompetence tvorby požadavků na systém V praxi je běžné, že k tvorbě požadavků ze strany zadavatele má přístup velké množství osob. Je zřejmé, že možnost vyjádřit se k požadavkům by měl mít velký počet budoucích uživatelů systému. Vytvářet je se však musí umožnit pouze omezené skupině osob. Jenom tak lze docílit, aby požadavky byly konzistentní, reálné a nebyly ve vzájemném rozporu.
• Nejsou definovány vazby mezi požadavky Jestliže není jasně určeno, které požadavky či skupiny požadavků spolu souvisejí, je obtížné vhodně navrhnout jednotlivé subsystémy.

Jak těmto chybám předejít?

1. Společný tým musí kvalitně spolupracovat Ze strany zadavatele musí být v týmu lidé, kteří mají dobré znalosti reálného systému, aby dokázali dostatečně definovat požadavky. Zároveň musí umět vysvětlit věcné oblasti systému zástupcům řešitele. Řešitel musí do týmu dosadit takové osoby, které se nebrání přijímání nových (a často velmi rozsáhlých) vědomostí o reálném systému. Jenom pochopení problematiky reálného systému může vést ke správnému rozpoznání požadavků. Samozřejmostí je vhodná motivace jednotlivých členů týmu.
2. Omezení nereálných požadavků Zadavatel občas mívá tendenci zahrnovat do specifikace nereálné požadavky. Bývá to způsobeno neschopností představit si skutečné možnosti informačního systému, často také zadavatel zkouší "co všechno řešitel dovede". Na straně řešitele musí být odborníci, kteří dokáží rozeznat nereálné požadavky a eliminovat je.
3. Změnové řízení Jedním ze základních kamenů je dobrá definice změnového řízení. Je nutné definovat, kdo může požadovat změny, za jakých podmínek, kdo rozhoduje o jejich přijetí. Jasnou definicí změnového řízení se řešitel brání proti nadměrnému přílivů požadavků na změny v průběhu prací. Zadavateli to dává do ruky nástroj, jak prosadit racionální změny do systému.
4. Strukturalizace požadavků Textový dokument, který vytváří zadavatel nemá být přímým podkladem pro specifikaci. Obsahuje totiž značné množství nadbytečného textu (spojky, částice), jednotlivé požadavky se v něm mohou opakovat. Proto se vytváří zvláštní dokument specifikace požadavků na systém (SRS - System Requirements Specification). Ten obsahuje strukturované a formalizované požadavky, které vznikly na základě studia textového dokumentu zadavatele. Požadavek je a) vlastnost nebo podmínka umožňující řešit problém nebo dosáhnout cíl projektu, b) vlastnost, kterou by měl disponovat navrhovaný informační systém, c) zdokumentovaná reprezentace bodu a) a b). Jednotlivé požadavky vytvářejí strukturu. Požadavek může mít podřízené požadavky. Text požadavku nesmí umožňovat nejednoznačný výklad. Pro případ, že by k tomu došlo, je rozšířen o slovní komentář, který nejednoznačný výklad eliminuje.
5. Dokument specifikace požadavků SRS musí disponovat následujícími vlastnostmi: Unikátnost - každý požadavek v něm smí být implementován pouze jednou. Normalizace - požadavky se nesmí překrývat tj. nesmí odkazovat na jiné požadavky nebo vlastnosti jiných požadavků. Provázanost - mezi požadavky musí být definovány relace, zachycující jejich vazby při definování systému. Kompletnost - SRS musí obsahovat všechny požadavky označené zákazníkem za požadavky definující systém a jeho vlastnosti. Musí definovat všechny vstupy a odpovídající výstupy včetně omezení na ně kladených. Musí definovat akceptovatelné doby odezvy. Konzistence - požadavky obsažené v SRS nesmí být ve vzájemném rozporu, musí být dotaženy na stejnou úroveň podrobnosti, musí být prezentovány shodným způsobem i stylem. Omezenost - musí být vymezen rozsah specifikace. Modifikovatelnost - SRS musí být modifikovatelná. Jednoznačnost a normalizace požadavků tuto vlastnost podporuje. Konfigurovatelnost - požaduje se možnost vytváření a správy verzí SRS.
6. Definice rozšiřujících atributů Aby se požadavky daly lépe členit, přiřazují se jim kvalitativní a kvantitativní atributy. Mezi nejdůležitější přiřazované atributy patří: a) priorita - určuje, nakolik je požadavek důležitý, b) úsilí - odhad pracnosti a nákladnosti realizace požadavku v systému, c) nutnost - rozdělení požadavků na povinné, žádoucí a vhodné. Na základě těchto a dalších atributů je možné provádět odhady nároků na vývoj systému, vytvářet plán vývoje, členit systém do subsystémů. Díky těmto atributům je také možné poznat, jak se promítne navrhovaná změna požadavku na vývoj systému a na ostatní požadavky.
7. Vazby mezi požadavky Je velmi užitečné znát vazby mezi požadavky. Každá vazba může obsahovat další rozšiřující atributy. Definicí vazeb se zprůhlední souvislosti. Dobré je vytvářet také vazby na další komponenty vývoje systému. Je-li konkrétní požadavek řešen např. procesním diagramem pomocí nástroje procesní analýzy a diagramem událostí pomocí CASE nástroje, měly by být informace o těchto diagramech zaznamenány a vytvořeny vazby mezi požadavkem a nimi. To umožňuje trasovat proces vývoje systému a dobře tento proces plánovat.
8. Oboustranná shoda Každý bod dokumentu specifikace požadavků na systém musí být oboustranně schválen. Zadavatel sleduje, zda dokument SRS obsahuje všechny požadavky definované v původním textovém dokumentu a zda rozšiřující atributy správně vypovídají o vlastnostech požadavků.
9. Kvalitní smlouva Je samozřejmostí, že nejen tato etapa vývoje projektu vyžaduje kvalitní smluvní vztahy a tedy i kvalitní smlouvy. Nutno dodat, že vedle těchto formálních náležitostí by základem vývoje projektu měly být také dobré mezilidské vztahy mezi dodavatelem a řešitelem.

Pro podporu tvorby SRS existují specializované nástroje (RCAT - Requirements Collection and Analyses Tools). Budete-li vybírat RCAT, sledujte především následující vlastnosti:

1. Způsob přenesení původního textového dokumentu do RCAT Jakým způsobem se přenáší dokumenty do nástroje evidence a analýzy požadavků? Dokáží importovat běžné formáty textu (Word, RTF, čistý text, …)?
2. Způsob extrakce požadavků z původního dokumentu Nástroj musí umožnit extrahovat požadavky z původního textového dokumentu, aniž by se měnil jeho obsah. Je žádoucí, aby se do původního dokumentu zaznamenávalo, kdo a kdy požadavek extrahoval. Když zadavatel prochází SRS, porovnává jej právě s původním textem. Dobrým řešením se ukázal způsob, kdy se extrahovaný požadavek v textu barevně odliší a skrytým atributem je autor extrakce a její čas.
3. Způsob zobrazení struktury formalizovaných požadavků Jak bylo popsáno výše, extrahované požadavky vytvářejí hierarchii. RCAT musí vedle textového zobrazení struktury požadavků (číslování hierarchie - 1, 1.1, 1.2, 1.2.1 atd.) umožnit také grafické zobrazení hierarchie. Tzn. nakreslit strom struktury požadavků. Pro lepší orientaci ve složité struktuře požadavků musí nástroj umožňovat jak v grafickém tak v textovém režimu zobrazení do určené úrovně (např. zobrazení do úrovně 2 zobrazí pouze požadavky očíslované 1, 1.1 nebo 3.5, ale nezobrazí požadavky 1.1.1 nebo 3.5.2).
4. Práce s požadavky nebo skupinami požadavků V rámci struktury požadavků musí být realizovány základní funkce jakými jsou kopírování a přenášení (ať již požadavků nebo celé podstruktury požadavku), třídění a filtrování výstupu.
5. Vytváření atributů a jejich zobrazení Každému požadavku musí být umožněno definovat neomezené množství atributů. Atributy jsou jak typu číslo nebo řetězec, tak typů interval či diskrétní výběrová hodnota. RCAT umožňuje zobrazit s požadavkem také stanovené atributy. Vhodný řešením je vytvoření různých pohledů na požadavek (manažerský - zobrazuje atribut nákladnosti a odhadovaného času, analytický - zobrazuje atribut priority, atd.). Mezi pohledy je možno přepínat.
6. Vytváření vazeb a jejich zobrazení Nástroj musí umožnit vytvářet vazby mezi jednotlivými požadavky a definovat jejich atributy. Vazby lze vytvářet nejen mezi požadavky jednoho dokumentu, ale i mezi požadavky více dokumentů. Díky tomu lze rozdělit SRS do více logických částí, ale také vytvářet různé dokumenty pro různé etapy vývoje a sledovat procesní vztahy mezi požadavkem a jeho řešením. Vazby mezi požadavky lze graficky zobrazit. Nástroj také umožňuje sledovat vstupující a vystupující vazby určenému požadavku do stanovené hloubky.
7. Správa verzí a tvorba historie změn Při tvorbě specifikace požadavků je více než jindy důležité rozlišovat jednotlivé verze dokumentů a sledovat historii jejich změn. Je vhodné, když každý požadavek má vlastní historii, kde se zaznamenává každá změna (byť jen syntaktická).
8. Správa přístupu uživatelů Musí být vytvořeni uživatelé, kteří přistupují k dokumentům a mají jasně definovaná práva nakládání s těmito dokumenty.
9. Otevřenost nástroje Nástroj musí být schopen automatizovaně agregovat informace z jiných vývojových nástrojů. To může být vyřešeno buď speciálními importními schopnostmi nástroje nebo možností naprogramovat si vlastní importní modul přímo do nástroje (to však vyžaduje přítomnost interpretru nějakého jazyka).

Nástroje pro evidenci a analýzu požadavků nedokáží rozpoznat v textu požadavky. Tahle práce zůstane vždy na člověku. Díky nim však odpadne většina potenciálních problémů, které při této práci vznikají.