5 min att läsa

Hur man gör ett SRS-dokument?

Affärsanalys

Guide

IT-konsulttjänster

I den här artikeln försöker vi förklara varför mjukvaruutvecklingsspecifikationen är så viktig och varför du bör ägna dig åt det.

Vad är en Software Requirements Specification (SRS)?

En SRS är ett dokument som definierar affärsmålen och programvarans funktionalitet. Eftersom det definierar hur programvara ska fungera enligt användarens eller företagets krav är det av största vikt att veta hur man gör SRS av ett projekt. Ett SRS-dokument innehåller dock inte bara funktionella krav utan också icke-funktionella, vilket är UI-design, prestanda och säkerhet. För att göra en lång historia kort är detta dokument en vägledning för alla utvecklare, testare och andra teammedlemmar i varje skede av utformningen och utvecklingen av programvaran. Med andra ord är det obligatoriskt att veta vad ett konventionellt SRS-dokument ska innehålla.

Skäl för att göra ett SRS-dokument

Inledningsvis skapas SRS-dokumenten för att ange framtida appmål och hur mycket arbete som ska utföras av programvaruleverantören. Så en detaljerad översikt gör det möjligt för utvecklarna att inse hur de kan implementera och bygga programvaran. Efteråt hjälper spec dig att verifiera programvaran som de utvecklat och kontrollera om den har alla nödvändiga funktioner implementerade. Att utarbeta ett bra SRS-dokument är vad du bör börja med redan innan själva utvecklingen. Det kan finnas fall då den skapade programvaran inte uppfyller de nödvändiga kraven, och där spec spelar in, eftersom det är källan för referens för utvecklarna, och efter att ha studerat SRS kan de fortsätta arbeta med programvaran för att uppfylla de befintliga kraven.

Att skapa en förstklassig teknisk specifikation är således det första viktigaste steget i alla projekt, och det måste förstås både av de som ansvarar för mjukvaruutveckling och av programvaruägarna. SRS-dokumentet vägleder teamet när de utformar och utvecklar programvaran. Så om du ger en fullständig och entydig spec så finns det en stor chans för dig att ägna mindre tid eller kanske till och med ingen tid att fixa, omdefiniera och implementera din programvara. Ju tidigare problemet upptäcks desto mer effektivt kan du allokera tiden eftersom uppdatering av en spec innan du börjar utvecklingen är enklare snarare än den funktionalitet som redan finns. Vanligtvis är en teknisk specifikation resultatet av kundens och utvecklingsteamets första konversation, eftersom den används som referens för att uppskatta tid och kostnader för projektet. Och som ursprungligen ett SRS-dokument är tänkt att ge en detaljerad beskrivning av den kommande programvaran, är det mycket snabbare och lättare att genomföra den exakta uppskattningen av projektet.

Plus, som att bygga en app är en pågående process, människorna på projektet förändras nästan hela tiden. Så när projektet överlämnas till en annan del av teamet kommer specifikationen att vara absolut oumbärlig. Är det inte en bra anledning att sitta ner och göra en SRS?

En hög nivå spec innebär också att det blir lättare att uppdatera programvaruprodukten. SRS måste uppdateras varje gång det sker en ändring och i det här fallet bör alla medlemmar vara engagerade i omprövningen av framtida förändringar.

Så som vi sa tidigare är det helt ett måste att göra ett SRS-dokument av hög kvalitet.

Hur skriver jag ett bra SRS-dokument? Här pratar vi om de viktigaste reglerna man bör följa när man skriver en spec.

Huvudregler

1. Endast en person ska skriva spec. Självklart finns det många medlemmar i laget som bidrar med sina otroliga tankar till detta dokument, men det borde bara vara en person som kommer att samla alla ideer till ett solidt förslag.

2. SRS är inte en slags manual. Naturligtvis innehåller en SRS något som inte existerar ännu, men det innebär inte att du måste beskriva varje enskild detalj. Dyk inte djupt i alla små saker, inkludera bara de som är riktigt betydelsefulla.

3. Låt inte ditt skrivande låta tråkigt. När du förstår att informationen du skrev är tråkig, är det liten chans att någon annan gärna läser den.

4. Försök inte avsluta det till varje pris. Det är helt bra om du borstar åt sidan i vissa delar som TBD. Om du bara informera läsarna att detta är vad som ska göras och se till att du avslutat alla tankar innan go-live.

