OI_SI_MAGISTERSKY_STATNICOVY_OKRUH_1

Uživatelské požadavky, definice funkcionality systému, vztah mezi funkcionálními a nefunkcionálními (např. kapacita, škálovatelnost, robustnost) požadavky na systémy, technická specifikace.(A4M33NMS)

• Inženýrství požadavků (Requirements engineering) je termín používaný k popisu aktivit, souvisejících se zjišťováním, dokumentací a údržbou množiny požadavků na sofwarový systém.
• Zastupuje odhalování způsobu, jak a k čemu uživatelé daný systém potřebují.
• Jedná se o klíčový faktor celého vývoje softwarového projektu.
• Nedostatečně specifikované požadavky a nedostatečné zapojení uživatelů, jsou dvěma hlavními příčinami konečného neúspěchu celého projektu.

• Požadavek lze definovat jako “specifikaci toho, co by mělo být implementováno”.
• Rozlišují se dva typy požadavků:
  • Funkční požadavky, které určují, jaké chování bude systém nabízet.
  • Nefunkční požadavky, které určují vlastnosti nebo omezující podmínky, kladené na daný systém.
• Požadavky jsou základem systému, neboť jsou vyjádřením toho, CO by měl systém dělat, nikoli však způsobu, JAK toho docílit.
• Požadavky je vhodné uspořádat do taxonomie (FURPS - functionality, usability, reliability, performance, supportability). Nejjednodušší rozdělení požadavků je na funkční a nefunkční. Lze je však dále jemněji uspořádávat do kategorií, které závisí na typu vyvíjeného softwaru. K těmto účelům je velmi užitečné použít nástroj pro správu požadavků.
• Na základě požadavků dochází k vypracování Use Case pro systémy, kde to má smysl (interakce s uživateli) a analýzy.

• špatně vyhodnocené požadavky
• nepřesné požadavky
• neúplné požadavky
• navzájem si odporující požadavky
• nevyřčené, ale přesto očekávané požadavky
• přehnané požadavky
• obtížně verifikovatelné (nekvantitativní) požadavky – např. systém bude potřebovat málo paměti
• nedostatečné zapojení zákazníka a uživatelů do procesu získávání požadavků
• chybějící priorita
• vytváření něčeho, co nikdo nechtěl
• specifikace není v systému pro správu verzí
• nedefinovaný proces změnových řízení

• Funkční požadavek definuje konkrétní funkci softwarového systému nebo jeho komponenty.
• Tato funkce je popsána jako množina vstupů, chování a výstupů.
• Funkčními požadavky mohou být výpočty, manipulace s daty a jejich zpracování či jiné specifické operace, které by systém měl být schopen splnit.
• Formulace funkčního požadavku má typicky následující podobu:
  • <ID> <název systému> musí/může/nesmí <popis funkce>
• Plán implementace funkčních požadavků je upřesněn ve fázi návrhu systému.

• Nefunkční požadavky podporují množinu funkčních.
• Často jsou označovány jako “kvality systému”.
• Kladou specifická omezení a vlastnosti na systém jako celek, jeho návrh a vývoj.
• Formulace nefunkčního požadavku má typicky následující podobu:
  • <ID> <název systému> musí/může/nesmí <popis vlastnosti / omezení>
• Plán implementace nefunkčních požadavků je upřesněn v architektuře systému.
• Definuje, za jakých okolností bude systém pracovat.

• Dostupnost - vyjadřuje poměr části časového intervalu, kdy je systém použitelný, ku celkové délce tohoto intervalu.
• Robustnost - vyjadřuje schopnost systému vypořádat se s eventuálními výjimečnými událostmi, které mohou nastat při jeho běhu.
• Škálovatelnost - vyjadřuje schopnost adaptace respektive možnosti rozšíření systému ve vztahu k rostoucím objemům práce.
• Výkon - obecně vyjadřuje objem času a zdrojů, které systém potřebuje ke splnění nějakého konkrétního úkolu.
• Bezpečnost - vyjadřuje stupeň ochrany vůči nebezpečí, škodám, ztrátě a kriminálním aktivitám.
• Shoda se standardy
• integrace s jinými systémy
• formát vstupních a výstupních dat
• běhové prostředí (OS, verze Javy, verze DB)
• použité technologie
• komunikace s jinými systémy

• SRS - (Software Requirements Specification) - je dokument obsahující kompletní popis chování vyvíjeného systému. Obsahuje všechny funkční i nefunkční požadavky.
• Funkční požadavky jsou zde obvykle vyjádřeny i ve formě případů užití., ve kterých je podrobně popsán způsob interakce uživatelů se systémem.
• SRS musí sloužit pro:
  • rozhodnutí, co patří do definovaného rozsahu projektu a co ne
  • ustanovení kontraktu pro vývoj
  • kvalifikační testování
  • akceptační testování
  • rozhodnutí, zda hlášený problém je 1) chyba 2) požadavek na změnu 3) šedá zóna mezi tím
• SRS má obyvkle podobu strukturovaného dokumentu. Méně často pak podobu katalogu požadavků.
• Typická struktura dokumentu SRS:
  • Úvod
    • Účel dokumentu
    • Rozsah projektu
    • Definice
    • Přehled systému
    • Reference
  • Souhrnný popis
    • Perspektiva produktu
    • Funkce produktu
    • Charakteristika uživatelů
    • Omezení, předpoklady a závislosti
  • Specifické požadavky
    • Externí rozhraní
    • Funkce
    • Požadavky na výkon
    • Požadavky na databáze
    • Omezení návrhu

Případy užití sestávají z Use case text a Use case diagrams. UCT je v podstatě scénář uživatelské akce.

Pojmy k UCD:

• vazby include a extend
• actors a jejich hierarchie
• hranice systému

Struktura UCT:

• pritorita
• preconditions a postconditions
• tok hlavního scénáře a rozvětvení (klíčová slova if, for, else)
• alternativní scénáře

• ARLOW, Jim, NEUSTADT, Ila. UML2 : a unifikovaný proces vývoje aplikací. Brno : Computer Press, a.s., 2007. 567 s.
• Přednášky předmětu A4M33SEP - Softwarové inženýrství pro praxi
• http://en.wikipedia.org/wiki/Software_Requirements_Specification
• http://en.wikipedia.org/wiki/Functional_requirements
• http://en.wikipedia.org/wiki/Non-functional_requirements