Hva er kravanalyse og samling i SDLC?

what is requirement analysis

Denne opplæringen forklarer hva som er kravanalyse, kravanalysetrinn, eksempler og mål for kravsamling i SDLC:

Programvareutvikling er en enorm oppgave som skaper et fungerende programvareprodukt.

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

Hva du vil lære:

• Hva er kravanalyse?
  • Trinn / trinn for kravanalyse
    • # 1) Kravsamling
    • # 2) Analyse av innsamlede krav
    • # 3) Dokumentering av analyserte krav
  • Konvertering av forretningskrav til programvarekrav
  • Forstå saker som ikke er funksjonelle krav
  • Forskjellen mellom forretningskrav og programvarekrav
• Konklusjon
  • Anbefalt lesing

Hva er kravanalyse?

La oss forstå kravanalysen ved hjelp av et eksempel.

Forventning fra kunde / sluttbruker:

Kunden / sluttbruker mottar:

Som du kan analysere fra de ovennevnte bildene, er det et misforhold i sluttproduktet til kundens forventning. Dette kan skyldes utallige årsaker, nemlig feil implementering av kundekrav, feil design, feil forståelse av kundekrav fra programmerere og kvalitetsteam, etc.

Som du kan se, uansett om det er en 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 den feilaktige og ufullstendige produktleveransen til kunde / sluttbruker.

En god produktlevering krever riktig 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)

Trinn / trinn for kravanalyse

Som du kan se er Kravanalyse den første aktiviteten i SDLC etterfulgt av Funksjonsspesifikasjon og så videre. Kravsanalyse er et viktig skritt i SDLC, da det gjenspeiler akseptasjonstesting som er kritisk for produktaksept fra kunder.

I denne veiledningen vil vi forklare hvordan kravanalyse gjøres i SDLC. Vi vil også se de forskjellige trinnene involvert, resultater, utfordringer og korrigerende tiltak i kravanalyse.

Kravsanalyse starter med:

1. Kravsamling som også kalles som elisitasjon.
2. Dette følges av analyserer de innsamlede kravene for å forstå korrektheten og gjennomførbarheten av å konvertere disse kravene til et mulig produkt.
3. Og endelig, dokumentere kravene samlet.

# 1) Kravsamling

For å sikre at alle trinnene som er nevnt ovenfor er riktig utført, må klare, konsise og riktige krav hentes fra kunden. Kunden skal kunne definere kravene sine riktig, og forretningsanalytikeren skal kunne samle det på samme måte som kunden har til hensikt å formidle det.

Mange ganger er det ikke mulig at kravinnsamling skjer effektivt av forretningsanalytikere fra kunden. Dette kan skyldes avhengighet av mange mennesker relatert til det forventede sluttproduktet, verktøy, miljø osv. Det er derfor alltid en god ide å involvere alle interessentene som kan påvirke eller kunne 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, sluttbrukere som produktet er beregnet for, programvareprogrammerere, et annet team i organisasjonen som kan tilby en modul eller programvareplattform, programvarebiblioteker, etc. for produktutvikling.

Eksempel: I en organisasjon utvikler de et ADAS-produkt (surround-view-kamerasystem for en prestisjefylt OEM) som trenger Autosar stack og Bootloader binærfiler som mottas fra en annen leverandør.

Å involvere ulike interessenter i kravinnsamlingsfasen hjelper til å forstå forskjellige avhengigheter av hverandre, og enhver mulig fremtidig konflikt kan avverges.

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

Denne prototypen er avhengig av to typer produkter:

1. Et lignende produkt som kundene hadde til hensikt, finnes i organisasjonen.
2. Nytt produkt skal utvikles.

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

For eksempel, Et surround-kamerasystem utviklet for en OEM (GM, Volkswagen, BMW, etc.) og kan vises til en annen OEM.

