Hva Er Kravanalyse Og Innsamling I SDLC?

Denne Opplæringen Forklarer Hva Som Er Kravanalyse, Kravanalysesteg, Eksempler og Mål For Kravsamling i SDLC:

Programvareutvikling er en humongous oppgave som skaper et fungerende programvareprodukt.

programvareproduktet er bygget i henhold til kundens krav. For det meste er dette programvareproduktet i samsvar med hva sluttkunden / brukeren hadde forventet, mens dette produktet noen ganger ikke fullt ut overholder hva kunden / sluttbrukeren hadde forventet.

Hva Er Kravanalyse?

La Oss forstå Kravanalysen ved hjelp av et eksempel.

Kunde/Sluttbruker forventning:

Kunde/Sluttbruker mottar:

Som du kan analysere fra bildene ovenfor at det er en mismatch i sluttproduktet til kundens forventning. Dette kan skyldes utallige grunner, nemlig. feil implementering av kundens krav, feil design, feil forståelse av kundens krav av programmerere og kvalitetsteam, etc.

men som du kan se, være det noen grunn til feil produktlevering, går den primære årsaken til kravet. Derfor, hvis riktig kravforståelse, fangst, implementering og testing ble gjort, ville det ha bidratt til å redusere feilaktig og ufullstendig produktlevering til kunde/sluttbruker.

en god produktlevering krever korrekt kravinnsamling, effektiv undersøkelse av krav som er samlet, og til slutt klar kravdokumentasjon, som forutsetning. Hele denne prosessen kalles Også Som Kravanalyse I Programvareutvikling Livssyklus (SDLC)

Kravanalysestadier / Trinn

Som du kan se, Er Kravanalyse den første aktiviteten i SDLC etterfulgt av Funksjonell Spesifikasjon og så videre. Kravanalyse er et viktig skritt i SDLC, da det resonerer med aksepttesting som er kritisk for produktaksept av kunder.

i denne opplæringen vil vi forklare hvordan kravanalyse gjøres i SDLC. Vi vil også se de ulike trinnene som er involvert, utfall, utfordringer og korrigerende tiltak i kravanalyse.

Kravanalyse starter med:

1. Krav samling som også kalles som utløser.
2. dette følges ved å analysere de innsamlede kravene for å forstå korrektheten og muligheten for å konvertere disse kravene til et mulig produkt.
3. og til slutt, dokumentere kravene samlet.

#1) Krav Samling

for å sikre at alle trinnene nevnt ovenfor er riktig utført, må klare, konsise og riktige krav samles fra kunden. Kunden skal kunne definere sine krav riktig og business analytiker skal kunne samle det på samme måte som kunden er tenkt det å formidle.

Mang en gang er det ikke mulig at kravet samling er gjort effektivt av forretningsanalytikere fra kunden. Dette kan skyldes avhengighet av mange mennesker relatert til forventet sluttprodukt, verktøy, miljø, etc. Derfor er det alltid en god ide å involvere alle interessenter som kan påvirke eller bli påvirket av sluttproduktet.

den mulige interessentgruppen kan være Programvarekvalitetsingeniører (Både QC og QA), enhver tredjepartsleverandør som kan gi støtte i prosjektet, sluttbruker for hvem produktet er ment for, programvareutviklere, et annet team i organisasjonen som kan gi en modul eller programvareplattform, programvarebiblioteker, etc. for produktutvikling.

Eksempel: I en organisasjon utvikler DE ET adas-produkt (surround-view camera system for en prestisjefylt OEM) som trenger Autosar-stack og Bootloader-binærfiler som mottas fra en annen leverandør.

Involverer ulike interessenter i kravet samlingsstadiet bidrar til å forstå ulike avhengigheter på hverandre og eventuelle fremtidige konflikter kan avverges.

Noen ganger er det en god ide å lage en prototypemodell av det planlagte produktet, og vise det til kunden. Dette er en utmerket måte å formidle til kundene hva produktet er de forventer og hvordan det kan se senere. Dette hjelper kunden med å visualisere produktet de forventer, og hjelper dem med å komme opp med klare krav.

denne prototypen er avhengig av to typer produkter:

1. et lignende produkt som kundene ment, finnes i organisasjonen.
2. Nytt produkt som skal utvikles.

(i) i det første tilfellet er det lettere å vise kunden hvordan sluttproduktet vil se ut og hvordan det ville bli utviklet. I automotive ADAS er det mulig å vise kunder et annet produkt som allerede er i markedet og ble utviklet i organisasjonen.

for eksempel er et surround-view-kamerasystem utviklet for EN OEM(GM, Volkswagen, BMW, etc.) og kan bli vist frem til en ANNEN OEM.

