Visure-løsninger


Support
Tilmeld
Login
Start gratis prøveversion

Sådan skriver du systemkravsdokumenter (SRS).

Sådan skriver du systemkravsdokumenter (SRS).

Indholdsfortegnelse

Et Software Requirement Specification Document (SRS) er et væsentligt dokument til softwareudvikling, der giver en detaljeret beskrivelse af behovene og kravene til et bestemt projekt. Den skitserer mål, omfang, baggrundsinformation, designdetaljer, implementeringsplan og andre relaterede aktiviteter. SRS-dokumentet fungerer som en kontrakt mellem kunden og udvikleren for at sikre, at begge parter forstår specifikationerne og forventningerne til det produkt, der udvikles. Derudover hjælper det med at reducere risici ved at sikre, at alle interessenter fuldt ud forstår, hvad der forventes af dem i hver fase af projektet. 

Et veludformet SRS-dokument skal være komplet, klart og kortfattet, så det nemt kan forstås af både udviklere og kunder. Desuden sikrer det at have et SRS på plads, at eventuelle ændringer eller opdateringer af produktet under udvikling nemt kan dokumenteres og spores. Dette er med til at minimere forvirring og sikrer, at slutproduktet opfylder alle de krav, der er specificeret i dokumentet. Samlet set er en SRS et kritisk værktøj for succesfulde softwareudviklingsprojekter, da det giver en klar ramme for succes. Med korrekt brug kan det hjælpe teams med at opnå kvalitetsresultater med minimal indsats.

Softwarekravspecifikation vs forretningskravspecifikation

Nogle gange blander folk koncepterne software og forretningskravspecifikationer. Faktisk er de begge ret forskellige.

Den største forskel mellem softwarekravspecifikation og forretningskravspecifikation er, at førstnævnte fanger al information relateret til softwaren, mens sidstnævnte fanger al information relateret til virksomheden.

S. Nej.
Software Requirements Specification (SRS)
Business Requirements Specification (BRS)
1.
Den specificerer de funktionelle og ikke-funktionelle krav, der er til stede i softwaren.
Det er et formelt dokument, der beskriver de forskellige krav stillet af klienten/interessenter.
2.
Det er afledt af Business Requirements Specification (BRS).
Det er afledt af kundens krav og interaktioner.
3.
Det er skabt af en systemanalytiker eller en systemarkitekt eller en forretningsanalytiker.
Det er skabt af en forretningsanalytiker.
4.
Den beskriver både de tekniske og funktionelle specifikationer af softwaren også på et højt niveau.
Den beskriver softwarens funktionelle specifikationer på et meget højt niveau.
5.
Det omhandler de ressourcer, som virksomheden stiller til rådighed.
Det handler om forretningskrav.
6.
Den beskriver, hvordan virksomheden fungerer, når softwaren eller applikationen bruges.
Det definerer kundens behov. Dokumentet bruges fra begyndelsen til slutningen af ​​projektet.
7.
Tabeller og use cases er inkluderet.
Tabeller og use cases er ikke inkluderet.

Væsentlige komponenter i en SRS

