Analýza požadavků

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání

Analýza požadavků v systémovém a softwarovém inženýrství, pojímá ty úkoly, které vstupují do rozhodování o potřebách a podmínkách, které jsou kladeny na nový, nebo změněný produkt. Také musí brát v úvahu různé protichůdné požadavky účastnících se stran tzv. stakeholderů jako uživatelů, nebo jiných účastníků využívajíc výsledných efektů.

Analýza požadavků je prvním stádiem v procesu systémového inženýrství a procesu softwarového vývoje.[1]

Systematická analýza požadavků, také známa jako requirements engineering.[2] Někdy je také (špatně) pojmenovaná jako sběr požadavků, nebo specifikace požadavků. Pojem analýza požadavků může být také pokládána za analýzu v právem slova smyslu (jako příklad opaku k sběru nebo dokumentaci požadavku).

Analýza požadavků je kritická ve vztahu k úspěšnému dokončení projektu vývoje.[3] Požadavek musí být proveditelný, měřitelný, testovatelný, musí se vztahovat ke konkrétnímu byznys požadavku, nebo příležitosti a také musí byt definovaný dostatečné detailně pro účely návrhu systému.

Přehled[editovat | editovat zdroj]

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

Analýza požadavků systému může být dlouhý a svízelný proces, během kterého jsou využívány mnohé psychologické dovednosti. Nový systém mění prostředí a vztahy mezi lidmi, takže je důležité identifikovat všechny zainteresované strany (stakeholders), vzít v úvahu všechny jejich potřeby a zajistit, že rozumějí důsledkům těchto nových navrhovaných systémů. Analytici mohou využít několik postupů k získaní požadavků od zákazníka. Historicky, to bylo interview, nebo vedeni rozhovoru s vybranou skupinou (focus group) (více příhodné pojmenovaní v tomto kontextu je 'požadavkový workshop') a vytváření seznamů požadavků. Více moderní techniky jako prototyping, a případy použití. Pokud to bude nutné, analytici použijí kombinaci těchto metod ke získání přesných požadavků od zúčastněných stran, aby vyvíjený systém zodpovídal byznys potřebám podniku.

Analýza požadavků[editovat | editovat zdroj]

Identifikace zúčastněných stran ("Stakeholderů")[editovat | editovat zdroj]

V devadesátých letech hlavní roli hrála identifikace zúčastněných stran (stakeholderů). Má se za to, že zúčastněné strany se neomezují pouze na organizaci, která zaměstnává analytika. Dalšími zúčastněnými stranami mohou být:

  • ty organizace, které se integrují (nebo by měly být začleněny) horizontálně s organizací pro kterou analytik systém navrhuje
  • jakékoli tzv. back office systémy nebo organizace
  • vrcholový management.

Interview se zúčastněnými stranami ("Stakeholdry")[editovat | editovat zdroj]

Rozhovory se Stakeholdery jsou běžné metody používané v analýze požadavků. Tyto rozhovory můžou odhalit požadavky, které nebyly původně zamýšlené jako ještě v rámci rozsahu tohoto projektu a můžou odhalit požadavky, které jsou protichůdné. Nicméně, každý se zúčastněnými stranami bude mít představu o jejich očekáváních, nebo budou muset své požadavky objasnit.

Contract-style seznam požadavků[editovat | editovat zdroj]

Jedním z tradičního způsobu dokumentování požadavků byl seznam požadavků. Ve složitém systému mohou takovéto seznamy mít až stovky stránek.

Měřitelné cíle[editovat | editovat zdroj]