Vær oppmerksom , er det ikke lurt å vise produkt / proto-produkt til kunden som er under utvikling, da det kan bryte med ikke-avsløringsavtale signert med en annen kunde som produktet utvikles for. Det kan også resultere i unødvendig juridisk krangling.

Et annet eksempel kan være infotainment-systemet, utviklet av organisasjonen, og er allerede i markedet. Forretningsanalytikere og andre interessenter i en organisasjon kan planlegge en workshopdemonstrasjon for kunden, og vise infotainment-systemer med håndfaste HMI, enhetskontaktporter, sandkasse osv.

Dette vil hjelpe kunden med å forstå hvordan sluttproduktet vil se ut og gi kravene deres mye tydeligere.

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

I alle fall ville det være en pustepause for kravinnsamlingsprosessen ettersom kunden nå vet hva han vil.

Forretningsanalytikeren kan nå organisere formelle krav om fremkallingsmøter, der alle interessenter kan bli invitert og dermed kan notere de ulike kravene som tilbys av kunden (i noen tilfeller, hvis interessentene er flere i antall, kan det oppnevnes en egen skriver som noterer kunden krav eller brukerhistorier slik at forretningsanalytiker kunne konsentrere seg om å moderere møtet).

Krav samlet kan være i form av brukerhistorier (i smidig utvikling), brukstilfeller, kunders naturlige språkdokumenter, diagrammer, flytskjemaer, etc. Brukerhistorier blir populære i dagens programvareutviklingslivssyklus. Brukerhistorier er i utgangspunktet et sett med kundeinnganger på deres naturlige språk.

Eksempel på kravsamling: I ADAS-kameraet med surround-visning kan en mulig brukerhistorie være: 'Som bruker skal jeg kunne se hva som er der bakfra på bilen min'.

Det kan være mange 'Hvorfor,' spørsmål stilt om hver brukerhistorie, som vil hjelpe kunden med å gi mer detaljert informasjon om kravet.

I brukerhistorien ovenfor, hvis en kunde sier 'Som bruker, burde jeg kunne se hva som er der bakfra på bilen min', stille et spørsmål 'Hvorfor 'Kunne gi' Som bruker, burde jeg kunne se hva som er der bakfra på bilen min, slik at jeg kan parkere bilen min trygt ”.

Still spørsmålet 'Hvorfor' hjelper også med å skape objektive og atomare krav fra humongous naturlige språk uttalelser gitt av kunden. Dette kan enkelt implementeres senere i koden.

program for å overvåke cpu og gpu temp

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

Eksempel:

# 2) Analyse av innsamlede krav

Innhenting av etterkrav, analyse av krav starter. På dette stadiet sitter ulike interessenter og gjør en idédugnad. De analyserer kravene som er samlet og ser etter muligheten for å implementere dem. De diskuterer med hverandre og enhver tvetydighet blir ordnet.

Dette trinnet er viktig i prosessen med kravanalyse på grunn av følgende hovedårsaker:

(Jeg) Kunden kan stille noen krav som kan være umulige å implementere på grunn av forskjellige avhengigheter.

Eksempel: Kunderkan be om å omgi kameraet med en bakkamera-funksjon som hjelper deg med parkering bilen. Kunden kan også be om Tilhenger hitch-funksjon som også bruker bakkamera til å fungere.

Hvis kunden oppgir et krav som ryggekamera for parkering assistanse skal fungere til enhver tid uten unntak, så Tilhenger funksjonen vil aldri fungere og omvendt.

(ii) En forretningsanalytiker kan ha forstått kravet fra kunde annerledes enn hvordan en Programmerer ville ha tolket.

Siden programmerere tenker som tekniske eksperter, er det alltid mulig at kundekravene blir konvertert feil til funksjonelle spesifikasjoner som senere blir gjort feil til arkitektur- og designdokumenter og deretter til kode. Virkningen er eksponentiell, og det bør derfor kontrolleres.

Et mulig avhjelpende tiltak kan være ved å følge en smidig metode for programvareutvikling, følge brukstilfeller som kunden gir osv.

