Lekce 2 - 1
Přehled metodiky vývoje GIS aplikací
(vytvořeno pro seminář na FIMU: Vybrané kapitoly z GIS, podzimní semestr)
Lekce 2: Model požadavků
Kategorizace požadavků...................................................................................................................... 2
Hlediska (dimenze) kvality software podle metody FURPS............................................................. 2
Častá rozšíření FURPS...................................................................................................................... 2
Hlavní činnosti při analýze požadavků ................................................................................................ 3
Identifikace zúčastněných stran (stakeholders).............................................................................. 3
Interview se zúčastněnými stranami............................................................................................... 3
Vytvoření seznamu (katalogu) požadavků ...................................................................................... 3
Vytvoření modelu požadavků.......................................................................................................... 4
Stanovení měřitelných cílů.............................................................................................................. 5
Prototypování.................................................................................................................................. 5
Přiřazení požadavků prvkům modelu navrhovaného systému ....................................................... 5
Lekce 2 - 2
Kategorizace požadavků
Požadavky lze kategorizovat několika způsoby. Jednu z možností poskytuje metoda FURPS, která byla
vytvořena společností Hewlett-Packard na základě potřeby definovat, jak poznat a ověřit kvalitu
dodávaného software. První zmínky o této metodě pocházejí z roku 1986 a veřejně myšlenky
publikovali Robert Grady a Deborah Caswell v knize „Software Metrics: Establishing a Company–Wide
Program“ v roce 1987.
FURPS se dívá na kvalitu software nebo informačního systému z pěti základních hledisek: funkčnost,
užitečnost, spolehlivost, výkon a rozšiřitelnost. Metoda na nejvyšší úrovni definuje, co by mělo být
hodnoceno, ale nespecifikuje, jakým způsobem mají být oblasti hodnoceny. V těchto jednotlivých
oblastech musí být dále vytvářeny konkrétní metriky a jejich hodnoty. Pokud chcete dodávat
zákazníkům opravdu dobrý software, tak je vhodné začít už při plánování testování zohledňovat tyto
oblasti.
Hlediska (dimenze) kvality software podle metody FURPS
 F (functionality) – funkčnost. Zaměřuje se na hlavní funkčnosti a schopnosti programu
(chování), zda software naplňuje požadavky byznysu a podporuje byznys procesy.
 U (usability) – vhodnost k použití. Hodnotí se zejména z pohledu koncového uživatele; jak
snadno lze aplikaci použít, jakým celkovým dojmem působí aplikace, dokumentace a školící
materiály.
 R (reliability) – spolehlivost. Jedná se o hodnocení četnosti a závažnost chyb, přesnosti
zpracování vstupů a výstupů. Pro vyjádření spolehlivosti se často používá
metrika MTBF (mean time between failures), což je střední doba mezi chybami nebo
selháními. V této oblasti se také sledují možnosti obnovení provozu a zotavení se z výpadku.
Patří sem také zátěžové testy a testy zotavení aplikace po selhání některých komponent
řešení.
 P (performace) – výkon. Hodnocení celkové rychlosti odezev systému a zpracování klíčových
byznys aktivit. Zároveň se sledují i technické parametry testovaného systému, např. vytížení
zdrojů OS, zatížení síťového provozu, rozložení zátěže na jednotlivé komponenty systému.
 S (supportability) – schopnost být udržována. Dalším hlediskem hodnocení je oblast údržby
a podpory aplikace, její testovatelnosti. V této oblasti se taktéž hodnotí i přizpůsobitelnost a
rozšiřitelnost o nové vlastnosti. Důležitá je také schopnost zapojení aplikace do existujících
procesů podpory a údržby SW.
V poslední době se metoda FURPS rozšířila o znaménko +, na FURPS+. Postupem času totiž přestaly
jednotlivé kategorie dostačovat, a proto bylo zavedeno toto „plus“, které označuje, že je metoda
rozšířena o další dílčí elementy nebo podoblasti.
Častá rozšíření FURPS
 Implementace – různá omezení, jazykové mutace, speciální nástroje a HW
 Rozhraní – efektivita rozhraní na externí IT systémy
Lekce 2 - 3
 Operační systémy – speciální požadavky na OS a jeho případnou úpravu, včetně návrhu další
správy
 Obchodní a právní aspekty – licencování a případná právní omezení pro různé demografické
