Sådan skriver du en kravspecifikation til et marketingbureau

Hvad kravspecifikationen skal løse for jer

En kravspecifikation beskriver præcist, hvad organisationen og de kommende brugere har behov for af platformen. Den skal være så præcis, at leverandøren og eventuelle testbrugere alene ud fra dokumentet kan se, hvad løsningen kan, og hvad arbejdet indebærer. Samtidig tjener den tre formål på én gang: forventningsafstemning mellem parterne, udviklingsdokument og kontrakt for samarbejdet med leverandøren (digitalmarkedsfoering.dk).

Ligger opgaven hos et marketingbureau i stedet for et udviklingshus, er kernen den samme. En kravspecifikation er en omfattende beskrivelse af funktioner, egenskaber og begrænsninger, og formålet er at skabe et klart og fælles billede mellem kunden og dem, der skal løse opgaven. Den rummer typisk både funktionelle krav – hvad løsningen skal kunne – og ikke-funktionelle krav om kvalitetsattributter som sikkerhed, ydeevne og brugervenlighed (webto.dk).

Uden dokumentet vokser risikoen for misforståelser, for at omfanget glider, og for omfattende, fordyrende ændringer undervejs. Kravspecifikationen afgrænser nemlig projektet og bliver det dokument, som tilbud og kontrakt bygger på, fordi den fastlægger, hvad der skal leveres, hvornår og til hvilken betaling (digitalmarkedsfoering.dk; webudvikleren.dk).

Du behøver hverken forudgående teknisk kendskab til løsningen eller platformen eller specialiseret viden om den forretning, den skal implementeres i. Det afgørende er forståelse for og erfaring med de aktiviteter, der skal gennemløbes (Sopra Steria).

Fordele og ulemper ved at udarbejde en kravspecifikation

Forretningsmål og målbare succeskriterier

Begynd med forretningskravene. De forklarer, hvorfor opgaven skal løses, og hvad der skal til, for at projektet lykkes. Forretningskravene er high-level mål for hele forretningen: de styrer, hvilken løsning I vælger, hvilke interessenter der skal inddrages, og den løbende prioritering i projektet. De indgår i og udgør business casen, som bør justeres, hvis og når kravene ændrer sig undervejs (Sopra Steria).

Forretningskravene skal være målbare. I Sopra Sterias eksempel på en kravspecifikation har forretningen på baggrund af en analyse vedtaget målsætninger i procent – både for kundetilfredshed og for håndteringstid – og gjort dem til krav i projektet (Sopra Steria). Skriv derfor succeskriterierne som måltal med et udgangspunkt, et mål og et tidspunkt, hvor målet skal være indfriet, frem for som ønsker.

Knyt succeskriterierne til det, hjemmesiden eller kampagnerne reelt skal flytte i forretningen. En kravspecifikation kan sikre, at løsningen bygges til brugerne, modtager den trafik, den kan, og er optimeret til at konvertere trafikken til kontakter og leads, så den understøtter salgsarbejdet og forretningsmålene (digitalmarkedsfoering.dk).

Beskriv også, hvad bureauet skal prioritere, når målene trækker i hver sin retning – for eksempel hvis I både vil have flere henvendelser og højere kvalitet i dem. Prioriteringsrækkefølgen bliver en del af grundlaget for at vurdere arbejdet bagefter, og de målbare mål er samtidig det, der gør business casen styrbar (Sopra Steria).

Afgrænsning: hvad er med, og hvad er ikke

Sæt et selvstændigt afsnit af til omfang og definitioner: hvad der inkluderes og ekskluderes, og hvilke akronymer og hvilken terminologi I bruger internt. Det er det afsnit, der forhindrer, at I betaler for mere, end I har brug for (webudvikleren.dk; digitalmarkedsfoering.dk).

Lav en leveranceliste, hvor hver leverance har form, indhold og antal: hvilke ydelser bureauet skal levere, i hvilke kanaler, i hvilke formater, på hvilke sprog, og hvem der skaffer det underliggende materiale – tekst, billeder, produktdata og adgang til systemer. Beskriv også, hvordan data skal håndteres, og hvordan løsningen skal spille sammen med jeres øvrige systemer, så det står klart, hvad bureauet skal have adgang til, og hvad det skal levere tilbage (webto.dk).

