Kaj je analiza zahtev in zbiranje v SDLC?

what is requirement analysis

Ta vadnica pojasnjuje, kaj je analiza zahtev, koraki, primeri in cilji zbiranja zahtev v SDLC:

Razvoj programske opreme je izjemna naloga, ki ustvarja delujoč programski izdelek.

Programski izdelek je izdelan na zahtevo stranke. Ta programski izdelek je večinoma v skladu s pričakovanji končnega kupca / uporabnika, včasih pa ta izdelek ni v celoti skladen s pričakovanji kupca / končnega uporabnika.

Kaj se boste naučili:

• Kaj je analiza zahtev?
  • Faze / koraki analize zahtev
    • # 1) Zbiranje zahtev
    • # 2) Analiza zbranih zahtev
    • # 3) Dokumentiranje analiziranih zahtev
  • Pretvorba poslovnih zahtev v zahteve za programsko opremo
  • Razumevanje primerov nefunkcionalnih zahtev
  • Razlika med poslovnimi zahtevami in zahtevami glede programske opreme
• Zaključek
  • Priporočeno branje

Kaj je analiza zahtev?

S pomočjo primera naj razumemo analizo zahtev.

Pričakovanja kupca / končnega uporabnika:

Stranka / končni uporabnik prejme:

Kot lahko iz zgornjih slik analizirate, da se končni izdelek ne ujema s pričakovanji kupcev. To je lahko posledica nešteto razlogov, tj. nepravilno izvajanje zahtev kupcev, napačna zasnova, napačno razumevanje zahtev kupcev s strani programerjev in ekipe za kakovost itd.

Kot lahko vidite, pa naj bo to razlog za napačno dostavo izdelka, glavni razlog je zahteva. Če bi torej opravili pravilno razumevanje, zajem, izvajanje in testiranje zahtev, bi to pomagalo ublažiti napačno in nepopolno dostavo izdelka kupcu / končnemu uporabniku.

Za dobro dostavo izdelkov so predpogoj pravilno zbiranje zahtev, učinkovito preverjanje zbranih zahtev in na koncu jasna dokumentacija o zahtevah. Celoten postopek se imenuje tudi Analiza zahtev v življenjskem ciklu razvoja programske opreme (SDLC)

Faze / koraki analize zahtev

Kot lahko vidite, je analiza zahtev prva dejavnost v SDLC, ki ji sledijo funkcionalne specifikacije itd. Analiza zahtev je ključni korak v SDLC, saj odmeva s preskusi sprejemljivosti, ki so ključnega pomena za sprejem izdelkov s strani kupcev.

V tej vadnici bomo razložili, kako se analiza zahtev izvaja v SDLC. V analizi potreb bomo videli tudi različne vključene korake, rezultate, izzive in korektivne ukrepe.

Analiza zahtev se začne z:

1. Zbiranje zahtev kar se imenuje tudi izsiljevanje.
2. Temu sledi analiziranje zbrane zahteve za razumevanje pravilnosti in izvedljivosti pretvorbe teh zahtev v možen izdelek.
3. In končno, dokumentiranje zbrane zahteve.

# 1) Zbiranje zahtev

Da se prepričate, da so vsi zgoraj navedeni koraki ustrezno izvedeni, mora stranka pridobiti jasne, jedrnate in pravilne zahteve. Stranka bi morala imeti možnost, da pravilno opredeli svoje zahteve, poslovni analitik pa bi jo moral imeti možnost, da jo zbere na enak način, kot jo stranka namerava posredovati.

Velikokrat ni mogoče, da zbiranje zahtev učinkovito opravijo poslovni analitiki od stranke. To je lahko posledica odvisnosti od mnogih ljudi, povezanih s pričakovanim končnim izdelkom, orodji, okoljem itd. Zato je vedno dobro vključiti vse zainteresirane strani, ki bi lahko vplivale ali bi lahko vplivale na končni izdelek.

Možna skupina zainteresiranih strani bi lahko bili inženirji za kakovost programske opreme (QC in QA), kateri koli tretji ponudnik, ki bi lahko zagotovil podporo pri projektu, končni uporabnik, ki mu je izdelek namenjen, programerji programske opreme, druga skupina v organizaciji, ki bi lahko zagotovila modul ali programska platforma, knjižnice programske opreme itd. za razvoj izdelkov.