# 3) Dokumentering av analyserte krav

Når analysen av kravene er gjort, starter kravdokumentasjonen. Ulike typer krav kommer ut av analysen av kravene.

Noen av disse er:

(Jeg) Kundespesifikasjon.

(ii) Programvarearkitekturkrav.

Eksempel:

(iii) Krav til programvaredesign.

Eksempel:

(iv) Funksjonskravspesifikasjon (direkte avledet fra kundespesifikasjoner.)

Eksempel: “Når brukeren trykker på Bluetooth-ikonet på Infotainment HMI, skal Bluetooth-skjermen vises”

(v) Ikke-funksjonell kravspesifikasjon (dvs. ytelse, stress, belastning osv.).

pl sql intervju spørsmål for erfarne

Eksempel: 'Det skal være mulig å koble 15 Bluetooth-enheter med infotainment-system uten forringelse av systemytelsen'.

(vi) Krav til brukergrensesnitt.

Eksempel: “På tuner FM-skjermen bør det være en knapp for å velge forskjellige stasjoner”

Ovennevnte krav registreres og dokumenteres i kravstyringsverktøy, som IBM DOORS, HP QC. Noen ganger har organisasjoner sine skreddersydde verktøy for kravhåndtering for å redusere kostnadene.

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

Konvertering av forretningskrav til programvarekrav

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

Dermed må forretningskrav deles opp på mer detaljerte programvarekrav som vil bli nærmere beskrevet til funksjonelle og ikke-funksjonelle krav.

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

1. Bryt ned høye forretningskrav til detaljerte brukerhistorier.
2. Utarbeide et flytskjema for å definere flyten av aktiviteter.
3. Tilbyr tilstanden som rettferdiggjør de avledede brukerhistoriene.
4. Trådrammediagrammer for å forklare arbeidsflyten til objekter.
5. Definere ikke-funksjonelle krav utenfor forretningskravene.

La oss starte med å ta et eksempel Automotive Infotainment system.

Forretningskravet sier: 'Sluttbruker skal kunne få tilgang til navigasjonsfeltboksen fra Infotainment-systemet HMI og skal kunne angi destinasjonsadresse'.

Så de ovennevnte trinnene kan implementeres som:

# 1) Bryt ned de høye forretningskravene til detaljerte brukerhistorier.

La oss konvertere dette forretningskravet til en brukerhistorie på høyt nivå, “ Som bruker skal jeg kunne få tilgang til navigasjonsfeltet Navigasjon slik at jeg kan angi destinasjonsadressen ”. Denne brukerhistorien forteller hva som er nødvendig av sluttbrukeren. Vi vil prøve å definere hvordan dette kravet skal implementeres.

La oss starte 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 SmartPhone?
3. Hva slags destinasjonsoppføringer kan jeg legge inn?
4. Bør jeg få lov til å angi destinasjonen selv når bilen er i parkering?

Dette er mer detaljerte brukerhistorier avledet fra brukerhistorier på høyt nivå og vil hjelpe oss med å få mer innsikt i våre forretningskrav.

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

1. Kan jeg legge inn destinasjonsoppføringer som Geo Coordinates, Postal Address, via Talegjenkjenning, etc.?
2. Trenger jeg GPS for å angi geokoordinater?
3. Kan jeg angi gjeldende destinasjonsadresse ved å søke i adresseloggen?

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

Nå kan vi se at forretningskravet er brutt ned til veldig detaljerte brukssaker som kan merkes i flytskjemaet som nedenfor:

# 3) Tilby betingelser som rettferdiggjør avledede brukerhistorier.

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

• Skjermens lastetid for å vise destinasjonsoppføringen skal være 1 sek.
• Destinasjonsinngangstastaturet skal ha alfanumeriske tegn og spesielle symboler.
• GPS-aktivering / deaktivering av vippeknapp skal være til stede på inntaksskjermen for navigasjonsmål.

