Produktionen af ​​kravene stadiet af softwareudviklingsprocessen er Softwarekravspecifikationer (SRS) (også kaldet a kravdokument ). Denne rapport lægger et fundament for softwareingeniøraktiviteter og er under opbygning, når hele krav er fremkaldt og analyseret. SRS er en formel rapport, der fungerer som en repræsentation af software, der gør det muligt for kunderne at gennemgå, om det (SRS) er i overensstemmelse med deres krav. Det omfatter også brugerkrav til et system samt detaljerede specifikationer af systemkravene.

SRS er en specifikation for et specifikt softwareprodukt, program eller sæt applikationer, der udfører bestemte funktioner i et specifikt miljø. Det tjener flere mål afhængigt af, hvem der skriver det. For det første kunne SRS skrives af klienten i et system. For det andet kunne SRS være skrevet af en udvikler af systemet. De to metoder skaber helt forskellige situationer og etablerer helt forskellige formål for dokumentet. Det første tilfælde, SRS, bruges til at definere brugernes behov og forventninger. Den anden sag, SRS, er skrevet til forskellige formål og fungerer som et kontraktdokument mellem kunde og udvikler.

Karakteristika for god SRS

Følgende er funktionerne i et godt SRS-dokument:

1. Rigtighed: Brugergennemgang bruges til at give nøjagtigheden af ​​kravene angivet i SRS. SRS siges at være perfekt, hvis det dækker alle de behov, der virkelig forventes af systemet.

2. Fuldstændighed: SRS er komplet, hvis og kun hvis det indeholder følgende elementer:

(1). Alle væsentlige krav, uanset om de vedrører funktionalitet, ydeevne, design, begrænsninger, attributter eller eksterne grænseflader.

opdatering af java

(2). Definition af deres svar af softwaren på alle realiserbare klasser af inputdata i alle tilgængelige kategorier af situationer.

Bemærk: Det er vigtigt at specificere svarene på både gyldige og ugyldige værdier.

(3). Fuldstændige etiketter og referencer til alle figurer, tabeller og diagrammer i SRS og definitioner af alle termer og måleenheder.

3. Konsistens: SRS er konsekvent, hvis og kun hvis der ikke er nogen delmængde af individuelle krav beskrevet i dens konflikt. Der er tre typer mulige konflikter i SRS:

(1). De angivne egenskaber for objekter i den virkelige verden kan komme i konflikt. For eksempel,

(a) Formatet af en outputrapport kan i et krav beskrives som tabelform, men i et andet som tekst.

(b) En betingelse kan angive, at alle lys skal være grønne, mens en anden angiver, at alle lys skal være blå.

(2). Der kan være en rimelig eller tidsmæssig konflikt mellem de to specificerede handlinger. For eksempel,

(a) Et krav kan bestemme, at programmet vil tilføje to input, og et andet kan bestemme, at programmet vil multiplicere dem.

(b) En betingelse kan angive, at 'A' altid skal følge 'B', mens en anden kræver, at 'A og B' optræder sammen.

(3). To eller flere krav kan definere det samme objekt i den virkelige verden, men bruger forskellige udtryk for det objekt. For eksempel kan et programs anmodning om brugerinput kaldes en 'prompt' i et krav og en 'cue' i et andet. Brugen af ​​standardterminologi og -beskrivelser fremmer sammenhængen.

4. Entydighed: SRS er utvetydigt, når hvert fast krav kun har én fortolkning. Dette tyder på, at hvert element er unikt fortolket. Hvis der er en metode, der anvendes med flere definitioner, bør kravrapporten bestemme implikationerne i SRS, så den er klar og enkel at forstå.

5. Rangering for vigtighed og stabilitet: SRS er rangeret for vigtighed og stabilitet, hvis hvert krav i det har en identifikator til at angive enten betydningen eller stabiliteten af ​​det pågældende krav.

