Vad är kravanalys och insamling i SDLC?

denna handledning förklarar vad som är kravanalys, Kravanalyssteg, exempel och mål för Kravansamling i SDLC:

mjukvaruutveckling är en humongous uppgift som skapar en fungerande mjukvaruprodukt.

programvaruprodukten är byggd enligt kundens krav. För det mesta överensstämmer denna mjukvaruprodukt med vad slutkund/användare hade förväntat sig, medan ibland denna produkt inte helt överensstämmer med vad kunden/slutanvändaren hade förväntat sig.

Vad är kravanalys?

Låt oss förstå Kravanalysen med hjälp av ett exempel.

kund/slutanvändare förväntan:

kund/slutanvändare får:

som du kan analysera från ovanstående bilder att det finns en obalans i slutprodukten till kundens förväntningar. Detta kan bero på otaliga skäl, nämligen. felaktig implementering av kundkrav, felaktig design, felaktig förståelse av kundkrav av programmerare och kvalitetsteam etc.

men som du kan se, oavsett om det är någon anledning till fel produktleverans, går den främsta orsaken till kravet. Därför, om korrekt kravförståelse, infångning, implementering och testning gjordes, skulle det ha bidragit till att mildra den felaktiga och ofullständiga produktleveransen till kund/slutanvändare.

en bra produktleverans kräver korrekt kravsamling, effektiv granskning av krav som samlas in och slutligen tydlig kravdokumentation som förutsättning. Hela processen kallas också som kravanalys i mjukvaruutveckling livscykel (SDLC)

Kravanalyssteg / steg

som du kan se är kravanalys den första aktiviteten i SDLC följt av funktionell specifikation och så vidare. Kravanalys är ett viktigt steg i SDLC eftersom det resonerar med acceptanstestning som är avgörande för produktacceptans av kunder.

i denna handledning kommer vi att förklara hur kravanalys görs i SDLC. Vi kommer också att se de olika stegen, resultat, utmaningar och korrigerande åtgärder i kravanalys.

kravanalys börjar med:

1. Kravsamling som också kallas elicitation.
2. detta följs av att analysera de insamlade kraven för att förstå riktigheten och genomförbarheten av att omvandla dessa krav till en möjlig produkt.
3. och slutligen dokumentera de insamlade kraven.

#1) Kravsamling

för att säkerställa att alla steg som nämns ovan är korrekt utförda måste tydliga, koncisa och korrekta krav samlas in från kunden. Kunden ska kunna definiera sina krav korrekt och affärsanalytikern ska kunna samla in det på samma sätt som kunden avser att förmedla.

många gånger är det inte möjligt att kravinsamling görs effektivt av affärsanalytiker från kunden. Detta kan bero på beroende av många människor relaterade till den förväntade slutprodukten, verktygen, miljön etc. Därför är det alltid bra att involvera alla intressenter som kan påverka eller påverkas av slutprodukten.

den möjliga intressentgruppen kan vara programvarukvalitetsingenjörer (både QC och QA), alla tredjepartsleverantörer som kan ge stöd i projektet, slutanvändare för vilken produkten är avsedd för, mjukvaruprogrammerare, ett annat team inom organisationen som kan tillhandahålla en modul eller mjukvaruplattform, programvarubibliotek etc. för produktutveckling.

exempel: i en organisation utvecklar de en ADAS-produkt (surround-view camera system för en prestigefylld OEM) som behöver Autosar-stack och Bootloader-binärer som tas emot från en annan leverantör.

att involvera olika intressenter i kravsamlingsstadiet hjälper till att förstå olika beroenden på varandra och eventuella framtida konflikter kan avvärjas.

ibland är det bra att skapa en prototypmodell av den planerade produkten och visa den för kunden. Detta är ett utmärkt sätt att förmedla till kunderna vilken produkt de förväntar sig och hur det kan se ut senare. Detta hjälper kunden att visualisera den produkt som de förväntar sig och hjälper dem att komma med tydliga krav.

denna prototypskapande beror på två typer av produkter:

1. en liknande produkt som kunderna avsåg finns inom organisationen.
2. ny produkt som ska utvecklas.

(i) i det första fallet är det lättare att visa kunden hur slutprodukten skulle se ut och hur den skulle utvecklas. I automotive ADAS är det möjligt att visa kunderna en annan produkt som redan finns på marknaden och utvecklades inom organisationen.

till exempel ett surround-view-kamerasystem utvecklat för en OEM (GM, Volkswagen, BMW, etc.) och kan visas upp till en annan OEM.

Observera att det inte är klokt att visa produkt/proto-produkt till kunden som är under utveckling eftersom det kan bryta mot sekretessavtal undertecknat med en annan kund för vilken produkten utvecklas. Det kan också leda till en onödig juridisk tussel.

ett annat exempel kan vara infotainmentsystemet, som utvecklas av organisationen och redan finns på marknaden. Affärsanalytiker och andra intressenter inom en organisation kan planera en workshop demo för kunden, visa infotainmentsystem med konkreta HMI, enhetskontaktportar,sandlåda, etc.

detta kommer att hjälpa kunden att förstå hur slutprodukten skulle se ut och ge sina krav mycket tydligare.

(ii) det andra fallet kan uppnås genom att skapa en grundläggande arbetsmodell genom att göra enkel kodning och montering (mestadels funktioner här är hårdkodade i program), eller genom att skapa ett flödesschema eller diagram som kan övertyga kunden hur produkten skulle se ut.

i alla fall skulle det vara en andning för kravinsamlingsprocessen eftersom kunden nu vet vad han vill.

affärsanalytikern kan nu organisera formella kravutlösningsmöten, där alla intressenter kan bjudas in och därmed kan notera de olika kraven från kunden (i vissa fall, om intressenterna är mer i antal, kan en separat skrivare utses för att notera kundkrav eller användarhistorier så att affärsanalytiker kan koncentrera sig på att moderera mötet).

krav som samlas in kan vara i form av användarhistorier (i smidig utveckling), användningsfall, kundens naturliga språkdokument, diagram, flödesscheman etc. Användarhistorier blir populära i den moderna livscykeln för mjukvaruutveckling. Användarhistorier är i grunden en uppsättning kundinsatser på sitt naturliga språk.

Kravsamlingsexempel: i ADAS surround-view-kamerasystemet kan en möjlig användarhistoria vara: ”som användare borde jag kunna se vad som finns i baksidan av min bil”.

det kan finnas många ”varför” frågor som ställs på varje användarhistoria, vilket hjälper kunden att ge mer detaljerad information om kravet.

i ovanstående användarhistoria, om en kund säger” som användare borde jag kunna se vad som finns i baksidan av min bil ”och ställa en fråga” varför ”skulle kunna ge”som användare borde jag kunna se vad som finns i baksidan av min bil, så att jag kan parkera min bil säkert”.

att ställa frågan ”Varför” hjälper också till att skapa objektiva och atomära krav från humongous natural language-uttalanden som ges av kunden. Detta kan enkelt implementeras senare i koden.

ett annat sätt att samla kravet är i form av användningsfall. Ett användningsfall är ett steg för steg för att uppnå ett visst resultat. Detta berättar inte hur programvaran kommer att fungera på användarinmatning utan det står, vad som förväntas av användaringångar.

exempel:

#2) analysera samlade krav

postkravsinsamling, analys av krav börjar. I detta skede sitter olika intressenter och gör en brainstorming. De analyserar de samlade kraven och letar efter genomförbarhet för att genomföra dem. De diskuterar med varandra och all tvetydighet sorteras ut.

detta steg är viktigt i kravanalysprocessen på grund av följande huvudorsaker:

(i) Kunden kan tillhandahålla vissa krav som kan vara omöjliga att genomföra på grund av olika beroenden.

exempel: kunder kan be om att omge kamerasystemet med en bakre kamerafunktion som hjälper till att parkera bilen. Kunden kan också be om dragkrok funktion som också använder bakre kamera för att arbeta.

om kunden anger ett krav på att backkamera för parkeringsassistans ska fungera hela tiden utan undantag, skulle Trailerfunktionen aldrig fungera och vice versa.

(ii) en affärsanalytiker kan ha förstått kravet från kunden annorlunda än hur en programmerare skulle ha tolkat.

eftersom programmerare tänker som tekniska experter är det alltid möjligt att kundkrav konverteras felaktigt till funktionella specifikationer som senare felaktigt görs till arkitektur-och designdokument och därefter till kod. Effekten är exponentiell och bör därför kontrolleras.

