Hvad er kravanalyse og indsamling i SDLC?

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

udvikling af programmer er en humongøs opgave, der skaber et arbejdsprogramprodukt.

produktet er bygget efter kundens krav. For det meste overholder dette produkt, hvad slutkunden/brugeren havde forventet, mens dette produkt undertiden ikke fuldt ud overholder, hvad kunden/slutbrugeren havde forventet.

Hvad er kravanalyse?

lad os forstå Kravanalysen ved hjælp af et eksempel.

kunde/slutbruger forventning:

kunde / slutbruger modtager:

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

men som du kan se, det være sig nogen 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 indsamles, og endelig klar kravdokumentation som forudsætning. Hele denne proces kaldes også som krav analyse i programmel udvikling livscyklus (SDLC)

krav analyse stadier / trin

som du kan se, krav analyse er den første aktivitet i SDLC efterfulgt af funktionel specifikation og så videre. Kravanalyse er et vigtigt trin i SDLC, da det resonerer med accepttest, der er kritisk for kundernes accept af produkter.

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

kravanalyse starter med:

1. krav indsamling, som også kaldes som fremkaldelse.
2. dette efterfølges af en analyse af de indsamlede krav for at forstå rigtigheden og gennemførligheden af at konvertere disse krav til et muligt produkt.
3. og endelig dokumentation af de indsamlede krav.

#1) Indsamling af krav

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.

mange gange er det ikke muligt, at kravindsamling udføres 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 derfor altid en god ide at involvere alle de interessenter, der kan påvirke eller blive påvirket af slutproduktet.

den mulige interessentgruppe kan være programmelkvalitetsingeniører, enhver tredjepartsleverandør, der kunne yde support i projektet, slutbruger, som produktet er beregnet til, programmører, et andet team i organisationen, der muligvis leverer et modul eller en programmelplatform, programmelbiblioteker osv. til produktudvikling.

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

inddragelse af 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 ide at oprette en prototype model af det planlagte produkt og vise det til 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 prototype skabelse afhænger af to typer af produkt:

1. et lignende produkt, som kunderne havde til hensigt, eksisterer inden for organisationen.
2. nyt produkt, der skal udvikles.

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

for eksempel er et surround-se kamerasystem udviklet til en OEM (GM, Folkevogn, BMV osv.) og kan fremvises til en anden OEM.

Bemærk venligst, at det ikke er klogt at vise produkt/proto produkt til kunden, som er under udvikling, da det kan være i strid med fortrolighedsaftale underskrevet med en anden kunde, for hvem produktet er under udvikling. Det kan også resultere i en unødvendig juridisk slagsmål.

et andet eksempel kan være infotainment-systemet, der udvikles af organisationen, og som allerede er på markedet. Forretningsanalytikere og andre interessenter i en organisation kan planlægge en værkstedsdemo for kunden, visning af infotainmentsystemer med håndgribelige HMI, enhedsforbindelsesporte, sandkasse, etc.

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

(ii) det andet tilfælde kan opnås ved at oprette en grundlæggende arbejdsmodel ved at udføre enkel kodning og samling (for det meste funktioner her er hardkodet i programmer) eller ved at oprette et rutediagram eller diagram, der kan overbevise kunden om, hvordan produktet ville se ud.

under alle omstændigheder ville det være en pause for kravindsamlingsprocessen, da kunden nu ved, hvad han vil.

forretningsanalytikeren kan nu arrangere formelle kravfremkaldelsesmøder, hvor alle interessenter kunne inviteres og dermed kan notere de forskellige krav, som kunden stiller (i nogle tilfælde, hvis interessenter er mere i antal, kan der udpeges en separat skribent til at notere kundekrav eller brugerhistorier, så forretningsanalytiker kunne koncentrere sig om at moderere mødet).

krav indsamlet kan være i form af brugerhistorier (i agil udvikling), brugssager, kundens naturlige sprogdokumenter, diagrammer, rutediagrammer osv. Brugerhistorier bliver populære i den moderne livscyklus for udvikling af programmer. Brugerhistorier er dybest set et sæt kundeinput på deres naturlige sprog.

