6 steg för att skriva ett SRS-dokument som fungerar + Mall
programvaruspecifikationsdokument ses ibland som artefakter som bara är meningsfulla för utvecklare. Ett SRS-dokument kan dock gå längre och bli en guide för marknadsföringsspecialister, intressenter, designteam och till och med användare.
den här artikeln kommer att förklara varför programvarudokumentation är viktig och hur du skriver ditt SRS-dokument för att göra det till en praktisk guide för alla teamspecialister.
Vad är ett SRS-dokument och varför spelar det någon roll?
ett SRS-dokument (software requirement specification) är en artefakt som innehåller krav, förväntningar och standarder för en framtida produkt. Det kan omfatta textdokument, kalkylblad, scheman, prejudikat och andra element som klargör produktens vision. Med andra ord ger ett SRS-dokument en detaljerad beskrivning av hur en produkt ska fungera och hur produktutvecklingsteamet ska implementera den.
Föreställ dig det som att bygga ett fartyg. Du har en vision av masten eller seglet, och du kan till och med föreställa dig hur den färdas genom vågorna. Du behöver dock strängare detaljer för att sätta fartyget på vattnet.
detsamma gäller för produktutveckling. Du kan ha en tydlig vision om en app du vill bygga med alla funktioner, designelement och knappar. En verbal beskrivning av funktioner räcker dock inte för att utvecklare ska kunna genomföra tanken.
för att resultatet ska matcha bilden i ditt huvud måste du förklara på papper exakt hur en funktion ska fungera. Ett SRS-dokument är ett utmärkt instrument för att beskriva sådana tekniska detaljer.
.jpg)
vem skriver ett SRS-dokument?
att skriva ett SRS-dokument innebär att överföra generiska beskrivningar av funktioner, uppgifter och mål till den detaljerade planen för deras tekniska implementering.
SRS-dokument skrivs vanligtvis av produkt-och projektledare eller affärsanalytiker, som direkt kommunicerar med kunder eller som gör användarforskning (som också arbetar med wireframes och vet hur produkten ska bete sig) och samlar framtida produkters krav.
under tiden detta dokument. Ett bra SRS-dokument är inte enbart tekniskt, eftersom det också täcker affärsmål, mätvärden, användarproblem, användarpersoner etc.
3 Anledningar till varför ett SRS-dokument är viktigt
så det totala värdet av ett SRS-dokument är tydligt. Här är anledningarna till att dokument för programvarukrav är viktiga:
SRS är en kommunikationspunkt
som ett levande dokument fungerar ett SRS-dokument som en kommunikationsplattform mellan alla specialister: Utvecklare, marknadsföringsspecialister och grundare.
genom att förklara detaljer i ett SRS-dokument, formellt eller informellt, är Chefer överens med kunderna om resultatens förväntningar. Under tiden, om ändringarna görs i kraven, kan en klient och/eller en produktägare kontrollera och validera dem i dokumentet. Och utvecklarna är ansvariga för att leva upp till dessa förväntningar.
slutlig beskrivning av funktioner
SRS dokumenterar de slutliga versionerna av programvara som kom från de antaganden som diskuterats med kunder tidigare. Under möten och samtal, användartester och intervjuer kan produktversionerna ändras mycket ofta. Ibland kan även produktchefer bli överväldigade av befintliga produkt iterationer. SRS-fil hjälper till att förena alla dessa krav i en standard och eliminera eventuell förvirring när det gäller produktkraven.
SRS är en Standardguide för produktutvecklare
förutom att beskriva produktkraven, vägleder SRS-dokumentet utvecklingsteamet om stegen de bör följa för att bygga en produkt som en kund vill ha.
beroende på projektets organisation kan eller kan utvecklare inte vara involverade i projektets analytiska del. I båda fallen måste de avgöra hur systemet ska fungera, definiera kraven och kodparametrarna för att passa det.
på samma sätt måste QA-proffs förstå alla tekniska aspekter som ligger bakom produktens koncept. Således fungerar SRS-dokumentation som en standard för planering och körning av QA-test.
slutligen får designers projektinsikter genom SRS-dokument för att matcha designen till användningsfallet.
6 steg för att skriva bra SRS-dokument
funktionella och icke-funktionella krav tar en stor del av alla SRS-dokument. Produktchefer tar inte bara dessa krav från ingenstans. De är resultatet av korrekt kommunikation med kunder och djupgående användar-och teknisk forskning. Här är de viktigaste stegen för att skriva utmärkt SRS-dokumentation:
Steg 1. Kommunikation med en intressent
vi tar bort det första lagret av osäkerhet genom att fråga intressenterna om deras förväntningar från produkten. Visst, en sådan intervju ger bara en liten förståelse för kraven. Detta är dock fortfarande en bra utgångspunkt för forskning.
på Uptech pratar vi först med kunden vid förköp och Kick-Off-samtal när vi försöker ta reda på om vi passar varandra. Vi försöker kristallisera de minsta detaljerna om klienten för att förstå hans/hennes ide.
ändå ger enkel kommunikation inte tillräckligt med information om produktens målgrupp och deras önskemål och behov. Så vi fortsätter med discovery-scenen för att göra det klart.
steg 2. Discovery Stage
Discovery stage är avgörande för att skriva SRS-dokumentation. I detta skede har vi möjlighet att utforska det problem som produkten ska lösa, intressen och behov. Vårt mål här är att identifiera användarnas problem och definiera hypoteser om möjliga lösningar för att hantera dem. Med ett sådant tillvägagångssätt kan vi göra appen värdefull för användaren.
Use Cases vs User Stories
all användardata blir en del av ett SRS-dokument som Use Cases och User Stories. Skillnaden mellan dessa två kategorier diskuteras allmänt bland produktutvecklingsgemenskapen.
enkelt uttryckt är användarhistorier mer fokuserade på resultatet och fördelar som en användare får när han använder en funktion. Medan användningsfall mer granulärt beskriver själva funktionen.
till exempel, efter flera användarintervjuer på Yaza-projektet, drog vi slutsatsen att appen skulle ha en chatt. Så användarberättelsen för ett sådant fall skulle låta som: ”som användare vill jag chatta med en potentiell husägare.”
under tiden skulle användningsfallet för den här historien beskriva varje steg hos en användare för att uppnå detta mål – ”som användare måste jag lägga till en kontakt i min chattlista och skicka honom/henne ett meddelande, så att…”.
steg 3. Bygg strukturen
när upptäckten är klar fortsätter vi med att skriva SRS-dokumentation. För det första behöver vi en kort struktur av dokumentet. Innehållet i ett SRS-dokument kan variera avsevärt, men den typiska SRS-dokumentationsstrukturen skulle se ut så här:
1. Inledning
introduktionen innehåller en sammanfattning av dokumentets innehåll. Det är tänkt att svara på följande frågor:
- Kort beskrivning av dokumentets innehåll;
- de avsedda läsarna av detta dokument;
- tanken på programvaran du utvecklar;
- avsedda läsare.
1.1 affärsmål
Ställ in en lista över mål du vill uppnå i projektet, som att skapa en MVP, skapa en multiplatform-mobilapp eller starta en webbplats.
Dessutom bör det här avsnittet återspegla målen och framgångsvärdena för ditt företag. Även om vissa kan utesluta denna del från dokumentet är det viktigt att ange dessa saker, eftersom de direkt påverkar forskning och utveckling.
1.3 Avsedd användning
hur tror du att en individ kommer att använda din produkt? Vilka funktioner tillhandahåller du för denna typ av användning? Beskriv alla möjliga sätt en person kan använda din produkt i vilken användarroll han / hon agerar.
1.4 Scope
den här delen beskriver omfattningen av det arbete du behöver utföra för att få din ide till liv.
1.5 definitioner och akronymer
den här kommer att lägga ut definitionerna av de termer du använder i dokumentet för att säkerställa en fullständig förståelse av användarna.
2. Övergripande beskrivning
här är den del där du förklarar appens uppfattning, var den kom ifrån och varför den kan vara intressant för användarna.
2.1 användarens behov
en mjukvara som är byggd för alla tjänar ingen. Men om du vet exakt vem din målgrupp är, var de arbetar och deras smärtor, har du större chanser att leverera en app som är allmänt antagen av användarna.
3. Systemfunktioner och krav
nu är det dags att beskriva de tekniska kraven för din framtida programvara. Beskriv de funktioner som din produkt kommer att innehålla, tillsammans med de standarder som definierar kvaliteten på dessa produkter.
3.1 funktionskrav
funktionskrav är systemspecifikationer, utan vilka programvaran inte fungerar korrekt. Definitionen du kommer att ge till dina programfunktioner kommer att avgöra hur de kommer att genomföras ytterligare.
3.2 icke-funktionella krav
medan funktionella krav definierar vad systemets funktion kommer att vara, bestämmer icke-funktionella krav hur systemet ska implementera dessa funktioner, till exempel färdigställningshastigheten.
3.3 Tech Stack
en tech stack är en pool av tekniska lösningar som används för att skapa och köra programvara eller ett projekt. Det är viktigt att ange det i SRS-dokumentet eftersom det definierar alla andra tekniska detaljer.
.jpg)
steg 4. Gör en allmän beskrivning
innan du kastar dig in i produktens detaljer, ge en allmän översikt över appens huvudfunktioner. Förklara bara appens syfte, dess funktioner och hur de löser användarens problem.
Steg 5. Definiera funktionella och icke-funktionella krav
kärnan i ditt SRS-dokument består vanligtvis av produktens funktionella och icke-funktionella krav. Med sådana specifikationer lägger du till mer detaljer i den allmänna översikten och guidar därmed teamet genom appens tekniska detaljer.
skillnaden mellan funktionella och icke-funktionella krav är en annan stickpunkt i produktutvecklingsgemenskapen. Vi har delat vår expertis om detta ämne i den här artikeln.
steg 6. Se till att klienten på samma sida
godkännande är en mycket förväntad del av utvecklingen. Klientens redigeringar kan emellertid ibland negera hela mängden arbete som slutförts vid en viss punkt i projektet.
för att undvika trycket rekommenderar vi att du godkänner små delar av färdigställd SRS-dokumentation, snarare än att skicka in ett helt paket med dokument på en gång. Detta hjälper till att lösa vissa problem snabbt och är mindre besvärligt.
experttips om att skriva bra SRS-dokumentation
det tar tid att finslipa färdigheten att skriva utmärkt SRS-dokumentation. Vi har dragit en lista med experttips om att skriva SRS-dokumentation från vår erfarenhet. Så här är några insikter som gör din SRS-dokumentation effektiv:
gör det enkelt
Detta är knappast en hemlighet, men enkla saker styr världen. Detta gäller verkligen för alla typer av dokumentation du arbetar med. Din SRS är en enhetlig beskrivning av den framtida produkten för hela ditt team. Detta innebär att språket, strukturen och formuleringarna i ditt SRS-dokument ska vara så lakoniska som möjligt.
inkludera affärsmål
även om ett SRS-dokument främst fokuserar på de tekniska egenskaperna, inklusive affärsmål är en bra praxis. Ett SRS-dokument är en instruktion för utvecklingsteamet och produktöversikten för icke-tekniska specialister relaterade till produkten. Dessutom, inklusive affärskrav, som mätvärden och syften, kommer att göra dina SRS till ett enhetligt instrument för hela laget.
Lägg till användardata
upptäcktsstadiet avslöjar vanligtvis den mest värdefulla informationen om en användare. Att lägga till denna information i SRS-dokumentet gör det till ett användbart papper för design-och utvecklingsteamet.
behandla dina SRS som ett levande dokument
SRS-dokumentet ska inte vara statiskt, även om du har sammanställt alla nödvändiga paket för ditt projekt. I agila ekosystem går projekt runt och förvärvar nya funktioner med varje passande iteration. Alla sådana ändringar och ändringar ska förmedlas i SRS-dokumentet och överenskommas med kunden.
slutsats
skriva SRS dokument tar djupgående forskning, analys och ansträngning. Ett omfattande SRS-dokument som täcker affärsegenskaper, tekniska detaljer och användardata kommer dock att löna sig med en fantastisk produkt som uppfyller både kundens och användarnas förväntningar.
Uptech har fem års erfarenhet av att bygga produkter för blomstrande startups. Vi vet hur man utforskar användarens behov och gör SRS-dokument till ett effektivt projekthanteringsinstrument snarare än en bunt dammtäckta papper.
F. A. Q.
Vad är SRS?
en SRS är ett dokument som innehåller en detaljerad beskrivning av de tekniska specifikationerna och kraven för en app eller programvara. En SRS instruerar också utvecklare om hur man implementerar produktens IDE för att matcha kundens förväntningar.
Vad är syftet med ett SRS-dokument?
syftet med ett SRS-dokument är att ge teknisk beskrivning av en produkts funktioner, tillhandahålla tekniska och icke-tekniska krav och vägleda utvecklingsteamet om implementeringen.
vem skriver SRS-dokument?
beroende på lagets sammansättning skrivs SRS-dokument vanligtvis av:
- produktchef;
- Projektledare;
- affärsanalytiker;
- teknisk ingenjör.