Så här skriver du ett dokument för programvarukrav (med mall)

Minns du när du läste 1800-talsromaner i skolan och tänkte: ”Är det ens samma språk?” Du har förmodligen haft samma tanke på kontoret när du har samarbetat med teknikintresserade AI-utvecklare eller SEO-analytiker. Om det bara fanns CliffsNotes för kollegor.

Ibland är det viktigt att avdelningar i motsatta ändar av en organisation arbetar tillsammans, även om de talar olika tekniska språk. Om du någon gång har arbetat i ett tvärfunktionellt team vet du hur svårt det kan vara att hålla alla informerade. 

Kravspecifikationer för programvara kan hjälpa projektledare, produktchefer och affärsanalytiker att bryta ner övergripande koncept till att göra-punkter som varje teammedlem kan följa under utvecklingsprocessen. 

Vad är ett dokument för programvarukravspecifikation (SRS)?

Ett dokument med programvarukravspecifikationer (SRS) listar krav, förväntningar, design och standarder för ett framtida projekt. Det inkluderar de övergripande affärskrav som definierar projektets mål, slutanvändarnas krav och behov, och produktens funktionalitet i tekniska termer. Enkelt uttryckt ger ett kravspecifikationsdokument en detaljerad beskrivning av hur en programvaruprodukt ska fungera och hur utvecklingsteamet ska få den att fungera.

Föreställ dig att du har en bra idé för en app. Du har en vision om vad du vill att den ska göra och hur du vill att den ska se ut, men du vet att du inte bara kan ge en muntlig beskrivning till en utvecklare och förvänta dig att de ska uppfylla dina förväntningar. Det är här ett kravspecifikationsdokument kommer in i bilden.

Varför använda ett kravspecifikationsdokument?

Om utvecklare inte har tydliga anvisningar när de skapar en ny produkt kan det sluta med att du spenderar mer tid och pengar än förväntat för att försöka få programvaran att matcha det du hade i åtanke. 

Att skriva ett kravspecifikationsdokument hjälper dig att få ner din idé på papper och skapa en tydlig lista över krav. Det här dokumentet blir produktens enda informationskälla, så att alla team – från marknadsföring till underhåll – är på samma sida. 

Eftersom programvarukravspecifikationer är levande dokument kan de också fungera som en kommunikationspunkt mellan alla intressenter som är involverade i produktutvecklingsprocessen. Produktiterationer kommer alltid att förekomma under ett programvaruutvecklingsprojekt. Genom att notera ändringar i kravspecifikationen kan alla parter validera dem i dokumentet. Det kommer att minska risken för förvirring kring produktkraven. 

Vad som ska ingå ingå i ett kravspecifikationsdokument

Ett grundläggande dokument för programvarukrav består av fyra delar: en inledning, system- och funktionskrav, krav på externa gränssnitt och icke-funktionella krav.

1. Inledning

En inledning till ett kravspecifikationsdokument är precis vad du förväntar dig: en översikt över projektet som helhet. När du skriver din inledning ska du beskriva syftet med produkten, den avsedda målgruppen och hur målgruppen kommer att använda den. Se till att inkludera följande i inledningen:

• Produktomfattning: omfattningen bör relatera till produktens övergripande affärsmål, vilket är särskilt viktigt om flera team eller entreprenörer kommer att ha åtkomst till dokumentet. Lista fördelarna, avsikterna och målen för produkten. 

• Produktvärde: varför är din produkt viktig? Hur kommer den att hjälpa din målgrupp? Vilken funktion kommer den att ha, eller vilket problem kommer den att lösa? Fråga dig själv hur din målgrupp kommer att uppleva värdet i produkten. 

• Avsedd målgrupp: Beskriv din idealiska målgrupp. De kommer att diktera produktens utseende och känslan den inger och hur du marknadsför den. 

• Avsedd användning: Föreställ dig hur din målgrupp kommer att använda din produkt. Lista de funktioner du tillhandahåller och alla möjliga sätt som din målgrupp kan använda din produkt på, beroende på deras roll. Det är också bästa praxis att inkludera användningsfall för att illustrera din vision.

