52 - Získávání a modelování požadavků Flashcards

1
Q

Získávání požadavků a FURPS model požadavků

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

FURPS+

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Techniky získávání požadavků - tradiční

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Techniky získávání požadavků - moderní metody

A

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ů)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Artefakty UP související s požadavky - Model případů užití

A

• 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Artefakty UP související s požadavky - ostatní

A

• 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.).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly