Vad är kravanalys och insamling i SDLC?

what is requirement analysis

Denna handledning förklarar vad som är kravanalys, kravanalyssteg, exempel och mål för kravinsamling i SDLC:

Mjukvaruutveckling är en enorm uppgift som skapar en fungerande mjukvaruprodukt.

Programvaruprodukten är byggd enligt kundens krav. För det mesta överensstämmer denna programvaruprodukt med vad slutkunden / användaren hade förväntat sig, medan ibland inte den här produkten helt uppfyller vad kunden / slutanvändaren hade förväntat sig.

Vad du kommer att lära dig:

• Vad är kravanalys?
  • Steg / steg för kravanalys
    • # 1) Kravsamling
    • # 2) Analysera insamlade krav
    • # 3) Dokumentera analyserade krav
  • Konvertering av företagskrav till programvarukrav
  • Att förstå fall som inte är funktionella krav
  • Skillnaden mellan företagskrav och programvarukrav
• Slutsats
  • Rekommenderad läsning

Vad är kravanalys?

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

Förväntningar från kunder / slutanvändare:

Kund / slutanvändare får:

Som du kan analysera från bilderna ovan att det inte finns någon matchning mellan slutprodukten och kundernas förväntningar. Detta kan bero på otaliga skäl, dvs. felaktig implementering av kundkrav, felaktig design, fel förståelse för kundkrav av programmerare och kvalitetsgrupper etc.

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 hjälpt till att mildra den felaktiga och ofullständiga produktleveransen till kund / slutanvändare.

En bra produktleverans kräver korrekt kravuppsamling, effektiv granskning av krav som samlats in och slutligen tydlig kravdokumentation som förutsättning. Hela denna process kallas också för Kravsanalys i programvaruutvecklings livscykel (SDLC)

Steg / steg för kravanalys

Som du kan se är Kravsanalys den första aktiviteten i SDLC följt av Functional Specification och så vidare. Kravsanalys är ett viktigt steg i SDLC eftersom det resonerar med acceptansprovning som är avgörande för produktaccept av kunder.

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

Kravsanalys börjar med:

1. Kravsamling vilket också kallas som elicitation.
2. Detta följs av analyserar 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 kraven som samlats in.

# 1) Kravsamling

För att säkerställa att alla ovan nämnda steg utförs på rätt sätt måste klara, kortfattade och korrekta krav samlas från kunden. Kunden ska kunna definiera sina krav ordentligt och affärsanalytikern ska kunna samla in det på samma sätt som kunden tänker 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. Det är därför alltid en bra idé att involvera alla intressenter som kan påverka eller kan påverkas av slutprodukten.

Den möjliga intressentgruppen kan vara programvarukvalitetsingenjörer (både QC och QA), alla tredjepartsleverantörer som kan ge support i projektet, slutanvändare som produkten är avsedd för, programvaruprogrammerare, 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-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 kravuppsamlingsfasen hjälper till att förstå olika beroende av varandra och eventuella framtida konflikter kan avvärjas.

Ibland är det en bra idé att skapa en prototypmodell av den planerade produkten som planeras och visa den för kunden. Detta är ett utmärkt sätt att förmedla till kunder 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 prototyp skapas 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 ADAS för bilar är det möjligt att visa kunder en annan produkt som redan finns på marknaden och som utvecklats inom organisationen.

Till exempel, Ett surround-kamerasystem utvecklat för en OEM (GM, Volkswagen, BMW, etc.) och kan presenteras för en annan OEM.

Vänligen notera , är det inte klokt att visa produkt / proto-produkt till kunden som är under utveckling eftersom det kan bryta mot hemlighetsavtal som undertecknats med en annan kund för vilken produkten utvecklas. Det kan också leda till onödig juridisk krångel.

Ett annat exempel kan vara det infotainment-systemet, som utvecklas av organisationen och redan finns på marknaden. Affärsanalytiker och andra intressenter inom en organisation kan planera en workshopdemonstration för kunden och visa infotainmentsystem med konkreta HMI, portar för enhetsanslutningar, sandlåda etc.