Skriv eksplicit, hvad der ikke er en del af aftalen: om mediebudgettet er holdt uden for bureauets honorar, om annonceproduktion, tekster, oversættelse, lagerfotografering og løbende rådgivning er med eller ej, og hvem der ejer konti, målinger, kreativt materiale og brugsretten til det, når samarbejdet stopper. Det er netop de punkter, der får tilbud til at se billige ud, fordi de ikke indeholder det samme.

Hold også fast i forskellen mellem funktionelle krav og systemkrav: funktionelle krav beskriver den ønskede funktionalitet og adfærd, mens systemkrav beskriver hardware, software og netværk. Har I krav til eksisterende platforme eller systemer, skal de stå i dokumentet, fordi de begrænser, hvad bureauet kan vælge (webto.dk).

Målgrupper, behov og centrale brugerrejser

Målgruppeafsnittet beskriver de kommende brugeres behov – ikke jeres egen organisations ønsker. En kravspecifikation er netop en præcis beskrivelse af organisationens og brugernes behov til platformen, og den skal være så konkret, at en leverandør kan arbejde ud fra den (digitalmarkedsfoering.dk).

Den overordnede beskrivelse bør dække brugernes behov, systemperspektivet og afhængighederne mellem kanaler, systemer og mennesker. Suppler med eksempler og brugerflows: wireframes, flows og use cases, så kravene kobles til konkrete situationer i stedet for til generelle ønsker om et moderne udtryk (webudvikleren.dk).

Beskriv også brugsscenarier – hvordan løsningen bruges i forskellige situationer. Et eksempel fra en webshop: sælger butikken både detailvarer og konfigurerbare varer, skal webshoppen kunne beregne prisen dynamisk for begge varetyper, og kundens valgmuligheder skal være fuldstændig ens, uanset om der handles i butikken eller online. Den slags krav er kun synlige, hvis brugerrejsen er beskrevet på tværs af kanaler (webto.dk).

Gennemgå målgrupperne systematisk: hvem de er, hvilken situation de står i, hvad de skal finde ud af, hvilke handlinger de skal kunne gennemføre, og hvad der skal ske bagefter. Alle krav i dokumentet bør kunne føres tilbage til en målgruppe og en situation – ellers er det ikke til at vurdere, om kravet er nødvendigt.

Funktionskrav til ydelser og leverancer

Funktionelle krav specificerer funktioner, brugerinteraktioner, forretningslogik og datahåndtering (webto.dk). For et marketingbureau betyder det, at hvert krav beskriver, hvad der skal ske, hvad der kommer ind, hvad der kommer ud, og hvornår det er opfyldt. Detaljerede krav med input, output og scenarier er den form, der efterfølgende kan testes (webudvikleren.dk).

Del kravene op efter de ydelsesområder, I skal aftale: hjemmeside, ny løsning eller redesign; webshop; SEO og synlighed i søgemaskiner; annoncering og digital markedsføring; brugeroplevelse, hastighed og flere konverteringer; design, branding og visuel retning; drift, vedligeholdelse og teknisk support; strategi, analyse og digital udvikling over tid. Det er de opgavetyper, bureauerne selv inddeler deres ydelser efter, og opdelingen viser, hvilke dele af opgaven der er indeholdt i tilbuddet (lokalt-webbureau.dk).

Formulér kravene som sætninger, der kan besvares med ja eller nej: hvem der gør hvad, i hvilken kanal, med hvilken kadence, med hvilke data som input, og hvad resultatet skal kunne. Undgå krav, der kun kan vurderes efter et skøn – de bliver umulige at gøre til genstand for godkendelse eller efterregning.

Vær eksplicit med detaljerne, fordi udviklere og bureauer tænker i detaljer og specifikke anvisninger: nævner man ikke en funktion eller en systemindstilling, er den ikke nødvendigvis en del af løsningen (webto.dk). Det gælder både tekniske detaljer i en platform og praksis i den løbende drift, som I forventer udført.

