Analýza požadavků - Requirements analysis

Pohled systémového inženýrství na analýzu požadavků.

V systémovém inženýrství a softwarovém inženýrství se analýza požadavků zaměřuje na úkoly, které určují potřeby nebo podmínky pro splnění nového nebo změněného produktu nebo projektu, s přihlédnutím k možným protichůdným požadavkům různých zúčastněných stran , analýze, dokumentaci, validaci a správě softwaru nebo Požadavky na systém.

Analýza požadavků je zásadní pro úspěch nebo selhání systému nebo softwarového projektu . Požadavky by měly být dokumentovány, přijatelné, měřitelné, testovatelné, sledovatelné, související s identifikovanými obchodními potřebami nebo příležitostmi a měly by být definovány na úrovni podrobností dostatečných pro návrh systému.

Přehled

Koncepčně zahrnuje analýza požadavků tři typy činností:

Vyžadující požadavky : (např. Charta nebo definice projektu), dokumentace obchodního procesu a rozhovory se zúčastněnými stranami. Tomu se někdy říká shromažďování požadavků nebo zjišťování požadavků.
Požadavky na záznam: Požadavky mohou být dokumentovány v různých formách, obvykle včetně souhrnného seznamu a mohou zahrnovat dokumenty v přirozeném jazyce, případy použití , uživatelské příběhy , specifikace procesů a různé modely včetně datových modelů.
Analýza požadavků: určení, zda jsou stanovené požadavky jasné, úplné, neduplikované, stručné, platné, konzistentní a jednoznačné, a řešení jakýchkoli zjevných konfliktů. Analýza může také zahrnovat požadavky na velikost.

Analýza požadavků může být dlouhý a únavný proces, během kterého je zapojeno mnoho citlivých psychologických dovedností. Nové systémy mění prostředí a vztahy mezi lidmi, proto je důležité identifikovat všechny zúčastněné strany, zohlednit všechny jejich potřeby a zajistit, aby rozuměly dopadům nových systémů. Analytici mohou k získání požadavků od zákazníka použít několik technik. Patří mezi ně vývoj scénářů (představovaných jako uživatelské příběhy v agilních metodách ), identifikace případů použití , použití pozorování na pracovišti nebo etnografie , pořádání rozhovorů nebo cílové skupiny (v tomto kontextu výstižněji pojmenované jako workshopy požadavků nebo požadavky kontrolní relace) a vytváření seznamů požadavků. Prototypování lze použít k vývoji příkladného systému, který lze demonstrovat zúčastněným stranám. V případě potřeby analytik použije kombinaci těchto metod ke stanovení přesných požadavků zúčastněných stran tak, aby vznikl systém, který splňuje obchodní potřeby. Kvalitu požadavků lze zlepšit pomocí těchto a dalších metod

Vizualizace. Používání nástrojů, které podporují lepší pochopení požadovaného konečného produktu, jako je vizualizace a simulace.
Důsledné používání šablon. Produkce konzistentní sady modelů a šablon pro dokumentaci požadavků.
Dokumentování závislostí . Dokumentování závislostí a vzájemných vztahů mezi požadavky, stejně jako jakékoli předpoklady a shromáždění.

Témata analýzy požadavků

Identifikace zúčastněných stran

V části Analýza zúčastněných stran najdete diskuzi o lidech nebo organizacích (právnických osobách, jako jsou společnosti, normalizační orgány), které mají o systém platný zájem. Může na ně mít přímý nebo nepřímý dopad. Hlavním novým důrazem v 90. letech bylo zaměření na identifikaci zúčastněných stran . Stále více se uznává, že zúčastněné strany se neomezují pouze na organizaci zaměstnávající analytika. Mezi další zúčastněné strany patří:

