Menu

Hvordan tester jeg specifikationer til softwarekrav (SRS)?

how test software requirements specification

Prøv Vores Instrument Til At Fjerne Problemer

Er du klar over det 'Det meste af Bugs i software skyldes ufuldstændige eller unøjagtige funktionelle krav? ” Uanset hvor godt det er skrevet, betyder softwarekoden ikke noget, og der kan ikke gøres noget, hvis der er uklarheder i kravene.

I denne artikel om specifikation af softwarekrav (SRS) hedder det, at krav skal være klare, specifikke, målbare og komplette uden modsigelser.

hvordan man finder netværkssikkerhedsnøgle på Android

Det er bedre at fange kravene uklarheder og rette dem i selve den tidlige udviklings livscyklus.

Sådan tester du specifikationer til softwarekrav (SRS) _

Omkostningerne ved at rette fejlen efter afslutningen af ​​udviklingen eller produktudgivelsen er for høje. Så det er vigtigt at have kravanalyse og fange disse forkerte krav inden designspecifikationer og projektimplementeringsfaser af SDLC.

Hvad du vil lære:

Sådan måles funktionelle SRS-dokumenter?

Vi skal definere nogle standardtest for at måle kravene. Når hvert krav er bestået gennem disse tests, kan du evaluere og fryse funktionelle krav.

Lad os tage en eksempel, du arbejder på en webbaseret applikation. Kravet er som følger: 'Webapplikation skal kunne tjene brugerforespørgsler så tidligt som muligt'

Hvordan fryser du kravet i dette tilfælde?

Hvad bliver dine kravtilfredshedskriterier? For at få svaret, spørg dette spørgsmål til interessenterne: Hvor meget responstid er ok for dig? Hvis de siger, accepterer vi svaret, hvis det er inden for 2 sekunder, så er dette din kravsmåling. Frys dette krav, og udfør den samme procedure til det næste krav.

Vi lærte lige hvordan vi måler kravene og fryser dem i design-, implementerings- og testfaser.

Lad os nu tage et andet eksempel: Jeg arbejdede på et webbaseret projekt. Kunden (interessenter) specificerede projektkravene i den indledende fase af projektudviklingen. Min manager cirkulerede alle kravene i teamet til gennemgang. Da vi startede diskussionen om disse krav, blev vi bare chokeret!

Alle havde sin egen opfattelse af kravene. Vi fandt mange uklarheder i de 'vilkår', der er specificeret i kravdokumenterne, som senere blev sendt til klienten til gennemgang / afklaring.

Klienten brugte mange tvetydige udtryk, som havde mange forskellige betydninger, hvilket gjorde det vanskeligt for os at analysere den nøjagtige betydning. Den næste version af kravdokumentet fra klienten var klar nok til at fryse til designfasen.

Fra dette eksempel lærte vi, at 'Krav skal være klare og konsekvente'

Næste kriterium til test af kravspecifikationen er 'Find manglende krav', lad os se på det.

Find manglende krav

Mange gange får projektdesignerne ikke en klar idé om hvert enkelt modul, og de antager simpelthen nogle krav i designfasen. Ethvert krav bør ikke baseres på antagelser. Kravene skal være komplette og dække hvert eneste aspekt af systemet under udvikling.

Specifikationer skal angive begge typer krav, dvs. hvilket system skal gøre, og hvad det ikke bør.

Generelt bruger jeg min egen metode til at afdække de uspecificerede krav. Når jeg læser Specifikationsdokument til softwarekrav (SRS) , Jeg noterer min egen forståelse af de krav, der er specificeret, plus andre krav, som SRS-dokumentet skal dække.

Dette hjælper mig med at stille spørgsmålene om de uspecificerede krav og derved gøre det tydeligere.

For at kontrollere fuldstændigheden af ​​kravene opdeles kravene i tre sektioner, 'Skal implementere' krav, krav, der ikke er specificeret, men som 'antages', og den tredje type er 'fantasi' type krav. Kontroller, om alle kravene er opfyldt inden softwaredesignfasen.

Kontroller, om kravene er relateret til projektmålet

Nogle gange har interessenter deres egen ekspertise, som de forventer at komme i systemet under udvikling. De tænker ikke engang, om dette krav ville være relevant for det igangværende projekt. Sørg for at identificere sådanne krav. Forsøg at undgå alle irrelevante krav i den første fase af projektudviklingscyklussen.

Hvis det ikke er muligt, så spørg spørgsmålene til interessenter som f.eks. Hvorfor vil du implementere dette specifikke krav? Dette vil beskrive det særlige krav i detaljer og derved gøre det lettere at designe systemet under hensyntagen til det fremtidige anvendelsesområde.

Men hvordan skal man beslutte, om kravene er relevante eller ej?

Simpelt svar: Indstil projektmålet, og spørg dette spørgsmål: Hvis ikke implementering af dette krav vil medføre problemer med at nå vores specificerede mål? Hvis ikke, er dette et irrelevant krav. Spørg interessenterne, hvis de virkelig ønsker at gennemføre denne type krav.

Kort fortalt skal kravspecifikationsdokumentet (SRS) behandle følgende:

  • Projektfunktionalitet (Hvad skal der gøres, og hvad der ikke skal gøres).
  • Software, hardwaregrænseflader og brugergrænsefladen.
  • Systemkorrekthed, sikkerhed og ydelseskriterier.
  • Implementeringsspørgsmål (risici), hvis der er nogen.

Konklusion

Jeg har dækket næsten alle aspekter af kravmåling. For at være specifik om kravene vil jeg sammenfatte kravtestning i en sætning:

'Krav skal være klare og specifikke uden usikkerhed, krav skal kunne måles med hensyn til specifikke værdier, krav skal kunne testes med nogle evalueringskriterier for hvert krav, og krav skal være komplette uden modsigelser'

Testning skal starte i kravfasen for at undgå yderligere kravrelaterede fejl. Kommunikere mere og mere med dine interessenter for at afklare alle kravene inden projektdesign og implementering påbegyndes.

Har du nogen erfaring med at teste softwarekrav?

Du er velkommen til at dele dem i kommentarerne nedenfor.

Anbefalet læsning

^