6 Trinn For Å Skrive ET SRS-Dokument Som Fungerer + Mal
programvarespesifikasjonsdokumenter blir noen ganger sett på som artefakter som bare gir mening for utviklere. ET SRS-dokument kan imidlertid gå videre og bli en veiledning for markedsføringsspesialister, interessenter, designteam og til og med brukere.
denne artikkelen vil forklare hvorfor programvaredokumentasjon er viktig og hvordan DU skriver SRS-dokumentet for å gjøre det til en praktisk veiledning for alle teamspesialister.
Hva Er ET SRS-Dokument, Og Hvorfor Betyr det Noe?
et SRS-dokument (software requirement specification) er en artefakt som inneholder kravene, forventningene og standardene for et fremtidig produkt. Det kan dekke tekstdokumenter, regneark, ordninger, presedenter og andre elementer som klargjør produktets visjon. MED ANDRE ord gir ET SRS-dokument en detaljert beskrivelse av hvordan et produkt skal fungere og hvordan produktutviklingsteamet skal implementere det.
Tenk deg det som å bygge et skip. Du har en visjon av masten eller seil, og du kan selv forestille seg hvordan det reiser gjennom bølgene. Men du trenger strengere detaljer for å sette skipet på vannet.
det samme gjelder for produktutvikling. Du kan ha en klar visjon om en app du vil bygge med alle funksjonene, designelementene og knappene. En verbal beskrivelse av funksjoner er imidlertid ikke nok for utviklere å implementere ideen.
for at resultatet skal samsvare med bildet i hodet ditt, må du forklare på papir nøyaktig hvordan en funksjon skal fungere. ET SRS-dokument er et utmerket instrument for å beskrive slike tekniske detaljer.
.jpg)
Hvem Skriver ET SRS-Dokument?
Å Skrive ET SRS-dokument betyr å overføre generiske beskrivelser av funksjoner, oppgaver og mål til den detaljerte planen for deres tekniske gjennomføring.
SRS-dokumenter er vanligvis skrevet av produkt – og prosjektledere eller forretningsanalytikere, som direkte kommuniserer med kunder eller som gjør brukerundersøkelser (som også jobber med wireframes og vet hvordan produktet skal oppføre seg) og samler fremtidige produkters krav.
I Mellomtiden er dette dokumentet. Et godt SRS-dokument er ikke bare teknisk, da det også dekker forretningsmål, beregninger, brukerproblemer, brukerpersoner, etc.
3 Grunner Til at ET SRS-Dokument Er Viktig
så den samlede verdien av ET SRS-dokument er klart. Her er grunnene til at programvare krav spesifikasjon dokumenter er avgjørende:
SRS Er Et Kommunikasjonspunkt
SOM et levende dokument fungerer ET SRS-dokument som en kommunikasjonsplattform mellom alle spesialister: utviklere, markedsføringsspesialister og medstiftere.
ved å forklare detaljer i ET SRS-dokument, formelt eller uformelt, er ledere enige med kundene om resultatenes forventninger. I mellomtiden, hvis endringene gjøres i kravene, kan en klient og / eller en produkteier sjekke og validere dem i dokumentet. Og utviklerne er ansvarlige for å leve opp til disse forventningene.
Endelig Beskrivelse av Funksjoner
SRS dokumenterer de endelige versjonene av programvare som kom fra forutsetningene diskutert med klienter før. Under møter og samtaler, brukertester og intervjuer kan produktversjonene endres veldig ofte. Noen ganger kan selv produktledere bli overveldet av eksisterende produkt iterasjoner. SRS-fil bidrar til å forene alle disse kravene til en standard og eliminere forvirring angående produktkravene.
SRS Er En Standardguide For Produktutviklere
I tillegg til å beskrive produktkravene, veileder SRS-dokumentet utviklingsteamet om trinnene de bør følge for å bygge et produkt som en klient ønsker.
avhengig av prosjektets organisasjon, kan utviklere eller ikke være involvert i prosjektets analytiske del. I begge tilfeller må de konkludere med hvordan systemet skal fungere, definere kravene og kodeparametrene som passer til det.
PÅ Samme måte MÅ QA-fagfolk forstå alle de tekniske aspektene som ligger bak produktets konsept. DERMED FUNGERER SRS-dokumentasjon som en standard for planlegging og kjøring AV QA-tester.
til Slutt får designere prosjektinnsikt gjennom SRS-dokumenter for å matche designet med brukssaken.
6 Trinn For Å Skrive Godt SRS-Dokument
Funksjonelle og ikke-funksjonelle krav tar en stor del av ET SRS-dokument. Vare ledere tar ikke bare disse kravene fra ingensteds. De er et resultat av nøyaktig kommunikasjon med kunder og grundig bruker-og teknisk forskning. Her er de viktigste trinnene for å skrive utmerket SRS dokumentasjon:
Trinn 1. Kommunikasjon med en interessent
vi fjerner det første laget av usikkerhet ved å spørre interessentene om deres forventninger fra produktet. Jo, et slikt intervju gir bare en liten forståelse av kravene. Dette er imidlertid fortsatt et godt utgangspunkt for forskning.
På Uptech snakker vi først med klienten På Pre-Salg og Kick-Off samtale når vi prøver å finne ut om vi passer hverandre. Vi prøver å krystallisere de minste detaljene om klienten for å forstå hans / hennes ide.
likevel gir enkel kommunikasjon ikke nok informasjon om målgruppen til produktet og deres ønsker og behov. Så vi går videre med oppdagelsen scenen for å gjøre det klart.
Trinn 2. Oppdagelsesstadiet
Oppdagelsesstadiet er kritisk i skriftlig SRS-dokumentasjon. På dette stadiet har vi mulighet til å utforske problemet som produktet skal løse, interesser og behov. Vårt mål her er å identifisere brukernes problemer og definere hypoteser om mulige løsninger for å takle dem. Med en slik tilnærming kan vi gjøre appen verdifull for brukeren.
Bruk Saker vs Brukerhistorier
Alle brukerdata blir en del av ET SRS-dokument som Bruk Saker og Brukerhistorier. Forskjellen mellom disse to kategoriene er mye diskutert blant produktutviklingssamfunnet.
enkelt sagt, brukerhistorier er mer fokusert på resultatet og fordelene en bruker får når du bruker en funksjon. Mens bruk tilfeller mer detaljert beskrive funksjonen selv.
for eksempel, etter flere brukerintervjuer På Yaza-prosjektet, konkluderte vi med at appen skulle ha en prat. Så brukerhistorien for et slikt tilfelle ville høres ut som: «som bruker vil jeg chatte med en potensiell huseier.»
i Mellomtiden vil brukstilfellet for denne historien beskrive hvert trinn av en bruker for å oppnå dette målet – «Som bruker må jeg legge til en kontakt i chatlisten min og sende ham / henne en melding, slik at…».
Trinn 3. Bygg Strukturen
Når oppdagelsen er fullført, fortsetter vi å skrive SRS-dokumentasjon. For det første trenger vi en kort struktur av dokumentet. Innholdet i ET SRS-dokument kan variere betydelig, men DEN typiske SRS-dokumentasjonsstrukturen vil se slik ut:
1. Innledning
introen legger ut et sammendrag av dokumentets innhold. Det skal svare på følgende spørsmål:
- Kort beskrivelse av dokumentets innhold;
- de tiltenkte leserne av dette dokumentet;
- ideen om programvaren du utvikler;
- Tiltenkte lesere.
1.1 Forretningsmål
Sett opp en liste over mål du vil oppnå på prosjektet, for eksempel å opprette EN MVP, opprette en multiplatform – mobilapp eller starte et nettsted.
dessuten bør denne delen gjenspeile målene og suksessberegningene for virksomheten din. Selv om noen kan utelukke denne delen fra dokumentet, er det viktig å indikere disse tingene, da de direkte påvirker forskning og utvikling.
1.3 Tiltenkt Bruk
hvordan kan du forestille deg at en person vil bruke produktet ditt? Hva er funksjonene du gir for denne typen bruk? Beskriv alle mulige måter en person kan bruke produktet i hvilken brukerrolle han / hun opptrer.
1.4 Scope
denne delen beskriver omfanget av arbeidet du må utføre for å få ideen til liv.
1.5 Definisjoner Og Akronymer
Denne vil legge ut definisjonene av vilkårene du bruker i dokumentet for å sikre en fullstendig forståelse av brukerne.
2. Samlet Beskrivelse
her er delen der du forklarer appens ide, hvor den kom fra og hvorfor den kan være interessant for brukerne.
2.1 Brukerbehov
et stykke programvare som er bygget for alle, tjener ingen. Men hvis du vet nøyaktig hvem målgruppen din er, hvor de jobber og deres smerter, har du større sjanser til å levere en app som er allment vedtatt av brukerne.
3. Systemfunksjoner Og Krav
nå er det på tide å skissere de tekniske kravene til fremtidig programvare. Beskriv funksjonene som produktet ditt vil inkludere, sammen med standardene som definerer kvaliteten på disse produktene.
3.1 Funksjonskrav
Funksjonskrav Er systemspesifikasjoner, uten hvilke programvaren ikke fungerer som den skal. Definisjonen du vil gi til programvarefunksjonene dine, bestemmer hvordan de skal implementeres videre.
3.2 Ikke-Funksjonelle Krav
mens funksjonelle krav definerer hva systemets funksjon vil være, bestemmer ikke-funksjonelle krav hvordan systemet skal implementere disse funksjonene, for eksempel fullføringshastigheten.
3.3 Tech Stack
en tech stack er et utvalg av tekniske løsninger som brukes til å lage og kjøre programvare eller et prosjekt. Det er viktig å angi DET i SRS-dokumentet da det definerer alle andre tekniske detaljer.
.jpg)
Trinn 4. Lag En Generell Beskrivelse
før du stuper inn i produktets detaljer, gi en generell oversikt over appens hovedfunksjoner. Bare forklare appens formål, dens funksjoner, og hvordan de løser brukerens problem.
Trinn 5. Definer Funksjonelle Og Ikke-Funksjonelle Krav
kjernen i SRS-dokumentet vil vanligvis bestå av produktets funksjonelle og ikke-funksjonelle krav. Med slike spesifikasjoner legger du til flere detaljer i den generelle oversikten og veileder teamet gjennom appens tekniske detaljer.
forskjellen mellom funksjonelle og ikke-funksjonelle krav er et annet fast punkt i produktutviklingssamfunnet. Vi har delt vår kompetanse om dette emnet i denne artikkelen.
Trinn 6. Kontroller At Klienten På Samme Side
Godkjenning er en mye forventet del av utviklingen. Klientens endringer kan imidlertid noen ganger negere hele arbeidet, fullført på et bestemt tidspunkt i prosjektet.
for å unngå trykk, anbefaler vi å godta små deler av utfylt SRS-dokumentasjon, i stedet for å sende inn en hel pakke med dokumenter samtidig. Dette bidrar til å løse visse problemer raskt og er mindre plagsom.
Ekspert Tips Om Å Skrive Stor SRS Dokumentasjon
Det tar tid å finpusse ferdigheten til å skrive utmerket SRS-dokumentasjon. Vi har trukket en liste over eksperttips om å skrive SRS-dokumentasjon fra vår erfaring. Så her er noen innsikt som vil gjøre SRS-dokumentasjonen effektiv:
Gjør Det Enkelt
dette er neppe en hemmelighet, men enkle ting styrer verden. Dette er sikkert sant for alle typer dokumentasjon du arbeider på. DIN SRS er en enhetlig beskrivelse av det fremtidige produktet for hele teamet ditt. Dette betyr at språket, strukturen og formuleringene i SRS-dokumentet ditt skal være så lakonisk som mulig.
Inkluder Forretningsmål
selv OM ET SRS-dokument primært fokuserer på de tekniske egenskapene, inkludert forretningsmål er en god praksis. ET SRS-dokument er en instruksjon for utviklingsteamet og produktsammendraget for ikke-tekniske spesialister relatert til produktet. Videre, inkludert forretningskrav, som beregninger og formål, vil GJØRE SRS et enhetlig instrument for hele teamet.
Legg Til Brukerdata
oppdagelsesfasen avslører vanligvis den mest verdifulle informasjonen om en bruker. Hvis DU legger til denne informasjonen I SRS-dokumentet, blir det et nyttig papir for design-og utviklingsteamet.
Behandle SRS som Et Levende Dokument
SRS-dokumentet bør ikke være statisk, selv om du har samlet alle nødvendige pakker for prosjektet ditt. I Agile økosystemer går prosjekter rundt og kjøper nye funksjoner med hver bestått iterasjon. Alle slike endringer og modifikasjoner skal formidles I SRS-dokumentet og avtales med kunden.
Konklusjon
Skrive SRS dokumenter tar dyp forskning, analyse og innsats. Et omfattende SRS-dokument som dekker forretningsegenskaper, tekniske detaljer og brukerdata, vil imidlertid lønne seg med et fantastisk produkt som oppfyller både klient-og brukernes forventninger.
Uptech har fem års erfaring med å bygge produkter for blomstrende oppstart. VI vet hvordan vi skal utforske brukerens behov og få SRS til å dokumentere et effektivt prosjektstyringsinstrument i stedet for en bunke støvdekket papir.
F. A. Q.
Hva ER SRS?
EN SRS er et dokument som dekker en detaljert beskrivelse av de tekniske spesifikasjonene og kravene til en app eller programvare. EN SRS instruerer også utviklere om hvordan man implementerer produktets ide for å matche kundens forventninger.
Hva er formålet MED ET SRS-dokument?
FORMÅLET MED ET SRS-dokument er å gi teknisk beskrivelse av produktets egenskaper, gi tekniske og ikke-tekniske krav og veilede utviklingsteamet om implementeringen.
Hvem Skriver SRS-dokumenter?
AVHENGIG av lagets sammensetning, ER SRS-dokumenter vanligvis skrevet av:
- Produktleder;
- Prosjektleder;
- Forretningsanalytiker;
- Teknisk Ingeniør.