Co je analýza požadavků a shromažďování v SDLC?

tento tutoriál vysvětluje, co je analýza požadavků, kroky analýzy požadavků, příklady a cíle shromažďování požadavků v SDLC:

vývoj softwaru je humongous úkol, který vytváří pracovní softwarový produkt.

softwarový produkt je postaven dle požadavku zákazníka. Většinou, tento softwarový produkt je v souladu s tím, co koncový zákazník / uživatel očekával, zatímco někdy tento produkt není plně v souladu s tím, co zákazník / koncový uživatel očekával.

co je analýza požadavků?

pojďme pochopit analýzu požadavků pomocí příkladu.

očekávání zákazníka / koncového uživatele:

zákazník / koncový uživatel obdrží:

, protože z výše uvedených obrázků můžete analyzovat, že v konečném produktu dochází k nesouladu s očekáváním zákazníka. Může to být z nesčetných důvodů, viz. nesprávná implementace požadavků zákazníka, chybný design, špatné pochopení požadavků zákazníka programátory a kvalitním týmem atd.

nicméně, jak vidíte, ať už je to nějaký důvod pro nesprávné dodání produktu, primárním důvodem je požadavek. Pokud by tedy bylo provedeno správné porozumění požadavkům, zachycení, implementace a testování, pomohlo by to zmírnit chybné a neúplné dodání produktu zákazníkovi/koncovému uživateli.

dobrá dodávka produktu vyžaduje správné shromažďování požadavků, efektivní zkoumání shromážděných požadavků a konečně jasnou dokumentaci požadavků jako předpoklad. Celý tento proces se také nazývá jako analýza požadavků v životním cyklu vývoje softwaru (SDLC)

Fáze/kroky analýzy požadavků

jak vidíte, Analýza požadavků je první činností v SDLC následovanou funkční specifikací a tak dále. Analýza požadavků je zásadním krokem v SDLC, protože rezonuje s akceptačním testováním, které je rozhodující pro přijetí produktu zákazníky.

v tomto tutoriálu vysvětlíme, jak se analýza požadavků provádí v SDLC. Uvidíme také různé kroky, výsledky, výzvy, a nápravná opatření v analýze požadavků.

Analýza požadavků začíná:

1. shromažďování požadavků, které se také nazývá elicitace.
2. následuje analýza shromážděných požadavků k pochopení správnosti a proveditelnosti přeměny těchto požadavků na možný produkt.
3. a konečně dokumentování shromážděných požadavků.

#1) shromažďování požadavků

abyste se ujistili, že všechny výše uvedené kroky jsou řádně provedeny, musí být od zákazníka shromážděny jasné, stručné a správné požadavky. Zákazník by měl být schopen správně definovat své požadavky a obchodní analytik by měl být schopen je shromáždit stejným způsobem, jakým jej zákazník zamýšlí sdělit.

mnohokrát není možné, aby shromažďování požadavků bylo prováděno efektivně obchodními analytiky od zákazníka. To může být způsobeno závislostí na mnoha lidech souvisejících s očekávaným konečným produktem, nástroji, prostředím atd. Proto je vždy dobré zapojit všechny zúčastněné strany, které by mohly ovlivnit nebo by mohly být ovlivněny konečným produktem.

možnou skupinou zúčastněných stran mohou být inženýři kvality softwaru (QC i QA), jakýkoli dodavatel třetí strany, který by mohl poskytnout podporu v projektu, koncový uživatel, pro kterého je produkt určen, programátoři softwaru, další tým v rámci organizace, který by mohl poskytnout modul nebo softwarovou platformu, softwarové knihovny atd. pro vývoj produktů.

příklad: v Organizaci vyvíjejí produkt ADAS (kamerový systém surround-view pro prestižní OEM), který potřebuje binární soubory Autosar stack a Bootloader, které jsou přijímány od jiného dodavatele.

zapojení různých zúčastněných stran do fáze shromažďování požadavků pomáhá pochopit různé závislosti na sobě a případné budoucí konflikty by mohly být odvráceny.

někdy je dobré vytvořit prototypový model zamýšleného produktu a ukázat jej zákazníkovi. To je vynikající způsob, jak sdělit zákazníkům, jaký produkt očekávají a jak to může vypadat později. To pomáhá zákazníkovi vizualizovat produkt, který očekává, a pomáhá mu přijít s jasnými požadavky.

vytvoření tohoto prototypu závisí na dvou typech produktu:

1. podobný produkt, který zákazníci zamýšleli, existuje v rámci organizace.
2. nový produkt, který má být vyvinut.

(i) v prvním případě je snazší ukázat zákazníkovi, jak by konečný produkt vypadal a jak by se vyvíjel. V automobilovém průmyslu ADAS je možné zákazníkům ukázat další produkt, který je již na trhu a byl vyvinut v rámci organizace.