en möjlig korrigerande åtgärd kan vara genom att följa en smidig metod för mjukvaruutveckling, efter användningsfall som kunden tillhandahåller etc.

# 3) dokumentera analyserade krav

när analysen av kraven är klar krav dokumentation startar. Olika typer av krav kommer ut ur analysen av krav.

några av dessa är:

(i) kundens kravspecifikation.

(ii) krav på programvaruarkitektur.

exempel:

(iii) krav på mjukvarudesign.

exempel:

(iv) funktionell Kravspecifikation (direkt härledd från kundspecifikationer.)

exempel: ”när användaren trycker på Bluetooth-ikonen på Infotainment HMI ska Bluetooth-skärmen visas”

(v) icke-funktionell Kravspecifikation (dvs. prestanda, stress,belastning etc.).

exempel: ”det bör vara möjligt att para ihop 15 Bluetooth-enheter med infotainment-system utan att systemets prestanda försämras”.

(vi) krav på användargränssnitt.

exempel: ”På Tuner FM-skärmen bör en knapp tillhandahållas för att välja olika stationer”

ovanstående krav registreras och dokumenteras i kravhanteringsverktyg, som IBM DOORS, HP QC. Ibland har organisationer sina skräddarsydda kravhanteringsverktyg för att minska kostnaderna.

Låt oss nu titta på processen att konvertera affärskrav till programkrav (funktionella och icke-funktionella).

konvertera affärskrav till programvarukrav

affärskrav, som diskuterats ovan är krav på hög nivå som talar om vad slutanvändaren vill ha från en definierad åtgärd på mjukvarusystemet. Att utveckla hela mjukvarusystemet baserat på dessa krav är inte möjligt eftersom en detaljerad beskrivning av hur programvarusystemet eller komponenten kommer att implementeras inte nämns.

således måste Affärskraven delas upp på mer detaljerade programvarukrav som kommer att beskrivas ytterligare till funktionella och icke-funktionella krav.

för att göra detta kan följande steg följas:

1. Bryt ner affärskraven på hög nivå till detaljerade användarhistorier.
2. härleda ett flödesschema för att definiera flödet av aktiviteter.
3. tillhandahåller villkoret som motiverar de härledda användarhistorierna.
4. Wireframe-diagram för att förklara arbetsflödet för objekt.
5. definiera icke-funktionella krav utifrån affärskraven.

Låt oss börja med att ta ett exempel Fordonsinfotainmentsystem.

affärskravet säger, ”slutanvändaren ska kunna komma åt navigation widget box från Infotainment system HMI och ska kunna ställa in destinationsadress”.

så kan ovanstående steg implementeras som:

#1) Bryt ner affärskraven på hög nivå till detaljerade användarhistorier.

låt oss Konvertera detta affärskrav till en användarhistoria på hög nivå, ”som användare borde jag kunna komma åt navigationswidgetrutan så att jag kan ange destinationsadressen”. Den här användarberättelsen berättar vad slutanvändaren behöver. Vi kommer att försöka definiera hur man genomför detta krav.

låt oss börja med att ställa möjliga frågor till den här användarberättelsen, nämligen.

1. vilka är användarna?
2. Hur kan jag komma åt navigering, ombord (från SD-kort) eller från SmartPhone?
3. vilken typ av destinationsposter kan jag ange?
4. ska jag få komma in i destinationen även när bilen är i parkering?

dessa är mer detaljerade användarhistorier som härrör från användarhistorier på hög nivå och skulle hjälpa oss att få mer inblick i vårt affärskrav.

vid denna tidpunkt kan vi ta upp en av användarunderhistorierna och börja ifrågasätta. Låt oss ta (nej. 3):

1. kan jag ange destinationsposter som Geo-koordinater, postadress, via taligenkänning etc.?
2. behöver jag GPS för att ange Geo-koordinater?
3. kan jag ange den aktuella destinationsadressen genom att söka från adresshistoriken?

#2) härleda ett flödesschema för att definiera flödet av aktiviteter.

nu kan vi se att affärskravet är uppdelat i mycket detaljerade användningsfall som kan markeras i flödesschemat enligt nedan:

#3) tillhandahålla villkor som motiverar härledda användarhistorier.

vi kan se att mer detaljerad information dyker upp på grund av nedbrytningen av affärskravet på hög nivå i detaljerade användarhistorier på låg nivå och till flödesschemat. Från detta flödesschema kan vi få de tekniska detaljerna som behövs för implementering, nämligen.

