#produktetikett
en specifikation för programvarukrav (SRS document) beskriver hur ett mjukvarusystem ska utvecklas. Enkelt uttryckt ger en SRS alla inblandade en färdplan för det projektet.
det erbjuder högkvalitativa definitioner för de funktionella och icke-funktionella specifikationerna för programvaran, och kan även innehålla användningsfall som illustrerar hur en användare skulle interagera med systemet efter avslutad.,
Obs! Låt oss hjälpa dig att skriva en specifikation för programvarukrav. Begär ett samtal med vår CTO genom att fylla i detta formulär.
Innehållsförteckning
Varför är ett SRS-dokument viktigt?
anta att du vill skapa en chattapp med ett specifikt utseende och funktionalitet och vill att den ska vara inriktad specifikt på företag. Du känner att du kan klippa ut de extra funktioner som kommersiella chattprogram använder för att vädja till allmänheten och fokusera på funktioner som företag behöver. Men du är ingen utvecklare.,
så du måste lägga ut utvecklingen av appen. Men du måste också se till att den som du anlitar för att förvandla din idé till verklighet vet exakt vad du försöker åstadkomma. Utan alla detaljer för att avsluta appen kan tid och kostnad snabbt komma ur hand. Utvecklare kan ta fel tur och måste refactor koden om den färdiga produkten inte matchar bilden du hade i huvudet.
ett SRS-dokument tvingar dig att lägga ner idén på papper för att täcka alla dessa detaljer. Du måste översätta denna idé till ett språk som utvecklare förstår., En SRS-dokument beskriver vad en klient vill och vad utvecklare kommer att ge. Det är det skriftliga avtalet om varje detalj i appen.
att ha en tydlig uppsättning krav säkerställer att ett utvecklingsteam skapar programvara som uppfyller kundernas behov. En SRS kommer att hjälpa till med att uppskatta kostnaderna för arbetet och täcka projektets omfattning. Det ger också kodare en uppfattning om den tekniska stacken de behöver och hjälper dem att planera sitt arbete, men det är inte allt:
- Designers får projektinsikter genom SRS-dokument så att de kan matcha designen till användningsfallet.,
- testare får riktlinjer för att skapa testfall som matchar företagets behov.
- slutanvändare använder SRS för att förstå programvaran.
- Det ger investerare en översikt över systemets funktioner så att de kan fatta investeringsbeslut.
en SRS är viktigt eftersom det är en enda källa till information och förväntningar, vilket förhindrar missförstånd mellan projektledare, utvecklare, designers och testare.
vad inkluderar en SRS?,
en SRS bör ha tillräckligt med information för utvecklare att slutföra den beskrivna programvaran. Det lägger inte bara ut beskrivningen av programvaran under utveckling utan också syftet det kommer att tjäna: vad Programvaran ska göra och hur den ska utföra.,
skillnaden mellan funktionella och icke-funktionella krav
funktionskrav är målen för det nya systemet du utformar., De beskriver systemet och hur det kommer att fungera för att hjälpa till med en användares uppgifter. De definierar hur systemet kommer att svara på användarinmatning och har detaljer om beräkningar, datainmatning och affärsprocesser. Du kan överväga funktionella krav en detaljerad beskrivning av programmets funktioner och användarens behov. Utan att uppfylla funktionskraven fungerar systemet inte.
även om funktionskrav anger vad ett system gör, beskriver icke-funktionella krav hur systemet ska göra det. Icke-funktionella krav påverkar inte programmets funktionalitet., Även utan att uppfylla icke-funktionella krav, kommer systemet att utföra de önskade uppgifterna.
icke-funktionella krav är också viktiga eftersom de definierar de allmänna egenskaper som påverkar användarupplevelsen. I stället för att fokusera på användarkrav fokuserar de på användarnas förväntningar och täcker sådana ämnen som prestanda, säkerhet, tillförlitlighet, tillgänglighet och användbarhet.,
hur man skriver en programvara krav specifikation dokument
det är bäst att organisera den process du använder för att skriva en SRS-dokument genom att börja med ett skelett och allmän information om den programvara du utvecklar, och efterbehandling genom att lägga till detaljer för att kött ut ditt utkast. Här är sex steg som är involverade i att skapa ett SRS-dokument:
Get software Requirements Specification Document
vi hjälpte 200+ företag att bygga sina mjukvaruprodukter. Anlita vår affärsanalytiker med 6 års expertis för att skriva en SRS för dig.,
begär SRS
skapa en översikt
det första steget i processen är att skapa en översikt för dina SRS. Du kan skapa detta själv eller använda en befintlig SRS-mall som utgångspunkt. Här är ett grundläggande exempel på en SRS-kontur:
ladda ner ebook
- introduktion
- syfte
- avsedd publik
- Avsedd användning
- omfattning
- definitioner
- övergripande beskrivning
- användarnas behov
- antaganden och beroenden
- systemfunktioner och krav
- funktionskrav
- krav på externt gränssnitt
- systemfunktioner
- icke-funktionella krav
definiera syftet
När du har en översikt måste du fylla ut det., Börja med att definiera syftet med produkten i introduktionen av dina SRS. Här kommer du att beskriva den avsedda publiken och hur de kommer att använda produkten. Så här ska du strukturera syftet:
- definiera produktens omfattning
- beskriv det värde det kommer att leverera
- visa vem som ska använda programvaran
- detaljera hur det kommer att hjälpa till med de avsedda användarnas jobb
ge en översikt
Efter att ha definierat produktens syfte, sammanfatta hur det kommer att fungera., Här kommer du att ge en allmän beskrivning av programvarans funktioner och hur de passar användarens behov.
Du kommer också att beskriva de antaganden du gör om produktens funktionalitet och allt det beror på i det nuvarande tekniska ekosystemet.
beskriv funktionella och icke-funktionella krav
Nu när du har skrivit den allmänna informationen är det dags att bli mer specifik. Slutföra din översikt innan du arbetar med funktionella och icke-funktionella krav ger dig en referens för att se till att du uppfyller användarens grundläggande behov medan du fyller i detaljerna.,
denna detaljerade beskrivning av systemets krav är den viktigaste komponenten i ett SRS-dokument. Beskriv funktionskraven i tillräckligt detalj så att utvecklare kan komma till jobbet och de icke-funktionella kraven som säkerhetsspecifikationer och prestanda.
här lägger du till användningsfall för att tydligt beskriva hur en användare kommer att interagera med ditt system. Det är där projektets mål är detaljerade och kommer att mäta hur projektet fortskrider under utveckling.,
Lägg till kompletterande detaljer
det sista steget i att skapa utkastet till ditt SRS-dokument är att lägga till alla detaljer som kan hjälpa utvecklare att avsluta jobbet i form av bilagor, ordlistor över termer och referenser.
få godkännande
När du har lagt till tillräckligt med detaljer till SRS för att beskriva vad systemet ska göra, är det dags att låta intressenterna godkänna dokumentet.
Du kommer sannolikt att behöva göra en presentation till de personer som är involverade i utvecklingsprocessen., De kan begära ändringar, och du måste uppdatera SRS-dokumentet baserat på feedback från berörda parter innan det slutliga godkännandet.
detta är ett gott tecken. Det betyder att både utvecklare och intressenter gör dokumentet mer exakt, så projektet är mindre som att gå av spår.
hur man skriver kundcase för programvaruanvändning i en SRS
ett användningsfall beskriver hur en användare kommer att interagera med systemet. Det kommer att beskriva produkten från slutanvändarens synvinkel i ett enkelt historieformat. Skriva ut användningsfall tvingar dig att tänka igenom vad användarna kommer att göra med programvaran och hur det kommer att reagera., Det är den verkliga visualiseringen av funktionella krav.
här är steg du kan följa för att skriva ett användningsfall:
- beskriv produktens slutanvändare.
- fokusera på en av dessa användare.
- bryta ner användarens interaktioner i användningsfall. Varje interaktion är ett användningsfall.
- beskriv händelseförloppet för varje användningsfall.
- Skriv en detaljerad beskrivning av användarens åtgärder och hur systemet ska reagera.
- utöka varje användningsfall med alternativa användaråtgärder och systemsvar.
- upprepa 1-6 för varje typ av slutanvändare.,
vilka är egenskaperna hos en stor SRS?
det finns specifika egenskaper som varje SRS ska ha. Genom att granska den här listan och jämföra den med dina SRS kan du se till att det blir ett användbart dokument för alla intressenter.
Explicit
ett SRS-dokument ska vara lätt att förstå. Ingenting bör vara vagt, så det finns inga missförstånd mellan intressenterna.,
mätbar
kraven i SRS-dokumentet måste vara mätbara, så att den färdiga produkten kan valideras och verifieras mot specifikationerna.
komplett
ett SRS-dokument ska ha tillräckligt med information för ditt utvecklingsteam för att avsluta produkten och för testare att validera att produkten uppfyller användarens behov utan fel.
livskraftig
kraven bör passa verkligheten i den nuvarande miljön, inklusive budget, tidslinje och teknik. De bör inte bero på kommande tekniska genombrott.,
Flexibel
eftersom saker och ting kan förändras i arbetsmiljön, bör SRS-dokumentet vara tillräckligt flexibelt för att möjliggöra uppdateringar. Lägg inte till överflödig information i flera avsnitt som måste uppdateras med varje ändring.
verifierbar
alla i utvecklingsgruppen bör ha tillgång till dokumentet så att de kan referera till det så ofta som nödvändigt. Kraven måste vara exakta så att gruppmedlemmar inte behöver be om mer information. De bör alla finnas tillgängliga i SRS-dokumentet.,
konsekvent
kraven ska passa varandra. En del av dina krav dokument bör inte stå i konflikt med en annan. Dokumentet ska formateras konsekvent och använda samma terminologi i hela.
inga Genomförandebegränsningar
ett SRS-dokument ska vara tillräckligt detaljerat för att avsluta jobbet, men bör inte vara alltför specifikt, eftersom det kan begränsa utvecklingen. Mycket utveckling beror på tjänster från tredje part som utvecklare inte har någon kontroll över.,
korrekt
mål i ett kravdokument bör vara exakta för att undvika förvirring. Undvik följande:
- kryphål: ”programmet ska laddas om 3 sekunder om det kan göras.”
- Ambiguity: ”MVP-produkten ska släppas så fort som möjligt.”
- subjektivitet: ”användargränssnittet ska vara användarvänligt.”
- Superlatives: ”detta bör vara det bästa programmet i sin klass.”
- Comparative: ”denna ansökan bör vara bättre än Slack.,”
exempel på Programvara Kravspecifikation (SRS)
här är ett trimmat ner exempel på ett SRS-dokument för en Enterprise chat-app som heter eChat:
introduktion
det här dokumentet beskriver projektplanen för utvecklingen av ”eChat”.”
den är avsedd för utvecklare, designers och testare som arbetar med” eChat ” samt projektinvesterare., Denna plan kommer att innehålla en sammanfattning av:
- hur systemet kommer att fungera
- projektets omfattning ur utvecklingssynpunkt
- den teknik som används för att utveckla projektet och
- de mätvärden som används för att bestämma projektets framsteg
- övergripande beskrivning
företag behöver fjärrkommunikationsverktyg, särskilt nu när fler människor arbetar hemifrån. Problemet är att de flesta företag slutar använda flera applikationer för att uppnå detta: en för textchatt, en för videochatt och en för konferenser och möten., ”eChat” kommer att lösa detta problem genom att kombinera dessa funktioner i ett program.
ladda ner whitepaper
kunder
kunderna kommer att vara företag. Den riktar sig inte till allmänheten.
funktionalitet
- användare bör kunna registrera sig med enterprise LDAP-konton.,
- användare bör kunna skapa ad hoc-chattgrupper som består av uppsättningar användare och skicka privata meddelanden till enskilda användare.
- användare ska kunna ha textchattar som de kan bryta sig in i trådar.
- programmet ska kunna hantera grupp videochatt på upp till 100 användare åt gången.
plattform
applikationen kommer att utvecklas i React Native för att möjliggöra skapandet av en webbaserad applikation, en iOS-mobilapp och en Android-mobilapp.
dessa program kommer att ansluta till ett REST API byggt med .,NET Core för att lagra och hämta data från en MySQL-databas.
autentisering kommer att ske genom befintliga LDAP-installationer.
utvecklingsansvar
utvecklarna i ”eChat” – teamet ansvarar för att skriva all kod för programmet, Utveckla databasen och hantera utgåvor.,
Användarklass och egenskaper
det kommer att finnas en klass av användare som heter admin som kommer att ha behörighet att få tillgång till alla funktioner i appen, inklusive:
- skapa kanaler där flera användare kan interagera
- göra dessa kanaler offentliga för hela företaget eller privat för en grupp människor
- ta bort dessa kanaler
- arkivera dessa kanaler
standardanvändare kommer att ha tillgång till alla funktioner i appen utom de som anges ovan.,
systemfunktioner
funktionskrav
- användare bör kunna skapa ad hoc-chattgrupper som omfattar uppsättningar användare och skicka privata meddelanden till andra användare.
- användare ska kunna ha textchattar som de kan bryta sig in i trådar.
- chattar ska kunna arkiveras på obestämd tid så att användare kan referera till tidigare chattar.
- användare bör kunna ladda upp filer till chattar som referens.
- krav på externt gränssnitt
användargränssnitt
- front-end software: React Native
- back-end software:.,s operativsystem via sin standardwebbläsare
- iPhone
- Android
- icke-funktionella krav
prestandakrav
- programmet ska laddas och användas inom 3 sekunder
- programmet ska uppdatera gränssnittet på interaktion inom 2 sekunder
- databasen ska normaliseras för att förhindra redundanta data och förbättra prestanda
- databasen ska distribueras för att förhindra avbrott
- li>
säkerhetskrav
- databaser bör använda sharding för att vara redundant för att förhindra förlust av data.,
- säkerhetskopior av databaserna bör göras varje timme och hållas i en vecka.
säkerhetskrav
- alla nycklar som används för REST API ska lagras säkert.
- endast REST API ska kunna ansluta till databaserna.
- databaser bör ligga bakom en brandvägg.
attribut Mjukvarukvalitet
- tillgänglighet: eftersom denna ansökan är avgörande för affärskommunikation, kommer vi att ha ett mål på fyra nior(99,99%) tillgänglighet.,
- korrekthet: programmet ska aldrig tillåta någon att läsa meddelanden eller diskussioner som inte är avsedda för den personen.
- underhåll: programmet bör använda kontinuerlig integration så att funktioner och buggfixar kan distribueras snabbt utan driftstopp.
- användbarhet: gränssnittet ska vara lätt att lära sig utan en handledning och tillåta användare att uppnå sina mål utan fel.
sammanfattning
ett SRS-dokument är en nödvändig del av att slutföra ett mjukvaruutvecklingsprojekt., Det är färdplanen som ger riktning till alla inblandade i projektet, så slutprodukten uppfyller användarens behov.
utan ett komplett SRS-dokument på plats innan du startar ett projekt, blir det svårt att säga när ett projekt är klart och kan sidospår utveckling till att skapa oavsiktliga funktioner. Ett SRS-dokument ger Dig möjlighet att uppskatta ett projekt korrekt och tilldela uppgifter effektivt.
att skapa ett SRS-dokument kan vara en tidskrävande och noggrann process., Lyckligtvis har teamet på Relevant hjälpt över 200 företag att skapa SRS-dokument och lansera nya produkter. Vi är redo att hjälpa till med ditt nästa mjukvaruprojekt, bara släppa oss en rad.