vær oppmerksom på at det ikke er lurt å vise produkt / proto produkt til kunden som er under utvikling, da det kan være i strid Med Ikke-Opplysningsavtale inngått med en annen kunde for hvem produktet utvikles. Det kan også resultere i en unødvendig juridisk tussle.

et annet eksempel kan være infotainmentsystemet, som utvikles av organisasjonen, og allerede er i markedet. Forretningsanalytikere og andre interessenter i en organisasjon kan planlegge en workshop demo for kunden, viser infotainment systemer med konkrete HMI, enhetskontakt porter, sandkasse, etc.

Dette vil hjelpe kunden til å forstå hvordan sluttproduktet vil se ut og gi sine krav mye tydeligere.

(ii) det andre tilfellet kan oppnås ved å lage en grunnleggende arbeidsmodell ved å gjøre enkel koding og montering (for det meste funksjoner her er hardkodet i programmer), eller ved å lage et flytskjema eller diagram som kan overbevise kunden hvordan produktet ville se ut.

I alle fall ville det være en pust i bakken for kravet samle prosessen som kunden nå vet hva han vil.

bedriftsanalytikeren kan nå organisere formelle kravfremkallingsmøter, der alle interessenter kan inviteres og dermed kan notere ned de ulike kravene fra kunden (i noen tilfeller, hvis interessenter er mer i antall, kan en egen skribent utnevnes for å notere kundekrav eller brukerhistorier slik at bedriftsanalytiker kan konsentrere seg om å moderere møtet).

krav samlet kan være i form av brukerhistorier (i smidig utvikling), brukstilfeller, kundespråklige dokumenter, diagrammer, flytdiagrammer, etc. Brukerhistorier blir populære i dagens livssyklus for programvareutvikling. Brukerhistorier er i utgangspunktet et sett med kundeinnganger i sitt naturlige språk.

Kravinnsamling Eksempel: I adas surround-view-kamerasystemet kan en mulig brukerhistorie være: «Som bruker bør jeg kunne se hva som er der i baksiden av bilen min».

det kan være mange «hvorfor» spørsmål på hver brukerhistorie, som vil hjelpe kunden med å gi mer detaljert informasjon om kravet.

i den ovennevnte brukerhistorien, hvis en kunde sier «som bruker skal jeg kunne se hva som er der i baksiden av bilen min», stille et spørsmål «hvorfor» kunne gi «som bruker skal jeg kunne se hva som er der i baksiden av bilen min, slik at jeg kan parkere bilen min trygt».

Å Stille spørsmålet «hvorfor» bidrar også til å skape objektive og atomiske krav fra humongous naturlig språk uttalelser gitt av kunden. Dette kan enkelt implementeres senere i koden.

En annen måte å samle kravet på er i form av brukstilfeller. Et brukstilfelle er en trinnvis tilnærming for å oppnå et bestemt resultat. Dette forteller ikke hvordan programvaren vil fungere på brukerinngang, men det står hva som forventes av brukerinnganger.

Eksempel:

#2) Analysere Samlet Krav

Etter kravet samling, analyse av kravet starter. På dette stadiet sitter ulike interessenter og gjør en brainstorming økt. De analyserer kravene samlet og ser etter mulighet til å implementere dem. De diskuterer med hverandre og enhver tvetydighet er sortert ut.

dette trinnet er viktig i kravanalyseprosessen på grunn av følgende hovedårsaker:

(I) Kunden kan gi noen krav som kan være umulig å implementere på grunn av ulike avhengigheter.

Eksempel: Kunder kan be om å surround-view kamerasystemet med en ryggekamera funksjon som vil hjelpe til med å parkere bilen. Kunden kan også be Om Trailer hitch-funksjonen som også bruker bakre kamera til å fungere.

hvis kunden oppgir et krav om at ryggekamera for parkeringshjelp skal fungere til enhver tid uten unntak, Vil Tilhengerfunksjonen aldri fungere og omvendt.

(ii) en forretningsanalytiker kan ha forstått kravet fra kunden annerledes enn hvordan en programmerer ville ha tolket.

siden programmerere tenker som tekniske eksperter, er det alltid mulig at kundens krav feilaktig konverteres til funksjonelle spesifikasjoner som senere blir feilaktig gjort til arkitektur – og designdokumenter og deretter til kode. Effekten er eksponentiell og bør derfor kontrolleres.

et mulig utbedringstiltak kan være ved å følge en smidig metode for programvareutvikling, etter brukssaker som kunden gir, etc.

#3) Dokumentere Analyserte Krav

når analysen av krav er gjort krav dokumentasjon starter. Ulike typer krav kommer ut av analysen av krav.