Osvědčenými postupy při vytvoření seznam požadavků je opakovaně se ptát otázku: "Proč?" až se odhalil skutečný byznys účel/y. Zainteresované strany a také vývojáři pak můžou navrhnout testy tak, aby bylo možné zjistit, nakolik bylo zatím dosaženo cíle. Tyto cíle se mění mnohem pomaleji, než dlouhý seznam konkrétních, ale neměřitelných požadavků. Jakmile je malý soubor kritických a měřitelných cílů stanoven,softwarové prototypování může v krátké interaktivní fázi započat vývoje. Tato krátká vývojová fáze může přinést stakeholderům hodnotu ještě předtím, než bude polovina projektu hotová.

Prototypy[editovat | editovat zdroj]

V polovině-1980, prototypování bylo vnímáno jako řešení problému analýzy požadavků. Prototypy jsou reálné modely (mock-ups) aplikací (něco jako ukázky, jak bude aplikace vypadat). Mock-up, která uživatelům umožňuje vizualizovat aplikací, která dosud nebyla vyrobena.

Prototypy pomohou uživatelům získat představu o tom, jak bude systém vypadat, aby si uživatelé mohli lépe zvolit design/layout, aniž by čekali na systém, který má být ještě jen postaven. Významné zlepšení komunikace mezi uživateli a vývojáři jsou často vnímány se zavedením prototypy.

Vytvoření prototyp aplikace vedlo později k menším změnám v aplikaci, a tedy nižším celkovým nákladům. Nicméně, v příštích deseti letech, ačkoli se jeví technika užitečnou, prototypování nevyřešilo problém požadavků:

  • Manažeři, jakmile vidí prototyp, můžou jen těžko pochopit, že konečný výsledek nebude vyroben ve stejném čase.
  • Designéři jsou často nuceni použít prototyp kódu v reálném systému, protože se obávají, aby 'neztráceli čas' začínat znovu již s hotovým kódem.
  • Prototypy jsou nápomocné hlavně při návrhu uživatelských rozhraní a návrhu obrazovek. Nicméně, nemohou nic říct o tom, jaký byl původní požadavek.
  • Designéři a koncoví uživatelé se soustředí příliš na uživatelské rozhraní a příliš málo na systém, který slouží k podpoře obchodních procesů.
  • Prototypy fungují velmi dobře pro uživatelské rozhraní, rozvržení obrazovky a tok obrazovek, ale nejsou tak užitečné pro dávkové nebo asynchronní procesy, které mohou obsahovat komplexní aktualizace databáze a / nebo kalkulace.

Prototypy můžou být 'flat diagrams' (dále jen 'wireframes') nebo funkční aplikace využívající syntetizovaných funkčností. Wireframes jsou vyráběny v různých grafických designech a často bez jakýchkoli barev v softwarovém designu (tj. používat paletu barev šedé) Finální software bude mít grafický design obdobného charakteru. To pomáhá zabránit nejasnostem ohledně konečné vizuálního vzhledu aplikace

Use cases[editovat | editovat zdroj]

Use case (případy (po)užití) je technika pro zdokumentování případného požadavku na nový systém, nebo změny na stávající systém. Každý use case poskytuje jeden nebo více scénářů, které zaznamenávají, jak by systém měl spolupracovat s koncovým uživatelem, nebo jiným systémem k dosažení konkrétních hospodářských cílů. Zde se obvykle nepoužívá technický jazyk, je preferován jazyk koncového uživatele nebo doménového experta. Use case jsou ve většině případu vytvářené autorem požadavků ve spolupráci s ostatními stakeholdery.

Use case jsou jednoduché nástroje na popsaní chování softwaru nebo systému. Use case obsahují textový popis všech možný způsobů jak uživatel může pracovat se softwarem nebo systémem. Use case nepopisují žádné interní procesy systému, nebo jak bude systém implementován. Jednoduše ukazují kroky jak má uživatel provést úkol/aktivitu. Všechny způsoby, kterými uživatelé komunikují se systémem, lze popsat tímto způsobem.

Důležitou součástí Use Case modelu jsou také scénáře užití. Tyto scénáře blíže rozvádějí jednotlivé aktivity stakeholderů a reakce modelovaného systému. Může jít o scénáře jednoduché i složitěji větvené, nebo alternativní. Vždy by však měly být stručně psané, jasné a měly by poskytovat přesnou informaci o popisované akci.

