6 trin til at skrive et SRS-dokument , der fungerer + skabelon
programspecifikationsdokumenter ses undertiden som artefakter, der kun giver mening for udviklere. Et SRS-dokument kan dog gå videre og blive en guide til marketingspecialister, interessenter, designteam og endda brugere.
denne artikel vil forklare, hvorfor programdokumentation betyder noget, og hvordan du skriver dit SRS-dokument for at gøre det til en praktisk vejledning for alle teamspecialister.
Hvad er et SRS-dokument, og hvorfor betyder det noget?
et SRS-dokument er en artefakt, der indeholder krav, forventninger og standarder for et fremtidigt produkt. Det kan dække tekstdokumenter, regneark, ordninger, præcedenser og andre elementer, der tydeliggør produktets vision. Med andre ord giver et SRS-dokument en detaljeret beskrivelse af, hvordan et produkt skal fungere, og hvordan produktudviklingsteamet skal implementere det.
Forestil dig det som at bygge et skib. Du har en vision om masten eller sejlet, og du kan endda forestille dig, hvordan det bevæger sig gennem bølgerne. Du har dog brug for strengere detaljer for at sætte skibet på vandet.
det samme gælder for produktudvikling. Du kan have en klar vision om en app, du vil bygge med alle funktioner, designelementer og knapper. En verbal beskrivelse af funktioner er imidlertid ikke nok for udviklere at implementere ideen.
for at resultatet skal matche billedet i dit hoved, skal du på papir forklare nøjagtigt, hvordan en funktion skal fungere. Et SRS-dokument er et glimrende instrument til at beskrive sådanne tekniske detaljer.
.jpg)
Hvem skriver et SRS-dokument?
skrivning af et SRS-dokument betyder overførsel af generiske beskrivelser af funktioner, opgaver og mål til den detaljerede plan for deres tekniske implementering.
SRS-dokumenter skrives normalt af produkt-og projektledere eller forretningsanalytikere, der direkte kommunikerer med klienter, eller som foretager brugerundersøgelser (som også arbejder med trådrammer og ved, hvordan produktet skal opføre sig) og samler fremtidige produkters krav.
i mellemtiden dette dokument. Et godt SRS-dokument er ikke kun teknisk, da det også dækker forretningsmål, målinger, brugerproblemer, brugerpersoner osv.
3 Årsager til, at et SRS-dokument er vigtigt
så den samlede værdi af et SRS-dokument er klart. Her er grundene til, at programmel krav specifikation dokumenter er afgørende:
SRS er et kommunikationspunkt
som et levende dokument fungerer et SRS-dokument som en kommunikationsplatform mellem alle specialisterne: udviklere, marketing specialister og medstiftere.
ved at forklare detaljer i et SRS-dokument, formelt eller uformelt, er ledere enige med klienter om resultaternes forventninger. I mellemtiden, hvis ændringerne foretages i kravene, kan en klient og/eller en produktejer kontrollere og validere dem i dokumentet. Og udviklerne er ansvarlige for at leve op til disse forventninger.
endelig beskrivelse af funktioner
SRS dokumenterer de endelige versioner af programmer, der stammer fra de antagelser, der blev diskuteret med klienter før. Under møder og opkald, brugertests og samtaler kan produktversionerne ændre sig meget ofte. Nogle gange kan selv produktledere blive overvældet af de eksisterende produkt iterationer. SRS-fil hjælper med at forene alle disse krav til en standard og eliminere enhver forvirring vedrørende produktkravene.
SRS er en Standardguide til produktudviklere
udover at beskrive produktkravene guider SRS-dokumentet udviklingsholdet om de trin, de skal følge for at opbygge et produkt, som en klient ønsker.
afhængigt af projektets organisation kan udviklere eller kan ikke være involveret i projektets analytiske del. I begge tilfælde skal de konkludere, hvordan systemet skal fungere, definere de krav og kodeparametre, der passer til det.
tilsvarende skal KVALITETSSIKRINGSPROFESSIONELLE forstå alle de tekniske aspekter, der ligger bag produktets koncept. SRS-dokumentation fungerer således som en standard for planlægning og kørsel af kvalitetssikringstest.
endelig får designere projektindsigt gennem SRS-dokumenter for at matche designet til brugssagen.
6 trin til at skrive godt SRS-dokument
funktionelle og ikke-funktionelle krav udgør en stor del af ethvert SRS-dokument. Produktledere tager ikke blot disse krav fra ingen steder. De er resultatet af nøjagtig kommunikation med klienter og dybdegående bruger-og teknisk forskning. Her er de vigtigste trin i at skrive fremragende SRS-dokumentation:
Trin 1. Kommunikation med en interessent
vi fjerner det første lag af usikkerhed ved at spørge interessenterne om deres forventninger til produktet. Jo da, en sådan samtale giver bare en lille forståelse af kravene. Dette er dog stadig et godt udgangspunkt for forskning.
hos Uptech taler vi først med klienten ved Pre-Sale og Kick-Off-opkaldet, når vi prøver at finde ud af, om vi passer til hinanden. Vi forsøger at krystallisere de mindste detaljer om klienten for at forstå hans/hendes ide.
alligevel giver enkel kommunikation ikke nok information om målgruppen for produktet og deres ønsker og behov. Så vi fortsætter med opdagelsesfasen for at gøre det klart.
Trin 2. Discovery Stage
Discovery stage er kritisk skriftligt SRS dokumentation. På dette stadium har vi mulighed for at undersøge det problem, som produktet skal løse, interesser og behov. Vores mål her er at identificere brugernes problemer og definere hypoteser om mulige løsninger til at tackle dem. Med en sådan tilgang kan vi gøre appen værdifuld for brugeren.
Use Cases vs User Stories
alle brugerdata bliver en del af et SRS-dokument som Use Cases og User Stories. Forskellen mellem disse to kategorier diskuteres bredt blandt produktudviklingssamfundet.
kort sagt, brugerhistorier er mere fokuserede på resultatet og fordelene, som en bruger får, mens han bruger en funktion. Mens brugssager mere detaljeret beskriver selve funktionen.
for eksempel konkluderede vi, at appen skulle have en chat. Så brugerhistorien i en sådan sag lyder som: “som bruger vil jeg chatte med en potentiel husejer.”
i mellemtiden vil brugssagen til denne historie beskrive hvert trin i en bruger for at nå dette mål – “som bruger skal jeg tilføje en kontakt i min chatliste og sende ham/hende en besked, så…”.
Trin 3. Byg strukturen
når opdagelsen er afsluttet, fortsætter vi med at skrive SRS-dokumentation. For det første har vi brug for en kort struktur af dokumentet. Indholdet af et SRS-dokument kan variere betydeligt, men den typiske SRS-dokumentationsstruktur ser sådan ud:
1. Introduktion
introen indeholder en oversigt over dokumentets indhold. Det skal svare på følgende spørgsmål:
- Kort beskrivelse af dokumentets indhold;
- de tilsigtede læsere af dette dokument;
- ideen om det program, du udvikler;
- tilsigtede læsere.
1.1 forretningsmål
Opret en liste over mål, du vil nå på projektet, som f.eks. at oprette en MVP, oprette en multiplatform-mobilapp eller starte en hjemmeside.
Desuden skal dette afsnit afspejle målene og succesmålingerne for din virksomhed. Selvom nogle måske udelukker denne del fra dokumentet, er det vigtigt at angive disse ting, da de direkte påvirker forskning og udvikling.
1.3 Tilsigtet brug
hvordan forestiller du dig, at en person vil bruge dit produkt? Hvad er de funktioner, du leverer til denne type brug? Beskriv alle mulige måder, hvorpå en person kan bruge dit produkt, uanset hvilken brugerrolle han / hun handler.
1.4 omfang
denne del beskriver omfanget af det arbejde, du skal udføre for at bringe din ide til liv.
1.5 definitioner og akronymer
denne beskriver definitionerne af de udtryk, du bruger i dokumentet for at sikre en fuldstændig forståelse af brugerne.
2. Samlet beskrivelse
her er den del, hvor du forklarer appens ide, hvor den kom fra, og hvorfor den kan være interessant for brugerne.
2.1 brugerbehov
et stykke program, der er bygget til alle, tjener ingen. Men hvis du ved præcis, hvem din målgruppe er, hvor de arbejder, og deres smerter, har du større chancer for at levere en app, der er bredt vedtaget af brugerne.
3. Systemfunktioner og krav
nu er det tid til at skitsere de tekniske krav til dit fremtidige program. Beskriv de funktioner, som dit produkt vil omfatte, sammen med de standarder, der definerer kvaliteten af disse produkter.
3.1 funktionelle krav
funktionelle krav er systemspecifikationer, uden hvilke programmet ikke fungerer korrekt. Den definition, du vil give til dine programfunktioner, bestemmer, hvordan de vil blive implementeret yderligere.
3.2 ikke-funktionelle krav
mens funktionelle krav definerer, hvad systemets funktion vil være, bestemmer ikke-funktionelle krav, hvordan systemet vil implementere disse funktioner, for eksempel færdiggørelseshastigheden.
3.3 Tech Stack
en tech stack er en pulje af tekniske løsninger, der bruges til at oprette og køre programmer eller et projekt. Det er vigtigt at angive det i SRS-dokumentet, da det definerer alle andre tekniske detaljer.
.jpg)
Trin 4. Lav en generel beskrivelse
før du kaster dig ned i dit produkts detaljer, skal du give et generelt overblik over appens hovedfunktioner. Forklar blot din apps formål, dens funktioner, og hvordan de løser brugerens problem.
Trin 5. Definer funktionelle og ikke-funktionelle krav
kernen i dit SRS-dokument vil normalt bestå af produktets funktionelle og ikke-funktionelle krav. Med sådanne specifikationer tilføjer du flere detaljer til det generelle overblik og guider dermed teamet gennem din apps tekniske detaljer.
forskellen mellem funktionelle og ikke-funktionelle krav er et andet klæbepunkt i produktudviklingssamfundet. Vi har delt vores ekspertise om dette emne i denne artikel.
Trin 6. Sørg for, at klienten på samme side
godkendelse er en meget forventet del af udviklingen. Klientens redigeringer kan dog undertiden negere hele mængden af arbejde, der er afsluttet på et bestemt tidspunkt i projektet.
for at undgå presset anbefaler vi at acceptere små dele af udfyldt SRS-dokumentation i stedet for at indsende en hel pakke dokumenter på en gang. Dette hjælper med at løse visse problemer hurtigt og er mindre besværligt.
ekspert Tips om at skrive stor SRS dokumentation
det tager tid at finpudse evnen til at skrive fremragende SRS-dokumentation. Vi har trukket en liste over eksperttips til skrivning af SRS-dokumentation fra vores erfaring. Så her er et par indsigter, der gør din SRS-dokumentation effektiv:
gør det enkelt
dette er næppe en hemmelighed, men enkle ting styrer verden. Dette gælder bestemt for enhver form for dokumentation, du arbejder på. Din SRS er en samlet beskrivelse af det fremtidige produkt for hele dit team. Dette betyder, at sproget, strukturen og formuleringerne i dit SRS-dokument skal være så lakoniske som muligt.
Inkluder forretningsmål
selvom et SRS-dokument primært fokuserer på de tekniske egenskaber, herunder forretningsmål er en god praksis. Et SRS-dokument er en instruktion til udviklingsholdet og produktoversigten for ikke-tekniske specialister relateret til produktet. Desuden vil inklusive forretningskrav, som målinger og formål, gøre dine SRS til et samlet instrument for hele teamet.
Tilføj brugerdata
opdagelsesfasen afslører normalt de mest værdifulde oplysninger om en bruger. Tilføjelse af disse oplysninger til SRS-dokumentet gør det til et nyttigt papir til design-og udviklingsholdet.
Behandl dine SRS som et levende dokument
SRS-dokumentet skal ikke være statisk, selvom du har samlet alle de nødvendige pakker til dit projekt. I Agile økosystemer går projekter rundt og erhverver nye funktioner med hver forbipasserende iteration. Alle sådanne ændringer og ændringer skal fremføres i SRS-dokumentet og aftales med kunden.
konklusion
skrivning af SRS-dokumenter kræver dyb forskning, analyse og indsats. Et omfattende SRS-dokument, der dækker forretningskarakteristika, tekniske detaljer og brugerdata, vil dog betale sig med et fantastisk produkt, der opfylder både klient-og brugernes forventninger.
Uptech har fem års erfaring med at bygge produkter til blomstrende startups. Vi ved, hvordan man udforsker brugerens behov og gør SRS document til et effektivt projektstyringsinstrument snarere end en stak støvdækkede papirer.
F. A. K.
Hvad er SRS?
en SRS er et dokument, der indeholder en detaljeret beskrivelse af de tekniske specifikationer og krav til en app eller et program. En SRS instruerer også udviklere om, hvordan man implementerer produktets ide for at matche kundens forventninger.
Hvad er formålet med et SRS-dokument?
formålet med et SRS-dokument er at give teknisk beskrivelse af et produkts funktioner, levere tekniske og ikke-tekniske krav og vejlede udviklingsholdet om implementeringen.
Hvem skriver SRS-dokumenter?
afhængigt af holdets sammensætning er SRS-dokumenter normalt skrevet af:
- produktchef;
- projektleder;
- forretningsanalytiker;
- teknisk ingeniør.