například kamerový systém prostorového pohledu vyvinutý pro OEM (GM, Volkswagen, BMW atd.)a může být předveden jinému OEM.

Vezměte prosím na vědomí, že není moudré ukazovat produkt / proto produkt zákazníkovi, který je ve vývoji, protože může porušovat dohodu o mlčenlivosti podepsanou s jiným zákazníkem, pro kterého je tento produkt vyvíjen. Může to také vést ke zbytečnému právnímu sporu.

dalším příkladem může být informační systém vyvinutý organizací a je již na trhu. Obchodní analytici a další zúčastněné strany v rámci organizace mohou naplánovat ukázku workshopu pro zákazníka, zobrazení informačních systémů s hmatatelným HMI, porty konektorů zařízení,karanténa, atd.

to zákazníkovi pomůže pochopit, jak by konečný produkt vypadal, a poskytnout jeho požadavky mnohem jasněji.

(ii) druhého případu lze dosáhnout vytvořením základního pracovního modelu jednoduchým kódováním a sestavením (většinou jsou zde prvky pevně zakódovány v softwarových programech) nebo vytvořením vývojového diagramu nebo diagramu, který by přesvědčil zákazníka, jak bude produkt vypadat.

v každém případě by to bylo oddych pro proces shromažďování požadavků, protože zákazník nyní ví, co chce.

obchodní analytik může nyní organizovat formální schůzky vyvolávání požadavků, kde by mohly být pozvány všechny zúčastněné strany, a tak si mohou všimnout různých požadavků poskytnutých zákazníkem (v některých případech, pokud jsou zúčastněné strany více v počtu, mohl by být jmenován samostatný písař, který by zaznamenal požadavky zákazníků nebo uživatelské příběhy, aby se obchodní analytik mohl soustředit na moderování schůzky).

shromážděné požadavky mohou být ve formě uživatelských příběhů (v agilním vývoji), případů použití, dokumentů v přirozeném jazyce zákazníka, diagramů, vývojových diagramů atd. Uživatelské příběhy se stávají populární v současném životním cyklu vývoje softwaru. Uživatelské příběhy jsou v podstatě souborem zákaznických vstupů v jejich přirozeném jazyce.

příklad shromažďování požadavků: v kamerovém systému ADAS surround-view By jeden možný uživatelský příběh mohl být: „jako uživatel bych měl být schopen vidět, co je v zadním pohledu mého auta“.

mohlo by existovat mnoho otázek“ proč“, kladených na každý příběh uživatele, což zákazníkovi pomůže poskytnout podrobnější informace o požadavku.

ve výše uvedeném uživatelském příběhu, pokud zákazník říká: „Jako uživatel bych měl být schopen vidět, co je v zpětném pohledu na mé auto“, a položit otázku „proč“ mohl dát „jako uživatel bych měl být schopen vidět, co je v zpětném pohledu na mé auto, abych mohl bezpečně zaparkovat své auto“.

položení otázky „Proč“ také pomáhá při vytváření objektivních a atomových požadavků z humongous prohlášení přirozeného jazyka zadaných zákazníkem. To lze snadno implementovat později v kódu.

dalším způsobem shromažďování požadavku je ve formě případů použití. Případ použití je krok za krokem k dosažení určitého výsledku. To neříká, jak bude software pracovat na vstupu uživatele, spíše to říká, co se očekává od uživatelských vstupů.

příklad:

#2) Analýza shromážděných požadavků

po shromáždění požadavků začíná analýza požadavků. V této fázi sedí různé zúčastněné strany a dělají brainstorming. Analyzují shromážděné požadavky a hledají proveditelnost jejich implementace. Diskutují mezi sebou a jakákoli nejednoznačnost je vyřešena.

tento krok je důležitý v procesu analýzy požadavků z následujících hlavních důvodů:

(i) zákazník může poskytnout některé požadavky, které by mohly být nemožné implementovat kvůli různým závislostem.

příklad: zákazníci mohou požádat o prostorové zobrazení kamerového systému pomocí funkce zpětné kamery, která pomůže při parkování automobilu. Zákazník může také požádat o funkci závěsu přívěsu, která také používá zadní kameru k práci.

pokud zákazník uvede požadavek, aby zpětná kamera pro parkovací asistenci fungovala po celou dobu bez výjimky, pak by Funkce přívěsu nikdy nefungovala a naopak.

(ii) obchodní analytik mohl chápat požadavek zákazníka jinak, než jak by programátor interpretoval.