Softwarová specifikace požadavků[editovat | editovat zdroj]

softwarová specifikace požadavků (SRS) je úplný popis chování systému, který má být vyvinut. Obsahuje soubor use casů, které popisují všechny interakce uživatele s tímto softwarem. Use casy jsou také známé jako funkční požadavky. Kromě use casů, RS obsahuje také nefunkční (nebo doplňkové) požadavky. Nefunkční požadavky softwarové architektury jsou požadavky, které kladou omezení na design a provedení (například požadavky na výkonnost, standardy kvality, nebo designové omezení).

Doporučené postupy pro specifikaci požadavků na software, jsou popsány v IEEE 830-1998. Tato norma popisuje možnou struktur, žádoucí obsah a kvality softwarové specifikace požadavkům.

Typy požadavků[editovat | editovat zdroj]

Požadavky jsou kategorizované několika způsoby. Následující kategorizace požadavků je z technického pohledu (technical managment):[1] ;Požadavky zákazníků : Specifikace požadavků a předpokladů, které určují očekávání od systému vzhledem na sledované cíle, prostředí, omezení a metriky efektivnosti a vhodnosti (MOE / MOS). Zákazníci jsou ti, kteří vykonávají osm primárních funkcí systémového inženýrství, se zvláštním důrazem na operátora jako na klíčového zákazníka. Provozní požadavky budou definovat základní potřeby a minimálně odpovědi na otázky položené v následujícím výčtu: [1]

*Operativní distribuce nebo nasazení: Kde bude systém používán?
*Profil mise nebo scénář: Jak bude systém splnit své poslání nebo cíl?
*Výkon a související parametre: Jaké jsou klíčové parametry systému pro splnění cíle?
*Využití prostředí: Jak jsou jednotlivé komponenty systému použity?
*Požadavky na efektivitu: Jak účinný nebo efektivní systém musí být při plnění svého poslání?
*Provozní životný cyklus: Jak dlouho bude systém používán uživatelem?
*Prostředí: V jakém předpokládaném prostředí bude systém pracovat?
Funkční požadavky
Funkční požadavky objasňující co se musí udělat a identifikuje nutné úkony, aktivity a akce, které musí být vykonány. Analýza funkčních požadavků bude použita jako základ takzvané toplevel funkce systému pro funkční analýzu.[1]
Výkonnostní požadavky
Kriterium stanovující do kdy nebo jak musí být funkce nebo činnost vykonaná; obvykle metrika ve vztahu pokud jde o množství, jakosti, pokrytí, aktuálnosti nebo pohotovosti. Během analýzy požadavků, celková kvalita a výkonnost (performance - jak dobře se to muset být učiněno), budou na základe požadavků interaktivně vyvinuté v rámci všech identifikovaných funkcí vzhledem na systém životního cyklu faktorů.[1]
Designové požadavky
Požadavky na procesy vyjádřená v technických datových balíčcích a technických příručkách.[1]
Odvozené požadavky
Požadavky, které jsou transformovány z požadavků vyšší úrovně. Například, požadavky na dlouhý dojezd nebo vysokou rychlost vytváří požadavek na nízkou hmotnost.[1]
Alokované požadavky
Požadavky, které vznikly rozdělením nebo alokováním tzv. high-level požadavku.[1]

Jiné členění např. metoda FURPS

Analýza požadavku problémy/dotazy[editovat | editovat zdroj]

Stakeholder problémy/dotazy[editovat | editovat zdroj]

