Požadavky na SW

1. Požadavky na SW Od zadání k architektuře aplikace

2. Modelování podnikových procesů Specifikace požadavků zákazníka Analýza a návrh Implementace Realizace Poznání reality Návrh řešení Nové potřeby Specifikace požadavků • Specifikace požadavků je 1. fáze návrhu IS (po podnikovém modelování) a je nástrojem poznání potřeb budoucího uživatele. • Cílem je vymezit systém z hlediska požadavků na funkcionalitu, technologie, bezpečnost atd. Je to základ pro veškeré práce na projektu.

3. Inženýrství požadavků • Před začátkem OOA (objektově orientovaná analýza) nebo OOD (objektově orientovaný návrh, design) je třeba vytvořit alespoň rámcový přehled o tom, co má systém dělat a jaký je smysl požadavků a jaká je jejich specifikace (vše v terminologii, které rozumí uživatel). • Tzv. Inženýrství požadavků (Requirements Engineering) spočívá ve stanovení služeb, které by měl vyvíjený systém poskytovat, včetně různých omezení. Jediný způsob zachycení požadavku v OOA je případ užití, toto ale neplatí pro nefunkční požadavky. • Základem jsou interview s pověřenými zástupci zadavatele, nebo studium podnikových norem zákazníka, BPM (Business Process Model), studium standardů problémové oblasti, ..

4. Specifikace požadavků • Při analýze požadavků je nutno uvažovat tyto faktory: • Zaměření podnikových činností • Okolí podniku • Legislativa • Strategické a podnikatelské plány • Omezení zdrojů (personální a technické) • Finanční omezení • Termínová omezení • Platí obecně, nejen u OOA (resp. OOD).

5. RUP (Rational Unified Process) a požadavky • V analýze a návrhu nás zajímají následující činnosti: • Vyhledání aktorů a případů užití • Detail případu užití (scénáře) • Struktura modelu případu užití • Pracovní postup v RUP je rozšířen o následující procesy • Vyhledání funkčních požadavků • Vyhledání nefunkčních požadavků • Prioritizace jednotlivých požadavků • Sledování požadavků k případům užití

6. Formát požadavků • Požadavek lze definovat stručně jako „specifikaci toho, co by mělo být implementováno”. • Funkční požadavky (functional req.) určují, jaké chování nebo jaké služby bude systém nabízet • Nefunkční požadavky (non-functional req.) specifikují vlastnosti nebo omezující podmínky daného systému (kvalita, technologie, dokumentace, řízení projektu, ..) (Požadavek vyjadřuje CO? nikoliv JAK?) • Formát pro vyjádření požadavků • <id><systém>bude<funkce>, kde • id jedinečný identifikátor • název systému • „bude” – klíčové slovo • vykonávaná funkce

7. Funkční požadavky Zákazníci Produkty Objednávky Prodejní kanály Platby Veškeré požadavky na funkce a služby od zadavatele Nefunkční požadavky Výkon Kapacita Dostupnost Shoda se standardy Zabezpečení Dokumentace Organizace projektu Technologie Klasifikace požadavků (taxonomie)

8. Modelování nefunkčních požadavků • Nefunkční požadavky je třeba zaznamenat a neustále je promítat do návrhu řešení. • Použít katalogový záznam • Identifikační číslo • Datum poslední změny • Kdo ho požaduje, kdo ho přijímá • Priorita požadavků • Stručný název požadavku • Detailní popis požadavku • Návaznost na další požadavky • Komplexnost/složitost požadavku

9. Příklady nefunkčních požadavků • Realizace projektu v přírůstcích • Pouze jedna zodpovědná osoba na straně dodavatele • Realizace kontrolních dnů každý měsíc • Podpora hotového produktu po dobu 7 let • Provoz na platformách Linux/Unix • Podpora uložení dat v DB ORACLE • Odezva systému do 3 sekund při všech operacích • …

10. Záznam požadavku • Atributy požadavků (pro dodatečné informace) • Status • Význam • Riziko • Stabilita resp. cílová verze • Termín, datumSplatnosti • Zdroj • Priorita (Must have, Should have, Could have, Want to have) • Odpovědná osoba (kdo požadavek požaduje a kdo ho přijímá) • Dále datum vytvoření požadavku a datum poslední změny, detailní popis, návaznosti na jiné požadavky, komplexnost/složitost požadavku (pokud je možné toto určit).

