Evrpský sciální fnd Praha & EU: Investujeme d vaší buducnsti Requirements Engineering Tmáš Krátký tmas.kratky@prfinit.eu http://www.prfinit.eu/cz/pdpra-univerzit/univerzitni-vyuka
Schematický phled (Sftware System) Requirements Engineering Elicitatin (schůzky, jednání, připmínkvání dkumentů, pzrvání uživatelů...) Analysis (přemýšlení, vymýšlení, debaty, pznámky, ) Specificatin (dekmpzice, psaní, pužívání ntace) Verificatin (čtení textu, schůzky, jednání, prmítání GUI,... velké bitvy rzsah... )... t vše i něklikrát, prmixvané v čase, lidech, zaměření
Rzsah Prject Scpe (PMBOOK): The wrk that needs t be accmplished t deliver a prduct, service, r result with the specified features and functins. ROZSAH == VŠECHNY ZÁVAZKY funkce, features, metdlgie, dkumenty, integrace s jinými systémy, čekávání týkající se výknnsti, bezpečnsti, zákazník chce vše c není explicitně "NE ddavatel dělá jen t c je explicite "ANO pzr na šedu zónu!!
Typy pžadavků Je třeba myslet na všechny typy pžadavků Je třeba se ptát všech relevantních skupin zainteresvaných sb (stakehlder) Minimálně následující pžadavky na vlastní funkce pžadavky na rzhranní uživatelské, sftwarvé, HW, kmunikační, nefunkční pžadavky výkn, bezpečnst, splehlivst, dstupnst, škálvatelnst, další pžadavky legislativní, vícejazyčnst, viz šablna pr specifikaci sftware
Sftwarvý prces
Sftwarvý prces Převzat z http://csse.usc.edu/csse/research/coradmo/
SWEBOK
Zásadní tázky
Zásadní tázky, které si kladu C má být výsledek analýzy? Jaký bsah má mít výstup analýzy? Jaku frmu má mít výstup analýzy? Lgická a fyzická dekmpzice? Míra detailu? Jaku pracnst má analýza? Klik kalendářníh času analýze věnvat? Jaký pčet lidí se jí má věnvat? Jak mezi paralelně pracující lidi dekmpnvat práci (de fact už vlivňuji výsledek analýzy její předčasnu dekmpzicí)? Kdy mhu už začít navrhvat architekturu? Kdy mhu už začít knstruvat? Jak má být analýza/specifikace rzprstřena v čase d psaní nabídky až p údržbu systému? Jaké jsu rzdíly mezi specifikací z nuly vs. specifikací změnvých řízení během údržby systému? Jaký je vlastně vztah mezi specifikací a architekturu (c vs. jak)?
Zásadní tázky, které si kladu Jak pznám, že na straně zákazníka se mi věnují ti správní lidé? Jaké vlastnsti má mít dbrý analytik? Jak věřím, že specifikace je specifikace th c se skutečně chce, resp. ptřebuje? Je rzumné bát se zeptat? Je rzumné nechat si schválit něc čem mám sám vnitřní pchyby? Jak pznám, že specifikace mi služí a k čemu vlastně? C s analytiky p analýze? Jak udržvat výstupy analýzy? Jak se liší analýza při vývji a při údržbě? Lze vynechat analýzu? Jak rzeznat ty správné krajvé pdmínky? Jak se budu (typicky) měnit pžadavky a jak se na t připravit? Jak detekvat nárůst rzsahu? Fenmén gld-plating? a mnh dalších
Pznatky z praxe
Pznatky z praxe pracnst: 10-30% pracnst při údržbě: 1/5 rzlžení v čase je pdle "knih" sbní předpklady žádné ghett analytiků frma nesmí zastínit bsah bsah musí být kmplexní dstatečný ppis rzsahu udržvatelnst je zásadní věc čistý princip SDLC hraje rli rzlžení výdajů pracnsti nutnst mít dvahu mdel GUI funguje strukturvaný text funguje template a checklist funguje všechny typy pžadavků jsu třeba naměřená data jsu třeba (brazvky, ) živt si prsadí, c je skutečně třeba (tázka jak blestně) c se změnu pžadavků změna neb dlžené pchpení změna neb větší míra detailu pzitivní a negativní vymezení bj rzsah
Slepé uličky
Slepé uličky Nedělat analýzu Nemyslet na architekturu Dělat puze katalg či use cases Ignrvat jiné než funkční pžadavky Nepznat, kd je skutečně důležitý stakehlder Nevěřit vlastní rzvaze a intuici Neptat se na věci, které nechci slyšet a mnh dalších
Zajímavá témata
Frma specifikace Mžné různé přístupy Strukturvaný dkument dplněný diagramy, brázky, mdely, Viktriánská nvela mnh vlnéh textu minimální struktura Izlvaný katalg pžadavků, pět bez hlubší struktury časté ne zcela ptimální Specifikace pžadavků v CASE nástrji (Enterprise Architekt, ) výrazně pracnější zatím spíše iluze pr větší systémy velmi slžité a btížně udržvatelné může fungvat např. v kntextu zavedenéh systému je nutné velmi dbře definvat pravidla a způsb tvrby specifikace
Dekmpzice pžadavků Hlavní mžnsti Feature centric (viz datvé schránky) Architecture (impsed/prpsed) centric Change request centric (viz IS VZ US) D LCA Při vývji Méně časté varianty Data centric Functin centric Use case centric Aspect centric P IC (údržba)
Mdel GUI Funguje skr ckli!!!! PwerPint (viz esipo) Excel (viz datvé schránky) HTML Speciální jazyky pr tvrbu mdelu GUI Může být výhda, pkud mdel GUI lze pužít a nezahazvat Ne vždy je třeba, ne vždy dává smysl Pmáhá pchpení systému Umžňuje dílčí verifikaci specifikace pžadavků zákazníkem
Mdelvání UML Prstředek pr reprezentaci vyvíjenéh SW na úrvni analýzy, návrhu a částečně i realizace Nutné znát (prblém u zákazníka) Nemá smysl vymýšlet něc jinéh Ne vždy je pužitelný Use case Scénáře Dbré jak dplněk (viz datvé schránky) Nelze pužít jak základ pr specifikaci Někdy jen útěk před slžitstí!
Business vs. Requirements analysis Tyt disciplíny mají velký překryv Business analýza se zaměřuje na identifikaci změn v rganizaci nutných pr dsažení strategických cílů rganizace Týká se změn ve strategii, rganizační struktuře, plitikách, prcesech a infrmačních systémech V reálu se tyt pjmy mixují a zaměňují Techniky pr business analýzu PESTLE HEPTALYSIS MOST SWOT CATWOE, MSCW, Five Why s, VPEC-T,
Gdies
Templates, checklists, literatura
Ilustrace - suhrn SVZ Jednduchá strukturvaná specifikace IS VZ US Dekmpzice dle change requests Specifikace změnvéh řízení 4907 esipo PwerPint mdel GUI Datvé schránky Funkční uživatelská specifikace, využití Use cases XLS mdel GUI
Otázky???