5. Tänk på att det inte kommer att finnas någon andra version. Vissa människor gör ett vanligt misstag när de börjar tänka att det finns en chans att föreslå en kortsiktig lösning eftersom det snart kommer att skrivas om. Tyvärr är det mycket osannolikt eftersom systemen sällan ersätts, de är vanligtvis bara fixade och expanderade med tiden. Du kan ringa ut några komponenter och processer som senare kan förbättras, men glöm inte att de viktigaste designbesluten kommer att pågå länge.

Hur skriver man ett SRS-dokument steg för steg?

1. Inledning

De säger att väl börjat är hälften gjort, så om du skriver en trevlig introduktion kommer du att vara halvvägs till framgång. För det första måste du definiera ditt produktmål. Introduktionen ger en sammanfattning av hela dokumentet, det specificerar projektets IDE, och det är en viktig del av programvaruspecifikationen.

Innan du börjar bygga appen måste du vara medveten om marknadssituationen i den nisch som du planerar att uppta, plus glöm inte att undersöka konkurrensnivån, eftersom olika faktorer inklusive ovan nämnda kan påverka kraven. Dina läsare kommer sannolikt att vara nuvarande och framtida experter som hanterar dina uppgifter och de behöver förstå företagsmiljön. När affärssammanhanget är uppenbart kan du definiera de högsta prioriteringarna och ordna mjukvaruutvecklingsprocessen.

En annan punkt som oftast listas i introduktionsavsnittet är mängden arbete på det kommande projektet. Här ska du prata om produktspecifikationerna: dess fördelar, unika egenskaper, mål och så vidare. Det är viktigt att göra en korrekt projektuppskattning och att göra ett samarbete med din tjänsteleverantör produktivt.

En annan viktig punkt som ska nämnas i inledningen är din målgrupp: vem som ska använda denna programvara, vad deras förväntningar och preferenser är. En bra ide skulle vara att tänka på begränsad åtkomst för vissa kluster av användare, de enheter som dina användare kommer att använda och deras plats.

Om du vill kan du också inkludera avsnittet förkortningar och definitioner för att undvika förvirring, så det är helt upp till dig. Vanligtvis tjänar det utvecklarna ett bra jobb när appen är avsedd för ett visst område som sjukvård eller bil.

2. En allmän översikt över systemet

Kom ihåg: när du skriver bör din grundläggande princip vara den allmänna till specifika principen. Så innan du hoppar direkt till produktens tekniska specifikationer måste du definitivt ge den allmänna översikten. En bra start är att nämna om det är någon ny app eller en aktuell app som behöver ändras.

Efteråt bör huvudgränssnitt och strukturelement nämnas, använd gärna visuellt innehåll för att stödja dina ord och hjälpa dina läsare.

Då kan du växla till lägen och tillstånd för det kommande systemet, allmänna krav, vad det ska kunna göra och vad är dess begränsningar, det finns inget behov av en grundlig beskrivning här eftersom du kommer tillbaka till denna punkt senare i ditt dokument.

Var noga med att inkludera gissningar och beroenden (de element som kan påverka faktumet av hur relevant denna variant av SRS är). Du bör nämna dem för att minska potentiella faror. Sist men inte minst är driftscenarier, vilket innebär hur elementen i systemet är engagerade med varandra, med miljön och med användaren. Ett bra sätt att visa sin interaktion är att skapa en kedja av händelser som inträffar med användaren.

3. Systemfunktioner, villkor och begränsningar

Denna del är av yttersta vikt, så se till att beskriva elementen här noggrant, eftersom det är avsnittet som hjälper utvecklare, designers och andra teammedlemmar att förstå dina tankar och krav.

Här beskriver vi de krav som kan delas in i två grupper: icke-funktionella och funktionella. Den första kan vara ganska lika för en rad branscher. De beskriver systemets prestanda och huvudkomponenten här är affärsbehovsdokumentet som innehåller slutanvändarnas förväntningar och behov.

Den andra typen av krav beskriver systemets beteende, med andra ord vad det förväntas göra i olika fall.

Gå sedan till de logiska datakraven. Om du har problem med att skriva den här delen, tänk på databehandlingen inom systemet, dess typ, hur den är ordnad och länkad. Att skapa en visuell modell är bara en bra väg ut.

4. Systemgränssnitt

Det finns sådana typer av gränssnitt som interna och externa gränssnitt. Här ska du klargöra hur systemkomponenterna (befintliga, på implementeringsstadiet och framtiden) är beroende av varandra. Kom ihåg att ta hänsyn till både de personer som kommer att använda ditt system och andra appar som ska fungera med systemet.

5. RTM