Kravindsamlingseksempel: i Adas surround-se kamerasystem kunne en mulig brugerhistorie være: “som bruger skulle jeg være i stand til at se, hvad der er bag på min bil”.

der kan være mange “hvorfor” – spørgsmål, der stilles 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 skal jeg være i stand til at se, hvad der er der i bagsiden af min bil”, stille et spørgsmål” Hvorfor “kunne give”som bruger skal jeg være i stand til at se, hvad der er der i bagsiden af min bil, så jeg kan parkere min bil sikkert”.

at stille spørgsmålet “Hvorfor” hjælper også med at skabe objektive og atomiske krav fra humongous naturlige sprog udsagn fra kunden. Dette kan let implementeres senere i koden.

en anden måde at indsamle 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 programmet vil arbejde på brugerinput snarere det siger, hvad der forventes af brugerinput.

eksempel:

#2) Analyse indsamlede krav

post krav indsamling, analyse af krav starter. På dette stadium sidder forskellige interessenter og laver en brainstorming. De analyserer de indsamlede krav og ser efter muligheden for at implementere dem. De diskuterer med hinanden, og enhver tvetydighed er sorteret ud.

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

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

eksempel: kunder kan bede om at surround-se kamerasystemet med en bagkamera-funktion, der hjælper med at parkere bilen. Kunden kan også bede om traileren hitch funktion, som også bruger bageste kamera til at arbejde.

Hvis kunden angiver et krav om, at bagkamera til parkeringshjælp skal fungere til enhver tid uden undtagelse, vil Trailerfunktionen aldrig fungere og omvendt.

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

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

en mulig afhjælpende foranstaltning kan være ved at følge en agil metode til udvikling af programmer, følge brugssager, som kunden leverer osv.

#3) dokumentation analyserede krav

når analysen af krav er gjort krav dokumentation starter. Forskellige typer krav kommer ud af analysen af krav.

nogle af disse er:

(i) kundekrav specifikation.

(II) krav til Programmelarkitektur.

eksempel:

(iii) krav til Programmeldesign.

eksempel:

(iv) funktionel Kravspecifikation (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ænsefladen.

eksempel: “På Tuner FM-skærmen skal der leveres en knap til at vælge forskellige stationer”

ovenstående krav registreres og dokumenteres i kravstyringsværktøjer, som f.eks. Nogle gange har organisationer deres skræddersyede kravstyringsværktøjer til at reducere omkostningerne.

lad os nu undersøge processen med at konvertere forretningskrav til Programmelkrav (funktionelle og ikke-funktionelle).

konvertering af forretningskrav til Programmelkrav

forretningskrav, som diskuteret ovenfor, er krav på højt niveau, der taler om, hvad slutbrugeren ønsker fra en defineret handling på programmelsystemet. Det er ikke muligt at udvikle hele programmelsystemet baseret på disse krav, da der ikke nævnes en detaljeret beskrivelse af, hvordan programmelsystemet eller komponenten vil blive implementeret.

Således skal Forretningskravene opdeles på mere detaljerede programmelkrav, 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. der følger et rutediagram for at definere strømmen af aktiviteter.
3. tilvejebringelse af den betingelse, der retfærdiggør de afledte brugerhistorier.
4. Rammediagrammer for at forklare arbejdsgangen for objekter.
5. definition af ikke – funktionelle krav ud af forretningskravene.

lad os starte med at tage et eksempel Automotive Infotainment system.

forretningskravet siger, “slutbrugeren skal kunne få adgang til Navigationskontrolboksen fra Infotainment system HMI og skal kunne indstille destinationsadresse”.

så ovenstående trin kan implementeres som:

#1) Opdel forretningskravene på højt niveau til detaljerede brugerhistorier.

lad os konvertere dette forretningskrav til en brugerhistorie på højt niveau, “som bruger skal jeg kunne få adgang til Navigationskontrolboksen, så jeg kan indtaste destinationsadressen”. Denne brugerhistorie fortæller, hvad slutbrugeren har brug for. Vi vil forsøge at definere, hvordan man implementerer dette krav.

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. skal jeg have lov til at komme ind på destinationen, selv når bilen er i parkering?

dette er mere detaljerede brugerhistorier, der stammer fra brugerhistorier 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 begynde at stille spørgsmålstegn ved. Lad os tage (nej. 3):

1. kan jeg indtaste destinationsposter som Geo koordinater, postadresse, via talegenkendelse osv.?
2. har jeg brug for GPS til indtastning af Geo-koordinater?
3. kan jeg indtaste den aktuelle destinationsadresse ved at søge fra adressehistorikken?

#2) der udledes 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 opstår mere detaljerede oplysninger på grund af nedbrydningen af forretningskravet på højt niveau i detaljerede brugerhistorier 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 at vise destinationsindtastningen skal være 1 sek.
• destinationsindtastaturet skal have alfanumeriske tegn og specielle symboler.
• GPS Aktiver/Deaktiver skifteknap skal være til stede på Navigationsdestinationsskærmen.

ovenstående oplysninger opfylder brugerhistorier og gør det muligt for kravet at blive testet diskret og målbart og undgå enhver forveksling med kravet, mens det implementeres som funktioner.

#4) Rammediagrammer for at forklare arbejdsgangen for objekter.

fra ovenstående brugssag udleder vi et rammediagram, der gør brugergrænsefladen klarere.

#5) definition af ikke-funktionelle krav ud af Forretningskravene.

det er bydende nødvendigt, at Detaljerede programmelkrav er afledt af forretningskrav på højt niveau, men mange gange identificeres kun funktionelle krav, der siger, hvordan et system vil opføre sig over for en bestemt brugerinput/handling.

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

eksempler:

a) Vi vil tage eksemplet på ovenstående infotainmentsystem til biler.

hvis føreren(slutbrugeren) af bilen spiller musik fra USB og Navigationsvejledning er i gang, får også et indgående opkald via Bluetooth i håndfri tilstand, så belastningen på CPU og RAM forbrug stiger til et maksimalt niveau, da flere processer kører i baggrunden.

på dette tidspunkt, hvis driveren tapper på en infotainment-system-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 Stressscenariet.

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 kunne håndtere alle indgående SMS ‘ er og på intet tidspunkt bør gå glip af nogen af de indgående SMS-meddelelser på Infotainment HMI.

ovenstående eksempler er tilfælde af ikke-funktionelle krav, der ikke kunne testes via funktionelle krav alene. Selvom nogle gange savner kunderne 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 Cases

nedenstående tabel forklarer ikke-funktionelle krav:

ikke-funktionelle krav, i modsætning til funktionelle krav, Tag fuld livscyklus for et projekt for at blive implementeret, da de implementeres trinvist i respektive Agile Sprints eller i forskellige iterationer.

så det er sådan, vi udleder Programmelkrav fra forretningskrav.

forskel mellem forretningskrav og Programmelkrav

vi har set ovenfor, hvordan man kan udlede Programmelkrav fra forretningskrav på højt niveau. Programkrav gør det muligt for programmøren og testingeniøren at udvikle systemet og teste det effektivt. Så vi ved nu, at forretningskrav er krav til kundens naturlige sprog på højt niveau, mens programmelkrav er detaljerede krav på lavt niveau, der hjælper med implementeringen af programmelsystemet.

lad os se på den detaljerede forskel mellem de to kravstyper.

konklusion

kravanalyse er rygraden i enhver SDLC-model.

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

organisationen ville ende med at udføre skadekontrolopgaver som rodårsanalyse, forberede 5 Hvorfor dokumenter, fejltræanalyse, 8D-dokument osv. i stedet for at fokusere på udvikling 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 (antiblokeringsbremsesystem) osv.