Kravdokument for nettside: hva du skal skrive
Et kravdokument finnes av én grunn: å sikre at du og den som bygger siden, snakker om samme prosjekt. Det trenger ikke være langt. Det må være konkret på de rette stedene.
Denne guiden viser hva du skal ha med, hva du skal la være, og hvilke deler som hindrer de vanligste stridighetene.
Deler som ikke kan mangle#
Hver av dem finnes fordi fraværet skaper et forutsigbart problem.
- Kontekst og mål. Hva bedriften gjør, og hva siden skal oppnå, i tall.
- Målgruppe. Hvem som besøker, og med hvilket spørsmål.
- Sideliste. Alle, gruppert etter mal, med markering av hvilke som er nye.
- Funksjoner. Skjemaer, søk, filtre, innlogget område, hva det nå er.
- Integrasjoner. Hvert eksternt system, med ansvarlig for tilgang.
- Innhold. Hvem skriver, hvem fotograferer, hvem legger inn, og innen når.
- Tekniske krav. Språk, tilgjengelighet, ytelse, støttede nettlesere.
- Utenfor omfang. Dokumentets viktigste del.
- Frister og ansvarlige. Hvem bestemmer, og hva som skjer ved forsinkelse.
Delen «utenfor omfang» hindrer flere stridigheter enn alle andre til sammen. Skriv den, selv om den virker opplagt.
Slik skriver du krav som kan etterprøves#
Et vagt krav kan ikke etterprøves, og det som ikke kan etterprøves, diskuteres på slutten av prosjektet.
| Vagt | Etterprøvbart |
|---|---|
| Siden skal være rask | LCP under 2,5 s på hovedmalene i 4G |
| Den skal virke på mobil | Brukbar fra 360 px, testet på ekte enheter |
| Den skal være tilgjengelig | Oppfyller WCAG 2.1 nivå AA på hovedmalene |
| Enkel å drifte | Teamet oppretter og publiserer en side uten utvikler |
| Moderne design | Følger designmanualen; tre innledende forslag |
| Optimalisert for SEO | Redigerbare titler, nettstedskart, strukturerte data, videresendinger |
| Støtter flere språk | NO og EN ved lansering; struktur for å legge til flere |
Hva du skal la være#
For detaljerte dokumenter koster tid å skrive, tid å lese, og fratar utføreren muligheten til å foreslå noe bedre.
- Foreskriv ikke teknologi uten grunn. Angi problemet; la løsningen ligge i tilbudet.
- Skriv ikke teksten på hver knapp. Det løses med skjermer foran seg.
- Design ikke siden i ord. Visuelle referanser virker bedre enn beskrivelser.
- Ta ikke med funksjoner «til fremtiden» uten tydelig å merke dem som fase to.
- Kopier ikke krav fra et annet dokument uten å sjekke om de gjelder.
- Be ikke om det du ikke skal bruke. Hver funksjon har en bygge- og driftskostnad.
Overstiger dokumentet ti sider for en bedriftsside, spesifiserer du sannsynligvis løsningen i stedet for problemet.
Å bruke dokumentet underveis#
Dokumentet skal ikke arkiveres etter signering. Det er referansen som avgjør stridigheter.
- Send samme dokument til alle kandidater for å få sammenlignbare tilbud.
- Legg det ved avtalen, så det avtalte omfanget er det skrevne omfanget.
- Ber noen om noe nytt, så sjekk dokumentet før dere snakker om tidsplan.
- Registrer endringer i omfang skriftlig, med estimat, før arbeidet begynner.
- Bruk sidelisten som sjekkliste for innhold under byggingen.
- Ved overlevering går dere gjennom de etterprøvbare kravene ett om gangen.
Ofte stilte spørsmål
Hvor langt skal dokumentet være?
For en bedriftsside holder fem til ti sider. For et stort prosjekt med integrasjoner tjue til tretti. Overstiger du det markant, spesifiserer du sannsynligvis løsningen i stedet for problemet — og slike dokumenter har en tendens til å bli ignorert av alle, inkludert dem som skrev dem.
Skal jeg oppgi budsjettet?
Ja. Utføreren kan da foreslå det beste mulige prosjektet innenfor beløpet i stedet for å gjette. Den som ikke oppgir budsjett, får bud som varierer ti ganger og kan ikke sammenligne dem. Et intervall holder; du trenger ikke røpe den eksakte grensen.
Hvem skal skrive dokumentet?
Noen på kundesiden som kjenner forretningen, helst med støtte fra noen som kan web. Ber du et byrå skrive det, beskriver det naturlig det prosjektet byrået liker å lage — noe som kan være fint, men slutter å duge til å sammenligne tilbud. Gjør du det slik, så betal for den fasen separat.
Hva om kravene endrer seg underveis?
De endrer seg nesten alltid, og dokumentet hindrer det ikke — det organiserer det. Ha en endringsprosedyre: hver ny forespørsel får et skriftlig estimat før arbeidet begynner. Problemet er ikke endringer, men endringer som glir inn uten at noen justerer tid og budsjett.
kravdokument nettsidebrief nettsidekravspesifikasjon nettstedomfang nettprosjektanbud nettsidekrav nettprosjekt
