Analysis, IT, SCRUM, IDEF, RUP, software, volere, development, Requirements

1. ANALÝZA
První krok nejen při vývoji softwaru
2- část
2015 Aktualizovaná verze
Martin Paták

2. Minule jsme prošli
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

3. Obsah
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

4. Získání požadavků
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

5. Jak požadavky získávat
Získávání požadavků
 Skupinové diskuze
 Prototypy
 Interview
 Pozorování
 Znovupoužití
Modelování požadavků
 Business procesy
 Use Cases
 Modelování cílů
 Přínosů
 .
 .

8. Jak identifikovat hodnotné informace
 Jak identifikovat „špatné“ informace
 Jak najít skutečně hodnotné informace zbavené zbytečné
"omáčky"

9. Nyní
Informací bylo málo
Informace byly cenné
Shánění jakýchkoli
informací
Dříve
Informací je přebytek
Informace jsou cenné
Třídění a vyhazování
nepotřebných informací
INFORMACE

10. Nyní
Informací bylo málo
Informace byly cenné
Shánění jakýchkoli
informací
Dříve
Informací je přebytek
Informace jsou cenné
Třídění a vyhazování
nepotřebných informací
INFORMACE
UPDATE 2015
PLATÍ VŠE DOHROMADY

11. Základní problém
Máme k dispozici mnoho dat!
Minimum znalostí!
Máme málo informací!

12. Kde nám dobře definovaná informace pomůže
DEFINICE SLUŽBY
POŽADAVEK
ZADÁNÍ ÚKOLU
EMAILOVÁ KOMUNIKACE
POPIS PRODUKTU
A ÚPLNĚ VŠUDE JINDE

13. Příklad 1- Nejasnost
 Strategická orientace – IS musí být schopen podporovat dosažení
strategických cílů podniku.
 Adekvátní funkční spektrum – IS musí pokrývat všechny uživatelské
požadavky na funkce, které jsou ve shodě se strategickými cíly podniku.
 Integrovanost – IS musí být integrován z hlediska funkčního, datového,
softwarového, hardwarového a z hlediska uživatelského rozhraní.
 Otevřenost – IS musí být schopen postupně přijímat další nové
technické a softwarové komponenty, datové zdroje apod.,
 Flexibilita – IS musí být parametrický tak, aby byl schopen v provozu
pružně reagovat na nové požadavky. Tzn. změny rychle a snadno.
Stále nevíme co má IS splňovat
»Informační hodnota 0
»Informační hodnota 0
»Informační hodnota 0
»Informační hodnota 0
»Informační hodnota 0

14. Příklad 1- Nejasnost
 V určitých případech ovšem rozvětvení toku pomocí příkazu
KDYŽ(If) není nijak snadné. Platí to především o situacích,
které se mohou vyskytovat v různých okamžicích.
 Toto je testovací zpráva. Pokud jste tuto zprávu neobdržel,
kontaktujte nás na telefonu xxx.

15. Slova
 adekvátní
 měl by
 může
 parametrický
 otevřený
 jestliže
 například
 zejména
 nebo

16. Nejasnost
 Výsledkem je stejná nejasnost jako na začátku- tedy
vyhozený čas
 Co je ale horší, pisatel má pocit, že se jasně vyjádřil

17. Příklad 2- Protichůdnost
 Ergonomičnost ovládání. Na každé obrazovce bude snaha
mít maximální množství informací a maximální
jednoduchost a uživatelskou rychlost vyplňování.

18. Příklad 2- Protichůdnost
 Opensource - pokud bychom se stali garantem levnějšího
opensourcového řešení a koordinátorem vývoje
funkcionalita a features by mohl rychle narůstat. Téměř pro
jakýkoliv business – určitá nezávislost procesů a
parametrizovatelnost umožní nasadit produkt
v kterémkoliv a pro holding třeba i novém prostředí.
 Jednoduché a přehledné databáze s rezervními poli -
parametrizovatelnými, které zajistí případnou
rozšiřitelnost.
 Ergonomičnost ovládání. Na každé obrazovce bude snaha
mít maximální množství informací a maximální
jednoduchost a uživatelskou rychlost vyplňování.
»Co vlastně chceme, jednoduché řešení, „levné“ řešení …
»Opět co chceme…jednoduché db nebo rozšiřitelné
»Bez komentáře