Primer: V organizaciji razvijejo izdelek ADAS (sistem kamer za prostorski pogled za prestižnega proizvajalca originalne opreme), ki ga potrebuje Sklad Autosar in Bootloader binarne datoteke, ki jih prejme drug dobavitelj.

Vključevanje različnih zainteresiranih strani v fazo zbiranja zahtev pomaga pri razumevanju različnih odvisnosti drug od drugega, zato bi lahko preprečili morebitne konflikte v prihodnosti.

Včasih je dobro ustvariti prototip modela načrtovanega izdelka in ga pokazati kupcu. To je odličen način, da kupcem sporočite, kakšen izdelek pričakujejo in kako bo videti pozneje. To kupcu pomaga pri vizualizaciji izdelka, ki ga pričakuje, in mu pomaga pri jasnih zahtevah.

Ta izdelava prototipa je odvisna od dveh vrst izdelkov:

1. V organizaciji obstaja podoben izdelek, ki so ga stranke nameravale.
2. Razviti nov izdelek.

(jaz) V prvem primeru je kupcu lažje pokazati, kako bi izgledal končni izdelek in kako bi ga razvili. V avtomobilskem ADAS je možno kupcem pokazati še en izdelek, ki je že na trgu in je bil razvit znotraj organizacije.

Na primer, Sistem kamer za prostorski pogled, razvit za proizvajalca originalne opreme (GM, Volkswagen, BMW itd.) In ga je mogoče predstaviti drugemu proizvajalcu originalne opreme.

Prosimo, upoštevajte , ni pametno, da izdelek / proto izdelek pokažete kupcu, ki je v fazi razvoja, saj lahko krši pogodbo o nerazkrivanju podatkov, podpisano z drugo stranko, za katero se ta izdelek razvija. Prav tako lahko pride do nepotrebnih pravnih spopadov.

Še en primer lahko informacijski sistem, ki ga razvija organizacija in je že na trgu. Poslovni analitiki in druge zainteresirane strani v organizaciji lahko za stranko načrtujejo predstavitev delavnice, ki prikazuje informacijsko-zabavne sisteme z oprijemljivim HMI, priključki za priključke naprav, peskovnik itd.

To bo kupcu pomagalo razumeti, kako bi izgledal končni izdelek, in veliko jasneje zagotovil svoje zahteve.

(ii) Drugi primer je mogoče doseči z ustvarjanjem osnovnega delovnega modela s preprostim kodiranjem in sestavljanjem (tu so večinoma funkcije kodirane v programih) ali z ustvarjanjem diagrama poteka ali diagrama, ki bi kupca lahko prepričal, kako bo izgledal izdelek.

V vsakem primeru bi si dal duška za postopek zbiranja zahtev, saj stranka zdaj ve, kaj hoče.

Poslovni analitik lahko zdaj organizira formalne sestanke za pridobivanje zahtev, kamor bi lahko povabili vse zainteresirane strani, in tako lahko zapiše različne zahteve, ki jih zagotavlja stranka (v nekaterih primerih, če je deležnikov več, bi lahko imenovali ločenega pisarja, ki bi zapisal stranke zahteve ali zgodbe uporabnikov, da se lahko poslovni analitik osredotoči na moderiranje sestanka).

Zbrane zahteve so lahko v obliki uporabniške zgodbe (v agilnem razvoju), primeri uporabe, dokumenti v naravnem jeziku, diagrami, diagrami poteka itd. Uporabniške zgodbe postajajo priljubljene v sodobnem življenjskem ciklu razvoja programske opreme. Zgodbe uporabnikov so v bistvu sklop vložkov kupcev v njihovem naravnem jeziku.

Primer zbiranja zahtev: V sistemu kamer za prostorski pogled ADAS bi lahko bila ena možna zgodba uporabnika: 'Kot uporabnik bi moral imeti možnost videti, kaj je tam v vzvratnem pogledu avtomobila'.

Lahko bi jih bilo veliko 'Zakaj,' vprašanja o vsaki uporabniški zgodbi, ki bodo kupcu pomagala pri zagotavljanju podrobnejših informacij o zahtevi.

Če stranka v zgornji zgodbi o uporabniku reče »Kot uporabnik, bi moral videti, kaj je tam na zadnji strani avtomobila«, in postavil vprašanje »Zakaj 'Bi lahko dal' Kot uporabnik bi moral videti, kaj je tam v vzvratnem pogledu avtomobila, tako da lahko varno parkiram avto '.

