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

what is requirement analysis

Tento výukový program 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 obrovský úkol, který vytváří funkční softwarový produkt.

Softwarový produkt je postaven podle požadavků zákazníka. Tento softwarový produkt většinou odpovídá tomu, co očekával koncový zákazník / uživatel, zatímco tento produkt někdy plně nesplňuje to, co očekával zákazník / koncový uživatel.

Co se naučíte:

• Co je analýza požadavků?
  • Fáze / kroky analýzy požadavků
    • # 1) Shromažďování požadavků
    • # 2) Analýza shromážděných požadavků
    • # 3) Dokumentace analyzovaných požadavků
  • Převod obchodních požadavků na softwarové požadavky
  • Porozumění případům nefunkčních požadavků
  • Rozdíl mezi obchodními požadavky a softwarovými požadavky
• Závěr
  • Doporučené čtení

Co je analýza požadavků?

Rozumíme analýze požadavků pomocí příkladu.

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

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

Jak můžete z výše uvedených obrázků analyzovat, že v konečném produktu existuje nesoulad s očekáváním zákazníka. Může to být způsobeno nesčetnými důvody, viz. nesprávná implementace požadavků zákazníka, chybný design, nesprávné pochopení požadavků zákazníka programátory a týmem kvality atd.

Jak však vidíte, ať už jde o jakýkoli důvod nesprávného dodání produktu, hlavním důvodem je požadavek. Pokud by tedy proběhlo správné porozumění požadavku, jeho zachycení, implementace a testování, pomohlo by to zmírnit chybné a neúplné dodání produktu zákazníkovi / koncovému uživateli.

Kvalitní dodávka produktu vyžaduje správné shromáždění požadavků, efektivní prověření shromážděných požadavků a nakonec jasnou dokumentaci požadavků jako předběžnou podmínku. 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í aktivitou v SDLC, následovanou funkční specifikací atd. Analýza požadavků je zásadním krokem v SDLC, protože rezonuje s akceptačním testováním, které je zásadní pro přijetí produktu zákazníky.

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

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

1. Shromažďování požadavků který se také nazývá elicitace.
2. Poté následuje analyzovat shromážděné požadavky k pochopení správnosti a proveditelnosti převodu těchto požadavků na možný produkt.
3. A nakonec, dokumentování shromážděné požadavky.

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

Aby bylo zajištěno, ž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 to zákazník zamýšlí sdělit.

Mnohokrát není možné, aby shromažďování požadavků prováděli efektivně obchodní analytici od zákazníka. Může to být způsobeno závislostí na mnoha lidech v souvislosti s očekávaným konečným produktem, nástroji, prostředím atd. Vždy je tedy 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 softwarové kvality (QC i QA), jakýkoli prodejce třetí strany, který by mohl poskytnout podporu v projektu, koncový uživatel, pro kterého je produkt určen, softwaroví programátoři, další tým v organizaci, který by mohl poskytnout modul nebo softwarová platforma, softwarové knihovny atd. pro vývoj produktu.

Příklad: V organizaci vyvíjejí produkt ADAS (kamerový systém s prostorovým pohledem pro prestižního výrobce OEM), který potřebuje Zásobník autosaru a Zavaděč binární soubory, 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á porozumět různým závislostem na sobě navzájem a je možné odvrátit případný budoucí konflikt.

Někdy je vhodné vytvořit prototyp modelu plánovaného zamýšleného produktu a ukázat ho zákazníkovi. Jedná se o vynikající způsob, jak zákazníkům sdělit, jaký produkt očekávají a jak může vypadat později. To pomáhá zákazníkovi při vizualizaci produktu, 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 produktů:

1. V organizaci existuje podobný produkt, který zákazníci zamýšleli.
2. Nový produkt k vývoji.

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

Například, Kamerový systém s prostorovým výhledem vyvinutý pro výrobce OEM (GM, Volkswagen, BMW atd.) A lze jej předvést jinému výrobci OEM.

Mějte prosím na paměti , není rozumné zákazníkovi ukazovat produkt / proto produkt, který je ve vývoji, protože by mohlo dojít k porušení dohody o mlčenlivosti podepsané 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ší příklad může být systém informačního a zábavního systému, který vyvinula organizace a je již na trhu. Obchodní analytici a další zúčastněné strany v rámci organizace mohou naplánovat pro zákazníka ukázku dílny, kde budou zobrazeny informační a zábavní systémy 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 funkce napevno zakódovány v softwarových programech) nebo vytvořením vývojového diagramu nebo diagramu, který by mohl přesvědčit zákazníka, jak by produkt vypadal.

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

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