Detta kommer att hjälpa kunden att förstå hur slutprodukten ser ut och tillhandahålla deras 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 (de flesta 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 vilket fall som helst skulle det vara en andning för kravuppsamlingsprocessen eftersom kunden nu vet vad han vill.

Affärsanalytikern kan nu anordna formella möten för kravutlämnande, där alla intressenter kan bjudas in och därmed kan notera de olika kraven som tillhandahålls av kunden (i vissa fall, om intressenterna är fler i antal, kan en separat skrivare utses för att notera kunden krav eller användarberättelser så att affärsanalytiker kan koncentrera sig på att moderera mötet).

Krav som samlats in kan vara i form av användarberättelser (i smidig utveckling), användningsfall, kundens naturliga språkdokument, diagram, flödesscheman etc. Användarberättelser blir populära i dagens programvaruutveckling. Användarberättelser är i grunden en uppsättning kundinmatningar på deras naturliga språk.

Exempel på kravsamling: I ADAS surround-kamerasystem kan en möjlig användarberättelse vara: 'Som användare borde jag kunna se vad som finns i baksidan av min bil'.

Det kan vara många 'Varför,' frågor som ställs i varje användarberättelse, vilket hjälper kunden att tillhandahålla mer detaljerad information om kravet.

I ovanstående användarberättelse, om en kund säger 'Som användare, skulle jag kunna se vad som finns i baksidan av min bil', ställa en fråga 'Varför 'Kan ge' Som användare borde jag kunna se vad som finns i baksidan av min bil, så att jag kan parkera min bil på ett säkert sätt ”.

Ställer frågan 'Varför' hjälper också till att skapa objektiva och atomkrav från humongous naturliga språk uttalanden från kunden. Detta kan enkelt implementeras senare i koden.

ny värld av Warcraft privat server

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

Exempel:

# 2) Analysera insamlade krav

Efterkravssamling, analys av kravstart. I detta skede sitter olika intressenter och gör en brainstorming-session. De analyserar de insamlade kraven och letar efter genomförbarhet för att genomföra dem. De diskuterar med varandra och varje tvetydighet ordnas.

Detta steg är viktigt i kravanalysprocessen på grund av följande huvudskäl:

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

Exempel: Kunderkan be om att titta på kamerasystemet med en bakåtkamerafunktion som hjälper till parkering bilen. Kunden kan också be om Trailer hitch-funktion som också använder bakre kamera för att fungera.

Om kunden anger ett krav som backkamera för parkering bistånd bör fungera hela tiden utan undantag, då Trailer funktionen skulle aldrig fungera och tvärtom.

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

Eftersom programmerare tänker som tekniska experter är det alltid möjligt att kundernas krav omvandlas felaktigt till funktionsspecifikationer som senare kommer att göras felaktigt 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 programutveckling, följa användningsfall som kunden tillhandahåller etc.

# 3) Dokumentera analyserade krav

När analysen av kraven är klar startar kravdokumentationen. Olika typer av krav kommer ur analysen av kraven.

Några av dessa är:

(i) Kundkravspecifikation.

(ii) Krav på programvaruarkitektur.

Exempel:

(iii) Krav på programvarudesign.

Exempel:

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

Exempel: 'När användaren trycker på Bluetooth-ikonen på Infotainment HMI, bör Bluetooth-skärmen visas'

(v) Icke-funktionell kravspecifikation (dvs prestanda, stress, belastning etc.).

Exempel: ”Det borde 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å FM-skärmen för tuner bör en knapp finnas för att välja olika stationer'

Ovanstående krav registreras och dokumenteras i kravhanteringsverktyg, som IBM DOORS, HP QC. Ibland har organisationer sina specialanpassade kravhanteringsverktyg för att sänka kostnaderna.

Låt oss nu titta på konverteringsprocessen Affärs krav till Programvarukrav (funktionell och icke-funktionell).

Konvertering av företagskrav 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 i mjukvarusystemet. Att utveckla hela mjukvarusystemet baserat på dessa krav är inte möjligt eftersom en detaljerad beskrivning av hur mjukvarusystemet eller komponenten kommer att implementeras inte nämns.

Python intervju frågor och svar för testare

Således måste företagskraven delas upp på mer detaljerade programvarukrav som kommer att beskrivas närmare funktionella och icke-funktionella krav.

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

1. Bryt ner höga affärsbehov till detaljerade användarberättelser.
2. Hämta ett flödesschema för att definiera flödet av aktiviteter.
3. Tillhandahålla villkoret som motiverar de härledda användarberättelserna.
4. Trådramscheman 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 på Automotive Infotainment-system.

Affärsbehovet säger, 'Slutanvändare ska kunna komma åt navigationsrutan Navigation från Infotainment-systemet HMI och bör kunna ställa in destinationsadress'.

Så ovanstående värvade steg kan implementeras som:

# 1) Bryt ner höga affärsbehov till detaljerade användarberättelser.

Låt oss konvertera detta affärsbehov till en användarberättelse på hög nivå, ” Som användare borde jag kunna komma åt rutan Navigationswidget så att jag kan ange destinationsadressen ”. Den här användarberättelsen berättar vad som behövs av slutanvändaren. Vi kommer att försöka definiera hur detta krav ska implementeras.

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

1. Vem är användarna?
2. Hur får jag åtkomst till navigering, ombord (från SD-kort) eller från SmartPhone?
3. Vilken typ av destinationsposter kan jag ange?
4. Ska jag få komma in på destinationen även när bilen parkerar?

Det här är mer detaljerade användarberättelser som härrör från användarnas berättelser på hög nivå och skulle hjälpa oss att få mer insikt i våra affärsbehov.

Vid den här tiden kan vi ta upp en av användarens underberättelser och börja ifrågasätta. Låt oss ta (nr 3):

1. Kan jag ange destinationsposter som Geo Coordinates, Postal Address, via Taligenkänning etc.?
2. Behöver jag GPS för att ange geokoordinater?
3. Kan jag ange den aktuella måladressen genom att söka från adresshistoriken?

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

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

# 3) Tillhandahållande av villkor som motiverar härledda användarberättelser.

Vi kan se att mer detaljerad information dyker upp på grund av sönderdelningen av högnivåaffärskravet i detaljerade lågnivåanvändarberättelser och flödesschemat. Från detta flödesschema kan vi få de tekniska detaljer som behövs för implementering, nämligen.

• Skärmens laddningstid för att visa destinationsinmatningen ska vara 1 sek.
• Destinationsinmatningstangentbordet ska ha alfanumeriska tecken och specialsymboler.
• Växlingsknappen GPS aktivera / inaktivera ska finnas på skärmen för destinationsdestination för navigering.

Ovanstående information tillfredsställer användarberättelser 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) Trådramsdiagram för att förklara arbetsflödet för objekt.