RTM (Requirements Traceability Matrix) är ett specialinstrument som låter dig kontrollera att alla krav för testning är uppfyllda. Detta avsnitt av SRS garanterar att utvecklingsprocessen är smidig. Kravspårningsmatrisen i sig är en tabell som innehåller alla objekt från det tekniska dokumentet och önskemål om ändringar.

Hur detta dokument ser ut beror på företaget som gör det.

6. Referenser

Glöm inte att inkludera det här avsnittet, även om det kan tyckas lite konstigt att ge referenser. Det är väldigt enkelt: lägg bara till länkarna till alla nödvändiga dokument, till deras datum, författare plus dina egna kommentarer.

7. Andra valfria avsnitt

De avsnitt som du också kan behöva i ditt SRS-dokument är: 1) ordlista (om du har för många akronymer, för att sätta dem alla i "Introduktion");2) Versionshistorik (om ditt projekt fortsätter under ganska lång tid är det troligt att det kommer att finnas ett par SRS-dokumentversioner, så du kanske vill lägga alla versioner i en enda tabell); 3) bilagor (om det finns information som du inte lyckades inkludera i andra avsnitt kan du lägga den i bilagor).

Sammanfattning

Så snart du bestämmer dig för att starta din mjukvaruutveckling (webbplats, en mobil app, osv.), se till att ditt första steg är att göra en SRS av hög kvalitet. Din spec bör skrivas till förmån för framtida kunder i din programvara och mjukvaruutvecklingsteamet, så SRS måste vara tydlig och korrekt. Ägna tid och ansträngning för att göra upp en fin spec kommer att resultera i att bygga den programvara som din kund behöver och förväntar sig.

Om du har problem när du skriver din egen SRS, sök oss så hjälper vi dig gärna.

Tack för ditt betyg!

Tack för din kommentar!

Dmitry Nazarevich CTO

Datum: 13 januari 2020

Innehållsförteckning

Betygsätt den här artikeln:

★★★★★ 4/5

4,9/5 (42 recensioner)

Relaterat innehåll

Blogg

Den ultimata guiden till de bästa CMS-plattformarna för e-handel 2024

Blogg

Liten täckning Utvecklingstrender för programvara 2024

Kodning av framtiden: 14 trender inom mjukvaruutveckling som du inte kan ignorera 2024

Blogg

Dataanalysens roll i revolutioneringen av försäkringsbranschen

Blogg

Varför anställa juniora mjukvaruutvecklare för dina projekt

Blogg

Brytande gränser Innowise rankas bland de 100 snabbast växande företagen för 2023

Bryta gränser: Innowise rankas bland de 100 snabbast växande företagen för 2023

Blogg

IAOP's lista över de 100 bästa globala outsourcingföretagen 2023

Innowise finns med på IAOP:s lista över de 100 bästa outsourcingföretagen i världen 2023.

Blogg

Varför ditt projekt sannolikt kommer att misslyckas utan BA

Varför ditt projekt sannolikt kommer att misslyckas utan en BA-specialist

Blogg

GoodFirms: Innowise - expert på att leverera avancerade tekniska lösningar med hög komplexitet

Blogg

Varför IT-projekt misslyckas

Blogg

Programvaruutveckling för nystartade företag

Mjukvaruutveckling för startups: entreprenörsguide

Blogg

Upptäcktsfasen i programvaruutvecklingen

Upptäcktsfasen i programvaruutveckling: hur den sparar tid och pengar

Blogg

Allt du bör veta om SDLC: faser, fördelar med mera

Har du en utmaning för oss?

Namn

Företag

E-post

Telefon

Meddelande Vänligen inkludera projektinformation, varaktighet, teknologistack, IT-proffs som behövs och annan relevant information

Spela in ett röstmeddelande om ditt projekt för att hjälpa oss att förstå det bättre

Bifoga ytterligare dokument vid behov

Ladda upp filen

Du kan bifoga upp till 1 fil på totalt 2 MB. Giltiga filer: pdf, jpg, jpeg, png

Observera att när du klickar på knappen Skicka kommer Innowise att behandla dina personuppgifter i enlighet med vår Integritetspolicy för att ge dig lämplig information.

Vad händer härnäst?

Efter att ha mottagit och behandlat din begäran kommer vi att återkomma till dig inom kort för att specificera dina projektbehov och underteckna en NDA för att säkerställa konfidentialitet av information.

Efter att ha undersökt kraven utarbetar våra analytiker och utvecklare en projektförslag med arbetets omfattning, lagets storlek, tid och kostnad uppskattningar.

Vi ordnar ett möte med dig för att diskutera erbjudandet och komma överens.

Vi skriver på ett kontrakt och börjar arbeta med ditt projekt så snabbt som möjligt.