Noen Av disse er:

(i) Kundekrav spesifikasjon.

(ii) Krav Til Programvarearkitektur.

Eksempel:

(iii) Krav Til Programvaredesign.

Eksempel:

(iv) Funksjonell Kravspesifikasjon (direkte avledet fra kundens spesifikasjoner.)

Eksempel: «når brukeren trykker På Bluetooth-ikonet På Infotainment HMI, Skal Bluetooth-skjermen vises»

(v) Ikke-funksjonell Kravspesifikasjon (dvs. ytelse, stress, belastning, etc.).

Eksempel: «Det skal være mulig å pare 15 Bluetooth-enheter med infotainmentsystem uten forringelse av systemytelsen».

(vi) Krav Til Brukergrensesnitt.

Eksempel: «På Tuner FM-skjermen skal det gis en knapp for å velge forskjellige stasjoner»

kravene ovenfor er registrert og dokumentert i kravstyringsverktøy, som IBM DOORS, HP QC. Noen ganger har organisasjoner sine skreddersydde behovsstyringsverktøy for å redusere kostnadene.

La oss nå se på prosessen med å konvertere Forretningskrav Til Programvarekrav (funksjonell og ikke-funksjonell).

Konvertere Forretningskrav Til Programvarekrav

Forretningskrav, som diskutert ovenfor, er krav på høyt nivå som snakker om hva sluttbrukeren ønsker fra en definert handling på programvaresystemet. Det er ikke mulig å utvikle hele programvaresystemet basert på disse kravene, da det ikke er nevnt en detaljert beskrivelse av hvordan programvaresystemet eller komponenten skal implementeres.

Dermed Må Forretningskrav brytes ned på mer detaljerte programvarekrav som vil bli ytterligere detaljert til funksjonelle og ikke-funksjonelle krav.

for å gjøre dette kan følgende trinn følges:

1. Bryt ned forretningskravene på høyt nivå til detaljerte brukerhistorier.
2. Utlede et flytskjema for å definere flyten av aktiviteter.
3. Gir betingelsen som rettferdiggjør de avledede brukerhistoriene.
4. Wireframe diagrammer for å forklare arbeidsflyten av objekter.
5. Definere ikke-funksjonelle krav ut av forretningskravene.

la oss starte med å ta et Eksempel Automotive Infotainment system.

forretningskravet sier: «Sluttbrukeren skal kunne få Tilgang Til navigasjonswidgetboksen fra Infotainmentsystemet HMI og skal kunne angi destinasjonsadresse».

så kan de ovennevnte trinnene implementeres som:

#1) Bryt ned forretningskravene på høyt nivå til detaljerte brukerhistorier.

la oss konvertere dette forretningskravet til en brukerhistorie på høyt nivå: «Som bruker skal jeg kunne få tilgang Til navigasjonswidget-boksen slik at jeg kan skrive inn destinasjonsadressen». Denne brukerhistorien forteller hva sluttbrukeren trenger. Vi vil prøve å definere hvordan dette kravet skal implementeres.

La oss begynne med å stille mulige spørsmål til denne brukerhistorien, nemlig.

1. Hvem er brukerne?
2. hvordan får Jeg Tilgang Til Navigasjon, ombord (FRA SD-kort) eller Fra Smarttelefon?
3. hva slags måloppføringer kan jeg skrive inn?
4. Skal Jeg få lov til å komme inn på destinasjonen selv Når Bilen Er I Parkering?

dette er mer detaljerte nivåbrukerhistorier avledet fra brukerhistorier på høyt nivå og vil hjelpe oss med å få mer innsikt i Forretningsbehovet vårt.

På dette punktet kan vi ta opp en av brukerens underhistorier og begynne å stille spørsmål. La oss ta (nei. 3):

1. Kan jeg legge inn måloppføringer som Geo Koordinater, Postadresse, Via Talegjenkjenning, etc.?
2. TRENGER JEG GPS for å skrive Inn Geo-Koordinater?
3. kan jeg angi gjeldende destinasjonsadresse ved å søke i adressehistorikken?

#2) Utlede et flytskjema for å definere flyten av aktiviteter.

nå kan vi se at forretningsbehovet er brutt ned til svært detaljerte brukssaker som kan merkes i flytskjemaet som nedenfor:

#3) Gir forhold som rettferdiggjør avledede brukerhistorier.

vi kan se at mer detaljert informasjon dukker opp på grunn av dekomponering av forretningsbehovet på høyt nivå i detaljerte brukerhistorier på lavt nivå og til flytskjemaet. Fra dette flytskjemaet kan vi få de tekniske detaljene som trengs for implementering, nemlig.

