Čo je analýza požiadaviek a zhromažďovanie v SDLC?

what is requirement analysis

Tento výukový program vysvetľuje, čo je analýza požiadaviek, kroky analýzy požiadaviek, príklady a ciele zhromažďovania požiadaviek v SDLC:

Vývoj softvéru je obrovská úloha, ktorá vytvára funkčný softvérový produkt.

Softvérový produkt je vyrobený podľa požiadaviek zákazníka. Väčšinou je tento softvérový produkt v súlade s tým, čo očakával koncový zákazník / používateľ, zatiaľ čo tento produkt niekedy úplne nezodpovedá tomu, čo očakával zákazník / koncový používateľ.

Čo sa dozviete:

• Čo je analýza požiadaviek?
  • Fázy / kroky analýzy požiadaviek
    • # 1) Zhromažďovanie požiadaviek
    • # 2) Analýza zhromaždených požiadaviek
    • # 3) Zdokumentovanie analyzovaných požiadaviek
  • Prevod obchodných požiadaviek na softvérové ​​požiadavky
  • Pochopenie prípadov nefunkčných požiadaviek
  • Rozdiel medzi obchodnými požiadavkami a softvérovými požiadavkami
• Záver
  • Odporúčané čítanie

Čo je analýza požiadaviek?

Pochopme Analýza požiadaviek pomocou príkladu.

Očakávanie zákazníka / koncového používateľa:

Zákazník / koncový používateľ dostane:

Ako môžete z vyššie uvedených obrázkov analyzovať, že v konečnom produkte existuje nesúlad s očakávaním zákazníka. Môže to byť z mnohých dôvodov, napr. nesprávna implementácia požiadaviek zákazníka, chybný dizajn, nesprávne pochopenie požiadaviek zákazníka programátormi a tímom kvality atď.

Ako však môžete vidieť, nech už je to akýkoľvek dôvod nesprávneho dodania produktu, hlavným dôvodom je požiadavka. Ak by sa teda urobilo správne pochopenie, zachytenie, implementácia a testovanie požiadaviek, pomohlo by to zmierniť chybné a neúplné dodanie produktu zákazníkovi / koncovému používateľovi.

Kvalitná dodávka produktu vyžaduje správne zhromaždenie požiadaviek, efektívne preskúmanie zhromaždených požiadaviek a nakoniec jasnú dokumentáciu požiadaviek ako predpoklad. Celý tento proces sa tiež nazýva ako Analýza požiadaviek v životnom cykle vývoja softvéru (SDLC)

Fázy / kroky analýzy požiadaviek

Ako vidíte, Analýza požiadaviek je prvou aktivitou v SDLC, po ktorej nasleduje Funkčná špecifikácia atď. Analýza požiadaviek je dôležitým krokom v SDLC, pretože rezonuje s testami prijatia, ktoré sú kritické pre prijatie produktu zákazníkmi.

V tomto tutoriále vysvetlíme, ako sa analýza požiadaviek vykonáva v SDLC. V analýze požiadaviek tiež uvidíme rôzne príslušné kroky, výsledky, výzvy a nápravné opatrenia.

Analýza požiadaviek začína:

1. Zhromažďovanie požiadaviek ktorá sa tiež nazýva elicitácia.
2. Potom nasleduje analyzovať zhromaždené požiadavky na pochopenie správnosti a uskutočniteľnosti premeny týchto požiadaviek na možný produkt.
3. A nakoniec, dokumentovanie zozbierané požiadavky.

# 1) Zhromažďovanie požiadaviek

Aby ste sa ubezpečili, že všetky vyššie uvedené kroky sú správne vykonané, musíte od zákazníka zhromaždiť jasné, stručné a správne požiadavky. Zákazník by mal byť schopný správne definovať svoje požiadavky a obchodný analytik by mal byť schopný ich zhromaždiť rovnakým spôsobom, ako to zamýšľa oznámiť.

Mnohokrát nie je možné, aby zhromažďovanie požiadaviek efektívne vykonávali obchodní analytici od zákazníka. Môže to byť spôsobené závislosťou od mnohých ľudí v súvislosti s očakávaným konečným produktom, nástrojmi, prostredím atď. Vždy je preto dobré zapojiť všetky zainteresované strany, ktoré by mohli mať vplyv na konečný produkt alebo na neho môžu mať vplyv.

Možnou skupinou zainteresovaných strán by mohli byť inžinieri softvérovej kvality (QC aj QA), akýkoľvek dodávateľ tretej strany, ktorý by mohol poskytnúť podporu v rámci projektu, konečný užívateľ, pre ktorého je produkt určený, softvéroví programátori, ďalší tím v rámci organizácie, ktorý by mohol poskytnúť modul alebo softvérová platforma, softvérové ​​knižnice atď. na vývoj produktu.

