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

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

Dokument för specifikation av programvarukrav kan hjälpa projektledare, produktchefer och affärsanalytiker att dela upp övergripande koncept i punkter att göra som varje teammedlem kan följa under utvecklingsprocessen. I den här guiden tar vi upp vad ett SRS-dokument är, vad som ska ingå, hur du skriver ett steg för steg och bästa praxis för att säkerställa att ditt team arbetar mot samma mål.

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

Ett SRS-dokument (software requirement specification) är en detaljerad beskrivning av hur en programvaruprodukt ska fungera och hur ditt utvecklingsteam ska bygga den. Det listar krav, förväntningar, design och standarder för ett framtida projekt, inklusive:

• Business-krav: De övergripande målen som styr projektets syfte

• Slutanvändarkrav: målgruppens behov och förväntningar

• Tekniska specifikationer: Produktens funktionalitet beskrivs i tekniska termer

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 hen ska uppfylla 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 du behöva lägga mer tid och pengar än väntat på att försöka få programvaran att matcha det du hade i åtanke. Ett SRS-dokument hjälper dig att undvika detta genom att tillhandahålla en central referenskälla för hela ditt team.

De främsta fördelarna med att använda ett SRS-dokument är:

• Samordning mellan team: Alla arbetar utifrån samma krav, från marknadsföring till underhåll

• Tydlig kommunikation: Intressenter har en central referenspunkt under hela utvecklingsprocessen

• Ändringsspårning: När produktiterationer sker kan alla parter verifiera uppdateringar i dokumentet för att undvika förvirring

Om ditt team fortfarande definierar det bredare affärssammanhanget bakom er programvara kan du kombinera ditt SRS-dokument 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

En grundläggande SRS-dokumentöversikt innehåller 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 projektet i stort. 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. Ange fördelarna, målsättningarna och målen som är avsedda för produkten.

• Produktvärde: Varför är din produkt viktig? Hur kommer den att hjälpa din avsedda målgrupp? Vilken funktion kommer den att ha, eller vilket problem kommer den att lösa?

• Avsedd målgrupp: Beskriv din idealiska målgrupp. De kommer att avgöra 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.

• Definitioner och akronymer: Varje bransch eller Business har sina egna unika akronymer eller sin egen jargong. Ange definitionerna av de termer du använder i ditt 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 troligen 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 introduktion är tydlig och kortfattad. Kom ihåg att din introduktion kommer att vägleda resten av SRS-utkastet, och du vill att den ska tolkas på samma sätt av alla som använder dokumentet.

2. Systemkrav och funktionskrav

När du har din introduktion är det dags att bli mer specifik. Funktionella krav delar upp systemfunktioner och funktioner som gör att ditt system kan fungera 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. Några av de vanligaste funktionella kraven är:

• Om/så-beteenden

• Logik för datahantering

• Systemarbetsflöden

• Transaktionshantering

• Administrativa funktioner

• Regulatoriska och efterlevnadsrelaterade behov

• Prestandakrav

• Detaljer om de å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 fler detaljer du inkluderar i ditt SRS-dokument, desto mindre felsökning behöver du göra senare.

När du går in på detaljerna i kraven ä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 har tydliga, uppdaterade instruktioner.

3. Krav på externa gränssnitt

Krav på externa gränssnitt är typer av funktionskrav som säkerställer att systemet kommer att kommunicera korrekt med externa komponenter, till exempel:

• Användargränssnitt: Nyckeln till applikationens användbarhet, vilket bland annat omfattar innehållspresentation, applikationsnavigering och användarassistans.

• Hårdvarugränssnitt: Egenskaperna hos varje gränssnitt mellan systemets programvaru- och hårdvarukomponenter, såsom enhetstyper som stöds och kommunikationsprotokoll.

• 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-postmeddelanden eller inbäddade formulär.

Inbyggda system förlitar sig på krav på externa gränssnitt. 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 (NFR)

Det sista avsnittet i ditt SRS 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 ditt system ska implementera dessa funktioner.

Även om ett system fortfarande kan fungera om du inte uppfyller NFR:er kan du riskera att inte uppfylla användarnas eller intressenternas förväntningar. Dessa krav håller de funktionella kraven i schack, så de omfattar fortfarande egenskaper som produktens prisvärdhet och användarvänlighet.

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

• Säkerhet: Vad behö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 möta ökade volymkrav.

• Kompatibilitet: Minimikraven för hårdvara för din programvara, såsom stöd för operativsystem och deras versioner.

• Tillförlitlighet och tillgänglighet: hur ofta du förväntar dig att användare ska använda din programvara och vad den kritiska feltiden är vid normal användning.

• Skalbarhet: De högsta arbetsbelastningarna under vilka ditt system fortfarande kommer att fungera som förväntat.