Zastavljanje vprašanja 'Zakaj' pomaga tudi pri ustvarjanju objektivnih in atomskih zahtev na podlagi ogromnih izjav v naravnem jeziku, ki jih da stranka. To je mogoče zlahka implementirati pozneje v kodi.

preizkusite moje spletno mesto v različnih brskalnikih

Drug način zbiranja zahteve je v obliki primeri uporabe . Primer uporabe je pristop po korakih za doseganje določenega rezultata. To ne pove, kako bo programska oprema delovala na vnosu uporabnika, temveč pove, kaj se pričakuje od vnosov uporabnikov.

Primer:

# 2) Analiza zbranih zahtev

Zbiranje zahtev po objavi, analiza zahtev se začne. Na tej stopnji različne zainteresirane strani zasedajo in sestankujejo. Analizirajo zbrane zahteve in iščejo izvedljivost njihovega izvajanja. Pogovarjata se med seboj in morebitne dvoumnosti se rešijo.

Ta korak je pomemben v procesu analize zahtev zaradi naslednjih glavnih razlogov:

(jaz) Naročnik lahko navede nekatere zahteve, ki jih je zaradi različnih odvisnosti nemogoče uvesti.

Primer: Strankelahko zahteva sistem za prostorski ogled kamere s funkcijo vzvratne kamere, ki vam bo pomagala parkirišče avto. Kupec lahko tudi zaprosi za Prikolica vlečna funkcija, ki za delo uporablja tudi zadnjo kamero.

Če kupec navede zahtevo, da vzvratna kamera za parkirišče pomoč bi morala delovati ves čas brez izjeme, nato pa Prikolica funkcija nikoli ne bi delovala in obratno.

(ii) Poslovni analitik bi morda razumel zahtevo iz stranko drugače kot kako programer bi razlagal.

Ker programerji razmišljajo kot tehnični strokovnjaki, je vedno mogoče, da se zahteve kupcev napačno pretvorijo v funkcionalne specifikacije, ki bodo kasneje napačno spremenjene v arhitekturno in oblikovalsko dokumentacijo in nato v kodo. Vpliv je eksponencialen, zato ga je treba preveriti.

Možni popravljalni ukrep bi lahko bil, če bi sledili agilni metodi razvoja programske opreme, upoštevali primere uporabe, ki jih zagotovi stranka itd.

# 3) Dokumentiranje analiziranih zahtev

Ko je analiza zahtev opravljena, se začne dokumentacija o zahtevah. Iz analize zahtev izhajajo različne vrste zahtev.

Nekateri od teh so:

(jaz) Specifikacija zahtev kupca.

(ii) Zahteva za arhitekturo programske opreme.

Primer:

(iii) Zahteva za oblikovanje programske opreme.

Primer:

(iv) Specifikacija funkcionalnih zahtev (neposredno izpeljana iz specifikacij kupca.)

Primer: 'Ko uporabnik tapne ikono Bluetooth v Infotainment HMI, se prikaže zaslon Bluetooth'

(v) Nefunkcionalna specifikacija zahteve (tj. Zmogljivost, napetost, obremenitev itd.).

Primer: 'Moral bi biti možno seznaniti 15 naprav Bluetooth z informacijsko-razvedrilnim sistemom brez poslabšanja zmogljivosti sistema.'

(mi) Zahteve uporabniškega vmesnika.

Primer: 'Na zaslonu sprejemnika FM mora biti na voljo gumb za izbiro različnih postaj.'

Zgornje zahteve so zabeležene in dokumentirane v orodjih za upravljanje zahtev, kot so IBM DOORS, HP QC. Včasih imajo organizacije po meri izdelana orodja za upravljanje zahtev, s katerimi zmanjšajo stroške.

Poglejmo si zdaj postopek pretvorbe Poslovne zahteve do Zahteve za programsko opremo (funkcionalno in nefunkcionalno).

Pretvorba poslovnih zahtev v zahteve za programsko opremo

Kot smo že omenili, so poslovne zahteve zahteve na visoki ravni, ki govorijo o tem, kaj končni uporabnik želi od določenega dejanja na programskem sistemu. Razvoj celotnega sistema programske opreme, ki temelji na teh zahtevah, ni mogoč, saj podroben opis načina izvajanja programskega sistema ali komponente ni omenjen.

Tako je treba poslovne zahteve razčleniti na podrobnejše zahteve za programsko opremo, ki bodo podrobneje razdeljene na funkcionalne in nefunkcionalne zahteve.

