Mikä on Vaatimusanalyysi ja kerääminen SDLC: ssä?

tämä opetusohjelma selittää, mikä on VAATIMUSANALYYSI, Vaatimusanalyysin vaiheet, esimerkit ja vaatimusten keräämisen tavoitteet SDLC: ssä:

ohjelmistokehitys on valtava tehtävä, joka luo toimivan ohjelmistotuotteen.

ohjelmistotuote rakennetaan asiakkaan vaatimuksen mukaan. Enimmäkseen, tämä ohjelmistotuote vastaa sitä, mitä loppuasiakas / käyttäjä oli odottanut, vaikka joskus tämä tuote ei täysin vastaa sitä, mitä asiakas / loppukäyttäjä oli odottanut.

mikä on Vaatimusanalyysi?

Ymmärtäkäämme Vaatimusanalyysi esimerkin avulla.

asiakkaan / loppukäyttäjän odotus:

asiakas / loppukäyttäjä saa:

, koska voit analysoida yllä olevista kuvista, että lopputuotteessa on epäsuhta asiakkaan odotukseen. Tämä voi johtua lukemattomista syistä. asiakkaan vaatimusten virheellinen täytäntöönpano, virheellinen suunnittelu, ohjelmoijien ja laatutiimin väärä käsitys asiakkaan vaatimuksista jne.

kuitenkin, kuten näette, oli syy mikä tahansa väärä tuote Toimitus, ensisijainen syy menee vaatimus. Näin ollen, jos oikea vaatimusten ymmärtäminen, talteenotto, täytäntöönpano ja testaus olisi tehty, se olisi auttanut lieventämään virheellistä ja puutteellista tuotteen toimittamista asiakkaalle/loppukäyttäjälle.

hyvä tuotetoimitus edellyttää asianmukaista vaatimusten keräämistä, kerättyjen vaatimusten tehokasta tutkimista ja lopuksi selkeää vaatimusdokumentointia. Tätä koko prosessia kutsutaan myös Vaatimusanalyysiksi ohjelmistokehityksen elinkaaressa (SDLC)

Vaatimusanalyysi vaiheet / vaiheet

kuten näette, Vaatimusanalyysi on SDLC: n ensimmäinen toiminto, jota seuraa funktionaalinen spesifikaatio ja niin edelleen. Vaatimusanalyysi on tärkeä askel SDLC: ssä, koska se resonoi hyväksymistestauksen kanssa, joka on kriittinen asiakkaiden tuotteiden hyväksymiselle.

tässä opetusohjelmassa kerromme, miten vaatimusanalyysi tehdään SDLC: ssä. Näemme myös eri vaiheet, tulokset, haasteet ja korjaavat toimenpiteet vaatimusanalyysissä.

Vaatimusanalyysi alkaa:

1. vaatimus kerääminen, jota kutsutaan myös elicitation.
2. tämän jälkeen analysoidaan kerätyt vaatimukset, jotta voidaan ymmärtää näiden vaatimusten muuntamisen oikeellisuus ja toteutettavuus mahdollisena tuotteena.
3. ja lopuksi dokumentoidaan kerätyt vaatimukset.

#1) Vaatimuskeräys

jotta kaikki edellä mainitut vaiheet toteutuvat asianmukaisesti, asiakkaalta on kerättävä selkeät, tiiviit ja oikeat vaatimukset. Asiakkaan pitäisi pystyä määrittelemään vaatimuksensa oikein ja liiketoiminta-analyytikon pitäisi pystyä keräämään se samalla tavalla kuin asiakas haluaa sen välittää.

monesti ei ole mahdollista, että yritysanalyytikot suorittaisivat vaatimuksien keräämisen tehokkaasti asiakkaalta. Tämä saattaa johtua riippuvuudesta monista ihmisistä, jotka liittyvät odotettuun lopputuotteeseen, työkaluihin, ympäristöön jne. Siksi on aina hyvä ottaa mukaan kaikki sidosryhmät, jotka voivat vaikuttaa tai joihin lopputuote voi vaikuttaa.

