Volere Šablona pro specifikaci požadavk

Transkript

1 Volere Šablona pro specifikaci požadavk 9. vydání James & Suzanne Robertson editelé spolenosti Atlantic Systems Guild Londýn, Cáchy & New York Copyright Atlantic Systems Guild Tento dokument lze mnit, upravovat nebo kopírovat pouze pro interní úely v souladu s autorskými právy. Cílem tohoto dokladu je vytvoit základ pro stanovení vašich požadavk. Bez pedchozího písemného souhlasu jej nelze prodávat i používat pro vytváení obchodního zisku nebo jiné úely. Aktualizace tohoto vzoru se nachází na našich webových stránkách a Translation 2003 Eurotel Praha, spol s r. o. Strana 1 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

2 ... Systém Specifikace požadavk Verze... PROJEKTOVÉ STIMULY (PROJECT DRIVERS) 1. Úel produktu 2. Klient, zákazník a další zúastnné osoby 3. Uživatelé produktu PROJEKTOVÁ OMEZENÍ (PROJECT CONSTRAINTS) 4. Nezbytná omezení 5. Jmenné konvence a definice 6. Relevantní skutenosti a pedpoklady FUNKNÍ POŽADAVKY (FUNCTIONAL REQUIREMENTS) 7. Rozsah prací 8. Rozsah produktu 9. Funkní a datové požadavky NEFUNKNÍ POŽADAVKY (NON-FUNCTIONAL REQUIREMENTS) 10. Požadavky na vzhled a dojem 11. Požadavky na uživatelnost 12. Požadavky na výkonnost 13. Požadavky na provoz 14. Požadavky na údržbu a penositelnost 15. Požadavky na bezpenost 16. Kulturní a politické požadavky 17. Právní požadavky PROJEKTOVÉ OTÁZKY (PROJECT ISSUES) 18. Otevené otázky 19. Hotová (standardní, již použitá) ešení 20. Nové problémy 21. Úkoly 22. Pepnutí systému 23. Rizika 24. Náklady 25. Uživatelská dokumentace a školení 26. Další požadavky pro další vývoj produktu, který není souástí stanoveného rozsahu prací 27. Nápady na ešení Specifikaci zpracoval... Dne... Strana 2 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

3 Preambule Toto je šablona (vzor) pro stanovení požadavk. Vyplte ásti, které se vztahují k vašemu projektu a jednotlivé položky nahrate vaším textem. Smažte veškeré ásti, které se na vás nevztahují. Do dokumentu pipojte jakékoliv další ásti a skutenosti, které se vztahují na váš projekt. Volere Volere je výsledkem dlouholeté praxe, poradenské innosti a výzkumu v oblasti ízení požadavk. Naše zkušenosti jsme zpístupnili prostednictvím balíku ve form všeobecného procesu ízení požadavk, školení v oblasti požadavk, poradenství v oblasti požadavk, audit požadavk a této šablony pro požadavky. Proces specifikace požadavk, Volere je popsán v knize: Mastering the Requirements Process autor Suzanne a Jamese Robertsonových, Addison-Wesley, Londýn, ISBN Veejné semináe o Volere se konají pravideln v Evrop, Spojených státech a Austrálii. Interní semináe a poradenskou innost v oblasti Volere si lze objednat. Další informace naleznete: Atlantic Systems Guild, 11 St Mary s Terrace, Londýn, W2 1SU, Spojené království. suzanne@systemsguild.com webová stránka: james@systemsguild.com Strana 3 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