kdokoli, kdo provozuje systém (normální a operátoři údržby)
každý, kdo má ze systému prospěch (funkční, političtí, finanční a sociální příjemci)
kdokoli podílející se na nákupu nebo pořízení systému. V organizaci produktů na masovém trhu působí produktový management, marketing a někdy i prodej jako náhradní spotřebitelé (zákazníci na masovém trhu), kteří mají řídit vývoj produktu.
organizace, které regulují aspekty systému (finanční, bezpečnostní a další regulační orgány)
lidé nebo organizace, které jsou proti systému (negativní zúčastněné strany; viz také případ zneužití )
organizace odpovědné za systémy, které jsou propojeny se systémem ve fázi návrhu.
ty organizace, které se horizontálně integrují s organizací, pro kterou analytik systém navrhuje.

Zasedání o vývoji společných požadavků (JRD)

Požadavky mají často mezifunkční důsledky, které jednotlivým zúčastněným stranám nejsou známy a během rozhovorů se zúčastněnými stranami často chybí nebo jsou definovány neúplně. Tyto mezifunkční důsledky lze vyvolat prováděním relací JRD v kontrolovaném prostředí za pomoci vyškoleného facilitátora (Business Analyst), kde se zúčastněné strany účastní diskusí za účelem získání požadavků, analýzy jejich podrobností a odhalení mezifunkčních důsledků. Měl by být přítomen specializovaný písař, který dokumentuje diskusi a uvolní tak Business analytika, aby vedl diskusi směrem, který generuje příslušné požadavky, které splňují cíl relace.

Relace JRD jsou obdobou relací Designu společných aplikací . V prvním případě relace vyvolávají požadavky, kterými se řídí návrh, zatímco druhé vyvolávají specifické konstrukční prvky, které mají být implementovány v uspokojení vyvolaných požadavků.

Seznamy požadavků ve stylu smlouvy

Jedním z tradičních způsobů dokumentování požadavků byly seznamy požadavků na smluvní styl. Ve složitém systému mohou takové seznamy požadavků běžet na stovky stránek.

Vhodnou metaforou by byl extrémně dlouhý nákupní seznam. Takové seznamy jsou v moderní analýze velmi nepříjemné; protože se ukázalo, že při dosahování svých cílů jsou mimořádně neúspěšní; ale jsou stále viditelné dodnes.

Silné stránky

Poskytuje kontrolní seznam požadavků.
Poskytněte smlouvu mezi sponzorem (sponzory) projektu a vývojáři.
Pro velký systém může poskytnout popis na vysoké úrovni, ze kterého lze odvodit požadavky na nižší úrovni.

Slabé stránky

Takové seznamy mohou běžet na stovky stránek. Nemají sloužit jako čitelný popis požadované aplikace.
Takové požadavky seznamy abstrakt všechny požadavky, a tak tam je malý kontext. Obchodní analytik může do doprovodné projektové dokumentace zahrnout kontext požadavků.
- Účelem této abstrakce není popsat, jak požadavky zapadají nebo spolupracují.
- Seznam nemusí odrážet vztahy a závislosti mezi požadavky. Zatímco seznam usnadňuje stanovení priorit každé jednotlivé položky, odstranění jedné položky mimo kontext může způsobit, že celý případ použití nebo obchodní požadavek bude zbytečný.
- Seznam nenahrazuje potřebu pečlivě přezkoumávat požadavky se zúčastněnými stranami, aby bylo možné lépe sdílet porozumění důsledkům pro návrh požadovaného systému / aplikace.
Pouhé vytvoření seznamu nezaručuje jeho úplnost. Obchodní analytik musí v dobré víře vyvinout a shromáždit v podstatě komplexní seznam a spoléhat se na zúčastněné strany, že upozorní na chybějící požadavky.
Tyto seznamy mohou vytvářet falešný pocit vzájemného porozumění mezi zúčastněnými stranami a vývojáři; Obchodní analytici jsou pro proces překladu zásadní.
Před zahájením procesu vývoje a testování je téměř nemožné odhalit všechny funkční požadavky. Pokud se s těmito seznamy zachází jako s nezměnitelnou smlouvou, pak požadavky, které se objeví v procesu vývoje, mohou generovat kontroverzní požadavek na změnu.