najboljše strani za prenos mp3 za android

Če želite to narediti, lahko sledite naslednjim korakom:

1. Razčlenite poslovne zahteve na visoki ravni na podrobne uporabniške zgodbe.
2. Izdelava diagrama poteka za opredelitev toka dejavnosti.
3. Zagotavljanje pogoja, ki upravičuje izvedene uporabniške zgodbe.
4. Okvirni diagrami za razlago poteka dela predmetov.
5. Določanje nefunkcionalnih zahtev izven poslovnih zahtev.

Začnimo s primerom avtomobilskega informacijsko-razvedrilnega sistema.

Poslovna zahteva pravi: 'Končni uporabnik mora imeti možnost dostopa do navigacijskega polja iz HMI Infotainment sistema in mora imeti možnost, da nastavi ciljni naslov.'

Torej lahko zgoraj navedene korake izvedemo kot:

# 1) Razčlenite poslovne zahteve na visoki ravni na podrobne uporabniške zgodbe.

Pretvorimo to poslovno zahtevo v zgodbo uporabnika na visoki ravni, “ Kot uporabnik bi moral imeti dostop do polja Gradnik za navigacijo, da lahko vnesem ciljni naslov '. Ta zgodba o uporabniku pripoveduje, kaj potrebuje končni uporabnik. Poskusili bomo določiti, kako uresničiti to zahtevo.

Začnimo z vprašanji o tej uporabniški zgodbi, tj.

1. Kdo so uporabniki?
2. Kako lahko dostopam do navigacije, na vozilu (s kartice SD) ali s pametnega telefona?
3. Kakšne ciljne vnose lahko vnesem?
4. Ali naj mi je dovoljen vstop na cilj, tudi če je avto na parkirišču?

To so podrobnejše zgodbe o uporabnikih, ki izhajajo iz zgodb o uporabnikih na visoki ravni, in bi nam pomagale do boljšega vpogleda v naše poslovne zahteve.

Na tej točki lahko vzamemo eno od uporabniških podzgodb in začnemo zasliševati. Vzemimo (št. 3):

1. Ali lahko vnesem ciljne vnose, kot so Geo koordinate, poštni naslov, prek prepoznavanja govora itd.?
2. Ali potrebujem GPS za vnos geo-koordinat?
3. Ali lahko z iskanjem po zgodovini naslovov vnesem trenutni ciljni naslov?

# 2) Izdelava diagrama poteka za opredelitev toka dejavnosti.

Zdaj lahko vidimo, da je poslovna zahteva razčlenjena na zelo podrobne primere uporabe, ki so na diagramu poteka označeni kot spodaj:

# 3) Zagotavljanje pogojev, ki upravičujejo izpeljane uporabniške zgodbe.

Vidimo lahko, da se podrobnejše informacije pojavljajo zaradi razgradnje zahtev na visoki ravni v podrobne zgodbe o uporabnikih na nizki ravni in v diagrame poteka. Iz tega diagrama poteka lahko dobimo tehnične podrobnosti, potrebne za izvedbo, tj.

• Čas nalaganja zaslona za prikaz vnosa cilja mora biti 1 s.
• Tipkovnica za vnos cilja mora imeti alfanumerične znake in posebne simbole.
• Preklopni gumb za omogočanje / onemogočanje GPS mora biti prisoten na zaslonu za vnos cilja navigacije.

Zgornje informacije zadovoljujejo uporabniške zgodbe in omogočajo diskretno preizkušanje zahteve ter merljivo izogibanje kakršni koli zmedi z zahtevo, medtem ko se izvaja kot značilnosti.

# 4) Okvirni diagrami za razlago poteka dela predmetov.

Iz zgornjega primera uporabe bomo izpeljali žični diagram, ki bo uporabniški vmesnik naredil jasnejši.

# 5) Določitev nefunkcionalnih zahtev iz poslovnih zahtev.

Nujno je, da podrobne zahteve glede programske opreme izhajajo iz visokih poslovnih zahtev, vendar se pogosto določijo le funkcionalne zahteve, ki pravijo, kako se bo sistem obnašal do določenega uporabnikovega vnosa / dejanja.

Vendar funkcionalne zahteve ne pojasnjujejo delovanja sistema in drugih kvalitativnih parametrov, kot so razpoložljivost, zanesljivost itd.

