Analýza požadavků a tvorba objektového návrhu – postup, použité modely a diagramy.

Analýza požadavků a tvorba objektového návrhu – postup, použité modely a diagramy.

Typu požadavků:

Funkční

Mimofunkční

Může být externí nebo interní

Zainteresovaný hráč

Ředitel, investor, …

Má vliv na úspěch projektu 

Jeho hlavní úlohou je zprostředkovávat kontakt mezi programátory a zákazníky

Musí mít dobré komunikační schopnosti, schopnost abstrakce, detailní znalost problémové oblasti, organizační dovednosti

Postup sběru požadavků

Kategorie požadavků

Podle toho, jaké informace systém obsluhuje, udržuje

Jaké funkce poskytuje uživatelům

Zobrazení vztahů s okolními entitami

Systém jako černá skříňka

Zobrazuje vztahy se stakeholders + ostatními systémy včetně rozhraní

Co má výsledný produkt dělat

Kdo jsou uživatelé

Časový rámec plánu projektu

Model užití

Model = aktéři + případy užití

Případ užití = sekvence akcí, které systém provede v důsledku nějakého podnětu zvenčí a jejichž výsledek je viditelný pro uživatele

Pro modelování datové části

Musíme od klienta zjistit, co tyto doménové třídy budou

S těmito třídami budeme najisto počítat

Logický (konceptuální), fyzický – obvykle ERA, viz DB1

Hodnoty atributů datových entit se vyvíjí v čase

CRUDL matice – Create, Rename, Update, Delete List – cílem je vědět kdo a jak manipuluje s údaji

Glosář

Pojmy a jejich vysvětlení, prevence nedorozumění

Model základních entit a jejich vztahů, doménové objekty – diagram tříd

Vztah produktu k prostředí

Analýza požadavků obsahuje tři typy aktivit:

Sběr požadavků: komunikace se zákazníky a uživateli za účelem získání jejich požadavků na systém.

Analýza požadavků: identifikování nejasných požadavků, nekompletních, nejasných, nebo protichůdných a následně řešení těchto nesrovnalostí.

Zaznamenání požadavků: dokumentování požadavků v různých formách, jako běžný textový dokument, případy užití (use case), nebo specifikace procesů → dokument specifikace požadavků

Analýza a klasifikace požadavků

Identifikace zúčastněných stran ("Stakeholderů")

Případy užití (Use Case)

XP (Extrémní programování) – user stories

Funkční

Mimofunkční

Zainteresovaný hráč

Ředitel, investor, standardizační orgán, daňový poplatník…

Vliv na úspěch projektu

Zprostředkovatel mezi zákazníkem a programátory

Komunikační schopnosti, naslouchání a pozorování

Vedení schůzek, organizační

Schopnost abstrakce, nadhled, tvořivost

Metoda FURPS – model klasifikace funkčních a mimofunkčních požadavků

F (functionality) – funkčnost

U (usability) – užitečnost

R (reliability) – spolehlivost

P (performace) – výkon

S (supportability) – rozšiřitelnost

Zobrazení vztahů systému s okolními entitami

Systém jako černá skříňka

Aktéři, stakeholders

4(+1) kategorie požadavků

Klasifikace funkčnosti do 4 kategorií

Jaké informace systém obsluhuje, udržuje

Jaké funkce poskytuje uživatelům

Pro každý druh příslušné vlastnosti

Stačí jednoduché seznamy

+1 = mimo rozsah zadání, doplňková funkčnost

Esenciální, klíčové, vysokoúrovňové požadavky

Business case (proč se to tak chce)

Zdůvodnění výhodnosti-návratnosti projektu

Požadavky: co to má dělat

Obchodní příležitost

Přehled stakeholders a uživatelů

Vize zahrnuje pohled všech zainteresovaných účastníků

Přehled očekávaných schopností a funkcí produktu

Časový rozsah

Model užití

Popis požadavků na vnější funkčnost systému

Jací uživatelé k systému přistupují

Co to pro ně dělá

Jak systém zpracovává požadavky

Model = aktéři + případy užití

Kontext, primární funkčnosti

Další iterace, podružná funkčnost

Případy užití

Co to je případ užití

Sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou k výsledkům viditelným pro některého jeho uživatele

Aktéři …

Základní popis případu užití: název, stručný popis účelu, základní kroky postupu, odkazy na zdrojové informace

UML diagram případů užití

akce – atomické dále nedělitelné kroky

vnořené aktivity – volání jiných procesů (aktivit), tyto aktivity mohou být reprezentovány dalším diagramem aktivit.

Sekvenci jednotlivých kroků v diagramu aktivit určuje řídicí tok.