Alternativa k seznamům požadavků

Jako alternativu k seznamům požadavků používá Agile Software Development uživatelské příběhy k navrhování požadavků v každodenním jazyce.

Měřitelné cíle

Osvědčené postupy berou složený seznam požadavků pouze jako vodítka a opakovaně se ptají „proč?“ dokud nebudou objeveny skutečné obchodní účely. Zúčastněné strany a vývojáři pak mohou navrhnout testy k měření, jaké úrovně každého cíle bylo dosud dosaženo. Tyto cíle se mění pomaleji než dlouhý seznam konkrétních, ale neměřených požadavků. Jakmile bude vytvořena malá sada kritických, měřených cílů, mohou pokračovat rychlé prototypování a krátké iterativní vývojové fáze, které poskytnou skutečnou hodnotu pro zainteresované subjekty dlouho předtím, než je projekt v polovině.

Prototypy

Prototyp je počítačový program, který vykazuje část vlastností jiného počítačového programu a umožňuje uživatelům vizualizovat aplikaci, která dosud nebyla vytvořena. Populární formou prototypu je maketa , která pomáhá budoucím uživatelům a dalším zúčastněným stranám získat představu o tom, jak bude systém vypadat. Prototypy usnadňují rozhodování o návrhu, protože aspekty aplikace lze zobrazit a sdílet před vytvořením aplikace. Významné zlepšení komunikace mezi uživateli a vývojáři bylo často vidět při zavedení prototypů. Dřívější pohledy na aplikace vedly později k menším změnám, a proto výrazně snížily celkové náklady.

Prototypy mohou být ploché diagramy (často označované jako drátové modely ) nebo pracovní aplikace využívající syntetizované funkce. Drátové modely jsou vytvářeny v různých dokumentech grafického designu a často odstraňují veškerou barvu z designu (tj. Používají paletu barev ve stupních šedi) v případech, kdy se od finálního softwaru očekává použití grafického designu . To pomáhá předcházet nejasnostem ohledně toho, zda prototyp představuje konečný vizuální vzhled a chování aplikace.

Případy užití

Případ použití je struktura pro dokumentaci funkčních požadavků na systém, obvykle zahrnující software, ať už je nový nebo se mění. Každý případ použití poskytuje sadu scénářů, které vyjadřují, jak by měl systém interagovat s lidským uživatelem nebo jiným systémem, aby dosáhl konkrétního obchodního cíle. Případy použití se obvykle vyhýbají technickému žargonu, místo toho upřednostňují jazyk odborníka na koncového uživatele nebo doménu . Případy použití jsou často spoluautory techniků požadavků a zúčastněných stran.

Případy použití jsou klamně jednoduchými nástroji k popisu chování softwaru nebo systémů. Případ použití obsahuje textový popis způsobů, jakými mají uživatelé pracovat se softwarem nebo systémem. Případy použití by neměly popisovat vnitřní fungování systému ani by neměly vysvětlovat, jak bude tento systém implementován. Místo toho ukazují kroky potřebné k provedení úkolu bez postupných předpokladů.

Specifikace požadavků

Specifikace požadavků je syntézou zjištění objevů týkajících se současných obchodních potřeb podniku a posouzení těchto potřeb za účelem stanovení a upřesnění toho, co je požadováno pro splnění potřeb v rámci zaměření řešení. Objev, analýza a specifikace přesouvají porozumění ze současného stavu do budoucího stavu. Specifikace požadavků může pokrýt celou šířku a hloubku budoucího stavu, který má být realizován, nebo může cílit na konkrétní mezery, které je třeba vyplnit, jako jsou například opravy chyb prioritního softwarového systému a vylepšení. Vzhledem k tomu, že jakýkoli velký podnikový proces téměř vždy využívá softwarové a datové systémy a technologie, specifikace požadavků je často spojena s sestavením softwarového systému, nákupy, strategiemi cloud computingu, vestavěným softwarem v produktech nebo zařízeních nebo jinými technologiemi. Širší definice specifikace požadavků zahrnuje nebo se zaměřuje na jakoukoli strategii nebo komponentu řešení, jako je školení, průvodci dokumentací, personál, marketingové strategie, vybavení, zásoby atd.