• Definitioner och akronymer: varje bransch eller business har sina egna unika akronymer eller jargong. Definiera de termer du använder i din kravspecifikation för att säkerställa att alla parter förstår vad du försöker säga.

• Innehållsförteckning: ett grundligt kravspecifikationsdokument kommer sannolikt att vara mycket långt. Inkludera en innehållsförteckning för att hjälpa alla deltagare att hitta exakt det de letar efter. 

Se till att din inledning är tydlig och kortfattad. Kom ihåg att inledningen kommer att vara din guide till resten av kravspecifikationen, och att du vill att den ska tolkas på samma sätt av alla som använder dokumentet.

2. Systemkrav och funktionella krav

När du har skrivit inledningen är det dags att bli mer specifik. Funktionella krav beskriver systemfunktioner och funktioner som gör att systemet fungerar som avsett. 

Använd din översikt som referens för att kontrollera att dina krav uppfyller användarens grundläggande behov när du fyller i detaljerna. Det finns tusentals funktionella krav att inkludera, beroende på din produkt. Några av de vanligaste är:

• Om/då-beteenden.

• Logik för datahantering.

• Systemets arbetsflöden.

• Transaktionshantering

• Administrativa funktioner

• Reglerings- och efterlevnadsbehov

• Prestandakrav.

• detaljer om åtgärder som utförs för varje skärm.

Om det känns överväldigande kan du prova att ta ett krav i taget. Ju mer information du kan inkludera i ditt kravspecifikationsdokument, desto mindre felsökning behöver du göra senare. 

När du går in på detaljerade krav är det lika viktigt att hålla ditt stödmaterial konsekvent och lätt att följa. En mall för teknisk dokumentation kan spara tid, minska antalet fel och se till att alla – från utvecklare till slutanvändare – har tydliga och uppdaterade instruktioner.

3. Krav på externa gränssnitt

Krav på externa gränssnitt är typer av funktionella krav som säkerställer att systemet kommunicerar korrekt med externa komponenter, till exempel:

• Användargränssnitt: nyckeln till användbarheten i applikationen, vilket bland annat omfattar innehållspresentation, applikationsnavigering och användarassistans.

• Hårdvarugränssnitt: egenskaperna för varje gränssnitt mellan systemets programvara och hårdvarukomponenter, såsom enhetstyper och kommunikationsprotokoll som stöds.  

• Programvarugränssnitt: anslutningarna mellan din produkt och andra programvarukomponenter, inklusive databaser, bibliotek och operativsystem. 

• Kommunikationsgränssnitt: kraven för de kommunikationsfunktioner som din produkt kommer att använda, till exempel e-post eller inbäddade formulär. 

Inbyggda system är beroende av externa gränssnittskrav. Du bör inkludera saker som skärmlayout, knappfunktioner och en beskrivning av hur din produkt är beroende av andra system. 

4. Icke-funktionella krav

Det sista avsnittet i din specifikation av programvarukrav beskriver icke-funktionella krav. Medan funktionella krav talar om för ett system vad det ska göra, avgör icke-funktionella krav (NFR) hur systemet ska implementera dessa funktioner. Ett funktionellt krav kan till exempel vara att systemet ska skriva ut en följesedel när en kund beställer din produkt. Ett icke-funktionellt krav säkerställer att följesedeln skrivs ut på vitt papper i standardstorlek. 

Även om ett system fortfarande kan fungera om du inte uppfyller de icke-funktionella kraven riskerar du att inte uppfylla användarnas eller intressenternas förväntningar. De här kraven håller de funktionella kraven i schack, så att de fortfarande innehåller attribut såsom produktens prisvärdhet och användarvänlighet. 

De vanligaste typerna av icke-funktionella krav kallas ”Itys”. De är:

• Säkerhet: vad som krävs för att säkerställa att all känslig information som din programvara samlar in från användare är skyddad. 

• Kapacitet: produktens nuvarande och framtida lagringsbehov, inklusive en plan för hur systemet ska skalas upp för att öka volymkraven.

• Kompatibilitet: de lägsta hårdvarukraven för din programvara, till exempel stöd för operativsystem och deras versioner. 

• Tillförlitlighet och tillgänglighet: hur ofta du förväntar dig att användarna ska använda din programvara och hur lång tid det tar innan ett kritiskt fel uppstår vid normal användning. 

