Analýza požadavků

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

Systematická analýza požadavků je někdy označována jako requirements engineering.^[2] nebo je také (špatně) pojmenovaná jako sběr požadavků, nebo specifikace požadavků. Analýza požadavků může být analýzou v pravém slova smyslu (jako opak ke sběru nebo dokumentaci požadavků).

Kvalitní analýza požadavků je podmínkou úspěšného 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.

Requirements engineering

Správa požadavků obecně může být zastřešující pojem pro různé aktivity:

• Sběr požadavků: komunikace se zákazníky a uživateli za účelem získání jejich požadavků na systém.
• Vlastní analýza: identifikování nejasných, nekompletních, nesmyslných, nesplnitelný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, případy užití (use case), nebo specifikace procesů.
• Řízení životního cyklu požadavků (změny, slučování, zánik)

Podle ISO/IEC 24766:2009,^[4] podporují nástroje pro práci s požadavky šest hlavních činností:

• Zjišťování požadavků
• Analýza požadavků
• Specifikace požadavků
• Ověření a validace požadavků
• Správa požadavků
• Další schopnosti.

Analytici mohou využít více postupů k získaní požadavků od zákazníka. Historicky, to bylo interview, nebo vedeni rozhovoru s vybranou skupinou (focus group) (příhodnější pojmenovaní v tomto kontextu je 'požadavkový workshop') a vytváření seznamů požadavků. Mezi modernější techniky patří prototypování, a tvorba případů užití. Pokud to bude nutné, analytici použijí kombinaci metod ke získání přesných požadavků od zúčastněných stran, aby vyvíjený systém co nejlépe odpovídal byznys potřebám zadavatele.

Analýza požadavků

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

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 ("Stakeholdery")

Rozhovory se Stakeholdery jsou běžné metody používané v analýze požadavků. Tyto rozhovory mohou odhalit požadavky, které nebyly původně zamýšlené jako ještě v rámci rozsahu tohoto projektu a mohou 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ů

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

Měřitelné cíle

Osvědčeným postupem je brát seznam požadavků pouze jako vodítko a opakovaně se klást otázku: „Proč?“ až se odhalí skutečné obchodní účely. Zainteresované strany a také vývojáři pak mohou 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 stanoven malý soubor kritických a měřitelných cílů, může navázat softwarové prototypování a krátké iterativní vývojové fáze, které mohou poskytnout zúčastněným stranám skutečnou hodnotu ještě předtím, než bude projekt v polovině.

Prototypy

Prototypování bylo v polovině 80. let vnímáno jako řešení problému analýzy požadavků. Prototypy jsou reálné modely (makety) aplikací umožňující uživatelům vizualizovat aplikace, dříve než jsou vyrobeny. Tím pomáhají uživatelům získat představu, jak bude systém vypadat, aby si mohli 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, mohou 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ž 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 mohou 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

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ů

Softwarová specifikace požadavků (SRS) je úplný popis chování systému, který má být vyvinut. Obsahuje soubor use cases, které popisují všechny interakce uživatele se softwarem. Use case je obvykle rozvedením funkčních požadavků. Kromě use cases, RS obsahuje také nefunkční (nebo doplňkové) požadavky. Nefunkční požadavky softwarové architektury jsou požadavky, které kladou omezení na návrh 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 ISO/IEC/IEEE 29148:2018^[5]. Tato norma popisuje možnou strukturu, žádoucí obsah a kvalitu softwarové specifikace požadavků.

Typy požadavků

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í parametry: 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ákladě 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 vozidla vytváří požadavek na jeho 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

Stakeholder problémy/dotazy

Steve McConnell ve své knize Rapid Development, popisuje řadu způsobů, jak mohou uživatelé brzdit správu požadavků:

• Uživatelé nerozumějí tomu, co chtějí, nebo 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 nepodílejí na kontrolách, nebo jsou neschopní je udělat
• Uživatelé jsou technicky nevzdělaní
• Uživatelé nerozumějí procesu vývoje
• Uživatelé nevědí o současné technologii

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

Inženýr/vývojář – problémy/dotazy

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 používat odlišný odborný jazyk. V důsledku toho se mohou všichni mylně domnívat, že jsou v perfektní shodě, dokud není hotový produkt dodán.
• Tým techniků a vývojářů přizpůsobí požadavek tak, aby odpovídal stávajícímu systému, místo aby vytvořili systém vhodný pro specifické potřeby klienta.
• Analýza může být prováděna inženýry nebo programátory a ne lidmi, kteří mají znalosti a nadání správně porozumět potřebám klienta.

Možné řešení

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

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

Literatura

• 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

• Obrázky, zvuky či videa k tématu analýza požadavků na Wikimedia Commons
• Requirements Engineering Process "Goodies"
• Requirements Engineering: A Roadmap (PDF) article by Bashar Nuseibeh and Steve; Easterbrook, 2000.
• Undreamt Requirements Analysis
• Getting Started With Use Cases
• 830-1984 — IEEE Guide to Software Requirements Specifications. [s.l.]: [s.n.], 1984. ISBN 978-0-7381-4418-4. DOI 10.1109/IEEESTD.1984.119205. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• 830-1993 — IEEE Recommended Practice for Software Requirements Specifications. [s.l.]: [s.n.], 1994. ISBN 978-0-7381-4723-9. DOI 10.1109/IEEESTD.1994.121431. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• 830-1998 — IEEE Recommended Practice for Software Requirements Specifications. [s.l.]: [s.n.], 1998. ISBN 978-0-7381-0332-7. DOI 10.1109/IEEESTD.1998.88286. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• 29148-2011 - Systems and software engineering — Life cycle processes — Requirements engineering. [s.l.]: [s.n.], 2011. Dostupné online. ISBN 978-0-7381-6591-2. DOI 10.1109/IEEESTD.2011.6146379. S. 1–94. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 – http://standards.ieee.org/findstds/standard/29148-2011.html")
• LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: A Use Case Approach. 2nd. vyd. [s.l.]: Addison-Wesley, 2003. ISBN 978-0321122476. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• GOTTESDIENER, Ellen. The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements. [s.l.]: Addison-Wesley, 2009. ISBN 978-1576811146. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• WIEGERS, Karl; BEATTY, Joy. Software Requirements, Third Edition. [s.l.]: Microsoft Press, 2013. ISBN 9780735679665. (anglicky) Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“.
• IEEE SRS Template - rick4470/IEEE-SRS-Tempate [online]. [cit. 2017-12-27]. Dostupné online. (anglicky) Je zde použita šablona {{Cite web}} označená jako k „pouze dočasnému použití“.
• TAAFFE, Ed. Mr [online]. [cit. 2019-02-02]. Dostupné online. (anglicky) Je zde použita šablona {{Cite web}} označená jako k „pouze dočasnému použití“.