11. Získání požadavku • Získávání požadavků (mapa pracovního modelu pracovníků). Pro co nejpodrobnější zachycení požadavků a jejich nejhlubší analýzu se používá • Vyřazení • Deformace • Zobecnění. • Nejlepší způsob je konzultace a pohovor se zainteresovanými osobami, dotazník, spontánní diskuze. • Správně formulované požadavky by měly být vyjádřeny strukturovaným jazykem, aby bylo možné využít nástroje pro podporu požadavků.

12. Modelování případů užití • Je jedna z forem inženýrství požadavků, skládá se z aktivit (viz. cvič.) • Nalezení hranic systému (ohraničení zobrazené kolem případů užití, jež je vyznačením hranic modelovaného systému – v UML 2 subjekt • Vyhledání aktorů • Nalezení případu užití • Tvorba slovníku pojmů (terminologie v dané oblasti, pozor na synonyma a homonyma) • Tento use case model je hlavním zdrojem objektů a tříd a prvotním vstupem k modelování tříd. • Zdroje pro model případu užití • Podnikový model • Model požadavků (seznam funkčních a nefunkčních požadavků) • Seznam vlastností (v souladu s vizí podniku)

13. Specifikace případu užití • Specifikace případu užití (doporučeno používat jednotný a konzistentní standard v rámci celého projektu) • Název + jedinečný identifikátor • Stručný popis • Aktoři (hlavní – spouští UC, vedlejší- jsou v interakci s UC po jeho spuštění) • Vstupní (co musí být PRAVDA předtím, než se spustí UC) a výstupní podmínky (stav systému po skončení UC) • Hlavní scénář • Alternativní scénáře Vše ve srozumitelné strukturované češtině Ostatní viz. cvičení

14. Softwarový projekt • Účastníci SW projektu • Zákazníci, uživatelé, analytici, vývojáři, testeři, dokumentátoři, vedoucí projektu, právníci, lidé z výroby, prodeje, marketingu, technické podpory • Typy požadavků ještě jednou - vztahy mezi různými typy požadavků • Viz Obr.

15. Vývoj a správa požadavků • Základní discipliny práce s požadavky viz Obr. • Vývoj požadavků jako proces Doporučeno postupné upřesňování, iterativní postup, správnost svých analýz ověřovat s uživateli. • Správa požadavků jako proces Definice požadavků, posouzení navrhovaných změn, zpracování změn, aktualizace plánů vývoje podle změn, vyjednávání, sledování požadavků od návrhu po implementaci a testování.

16. Hranice mezi vývojem a správou požadavků

17. Výhody kvalitního zpracování požadavků • Méně chyb v požadavcích • Snížení objemu přidělávané práce • Méně nepotřebných funkcí • Nižší náklady na vylepšování • Rychlejší vývoj • Méně nedorozumění • Menší pravděpodobnost tichého rozšiřování rozsahu , menší chaos v projektu • Přesnější odhady • Spokojenější zákazník i vývojář

18. Vlastnosti požadavků a celé specifikace • Vlastnosti dobře popsaných požadavků • Úplnost • Správnost • Proveditelnost • Nepostradatelnost • Priorita • Jednoznačnost • Ověřitelnost • Vlastnost celé specifikace • Úplnost • Jednotnost • Přizpůsobitelnost • Dohledatelnost

19. Vztah mezi zákazníkem a vývojáři • Základní práva a povinnosti softwarového zákazníka viz tab 1 a tab.2 dále. • Faktem je, že na začátku projektu všechny požadavky nemohou být známy a budou se v průběhu času měnit. • Podepsaná směrná verze specifikace= závazná podoba požadavků v daném čase. Další úpravy se budou provádět kontrolovaným způsobem(analýza důsledků na termín, cenu a další faktory).

21. Aktivity vývoje požadavků • Etapy : Sbírání, analýza, specifikace, kontrola. • Sbírání(popsat rozsah a jeho vizi, najít třídy uživatelů a klíčovou osobu pro každou třídu uživatelů, vybrat skupinu typických uživatelů, najít jejich UC, najít systémové události a odpovědi na ně, uspořádat workshop, sledovat uživatele při práci, hledat nápady na zlepšení…) • Analýza (vytvořit kontextový diagram, vytvořit prototyp GUI, analyzovat proveditelnost požadavků, prioritizovat požadavky, modelovat požadavky (ERD, STD, DFD, diagram tříd, mapa dialogů, SD, rozhodovací tabulky, rozhodovací stromy,..), vytvořit DD, rozdělit požadavky do subsystémů,…) • Specifikace (psát podle šablony, najít zdroje požadavků, ID, zapsat pravidlo, popsat kvalitativní parametry jako je výkon, efektivita, spolehlivost, použitelnost,…) • Kontrola (provést revizi, testovat požadavky) • Proces vývoje požadavků viz Obr.

22. Aktivity správy požadavků • Stanovit postup verzování změnového řízení včetně zřízení komise • Pro každou změnu provést analýzu • Verzovat i dokumentaci požadavků • Vést historii změn (datum, změna, autor a důvod) • Sledovat stav každého požadavku • Používat nástroj pro správu požadavků • Vytvořit spojovací matici (požadavek X odkaz na implementační kód, testy)

23. Analytik požadavků • Úkoly (definovat uživatele, sbírat a analyzovat požadavek, psát specifikace, modelovat požadavek, kontrolovat, prioritizovat, spravovat požadavky) • Analytické dovednosti (umění naslouchat, ptát se, vést hovor,moderovat diskuze, pozorovací schopnost, vyjadřovací schopnost, organizační schopnost, modelovací schopnost, sociální inteligence, nápaditost). Většina znalostí s získá zkušenostmi (soft kills znalosti se týkají spíše lidí než technologií). • Viz Obr.

24. Dokumentace požadavků • Tři způsoby psaní požadavků • Dobře strukturovaným dokumentem v přirozeném jazyce • Grafickými modely • Formální specifikace pomocí matematického a formálního jazyka • Šablona pro specifikaci požadavků ze standardu IEEE 830 viz Obr. Dále • Modelování požadavků • „Jeden obrázek vydá za 1024 slov“ • Zákazníkův hlas X modely • Podstatné jméno X datastore, aktor, entity, atribut, třída • Sloveso X proces, use case, vztah v ERD, přechod v STD, aktivita v AD

25. Šablona pro specifikaci požadavků ze standardu IEEE 830

26. Kvalitativní parametry SW systémů • Důležité pro uživatele • Dostupnost (poměr plánované doby provozu systému a doby, kdy je systém skutečné k dispozici a plně funkční) • Efektivita(jak systém nakládá s časem procesoru, místem na disku, pamětí a komunikačními prostředky) • Flexibilita(jak snadno se do hotového systému přidávají nové funkce) • Integrita (neautorizovaný přístup k systému, ztráta informací, ochrana před viry, …) • Kompatibilita(jak snadno dokáže systém vyměňovat data nebo služby s jinými systémy) • Spolehlivost(pravděpodobnost, se kterou bude systém pracovat bez chyby, např. průměrný čas mezi chybami) • Odolnost(míra do jaké systém odolá chybám vstupu nebo nečekaným provozním podmínkám) • Použitelnost(patří sem uživatelská přívětivost).

27. Kvalitativní parametry SW systémů • Důležité pro vývojáře • Udržovatelnost (jak snadno se SW upravuje a jak rychle se v něm hledají a opravují chyby) • Přenositelnost(úsilí, které je třeba k přenosu SW z jednoho provozního prostředí do druhého) • Znovu použitelnost(recyklovatelnost, úsilí pro vytvoření komponenty pro použití v jiných aplikacích) • Testovatelnost (úsilí, které je potřeba pro hledání chyb). • Výkonnostní požadavky (jak dobře nebo rychle musí systém zvládat zadané funkce • Rychlost a odezva, propustnost (počet transakcí za sekundu, kapacita (schopnost zvládat souběžnou zátěž), časování (schopnost vyřídit požadavky v daném čase). • Různé části systému vyžadují různé kombinace kvalitativních parametrů, pro některé je kritická efektivita, pro jiné použitelnost,…

28. Rozdělení priorit požadavků • Důležité nejen pro určení pořadí implementace, ale pomáhá to také vyjasnit zákazníkova očekávání. • Tradičně požadavky s vysokou (důležité a naléhavé kvůli smluvním nebo právním požadavkům nebo z podnikatelských důvodů), střední (důležité ale ne naléhavé, mohou počkat do další verze) a s nízkou prioritou (nespěchají).

29. Kontrola požadavků • V - model SW vývoje naznačuje, že testování přijetí SW vychází z uživatelských požadavků, systémové testování z funkčních požadavků a integrační testování z architektury systému. viz Obr. dále • Provádí se neformální (popis si přečte někdo jiný než autor) a formální recenze (probíhá podle jasně definovaného procesu se vstupy, recenzenty a výstupy, shrnutím všech chyb a problémů, které z nich plynou. Typem recenzního řízení je inspekce požadavkové dokumentace. Fáze inspekce viz Obr. dále