• Underhållsmässighet: 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, ofta validerat genom användbarhetstestning.

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

Hur man skriver ett SRS-dokument

Att veta vad som ska ingå i ett SRS är det första steget. Nästa steg är att sätta ihop det hela. Genom att följa en tydlig process ser du till att du inte missar några viktiga detaljer och att alla intressenter är överens redan från början.

Här är en enkel, stegvis metod för att skriva ett effektivt SRS-dokument:

1. Skapa en översikt. Skapa en struktur för dokumentet innan du börjar skriva. Du kan använda vår mall för dokument för programvarukrav som utgångspunkt för att se till att alla viktiga avsnitt är redo.

2. Definiera produktens syfte och omfattning. Samarbeta med intressenterna för att tydligt ange vad produkten är till för, vem som kommer att använda den och vilket Business-värde den kommer att ge. Den här informationen kommer att utgöra kärnan i din introduktion.

3. Samla in krav från alla intressenter. Intervjua slutanvändare, Business-ledare och utvecklingsteamet för att förstå deras behov och förväntningar. Det hjälper till att säkerställa att slutprodukten löser rätt problem för rätt personer.

4. Detaljera de funktionella och icke-funktionella kraven. Det här är den mest detaljerade delen av dokumentet. Beskriv tydligt vad systemet måste göra (funktionellt) och de kvalitetsstandarder som det måste uppfylla (icke-funktionellt), såsom prestanda och säkerhet.

5. Få feedback och godkännanden. Dela utkastet med alla intressenter för granskning. Ett register över intressenter hjälper till att säkerställa att ingen viktig granskare glöms bort. En formell granskningsprocess hjälper till att identifiera eventuella oklarheter eller meningsskiljaktigheter tidigt, vilket sparar tid och resurser senare.

Dokumentmall för programvarukrav

Är du redo att starta ditt eget programvaruutvecklingsföretag? Under projektinitieringen kommer ditt SRS att ligga till grund för utvecklingen. Vår SRS-mall beskriver alla fyra huvudsakliga delarna i ett bra SRS-dokument och ger dig och ditt team värdefulla insikter om produkten ni ska utveckla. Kom ihåg att dina krav ska vara detaljerade, tydliga och koncisa så att alla parter har samma vision.

Bästa praxis för att skriva ett SRS-dokument

Syftet med ett SRS ä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 ditt SRS tjänar sitt syfte.

Berika ditt SRS med visuellt innehåll

Att inkludera visuella hjälpmedel 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 användbarhet.

En teknik att prova när du brainstormar om ditt projekt är mind mapping, som organiserar idéer, funktioner och scenarier och drar kopplingarna mellan dem. Skapa en tankekarta för att strukturera dina tankar när du sätter ihop dina idéer. Fokusera på programvarans viktigaste funktioner och hur de är kopplade till varandra. De detaljerade specifikationerna kommer senare i din SRS.

Gör det tydligt och kortfattat

Det sista du vill är att dina utvecklare ska behöva gissa sig fram när de skapar din produkt. Försök att inte lämna utrymme för teammedlemmar att vara kreativa och fylla i tomrummen. Inkludera så många detaljer 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 "/", som kan tolkas som "och" eller "eller"

• Använda komplicerade gränsvärden

• Använda dubbla och tredubbla negationer

En formell kollegial granskning är ett bra sätt att identifiera tvetydigheter i ditt SRS-dokument. Planera att gå igenom det med varje deltagare för att jämföra deras förståelse av kraven och göra de nödvändiga ändringarna.

Var medveten om din slutanvändare

Lägg till din fältundersökning och dina användarintervjuer i SRS för att få en tydlig förståelse för dina slutanvändares krav, förväntningar och behov. Ta hänsyn till alla möjliga scenarier och nyanser, eftersom dina utvecklare kommer att implementera exakt det som ingår i dokumentet, varken mer eller mindre.

Inkludera en flexibilitetsmarginal

Ditt SRS är ett levande dokument, vilket innebär att du lägger till nya funktioner och ändringar vid varje iteration. Ta hänsyn till det genom att hålla kraven flexibla om resultatet inte skulle uppfylla dina förväntningar.

Effektiv kravhantering innebär att du håller ett register över alla ändringar för att undvika missförstånd. Deltagarna bör kunna spåra varje krav till dess ursprung och se vem som gjorde ändringen, när och varför.

Använd programvarukravdokument för att tydliggöra din vision

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

Är du redo att skapa klarhet i ditt nästa programvaruprojekt? Kom igång med Asana för att hantera ditt SRS tillsammans med dina projektuppgifter, så att hela teamet kan hålla sig samordnat från krav till lansering.

Vanliga frågor om programvarukravdokument