mahdollinen sidosryhmä voisi olla ohjelmistojen laatuinsinöörit (sekä QC että QA), mikä tahansa kolmannen osapuolen myyjä, joka voisi tukea projektia, loppukäyttäjä, jolle tuote on tarkoitettu, ohjelmoijat, organisaation toinen tiimi, joka voisi tarjota moduulin tai ohjelmistoalustan, ohjelmistokirjastot jne. tuotekehitykseen.

esimerkki: organisaatiossa kehitetään ADAS-tuote (Surround-view-kamerajärjestelmä arvostetulle OEM: lle), joka tarvitsee Autosar-pinon ja Bootloader-binäärit, jotka saadaan toiselta toimittajalta.

eri sidosryhmien osallistuminen vaatimusten keruuvaiheeseen auttaa ymmärtämään erilaisia riippuvuuksia toisistaan ja mahdolliset tulevat konfliktit voitaisiin välttää.

joskus on hyvä idea luoda suunnitellusta tuotteesta prototyyppimalli ja näyttää se asiakkaalle. Tämä on erinomainen tapa välittää asiakkaille, mitä tuotetta he odottavat ja miltä se voi näyttää myöhemmin. Tämä auttaa asiakasta visualisoimaan tuotteen, että he odottavat ja auttaa heitä keksiä selkeitä vaatimuksia.

tämän prototyypin luominen riippuu kahdesta tuotetyypistä:

1. samanlainen tuote, että asiakkaat tarkoitettu, on olemassa organisaation sisällä.
2. uusi tuote kehitettävänä.

(I) ensimmäisessä tapauksessa on helpompi näyttää asiakkaalle, miltä lopputuote näyttäisi ja miten sitä kehitettäisiin. Automotive ADASISSA on mahdollista näyttää asiakkaille toinen tuote, joka on jo markkinoilla ja on kehitetty organisaation sisällä.

esimerkiksi OEM: lle (GM, Volkswagen, BMW jne.) kehitetty surround-view-kamerajärjestelmä.) ja voidaan esitellä toiselle OEM.

huomaa, että kehitteillä olevaa tuotetta/proto-tuotetta ei ole viisasta näyttää asiakkaalle, koska se saattaa rikkoa toisen asiakkaan kanssa allekirjoitettua salassapitosopimusta, jolle tuotetta kehitetään. Se voi johtaa myös tarpeettomaan oikeudelliseen nahisteluun.

toinen esimerkki voisi olla järjestön kehittämä infotainment-järjestelmä, joka on jo markkinoilla. Liiketoiminta-analyytikot ja muut organisaation sidosryhmät voivat suunnitella asiakkaalle työpajademon, jossa esitellään infotainment-järjestelmiä, joissa on konkreettinen HMI, laitteen liitinportit, hiekkalaatikko jne.

tämä auttaa asiakasta ymmärtämään, miltä lopputuote näyttäisi ja tarjoamaan tarpeensa paljon selkeämmin.

(ii) toinen tapaus voidaan saavuttaa luomalla perustoimintamalli tekemällä yksinkertainen koodaus ja kokoonpano (useimmiten ominaisuudet tässä ovat kovakoodattuja ohjelmissa), tai luomalla vuokaavio tai kaavio, joka voisi vakuuttaa asiakkaan siitä, miltä tuote näyttäisi.

joka tapauksessa se olisi hengähdystauko vaatimuksenkeruuprosessille, sillä asiakas tietää nyt, mitä haluaa.

yritysanalyytikko voi nyt järjestää muodollisia vaatimuksensaantitapaamisia, joihin kaikki sidosryhmät voidaan kutsua ja siten kirjata ylös asiakkaan asettamat vaatimukset (joissakin tapauksissa, jos sidosryhmiä on enemmän, voidaan nimetä erillinen kirjuri, joka kirjaa ylös asiakkaiden vaatimukset tai käyttäjätarinat, jotta yritysanalyytikko voisi keskittyä kokouksen moderointiin).

