Hvad er kravanalyse og indsamling i SDLC?

what is requirement analysis

Denne vejledning forklarer, hvad der er kravanalyse, kravanalysetrin, eksempler og mål for kravindsamling i SDLC:

Softwareudvikling er en enorm opgave, der skaber et fungerende softwareprodukt.

Softwareproduktet er bygget efter kundens krav. For det meste overholder dette softwareprodukt, hvad slutkund / bruger havde forventet, mens dette produkt undertiden ikke overholder det, kunden / slutbrugeren havde forventet.

Hvad du vil lære:

• Hvad er kravanalyse?
  • Trin / trin for kravanalyse
    • # 1) Kravsamling
    • # 2) Analyse af indsamlede krav
    • # 3) Dokumentering af analyserede krav
  • Konvertering af forretningskrav til softwarekrav
  • Forståelse af ikke-funktionelle krav Tilfælde
  • Forskellen mellem forretningskrav og softwarekrav
• Konklusion
  • Anbefalet læsning

Hvad er kravanalyse?

Lad os forstå kravanalysen ved hjælp af et eksempel.

Forventning fra kunde / slutbruger:

Kunden / slutbrugeren modtager:

Som du kan analysere ud fra ovenstående billeder, er der en uoverensstemmelse i slutproduktet til kundens forventning. Dette kan skyldes utallige grunde, nemlig forkert implementering af kundekrav, defekt design, forkert forståelse af kundekrav fra programmører og kvalitetshold osv.

Som du kan se, uanset om det er en grund til forkert produktlevering, går den primære årsag til kravet. Derfor, hvis korrekt kravforståelse, indfangning, implementering og test blev udført, ville det have bidraget til at afbøde den fejlagtige og ufuldstændige produktlevering til kunde / slutbruger.

En god produktlevering kræver korrekt kravindsamling, effektiv undersøgelse af krav, der er samlet, og endelig klar kravsdokumentation som forudsætning. Hele denne proces kaldes også som Kravsanalyse i softwareudviklings livscyklus (SDLC)

Trin / trin for kravanalyse

Som du kan se, er Kravsanalyse den første aktivitet i SDLC efterfulgt af Funktionsspecifikation og så videre. Kravsanalyse er et vigtigt skridt i SDLC, da det resonerer med accepttest, der er kritisk for produktaccept af kunder.

I denne vejledning forklarer vi, hvordan kravanalyse udføres i SDLC. Vi vil også se de forskellige involverede trin, resultater, udfordringer og korrigerende foranstaltninger i kravanalyse.

Kravsanalyse starter med:

1. Kravindsamling hvilket også kaldes som elicitation.
2. Dette efterfølges af analysere de indsamlede krav for at forstå rigtigheden og gennemførligheden af ​​at konvertere disse krav til et muligt produkt.
3. Og endelig, dokumenterer kravene indsamlet.

# 1) Kravsamling

For at sikre, at alle ovennævnte trin udføres korrekt, skal klare, koncise og korrekte krav indsamles fra kunden. Kunden skal være i stand til at definere deres krav korrekt, og forretningsanalytikeren skal være i stand til at indsamle det på samme måde som kunden har til hensigt at formidle det.

Mange gange er det ikke muligt, at kravindsamling sker effektivt af forretningsanalytikere fra kunden. Dette kan skyldes afhængighed af mange mennesker relateret til det forventede slutprodukt, værktøjer, miljø osv. Det er således altid en god ide at involvere alle de interessenter, der kan påvirke eller kunne blive påvirket af slutproduktet.

Den mulige interessentgruppe kan være softwarekvalitetsingeniører (både QC og QA), enhver tredjepartsleverandør, der kan yde support i projektet, slutbruger, som produktet er beregnet til, softwareprogrammerere, et andet team inden for organisationen, der muligvis leverer et modul eller en softwareplatform, softwarebiblioteker osv. til produktudvikling.