Shromážděné požadavky mohou mít formu uživatelské příběhy (v agilním vývoji), případy použití, dokumenty, diagramy, vývojové diagramy atd. v přirozeném jazyce zákazníka. Uživatelské příběhy se stávají populárními v moderním životním cyklu vývoje softwaru. Uživatelské příběhy jsou v podstatě souborem vstupů zákazníků v jejich přirozeném jazyce.

Příklad shromažďování požadavků: V kamerovém systému ADAS surround-view by mohl být jeden z příběhů uživatelů: „Jako uživatel bych měl být schopen vidět, co tam je, v pohledu zezadu na mé auto“.

Mohlo jich být mnoho 'proč,' otázky kladené na každý příběh uživatele, které zákazníkovi pomohou poskytnout podrobnější informace o požadavku.

Ve výše uvedeném příběhu uživatele, pokud zákazník řekne „Jako uživatel bych měl být schopen vidět, co je tam v pohledu zezadu na moje auto“, položit otázku 'proč “By mohl dát„ Jako uživatel bych měl být schopen vidět, co je tam v pohledu zezadu mého auta, abych mohl bezpečně zaparkovat auto “.

Kladení otázek 'proč' také pomáhá při vytváření objektivních a atomových požadavků z humongous přirozeného jazyka prohlášení poskytnutých zákazníkem. To lze snadno implementovat později v kódu.

jak otevřít xml soubor v prohlížeči

Dalším způsobem, jak tento požadavek shromáždit, je forma případy užití . Případ použití je postupný přístup k dosažení určitého výsledku. To neříká, jak bude software fungovat na vstupu uživatele, spíše říká, co se od vstupů uživatele očekává.

Příklad:

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

Shromáždění po požadavku, analýza požadavku začíná. V této fázi sedí různé zúčastněné strany a vedou brainstorming. Analyzují shromážděné požadavky a hledají proveditelnost jejich implementace. Diskutují spolu a případná 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 nebylo možné implementovat kvůli různým závislostem.

Příklad: Zákaznícimůže požádat o prostorový pohled na kamerový systém s funkcí zpětné kamery, která vám pomůže parkoviště auto. Zákazník může také požádat o Upoutávka funkce závěsu, která k práci využívá také zadní kameru.

Pokud zákazník uvede požadavek, pro který je zpětná kamera parkoviště pomoc by měla fungovat vždy bez výjimky, pak Upoutávka funkce by nikdy nefungovala a naopak.

ii) Obchodní analytik mohl pochopit požadavek z zákazník jinak, než jak programátor by vyložil.

Protože programátoři považují za technické odborníky, je vždy možné, že požadavky zákazníků budou nesprávně převedeny na funkční specifikace, které budou později nesprávně provedeny v dokumentech architektury a designu 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é poskytuje zákazník atd.

# 3) Dokumentace analyzovaných požadavků

Jakmile je provedena analýza 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 na softwarovou architekturu.

Příklad:

(iii) Požadavek na softwarový design.

Příklad:

(iv) Specifikace funkčních požadavků (přímo odvozena ze specifikací zákazníka.)

Příklad: „Když uživatel klepne na ikonu Bluetooth na infotainment HMI, měla by se zobrazit obrazovka Bluetooth.“

(proti) Nefunkční specifikace požadavku (viz. Výkon, napětí, zatížení atd.).

Příklad: 'Mělo by být možné spárovat 15 zařízení Bluetooth se systémem infotainmentu bez zhoršení výkonu systému.'

(my) Požadavky na uživatelské rozhraní.

Příklad: „Na obrazovce Tuner 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 dokumentovány v nástrojích pro správu požadavků, jako jsou IBM DOORS, HP QC. Někdy mají organizace své vlastní nástroje pro správu požadavků, které snižují náklady.

Pojďme se nyní podívat na proces konverze Obchodní požadavky na Softwarové požadavky (funkční a nefunkční).

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

Obchodní požadavky, jak jsou diskutovány výše, jsou požadavky na vysoké úrovni, které hovoří o tom, co chce koncový uživatel 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 způsobu implementace softwarového systému nebo komponenty.

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

K tomu je možné provést následující kroky:

nejlepší program pro opravu chyb registru

1. Rozdělte obchodní požadavky na vysoké úrovni na podrobné uživatelské příběhy.
2. Odvození vývojového diagramu k definování toku aktivit.
3. Poskytnutí podmínky, která ospravedlňuje odvozené uživatelské příběhy.
4. Drátové diagramy vysvětlující pracovní postup objektů.
5. Definování nefunkčních požadavků z obchodních požadavků.

Začněme příkladem automobilového informačního a zábavního systému.

Obchodní požadavek říká: „Koncový uživatel by měl mít přístup k poli widgetů Navigace z HMI informačního systému 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.

Pojďme převést 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 widgetů Navigace, abych mohl zadat cílovou adresu “. Tento uživatelský příběh říká, 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 k tomuto příběhu uživatele, viz.