Hovedafsnittene i en softwarekravspecifikation er:

  • Forretningsdrivere – Grundene til, at kunden ønsker at bygge et system, er beskrevet i dette afsnit. Dette afsnit inkluderer yderligere de problemer, kunden står over for med det nuværende system, og de muligheder, det nye system vil give.
  • Forretningsmodel – Den forretningsmodel, som systemet skal understøtte, diskuteres i dette afsnit. Det inkluderer yderligere forskellige andre detaljer som den organisatoriske og forretningsmæssige kontekst, hovedforretningsfunktioner og procesflowdiagrammer for systemet.
  • Funktions- og systemkrav – Dette afsnit beskriver typisk krav, der er organiseret i en hierarkisk struktur. Funktionskravene er på øverste niveau, og de detaljerede systemkrav er angivet som underpunkter.
  • Systembrugssager – Dette afsnit består af et Unified Modeling Language (UML) use case-diagram, der forklarer alle de eksterne nøgleenheder, der vil interagere med systemet, og de forskellige use cases, de skal udføre.
  • Tekniske krav – Dette afsnit diskuterer alle de ikke-funktionelle krav, der udgør det tekniske miljø, og de tekniske begrænsninger, som softwaren vil fungere under.  
  • Systemkvaliteter – I dette afsnit er systemets mange kvaliteter defineret, såsom pålidelighed, servicevenlighed, sikkerhed, skalerbarhed, tilgængelighed og vedligeholdelse.
  • Begrænsninger og forudsætninger – Alle de begrænsninger, der er pålagt systemdesignet fra kundens synspunkt, er beskrevet i dette afsnit. De forskellige antagelser fra ingeniørteamet om, hvad de kan forvente under udviklingen, diskuteres også her.
  • Acceptanskriterier – Nærmere oplysninger om alle de betingelser, der skal være opfyldt, før systemet overdrages til de endelige kunder, er beskrevet i dette afsnit.

Struktur af en SRS

1. Introduktion -

Introduktionen forklarer SRS-betydningen generelt, dens omfang for dit team og dets struktur.

1.1. Formål

Forklar her SRS-softwaredokumentationens formål og struktur: de typer krav, der vil blive behandlet, samt det personale, der vil bruge det.

Hold dette afsnit kort: 1-2 afsnit er nok.

1.2. Tilsigtet publikum

Du kan gå i dybden og forklare, hvordan interessenter og teams vil arbejde med SRS, samt deltage i udviklingen heraf. Disse er typisk produktejere, investorer, forretningsanalytikere, udviklere, nogle gange testere og driftspersonale. Hele strukturen bestemmes af din softwareudviklingstilgang og teamets organisatoriske setup.

1.3. Tilsigtet brug

Beskriv i hvilke situationer dit team vil bruge SRS. Normalt bruges det i følgende tilfælde:

  • designe og brainstorme nye funktioner
  • planlægning af projektets varighed, sprints, estimering af omkostninger
  • at vurdere risici
  • overvågning og måling af teamets succes
  • modstridende situationer, hvor involverede parter har forskellige visioner om et veludført produkt.

1.4. Anvendelsesområde

Denne del dækker produktets omfang, så du bliver nødt til at give et hurtigt overblik over systemet – dets primære formål, funktion og position. Det kan sammenlignes med, hvordan du ville forklare et produkt på et interessentmøde, bortset fra at det er tilladt at dykke dybere ned i tekniske detaljer.

Dette afsnit skal beskrive:

  • Alle typer brugere forventes at engagere sig i systemet
  • Alle væsentlige dele af arkitekturen

1.5 Definitioner og akronymer

I hele dit dokument bruger teamet ofte bestemte ord. At eliminere potentielle misforståelser, tillade nye udviklere at komme ombord og løse konfliktsituationer vil alt sammen være nemmere, hvis du opklarer betydningen af ​​disse ord.

De ovennævnte komponenter udgør en definition. Definitioner giver information om funktionen, underliggende teknologier, målpersoner, forretningsenheder (brugere, kunder, mellemmænd) og interessenter. Du kan bruge et akronym til at skrive din SRS hurtigere, hvis du vælger at gøre det. Dokumentet vil være læsbart, så længe definitionstabellen har det inkluderet.

2. Overordnet beskrivelse

I anden del beskriver du produktets vigtigste funktioner, målbrugere og systemomfang for læserne. Denne beskrivelse koncentrerer sig kun om nøglefunktioner og softwarearkitektur uden at komme ind på detaljer om tilføjelser og forbindelser.

2.1 Brugerbehov

Denne del er et spørgsmål om valg, så nogle organisationer vælger ikke at inkludere det i deres SRS-ingeniørdokumentation. Vi mener, det er bedre at liste de problemer, du vil løse med din funktionalitet lige nu. Det vil komme til nytte senere, mens du brainstormer og overvåger funktioner. Du kan gå tilbage til denne sektion når som helst under produktudviklingsprocessen og se, om brugeroplevelsesteamet ikke er kommet væk fra den tilsigtede vej.