Eksempel: I en organisation udvikler de et ADAS-produkt (surround-view-kamerasystem til en prestigefyldt OEM), der har brug for Autosar-stak og Bootloader binære filer, der modtages fra en anden leverandør.

At involvere forskellige interessenter i kravindsamlingsfasen hjælper med at forstå forskellige afhængigheder af hinanden, og enhver mulig fremtidig konflikt kan afværges.

Nogle gange er det en god idé at oprette en prototype model af det planlagte produkt og vise det for kunden. Dette er en glimrende måde at formidle til kunderne, hvilket produkt de forventer, og hvordan det kan se ud senere. Dette hjælper kunden med at visualisere det produkt, de forventer, og hjælper dem med at komme med klare krav.

Denne oprettelse af prototype afhænger af to typer produkter:

1. Et lignende produkt, som kunderne havde til hensigt, findes inden for organisationen.
2. Nyt produkt skal udvikles.

(jeg) I det første tilfælde er det lettere at vise kunden, hvordan slutproduktet ville se ud, og hvordan det ville blive udviklet. I bilindustrien ADAS er det muligt at vise kunderne et andet produkt, der allerede er på markedet og blev udviklet inden for organisationen.

For eksempel, Et surround-kamerasystem udviklet til en OEM (GM, Volkswagen, BMW osv.) Og kan fremvises til en anden OEM.

Bemærk venligst , er det ikke klogt at vise produkt / proto-produkt til kunden, som er under udvikling, da det kan krænke tavshedsaftale underskrevet med en anden kunde, for hvem produktet udvikles. Det kan også resultere i en unødvendig juridisk kamp.

Et andet eksempel kan være infotainment-systemet, der udvikles af organisationen og allerede findes på markedet. Forretningsanalytikere og andre interessenter i en organisation kan planlægge en workshopdemo for kunden, der viser infotainment-systemer med håndgribelig HMI, enhedsstikporte, sandkasse osv.

Dette vil hjælpe kunden med at forstå, hvordan slutproduktet ser ud og give deres krav meget tydeligere.

(ii) Den anden sag kan opnås ved at oprette en grundlæggende arbejdsmodel ved at udføre enkel kodning og samling (for det meste er funktioner her hårdkodet i softwareprogrammer) eller ved at oprette et rutediagram eller diagram, der kunne overbevise kunden om, hvordan produktet ville se ud.

Under alle omstændigheder ville det være en åndedræt for kravindsamlingsprocessen, da kunden nu ved, hvad han vil have.

Forretningsanalytikeren kan nu afholde formelle møder med krav om fremkaldelse af krav, hvor alle interessenter kunne blive inviteret og således kan notere de forskellige krav, der stilles af kunden (i nogle tilfælde, hvis interessenterne er mere i antal, kan der udpeges en separat skriftlig skriftlærer til at notere kunden krav eller brugerhistorier, så forretningsanalytikere kunne koncentrere sig om at moderere mødet).

Krav, der indsamles, kan være i form af brugerhistorier (i agil udvikling), brugssager, kunders naturlige sprogdokumenter, diagrammer, flowcharts osv. Brugerhistorier bliver populære i den moderne softwareudviklings livscyklus. Brugerhistorier er dybest set et sæt kundeinput på deres naturlige sprog.

Eksempel på indsamling af krav: I ADAS-surround-kamerasystemet kunne en mulig brugerhistorie være: 'Som bruger skal jeg kunne se, hvad der er bagud i bilen'.

Der kunne være mange 'hvorfor,' spørgsmål stillet til hver brugerhistorie, som vil hjælpe kunden med at give mere detaljerede oplysninger om kravet.

I ovenstående brugerhistorie, hvis en kunde siger 'Som bruger, skulle jeg være i stand til at se, hvad der er bagfra i min bil', stille et spørgsmål 'hvorfor 'Kunne give' Som bruger skulle jeg være i stand til at se, hvad der er bagfra på min bil, så jeg kan parkere min bil sikkert ”.

Stil spørgsmålet 'hvorfor' hjælper også med at skabe objektive og atomare krav ud fra humongous naturlige sproglige udsagn fra kunden. Dette kan let implementeres senere i koden.

hvordan ser et modem ud

En anden måde at samle kravet på er i form af brugssager . En brugssag er en trinvis tilgang til opnåelse af et bestemt resultat. Dette fortæller ikke, hvordan softwaren fungerer på brugerinput, men der står, hvad der forventes af brugerinput.

Eksempel:

# 2) Analyse af indsamlede krav

Indsamling af postkrav, analyse af kravstart. På dette stadium sidder forskellige interessenter og laver en brainstorming. De analyserer de samlede krav og ser efter muligheden for at gennemføre dem. De diskuterer med hinanden, og enhver tvetydighed ordnes.

Dette trin er vigtigt i kravanalyseprocessen på grund af følgende hovedårsager:

(jeg) Kunden kan stille nogle krav, som kan være umulige at implementere på grund af forskellige afhængigheder.

Eksempel: Kunderkan bede om at surround-view kamerasystemet med en bakkamera-funktion, der hjælper med parkering bilen. Kunden kan også bede om Anhænger hitch-funktion, som også bruger bagkamera til at arbejde.

Hvis kunden angiver et krav, som bakkamera til parkering assistance skal fungere til enhver tid uden undtagelse, så Anhænger funktion fungerer aldrig og omvendt.

(ii) En forretningsanalytiker kunne have forstået kravet fra kunde anderledes end hvordan en programmør ville have fortolket.

Da programmører tænker som tekniske eksperter, er det altid muligt, at kundekrav konverteres forkert til funktionelle specifikationer, som senere vil blive fejlagtigt foretaget i arkitektur- og designdokumenter og derefter til kode. Virkningen er eksponentiel og bør derfor kontrolleres.

En mulig afhjælpende foranstaltning kan være ved at følge en smidig metode til softwareudvikling, følge brugssager, som kunden leverer osv.

# 3) Dokumentering af analyserede krav

Når analysen af ​​kravene er udført, starter kravdokumentationen. Forskellige typer krav kommer ud af analysen af ​​kravene.

Nogle af disse er:

(jeg) Kundespecifikation.

(ii) Krav til softwarearkitektur.

Eksempel:

(iii) Software design krav.

Eksempel:

(iv) Funktionskravspecifikation (direkte afledt af kundespecifikationer.)

Eksempel: 'Når brugeren trykker på Bluetooth-ikonet på Infotainment HMI, skal Bluetooth-skærmen vises'

(v) Ikke-funktionel kravspecifikation (nemlig ydeevne, stress, belastning osv.).

Eksempel: “Det skal være muligt at parre 15 Bluetooth-enheder med infotainment-system uden forringelse af systemets ydeevne”.

(vi) Krav til brugergrænseflade.

Eksempel: “På tuner FM-skærmen skal der være en knap til at vælge forskellige stationer”

Ovennævnte krav registreres og dokumenteres i kravstyringsværktøjer som IBM DOORS, HP QC. Nogle gange har organisationer deres specialfremstillede værktøjer til styring af krav for at reducere omkostningerne.

Lad os nu se på processen med at konvertere Forretningskrav til Softwarekrav (funktionel og ikke-funktionel).

Konvertering af forretningskrav til softwarekrav

Forretningskrav, som beskrevet ovenfor, er krav på højt niveau, der taler om, hvad slutbrugeren ønsker af en defineret handling på softwaresystemet. Det er ikke muligt at udvikle hele softwaresystemet baseret på disse krav, da der ikke nævnes en detaljeret beskrivelse af, hvordan softwaresystemet eller komponenten skal implementeres.

Således skal forretningskrav opdeles på mere detaljerede softwarekrav, som vil blive yderligere detaljeret til funktionelle og ikke-funktionelle krav.

For at gøre dette kunne følgende trin følges:

1. Opdel forretningskravene på højt niveau til detaljerede brugerhistorier.
2. Udledning af et rutediagram for at definere strømmen af ​​aktiviteter.
3. Tilvejebringelse af den betingelse, der retfærdiggør de afledte brugerhistorier.
4. Trådrammediagrammer til forklaring af genstande.
5. Definition af ikke-funktionelle krav ud fra forretningskravene.

Lad os starte med at tage et eksempel på Automotive Infotainment-system.

Forretningskravet siger, 'Slutbruger skal have adgang til Navigation-widgetboksen fra Infotainment-systemet HMI og skal kunne indstille destinationsadresse'.

Så ovennævnte trin kan implementeres som:

# 1) Opdel de høje forretningskrav til detaljerede brugerhistorier.

Lad os konvertere dette forretningskrav til en brugerhistorie på højt niveau, “ Som bruger skal jeg kunne få adgang til navigationsfeltet Navigation, så jeg kan indtaste destinationsadressen ”. Denne brugerhistorie fortæller hvad der er nødvendigt af slutbrugeren. Vi vil forsøge at definere, hvordan dette krav skal implementeres.

Lad os starte med at stille mulige spørgsmål til denne brugerhistorie, nemlig.

1. Hvem er brugerne?
2. Hvordan kan jeg få adgang til Navigation, ombord (fra SD-kort) eller fra SmartPhone?
3. Hvilken slags destinationsposter kan jeg indtaste?
4. Bør jeg få lov til at indtaste destinationen, selv når bilen er i parkering?

Disse er mere detaljerede niveau brugerhistorier afledt af brugerniveauer på højt niveau og vil hjælpe os med at få mere indsigt i vores forretningskrav.

På dette tidspunkt kan vi tage en af ​​brugerunderhistorierne op og starte spørgsmålstegn. Lad os tage (nr. 3):

1. Kan jeg indtaste destinationsposter som Geo Coordinates, Postal Address, via Talegenkendelse osv.?
2. Har jeg brug for GPS til indtastning af geokoordinater?
3. Kan jeg indtaste den aktuelle destinationsadresse ved at søge fra adressernes historie?

# 2) Udledning af et rutediagram for at definere strømmen af ​​aktiviteter.

Nu kan vi se, at forretningskravet er opdelt i meget detaljerede brugssager, som kan markeres i rutediagrammet som nedenfor:

# 3) Tilvejebringelse af betingelser, der retfærdiggør afledte brugerhistorier.

Vi kan se, at der kommer mere detaljerede oplysninger på grund af nedbrydningen af ​​forretningskravet på højt niveau i detaljerede brugerniveauer på lavt niveau og til rutediagrammet. Fra dette rutediagram kan vi få de tekniske detaljer, der er nødvendige for implementering, nemlig.

• Skærmindlæsningstid for visning af destinationsindtastning skal være 1 sek.
• Destinationsindtastningstastaturet skal have alfanumeriske tegn og specielle symboler.
• GPS-aktivering / deaktivering af skifteknap skal være til stede på navigationsdestinationens skærmbillede.

Ovenstående information tilfredsstiller brugerhistorier og gør det muligt for kravet at blive testet diskret og måleligt og undgå enhver forveksling med kravet, mens det implementeres som funktioner.

# 4) Trådrammediagrammer til forklaring af arbejdsgange for objekter.

Fra ovenstående brugssag udleder vi et trådrammediagram, der gør brugergrænsefladen klarere.

# 5) Definition af ikke-funktionelle krav ud fra forretningskravene.

Det er bydende nødvendigt, at detaljerede softwarekrav er afledt af forretningskrav på højt niveau, men mange gange identificeres kun funktionelle krav, der siger, hvordan et system opfører sig for en bestemt brugerinput / handling.

Funktionelle krav præciserer imidlertid ikke systemets ydeevne og andre kvalitative parametre som tilgængelighed, pålidelighed osv.

data maskering værktøjer til SQL Server

Eksempler:

a) Vi tager eksemplet med ovenstående infotainmentsystem til biler.

Hvis bilens driver (slutbruger) spiller musik fra USB, og navigationsvejledning er i gang, også modtager et indgående opkald via Bluetooth i håndfri tilstand, øges belastningen på CPU og RAM-forbrug til et maksimalt niveau, da flere processer er kører i baggrunden.

På dette tidspunkt, hvis chaufføren banker på en infotainment-berøringsskærmgrænseflade for at afvise indgående opkald via automatisk svar-SMS (på samme måde som vi gør i vores mobiltelefoner), skal systemet være i stand til at udføre denne opgave og bør ikke hænge eller gå ned. Dette er systemets ydeevne, når belastningen er høj, og vi tester tilgængelighed og pålidelighed.

b) En anden sag er Stress-scenariet.

Tag et eksempel, infotainment-systemet modtager back-to-back SMS'er (måske 20 SMS inden for 10 sek) via tilsluttet Bluetooth-telefon. Infotainment-systemet skal være i stand til at håndtere al indgående SMS og bør på intet tidspunkt gå glip af nogen af ​​de indgående SMS-meddelelser på Infotainment HMI.

Ovenstående eksempler er tilfælde af ikke-funktionelle krav, som ikke kunne testes via funktionelle krav alene. Selvom kunder nogle gange savner at levere disse ikke-funktionelle krav. Det er organisationens ansvar at give dem disse oplysninger, når et produkt leveres til kunden.

Forståelse af ikke-funktionelle krav Tilfælde

Nedenstående tabel forklarer ikke-funktionelle krav:

Ikke-funktionelle krav tager i modsætning til funktionelle krav et projekts fulde livscyklus for at blive implementeret, da de implementeres trinvist i respektive Agile Sprints eller i forskellige iterationer.

Så det er sådan, vi udleder softwarekrav fra forretningskrav.

Forskellen mellem forretningskrav og softwarekrav

Vi har set ovenfor, hvordan man udleder softwarekrav fra forretningskrav på højt niveau. Softwarekrav gør det muligt for programmøren og testingeniøren at udvikle systemet og teste det effektivt. Så vi ved nu, at forretningskrav er naturlige kunders sproglige krav på højt niveau, mens softwarekrav er detaljerede krav på lavt niveau, der hjælper med implementeringen af ​​softwaresystemet.

Lad os se på den detaljerede forskel mellem de to kravtyper.

Konklusion

Kravsanalyse er rygraden i enhver SDLC-model.

Et problem, der blev savnet under kravanalyse og fanget ved enhedstest, kunne koste en organisation titusindvis af dollars, og disse omkostninger kunne føre til millioner af dollars, hvis de kommer fra markedet som tilbagekaldelse (i 2017 opkrævede USA airbagproducent, Takata a bøde på $ 1 billion på grund af eksploderende airbags).

Organisationen ville ende med at udføre skadekontrolopgaver som rodårsagsanalyse, forberede 5 hvorfor dokumenter, fejltræanalyse, 8D-dokument osv. I stedet for at koncentrere sig om softwareudvikling og kvalitet.

I værste tilfælde vil organisationen blive trukket ind i juridiske retssager indgivet af kunden, hvis den berørte funktion er sikkerheds- / sikkerhedsrelateret som sikkerhedsadgang, airbag, ABS (blokeringsfri bremsesystem) osv.

Anbefalet læsning

• SDLC (softwareudvikling livscyklus) faser, metoder, proces og modeller
• Funktioner af funktionelle krav og ikke-funktionelle krav
• Hvordan tester jeg specifikationer til softwarekrav (SRS)?
• 5 Dødbringende fejl i kravstyring og hvordan man kan overvinde dem
• Hvordan testes en ansøgning uden krav?
• Foranstaltninger til SSDLC (Secure Software Development Life Cycle)
• Spiral Model - Hvad er SDLC Spiral Model?
• Hvad er SDLC Waterfall Model?