regiony
Pro potřeby projektu v semináři Vybrané kapitoly z GIS postačí členění na funkční a nefunkční
požadavky.
Hlavní činnosti při analýze požadavků
Identifikace zúčastněných stran (stakeholders)
Identifikace zúčastněných stran (stakeholderů). Zúčastněné strany se neomezují pouze na organizaci,
která pořizuje IS. Dalšími zúčastněnými stranami mohou být:
 ty organizace, které se integrují na pořizovaný IS
 jakékoli tzv. back office systémy nebo organizace (které podporují pořizovaný IS)
 vrcholový management
Interview se zúčastněnými stranami
Rozhovory (interview) se zúčastněnými vysvětlují požadavky, které jsou definovány v zadání projektu,
a odhalují další požadavky, které v zadání původně nebyly. Požadavky zúčastněných stran mohou být
protichůdné, požadavky je tedy nutné konsolidovat. V rámci interview je vhodné identifikovat i ty
požadavky nebo vlastnosti systému, které pořizovaný IS nebude mít.
Při zahájení projektu je nutné stanovit, kdo bude mít rozhodující slovo při finalizaci požadavků.
Vytvoření seznamu (katalogu) požadavků
Jedním z tradičního způsobu dokumentování požadavků je seznam požadavků. Tento způsob
použijeme i v projektu v semináři Vybrané kapitoly z GIS.
Požadavky zařazené do návrhu systému - tabulka obsahuje požadavky uživatele (klienta) zahrnuté do
návrhu systému.
P. č. Popis požadavku Typ (F/N) Zdroj Kritérium splnění
1
2
…
Požadavky nezařazené do návrhu - tabulka obsahuje požadavky uživatelů (klienta), které nejsou
zařazeny do návrhu systému (pokud takové existují).
P. č. Požadavek Zdroj Zdůvodnění
1
2
…
Lekce 2 - 4
Vytvoření modelu požadavků
Využití UML prvku „requirement“.
Příklad:
req Požadavky
Funkční požadavky
+ Doplnění řízení může být předloženo před nebo po převzetí výzvy posledním z obesílaných účastníků
+ Snížit chybovost zápisu událostí
+ Správné ukončování běžících lhůt
+ Správné ukončování přerušení lhůt
+ V řízení typu PD zjednodušit výběr zapisovaných událostí funkce 100: Navázání řízení
+ Výběr zapisované události musí být ze seznamu pouze událostí relevantních požadovanému úkonu
+ Výběr řízení Z pro navázání musí předcházet výběru zapisované události
+ Zápis správné události mezi řízeními PD a Z
+ Zlepšit výpočet dob zpracování a přerušení řízení
Nefunkční požadavky
+ Analýza dopadu jednotlivých úkonů na statistiky řízení
req Struktura dílčích požadavků k modelovému požadavku č. 1
V řízení typu PD zjednodušit výběr
zapisovaných událostí funkce 100:
Navázání řízení
(from Funkční požadavky)
Snížit chybovost zápisu událostí
(from Funkční požadavky)
Výběr řízení Z pro
navázání musí
předcházet výběru
zapisované
události
(from Funkční požadavky)
Výběr zapisované
události musí být ze
seznamu pouze
událostí
relevantních
požadovanému
úkonu
(from Funkční požadavky)
Doplnění řízení
může být
předloženo před
nebo po převzetí
výzvy posledním z
obesílaných
účastníků
(from Funkční požadavky)
Zlepšit výpočet dob zpracování a
přerušení řízení
(from Funkční požadavky)
Správné
ukončování
běžících lhůt
(from Funkční požadavky)
Správné
ukončování
přerušení lhůt
(from Funkční požadavky)
Analýza dopadu
jednotlivých úkonů
na statistiky řízení
(from Nefunkční požadavky)
Zápis správné
události mezi
řízeními PD a Z
(from Funkční požadavky)
Lekce 2 - 5
Stanovení měřitelných cílů
Osvědčenými postupy při specifikaci požadavků je klást si otázku, aby bylo možné odhalit skutečný cíl
požadavku. Analytici pak můžou navrhnout testy tak, aby bylo možné zjistit, nakolik při plnění každého
požadavku bylo dosaženo cíle.
Prototypování
Prototypy jsou reálné modely (mock-ups) aplikací (ukázky, jak bude aplikace vypadat). Prototyp
umožňuje uživatelům vizualizovat aplikací, která dosud nebyla vytvořena. Prototypy pomohou
uživatelům získat představu o tom, jak bude systém vypadat, aby uživatelé mohli ověřit design
uživatelského interface před finálním vytvořením systému. Zavedením prototypů dochází
k významnému zlepšení komunikace mezi uživateli a vývojáři.
Vytváření prototypů aplikace vede k menším pozdějším změnám v aplikaci, a tedy nižším celkovým
nákladům. Nicméně, existuje několik problémů spojených s prototypováním:
 Jakmile manažeři vidí prototyp, můžou jen těžko pochopit, že konečný výsledek nebude