19. Protichůdnost
 Když už si myslíme, že nějakou informaci máme, za několik
okamžiků zjistíme, že je nám na nic
 Výsledkem je větší nejasnost než na začátku … tedy opět
vyhozený čas

20. Ověřitelnost, testovatelnost ..
 Požadavek na navigaci– uživatel bude mile překvapen
přehlednou navigací systému. Vždy bude vědět, kde se nachází

21. Ověřitelnost, testovatelnost ..
 Informaci sice získáme, vcelku se zdá jasná a jednoznačná, ale
nemáme způsob jak ji ověřit … v případě úkolu či náplně práce je
to nejvíce zřejmé
• Ještě bych zapomněl –
…“Podívejte se na to a dejte mi vědět“

22. Další
 Časové měřítko
 Kdy, odkdy, jak dlouho …
 Odsouhlasení
 Rozumí všichni informaci stejně ?
 Realističnost
 Na první pohled zjevné znaky např.: neproveditelnosti

23. Jak hledat
 Absence uvedených slov
 Dlouhé věty a opakování „novinářský syndrom“
 Vyloučení všech špatných informací
 To co zůstane …pokud zůstane…

24. Co dělat když…
 Pokud od kohokoli špatné informace dostaneme, je třeba na to
upozornit a definovat rizika
 Pokud jsou špatné informace produkovány uvnitř firmy je to
riziko samo o sobě a stojí nás to zbytečný čas a peníze
 Někdy je největší umění nic nenapsat

25. Use Case a požadavky
Potřeba
Požadavek
Funkce
Důvod

26. Use Case a požadavky
Potřeba
Požadavek
Funkce
Důvod

27. Důvody
PROBLÉMEM JE ... Popis / definice problému
STAKEHOLDERS
JSOU ...
Seznam zúčastněných osob dotčených
problémem
DOPADY
PROBLÉMU JSOU
Seznam dopadů problému
ÚSPĚŠNÉ ŘEŠENÍ
ZAJISTÍ A PŘINESE
Seznam klíčových přínosů úspěšného
řešení problému
 Problémy zúčastněných osob nebo
pozadí práce na projektu
 Cíle implementace

28. PŘÍKLAD
“Chceme dát okamžitou a úplnou odpověď zákazníkům,
kteří si objednávají naše zboží po telefonu.”

29. PŘÍKLAD
“My – zaměstnanci společnosti ALFA chceme dát
okamžitou – v průběhu telefonického hovoru
a
úplnou – dostupnost produktu a ceny
odpověď – ústní informaci
zákazníkům – osobám, které se zajímají o naše produkty
našeho – dodávané společností ALFA
zboží – produkty, které vyrábíme
po telefonu.

30. PŘÍKLAD
Zaměstnanci společnosti ALFA chtějí v průběhu
telefonického hovoru informovat osoby, které se zajímají
o produkty ALFA, o dostupnosti a ceně produktů, které
společnost ALFA vyrábí.
Závazná pravidla pro stanovení změřitelného cíle vás
vedou k tomu, abyste si položili relevantní otázky
ohledně jeho významu.

31.  Správné požadavky
 Požadavky na správnou věc

32. Rozsah (oblast)
SYSTEM

33. Rozsah (oblast)
SYSTEM

34. Rozsah (oblast)
SYSTEM

35. Rozsah (oblast)
SYSTEM
DODAVATELÉ ZákazníciKonkurence

36. Příklad
Pro autoservis je třeba navrhnout nový
informační systém. Definujete rozsah
dodávaného sytému.
 Základ systému
 Okolí systému
 Co nás nebude zajímat

37. Requirements engineering
 Obor zabývající se požadavky se nazývá Requirements
engineering (RE)
 Kde se dá RE použít:
 Vývoj produktů
 Vývoj a úprava software
 …ale i plánování dovolené, stěhování …
 …tedy úplně všude

38. Requirements engineering
 Obor zabývající se požadavky se nazývá Requirements
engineering (RE)
 Kde se dá RE použít:
 Vývoj produktů
 Vývoj a úprava software
 Ale i plánování dovolené, stěhování …
 …tedy úplně všude

39. Normy pro RE
 IDEF (0,1)
 Dekompozice (kontextový rozklad)
 RUP
 UML, objekty
 VOLERE
 „Work“, „UC“

40. RUP základní přehled

41. Základním pravidlo - rozdělení
POŽADAVKU
OMEZENÍ
ŘEŠENÍ
…PŘEHLED VŠECH TRANSAKCÍ
V PROHLÍŽEČI NAPŘ.IE
3VRSTVÁ ARCH, WEB SERVER

42. Potřeba
Požadavek
Funkce
Důvod

43. Druhy požadavků
 Functional
 Co systém má dělat (dále popisováno UC)
 Non-functional
 Jaké vlastnosti má mít

44. Non-functional požadavky, omezení
 Implementační prostředí současného systému
 Partnerské aplikace
 Hotový software
 Zákonné požadavky
 Možnosti podpory

45. Globální požadavky
 Afektují všechny součásti systému
 Jejich úprava nebo doplnění stojí mnoho peněz
 Většinou mají vazbu na základní pořeby a strategii společnosti

46. Zákonné požadavky
Spadá systém do působnosti nějakého zákona?
Vyhovět zákonným požadavkům a vyvarovat se
budoucím zdržením, žalobám a právním nákladům.
“Osobní údaje je nutno implementovat tak, aby
splňovaly
požadavky zákona o ochraně osobních údajů.”
Názor právního zástupce, že produkt neporušuje žádný
právní předpis.
CÍLPŘÍKLAD
FIT
KRITERIUM

47. Zákonné požadavky
Splnit požadavky norem, aby později nedošlo ke
zdržením.
“Produkt musí vyhovovat normám v oblasti pojišťovnictví.”
“Produkt bude vyvíjen v souladu se standardem RUP
Vhodná osoba odpovědná za sledování dodržování norem.
Existují normy, jimž je nutno vyhovět?
CÍLPŘÍKLAD
FIT
KRITERIUM

48. Výkonové a kapacitní požadavky
Některé produkty, obvykle produkty, které pracují v
reálném čase, musí být schopny plnit svou funkci v
určité době. -> Nesplnění tohoto požadavku může vést ke
katastrofickému selhání
“Jakékoliv rozhraní mezi uživatelem a automatizovaným
systémem musí mít maximální čas reakce 2 sekundy.”
Jednotka měření.
Požadovaný rozsah hodnot.
Požadavky na rychlost a čas reakce
CÍLPŘÍKLAD
FIT
KRITERIUM

49. Zákonné požadavky
Splnit požadavky norem, aby později nedošlo ke
zdržením.
“Produkt musí vyhovovat normám v oblasti pojišťovnictví.”
“Produkt bude vyvíjen v souladu se standardem RUP
Vhodná osoba odpovědná za sledování dodržování norem.
Existují normy, jimž je nutno vyhovět?
CÍLPŘÍKLAD
FIT
KRITERIUM

50. Výkonové a kapacitní požadavky
Tato část vám umožňuje prozkoumat možnosti výskytu poruchy
a stanovit reálnou míru servisních zásahů. Rovněž poskytuje
příležitost zjistit očekávání klienta a uživatele v době, během níž
bude produkt dostupný.
“Produkt bude dostupný 24 hodin denně, 365 dní v roce.”
“Eskalátory budou v provozu od 6:00 do příletu posledního letu
ve 22:00.”
Požadavky na spolehlivost a dostupnost
CÍLPŘÍKLAD

51. Zabezpečit, aby produkt byl schopen poskytovat část nebo
všechny své služby při neobvyklých událostech, k nimž v rámci
prostředí došlo.
“Produkt musí i nadále fungovat v místním režimu, kdykoliv
dojde k přerušení spojení s centrálním serverem.”
“Produkt by měl v případě odpojení od elektrického zdroje
fungovat 10 minut v nouzovém režimu.”
Požadavek na odolnost
Výkonové a kapacitní požadavky
CÍLPŘÍKLAD

52. Zabezpečit, aby produkt byl schopen zpracovávat
předpokládaný objem.
“Produkt by měl zajistit občerstvení současně pro 300
uživatelů v období od 9:00 do 11:00. Maximální zátěž v
ostatních obdobích bude 150 uživatelů.”
Požadavky na kapacitu
Výkonové a kapacitní požadavky
CÍLPŘÍKLAD