Ikke-funktionelle krav, kvalitet og brand

De ikke-funktionelle krav beskriver kvalitetsniveauet: ydeevnekrav, sikkerhedskrav, tilgængelighed, skalerbarhed og brugervenlighed (webto.dk). Skriv dem som målbare størrelser, ikke som egenskabsord – "hurtig", "sikker" og "tilgængelig" kan ikke godkendes eller afvises og bliver derfor heller ikke styrende for bureauets arbejde.

Sikkerhed handler i praksis om, hvem der har adgang til hvilke konti og data, hvor længe adgangen varer, og hvad der sker, når en medarbejder eller et bureau stopper. Skalerbarhed handler om, hvad løsningen skal kunne holde til ved kampagner og sæsonudsving. Tilgængelighed bør knyttes til en anerkendt standard, fx WCAG, og til hvilke brugergrupper I prioriterer. Ydeevne beskrives som grænseværdier for indlæsningstid og oppetid frem for som hensigter (webto.dk; webudvikleren.dk).

Brand er en del af de ikke-funktionelle krav. Designspecifikationer omfatter UI/UX-design, navigationsstrukturer, wireframes og mockups (webto.dk), og kravene til design, visuel identitet og en sammenhængende digital profil skal beskrives frem for at henvises til, "som vi plejer" (lokalt-webbureau.dk). Læg farver, typografi, billedstil, tone of voice og regler for, hvad der aldrig må stå i kommunikationen, ind i dokumentet eller som bilag.

Knyt kvalitetskravene til konvertering, hvor det er muligt. Brugeroplevelse og hastighed påvirker, hvor mange der gennemfører en handling på siden (lokalt-webbureau.dk), så kravene til indlæsningstid og brugeroplevelse bør hænge sammen med de succeskriterier, I har formuleret for forretningen.

Vigtige kvalitetssikringseksempler i kravspecifikation

Prioritering, data og måling

Prioritér kravene med MoSCoW-metoden, så det er tydeligt, hvad der skal være med i den første leverance, og hvad der kan vente (webudvikleren.dk). Opdel i krav, der skal leveres, krav der bør leveres, krav der kan leveres, hvis der er plads, og krav der udtrykkeligt ikke er en del af denne aftale. Det giver bureauet mulighed for at prioritere indsatsen og jer et redskab til at sammenligne tilbud, hvor den ene leverandør har lagt alt i første fase og den anden kun det nødvendige.

Datakravene skal stå i dokumentet: datamodeller, datatyper, datalagringskrav og integritetsregler samt integrationer til andre systemer med API-specifikationer og dataudvekslingsformater (webto.dk). Beskriv, hvilke kundedata bureauet skal bruge, hvor de kommer fra, hvordan de overføres, og hvad der sker med dem, når samarbejdet ophører.

Kobl målepunkterne direkte til succeskriterierne, og definér, hvad der udløser en måling – hvornår en henvendelse tælles som et lead, hvornår et køb registreres, og hvilke mål der rapporteres i hvilken kadence. Dokumentér sammenhængen mellem krav og test, dokumenter og design, så I kan se, om hvert krav er undersøgt og godkendt (webudvikleren.dk).

Aftal også, hvem der ejer analysekonti og målinger, hvem der har adgang, og hvordan data udveksles mellem jeres systemer og bureauets – samt hvordan resultater rapporteres tilbage. Uden det bliver det vanskeligt at afgøre, om succeskriterierne er indfriet, eller om trafikken blot er flyttet.

Test, godkendelse og ændringshåndtering

Kvalitetssikring i kravspecifikationen består af testplaner, testcases og testkriterier samt af godkendelseskriterier for de enkelte leverancer. Kravspecifikationen kan også indeholde en risikovurdering med identificerede risici, risikostyringsstrategier og beredskabsplaner (webto.dk). Skriv testkriterierne som de betingelser, en leverance skal opfylde for at blive godkendt, og knyt dem til de krav, de tester (webudvikleren.dk).