Druhy požadavků

Požadavky jsou kategorizovány několika způsoby. Níže jsou uvedeny běžné kategorizace požadavků, které se vztahují k technickému řízení:

Požadavky zákazníka

Fakta a předpoklady, které definují očekávání systému, pokud jde o cíle mise, prostředí, omezení a měřítka účinnosti a vhodnosti (MOE / MOS). Zákazníci jsou ti, kteří vykonávají osm hlavních funkcí systémového inženýrství, se zvláštním důrazem na operátora jako klíčového zákazníka. Provozní požadavky budou definovat základní potřebu a minimálně budou odpovídat na otázky kladené v následujícím seznamu:

Provozní distribuce nebo nasazení : Kde bude systém používán?
Profil mise nebo scénář : Jak systém dosáhne svého cíle mise?
Výkon a související parametry : Jaké jsou důležité parametry systému pro splnění mise?
Prostředí využití : Jak se mají používat různé součásti systému?
Požadavky na účinnost : Jak efektivní nebo efektivní musí být systém při plnění svých úkolů?
Provozní životní cyklus : Jak dlouho bude systém používán uživatelem?
Prostředí : V jakých prostředích bude systém fungovat efektivně?

Architektonické požadavky: Architektonické požadavky vysvětlit, co je třeba provést identifikaci potřebné architektury systémů o systému .
Strukturální požadavky: Strukturální požadavky vysvětlují, co je třeba udělat, identifikováním nezbytné struktury systému.
Behaviorální požadavky: Požadavky na chování vysvětlují, co je třeba udělat, identifikováním nezbytného chování systému.
Funkční požadavky: Funkční požadavky vysvětlují, co je třeba udělat, identifikováním nezbytného úkolu, akce nebo činnosti, které musí být provedeny. Analýza funkčních požadavků bude použita jako hlavní funkce pro funkční analýzu.
Nefunkční požadavky: Nefunkční požadavky jsou požadavky, které specifikují kritéria, která lze použít k posouzení fungování systému, spíše než konkrétní chování.
Požadavky na výkon: Rozsah, v jakém musí být mise nebo funkce vykonány; obvykle se měří z hlediska množství, kvality, pokrytí, včasnosti nebo připravenosti. Během analýzy požadavků budou požadavky na výkon (jak dobře to musí být provedeno) interaktivně vyvíjeny napříč všemi identifikovanými funkcemi na základě faktorů životního cyklu systému; a charakterizovány mírou jistoty v jejich odhadu, mírou kritičnosti k úspěchu systému a jejich vztahem k dalším požadavkům.
Požadavky na design: Požadavky na produkty „build to“, „code to“ a „buy to“ pro produkty a „jak provádět“ požadavky na procesy vyjádřené v balíčcích technických údajů a technických příručkách.
Odvozené požadavky: Požadavky, které jsou implicitní nebo transformované z požadavku vyšší úrovně. Například požadavek na dlouhý dosah nebo vysokou rychlost může mít za následek konstrukční požadavek na nízkou hmotnost.
Přidělené požadavky: Požadavek, který je stanoven rozdělením nebo jiným přidělením požadavku na vysoké úrovni do několika požadavků na nižší úrovni. Příklad: Položka o hmotnosti 100 liber, která se skládá ze dvou subsystémů, může mít za následek požadavky na váhu 70 liber a 30 liber pro dvě položky na nižší úrovni.

Známé modely kategorizace požadavků zahrnují FURPS a FURPS + vyvinuté v Hewlett-Packard .

Problémy s analýzou požadavků

Problémy se zúčastněnými stranami

Steve McConnell ve své knize Rychlý vývoj popisuje řadu způsobů, jak mohou uživatelé bránit shromažďování požadavků:

Uživatelé nerozumí tomu, co chtějí, nebo nemají jasnou představu o svých požadavcích
Uživatelé se nezaváže k souboru písemných požadavků
Po stanovení nákladů a harmonogramu uživatelé trvají na nových požadavcích
Komunikace s uživateli je pomalá
Uživatelé se často nezúčastňují kontrol nebo tak nemohou učinit
Uživatelé jsou technicky nenároční
Uživatelé nerozumí procesu vývoje
Uživatelé neví o současné technologii

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

Problémy inženýra / vývojáře

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

Přirozený sklon k psaní kódu může vést k zahájení implementace před dokončením analýzy požadavků, což může mít za následek změny kódu, které splní skutečné požadavky, jakmile budou známy.
Technický personál a koncoví uživatelé mohou mít různé slovníky. V důsledku toho se mohou mylně domnívat, že jsou v dokonalé shodě, dokud nebude dodán hotový výrobek.
Inženýři a vývojáři se mohou pokusit přizpůsobit požadavky stávajícímu systému nebo modelu, spíše než vyvíjet systém specifický pro potřeby klienta.

Pokus o řešení

Jedním z pokusů o řešení komunikačních problémů bylo zaměstnat odborníky na obchodní nebo systémovou analýzu.

Techniky zavedené v 90. letech, jako je prototypování , Unified Modeling Language (UML), případy použití a agilní vývoj softwaru, jsou také zamýšleny jako řešení problémů, které se vyskytly u předchozích metod.

Na trh také vstoupila nová třída nástrojů pro simulaci nebo definici aplikací. Tyto nástroje jsou navrženy k překlenutí komunikační mezery mezi podnikovými uživateli a IT organizací - a také k tomu, aby umožnily „testování trhu“ aplikací před vytvořením jakéhokoli kódu. To nejlepší z těchto nástrojů nabízí:

elektronické tabule k načrtnutí toků aplikací a testování alternativ
schopnost zachytit obchodní logiku a potřeby dat
schopnost generovat vysoce věrné prototypy, které úzce napodobují finální aplikaci
interaktivita
schopnost přidávat kontextové požadavky a další komentáře
schopnost vzdálených a distribuovaných uživatelů spouštět a pracovat se simulací

Viz také

Reference

Bibliografie

Brian Berenbach; Daniel Paulish; Juergen Katzmeier; Arnold Rudorfer (2009). Softwarové a systémové požadavky: V praxi . New York: McGraw-Hill Professional. ISBN 978-0-07-160547-2.
Hay, David C. (2003). Analýza požadavků: Od obchodních pohledů po architekturu (1. vydání). Upper Saddle River, NJ: Prentice Hall. ISBN 0-13-028228-6.
Laplante, Phil (2009). Požadavky na software a systémy (1. vydání). Redmond, WA: CRC Press. ISBN 978-1-4200-6467-4.
McConnell, Steve (1996). Rychlý vývoj: Zkrocení plánů divokého softwaru (1. vyd.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
Nuseibeh, B .; Easterbrook, S. (2000). Inženýrství požadavků: cestovní mapa (PDF) . ICSE '00. Sborník z konference o budoucnosti softwarového inženýrství . str. 35–46. CiteSeerX 10.1.1.131.3116 . doi : 10,1145 / 336512,336523 . ISBN 1-58113-253-0.
Andrew Stellman a Jennifer Greene (2005). Aplikovaný softwarový projektový management . Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
Karl Wiegers & Joy Beatty (2013). Softwarové požadavky (3. vydání). Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5.

externí odkazy

Peer-reviewed Encyclopedia Entry on Requirements Engineering and Analysis
Proces definice požadavků zúčastněných stran na univerzitě v oblasti obrany --- Proces definice požadavků zúčastněných stran na stroji Wayback (archivováno 23. prosince 2015)
Pokyny k dokumentaci k systémovým požadavkům MIL-HDBK 520

Languages

In other projects