Typisk er alle krav ikke lige vigtige. Nogle forudsætninger kan være væsentlige, især for livskritiske applikationer, mens andre kan være ønskelige. Hvert element bør identificeres for at gøre disse forskelle klare og eksplicitte. En anden måde at rangordne krav på er at skelne klasser af elementer som væsentlige, betingede og valgfrie.

6. Modificerbarhed: SRS bør gøres så modificerbart som sandsynligt og bør være i stand til hurtigt at opnå ændringer i systemet til en vis grad. Ændringer skal indekseres perfekt og krydshenvises.

7. Verificerbarhed: SRS er korrekt, når de specificerede krav kan verificeres med et omkostningseffektivt system for at kontrollere, om den endelige software opfylder disse krav. Kravene verificeres ved hjælp af anmeldelser.

8. Sporbarhed: SRS kan spores, hvis oprindelsen af ​​hvert af kravene er klar, og hvis det letter henvisningen til hver betingelse i fremtidig udviklings- eller forbedringsdokumentation.

Der er to typer sporbarhed:

singleton design

1. Sporbarhed bagud: Dette afhænger af, at hvert krav udtrykkeligt henviser til sin kilde i tidligere dokumenter.

2. Fremadrettet sporbarhed: Dette afhænger af, at hvert element i SRS'en har et unikt navn eller referencenummer.

Den fremadrettede sporbarhed af SRS er især afgørende, når softwareproduktet går ind i drifts- og vedligeholdelsesfasen. Efterhånden som kode og designdokument ændres, er det nødvendigt at være i stand til at fastslå det komplette sæt af krav, der kan være berørt af disse ændringer.

9. Designuafhængighed: Der bør være mulighed for at vælge mellem flere designalternativer til det endelige system. Mere specifikt bør SRS ikke indeholde nogen implementeringsdetaljer.

10. Testbarhed: En SRS bør skrives på en sådan måde, at det er nemt at generere testcases og testplaner ud fra rapporten.

11. Forståelig af kunden: En slutbruger kan være ekspert inden for sit eksplicitte domæne, men er muligvis ikke uddannet i datalogi. Derfor bør formålet med formelle notationer og symboler så vidt muligt undgås. Sproget skal holdes enkelt og klart.

12. Det rigtige abstraktionsniveau: Hvis SRS er skrevet til kravstadiet, skal detaljerne forklares eksplicit. Hvorimod færre analyser kan bruges til en forundersøgelse. Derfor ændres abstraktionsniveauet i overensstemmelse med målet med SRS.

Egenskaber ved et godt SRS-dokument

De væsentlige egenskaber ved et godt SRS-dokument er følgende:

Kortfattet: SRS-rapporten skal være kortfattet og samtidig entydig, konsekvent og fuldstændig. Udførlige og irrelevante beskrivelser mindsker læsbarheden og øger også fejlmulighederne.

Struktureret: Det skal være velstruktureret. Et velstruktureret dokument er nemt at forstå og ændre. I praksis gennemgår SRS-dokumentet flere revisioner for at imødekomme brugerkravene. Ofte udvikler brugerkrav sig over en periode. For at gøre ændringerne til SRS-dokumentet nemme, er det derfor afgørende at gøre rapporten velstruktureret.

hvad gør en pc hurtig

Black-box-visning: Det skal kun definere, hvad systemet skal gøre og undlade at angive, hvordan disse skal gøres. Det betyder, at SRS-dokumentet skal definere systemets eksterne adfærd og ikke diskutere implementeringsproblemerne. SRS-rapporten bør se det system, der skal udvikles, som en sort boks og bør definere systemets eksternt synlige adfærd. Af denne grund er SRS-rapporten også kendt som black-box-specifikationen for et system.

Konceptuel integritet: Den skal vise begrebsmæssig integritet, så læseren blot kan forstå den. Reaktion på uønskede hændelser: Den skal karakterisere acceptable reaktioner på uønskede hændelser. Disse kaldes systemrespons på ekstraordinære forhold.

Verificerbar: Alle krav til systemet, som dokumenteret i SRS-dokumentet, skal være korrekte. Det betyder, at det bør være muligt at tage stilling til, om krav er opfyldt i en implementering.