Så här skriver man 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?” Det är troligtvis precis vad du har tänkt på kontoret när du har samarbetat med teknikintresserade AI-utvecklare eller webbkunniga SEO-analytiker. Om det bara fanns CliffsNotes för kollegor.

Ibland är det viktigt att avdelningar i en organisation som befinner sig på motsatta sidor av organisationen samarbetar – även om de talar olika tekniska språk. Om du någonsin har arbetat i ett tvärfunktionellt team vet du hur svårt det kan vara att hålla alla på samma spår. 

Dokument för programvarukravsspecifikationer kan hjälpa projektledare, produktchefer och Business-analytiker att dela upp koncept på hög nivå i punkter att göra som varje teammedlem kan följa under utvecklingsprocessen. 

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

Ett SRS-dokument listar krav, förväntningar, design och standarder för ett framtida projekt. Det inkluderar de övergripande business-kraven som dikterar projektets mål, slutanvändarnas krav och behov och produktens funktionalitet i tekniska termer. Enkelt uttryckt ger en kravspecifikation 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é till 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 resultatet ska matcha dina förväntningar. Det är här som en SRS kommer in i bilden.

Varför använda en SRS?

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

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

Eftersom programvarukravspecifikationer är levande dokument fungerar de också som en kommunikationspunkt mellan alla intressenter som är involverade i produktutvecklingsprocessen. Produktiterationer är oundvikliga i alla programvaruutvecklingsprojekt. Genom att registrera ändringar i SRS kan alla parter verifiera dem i dokumentet för att förhindra förvirring kring produktkrav.

Om ditt team fortfarande definierar det bredare affärssammanhanget bakom programvaran kan du kombinera din SRS med en mall för verksamhetskrav för att definiera mål, omfattning och framgångsvärden innan du dokumenterar de tekniska detaljerna.

Vad ett SRS-dokument bör innehålla

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

1. Inledning

En SRS-introduktion är precis vad du förväntar dig – det är en översikt över hela projektet. När du skriver din introduktion 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 din introduktion:

• 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 fylla 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, 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. Ange definitionerna av de termer du använder i din SRS för att säkerställa att alla parter förstår vad du försöker säga.

• Innehållsförteckning: Ett grundligt SRS-dokument kommer sannolikt att vara mycket långt. Inkludera en innehållsförteckning för att hjälpa alla deltagare att hitta precis det de letar efter. 

Se till att din introduktion är tydlig och kortfattad. Kom ihåg att introduktionen är din guide till resten av SRS-dokumentet och att den ska tolkas på samma sätt av alla som använder dokumentet.

2. Systemkrav och funktionskrav

När introduktionen är klar är det dags att bli mer specifik. Funktionella krav är en uppdelning av systemfunktioner som gör det möjligt för systemet att fungera som avsett. 

Använd översikten som referens för att kontrollera att kraven 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/så-beteenden

• Logik för datahantering

• Systemarbetsflöden

• Transaktionshantering

• Administrativa funktioner

• Reglerings- och efterlevnadsbehov

• Prestandakrav

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

Om det här känns överväldigande kan du försöka ta itu med ett krav i taget. Ju mer detaljer du kan inkludera i ditt SRS-dokument, 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, 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 applikationens användbarhet, som bland annat omfattar innehållspresentation, applikationsnavigering och användarhjälp.

• Hårdvarugränssnitt: egenskaperna för varje gränssnitt mellan systemets programvaru- och hårdvarukomponenter, såsom vilka 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. 

Inbäddade system förlitar sig på externa gränssnittskrav. Du bör inkludera saker som skärmlayouter, knappfunktioner och en beskrivning av hur din produkt är beroende av andra system. 

4. Icke-funktionella krav

Det sista avsnittet i din systemkravsspecifikation beskriver icke-funktionella krav. Medan funktionella krav talar om för ett system vad det ska göra, bestämmer icke-funktionella krav (NFR) hur systemet ska implementera funktionerna. Ett funktionellt krav kan till exempel säga åt ditt system att skriva ut en fraktsedel när en kund beställer din produkt. Ett icke-funktionellt krav säkerställer att fraktsedeln skrivs ut på 10 x 15 cm vitt papper, vilket är standardstorleken för fraktsedlar. 

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

De vanligaste typerna av NFR:er kallas "Itys". De är:

• Säkerhet: Vad som behövs för att säkerställa att all känslig information som programvaran 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 möta ökade volymkrav.

• 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 använder din programvara och vad den kritiska feltiden är under normal användning. 

• Skalbarhet: Den högsta arbetsbelastningen under vilken systemet fortfarande kommer att fungera som förväntat. 

• Underhåll: 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, reglerings- 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 och 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 SRS-dokument

Syftet med ett SRS är att se till att varje team på varje avdelning arbetar 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 SRS tjänar sitt syfte.

Berika din SRS med visuellt innehåll

Att inkludera visuella element som diagram, scheman och modeller hjälper teammedlemmarna att förstå processen bättre. Det är särskilt användbart när du illustrerar de viktigaste funktionerna och hur programvaran fungerar. 

En teknik att prova när du brainstormar ditt projekt är mind mapping, som organiserar idéer, funktioner och scenarier och kopplar ihop 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 bilden behöver inte vara superdetaljerad – det är vad din SRS är till för. Fokusera istället på de viktigaste funktionerna i programvaran och hur de förhåller sig till varandra.

Håll det tydligt och kortfattat

Det sista du vill är att dina utvecklare ska behöva fundera på sig själva när de konstruerar 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 är ett bra sätt att hitta tvetydigheter i ditt SRS-dokument. 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. 

Känn din slutanvändare

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

Inkludera en flexibilitetsmarginal

Din SRS ä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 det genom att hålla kraven flexibla om resultatet inte uppfyller dina förväntningar. Det är också bästa praxis att registrera ändringar som görs i dokumentet för att undvika missförstånd. Deltagarna ska kunna spåra varje krav tillbaka till originalet 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 en SRS är inte lätt, men det är inte heller oändlig felsökning eller att navigera i argument mellan dina 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.