Meny

Hur testar jag specifikationer för mjukvarukrav (SRS)?

how test software requirements specification

Prova Vårt Instrument För Att Eliminera Problem

Är du medveten om det 'De flesta av Fel i programvara beror på ofullständiga eller felaktiga funktionella krav? ” Hur väl det är skrivet, mjukvarukoden spelar ingen roll och ingenting kan göras om det finns tvetydigheter i kraven.

I den här artikeln om specifikation för mjukvarukrav (SRS) anges att krav måste vara tydliga, specifika, mätbara och fullständiga utan motsägelser.

Det är bättre att fånga kraven på tvetydigheter och fixa dem i själva den tidiga utvecklingslivet.

Hur man testar specifikationer för programvarukrav (SRS) _

Kostnaden för att åtgärda felet efter avslutad utveckling eller produktutgåva är för hög. Så det är viktigt att ha kravanalys och fånga upp dessa felaktiga krav innan designspecifikationer och projektimplementeringsfaser för SDLC.

Vad du kommer att lära dig:

Hur mäter jag funktionella SRS-dokument?

Vi måste definiera några standardtester för att mäta kraven. När varje krav har godkänts genom dessa tester kan du utvärdera och frysa funktionskraven.

Låt oss ta en exempel, du arbetar med en webbaserad applikation. Kravet är följande: 'Webbapplikationen ska kunna betjäna användarfrågorna så tidigt som möjligt'

Hur fryser du kravet i det här fallet?

Vilka blir dina kravtillfredsställelsekriterier? För att få svaret, ställ den här frågan till intressenterna: Hur mycket svarstid är ok för dig? Om de säger kommer vi att acceptera svaret om det är inom två sekunder, då är detta ditt kravmått. Frys detta krav och utför samma procedur för nästa krav också.

Vi lärde oss just hur man mäter kraven och fryser dem i faserna Design, Implementation och Testing.

Låt oss ta ett annat exempel: Jag arbetade med ett webbaserat projekt. Kund (intressenter) specificerade projektkraven i den inledande fasen av projektutvecklingen. Min chef cirkulerade alla krav i teamet för granskning. När vi inledde diskussionen om dessa krav blev vi bara chockade!

Alla hade sin egen uppfattning om kraven. Vi hittade många oklarheter i de ”termer” som anges i kravdokumenten, som senare skickades till klienten för granskning / förtydligande.

Klienten använde många tvetydiga termer, som hade många olika betydelser, vilket gjorde det svårt för oss att analysera den exakta innebörden. Nästa version av kravdokumentet från klienten var tillräckligt tydlig för att frysa för designfasen.

Från detta exempel lärde vi oss att 'Krav bör vara tydliga och konsekventa'

Nästa kriterium för att testa kravspecifikationen är 'Upptäck saknade krav', låt oss titta på det.

Upptäck saknade krav

Många gånger får projektdesignerna inte en klar uppfattning om varje specifik modul och de antar helt enkelt vissa krav i designfasen. Eventuella krav bör inte baseras på antaganden. Kraven bör vara fullständiga och täcka varje aspekt av systemet under utveckling.

Specifikationerna ska ange båda typerna av kravet, dvs. vilket system ska göra och vad det inte bör.

Generellt använder jag min egen metod för att avslöja de ospecificerade kraven. När jag läser Programvarukravspecifikationsdokument (SRS) , Jag antecknar min egen förståelse för de krav som anges, plus andra krav som SRS-dokumentet ska täcka.

Detta hjälper mig att ställa frågorna om de ospecificerade kraven och därmed göra det tydligare.

bästa gratisoptimeraren för Windows 7

För att kontrollera kraven är fullständiga, dela upp kraven i tre avsnitt, ”Måste implementera” krav, krav som inte är specificerade men antas och den tredje typen är ”fantasi” typ av krav. Kontrollera om alla typer av krav tas upp före programvarudesignfasen.

Kontrollera om kraven är relaterade till projektmålet

Ibland har intressenterna sin egen expertis som de förväntar sig kommer i systemet under utveckling. De tänker inte ens om detta krav skulle vara relevant för det aktuella projektet. Se till att identifiera sådana krav. Försök att undvika alla irrelevanta krav under den första fasen av projektutvecklingscykeln.

Om det inte är möjligt, ställ sedan frågorna till intressenter som varför vill du genomföra detta specifika krav? Detta kommer att beskriva det specifika kravet i detalj, vilket gör det enklare för design av systemet med tanke på det framtida omfånget.

Men hur avgör man om kraven är relevanta eller inte?

Enkelt svar: Ställ in projektmålet och ställ den här frågan: Om detta krav inte genomförs kommer det att orsaka problem att nå vårt angivna mål? Om inte, är detta ett irrelevant krav. Fråga intressenterna om de verkligen vill genomföra dessa typer av krav.

Kort sagt, kravspecifikationen (SRS) ska behandla följande:

  • Projektfunktionalitet (Vad ska göras och vad som inte bör göras).
  • Programvara, hårdvarugränssnitt och användargränssnittet.
  • Systemkorrekthet, säkerhet och prestandakriterier.
  • Implementeringsfrågor (risker) om sådana finns.

Slutsats

Jag har täckt nästan alla aspekter av kravmätning. För att vara specifik om kraven kommer jag att sammanfatta kravtestning i en mening:

'Krav bör vara tydliga och specifika utan osäkerhet, krav bör vara mätbara i termer av specifika värden, krav bör vara testbara med vissa utvärderingskriterier för varje krav och krav bör vara fullständiga, utan motsägelser'

Testning bör börja vid kravfasen för att undvika ytterligare kravrelaterade buggar. Kommunicera mer och mer med dina intressenter för att klargöra alla krav innan projektdesign och implementering påbörjas.

Har du någon erfarenhet av att testa programvarukrav?

Dela gärna dem i kommentarerna nedan.

Rekommenderad läsning

^