Ovenstående informasjon tilfredsstiller brukerhistorier og gjør det mulig for kravet å bli testet diskret og målbart, og unngå enhver forveksling med kravet mens det implementeres som funksjoner.

# 4) Trådrammediagrammer for å forklare arbeidsflyten til objekter.

Fra ovennevnte tilfelle vil vi utlede et trådrammediagram som vil gjøre brukergrensesnittet tydeligere.

# 5) Definere ikke-funksjonelle krav ut fra forretningskravene.

Det er viktig at detaljerte programvarekrav er avledet fra høye forretningskrav, men mange ganger identifiseres bare funksjonelle krav som sier hvordan et system vil oppføre seg for en bestemt brukerinngang / handling.

Funksjonelle krav avklarer imidlertid ikke systemytelse og andre kvalitative parametere som tilgjengelighet, pålitelighet osv.

Eksempler:

a) Vi tar eksemplet med ovennevnte bilinfotainmentsystem.

Hvis føreren (sluttbruker) av bilen spiller musikk fra USB og navigasjonsveiledning pågår, også får et innkommende anrop via Bluetooth i håndfri modus, øker belastningen på CPU og RAM-forbruk til et maksimalt nivå ettersom flere prosesser er kjører i bakgrunnen.

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

b) En annen sak er Stress-scenariet.

Ta et eksempel, infotainment-systemet mottar rygg-til-bak-SMS (kanskje 20 SMS innen 10 sek) via tilkoblet Bluetooth-telefon. Infotainment-systemet skal kunne håndtere all innkommende SMS og skal ikke på noe tidspunkt savne noe av det innkommende SMS-varselet på Infotainment HMI.

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

Forstå saker som ikke er funksjonelle krav

Tabellen nedenfor forklarer ikke-funksjonelle krav:

Ikke-funksjonelle krav, i motsetning til funksjonelle krav, tar hele prosjektets livssyklus for å bli implementert, ettersom de implementeres trinnvis i respektive Agile Sprints eller i forskjellige iterasjoner.

Så dette stammer vi fra programvarekrav fra forretningskrav.

Forskjellen mellom forretningskrav og programvarekrav

Vi har sett ovenfor hvordan man kan utlede programvarekrav fra høye forretningskrav. 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 kunders naturlige språk, mens programvarekrav er detaljerte krav på lavt nivå som hjelper til med implementeringen av programvaresystemet.

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

Konklusjon

Kravsanalyse er ryggraden i enhver SDLC-modell.

Et problem som ble savnet under kravanalysen og fanget opp under enhetstesting, kunne koste titusenvis av dollar for en organisasjon, og denne kostnaden kan føre til millioner av dollar hvis den kommer fra markedet som tilbakeringing (i 2017 belastet USA produsenten av kollisjonsputer, Takata a bot på $ 1 milliarder på grunn av eksploderende kollisjonsputer).

Organisasjonen vil ende opp med å utføre skadekontrolloppgaver som rotårsaksanalyse, utarbeide 5 hvorfor dokumenter, feiltre-analyse, 8D-dokument osv. I stedet for å konsentrere seg om programvareutvikling og kvalitet.

I verste fall vil organisasjonen bli dratt inn i juridiske søksmål anlagt av kunden hvis den berørte funksjonen er sikkerhets / sikkerhetsrelatert som sikkerhetstilgang, kollisjonspute, ABS (blokkeringsfri bremsesystem), etc.

Anbefalt lesing

• SDLC (programvareutvikling livssyklus) faser, metoder, prosesser og modeller
• Funksjoner av funksjonelle krav og ikke-funksjonelle krav
• Hvordan teste programvarekravspesifikasjon (SRS)?
• 5 dødelige feil i kravhåndtering og hvordan du kan overvinne dem
• Hvordan teste en søknad uten krav?
• Tiltak for SSDLC (Secure Software Development Life Cycle)
• Spiral Model - Hva er SDLC Spiral Model?
• Hva er SDLC Waterfall Model?