kerätyt vaatimukset voivat olla käyttäjien kertomuksia (ketterässä kehityksessä), käyttötapauksia, asiakkaan luonnollisen kielen asiakirjoja, kaavioita, vuokaavioita jne. Käyttäjätarinoista on tulossa suosittuja nykypäivän ohjelmistokehityksen elinkaaressa. Käyttäjätarinat ovat pohjimmiltaan joukko asiakkaan panoksia heidän luonnollisella kielellään.

Requirement Gathering esimerkki: ADAS surround-kamerajärjestelmässä yksi mahdollinen käyttäjätarina voisi olla: ”käyttäjänä minun pitäisi pystyä näkemään, mitä autoni taustapeilissä on”.

jokaisessa käyttäjätarinassa voi olla monia ”miksi” – kysymyksiä, jotka auttavat asiakasta antamaan tarkempia tietoja vaatimuksesta.

yllä olevassa käyttäjä tarina, Jos asiakas sanoo ”käyttäjänä, minun pitäisi pystyä näkemään, mitä siellä peruutusnäkymässä autoni”, kysymällä ”miksi” voisi antaa ”käyttäjänä, minun pitäisi pystyä näkemään, mitä siellä peruutusnäkymässä autoni, jotta voin pysäköidä autoni turvallisesti”.

kysymyksen ”miksi” esittäminen auttaa myös luomaan objektiivisia ja atomisia vaatimuksia asiakkaan antamien mahtavien luontokielisten lausuntojen pohjalta. Tämä voidaan helposti toteuttaa myöhemmin koodissa.

toinen tapa kerätä vaatimus on käyttötapausten muodossa. Käyttötapaus on askel askeleelta lähestymistapa tietyn tuloksen saavuttamiseksi. Tämä ei kerro, miten ohjelmisto toimii käyttäjän syötteen pikemminkin se kertoo, mitä odotetaan käyttäjän syötteitä.

esimerkki:

#2) kerättyjen vaatimusten analysointi

Post requirement gathering, vaatimuksen analysointi alkaa. Tässä vaiheessa eri sidosryhmät istuvat ja tekevät aivoriihen. He analysoivat kerätyt vaatimukset ja etsivät toteutettavuutta niiden toteuttamiseksi. He keskustelevat keskenään ja mahdolliset epäselvyydet selvitetään.

tämä vaihe on tärkeä tarveanalyysiprosessissa seuraavista keskeisistä syistä johtuen:

(I) asiakas saattaa esittää joitakin vaatimuksia, joita voi olla mahdotonta toteuttaa erilaisten riippuvuuksien vuoksi.

esimerkki: asiakkaat voivat pyytää ympäröimään kamerajärjestelmän peruutuskameraominaisuudella, joka auttaa auton pysäköinnissä. Asiakas voi myös pyytää Peräkiinnikeominaisuutta, joka käyttää myös takakameraa toimiakseen.

jos asiakas esittää vaatimuksen, että pysäköintiavustuksen peruutuskameran pitäisi toimia poikkeuksetta koko ajan, Perävaunun ominaisuus ei koskaan toimisi ja päinvastoin.

(ii) liiketoiminta-analyytikko on saattanut ymmärtää asiakkaan vaatimuksen eri tavalla kuin ohjelmoija olisi tulkinnut.

koska ohjelmoijat ajattelevat teknisinä asiantuntijoina, on aina mahdollista, että asiakkaan vaatimukset muunnetaan virheellisesti toiminnallisiksi eritelmiksi, jotka myöhemmin muutetaan virheellisesti arkkitehtuuri-ja suunnitteludokumenteiksi ja myöhemmin koodiksi. Vaikutus on eksponentiaalinen, joten se on tarkistettava.