4 Druhy požadavk Funkní požadavky pedstavují základní pedmt systému a jsou meny konkrétními prostedky jako jsou napíklad hodnoty dat, logika a algoritmy rozhodování. Funkní požadavky specifikují, co má produkt dlat. Nefunkní požadavky pedstavují vlastnosti v oblasti chování, které musí mít stanovené funkce jako napíklad výkonnost, uživatelnost atd. Nefunkním požadavkm lze piadit konkrétní metodu mení. Tento vzor uvádí píklady kvantifikace nefunkních požadavk. Nefunkní požadavky specifikují, jaké vlastnosti má produkt mít. Projektová omezení urují, jak lze konený produkt aplikovat v reálném svt. Napíklad produkt musí využívat urité rozhraní nebo využívat stávající hardware, software nebo vyhovovat obchodním zvyklostem, musí se vejít do stanoveného rozpotu i být pipraven k pedem stanovenému termínu. Projektové stimuly pedstavují síly související s obchodní inností. Napíklad úel produktu pedstavuje projektový stimul, stejn tak jako všechny zúastnné osoby na projektu z nichž se ovšem každá projektu úastní z rzných dvod. Projektové otázky urují podmínky, na jejichž základ bude projekt vypracován. Tyto požadavky zahrnujeme do stanovení požadavk tak, abychom vám pedložili celkový obrázek všech hledisek, které pispívají k úspchu nebo neúspchu projektu. Testování požadavk Své požadavky zanete pravdpodobn testovat již v okamžiku, kdy je napíšete na papír. Váš první test bude smovat k tomu, zda jste schopni kvantifikovat požadavek na základ stanovení kritéria jeho zpsobilosti. Toto kritérium zpsobilosti pedstavuje objektivní nástroj mení významu požadavku; je hodnotícím kritériem, zda i nikoliv zvolené ešení odpovídá požadavku. V pípad, že toto kritérium nelze pimen stanovit, pak je požadavek nejasný nebo byl nesprávn pochopen. Neexistuje-li žádné kritérium zpsobilosti, nelze zjistit, zda ešení odpovídá požadavku. Strana 4 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

5 Formulá požadavk Použijte tento formulá jako návod pro sepsání jednotlivých požadavk. Obr. Požadavek. - nezamnitelné íslo Druh požadavku (uvedený v šablon) Událost /pípad užití (seznam událostí/pípad užití, které potebují tento požadavek) Popis: v jedné vt vyjádete cíle požadavku Zdvodnní: zdvodnní požadavku Zdroj: kdo tento požadavek vznesl Kritérium zpsobilosti: mení požadavku, napíklad je-li možné zmit, zda ešení odpovídá pvodnímu požadavku Strana 5 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