• Skalbarhet: den högsta arbetsbelastning som systemet fortfarande kan hantera. 

• Underhållbarhet: hur din applikation ska använda kontinuerlig integrering så att du snabbt kan distribuera funktioner och buggfixar. 

• Användbarhet: hur lätt det är att använda produkten. 

Andra vanliga typer av icke-funktionella krav inkluderar prestanda, regler och miljökrav. 

Dokumentmall för programvarukrav

Är du redo att starta ditt eget programvaruutvecklingsföretag? Vår SRS-mall beskriver de fyra viktigaste delarna i ett bra SRS-dokument, vilket ger dig och ditt team värdefulla insikter om den produkt ni ska utveckla. Kom ihåg att hålla kraven detaljerade, tydliga och koncisa, så att alla parter har samma vision i åtanke.

Bästa praxis för att skriva ett programvarukravdokument

Syftet med ett kravspecifikationsdokument är att få varje team på varje avdelning att arbeta mot ett tydligt mål. Med det sagt finns det några bästa praxis att följa för att säkerställa att din specifikation för programvarukrav tjänar sitt syfte.

Berika din kravspecifikation med visuellt innehåll

Att inkludera visuella hjälpmedel såsom diagram, scheman och modeller hjälper teammedlemmarna att förstå processen bättre. De är särskilt användbara när du illustrerar programvarans huvudfunktioner och funktionalitet. 

En teknik att prova när du brainstormar kring ditt projekt är tankekartor, som organiserar idéer, funktioner och scenarier och visar kopplingarna mellan dem. Skapa en tankekarta för att strukturera slumpmässiga tankar när du börjar sätta ihop dina idéer. Den här visualiseringen behöver inte vara superdetaljerad – det är vad din programvarukravspecifikation är till för. Fokusera istället på de viktigaste funktionerna i din programvara och hur de relaterar till varandra.

Håll det tydligt och kortfattat

Det sista du vill är att dina utvecklare ska tvivla på sig själva när de skapar din produkt. Försök att inte lämna utrymme för teammedlemmar att bli kreativa och fylla i tomrummen. Inkludera så mycket information som möjligt när du beskriver dina programvarukrav och undvik att:

• Använda vaga ord som i allmänhet eller ungefär.

• kombinera termer med ett ”/”, vilket kan tolkas som ”och” eller ”eller”

• Använda komplicerade gränsvärden.

• Använda dubbla och tredubbla negationer.

En formell granskning av kollegor är ett bra sätt att identifiera tvetydigheter i ditt kravspecifikationsdokument. Planera att gå igenom det med varje deltagare för att jämföra hans eller hennes förståelse av kraven och göra nödvändiga ändringar. 

Var medveten om din slutanvändare

Lägg till din fältundersökning och dina användarintervjuer i kravspecifikationen för att skapa en tydlig förståelse för dina slutanvändares krav, förväntningar och behov. Det bör hjälpa dig att visualisera de åtgärder som slutanvändaren kommer att utföra med programvaran. Ta hänsyn till alla möjliga scenarier och nyanser som kan uppstå och inkludera dem i din kravspecifikation. Kom ihåg att utvecklarna kommer att implementera exakt det du inkluderar i dokumentet – varken mer eller mindre. 

Inkludera en marginal för flexibilitet

Kravspecifikationen är ett levande dokument, vilket innebär att du kommer att lägga till nya funktioner och ändringar vid varje iteration. Ta hänsyn till detta genom att hålla kraven flexibla om resultatet inte uppfyller dina förväntningar. Det är också bästa praxis att föra ett register över de ändringar som görs i dokumentet för att undvika missförstånd. Deltagarna bör kunna spåra varje krav till dess ursprung och se vem som gör ändringen, när och varför. 

Använd dokument för programvarukrav för att klargöra din vision

Att skriva ett kravspecifikationsdokument är inte lätt, men det är inte heller oändlig felsökning eller att hantera argument mellan teammedlemmar. Arbetet du lägger ner på ett omfattande dokument för programvarukrav kommer att löna sig med en fantastisk produkt som du och dina intressenter kan vara stolta över.