Behov refererer til problemer, som brugere vil være i stand til at løse med systemet. Du kan opdele disse behov i underkategorier, hvis du har med en meget segmenteret målgruppe at gøre. Prøv ikke at gå i detaljer om hver enkelt brugers behov. Du skal give lidt plads til fortolkning, bare hvis et problem skulle vise sig at være mere væsentligt, end du først troede.

2.2 Antagelser og afhængigheder

Antagelser er teamets antagelser om produktet og dets muligheder, som vil være korrekte i 99 % af situationerne. Det er naturligt at antage, for eksempel, at en platform, der hjælper chauffører med at navigere om natten, mest vil blive brugt i nattilstand.

Hvad er betydningen af ​​antagelser? De giver dig mulighed for at koncentrere dig om appens vigtigste funktioner først. Denne antagelse hjælper med forståelsen af, at designere skal udvikle en grænseflade, der er egnet til syn i mørke for en natkørselsassistent. Nogle brugere kan helt sikkert åbne applikationen i løbet af dagen, men det er et langt skud, så du behøver ikke at inkludere relaterede elementer i prototypen med det samme.

3. Systemfunktioner og -krav

Denne del dækker produktegenskaber og udførelseskriterier i detaljer. Fordi de to foregående afsnit omhandler produktet som helhed, finder du en mere omfattende beskrivelse her.

3.1 Funktionskrav

er angivet i en liste over funktioner, der vil blive udført i et system. Disse kriterier handler om "hvad vil blive skabt?" snarere end "hvordan" og "hvornår".

Funktionelle krav starter med at beskrive den funktionalitet, der kræves baseret på, hvor væsentlig den er for applikationen. Hvis du vil arbejde på det først, kan du begynde med design, men du bør derefter gå i udvikling. Funktionelle krav går ikke i detaljer om teknologistakke, da de kan ændre sig, efterhånden som projektet skrider frem. I stedet for at koncentrere sig om intern logik fokuserer funktionelle krav på slutbrugerfunktionalitet.

3.2 Krav til ekstern grænseflade

Funktionelle krav er en væsentlig del af en systemkravspecifikation. For at dække alle de nødvendige funktioner i systemet skal du bruge 4-5 sider med information. Nogle hold opdeler dem efter temaer for at gøre dokumentet lettere at læse.

Typisk omtales SRS-designkomponenter som adskilte fra backend- og forretningslogikken. Dette giver mening, da designere frem for udviklere håndterer størstedelen af ​​dette område, men også fordi det er her, produktudviklingsprocessen begynder.

Afhængigt af projektet kan eksterne grænsefladekrav bestå af fire typer:

  • Brugergrænseflade
  • Software interface
  • Hardware -interface
  • Kommunikationsgrænseflade

Eksterne grænsefladekrav beskriver sideelementerne, der vil være synlige for slutklienten. De kan inkludere listen over sider, designelementer, centrale stilistiske temaer, endda kunstneriske elementer og mere, hvis de er væsentlige for produktet.

3.3 Systemkrav

Produktets systemkrav angiver under hvilke betingelser det må bruges. De vedrører normalt hardwarespecifikationer og funktioner. SRS-hardwarekrav er ofte defineret af minimale og maksimale intervaller samt en optimal produktydelsestærskel.

At skabe systemkrav, før man begynder at skabe et produkt, kan virke svært, men det er vigtigt. Udviklere skal overholde hardwarekravene, så de ikke skal genstarte projektet senere. Mobile apps (med mange variabler at overveje) og applikationer, der har brug for høj reaktivitet (spil, ethvert produkt med VR/AR eller IoT) er særligt sårbare.

3.4 Ikke-funktionelle krav 

