Specifikation af softwarekrav (SRS): Tips & skabelon

Specifikation af softwarekrav (SRS): Tips & skabelon

Kommunikation er nøglen til succes inden for softwareudvikling. Ifølge en studere der undersøgte, hvorfor softwareudviklingsvirksomheder kæmper for at give kunderne softwareløsninger, der lever op til deres forventninger, dårlig kommunikation og uklare krav, er blandt de vigtigste grunde til, at softwareprojekter mislykkes.

Klare, velkommuniserede krav hjælper udviklingshold med at skabe det rigtige produkt, der repræsenterer grundlaget for en vellykket produktudvikling. Men hvordan ser sådanne krav faktisk ud, og hvordan skal de kommunikeres? Svaret er enkelt: med en softwarekravspecifikation (SRS).

Hvad er en SRS?

En SRS er et dokument, hvis formål er at give en omfattende beskrivelse af et softwareprodukt, der skal udvikles, herunder dets formål, de vigtigste forretningsprocesser, der understøttes, funktioner, nøglepræstationsparametre og adfærd. Som sådan fungerer det i det væsentlige som et kort, der styrer udviklingsprocessen og holder alle på rette spor.

En SRS er normalt underskrevet i slutningen af ​​kravene engineering fase, den tidligste fase i softwareudviklingsprocessen. Den indeholder både funktionelle og ikke-funktionelle krav. Funktionelle krav beskriver et softwaresystems og dets komponents funktion (såsom forudbestilling af bøger, når der beskrives et universitetsbibliotekssystem), mens ikke-funktionelle krav beskriver softwaresystemets og dets komponents ydeevneegenskaber (såsom sikkerhed eller service tilgængelighed).

IEEE (Institute of Electrical and Electronics Engineers) specifikation 830-1998 beskriver metoderne og de anbefalede tilgange til at definere en SRS, der hjælper softwarekunder med nøjagtigt at beskrive, hvad de ønsker at opnå, samtidig med at det er lettere for leverandører at forstå nøjagtigt, hvad kunden ønsker.

Fordele ved at skrive et SRS-dokument

Ud over at skabe grundlaget for en vellykket produktudvikling ved at skabe tilpasning mellem kunder og leverandører og holde alle involverede på samme side, tilbyder en SRS en række andre fordele, der gør det umagen værd at kræve at skrive det.

Ifølge Kurosh Farsimadan, en full-stack-udvikler hos Rideau, "Brug af SRS kan eliminere og forhindre fejl i designfasen, da eventuelle modstridende krav og funktioner, der har brug for validering, kan løses på dette tidspunkt, og interessenter kan kontaktes for revaluering."

Det er altid betydeligt billigere at foretage ændringer tidligt i softwareudviklingsprocessen end senere, når utallige timer og en masse energi og ressourcer allerede er brugt. At have en velskrevet SRS hjælper med at optimere udviklingsprocessen ved at forhindre dobbeltarbejde og strukturere problemer på en måde, der gør dem lette at løse.

Al anden dokumentation - både teknisk og forretningsmæssigt - kan baseres på SRS for at garantere dens konsistens og nøjagtighed.

Komponenter i en SRS

Ingen to SRS-dokumenter er identiske, fordi alle softwareprojekter er forskellige, nogle bruger vandfaldsudviklingsmodellen, og andre praktiserer agil udvikling. Det er dog stadig muligt at destillere hovedkomponenterne i en SRS og skabe en grov oversigt over, hvordan den skal se ud:

1. Introduktion
   1. Formål
   2. Publikum
   3. Anvendelsesformål
   4. Anvendelsesområde
   5. Akronymer og definitioner
2. Generel beskrivelse
   1. Brugernes behov
   2. Afhængigheder og antagelse
3. Krav og systemfunktioner
   1. Funktionelle krav
   2. Krav til eksternt interface
   3. System Egenskaber
   4. Ikke-funktionelle krav

Det første afsnit beskriver det produkt, der udvikles, dets formål, målgruppe, tilsigtede anvendelse og omfang. Det andet afsnit giver mere information om brugernes behov og de faktorer, der potentielt kan forhindre kravene i SRS i at blive opfyldt. Den sidste store sektion er dedikeret til specifikke krav, både funktionelle og ikke-funktionelle.

Hvordan man skriver en god SRS?

En god SRS skal opfylde flere nøgleegenskaber. Det bør være:

• Korrekt: Det er vigtigt at sikre, at SRS altid afspejler produktfunktionalitet og specifikation.
• Utvetydig: Det er bedre at være alt for specifik end tvetydig. SRS er ikke et litterært mesterværk, så selv de mest grundlæggende stilistiske regler kan ignoreres i klarhedens navn.
• Komplet: Det er aldrig en god ide at udelade enhver funktion, som kunden anmoder om.
• Konsekvent: Alle akronymer og definitioner skal bruges på en ensartet måde i hele SRS.
• Rangeret efter betydning og / eller stabilitet: Tid er ofte en knappe ressource under udviklingsprocessen, så rangordning af krav efter deres betydning og stabilitet er en god idé.
• verificerbar: Der skal være en verifikationsmetode for hvert krav.
• modificerbare: Ændringer i kravene skal foretages på en systematisk måde og deres indvirkning på andre krav bør tages i betragtning.
• sporbar: Alle krav skal kunne spores lige fra deres oprindelse.

Hvordan RM-software kan hjælpe med at skrive SRS-dokumenter

Det er fuldt ud muligt at skrive et godt SRS-dokument i Microsoft Word, Google Docs eller enhver anden tekstbehandler. Problemet med denne tilgang er, at det kan være ubehageligt kedeligt og tidskrævende. Faktum er, at selv relativt ligefremme softwareudviklingsprojekter kan være kravstunge. Når kravene ændres, grænser for ord processorer som Microsoft Word afsløres hurtigt.

I stedet for at løbe ind i forhindringer senere i udviklingsprocessen er det en meget bedre idé at bruge et dedikeret kravstyringsværktøj som Visure lige fra starten. En dedikeret værktøj til styring af krav giver integreret support til den komplette kravproces, styring af alle kravrelaterede oplysninger og deres forhold og interaktioner med brugerne.

Visure er et glimrende eksempel på et moderne kravstyringsværktøj, fordi det er specielt designet til at give integreret support til den komplette kravproces, herunder kravoptagelse, analyse, specifikation, validering og verifikation, sporbarhed, forvaltning og genbrug. Visure kan tilpasses fuldt ud, og det integreres med mange tredjepartsværktøjer.

Konklusion

Alle dem, der har arbejdet med et softwareprojekt, ved, hvor hurtigt krav kan samle sig, og hvor vanskeligt det kan være at styre dem. En specifikation til softwarekrav giver en omfattende beskrivelse af et softwareprodukt, der skal udvikles, og holder alle involverede på samme side. Med moderne krav til styringsværktøjer kræver det slet ikke meget arbejde at skrive en softwarekravspecifikation, og fordelene er umulige at ignorere.

Andre relaterede artikler: