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

Přehled

Analýza požadavků obsahuje 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, jako běžný textový dokument, případy užití (use case), nebo specifikace procesů.
  • Řízení životního cyklu požadavků (změny, slučování, zánik)

Analýza požadavků na systém 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 jejich podstatné potřeby a zajistit, že rozumějí důsledkům vzniku nově navrhovaných systémů. 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 ("Stakeholdry")

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ů. 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 casů, které popisují všechny interakce uživatele s tímto softwarem. Use casy jsou součástí funkčních požadavků. 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 29148:2018[4]. Tato norma popisuje možnou struktur, žádoucí obsah a kvality softwarové specifikace požadavkům.

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

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.

  1. 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. 2. 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.
  4. 14:00-17:00. ISO/IEC/IEEE 29148:2018. ISO [online]. [cit. 2021-10-17]. Dostupné online. (anglicky)

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)
  • 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)
  • 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)
  • 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)("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)
  • 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)
  • WIEGERS, Karl; BEATTY, Joy. Software Requirements, Third Edition. [s.l.]: Microsoft Press, 2013. ISBN 9780735679665. (anglicky)
  • IEEE SRS Template - rick4470/IEEE-SRS-Tempate [online]. [cit. 2017-12-27]. Dostupné online. (anglicky)
  • TAAFFE, Ed. Mr [online]. [cit. 2019-02-02]. Dostupné online. (anglicky)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.