vzhledem k tomu, že programátoři uvažují jako techničtí odborníci, je vždy možné, že požadavky zákazníků jsou nesprávně převedeny na funkční specifikace, které budou později nesprávně provedeny v dokumentech architektury a návrhu a následně v kódu. Dopad je exponenciální, a proto by měl být zkontrolován.

možným nápravným opatřením by mohlo být dodržování agilní metody vývoje softwaru, sledování případů použití, které zákazník poskytuje atd.

#3) dokumentování analyzovaných požadavků

po dokončení analýzy požadavků začíná dokumentace požadavků. Z analýzy požadavků vycházejí různé typy požadavků.

některé z nich jsou:

(i) specifikace požadavků zákazníka.

(ii) požadavek softwarové architektury.

příklad:

(iii) požadavek na návrh softwaru.

příklad:

(iv) SPECIFIKACE funkčních požadavků (přímo odvozená od specifikací zákazníka.)

příklad: „když uživatel klepne na ikonu Bluetooth na Infotainment HMI, měla by se zobrazit obrazovka Bluetooth“

(v) Specifikace nefunkčních požadavků (viz. výkon, stres, zatížení atd.).

příklad: „mělo by být možné spárovat 15 Zařízení Bluetooth s informačním systémem bez zhoršení výkonu systému“.

(vi) požadavky na uživatelské rozhraní.

příklad: „Na obrazovce tuneru FM by mělo být k dispozici tlačítko pro výběr různých stanic“

výše uvedené požadavky jsou zaznamenány a zdokumentovány v nástrojích pro správu požadavků, jako jsou IBM DOORS, HP QC. Někdy organizace mají své vlastní nástroje pro správu požadavků ke snížení nákladů.

podívejme se nyní na proces přeměny obchodních požadavků na softwarové požadavky (funkční a nefunkční).

převod obchodních požadavků na softwarové požadavky

obchodní požadavky, jak je uvedeno výše, jsou požadavky na vysoké úrovni, které hovoří o tom, co koncový uživatel chce od definované akce v softwarovém systému. Vývoj celého softwarového systému na základě těchto požadavků není možný, protože není uveden podrobný popis toho, jak bude softwarový systém nebo komponenta implementována.

proto musí být obchodní požadavky rozděleny na podrobnější softwarové požadavky, které budou dále podrobně popsány funkčním a nefunkčním požadavkům.

za tímto účelem lze provést následující kroky:

1. rozdělte obchodní požadavky na vysoké úrovni na podrobné uživatelské příběhy.
2. odvození vývojového diagramu pro definování toku činností.
3. poskytnutí podmínky, která ospravedlňuje odvozené uživatelské příběhy.
4. Wireframe diagramy vysvětlit pracovní postup objektů.
5. definování nefunkčních požadavků mimo obchodní požadavky.

začněme příkladem automobilového Informačního systému.

obchodní požadavek říká: „koncový uživatel by měl mít přístup k navigačnímu widgetu z Informačního systému HMI a měl by být schopen nastavit cílovou adresu“.

výše uvedené kroky lze tedy implementovat jako:

#1) rozdělte obchodní požadavky na vysoké úrovni na podrobné uživatelské příběhy.

převedme tento obchodní požadavek na příběh uživatele na vysoké úrovni: „jako uživatel bych měl mít přístup do pole navigačního widgetu, abych mohl zadat cílovou adresu“. Tento uživatelský příběh vypráví, co koncový uživatel potřebuje. Pokusíme se definovat, jak tento požadavek implementovat.

začněme položením možných otázek tomuto uživatelskému příběhu viz.

1. kdo jsou uživatelé?
2. Jak mohu přistupovat k navigaci, na palubě (z SD karty) nebo ze smartphonu?
3. jaké cílové položky mohu zadat?
4. měl bych mít možnost vstoupit do cíle, i když je auto na parkovišti?

jedná se o podrobnější uživatelské příběhy na úrovni odvozené z uživatelských příběhů na vysoké úrovni a pomohly by nám získat lepší přehled o našich obchodních požadavcích.

v tomto okamžiku můžeme vzít jeden z uživatelských dílčích příběhů a začít se ptát. Vezměme si (ne. 3):

1. Mohu zadat cílové položky, jako jsou Geo souřadnice, Poštovní adresa, rozpoznávání řeči atd.?
2. potřebuji GPS pro zadávání Geo-souřadnic?
3. Mohu zadat aktuální cílovou adresu hledáním z historie adres?

#2) odvození vývojového diagramu pro definování toku činností.

nyní vidíme, že obchodní požadavek je rozdělen na velmi podrobné případy použití, které lze označit ve vývojovém diagramu níže:

#3) poskytování podmínek, které odůvodňují odvozené uživatelské příběhy.