• innlastingstid På Skjermen for å vise destinasjonsoppføring skal være 1 sek.
• tastaturet for destinasjonsoppføring skal ha alfanumeriske tegn og spesialtegn.
• GPS aktiver / deaktiver veksleknappen skal være til stede På Navigasjonsmålingsskjermen.

ovennevnte informasjon tilfredsstiller brukerhistorier og gjør det mulig for kravet å bli testet diskret og målbart å unngå forvirring med kravet mens det implementeres som funksjoner.

#4) Wireframe diagrammer for å forklare arbeidsflyten av objekter.

fra ovennevnte brukstilfelle vil vi utlede et wireframe-diagram som vil gjøre brukergrensesnittet klarere.

#5) Definere ikke-funksjonelle krav ut Av Forretningskravene.

det er viktig at detaljerte programvarekrav er avledet fra forretningskrav på høyt nivå, men mang en gang bare funksjonelle krav identifiseres som sier hvordan et system vil oppføre seg til en bestemt brukerinngang / handling.

funksjonelle krav klargjør imidlertid ikke systemytelse og andre kvalitative parametere som tilgjengelighet, pålitelighet, etc.

Eksempler:

a) vi tar eksemplet på det ovennevnte automotive infotainment-systemet.

hvis sjåføren(sluttbrukeren) av bilen spiller musikk FRA USB Og Navigasjonsveiledning pågår, får også et innkommende anrop via Bluetooth I Håndfri modus, og deretter øker CPU-og RAM-forbruket til et maksimalt nivå ettersom flere prosesser kjører i bakgrunnen.

På dette punktet, hvis sjåføren trykker på et infotainmentsystem berøringsskjermgrensesnitt for å avvise innkommende anrop via automatisk svar SMS (samme måte som vi gjør i våre mobiltelefoner), bør systemet kunne utføre denne oppgaven og bør ikke henge eller krasje. Dette er ytelsen til systemet når belastningen er høy, og vi tester tilgjengelighet og pålitelighet.

b) Et annet tilfelle er Stressscenariet.

Ta et eksempel, infotainment-systemet mottar Tilbake Til Tilbake Sms (kanskje 20 SMS innen 10 sek) via tilkoblet Bluetooth-telefon. Infotainment systemet skal kunne håndtere alle innkommende SMS og ikke på noe punkt bør gå glipp av noen av innkommende SMS-varsling På Infotainment HMI.

eksemplene ovenfor er tilfeller av ikke-funksjonelle krav som ikke kunne testes via funksjonelle krav alene. Selv om kundene noen ganger savner å gi disse ikke-funksjonelle kravene. Det er organisasjonens ansvar å gi dem denne informasjonen når et produkt leveres til kunden.

Forstå Ikke-funksjonelle Krav Tilfeller

tabellen nedenfor forklarer ikke-funksjonelle krav:

Ikke-funksjonelle krav, i motsetning til funksjonelle krav, ta hele livssyklusen til et prosjekt for å bli implementert, da de implementeres trinnvis i respektive Agile Sprints eller i forskjellige iterasjoner.

så, dette er hvordan vi utlede Programvarekrav Fra Forretningskrav.

Forskjell Mellom Forretningskrav Og Programvarekrav

vi har sett over hvordan vi kan utlede Programvarekrav fra Forretningskrav på Høyt Nivå. Programvarekrav gjør det mulig for programmerer og testingeniør å utvikle systemet og teste det effektivt. Så, vi vet nå at forretningskrav er høye krav til kundens naturlige språk, mens programvarekrav er detaljerte krav på lavt nivå som bidrar til implementeringen av programvaresystemet.

La oss se nærmere på den detaljerte forskjellen mellom de to kravtypene.

Konklusjon

Kravanalyse er ryggraden i ENHVER SDLC-modell.

et problem savnet under kravanalyse og fanget Ved Enhetstesting kan koste titusenvis av dollar til en organisasjon, og denne kostnaden kan føre til millioner av dollar hvis den kommer fra markedet som tilbakeringing(I 2017, usa belastet airbag produsent, Takata en bot på $1billion på grunn av eksploderende airbags).

organisasjonen vil ende opp med å utføre skadekontrolloppgaver som rotårsaksanalyse, forberedelse av 5 hvorfor dokumenter, feiltreanalyse, 8D-dokument, etc. i stedet for å konsentrere seg om programvareutvikling og kvalitet.

i verste fall vil organisasjonen bli trukket inn i juridiske søksmål innlevert av kunden hvis den berørte funksjonen er sikkerhet / sikkerhetsrelatert som sikkerhetstilgang, airbag, ABS (Anti-Lock braking system), etc.