vyroben ve stejném čase.
 Designéři často používají prototyp v reálném systému, protože se obávají, aby 'neztráceli čas'
a nezačínali znovu.
 Prototypy jsou nápomocné hlavně při návrhu uživatelských rozhraní a návrhu obrazovek.
Nemohou nic říct o tom, jaký byl původní požadavek.
 Designéři a koncoví uživatelé se soustředí příliš na uživatelské rozhraní a příliš málo na tu část
systému, která slouží k podpoře procesů.
Přiřazení požadavků prvkům modelu navrhovaného systému
Pokud je vytvořen model požadavků (například v UML), je vhodné jednotlivé požadavky nebo jejich
skupiny v průběhu analýzy přiřazovat prvkům modelu. Typy prvků jsou voleny podle toho, jakého
charakteru jsou požadavky. Nejčastěji:
 prvkům typu use case, které vyjadřují funkční specifikaci modelu, jsou přiřazovány požadavky
na funkčnost systému,
 prvkům typu class, které reprezentují entity (konceptuálního) datového modelu, jsou
přiřazovány požadavky na data systému.
Lekce 2 - 6
Příklad:
req Požadavky
Evidence projektů
F001 - Ze systému MS2014+ budou přebírány zadavatelem definované informace o projektech. Iniciátorem výměny dat
bude MS 2014+, přenos dat bude dávkový.
F002 - Informace o projektech převzaté z MS2014+ nebude možné v IS ESF 2014+ editovat
F003 - Data o projektech bude možné v systému IS ESF 2014+ doplnit o další informace nezbytné pro monitoring projektu
v rámci IS ESF 2014+. Detailní struktura informací o projektu bude definována v rámci analytické fáze projektu.
F004 - Pro každý projekt bude jednoznačně určena osoba zastupující realizátora projektu. Zástupce realizátora bude mít
oprávnění k editaci doplněných informací o projektu (např. stručný popis projektu, přehled plánovaných výběrových řízení
apod.).
notes
Informaci o osobách spojených s projektem bude možné převzít ze systému MS2014+, pokud budou tyto informace
poskytnuty. Registraci uživatele v IS ESF 2014+ na základě těchto dat musí ale následně potvrdit oprávněný uživatel.
F005 - Zástupce realizátora bude mít možnost doplnit k projektu další osobu, která bude oprávněna editovat data projektu
F006 - Pracovníci ŘO budou mít oprávnění k doplnění informací k projektu
uc Evidence projektů
Převzetí informací o
projektech z MS 2014+
Doplnění a editace dat o
projektech
F001 - Ze systému MS2014+ budou přebírány
zadavatelem definované informace o projektech.
Iniciátorem výměny dat bude MS 2014+, přenos dat
bude dávkový.
(from Požadavky)
F002 - Informace o projektech
převzaté z MS2014+ nebude možné
v IS ESF 2014+ editovat
(from Požadavky)
F003 - Data o projektech bude možné v systému
IS ESF 2014+ doplnit o další informace
nezbytné pro monitoring projektu v rámci IS ESF
2014+. Detailní struktura informací o projektu
bude definována v rámci analytické fáze
projektu.
(from Požadavky)
F004 - Pro každý projekt
bude jednoznačně určena
osoba zastupující realizátora
projektu. Zástupce
realizátora bude mít
oprávnění k editaci
doplněných informací o
projektu (např. stručný popis
projektu, přehled
plánovaných výběrových
řízení apod.).
(from Požadavky)
F005 - Zástupce realizátora bude mít možnost
doplnit k projektu další osobu, která bude oprávněna
editovat data projektu
(from Požadavky)
F006 - Pracovníci ŘO budou mít oprávnění k
doplnění informací k projektu
(from Požadavky)
:Osoba pověřená
realizátorem
projektu
:Systém
:Správce systému
:Pracovník ŘO OPZ
:Zástupce
realizátora projektu
F041 - Dle charakteru projektu bude ŘO moci
rozhodnout a zadat, zda je možné pro daný
projekt vytvářet seznamy podpořených osob
pomocí odhadování informací o osobách.
Projekty bude možné vybírat jmenovitě, či dle
hodnot atributů (např. výzva).
(from Požadavky)
Uchování historie dat
F099 - Pro data o projektech, akcích a
podpořených osobách bude evidovaná
historie stavu dat. Pro každou editaci
dat bude uvedeno, který atribut byl
změněn, kdo změnu provedl, jaká byla
původní hodnota atributu a jaká je
hodnota nová
(from Požadavky)
«include»