6 Spokojenost zákazníka: 1-5 Nespokojenost zákazníka: 1-5 Závislosti: seznam dalších požadavk, které souvisejí s tímto požadavkem Konflikty: další požadavky, které nelze implementovat souasn s tímto požadavkem Podklady: odkaz na dokumentaci, která objasuje a vysvtluje tento požadavek Historie: vytvoení, zmny íslování požadavk Jednotlivým požadavkm piate specifické identifikaní oznaení tak, aby jej bylo možno kdykoliv v procesu vývoje nalézt. íselné schéma navrhované ve formulái je následující: Požadavek. (Requirement #) je další specifické íslo požadavku Druh požadavku (Requirement Type) je íslo kapitoly šablony pro tento druh požadavku Uvedení ísla kapitoly není nezbytn nutné, nebo máme k dispozici specifické identifikaní oznaení požadavku. Nicmén slouží jako odkaz na to, k emu se požadavek vztahuje a upozoruje nás na to, pro je tento požadavek dležitý. Rovnž schopnost porovnávat jednotlivé požadavky stejného druhu usnaduje nacházení vzájemných rozpor a dvojího výskytu stejného požadavku. Napíklad: Funkní požadavek v kapitole 9, piemž další specifické íslo je 128. Požadavek #: 128 Druh požadavku: 9 Zaznamenat as oznámení poruchy kamionu Výkonnostní požadavek vychází z kapitoly 12, piemž další specifické íslo je 129. Požadavek #: 129 Druh požadavku: 12 Strana 6 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

7 idie kamionu je nutno informovat o jejich asovém plánu 30 minut ped odjezdem z garáží. íslo události (event)/pípadu užití (use case) je identifikaním oznaením obchodní události nebo pípadu užití, jejichž souástí je daný požadavek. S jedním požadavkem mže být spojeno nkolik událostí/pípad užití, protože stejný požadavek se mže vztahovat k ad událostí. Užívání termín událost a pípad užití je v oblasti vývoje systém velmi rozšíené. Termín obchodní událost používáme v souvislosti s událostí, která se vztahuje k obchodní innosti a která zpsobí odezvu na událost v rámci sledované pracovní innosti. Termín pípad užití spuštný událostí (nebo pípad užití produktu) používáme v souvislosti s uživatelem definovanou (nebo initelem definovanou) ástí innosti v kontextu produktu. Obchodní události a pípady užití umožují zpsob pro tídní požadavk souvisejících s obchodní inností a jejich vyhledávání pi jejich implementaci ; používají se v rámci celého procesu vývoje Volere. Hodnota pro zákazníka (Customer Value) Hodnota pro zákazníka pedstavuje míru, do jaké zákazníkovi záleží na jednotlivých požadavcích. Požádejte zúastnné osoby, aby ohodnotily každý požadavek spokojenosti zákazníka známkou na stupnici od jedné do pti, kde 1 znamená nepatrný zájem na úspšné realizaci tohoto požadavku a 5 velkou spokojenost pi úspšné realizaci tohoto požadavku. Zúastnné osoby rovnž každý požadavek ohodnotí v souvislosti s nespokojeností zákazníka známkou na stupnici od jedné do pti, kde 1 znamená neutrální hodnocení a 5 extrémní nespokojenost, pokud požadavek nebude úspšn realizován. Smyslem žebíku spokojenosti a nespokojenosti je mít k dispozici nástroj, který zákazníky pinutí o požadavku pemýšlet ze dvou hledisek, a pomže jim odkrýt ty skutenosti, na kterých jim nejvíce záleží. Závislosti (Dependencies) Závislosti umožují sledovat jiné požadavky, které mají vliv na pvodní požadavek. V pípad, že k závislosti dochází pouze proto, že požadavky využívají stejné informace, pak pro implementaci této závislosti použijte jmenné Strana 7 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

8 konvence a definice (viz. Oddíl 5). K dalším závislostem dochází proto, že ešení tohoto požadavku má pozitivní nebo negativní dopad na ešení dalších požadavk. Naleznte tyto druhy závislostí pomocí kížových odkaz mezi požadavky. Nkteré požadavky, zvlášt projektové stimuly a projektová omezení, mají vliv na všechny ostatní požadavky. Konflikty (Conflicts) Konflikty umožují sledovat další požadavky, které jsou v rozporu s pvodním požadavkem. Konflikty, které jsou zpsobeny chybou, lze snadno vyešit tím, že je vyneseme na svtlo a nalezneme jejich ešení. K dalším konfliktm dochází v dsledku skutených rozpor v názoru/zámru. To jsou konflikty, kterým je teba se v koneném dsledku vnovat na základ technik jednání nebo zprostedkování. Pokud o konfliktech víte, není teba se znepokojovat, když mezi požadavky nastanou. Jste schopni tyto konflikty vyešit. Historie (History) Sledujeme požadavek ode dne jeho vytvoení pes jeho veškeré zmny. Minimalizujeme možné budoucí nejasnosti prostednictvím zaznamenávání dvod pro významné zmny. V okamžiku vymazání požadavku, zaznamenáme okamžik výmazu a jeho dvod. Datum, kdy požadavek projde kontrolou kvality, i jméno kontrolora se rovnž zaznamená. Definice používané v této šablon Kontext produktu (Context of the Product) Hranice mezi produktem, který chceme vytvoit a lidmi, organizacemi, dalšími produkty a technologiemi, které mají pímou vazbu na produkt. Pracovní kontext (Context of the Work) Pedmt, lidé a organizace, kteí mají vliv na požadavky na produkt. Kontext studie vymezuje styné body všech oblastí zájmu. Klient (Client) Osoba nebo organizace, pro níž se produkt vytváí, a která obvykle platí vývoj produktu. Zákazník (Customer) Osoba nebo organizace, která produkt koupí (všimnte si, že stejná osoba/organizace mže být souasn klient, zákazník i uživatel). Strana 8 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

9 Návrh nebo systémový návrh (Design or Systems Design) Tvorba ešení, které odpovídá požadavkm. Vývojái (Developers) Lidé, kteí navrhnou ešení a vytvoí produkt. Oblast zájmu (Domain of Interest) Pedmtná oblast, která má v kontextu studie jistou míru závažnosti. Nefunkní požadavek (Non-Functional Requirement) Vlastnost, kterou konený produkt musí mít. Událost (Event) Pojem obchodní událost používáme ve významu obchodní innosti spojené s událostí v rámci systému spojeného s pracovní inností, kterou studujeme. V dsledku této události pracovní innost vyvolá odezvu na událost. Kritérium zpsobilosti (Fit Criterion) Objektivní opatení pro stanovení významu požadavku a konen i testování, zda dané ešení vyhovuje pvodnímu požadavku. Funkní požadavek (Functional Requirement) innost, kterou produkt musí být schopen vykonávat, tedy nco, co produkt musí vykonávat. Globální omezení (Global Constraint) Omezení, která se vztahují na systém jako celek. Produkt (Product) To, co máme dodat. Mže to být software, instalace balíku, ada postup, hardware, strojní zaízení, nová organizace, zkrátka cokoliv. Požadavek (Requirement) Zmitelné vyjádení zámru v souvislosti s funkcí, kterou produkt musí vykonávat, nebo vlastnost, kterou musí mít i omezení v systému. Zúastnná osoba (Stakeholder) Zúastnná osoba je osoba, která mže ovlivnit výsledek/úspch projektu a/nebo je ovlivnna výsledkem/úspchem. Systém (System) Obchodní systém, jehož požadavky studujeme. Systémová analýza (Systems Analysis) Podrobná studie požadavk, jejíž cílem je prokázat jejich funknost pi Strana 9 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

10 vstupu do systémového návrhu. Pípad užití (Use case) Pojem událost spuštná pípadem užití (nebo pípadem užití produktu) ve smyslu uživatelsky definované (nebo initelem definované) innosti v kontextu produktu. Uživatel nebo koncový uživatel (User or End User) Ten, kdo má njakou pímou vazbu na produkt. Strana 10 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

11 1 Úel produktu (The Purpose of the Product) 1a. Problém uživatele nebo pozadí práce na projektu (The user problem or background to the project effort). Krátký popis pracovního kontextu a situace, která spouští práci na vývoji. Rovnž by mla popsat pracovní funkci, kterou uživatel od dodaného produktu oekává. Bez tohoto vyjádení projekt postrádá své oprávnní i smr. Mli byste zvážit, zda je i není problém uživatele závažný a zda je teba ho ešit. 1b. Cíle projektu (Goals of the project) Cíle v podstat znamenají jednu nebo více vt s podobným významem: K emu tento produkt chceme? Jinými slovy, skutený dvod, pro je produkt vyvíjen. Existuje reálné nebezpeí, že se tento úel na cest vývoje produktu vytratí. Jak se vývojové úsilí stále stupuje a zákazník i vývojái objevují další možnosti produktu, mže se stát, že se systém ve výstavb odchýlí od pvodních cíl. V pípad, že ze strany zákazníka zámrn nedojde ke zmn cíl, jedná se vždy o negativum. Mže být i nezbytné nkoho urit tzv. strážcem cíl, ale pravdpodobn pln postaí zveejnní cíl a periodické pipomínání tchto cíl vývojám. Povinností by pak mlo být cíle znovu potvrzovat na každé kontrolní porad. Chceme dát okamžitou a úplnou odpov zákazníkm, kteí si objednávají naše zboží po telefonu. Chceme být schopni pedpovídat poasí. Kritérium zpsobilosti Objektivní mítko, které umožní testování za úelem zjištní, zda cíl Strana 11 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

12 byl produktem dosažen. Nkolik poznámek, jak lze cíle zmit: - Stanovte pesný význam píslovcí a pídavných jmen tak, aby všechny osoby zainteresované na projektu chápaly jejich význam stejn. - Nahrate zájmena vlastními jmény konkrétních lidí a organizací. - Zajistte, aby význam každého podstatného jména byl ve specifikaci definován na jednom míst. Kupíkladu, výše uvedený píklad lze analyzovat a zpesnit následujícím zpsobem: My zamstnanci spolenosti XYZ chceme dát okamžitou v prbhu telefonického hovoru a úplnou - dostupnost produktu a ceny odpov ústní informaci komu zákazníkm osobám, které se zajímají o naše produkty našeho dodávané spoleností XYZ zboží produkty, které vyrábíme po telefonu Na základ této analýzy lze cíl peformulovat následujícím zpsobem: Zamstnanci spolenosti XYZ chtjí v prbhu telefonického hovoru informovat osoby, které se zajímají o produkty XYZ, o dostupnosti a cen produkt, které spolenost XYZ vyrábí. Kdykoliv analyzujete prostednictvím této techniky uritý cíl, budete provádt nkolik operací. Závazná pravidla pro stanovení zmitelného cíle vás vedou k tomu, abyste si položili relevantní otázky ohledn jeho významu. Ke zmení vašich cíl mžete použít techniku kladení otázek Volere v oblasti Úelu, výhody a mení. Strana 12 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

13 2 Klient, zákazník a další zúastnné osoby (Client, Customer and other Stakeholders) 2a. Klient je osoba (osoby), která platí za vývoj a která je vlastníkem dodávaného systému. Tato položka musí obsahovat jméno klienta. Mžete uvést i více jmen, ale pi uvedení více než tí jmen se vytrácí úel tohoto bodu. Klient v koneném dsledku pebírá systém, a proto musí být pi jeho dodání spokojen. Tam, kde je systém vyvíjen pro interní úely, lze roli klienta a zákazníka nahradit stejnou osobou. Pokud nemžete urit jméno klienta, pak byste se do vývoje produktu nemli vbec pouštt. V nkterých pípadech pi vývoji balíku produkt nebo produktu pro externího uživatele je klientem marketingové oddlení. V tomto pípad je nutno jako klienta uvést jméno osoby z marketingového oddlení. 2b. Zákazník je osoba (osoby), která od klienta produkt koupí. Jméno osoby, která v souvislosti s produktem vystupuje v roli zákazníka. V pípad interního vývoje v rolích klienta a zákazníka asto vystupuje stejná osoba. V pípad vývoje produktu pro masový trh mže v roli zákazníka vystupovat nkolik osob. V pípad vývoje produktu pro mezinárodní trh, mže být v každé zemi rzný zákazník (nebo profil zákazník). Zákazník se ve své roli v koneném dsledku rozhoduje, zda od klienta produkt koupí. Produkt musí být navržen tak, aby uspokojil cíle zákazníka a pitom se pizpsobil omezením klienta. I v pípadech, kdy jsou zákazníky osoby, které pracují pro jinou ást organizace klienta, mohou mít i pesto pravomoc se rozhodnout, zda chtjí nebo nechtjí svj rozpoet investovat do nového produktu. Strana 13 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

14 2c. Další zúastnné osoby (Other stakeholders) Úlohy a (pípadn) jména dalších osob a organizací, které mají na produkt vliv nebo jejichž vklad je pro vývoj produktu nezbytný. Mezi zúastnné osoby napíklad patí: Uživatelé (Users), viz. lánek 3 Sponzor (Sponsor) Testei (Testers) Obchodní analytici (Business Analysts) Odborníci v oblasti technologií (Technology Experts) Systémoví návrhái (System Designers) Odborníci v oblasti marketingu (Marketing Experts) Právníci (Legal Experts) Odborníci na danou oblast (Domain Experts) Odborníci v oblasti uživatelnosti (Usability Experts) Zástupci externích sdružení (Representatives of external associations) U každého druhu zúastnné osoby uvete: Údaje o zúastnné osob (úloha, povolání, jméno osoby, jméno organizace ), Poznatky nezbytné pro projekt, Nezbytnou míru úasti dané zúastnné osoby / kombinace poznatk, Míru vlivu dané zúastnné osoby / kombinaci poznatk, Dohodu, která eší spory mezi zúastnnými osobami, jež mají zájem na stejných poznatcích. Nejste-li schopni identifikovat zúastnné osoby, chybí vám pak jednotlivé požadavky. Strana 14 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

15 3 Uživatelé produktu (Users of the Product) 3a. Uživatelé produktu Seznam potenciálních uživatel produktu. U každé kategorie uživatele uvete následující informace: Jméno uživatele s nejvtší pravdpodobností to bude jméno skupiny uživatel jako napíklad: školáci, technici správy silnic, projektoví manažei. Role uživatele zahrnuje povinnosti uživatele. Pedmtná zkušenost (Subject matter experience) zahrnuje vdomosti uživatele o odvtví. Škála hodnocení, jako napíklad nováek, zkušený uživatel nebo mistr. Zkušenost s technologií ta popisuje zkušenost uživatele s píslušnou technologií. Škála hodnocení jako nováek, zkušený uživatel nebo mistr. Další charakteristika uživatele uvete jakoukoliv charakteristiku uživatele, která má vliv na požadavky a konenou podobu produktu. Uvete skutenosti jako: Fyzické pedpoklady /nedostatky Intelektuální pedpoklady /nedostatky Pístup k práci Pístup k technologii Vzdlání Jazyková vybavenost Vková skupina Pohlaví Uživatelé jsou lidé, kteí s produktem njakým zpsobem picházejí do styku. Úlohou klienta je zaplatit za vývoj produktu a úlohou zákazníka je produkt koupit. Úlohou uživatele je produkt užívat k práci. Charakteristiku uživatele potebujete ke stanovení požadavk uživatelnosti produktu. Strana 15 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

16 Zdroje uživatel jsou rozsáhlé a nkdy i neekané. Zvažte možnost, že vašimi uživateli budou administrativní pracovníci, prodavai, manažei, vyškolení operátoi, široká veejnost, bžní uživatelé, náhodní uživatelé, negramotné osoby, obchodní zástupci, studenti, testovací inženýi, cizinci, dti, právníci, vzdálení uživatelé, lidé, kteí systém používají prostednictvím telefonu nebo internetu, havarijní technici atd. 3b. Priorita piazená jednotlivým uživatelm (The priorities assigned to users) Ke každé kategorii uživatel piate její prioritu. To vám poskytne dležitost a prioritu jednotlivých uživatel. Rozdlte uživatele podle priority na: Klíoví uživatelé (Key users). Tato kategorie je zásadní pro trvalý úspch produktu. Pikládejte vtší význam požadavkm pedkládaným touto kategorií uživatel. Druhotní uživatelé (Secondary users). Ti budou produkt používat, ale jejich názor nemá žádný vliv na dlouhodobý úspch produktu. Pokud dochází k rozporu mezi požadavky druhotných uživatel a klíových uživatel, prioritu mají klíoví uživatelé. Nevýznamní uživatelé (Unimportant users). Tato kategorie uživatel má nejnižší prioritu. Zahrnuje obasné, neoprávnné uživatele bez zvláštních dovedností a osoby, které produkt zneužívají. Procento tohoto druhu uživatel cílem je posoudit míru významu pisuzovaného této kategorii uživatel. Pokud nkteré uživatele ve vztahu k produktu nebo organizaci považujete za dležitjší, pak je tuto skutenost nutno uvést, nebo by mohla ovlivnit zpsob vývoje produktu. Potebujete napíklad vdt, jestli existuje velký zákazník, který vznesl konkrétní požadavek na produkt a pokud nedostane to, o co stojí, mže vám vzniknout významná ztráta obchodu. Nkteré uživatele lze na seznam uvést jako uživatele bez žádného vlivu na produkt. To znamená, že tito uživatelé budou produkt užívat, ale nebudou na nm mít žádný zájem. Jinými slovy, uživatelé si nebudou ani stžovat, ani k produktu nijak nepispjí. Jakékoliv zvláštní požadavky této skupiny uživatel budou mít pi vývoji menší prioritu. Strana 16 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

17 3c. Úast uživatele (User participation) Tam, kde je to vhodné, piate ke kategorii uživatele, vyjádení jeho úasti, která je podle vašeho názoru nezbytná pro stanovení požadavk. Popište pedpokládanou formu úasti uživatele obchodní znalosti, prototypování uživatelského rozhraní, požadavky na uživatelnost, atd. Pokud je to možné, odhadnte minimální as, který vám uživatel musí vnovat, abyste byli schopni urit všechny jeho požadavky. ada projekt selže v dsledku nedostatené úasti uživatel; nkdy i proto, že požadovaná míra úasti nebyla jasn stanovena. Když si lidé mají zvolit mezi dokonením své každodenní práce a prací na novém projektu, dávají pednost své každodenní práci. Tento požadavek již od poátku jasn stanoví, jaké zdroje uživatele mají být pro projekt vylenny. 4 Nezbytná omezení (Mandated Constraints) Tato ást se vnuje omezením požadavk a konené podob produktu. 4a. Omezení v oblasti ešení (Solution constraints) Uvádjí se zde omezení na cest pi ešení problému. Mžete je považovat za nezbytná ešení. Peliv popište nezbytnou technologii vetn píslušných ísel verzí a zpsob mení pi testování plnní požadavk. Pokud je to možné, rovnž uvete dvody pro použití dané technologie. Zjistit omezení, která jsou souástí koneného produktu. Váš klient, zákazník nebo uživatel mohou upednostovat uritý design. Pokud tyto požadavky nesplníte, pak je ešení nepijatelné. Produkt musí používat souasný dvousmrný vysílací systém pro komunikaci mezi idii kamion. Produkt musí používat operaní systém Windows NT. Strana 17 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

18 Produkt musí být píruní zaízení. Chceme urit hranice, v nichž mžeme problém vyešit. Bume opatrní, protože každý, kdo má zkušenosti / znalosti v oblasti urité technologie, má sklon vidt požadavky z hlediska této technologie. V dsledku této tendence lidé zavádjí omezení v oblasti ešení z nesprávného dvodu a tato mylná omezení se pak snadno stanou souástí specifikace. Pokud zavedete mylné omezení, existuje nebezpeí, že nebudete mít tvrí volnost pi nacházení nejlepšího ešení problému. Omezení v oblasti ešení by mla pedstavovat pouze ta omezení, o nichž nelze pochybovat. Jinými slovy, a tento problém vyešíte jakkoliv, musíte použít tuto konkrétní technologii. Jakékoliv jiné ešení by bylo nepijatelné. 4b. Implementaní prostedí souasného systému (Implementation environment of the current system) Popisuje technologické a fyzické prostedí, v nmž bude produkt instalován. To zahrnuje automatická, mechanická, organizaní a další zaízení. Mezi n patí vedlejší systémy s vylouením lidského faktoru. Popsat technologické prostedí, pro njž musí být produkt zpsobilý. Prostedí vytváí omezení v oblasti vývoje produktu. Tato ást specifikace poskytuje dostatek informací o prostedí tak, aby projektanti navrhli produkt s úspšnou interakcí s okolní technologií. Z toho se odvíjejí provozní požadavky. To si lze ukázat na diagramu. Ikonka bude zastupovat samostatné zaízení nebo osobu (procesor). Nakreslete šipky, které urí interakci mezi procesory a oznate je jejich formou a obsahem. Veškeré souásti souasného systému bez ohledu na jejich druh, by mly být v popisu implementaního prostedí uvedeny. Pokud bude produkt mít na souasnou organizaci vliv, nebo pro ni bude dležitý, uvete rovnž organizaní schéma. Strana 18 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

19 4c. Partnerské aplikace (Partner applications) Popisuje aplikace, které nejsou souástí produktu, ale s nimiž produkt spolupracuje. To mohou být externí aplikace, komerní produkty nebo stávající interní aplikace. Poskytnout informace o konstrukních omezeních, které jsou zpsobeny využíváním partnerských aplikací. Na základ popisu nebo modelování tchto partnerských aplikací zjistíte a uríte potenciální problémy pi integraci. Tuto ást lze vyplnit na základ písemných údaj, model nebo odkaz na další specifikace. Údaje musí zahrnovat úplnou specifikaci všech rozhraní, které mají na produkt vliv. Posute pracovní kontextový model a zjistte, zda lze nkteré vedlejší systémy považovat za partnerské aplikace. Pro zjištní píslušných partnerských aplikací mže být rovnž nutné posoudit nkteré náležitosti celého kontextu produktu (= celé oblasti organizace, kde produkt, který popisujeme, je souástí této oblasti). 4d. Hotový software (Off-the-shelf software) Popisuje aplikace, které je nutno použít pro implementaci nkterých požadavk na produkt. Slouží ke zjištní a popsání stávajících komerních, svobodných, open source a dalších produkt, které je nutno do koneného produktu zalenit. Charakteristické chování a rozhraní balíku pedstavují konstrukní omezení. Tuto ást lze vyplnit na základ písemných údaj, model nebo odkaz na specifikaci dodavatele. Použití konkrétního balíku ešení je nezbytné. Pi shromažování požadavk mžete zjistit, že tyto požadavky jsou ve vážném rozporu s chováním a charakteristickými znaky balíku. Pamatujte, že použití Strana 19 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

20 balíku bylo nezbytné již ped zjištním celého rozsahu požadavk. Ve svtle tchto zjištní musíte zvážit, zda je po zjištní všech požadavk použití tohoto balíku životaschopné. Pokud se použití balíku nelze vyhnout, je teba vyadit rozporné požadavky. Mli byste rovnž zvážit, zda pro vás z užívání softwaru neplynou njaká právní omezení. To lze rovnž pokrýt v ásti 17 právní požadavky. 4e. Pedpokládané pracovní prostedí (Anticipated workplace environment) Popisuje prostedí, v nmž uživatelé budou používat a pracovat s produktem. Tato ást by mla popsat jakékoliv prvky pracovišt, které by mohly ovlivnit podobu produktu. Zjistit charakteristické znaky konkrétního místa, kde bude produkt používán, aby tak byly vyloueny jakékoliv obtíže pi užívání tohoto produktu. Tiskárna se nachází ve znané vzdálenosti od pracovního stolu uživatele. Toto omezení naznauje, že na tištný výstup by neml být brán velký zetel. Pracovišt je hluné, zvukové signály proto nemusejí fungovat. Pracovišt se nachází venku, proto musí být produkt vodotsný, mít displeje, které jsou viditelné na pímém slunením svtle a musí zohledovat vliv vtru pi tištném výstupu. Uživatel bude pracovat ve stoje nebo v pozici, v níž bude produkt držet. To sice naznauje možnost píruního produktu, nicmén pouze dkladná studie práce uživatele a pracovišt poskytne nezbytné údaje pro stanovení provozních požadavk. Konkrétní pracovní prostedí omezuje zpsob výkonu práce. Pestože by produkt ml pekonat jakékoliv pekážky, alternativn lze zvážit úpravu pracovišt. Strana 20 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

21 4f. Jak dlouhou dobu mají vývojái na vývoj systému? (How long do the developers have to build the system?) Zde je teba uvést jakékoliv známé termíny nebo možnosti jejich posunutí. Zjistit zásadní lhty a termíny, které mají vliv na požadavky na produkt. V pípad krátkého termínu je nutno požadavky omezit na cokoliv, co lze v této dob vyvinout. Stihnout plánované vydání softwarové verze. Mohou existovat další ásti obchodní innosti nebo softwarové produkty, které na produktu závisejí. Marketingové píležitosti. Plánované zmny obchodní innosti, které budou produkt využívat. Organizace mže napíklad otevírat nový závod a váš produkt je nezbytný pro zahájení výroby. Uvete stávající termínová omezení na základ uvedení datumu a stanovte dvody, pro jsou významná. Rovnž stanovte pedchozí data, ke kterým musí být souásti vašeho produktu k dispozici pro úely testování. Rovnž byste si mli položit otázky o dsledcích nesplnní termínu, jako napíklad: Co se stane, když systém nepostavím do...? Jaký je finanní dsledek nepostavení systému do? 4g. Jaký je finanní rozpoet systému? (What is the financial budget for the system?) Rozpoet systému vyjádený v penzích nebo dostupných zdrojích. Požadavky nesmí pekroit rozpoet. To mže omezovat poet požadavk, které lze zahrnout do produktu. Úelem této otázky je zjistit, zda je o produkt skuten zájem. Strana 21 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.

22 Je reálné vyvinout produkt v rámci tohoto rozpotu? Pokud odpov na tuto otázku zní ne, klient není pevn rozhodnut pro vývoj produktu nebo produktu nepikládá dostatený význam. V každém pípad byste mli zvážit, zda má smysl ve vývoji pokraovat. 5 Jmenné konvence a definice (Naming Conventions and Definitions) Tato ást uvádí definice všech pojm a názv vetn zkratek používaných v tomto projektu. Slovníek obsahující význam všech pojm používaných pi specifikaci požadavk. Volte jména peliv, a to tak, abyste se vyvarovali rzných, nechtných význam. Tento slovníek by ml vycházet ze standardních pojm, která vaše organizace, odvtví používá. Pojmy by rovnž mly odrážet souasn používanou terminologii v pracovní oblasti. Slovníek obsahuje veškeré významné pojmy, které projekt používá. U každého pojmu uvete jeho strunou definici. Tato definice musí být odsouhlasena píslušnými zúastnnými osobami. Pojmy jsou velmi dležité. Vyvolávají význam, který vám, je-li peliv definován, ušetí hodiny vysvtlování. Pozornost vnovaná pojmm v této fázi projektu pomáhá zjistit možné oblasti nedorozumní. Slovníek sestavený v prbhu stanovování požadavk se používá a navazuje se na nj v prbhu celého projektu. Posypový vz vz používaný pro látky bránící námraze na silnicích v zimním období. Využijte stávající odkazové a datové slovníky. Pokud pojmy nejsou píliš zavádjící, vyvarujte se pejmenovávání již existujících výraz. Od poátku projektu klate draz na potebu vyvarovat se homonym a synonym a vysvtlete, jak zvyšují náklady na projekt. Strana 22 (celkem 64) Translation 2003 Eurotel Praha, spol s r. o.