Analýza požadavků

Z Wikipedie, otevřené encyklopedie
Skočit na navigaci Skočit na vyhledává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, nekompletních, nebo protichůdných požadavků 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 odhalí 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ě 80. let bylo prototypování vnímáno jako řešení problému analýzy požadavků. Prototypy jsou reálné modely (mock-ups) aplikací, které uživatelům umožňují vizualizovat aplikace, které dosud nebyly vyrobeny. Pomáhají uživatelům získat představu o tom, jak bude systém vypadat, aby si uživatelé mohli lépe zvolit vzhled/rozložení, aniž by čekali na systém, který má být teprve vytvořen. Použití prototypů významně zlepšilo komunikaci mezi uživateli a vývojáři.

Vytvoření prototypové aplikace vedlo k menším následným změnám v aplikaci, a tedy nižším celkovým nákladům. Nicméně se v následujících deseti letech i přes užitečnost prototypování nepodařilo vyřešit související problémy:

  • Jakmile manažeři 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 nechtějí ztrácet čas znovuvytvářením již s hotového kódu.
  • 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 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í) modelování je technika pro nalezení a zdokumentování veškerých použití (funkcionalit) systému. Využívá se jak pro systémy zcela nové, tak při změnách systémů provozovaných. Každý use case poskytuje jeden nebo více scénářů, které zaznamenávají, jak by systém měl interagovat s koncovým uživatelem, případně i jiným systémem (obecně je systém nebo uživatel označován termínem aktér), k dosažení konkrétních cílů (užitek plynoucí z použití systému). Use case modely zpravidla vytváří business analytik ve spolupráci se zadavatelem, resp. klíčovými uživateli systému.

Pro vytvoření Use case modelu postačí i jednoduché nástroje (textový editor) na popsaní chování softwaru nebo systému. Use case modely obsahují ve formě scénářů užití textový popis všech možný způsobů, jak uživatel (aktér) může pracovat se softwarem nebo systémem. Tyto scénáře blíže rozvádějí jednotlivé kroky aktérů 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. Při psaní scénářů se užití obvykle nepoužívá technický jazyk, ale je preferován jazyk koncového uživatele nebo doménového experta.

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]

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

  1. a b c d e f g h Systems Engineering Fundamentals. Archivováno 11. 2. 2006 na Wayback Machine 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, March 2005. Dostupné online. ISBN 0-7695-2330-7. Kapitola Chapter 2: Software Requirements. 

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]