Požadavky na informační systém

Zadavatelé nevěnují požadavkům pozornost. Ještě hodněkrát bude daňový poplatník nadávat na projekty jako OpenCard nebo Registr motorových vozidel. A ještě vícekrát budou investoři litovat peněz a času, který ztratili vyjednáváním o navýšení cen za pořízení softwaru. Ti méně šťastní budou litovat peněz za advokáty.


Kdo nemá požadavky, zaslouží si dostat systém, který je splní.

Přibližně polovina projektů v IT je neúspěšných – jsou drahé, pozdě realizované nebo nefunkční. Podle článku serveru InformationWeek1 existuje několik hlavních příčin:

  • nejasný vlastník projektu

  • nejasné nebo měnící se požadavky

  • neadekvátní znalosti a zdroje

  • špatný návrh a nevhodné použití nových technologií

Nejasné nebo měnící se požadavky jsou zcela proti zájmům zadavatele a naopak hrají výrazně do karet dodavateli. Autor článku dále pokračuje:

"... na základě mých zkušeností podezřívám dodavatele, ... že podporují dodatečné změny, protože v tom vidí příležitost k rozšíření rozsahu projektu a k dosažení podstatně vyšší marže (změny jsou vždy podstatně ziskovější než originální nabídka)".


Motivace zadavatele a dodavatele

Dodavatel má při vyjednávání o změnách nesrovnatelně silnější pozici, než když se ucházel o původní zakázku. Je jasné, proč. Dodavatel je vybraný, konkurenti z výběrového řízení zmizeli ze scény a hlavně část peněz za systém je už utracená (proto se většinou vyplácí zálohy hned po podpisu smlouvy). Proto jsou také dodavatelé velice bohorovní, pokud jde o definici požadavků, a podsunují myšlenku, že nejdůležitější je začít programovat a instalovat co nejdřív - teprve podle toho se pozná, že projekt skutečně "jede".

Specifická je situace u ERP systémů. Tam se mění taktika dodavatele tak, že se za požadavky prohlásí právě to, co systém už umí. Zadavatel samozřejmě neví, co systém umí, ale věří, že všechno, co potřebuje. To co neumí bude, "předmětem dalšího vývoje". S jinou marží, samozřejmě.


Rizika projektů a analýza požadavků

Projektové řízení je hlavně řízení rizik. Absence napsaných požadavků je obrovské riziko a vyvolává řadu neřešitelných problémů:

Jak mám vybrat dodavatele, když pro něj nemám zadání? Koho mám vůbec oslovit?

Jak dobře může dodavatel odpovědět na mou poptávku, když neví, co chci?

Jak můžu podepsat smlouvu o dodávce (co, za kolik, do kdy), když nevím na co?

Jak můžu testovat dodávku, když jsem dodavatele nezavázal k určené funkcionalitě?

Jak můžu uplatňovat reklamace?

Opačným rizikem je paralýza z analýzy a právě obava z takové strašné nemoci je pravděpodobně za tím, že se zadavatelé obávají ztráty dechu ještě před začátkem projektu. Ani tomu se není možné úplně divit. Požadavky šustí papírem a pro lidi uvnitř firmy vlastně nepřinášejí nic nového – popisují to, co všichni vědí. Metodika vhodná pro ministerstvo obrany se nehodí pro maloobchod a je důležité hledat formu a rozsah, který pokryje rizika a nevyčerpá všechnu energii projektového týmu.

Často však dochází k tomu, že pokus o definici požadavků odkryje slabá místa v procesech, odlišné chápání pojmů v různých odděleních nebo přinese inspiraci pro zlepšení organizace práce tam, kde se to nečekalo a nebo tam, kde na to dosud nebyl čas. To už ovšem není paralýza, to je vývoj. Pokud se nerealizuje právě v této etapě vývoje, nebude se realizovat ani v dohledné době, protože nový systém - pokud se úspěšně uvede do provozu - zafixuje staré chyby a později bude chybět vůle se k nim vracet (teď jsme to dodělali a budeme to zase měnit?!).


Náklady na změny

Chyby, které se podaří odhalit během fáze požadavků jsou snadněji odstranitelné než ty, které se projeví později v provozu. Náklady na jejich odstranění jsou řádově nižší. Steve McConnell, autor knihy Code Complete (v češtině Dokonalý kód) k tomu uvádí:2

"Studie ukázaly, že opravy chybných požadavků, designu a kódu běžně reprezentují 40 až 50 procent celkových nákladů na vývoj softwaru (Jones 1986). Odhadem platí, že každá hodina, kterou věnujete prevenci chyb, sníží čas oprav o 3 až 10 hodin. V nejhorším případě trvá odstranění chyby 50 až 200krát déle v provozovaném systému než v požadavcích (Boehm a Papaccio 1988)."

Je to logické. Jednořádkový požadavek může zabrat stránku v softwarové specifikaci a 10 stránek kódu.

Co už by mělo přesvědčit účetního, když ne tohle?

Rozmyslete si své požadavky a ušetřete nejméně polovinu času i peněz za vývoj.

ITCrawl poskytuje konzultace v oboru analýzy požadavků. Pomáháme našim zákazníkům při přípravě projektové a smluvní dokumentace a pomáháme při testování a akceptaci předávaných systémů. Využijte našich dvacetiletých zkušeností se stavbou systémů.

Zpět na domovskou stránku