For mange organisationer er denne del af en SRS den sværeste. Hvis funktionelle krav omhandler spørgsmålet om, hvad der skal oprettes, definerer ikke-funktionelle standarder hvordan. De fastlægger kriterierne efter, hvor effektivt systemet skal fungere. Tærskler for ydeevne, sikkerhed og brugervenlighed er alle inkluderet i dette område.

Den reelle værdi er det, der gør det svært at definere ikke-funktionelle krav. Det er vanskeligt at definere sådanne sætninger som "samtidig" eller "portabilitet", da de kan have forskellige fortolkninger for alle involverede parter. Som følge heraf anbefaler vi at give hvert ikke-funktionelt krav en score. Du kan til enhver tid gense dine projektkrav for at se, om det nuværende system lever op til de oprindelige forventninger.

Hvilke fejl bør undgås, når man laver en systemkravspecifikation?

Efterhånden som dine færdigheder i SRS-udvikling øges, vil processen blive fremskyndet. Ikke desto mindre, når du lige er begyndt, er det klogt at have en liste over typiske bommerter ved hånden som reference. Til det formål skal du overveje disse:  

  • Forsømmer at inkorporere en omfattende ordliste: Indeholder din SRS jargon, som kun folk inden for branchen er bekendt med? Hvis det er tilfældet, skal du oprette en letforståelig ordbogssektion og inkludere definitioner af ord eller udtryk, der ikke er almindeligt kendte. Dette vil hjælpe med at sikre, at alle brugere kan forstå både dokumentets formål og terminologi.
  • At skabe uorden ved at kombinere ideer: Strukturer dit dokument på en overskuelig måde, og sørg for at levere information til læserne i en logisk progression. For at forhindre enhver misforståelse eller forvirring, lad være med at blande begreber sammen i hele teksten.
  • Uvidenhed om målgruppens behov og ønsker: For at forstå det forventede output fra software, er det vigtigt at skelne, hvem der vil bruge det, samt hvilke resultater der forventes. Lad os f.eks. sige, at en app blev oprettet til rapportoprettelse. Nogle af dens krav skal indebære, hvordan brugere kan trykke på bestemte knapper for at få forskellige dokumenter. For virkelig at forstå, hvad der kræves af dette rapporteringsprogram og også genkende, hvem der skal bruge det, bør du have indsigt i både brugeren og deres forventninger med hensyn til funktionalitet.  
  • At være tvetydig: Sørg for, at dine behov er utvetydige. En SRS er formuleret for at undgå misforståelser, og derfor er det vigtigt at sikre, at dokumentet ikke skaber forvirring. For hver funktion eller tilstandsbeskrivelse skal du sikre dig, at du ikke inkluderer funktioner, der ikke er blevet specificeret endnu.

Bedste praksis for at skrive SRS-dokumenter