1. Kdo jsou uživatelé?
2. Jak mohu získat přístup k navigaci, na palubě (z karty SD) nebo ze SmartPhone?
3. Jaký druh cílových záznamů mohu zadat?
4. Mělo by mi být umožněno vstoupit do cíle, i když je auto na parkovišti?

Jedná se o podrobnější příběhy uživatelů odvozené z příběhů uživatelů 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 převzít jeden z uživatelských dílčích příběhů a začít vyslýchat. Vezměme si (č. 3):

1. Mohu zadat cílové položky, jako jsou zeměpisné souřadnice, poštovní adresa, pomocí rozpoznávání řeči atd.?
2. Potřebuji GPS pro zadávání zeměpisných souřadnic?
3. Mohu zadat aktuální cílovou adresu vyhledáváním z historie adres?

# 2) Odvození vývojového diagramu k definování toku aktivit.

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

# 3) Poskytování podmínek, které ospravedlňují odvozené uživatelské příběhy.

Vidíme, že se objevují podrobnější informace v důsledku rozkladu obchodního požadavku na vysoké úrovni na podrobné příběhy uživatelů na nízké úrovni a 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í zadání cíle by měla být 1 s.
• Klávesnice pro zadávání cíle by měla mít alfanumerické znaky a speciální symboly.
• Na obrazovce pro zadání cíle navigace by mělo být přítomno přepínací tlačítko GPS.

Výše uvedené informace uspokojují příběhy uživatelů a umožňují, aby byl požadavek testován diskrétně a měřitelně, aby nedocházelo k záměně s požadavkem, zatímco je implementován jako funkce.

# 4) Drátové diagramy vysvětlující pracovní postup objektů.

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

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

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

Funkční požadavky však neobjasň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 systému infotainmentu pro automobily.

Pokud řidič (koncový uživatel) automobilu přehrává hudbu z USB a probíhá navigační navigace, obdrží také příchozí hovor přes Bluetooth v režimu hands-free, poté se zatížení procesoru a RAM zvýší na maximální úroveň, protože probíhá více procesů běží na pozadí.

V tomto okamžiku, pokud řidič klepne na rozhraní infotainment systému na dotykové obrazovce a odmítne příchozí hovor pomocí automatické odpovědi SMS (stejně jako to děláme 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 zátěž vysoká a testujeme dostupnost a spolehlivost.

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

Vezměte si příklad, informační a zábavní systém přijímá připojené SMS (možná 20 SMS do 10 sekund) prostřednictvím připojeného telefonu Bluetooth. Informační a zábavní systém by měl být schopen zpracovat všechny příchozí SMS a v žádném okamžiku by mu nemělo chybět žádné oznámení o příchozích SMS na informačním a zábavním rozhraní.

Výše uvedené příklady jsou případy nefunkčních požadavků, které nelze testovat pouze pomocí funkčních požadavků. Ačkoli někdy zákazníkům chybí poskytnutí těchto nefunkčních požadavků. Je odpovědností organizace poskytnout jim tyto informace při dodání produktu 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ů, vyžadují implementaci celého životního cyklu projektu, 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 od obchodních požadavků.

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

Výše jsme viděli, jak odvodit softwarové požadavky z obchodních požadavků na vysoké úrovni. Softwarové požadavky umožňují programátorovi a testovacímu technikovi vyvinout systém a efektivně jej otestovat. Nyní tedy víme, že obchodní požadavky jsou vysoké požadavky zákazníků na přirozený jazyk, zatímco softwarové požadavky jsou podrobné nízké požadavky, 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 zachycený při testování jednotky by mohl organizaci stát desítky tisíc dolarů a tato cena by mohla vést k milionům dolarů, pokud by přišla z trhu jako zpětné volání (v roce 2017, výrobce airbagů účtovaný USA, Takata a pokuta $ 1 miliarda kvůli explodujícím airbagům).

Organizace by místo soustředění na vývoj a kvalitu softwaru skončila s prováděním úkolů kontroly poškození, jako je analýza hlavních příčin, příprava 5 dokumentů, analýza stromu poruch, 8D dokument atd.

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

Doporučené čtení

• Fáze, metodologie, proces a modely SDLC (životní cyklus vývoje softwaru)
• Vlastnosti funkčních požadavků a nefunkčních požadavků
• Jak otestovat specifikaci softwarových požadavků (SRS)?
• 5 smrtelných chyb ve správě požadavků a jak je překonat
• Jak otestovat aplikaci bez požadavků?
• Opatření pro SSDLC (zabezpečený životní cyklus vývoje softwaru)
• Spirálový model - Co je to SDLC spirálový model?
• Co je model SDLC Waterfall?