Príklad: V organizácii vyvíjajú produkt ADAS (kamerový systém priestorového zobrazenia pre prestížneho výrobcu OEM), ktorý potrebuje Zásobník Autosar a Bootloader binárne súbory, ktoré sú prijaté od iného dodávateľa.

Zapojenie rôznych zainteresovaných strán do fázy zhromažďovania požiadaviek pomáha porozumieť rôznym vzájomným závislostiam a dalo by sa zabrániť možnému budúcemu konfliktu.

Niekedy je dobré vytvoriť prototyp plánovaného produktu a ukázať ho zákazníkovi. Toto je vynikajúci spôsob, ako zákazníkom oznámiť, aký produkt očakávajú a ako môže vyzerať neskôr. To pomáha zákazníkom pri vizualizácii produktu, ktorý očakávajú, a pomáha mu prísť s jasnými požiadavkami.

Táto tvorba prototypu závisí od dvoch typov produktu:

1. Podobný produkt, ktorý zákazníci zamýšľali, existuje v organizácii.
2. Vyvinutý nový produkt.

i) V prvom prípade je jednoduchšie zákazníkovi ukázať, ako by konečný produkt vyzeral a ako by sa vyvíjal. V automobilovom ADAS je možné zákazníkom ukázať ďalší produkt, ktorý je už na trhu a bol vyvinutý v rámci organizácie.

Napríklad, Kamerový systém s priestorovým výhľadom vyvinutý pre výrobcu OEM (GM, Volkswagen, BMW atď.) A môže byť prezentovaný inému OEM.

Vezmite prosím na vedomie , nie je rozumné ukazovať produkt / protokol produktu zákazníkovi, ktorý je vo vývoji, pretože by to mohlo porušiť Dohodu o mlčanlivosti podpísanú s iným zákazníkom, pre ktorého je tento produkt vyvíjaný. Môže to mať za následok aj zbytočné právne spory.

Ďalší príklad môže byť systém informačno-zábavného systému, ktorý vyvinula organizácia a už je na trhu. Obchodní analytici a ďalšie zainteresované strany v rámci organizácie môžu naplánovať pre zákazníka ukážku dielne, ktorá bude obsahovať informačno-zábavné systémy s hmatateľným HMI, porty konektorov zariadení, karanténu atď.

To pomôže zákazníkovi pochopiť, ako by konečný produkt vyzeral, a oveľa jasnejšie vybaviť svoje požiadavky.

ii) Druhý prípad je možné dosiahnuť vytvorením základného pracovného modelu jednoduchým kódovaním a zostavením (väčšinou sú tu funkcie napevno naprogramované v softvérových programoch) alebo vytvorením vývojového diagramu alebo diagramu, ktorý zákazníka presvedčí, ako bude produkt vyzerať.

V každom prípade by to bolo narušenie procesu zhromažďovania požiadaviek, pretože zákazník teraz vie, čo chce.

Obchodný analytik môže teraz zorganizovať formálne stretnutia na vyvolanie formálnych požiadaviek, na ktoré môžu byť pozvané všetky zúčastnené strany, a tým si môže zapísať rôzne požiadavky poskytované zákazníkom (v niektorých prípadoch, ak je ich počet väčší, je možné určiť samostatného pisára na zapísanie zákazníka) požiadavky alebo príbehy používateľov, aby sa obchodný analytik mohol sústrediť na moderovanie stretnutia).

Zhromaždené požiadavky môžu byť vo forme príbehy používateľov (v agilnom vývoji), prípady použitia, dokumenty, diagramy, vývojové diagramy atď. v prirodzenom jazyku zákazníka. Príbehy používateľov sa stávajú populárnymi v životnom cykle súčasného vývoja softvéru. Príbehy používateľov sú v podstate súborom vstupov zákazníkov v ich prirodzenom jazyku.

Príklad zhromažďovania požiadaviek: V kamerovom systéme ADAS s priestorovým výhľadom môže byť jeden z možných príbehov používateľov: „Ako užívateľ by som mal byť schopný vidieť to, čo tam je, v spätnom pohľade na moje auto.“

Mohlo ich byť veľa „Prečo“ otázky kladené na jednotlivé príbehy používateľov, ktoré zákazníkovi pomôžu pri poskytovaní podrobnejších informácií o požiadavke.

Ak zákazník v predchádzajúcom príbehu používateľa povie „Ako používateľ by som mal byť schopný vidieť to, čo je tam v spätnom pohľade na moje auto“, položil otázku „Prečo By mohol dať „Ako používateľ by som mal byť schopný vidieť, čo je tam v spätnom pohľade na moje auto, aby som mohol bezpečne zaparkovať svoje auto “.

Položenie otázky „Prečo“ pomáha tiež pri vytváraní objektívnych a atómových požiadaviek z humongóznych výrokov v prirodzenom jazyku poskytovaných zákazníkom. To sa dá ľahko implementovať neskôr v kóde.

dobrý bezplatný firewall pre Windows 10

Ďalším spôsobom, ako zhromaždiť požiadavku, je forma prípady použitia . Prípad použitia je postupný prístup k dosiahnutiu určitého výsledku. To nehovorí o tom, ako bude softvér fungovať na vstupe používateľa, skôr hovorí, čo sa od vstupov používateľa očakáva.

Príklad:

# 2) Analýza zhromaždených požiadaviek

Zhromažďovanie požiadaviek po dátume, analýza požiadaviek sa začína. V tejto fáze rôzne zúčastnené strany sedia a vedú brainstorming. Analyzujú zhromaždené požiadavky a hľadajú realizovateľnosť ich implementácie. Diskutujú medzi sebou a akékoľvek nejasnosti sú vyriešené.

Tento krok je dôležitý v procese analýzy požiadaviek z nasledujúcich hlavných dôvodov:

i) Zákazník môže poskytnúť niektoré požiadavky, ktoré by nebolo možné implementovať kvôli rôznym závislostiam.

Príklad: Zákaznícimôže požiadať o priestorový pohľad na kamerový systém s funkciou spätnej kamery, ktorá vám pomôže v parkovisko auto. Zákazník môže tiež požiadať o Trailer funkcia zapojenia, ktorá na prácu využíva aj zadný fotoaparát.

Ak zákazník uvedie požiadavku, že spätná kamera pre parkovisko pomoc by mala fungovať vždy bez výnimky, potom Trailer funkcia by nikdy nefungovala a naopak.

ii) Obchodný analytik mohol pochopiť požiadavku od zákazník inak ako a programátor by tlmočil.

Pretože programátori myslia ako technických odborníkov, je vždy možné, že požiadavky zákazníkov budú nesprávne prevedené na funkčné špecifikácie, ktoré budú neskôr nesprávne urobené v dokumentoch o architektúre a dizajne a následne v kóde. Dopad je exponenciálny, a preto by sa mal skontrolovať.

Možným nápravným opatrením by mohlo byť dodržiavanie agilnej metódy vývoja softvéru, sledovanie prípadov použitia, ktoré poskytuje zákazník, atď.

# 3) Zdokumentovanie analyzovaných požiadaviek

Po dokončení analýzy požiadaviek sa začne dokumentácia požiadaviek. Z analýzy požiadaviek vychádzajú rôzne typy požiadaviek.

Niektoré z nich sú:

i) Špecifikácia požiadaviek zákazníka.

ii) Požiadavka na softvérovú architektúru.

Príklad:

iii) Požiadavka na softvérový dizajn.

Príklad:

iv) Špecifikácia funkčných požiadaviek (priamo odvodená zo špecifikácií zákazníka.)

otázky a odpovede z rozhovoru s technickou podporou

Príklad: „Keď používateľ klepne na ikonu Bluetooth na informačno-zábavnom rozhraní HMI, mala by sa zobraziť obrazovka Bluetooth.“

(v) Nefunkčná požiadavka (napr. Výkon, namáhanie, zaťaženie atď.).

Príklad: „Malo by byť možné spárovať 15 zariadení Bluetooth so systémom infotainmentu bez zníženia výkonu systému.“

(my) Požiadavky na užívateľské rozhranie.

Príklad: „Na obrazovke Tuner FM by malo byť k dispozícii tlačidlo na výber rôznych staníc“

Vyššie uvedené požiadavky sú zaznamenané a zdokumentované v nástrojoch na správu požiadaviek, ako sú IBM DOORS, HP QC. Organizácie niekedy majú svoje vlastné nástroje na správu požiadaviek na zníženie nákladov.

Pozrime sa teraz na proces premeny Obchodné požiadavky do Softvérové ​​požiadavky (funkčné a nefunkčné).

Prevod obchodných požiadaviek na softvérové ​​požiadavky

Obchodné požiadavky, ako sú diskutované vyššie, sú požiadavkami na vysokej úrovni, ktoré hovoria o tom, čo koncový používateľ chce od definovanej akcie v softvérovom systéme. Vývoj celého softvérového systému na základe týchto požiadaviek nie je možný, pretože nie je uvedený podrobný popis toho, ako bude softvérový systém alebo komponent implementovaný.

Obchodné požiadavky sa preto musia rozdeliť na podrobnejšie softvérové ​​požiadavky, ktoré sa budú ďalej podrobnejšie zaoberať funkčnými a nefunkčnými požiadavkami.

K tomu je možné postupovať podľa nasledujúcich krokov:

1. Rozdeľte obchodné požiadavky na vysokej úrovni na podrobné príbehy používateľov.
2. Odvodenie vývojového diagramu na definovanie toku aktivít.
3. Poskytnutie podmienky, ktorá odôvodňuje odvodené príbehy používateľov.
4. Drôtové diagramy na vysvetlenie pracovného toku objektov.
5. Definovanie nefunkčných požiadaviek z obchodných požiadaviek.

Začnime príkladom Automobilový informačno-zábavný systém.

Obchodná požiadavka hovorí: „Koncový používateľ by mal mať prístup k widgetu Navigácia z informačného systému HMI a mal by byť schopný nastaviť cieľovú adresu“.

Vyššie uvedené kroky teda možno implementovať ako:

# 1) Rozdeľte obchodné požiadavky na vysokej úrovni na podrobné príbehy používateľov.

Prenesme túto obchodnú požiadavku na príbeh používateľa na vysokej úrovni, “ Ako používateľ by som mal mať prístup do poľa widgetov Navigácia, aby som mohol zadať cieľovú adresu “. Tento príbeh používateľa hovorí, čo koncový užívateľ potrebuje. Pokúsime sa definovať, ako implementovať túto požiadavku.

Začnime položením možných otázok k tomuto príbehu používateľa, viď.

1. Kto sú používatelia?
2. Ako môžem získať prístup k navigácii, na palube (z SD karty) alebo zo SmartPhone?
3. Aký druh cieľových položiek môžem zadať?
4. Malo by mi byť umožnené vstúpiť do cieľa, aj keď je auto na parkovisku?

Toto sú podrobnejšie príbehy používateľov odvodené z príbehov používateľov vysokých úrovní a pomohli by nám získať viac informácií o našich obchodných požiadavkách.

V tomto okamihu môžeme začať využívať niektorý z používateľských podpríbehov a začať pýtať. Vezmime si (č. 3):

1. Môžem zadať cieľové položky, napríklad geografické súradnice, poštovú adresu, rozpoznávanie reči atď.?
2. Potrebujem GPS na zadávanie geografických súradníc?
3. Môžem zadať aktuálnu cieľovú adresu vyhľadávaním z histórie adries?

# 2) Odvodenie vývojového diagramu na definovanie toku aktivít.

Teraz vidíme, že obchodné požiadavky sú rozdelené na veľmi podrobné prípady použitia, ktoré je možné vo vývojovom diagrame označiť takto:

# 3) Poskytnutie podmienok, ktoré odôvodňujú odvodené príbehy používateľov.

Vidíme, že podrobnejšie informácie sa objavujú v dôsledku rozkladu obchodných požiadaviek na vysokej úrovni na podrobné príbehy používateľov na nízkej úrovni a na vývojový diagram. Z tohto vývojového diagramu môžeme získať technické podrobnosti potrebné na implementáciu, viď.

• Doba načítania obrazovky na zobrazenie zadania cieľa by mala byť 1 s.
• Klávesnica pre zadávanie cieľa by mala mať alfanumerické znaky a špeciálne symboly.
• Na obrazovke zadávania cieľa navigácie by malo byť prepínacie tlačidlo zapnutia / vypnutia GPS.

Vyššie uvedené informácie uspokoja užívateľské príbehy a umožňujú, aby sa požiadavka testovala diskrétne a merateľne, aby sa predišlo akejkoľvek zámene s požiadavkou, zatiaľ čo sa implementuje ako funkcia.

# 4) Drôtové diagramy na vysvetlenie pracovného toku objektov.

Z vyššie uvedeného prípadu použitia odvodíme drôtový diagram, ktorý sprehľadní používateľské rozhranie.

# 5) Definovanie nefunkčných požiadaviek z obchodných požiadaviek.

Je nevyhnutné, aby boli podrobné softvérové ​​požiadavky odvodené z obchodných požiadaviek na vysokej úrovni, ale často sú identifikované iba funkčné požiadavky, ktoré hovoria o tom, ako sa systém bude správať ku konkrétnemu vstupu / akcii používateľa.

Funkčné požiadavky však neobjasňujú výkon systémov a ďalšie kvalitatívne parametre, ako sú dostupnosť, spoľahlivosť atď.

Príklady:

a) Vezmeme si príklad vyššie uvedeného automobilového informačno-zábavného systému.

Ak vodič (koncový užívateľ) vo vozidle prehráva hudbu z USB a prebieha navigačné navádzanie, prijme aj prichádzajúci hovor cez Bluetooth v režime Hands-free, potom sa zaťaženie CPU a RAM zvýši na maximálnu úroveň, pretože prebieha viac procesov bežiaci na pozadí.

Ak v tomto okamihu vodič klepne na rozhranie dotykovej obrazovky informačného systému, aby odmietol prichádzajúci hovor pomocou automatickej odpovede SMS (rovnakým spôsobom ako to robíme v našich mobilných telefónoch), systém by mal byť schopný vykonať túto úlohu a nemal by visieť alebo havarovať. Toto je výkon systému, keď je zaťaženie vysoké a testujeme dostupnosť a spoľahlivosť.

b) Ďalším prípadom je stresový scenár.

Vezmime si príklad, informačný systém prijíma správy typu back-to-back (možno 20 SMS do 10 sekúnd) prostredníctvom pripojeného telefónu Bluetooth. Informačný systém by mal byť schopný spracovať všetky prichádzajúce SMS a v žiadnom okamihu by mu nemalo chýbať žiadne upozornenie na prichádzajúcu SMS na informačnom rozhraní HMI.

Vyššie uvedené príklady sú prípady nefunkčných požiadaviek, ktoré nebolo možné testovať iba prostredníctvom funkčných požiadaviek. Aj keď niekedy zákazníkom chýba poskytnutie týchto nefunkčných požiadaviek. Je zodpovednosťou organizácie poskytnúť im tieto informácie pri dodaní produktu zákazníkovi.

Pochopenie prípadov nefunkčných požiadaviek

Nasledujúca tabuľka vysvetľuje nefunkčné požiadavky:

Nefunkčné požiadavky, na rozdiel od funkčných požiadaviek, vyžadujú implementáciu celého životného cyklu projektu, pretože sú implementované postupne v príslušných Agilných sprintoch alebo v rôznych iteráciách.

Takto teda odvodzujeme softvérové ​​požiadavky od obchodných požiadaviek.

Rozdiel medzi obchodnými požiadavkami a softvérovými požiadavkami

Vyššie sme videli, ako odvodiť softvérové ​​požiadavky od obchodných požiadaviek na vysokej úrovni. Softvérové ​​požiadavky umožňujú programátorovi a skúšobnému technikovi vyvinúť systém a efektívne ho testovať. Takže teraz vieme, že obchodné požiadavky sú požiadavky zákazníka na vysokej úrovni v prirodzenom jazyku, zatiaľ čo požiadavky na softvér sú podrobné požiadavky na nízkej úrovni, ktoré pomáhajú pri implementácii softvérového systému.

Pozrime sa na podrobný rozdiel medzi týmito dvoma typmi požiadaviek.

Záver

Analýza požiadaviek je chrbticou každého modelu SDLC.

Problém zmeškaný počas analýzy požiadaviek a zachytený pri testovaní jednotky by mohol pre organizáciu stáť desiatky tisíc dolárov a tieto náklady by mohli viesť k miliónom dolárov, ak pochádza z trhu ako spätné volanie (v roku 2017, výrobca airbagov účtovaný v USA, spoločnosť Takata a pokuta 1 miliarda dolárov za vybuchujúce airbagy).

Organizácia by namiesto sústredenia na vývoj a kvalitu softvéru skončila s vykonávaním úloh kontroly poškodenia, ako je analýza hlavných príčin, príprava 5 dokumentov, analýza stromov porúch, 8D dokument atď.

V najhorších prípadoch by bola organizácia zatiahnutá do právnych sporov podaných zákazníkom, ak je ovplyvnená funkcia súvisiaca s bezpečnosťou / bezpečnosťou, ako napríklad bezpečnostný prístup, airbag, ABS (protiblokovací brzdový systém) atď.

Odporúčané čítanie

• Fázy, metodiky, proces a modely SDLC (životný cyklus vývoja softvéru)
• Vlastnosti funkčných požiadaviek a nefunkčných požiadaviek
• Ako otestovať špecifikáciu softvérových požiadaviek (SRS)?
• 5 smrteľných chýb v riadení požiadaviek a ako ich prekonať
• Ako otestovať aplikáciu bez požiadaviek?
• Opatrenia pre SSDLC (zabezpečený životný cyklus vývoja softvéru)
• Špirálový model - Čo je to SDLC špirálový model?
• Čo je model SDLC Waterfall?