vidíme, že podrobnější informace se objevují v důsledku rozkladu požadavků na vysoké úrovni na podrobné příběhy uživatelů na nízké úrovni a na vývojový diagram. Z tohoto vývojového diagramu můžeme získat technické podrobnosti potřebné pro implementaci viz.

• doba načítání obrazovky pro zobrazení cílové položky by měla být 1 sec.
• klávesnice cílové položky by měla mít alfanumerické znaky a speciální symboly.
• tlačítko zapnutí / vypnutí GPS by mělo být přítomno na obrazovce cílového vstupu navigace.

výše uvedené informace splňují uživatelské příběhy a umožňují, aby byl požadavek testován diskrétně a měřitelně, aby se zabránilo záměně s požadavkem při implementaci jako funkce.

#4) Wireframe diagramy vysvětlit pracovní postup objektů.

z výše uvedeného případu použití odvodíme schéma drátového modelu, díky kterému bude uživatelské rozhraní jasnější.

#5) vymezení nefunkčních požadavků z obchodních požadavků.

je nezbytné, aby podrobné požadavky na software byly odvozeny z obchodních požadavků na vysoké úrovni, ale mnohokrát jsou identifikovány pouze funkční požadavky, které říkají, jak se systém bude chovat ke konkrétnímu vstupu/akci uživatele.

funkční požadavky však nezjasňují výkon systémů a další kvalitativní parametry, jako je dostupnost, spolehlivost atd.

příklady:

a) vezmeme si příklad výše uvedeného informačního systému pro automobily.

pokud řidič(koncový uživatel) automobilu přehrává hudbu z USB a Navigační pokyny probíhají, také obdrží příchozí hovor přes Bluetooth v režimu Hands-free, načte se spotřeba CPU a RAM na maximální úroveň, protože na pozadí běží více procesů.

v tomto okamžiku, pokud řidič klepne na dotykové rozhraní informačního systému a odmítne příchozí hovor prostřednictvím SMS s automatickou odpovědí (stejně jako v našich mobilních telefonech), systém by měl být schopen provést tento úkol a neměl by viset nebo havarovat. Jedná se o výkon systému, když je zatížení vysoké a testujeme dostupnost a spolehlivost.

b) dalším případem je stresový scénář.

Vezměte si příklad, infotainment systém přijímá zpět SMS (možná 20 SMS během 10 sekund) přes připojený telefon Bluetooth. Infotainment systém by měl být schopen zpracovat všechny příchozí SMS a v žádném okamžiku by neměl chybět některý z příchozích SMS oznámení na Infotainment HMI.

výše uvedené příklady jsou případy nefunkčních požadavků, které nemohly být testovány pouze pomocí funkčních požadavků. I když někdy zákazníkům chybí poskytování těchto nefunkčních požadavků. Je odpovědností organizace poskytnout jim tyto informace, když je produkt dodán zákazníkovi.

porozumění případům nefunkčních požadavků

níže uvedená tabulka vysvětluje nefunkční požadavky:

nefunkční požadavky, na rozdíl od funkčních požadavků, vezměte celý životní cyklus projektu, aby se realizoval, protože jsou implementovány postupně v příslušných agilních sprintech nebo v různých iteracích.

takto odvozujeme softwarové požadavky z obchodních požadavků.

rozdíl mezi obchodními požadavky a softwarovými požadavky

viděli jsme výše, jak odvodit softwarové požadavky z obchodních požadavků na vysoké úrovni. Softwarové požadavky umožňují programátorovi a zkušebnímu technikovi vyvinout systém a efektivně jej otestovat. Nyní tedy víme, že obchodní požadavky jsou požadavky na přirozený jazyk zákazníků na vysoké úrovni, zatímco softwarové požadavky jsou podrobné požadavky na nízké úrovni, které pomáhají při implementaci softwarového systému.

podívejme se na podrobný rozdíl mezi těmito dvěma typy požadavků.

závěr

Analýza požadavků je páteří každého modelu SDLC.

problém zmeškaný během analýzy požadavků a chycený při testování jednotek by mohl organizaci stát desítky tisíc dolarů a tyto náklady by mohly vést k milionům dolarů, pokud pocházejí z trhu jako zpětné volání (v roce 2017 USA účtovaly výrobce airbagů, Takata pokutu ve výši $ 1Billion kvůli explodujícím airbagům).

organizace by nakonec provedla úkoly kontroly poškození, jako je analýza příčin, příprava dokumentů 5, analýza stromu poruch, dokument 8D atd. místo toho, abychom se soustředili na vývoj a kvalitu softwaru.

v nejhorších případech by byla organizace vtažena do soudních sporů podaných zákazníkem, pokud je postižená funkce bezpečnostní / bezpečnostní, jako je bezpečnostní přístup, airbag, ABS (protiblokovací brzdový systém) atd.