Steve McConnell ve své knize Rapid Development, popisuje řadu způsobů, jak mohou uživatelé brzdí sběr požadavků:

  • Uživatelé nerozumí tomu, co chtějí, nebo uživatelé nemají jasnou představu o svých požadavcích
  • Uživatelé neschválí seznam sepsaných požadavku jako finální
  • Uživatelé trvají na nových požadavcích i po zafixovaní nákladů a časového harmonogramu
  • Komunikace s uživateli je pomalá
  • Uživatelé se často nepodílejí na kontrolách, nebo jsou neschopní to udělat
  • Uživatelé jsou technicky nevzdělaní
  • Uživatelé nerozumí procesu vývoje
  • Uživatelé neví o současné technologii

To může vést k situaci, kdy uživatelé průběžně mění své požadavky, i když systém nebo vývoj produktu byl zahájen.

Inženýr/vývojář - problémy/dotazy[editovat | editovat zdroj]

Možné problémy způsobené inženýři a vývojáři za běhu analýzy požadavků jsou:

  • Technický personál a koncoví uživatelé mohou mít různé odborné jazyky. V důsledku toho se mohou mylně domnívat, že jsou v perfektní shodě, dokud není hotový produkt dodán.
  • Inženýrů a vývojářů, přizpůsobí požadavek, aby odpovídal požadavkům stávajícího systém nebo model, spíše než vytvořit systém specifické potřeby klienta.
  • Analýza může být často prováděna inženýry nebo programátory, spíše než s lidmi, kteří mají dovednosti a znalosti porozumět potřebám klienta správně.

Možné řešení[editovat | editovat zdroj]

Jeden pokus o řešení problémů komunikace by mohlo být zaměstnávat specialisty v byznysu nebo systémové analýze.

Techniky, které přinesl rok 1990 jako Unified Modeling Language (UML), use case, Agilní softwarové metody vývoje jsou určeny také jako řešení problémů, s nimiž se potkali u předchozí metody. Také nové třídy simulace aplikací, nebo použití nástroje pro definici aplikací, které vstoupilo na trh. Tyto nástroje jsou navrženy tak, aby překlenuly propast mezi byznys uživateli a IT organizací - a také, aby aplikace, mohly být otestovány na trhu (test marketed) předtím než je vůbec nějaký kód vytvořen. Nejlepší z těchto nástrojů nabízí:

  • Elektronická tabule pro náčrt použití toků a test alternativ
  • Schopnost zachytit byznys logiku a datové potřeby
  • Schopnost generovat High Fidelity prototypy, které věrně imitují finální aplikaci
  • Interaktivita
  • Schopnost přidat jiné kontextové požadavky a připomínky
  • Schopnost pro vzdálené a distribuované uživatele spouštět a pracovat se simulacemi

Reference[editovat | editovat zdroj]

  1. a b c d e f g h Systems Engineering Fundamentals. Defense Acquisition University Press, 2001
  2. WIEGERS, Karl E.. Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle. 2nd. vyd. Redmond : Microsoft Press, 2003. Dostupné online. ISBN 0-7356-1879-8.  
  3. Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis. Guide to the software engineering body of knowledge. 2004. vyd. Los Alamitos, CA : IEEE Computer Society Press, 2005-March. Dostupné online. ISBN 0-7695-2330-7. Kapitola Chapter 2: Software Requirements.  

V tomto článku byl použit překlad textu z článku Requirements analysis na anglické Wikipedii.

Další zdroje informací[editovat | editovat zdroj]

  • MCCONNELL, Steve. Rapid Development: Taming Wild Software Schedules. 1st. vyd. Redmond, WA : Microsoft Press, 1996. Dostupné online. ISBN 1-55615-900-5.  
  • WIEGERS, Karl E.. Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle. 2nd. vyd. Redmond : Microsoft Press, 2003. Dostupné online. ISBN 0-7356-1879-8.  
  • Andrew Stellman and Jennifer Greene. Applied Software Project Management. Cambridge, MA : O'Reilly Media, 2005. Dostupné online. ISBN 0-596-00948-8.  

Externí odkazy[editovat | editovat zdroj]