53. Zabezpečit, aby architekti počítali s budoucími kapacitami a
rozšířením.
“Produkt by měl být schopen zpracovávat stávajících 100 000
zákazníků. Do tří let se očekává nárůst tohoto čísla o
500000.”
“Produkt by měl být do dvou let od svého uvedení na trh
schopen zpracovávat 50 000 transakcí za hodinu.”}
Požadavek na rozšíření
Výkonové a kapacitní požadavky
CÍLPŘÍKLAD

54. Požadavky na podporu provozu
Upozornit všechny zúčastněné na potřebu údržby
produktu.
“Nová zpráva o novém informačním systému pro řízení
musí být k dispozici do jednoho pracovního týdne od
chvíle, kdy byl tento požadavek odsouhlasen.”
“Nová meteorologická stanice musí být do systému
připojena do druhého dne.”
Nakolik musí mít produkt snadnou údržbu
CÍLPŘÍKLAD

55. Požadavky na podporu provozu
Informovat všechny zúčastněné osoby o tom, jak často
budou vydávány nové verze produktu.
“Opravné verze budou koncovým uživatelům nabízeny
jednou do roka.”
“Každý registrovaný uživatel bude mít prostřednictvím
Internetu přístup na naši stránku s podporou.”
Popis druhu údržby + množství práce v rámci daného
rozpočtu.
Existují zvláštní podmínky, které se vztahují na údržbu
tohoto produktu?
CÍLPŘÍKLAD
FIT
KRITERIUM

56. Bezpečnostní požadavky
Pochopit očekávání z hlediska důvěrnosti informací
systému.
“Do osobních záznamů svých podřízených mohou
nahlížet pouze jejich přímí nadřízení. ”
“Vstup do budovy mají pouze osoby, které prošly
bezpečnostní prověrkou.”
Název systémové funkce nebo systémových dat.
Úloha uživatele a/nebo jména prověřených osob.
Požadavky na bezpečnost
CÍLPŘÍKLAD
FIT
KRITERIUM

57. Bezpečnostní požadavky
Pochopit očekávání v oblasti integrity systémových
dat. Stanovit možné chování produktu při nechtěné
události jako je například vnější útok v důsledku
neúmyslného zneužití dat neoprávněným uživatelem
tak, aby bylo možno zajistit jeho integritu.
“Produkt by měl chránit svá data před nahráním
nesprávných dat.”
“Produkt by se měl bránit proti úmyslnému zneužití.”
Požadavky na integritu
CÍLPŘÍKLAD

58. Bezpečnostní požadavky
Zabezpečit, aby produkt splňoval zákonné požadavky a
chránil soukromí vašich zákazníků. Dnes jen málo lidí
nahlíží příznivě na organizace, které nerespektují jejich
soukromí.
“Produkt uživatele před shromažďováním dat upozorní na
zvyklosti v oblasti nakládání s informacemi.“
“Produkt upozorní zákazníky na změny v oblasti
informační politiky.”
“Produkt zpřístupní soukromé informace pouze v souladu
s informační politikou organizace.”
Požadavky na ochranu osobních údajů
CÍLPŘÍKLAD

59. Bezpečnostní požadavky
Vyvinout systém, který vyhovuje příslušným pravidlům pro
audit.
Vyvinout produkt, který je co nejbezpečnější vůči
zákeřným napadením.
Požadavky na audit
Požadavky na antivirovou ochranu
CÍLCÍL

60. Omezení
Nezbytná omezení
CÍLPŘÍKLAD
Zjistit omezení, která jsou součástí konečného produktu.
Váš klient, zákazník nebo uživatel, mohou
upřednostňovat určitý design. Pokud tyto požadavky
nesplníte, pak je řešení nepřijatelné.
Produkt musí používat současný dvousměrný vysílací
systém pro komunikaci mezi řidiči kamionů.
Produkt musí používat operační systém Windows NT.
Produkt musí být příruční zařízení.

61. Omezení
Slouží ke zjištění a popsání stávajících komerčních,
svobodných, open-source a dalších produktů, které je
nutno do konečného produktu začlenit. Charakteristické
chování a rozhraní balíčku představují konstrukční
omezení.
Hotový software
CÍL

62. Omezení
Poskytnout informace o konstrukčních omezeních, která
jsou způsobena využíváním partnerských aplikací.
Na základě popisu nebo modelování těchto partnerských
aplikací zjistíte a určíte potenciální problémy při 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.
Partnerské aplikace
CÍLPŘÍKLAD