At skrive et SRS-dokument (System Requirement Specification) er et afgørende aspekt af softwareudvikling, og overholdelse af bedste praksis kan forbedre kvaliteten og effektiviteten af ​​dokumentet betydeligt. Her er nogle bedste fremgangsmåder til at skrive SRS-dokumenter:

  • Brug klart og præcist sprog:
    • Undgå teknisk jargon og akronymer, der måske ikke er universelt forstået. Brug sprog, der er klart og ligetil, så du sikrer, at alle interessenter nemt kan forstå indholdet.
  • Inkluder visuelle hjælpemidler:
    • Forbedre forståelsen ved at inkorporere diagrammer, flowcharts og mock-ups sammen med tekstmæssige beskrivelser af krav. Visuelle hjælpemidler kan give en mere intuitiv repræsentation af komplekse begreber og systemadfærd.
  • Prioritér krav:
    • Definer tydeligt prioriteringen af ​​hvert krav. Brug etiketter som "must-have", "should-have" og "nice-to-have" for at angive den relative betydning af forskellige funktioner. Prioritering hjælper udviklingsteamet med at fokusere på kritisk funktionalitet først.
  • Hold det opdateret:
    • Oprethold versionskontrol for SRS-dokumentet. Opdater regelmæssigt dokumentet for at afspejle eventuelle ændringer i projektkrav, omfang eller feedback fra interessenter. Hold en klar ændringslog for at spore ændringer over tid.
  • Involver interessenter:
    • Samarbejd tæt med alle relevante interessenter gennem hele SRS-udviklingsprocessen. Deltag i diskussioner, indsaml feedback og sørg for, at deres behov og forventninger er fanget præcist i dokumentet. Denne involvering fremmer en fælles forståelse af projektets mål.
  • Vær omfattende:
    • Efterlad ikke plads til fortolkning eller antagelser. Giv detaljerede og omfattende beskrivelser af hvert krav, herunder funktionelle og ikke-funktionelle aspekter. Uklarhed i krav kan føre til misforståelser og projektforsinkelser.
  • Brug et struktureret format:
    • Organiser SRS-dokumentet i veldefinerede sektioner, såsom introduktion, interessentkrav, systemarkitektur, funktionelle krav, ikke-funktionelle krav, begrænsninger, antagelser, afhængigheder og en sporbarhedsmatrix. Et struktureret format gør det nemmere for læserne at finde specifik information.
  • Sikre testbarhed:
    • Skriv krav på en måde, der letter test og validering. Hvert krav bør være verificerbart, hvilket giver testere mulighed for at oprette testcases, der validerer, om systemet opfylder de specificerede kriterier. Klare acceptkriterier for hvert krav er afgørende.
  • Undgå tvetydighed:
    • Vær opmærksom på at fjerne tvetydighed i kravene. Brug præcist sprog, undgå vage udtryk, og sørg for, at der ikke er plads til flere fortolkninger af et krav. Uklarheder kan føre til misforståelser og projektomarbejdelse.
  • Overvej fremtidig skalerbarhed:
    • Tænk på den langsigtede skalerbarhed af softwaresystemet. Foregribe potentielle fremtidige behov og sikre, at SRS-dokumentet imødekommer dem. Denne proaktive tilgang kan spare tid og ressourcer i fremtiden.
  • Gennemgå og valider:
    • Foretag grundige gennemgange af SRS-dokumentet med interessenter, herunder klienten, udviklingsteamet og emneeksperter. Håndter eventuelle uoverensstemmelser, uoverensstemmelser eller uklarheder, der opstår under gennemgangsprocessen. Validering sikrer, at dokumentet nøjagtigt repræsenterer projektets mål.
  • Få formel godkendelse:
    • Efter færdiggørelse af SRS-dokumentet, indhent formel godkendelse og underskrivelse fra klienten eller projektsponsoren. Dette formaliserer aftalen om projektets omfang og krav, hvilket giver et klart grundlag for udvikling.

Inkorporering af disse bedste praksisser i processen med at skrive SRS-dokumenter kan bidrage til succes for softwareudviklingsprojekter. Et veludformet SRS-dokument fungerer som en pålidelig guide for både udviklingsteamet og interessenter, der hjælper med at sikre, at det endelige softwaresystem stemmer overens med forventninger og krav.

Konklusion

At skrive et effektivt SRS-dokument (System Requirement Specification) er et kritisk trin i softwareudviklingsprocessen. Det tjener som grundlag for vellykket projektplanlægning, udvikling, test og validering. Ved at følge de trin, der er skitseret i denne artikel og overholde bedste praksis, kan du oprette SRS-dokumenter, der fungerer som en pålidelig guide til at bygge softwaresystemer, der opfylder interessenternes behov og forventninger.

Glem ikke at dele dette opslag!

Top

Strømlining af kravstyring og validering

Juli 11th, 2024

10:4 EST | 7 CET | XNUMX PST

Louis Arduin

Louis Arduin

Seniorkonsulent, Visure Solutions

Thomas Dirsch

Senior softwarekvalitetskonsulent, Razorcat Development GmbH

En integreret tilgang med Visure Solutions og Razorcat-udvikling TESSY

Lær, hvordan du strømliner kravstyring og validering for de bedste resultater.