• Skärmladdningstid för att visa destinationsinmatning ska vara 1 SEK.
• destinationstangentbordet ska ha alfanumeriska tecken och specialsymboler.
• GPS aktivera / inaktivera växlingsknappen ska vara närvarande på Navigeringsdestinationsskärmen.

ovanstående information uppfyller användarhistorier och gör det möjligt för kravet att testas diskret och mätbart för att undvika förvirring med kravet samtidigt som det implementeras som funktioner.

#4) Wireframe diagram för att förklara arbetsflödet för objekt.

från ovanstående användningsfall kommer vi att härleda ett wireframe-diagram som gör användargränssnittet tydligare.

#5) definiera icke-funktionella krav utifrån Affärskraven.

det är absolut nödvändigt att detaljerade programkrav härrör från höga affärskrav, men många gånger identifieras endast funktionella krav som säger hur ett system kommer att bete sig för en viss användarinmatning/åtgärd.

funktionella krav klargör dock inte systemprestanda och andra kvalitativa parametrar som tillgänglighet, tillförlitlighet etc.

exempel:

a) vi tar exemplet med ovanstående fordonsinfotainmentsystem.

om föraren(slutanvändaren) av bilen spelar musik från USB och navigering vägledning pågår, får också ett inkommande samtal via Bluetooth i handsfree-läge sedan ladda på CPU och RAM konsumtionen ökar till en maximal nivå som flera processer körs i bakgrunden.

vid denna punkt, om föraren kranar på ett infotainment-system pekskärm gränssnitt för att avvisa inkommande samtal via autosvar SMS (samma sätt som vi gör i våra mobiltelefoner), systemet ska kunna utföra denna uppgift och bör inte hänga eller krascha. Detta är systemets prestanda när belastningen är hög och vi testar tillgänglighet och tillförlitlighet.

b) ett annat fall är Stressscenariot.

ta ett exempel, infotainmentsystemet får rygg mot rygg SMS (kanske 20 SMS inom 10 SEK) via ansluten Bluetooth-telefon. Infotainment systemet ska kunna hantera alla inkommande SMS och vid något tillfälle bör missa någon av de inkommande SMS-aviseringar på Infotainment HMI.

ovanstående exempel är fall av icke-funktionella krav som inte kunde testas enbart via funktionella krav. Även om kunderna ibland saknar att tillhandahålla dessa icke-funktionella krav. Det är organisationens ansvar att förse dem med denna information när en produkt levereras till kunden.

förstå icke-funktionella Kravfall

nedanstående tabell förklarar icke-funktionella krav:

icke-funktionella krav, till skillnad från funktionella krav, ta hela livscykeln för ett projekt för att bli implementerat, eftersom de implementeras stegvis i respektive Agila sprintar eller i olika iterationer.

så det här är hur vi härleder programvarukrav från affärskrav.

skillnad mellan affärskrav och programkrav

vi har sett ovan hur man härleda programkrav från hög nivå affärskrav. Programvarukrav gör det möjligt för programmeraren och testingenjören att utveckla systemet och testa det effektivt. Så vi vet nu att affärskrav är höga krav på kundens naturliga språk medan programvarukrav är detaljerade krav på låg nivå som hjälper till att implementera mjukvarusystemet.

Låt oss titta på den detaljerade skillnaden mellan de två kravtyperna.

slutsats

kravanalys är ryggraden i alla SDLC-modeller.

ett problem som missades under kravanalys och fångades vid enhetstestning kan kosta tiotusentals dollar till en organisation och denna kostnad kan leda till miljoner dollar om den kommer från marknaden som en återuppringning (i 2017, USA laddad airbag tillverkare, Takata en böter på $1billion på grund av exploderande krockkuddar).

organisationen skulle sluta utföra skadekontrolluppgifter som grundorsaksanalys, förbereda 5 Varför dokument, felträdanalys, 8D-dokument etc. istället för att koncentrera sig på mjukvaruutveckling och kvalitet.

i värsta fall skulle organisationen dras in i juridiska rättegångar som lämnats in av kunden om den drabbade funktionen är säkerhets-/säkerhetsrelaterad som säkerhetsåtkomst, krockkudde, ABS (Anti-Lock bromssystem) etc.