63. Omezení
Popsat technologické prostředí, pro nějž musí být
produkt způsobilý. Prostředí vytváří omezení v
oblasti vývoje produktu. Z toho se odvíjejí provozní
požadavky.
Implementační prostředí současného systému
CÍL

64. Omezení
Zjistit charakteristické znaky konkrétního místa, kde bude
produkt používán, aby tak byly vyloučeny jakékoliv obtíže při
užívání tohoto produktu.
Pracoviště je hlučné, zvukové signály proto nemusejí
fungovat.
Uživatel bude pracovat ve stoje nebo v pozici, v níž bude
produkt držet.
Předpokládané pracovní prostředí
Pouze důkladná studie práce uživatele a pracoviště
poskytne nezbytné údaje pro stanovení provozních
požadavků.
CÍLPŘÍKLAD

65. Dokonalý požadavek

66. Příklad
 Definujte funkční (F) a nefunkční požadavky (NF) pro uvažovaný
informační systém autoservisu.
 Najděte a napište alespoň 5 F
 Najděte a napište alespoň 5 NF
 Najděte nějaké globální požadavky
 Napište příklady oblastí požadavků, které nejsou vůbec pokryty

67. Důvody pro správu
 Zachování rozsahu
 Identifikovat včas nové požadavky
 Identifikovat dopady
 Udržet aktuální zadání
 Vyjasnění
 Podpora pro akceptaci

68. Vztahy
Požadavek
1
Požadavek
2
Požadavek
3
….
Požadavek
1
X
Požadavek
2
Požadavek
3
X
….

69. Jak získat dokonalé požadavky
Priorizace požadavků
 Je nutné porozumět, které požadavky jsou nejdůležitější a
nejvíce urgentní
 Ne vše může mít nejvyšší prioritou!
 Stanovení priorit Vám pomůže:
 pracovat nejdříve na správných věcech
 přijmout kompromisní rozhodnutí
 zabývat se dodatečnými a změněnými požadavky
 Je nutné se vyhnout zájmům a emocím
 příznivý indikátor: hodnota pro zákazníka (benefit + cena)
 nepříznivý indikátor: náklady a rizika
Hodnota Náklady

70. Jak získat dokonalé požadavky
Stupnice priorit požadavků
 Jedna stupnice:
 vysoká priorita = musí být zahrnuty v příštím release
 střední priorita = musí být zahrnuty, ale mohou počkat na příští
release
 nízká priorita = mohly by být vhodné, pokud se nám hodí
 Další stupnice:
 nezbytný = kritické poslání
 důležitý = podporuje nezbytné činnosti systému
 žádoucí = funkční, kvalitativní nebo uživatelské zlepšení
 Třetí stupnice
 Základní = produkt bez tohoto požadavků není
akceptovatelný
 Podmíněný = zlepšuje produkt, ale není neakceptovatelný,
pokud chybí
 Volitelný = funkce, které by mohly být užitečné

71. Prioritizace
 Prioritizace může vést a většinou vede k zmenšení rozsahu
 Zkonsolidujte požadavky a navrhněte priority
 Dejte k schválení garantům
 Dejte architektům k odhadům pracnosti
 Vraťte zpět k schválení garantům

72. Jak získat dokonalé požadavky
Verifikace požadavků
 Revize a kontrola
 Formálně kontrolovat všechny dokumenty s požadavky!
 Zacvičovat team při formální kontrole
 Zaznamenávání akceptačních kritérií
 Experti pro danou oblast rozpracují scénáře a testované případy

73. Prototyp
Komu prototyp pomáhá?
 Pro zjištění požadavků
 analytik, klient
 Pro přesnou definici požadavků
 architekt, vývojář, tester

74. Jak získat dokonalé požadavky
Omezit rozdíly v očekávání prostřednictvím prototypů
Rozdíly
v očekávání
Revize
prototypu
Revize
prototypu
Revize
prototypu
Čas

76. Třídění požadavků
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny

77. Pravidla
 Skupina
• Druh
 Priorita
 Vlastník
 Pracnost
 Úplnost
 Fáze
Konsolidace
Validace
Třídění

78. Analýza požadavků
Analýza
a její dopady
nejen na projekty
Proces vzniku,
analýzy a
řízení požadavků
Stakeholders
Získání
požadavků
Třídění
požadavků
Analýza
požadavků
Review Změny