Modelování datové části

Použití doménového modelu

Dorozumění s klientem

S těmito třídami můžeme najisto počítat

Analýza přidá zodpovědnosti, detaily vlastností a chování

Návrh je transformuje a přidá implementační třídy

The three level of data modeling, conceptual data model, logical data model, and physical data model, were discussed in prior sections. Here we compare these three types of data models. The table below compares the different features: 

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

Datová entita typicky prochází vývojem (myšleno asi tak že hodnoty atributů entity se mění)

Životní cyklus

Cíl: vědět, kdo manipuluje s jakými údaji

Úroveň detailu

Analytická - uživatel, případ užití x informace

Návrhová - třída, funkce, proces x tabulka

Úplnost modelu požadavků

Přesně cíl/vize projektu

Seznam klíčových aktérů, jejich cíle

Seznam/diagram podstatných případů užití (dle cíle)

Stručný popis klíčových PU, znalost klíčových vlastností

Kompletní seznam aktérů, popis důležitých

Kompletní specifikace, 80-100% funkčnosti, stručné povědomí o všech

Přesný popis mimofunkčních vlastností

Kontext - vize, aktéři

Funkčnost - případy užití, user stories, procesní model…

Vlastnosti - u PU, funkcí, doménových tříd, samostatně

Obrysy požadavků agilně

Společné rysy agilních specifikací požadavků:

Cílem je říct, produkt by měl umět tohle

Název, stručný popis, odhad pracnosti, testy

Vize produktu -> Feature (více než 2 sprinty) -> Epic (větší funkcionalita, > 1 sprint) -> Skupina user stories

Glosář

Seznam důležitých pojmů

Klíčové

Stručný, všemi odsouhlasený popis = společný slovník, prevence nedorozumění

Formát různý (word, excel, access…)

Jaké jsou základní abstrakce používané v oblasti aplikace?

Podle čeho si máme vymyslet stabilní třídy pro realizaci?

Východisko = glosář

Model = doménové objekty (diagram tříd)

Doménové objekty/třídy

Doménové objekty - > třídy

Věci vyskytující se v problémové doméně

Klíčové pro fungování systému

Systém udržuje informace

Terminologie uživatele, pojmy -> názvy tříd

Vztahy mezi třídami (asociace, kardinality)

Jak je najít? Doménovou analýzou (konzultace, doménový expert, části systému podstatné z jejich pohledu - pomůže obrázek, rozhovor s uživatelem, pozorování práce)

Vztahy produktu k prostředí

Porozumění runtime a fyzickému prostředí

Odhad nákladů + podklad pro architekturu

Zelená louka - součást návrhu architektury

Postup se zaměřuje na data a jejich transformaci pomocí procesů systému,

Zaměřuje se na vytvoření logického modelu nového navrhovaného systému (esenciální model) a následně přizpůsobení implementačním požadavkům (implementační model). 

Model prostředí 

Definuje vnitřní chování systému, tak aby plnil požadavky okolí

Používané modely (diagramy) DFD, ERD, DD (datový slovník), SP (specifikace procesů), případně STD (stavový diagram)

Strukturovaná analýza. Klasický postup "shora dolů". Chápe systém jako celek a postupně ho dekomponuje na jednodušší části. Je metodicky velmi dobře zvládnut. Nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Typickým příkladem je metoda SSADM (Structured Systems Analysis and Design Method).

Často se používá modelovací jazyk UML

Model případů užití

Diagram tříd

Stavové diagramy, sekvenční diagramy a další

Umožňuje zvládnout návrh i složitých a velkých systémů

Není na první pohled vidět kudy vedou vztahy, musí se vyčíst z karet (barevné rozlišení, čáry na nástěnce…)

Hierarchie objektů – sdružovány podle logických souvislostí do balíků a podbalíků

Přirozený přechod od analýzy k návrhu

Doménová analýza nepřihlíží podstatně k jednomu účelu a způsobu použití (kontextu použití), nýbrž shromažďuje pojmy a vazby pro doménu podstatné. 

Hledají se objekty, operace a vazby, které znalci z problémové oblasti pokládají za důležité (často používají jejich názvy apod.)

Objektově orientovaná analýza. Přístup "zdola nahoru", jehož základní myšlenkou je zobecňování. Začíná se z konkrétní části systému, která se analyzuje a popíše. V dalších částech se pak hledají společné rysy, z nichž se odvozují obecné zákonitosti. Výhodou je možnost rychlého paralelního vývoje prototypového software; nevýhodou je nedostatek ověřených metodických postupů a hlubší zkušenosti s rozsáhlejšími systémy.