Primeri:

a) Vzeli bomo primer zgornjega avtomobilskega informacijsko-razvedrilnega sistema.

Če voznik (končni uporabnik) avtomobila predvaja glasbo z USB-ja in v teku so navigacijske smernice, prejme tudi dohodni klic prek Bluetootha v načinu za prostoročno telefoniranje, nato pa se obremenitev procesorja in RAM-a poveča na največjo raven, ko se izvaja več procesov teče v ozadju.

V tem trenutku, če voznik tapne vmesnik zaslona na dotik informacijsko-razvedrilnega sistema, da zavrne dohodni klic prek samodejnega odgovora na SMS (enako kot to počnemo pri svojih mobilnih telefonih), bi moral sistem to nalogo izvesti in ne bi smel visjeti ali sesuti. To je zmogljivost sistema, ko je obremenitev velika in preizkušamo razpoložljivost in zanesljivost.

b) Drug primer je scenarij stresa.

Vzemimo za primer: informacijsko-zabavni sistem sprejema sporočila SMS (morda 20 SMS v 10 sekundah) prek povezanega telefona Bluetooth. Infotainment sistem bi moral biti sposoben upravljati z vsemi dohodnimi SMS-ji in v nobenem trenutku ne bi smel zamuditi nobenega obvestila o dohodnem SMS-u v Infotainment HMI.

Zgornji primeri so primeri nefunkcionalnih zahtev, ki jih ni bilo mogoče preizkusiti samo s funkcionalnimi zahtevami. Čeprav včasih kupci pogrešajo zagotavljanje teh nefunkcionalnih zahtev. Odgovornost organizacije je, da jim te podatke posreduje, ko je izdelek dostavljen kupcu.

Razumevanje primerov nefunkcionalnih zahtev

Spodnja tabela pojasnjuje nefunkcionalne zahteve:

Nefunkcionalne zahteve v nasprotju s funkcionalnimi zahtevajo celoten življenjski cikel projekta, da se začnejo izvajati, saj se postopoma izvajajo v ustreznih agilnih sprintih ali v različnih ponovitvah.

Torej, tako iz poslovnih zahtev izhajamo iz zahtev za programsko opremo.

Razlika med poslovnimi zahtevami in zahtevami glede programske opreme

Zgoraj smo videli, kako zahteve za programsko opremo izpeljati iz visokih poslovnih zahtev. Programske zahteve omogočajo programerju in testnemu inženirju, da razvije sistem in ga učinkovito preizkusi. Zdaj vemo, da so poslovne zahteve zahteve kupcev v naravnem jeziku, zahteve programske opreme pa so podrobne zahteve na nizki ravni, ki pomagajo pri implementaciji programskega sistema.

Poglejmo podrobno razliko med obema vrstama zahtev.

Zaključek

Analiza zahtev je hrbtenica katerega koli modela SDLC.

Težava, ki je bila zamujena med analizo zahtev in je bila ujeta pri preizkušanju enote, bi lahko stala na desetine tisoč dolarjev za organizacijo in bi lahko povzročila milijone dolarjev, če bi prišla s trga kot povratni klic (leta 2017 je ameriški proizvajalec zračnih blazin, Takata a globa v višini 1 milijarde USD zaradi eksplozije zračnih blazin).

Organizacija bi na koncu opravljala naloge nadzora škode, kot je analiza vzrokov vzrokov, priprava 5, zakaj dokumenti, analiza dreves napak, 8D dokument itd., Namesto da bi se osredotočila na razvoj in kakovost programske opreme.

V najslabših primerih se organizacija vleče v pravne tožbe, ki jih vloži stranka, če je prizadeta lastnost povezana z varnostjo / varnostjo, kot so varnostni dostop, zračna blazina, ABS (protiblokirni zavorni sistem) itd.

Priporočeno branje

• Faze, metodologije, procesi in modeli SDLC (življenjski cikel razvoja programske opreme)
• Značilnosti funkcionalnih zahtev in nefunkcionalnih zahtev
• Kako preizkusiti specifikacijo zahtev za programsko opremo (SRS)?
• 5 smrtonosnih napak pri upravljanju z zahtevami in kako jih premagati
• Kako preizkusiti prijavo brez zahtev?
• Ukrepi za SSDLC (življenjski cikel varnega razvoja programske opreme)
• Spiralni model - kaj je SDLC spiralni model?
• Kaj je model slapa SDLC?