mahdollinen korjaava toimenpide voisi olla ketterä ohjelmistokehitysmenetelmä, asiakkaan tarjoamien käyttötapausten seuraaminen jne.

#3) dokumentointi analysoidut vaatimukset

kun vaatimusten analysointi on tehty vaatimusdokumentaatio alkaa. Erilaisia vaatimuksia tulee ulos analyysin vaatimuksia.

jotkut näistä ovat:

(i) asiakkaan vaatimusmäärittely.

(ii) tietojärjestelmäarkkitehtuurin vaatimus.

esimerkki:

(iii) ohjelmiston suunnittelun vaatimus.

esimerkki:

(iv) toiminnallinen vaatimus erittely (suoraan johdettu asiakkaan eritelmät.)

esimerkki: ”Kun käyttäjä napauttaa Bluetooth-kuvaketta Infotainment HMI: ssä, Bluetooth-näytön pitäisi näkyä”

(v) ei-toiminnalliset Vaatimusmääritykset (viz. suorituskyky, stressi, kuormitus jne.).

esimerkki: ”pitäisi olla mahdollista yhdistää 15 Bluetooth-laitetta infotainment-järjestelmään järjestelmän suorituskyvyn heikkenemättä”.

(vi) Käyttöliittymävaatimukset.

esimerkki: ”Virittimen FM-näytöllä tulisi olla painike, jolla voi valita eri asemat”

edellä mainitut vaatimukset on tallennettu ja dokumentoitu vaatimuksenhallintatyökaluissa, kuten IBM DOORS, HP QC. Joskus organisaatioilla on Mittatilaustyönä tehdyt tarvehallintatyökalut kustannusten vähentämiseksi.

tarkastelkaamme nyt prosessia, jossa liiketoiminnan vaatimukset muunnetaan Ohjelmistovaatimuksiksi (toiminnalliset ja ei-toiminnalliset).

liiketoiminnan vaatimusten muuntaminen Ohjelmistovaatimuksiksi

liiketoiminnan vaatimukset, kuten edellä on käsitelty, ovat korkean tason vaatimuksia, joissa puhutaan siitä, mitä loppukäyttäjä haluaa määritellyltä toiminnalta ohjelmistojärjestelmässä. Koko ohjelmistojärjestelmän kehittäminen näiden vaatimusten pohjalta ei ole mahdollista, koska yksityiskohtaista kuvausta siitä, miten ohjelmistojärjestelmä tai osa toteutetaan, ei mainita.

näin ollen liiketoiminnan vaatimukset on jaoteltava yksityiskohtaisempiin ohjelmistovaatimuksiin, jotka tarkentuvat toiminnallisiin ja ei-toiminnallisiin vaatimuksiin.

tätä varten voitiin noudattaa seuraavia vaiheita:

1. Break down korkean tason liiketoiminnan vaatimukset yksityiskohtaisia käyttäjien tarinoita.
2. luodaan vuokaavio toimintojen virtauksen määrittelemiseksi.
3. antaa ehdon, joka oikeuttaa johdetut käyttäjätarinat.
4. Wireframe-diagrammit selittämään objektien työnkulkua.
5. ei-toiminnallisten vaatimusten määritteleminen liiketoiminnan vaatimusten ulkopuolelle.

aloitetaan ottamalla esimerkki autojen Infotainment-järjestelmästä.

business requirement sanoo, ”loppukäyttäjän pitäisi pystyä käyttämään navigointilaitteen ruutuun infotainment system HMI ja pitäisi pystyä asettamaan kohdeosoite”.

joten edellä mainitut vaiheet voidaan toteuttaa:

#1) Break down korkean tason liiketoiminnan vaatimukset yksityiskohtaisia käyttäjien tarinoita.

muuttakaamme tämä liiketoimintavaatimus korkean tason käyttäjätarinaksi, ”käyttäjänä minun pitäisi pystyä käyttämään navigaatio widget-laatikkoa niin, että voin syöttää kohdeosoitteen”. Tämä käyttäjätarina kertoo, mitä loppukäyttäjä tarvitsee. Pyrimme määrittelemään, miten tämä vaatimus toteutetaan.

aloitetaan kysymällä mahdollisia kysymyksiä tälle käyttäjän tarinavisiirille.

1. ketkä ovat käyttäjiä?
2. Miten pääsen navigointiin, junaan (SD-kortilta) tai älypuhelimeen?
3. millaisia kohdemerkintöjä voin syöttää?
4. Pitäisikö minun päästä määränpäähän, vaikka auto olisi pysäköitynä?

nämä ovat yksityiskohtaisempia korkean tason käyttäjätarinoita, jotka ovat peräisin korkean tason käyttäjätarinoista ja auttaisivat meitä saamaan enemmän tietoa liiketoimintamme vaatimuksista.

tässä vaiheessa voimme tarttua yhteen käyttäjän alajutuista ja aloittaa kuulustelut. Otetaanpa (ei. 3):

1. Voinko syöttää kohdemerkintöjä, kuten Geo-koordinaatit, Postiosoite, puheentunnistuksen kautta jne.?
2. Tarvitsenko GPS: ää Geokoordinaattien syöttämiseen?
3. Voinko syöttää nykyisen kohdeosoitteen etsimällä osoitehistoriasta?

#2) Johtaminen vuokaavio määritellä virtauksen toimintaa.

nyt voimme nähdä, että liiketoimintavaatimus on jaettu hyvin yksityiskohtaisiin käyttötapauksiin, jotka voidaan merkitä vuokaavioon alla olevalla tavalla:

#3) tarjoamalla ehtoja, jotka oikeuttavat johdetut käyttäjätarinat.

voimme nähdä, että tarkempaa tietoa on syntymässä, koska korkean tason yritystarve on hajotettu yksityiskohtaisiksi matalan tason käyttäjätarinoiksi ja vuokaavioksi. Tästä vuokaavio, voimme saada teknisiä yksityiskohtia tarvitaan täytäntöönpanoa viz.

• näytön latausaika kohdesyötteen näyttämiseen tulee olla 1 sek.
• kohdesyöttönäppäimistössä tulee olla aakkosnumeeriset merkit ja erikoissymbolit.
• GPS Ota käyttöön/Poista käytöstä-painikkeen pitäisi olla Navigointikohteiden sisääntuloruudussa.

yllä olevat tiedot täyttävät käyttäjien tarinat ja mahdollistavat vaatimuksen testaamisen hienovaraisesti ja mitattavasti välttäen sekaannuksen vaatimuksen kanssa samalla, kun se toteutetaan ominaisuuksina.

#4) Wireframe-diagrammit selittämään objektien työnkulkua.

yllä olevasta käyttötapauksesta johdetaan wireframe-kaavio, joka selkeyttää käyttöliittymää.

#5) määrittelemällä ei-toiminnalliset vaatimukset pois liiketoiminnan vaatimuksista.

on välttämätöntä, että yksityiskohtaiset ohjelmistovaatimukset johdetaan korkean tason liiketoimintavaatimuksista, mutta usein tunnistetaan vain toiminnallisia vaatimuksia, jotka kertovat, miten järjestelmä käyttäytyy tietylle käyttäjän syötölle/toiminnalle.

toiminnalliset vaatimukset eivät kuitenkaan selkeytä järjestelmien suorituskykyä ja muita laadullisia muuttujia, kuten käytettävyyttä, luotettavuutta jne.

Examples:

a) otamme esimerkin edellä mainitusta autojen infotainment-järjestelmästä.

jos auton kuljettaja(loppukäyttäjä) soittaa musiikkia USB: ltä ja navigoinnin ohjaus on käynnissä, saa myös saapuvan puhelun Bluetoothin kautta handsfree-tilassa, sitten lataus suorittimeen ja RAM-muistin kulutus kasvaa maksimitasolle useiden prosessien ollessa käynnissä taustalla.