Från ovanstående användningsfall kommer vi att härleda ett trådramschema som gör användargränssnittet tydligare.

# 5) Definiera icke-funktionella krav utifrån affärskraven.

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

Funktionskrav klargör dock inte systemets prestanda och andra kvalitativa parametrar som tillgänglighet, tillförlitlighet etc.

Exempel:

a) Vi tar exemplet med ovanstående bilinfotainmentsystem.

Om föraren (slutanvändaren) av bilen spelar musik från USB och navigeringsvägledningen pågår, också får ett inkommande samtal via Bluetooth i handsfree-läge ökar belastningen på CPU- och RAM-förbrukningen till en maximal nivå eftersom flera processer är kör i bakgrunden.

Vid det här tillfället, om föraren trycker på ett infotainmentsystem pekskärmsgränssnitt för att avvisa inkommande samtal via autosvar-SMS (på samma sätt som vi gör i våra mobiltelefoner), bör systemet 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, infotainment-systemet tar emot rygg-till-bak-SMS (kanske 20 SMS inom 10 sekunder) via ansluten Bluetooth-telefon. Infotainment-systemet borde kunna hantera alla inkommande SMS och bör under inga omständigheter missa något av det inkommande SMS-meddelandet på Infotainment HMI.

Ovanstående exempel är fall av icke-funktionella krav som inte kunde testas via funktionskrav ensamma. Även om kunder ibland missar 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.

Att förstå fall som inte är funktionella krav

Tabellen nedan förklarar icke-funktionella krav:

Icke-funktionella krav, till skillnad från funktionskrav, tar ett projekts hela livscykel för att implementeras, eftersom de implementeras stegvis i respektive Agile Sprints eller i olika iterationer.

Så här härleder vi programvarukrav från företagskrav.

Skillnaden mellan företagskrav och programvarukrav

Vi har sett ovan hur man kan härleda mjukvarukrav från höga 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 företagskrav är höga krav på kundernas naturliga språk medan mjukvarukrav är detaljerade lågnivåkrav som hjälper till att implementera programvarusystemet.

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

Slutsats

Kravsanalys är ryggraden i alla SDLC-modeller.

En fråga som missas under kravanalys och fångas vid enhetstestning kan kosta tiotusentals dollar för en organisation och den här kostnaden kan leda till miljontals dollar om den kommer från marknaden som återuppringning (2017, USA laddade krockkuddstillverkaren, Takata a böter på $ 1 miljarder på grund av exploderande krockkuddar).

Organisationen skulle sluta utföra skadekontrolluppgifter som rotorsaksanalys, förbereda 5 varför dokument, felträdsanalys, 8D-dokument etc. istället för att koncentrera sig på mjukvaruutveckling och kvalitet.

I värsta fall skulle organisationen dras in i juridiska stämningar som inlämnats av kunden om den berörda funktionen är säkerhets- / säkerhetsrelaterad som säkerhetsåtkomst, krockkudde, ABS (Anti-Lock-bromssystem) etc.

Rekommenderad läsning

• SDLC (Software Development Life Cycle) -faser, metoder, processer och modeller
• Funktioner av funktionella krav och icke-funktionella krav
• Hur testar jag specifikationer för mjukvarukrav (SRS)?
• 5 Dödliga misstag i kravhantering och hur man övervinner dem
• Hur testar jag en ansökan utan krav?
• Åtgärder för SSDLC (Secure Software Development Life Cycle)
• Spiral Model - Vad är SDLC Spiral Model?
• Vad är SDLC Waterfall Model?