52 - Získávání a modelování požadavků Flashcards
Získávání požadavků a FURPS model požadavků
Určenı́ požadavků je hlavně manažerská činnost pro zı́skánı́ specifikace požadavků na produkt od zákaznı́ka.
- Je potřeba hluboké pochopenı́ požadavků, jinak nastanou nákladné změny v budoucnu.
Získávání požadavků je proces komunikace mezi analytikem a zákazníkem, výsledkem je obchodní model použití a diagram tříd
• Uvádí se, že průměrně 25% požadavků se v průběhu projektu mění tj. nelze je „zmrazit“ nebo úplně definovat.
• UP chápe požadavky jako měnící se, vyvíjející se.
Práce s měnícími se požadavky:
• Vyžaduje systematický přístup ke zjišťování, dokumentování, organizování a sledování měnících se požadavků.
• Vítány jsou jakékoliv metody zjišťování požadavků (elicitation), které zvýší účast zákazníka/uživatele.
FURPS+
FURPS+ model - funkční / nefunkční požadavky (URPS)
FURPS:
• F - Function - Funkční - rysy, schopnosti, bezpečnost, … - co má systém dělat - vstupy, výstupy, funkce
* U - Usability - Použitelnost + Znovupoužitelnost - lidské faktory, nápověda, dokumentace, uživatelské rozhraní, ... - jednoduchost používání systému * R - Reliability - Spolehlivost - frekvence výpadků, zotavitelnost, ... - frekvence a vážnost selhání systému a zotavení po nich * P - Performace - Výkonnost + efektivita - doba odezvy, dostupnost, propustnost, využití zdrojů, ... - očekávání týkající se doby odezvy systému, průchodnosti, paměťi,.. * S - Suportability - Podporovatelnost - přizpůsobitelnost, udržovatelnost, konfigurovatelnost, internacionalizace, ... - udává, jak rychle lze systém pochopit, opravit nebo rozšířit
FURPS+ doplňková omezení :
• Implementace - zdroje, jazyky, nástroje, …
• Rozhraní - vynucené vazby na další systémy
• Provozu - správa systému
• Fyzická - média, uspořádání, …
• Právní - licence, …
Kvalitativní požadavky = URPS
Techniky získávání požadavků - tradiční
Získávání požadavků je proces komunikace mezi analytikem a zákaznı́kem,
výsledek:
- obchodnı́ model použitı́ (upravený use-case)
- diagram třı́d
a) Tradiční (jednoduššı́, levnějšı́, efektivnı́ pro menšı́ projekty)
Interview - rozhovor se zadavatelem, doménovým expertem
○ Rozhovor se zákaznı́kem → požadavky na použitı́
○ Rozhovor s odbornı́kem v oblasti → znalost problematiky
* používat nestranné otázky * naslouchat * nepodsouvat řešení Dva typy: ○ strukturované - předpřipravené otázky případně nabízené odpovědi ○ nestrukturované - neformální
Dotazníky - zpravidla doplněk interview, pasivní technika
* vı́ce času, méně ostychu, ale klient se nemůže zeptat * Výhoda: čas na rozmyšlení odpovědi * Nevýhoda: není možné otázky vysvětlit
Pozorování - pozorování uživatele při práci
* sledovánı́ procesu, aktivnı́ zapojenı́ nebo s doprovodem * třeba pozorovat delší dobu za různých podmínek * Nevýhoda uživatelé mají tendenci se chovat jinak jsou-li pozorováni Formy: ○ pasivní - pouze pozorujeme ○ aktivní - analytik se aktivit účastní § vysvětlující - uživatel aktivity vysvětluje
Studium dokumentů organizace = studium zdrojů znalostí o dané doméně (časopisy, internet, knihy, dokumenty organizace, formuláře, sestavy, stávající systém, …)
• používáme prakticky vždy
Techniky získávání požadavků - moderní metody
b) Moderní metody (složitějšı́, dražšı́, vhodné pro velké a rizikové projekty)
Prototypování - rychlé řešení pro získání zpětné vazby
• nejpoužívanější moderní metoda - zákaznı́k dostane celý systém, ale bez plné funkčnosti
• prezentuje především uživatelské rozhraní
• Prototypy mohou být jak funkční (ukázkové aplikace, …) tak nefunkční (diagramy, videa, prototypy obrazovek na papíře)
Vhodné v případě, že: • nelze informace zjistit jinak • uživatelé nemají jasnou představu • při konfliktu požadavků • problémech v komunikaci • je obtížné získat zpětnou vazbu
Brainstorming = setkání více lidí, kteří se musí dohodnout na výsledné podobě
• používá se pokud všichni aktéři vidí jen “svoje” požadavky a je třeba najít konsensus
• konference s moderátorem, vı́ce nápadů, odstraňuje rozpory
Postup:
• moderátor pokládá otázky
• účastníci anonymně napíší svoje nápady
• o nápadech se diskutuje, hlasuje, …
Joint Application Development (JAD) = podobné brainstormingu, založena na skupinové spolupráci a schůzkách max 25.lidí
• moderátor, pı́sař, zákaznı́ci a vývojáři
Role:
• vedoucí/moderátor - komunikace, znalost domény
• písař - zaznamenává průběh
• zákazníci - diskutují o požadavcích, rozhodují
• vývojáři - ujasňují si požadavky, doplňují podrobnosti
Rychlý vývoj aplikací (Rapid Application Development - RAD) = upřednostňuje rychlost před kvalitou (to přináší rizika)
• pouze pro malé projekty
• užití při prototypování (generátory formulářů, aplikací)
• zahrnuje celý vývoj projektu (nejen sběr požadavků)
Artefakty UP související s požadavky - Model případů užití
• Model případů užití
○ textové dokumenty zaměřující se na obchodní a typické použití z pohledu uživatele
Úrovně popisu: • Stručný - popisuje pouze hlavní scénář • Neformální - popisuje i alternativní scénáře • Plný - strukturovaný, detailní, všechny scénáře Doporučení: • zaměřit se na úmysl aktéra ne na způsob provedení • co systém udělá ne jak • zaměření na aktéry • důležitý je textový popis ne "druhořadý" diagram
Artefakty UP související s požadavky - ostatní
• Doplňující specifikace -> typicky nefunkční požadavky, to co nelze vyjádřit v případech užití,
• Slovník (Obchodnı́ slovnı́ček)
○ definice pojmů, zahrnuje také datový slovník (typy dat, omezení, rozsahy)
○ ustanovuje pojmy pro obě strany, důležitý pro jednoznačnost na obou stranách.
○ Může být postaven na jiném slovnı́čku, ale je nutná revize. Při budovánı́ se pojmy přidávajı́ v každé fázi projektu.
* Vize = shrnuje požadavky vysoké úrovně, shrnuje přínos projektu (business case) * Pravidla (business/domain rules) = pravidla aplikační domény, legislativa, ... • Model rozsahu systému ○ určuje rozsah systému, při změnách požadavků by se rozsah neměl měnit ○ je DFD (Data Flow Diagram) řádu 0, tedy pouze systém a jeho okolı́ (nenı́ součástı́ UML). • Obchodní model použití ○ model použitý na vysoké úrovni abstrakce, definuje procesy bez ohledu na jejich realizaci, je transformován na případy užití. ○ (je use-case diagram, ale na vysoké úrovni abstrakce.) • Obchodní diagram tříd ○ diagram hlavních obchodních objektů systému na vysoké úrovni abstrakce ○ je opět vı́ce abstraktnı́ model diagramu třı́d, třı́dy zde jsou spı́še vyššı́ entity, jejichž atributy nejsou plně důležité. • Vyjednávánı́ a validace požadavků -> jsou potřeba kvůli nejasnosti nebo nereálnosti požadavků (mohou se překrývat, být v rozporu). Také je potřeba eliminovat nepotřebné požadavky nebo požadavky mimo oblast. ○ Využı́vá se matice požadavků, sestavuje se žebřı́ček priority požadavků. * Správa požadavků -> se stará o identifikaci, klasifikaci, organizaci a dokumentaci požadavků. Každý požadavek má jednoznačné ID, vhodné při použitı́ CASE. Požadavky tvořı́ hierarchii a je potřeba je verzovat. * Obchodnı́ model požadavků (BOM) je modelovánı́ procesů ve firmě, pro kterou se tvořı́ produkt. Modeluje pro zákaznı́ka, zjednodušuje, zavádı́ obchodnı́ slovnı́ček. * Doménový model požadavků (DOM) modeluje oblast (doménu) bussiness procesu, kterého se projekt týká přı́mo. Použı́vá konkrétnějšı́ diagramy než BOM a rozšiřuje slovnı́ček. * Dokument požadavků je hlavnı́ a zásadnı́ výstup procesu určenı́ požadavků. Obsahuje soupis všech funkčnı́ch a nefunkčnı́ch požadavků, specifikuje cı́le projektu, rozsah apod. Většinou se tvořı́ na základě standardizované šablony (IEEE aj.).