Beskriv, hvordan kravene skal verificeres og testes, hvem der tester, og hvilket miljø testen foregår i. Aftal, hvornår i forløbet godkendelsen sker – ved milepæle eller ved afslutning af en fase – og hvor lang fristen er for at svare, efter at I har modtaget noget til godkendelse. En frist og en regel for, hvad der sker, hvis fristen overskrides, hører med i dokumentet.

Ændringer skal dokumenteres med en ændringslog, der indeholder versionshistorie og godkendelser (webudvikleren.dk). Aftal, hvem der må godkende en ændring, og at ændringer, der påvirker pris eller tidsplan, først gennemføres efter skriftlig accept – den skriftlige godkendelse forhindrer de større, fordyrende ændringer undervejs (digitalmarkedsfoering.dk).

Sæt også navn på, hvem der repræsenterer jer i godkendelsen, og hvad der sker, hvis I ikke er enige om, hvorvidt et krav er opfyldt. Uden en beskrevet proces ender uenigheden typisk som en diskussion om timer i stedet for om kravet.

Drift, support, budget og samarbejdsmodel

Vedligeholdelsesafsnittet skal indeholde planer for systemvedligeholdelse og opdateringer samt supportkrav (webto.dk). Konkret betyder det supportniveauer, svartider og SLA-aftaler: hvad der er inkluderet i den løbende aftale, hvad der er merkøb, hvad der er kritiske fejl, og hvornår på døgnet supporten gælder (webudvikleren.dk).

Pris og tidsramme beskrives med budgetoverslag, betalingsplan, milepæle og deadlines (webudvikleren.dk), suppleret af en projektplan med tidsplan, milepæle og deadlines (webto.dk). Skriv både bureauets honorar og det mediebudget, der skal bruges på annoncering, som to separate tal, så I kan se, hvad der går til arbejde, og hvad der går til købt visning.

Samarbejdsformen skal være beskrevet: om det er fastpris, timepris eller en løbende aftale, hvordan betalingen falder, hvilke bindinger og kontrakter der gælder, og hvilke samarbejds- og betalingsformer der er aftalt (lokalt-webbureau.dk). Aftal også, hvordan timer eller leverancer dokumenteres, og hvad der sker med uforbrugte timer.

Beskriv den praktiske samarbejdsmodel: navngivet kontaktperson hos jer og hos bureauet, mødekadence, hvordan beslutninger dokumenteres, og hvordan I giver feedback. Samarbejde, kontakt og forventningsafstemning er et selvstændigt vurderingspunkt, når et bureau vælges, og det er lettere at vurdere, hvis I på forhånd har beskrevet, hvordan I vil arbejde sammen (lokalt-webbureau.dk).

Fra kravspecifikation til tilbud og bureauvalg

Kravspecifikationen er grundlaget for tilbuddet og kontrakten, fordi den indeholder en klar aftale om arbejdets omfang, betaling og leveringsdatoer (webudvikleren.dk). Send den derfor ud som bilag til tilbudsanmodningen sammen med en tidsplan, så alle bureauer svarer på det samme grundlag.

Bed hvert bureau svare punkt for punkt på kravene og oplyse antagelser og forbehold. Sammenlign derefter tilbuddene, og sammenlign flere bureauer, før du vælger (lokalt-webbureau.dk). Brug kravspecifikationens prioritering til at se, om bureauet har lagt det, der skal leveres, i den første fase, eller om noget af det nødvendige er skåret væk for at nå en pris.

Vurder bureauet på cases, referencer og dokumenterede resultater, på om kompetencerne passer til netop jeres opgavetype, og på om dets måde at arbejde på stemmer overens med jeres. Tag også stilling til drift og fremtidige behov, så valget ikke kun dækker den første leverance (lokalt-webbureau.dk).

Selve arbejdet med at udarbejde kravspecifikation og projektplan er en øvelse for både kunde og leverandør: den tvinger begge parter til at gennemgå behov, afgrænsning og forventninger, inden arbejdet begynder. Punkter, I ikke kan besvare i dokumentet, er samtidig de punkter, hvor I skal bede bureauet om at forklare, hvordan det vil løse opgaven (digitalmarkedsfoering.dk).

Sådan opbygges en kravspecifikation til et marketingbureau