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φ.

Petr Kop°iva, kopriva@komix.cz