tässä vaiheessa, jos kuljettaja napauttaa infotainment-järjestelmän kosketusnäyttöliittymää torjuakseen saapuvan puhelun automaattisella tekstiviestillä (samalla tavalla kuin matkapuhelimissamme), järjestelmän pitäisi pystyä suorittamaan tämä tehtävä eikä se saisi roikkua tai kaatua. Tämä on järjestelmän suorituskyky, kun kuormitus on suuri ja testaamme käytettävyyttä ja luotettavuutta.

b) toinen tapaus on Stressiskenaario.

otetaan esimerkki, infotainment-järjestelmä vastaanottaa back to back SMSs: ää (ehkä 20 tekstiviestiä 10 sekunnin kuluessa) yhdistetyn Bluetooth-puhelimen kautta. Infotainment-järjestelmän pitäisi pystyä käsittelemään kaikki saapuvat tekstiviestit, eikä se saisi missään vaiheessa jättää väliin mitään saapuvaa TEKSTIVIESTIILMOITUSTA Infotainment HMI: ssä.

edellä mainitut esimerkit ovat tapauksia, joissa ei ole toiminnallisia vaatimuksia, joita ei ole voitu testata pelkästään toiminnallisten vaatimusten avulla. Vaikka joskus asiakkaat kaipaavat näitä ei-toiminnallisia vaatimuksia. On organisaation vastuulla antaa heille nämä tiedot, Kun tuote toimitetaan asiakkaalle.

Ei-toiminnallisten vaatimusten ymmärtäminen tapaukset

alla olevassa taulukossa selitetään ei-toiminnalliset vaatimukset:

ei-toiminnalliset vaatimukset, toisin kuin toiminnalliset vaatimukset, ota projektin koko elinkaari toteutukseen, koska ne toteutetaan asteittain vastaavissa ketterissä sprinteissä tai erilaisissa iteraatioissa.

näin johdamme ohjelmistovaatimukset liiketoiminnan vaatimuksista.

ero liiketoimintavaatimusten ja Ohjelmistovaatimusten välillä

olemme nähneet edellä, miten ohjelmistovaatimukset voidaan johtaa liiketoiminnan korkean tason vaatimuksista. Ohjelmistovaatimusten avulla ohjelmoija ja testausinsinööri voivat kehittää järjestelmää ja testata sitä tehokkaasti. Niin, tiedämme nyt, että liiketoiminnan vaatimukset ovat korkean tason asiakkaan luonnollisen kielen vaatimukset, kun taas ohjelmistovaatimukset ovat yksityiskohtaisia matalan tason vaatimuksia, jotka auttavat ohjelmistojärjestelmän toteuttamisessa.

Tarkastellaanpa näiden kahden vaatimustyypin yksityiskohtaista eroa.

johtopäätös

Vaatimusanalyysi on minkä tahansa SDLC-mallin selkäranka.

vaatimusanalyysin aikana väliin jäänyt ja Yksikkötesteissä Kiinni jäänyt ongelma voi maksaa organisaatiolle kymmeniä tuhansia dollareita ja tämä hinta voi johtaa miljooniin dollareihin, jos se tulee markkinoilta takaisinkutsuna (vuonna 2017 USA veloitti turvatyynyvalmistaja Takatalta 1 miljardin dollarin sakon räjähtävien turvatyynyjen takia).

organisaatio päätyisi suorittamaan vahingontorjuntatehtäviä, kuten juurisyyanalyysin, 5 why documentsin, vikapuuanalyysin, 8D-dokumentin jne. sen sijaan, että keskityttäisiin ohjelmistokehitykseen ja laatuun.

pahimmissa tapauksissa organisaatio ajautuisi asiakkaan nostamiin oikeusjuttuihin, jos kyseinen ominaisuus on turvallisuuteen/turvallisuuteen liittyvä, kuten turvatyyny, turvatyyny, ABS (Lukkiutumaton jarrujärjestelmä) jne.