Kravspesifikasjon for nettside: slik bestiller du riktig

Hva dokumentet skal svare på

Kravspesifikasjonen skal beskrive hva den nye nettsiden må oppfylle av funksjonalitet, integrasjoner mot andre systemer, oppetid og rammer rundt drift og innhold. Den er ikke en ønskeliste. Den bestemmer hva som skal leveres, og hvilke mål nettsiden skal nå. Begynn gjerne med den komplette guiden for nettside for bedrift før du går i detalj.

Det viktigste avsnittet handler om brukermål: hva målgruppen kommer til nettsiden for å gjøre. Finne informasjon, kjøpe et produkt, bestille en time eller ta kontakt. Det er vanskelig å beskrive helt presist, men skriv i det minste en generell beskrivelse av hva de fleste besøkende er der for. Da blir det lettere å prioritere hvilke funksjoner som faktisk må med.

Involver de som skal leve med nettsiden etterpå, ikke bare den som bestiller. De som svarer på henvendelser, selger eller oppdaterer innhold, ser behov som en innkjøper ikke ser.

Funksjonskrav: konkret uten å bli teknisk

Vanlige eksempler er søkefunksjon, bestillings- og betalingsløsning, kontaktskjema, mulighet for å overstyre metabeskrivelse, støtte for flere språk, chat og løsning for samtykkehåndtering. Skriv hvert krav som en setning med hvem som bruker det, og hva som er godt nok.

Søk er et godt eksempel. Skal det søkes i produkter, sider eller begge deler, og skal treffene kunne filtreres? Søkefunksjon på nettside går gjennom hva som gjør søket brukbart i praksis. Bruk samme presisjon på bestilling, betaling og skjema.

Integrasjoner driver ofte kostnadene. Regnskap, booking, lager, e-post og nyhetsbrev bør nevnes med navn, ikke som «integrasjoner ved behov». Vurderer du chat eller automatisert kundeservice, kan du lese om AI og nettside og beskrive hva assistenten skal svare på, og hva den ikke skal svare på.

Tekniske krav, sikkerhet og drift

Skriv krav til oppetid, sikkerhetskopi, oppdateringer og hvem som har ansvar når noe stopper. Er det viktig for deg at tjenesten driftes på fornybar energi, må det stå i dokumentet, ellers blir det ikke priset.

Sikkerhet er ikke bare for store bedrifter. HTTPS, tilgangsstyring og hvordan personopplysninger behandles hører hjemme her. Sikker nettside: slik beskytter du bedriften viser hvilke spørsmål du kan stille før du signerer.

Ta også med hvordan kravene skal testes og godkjennes. Skal du få en skriftlig gjennomgang ved overlevering? Et krav uten en måte å kontrollere det på, forsvinner lett i en travel prosjektperiode.

Universell utforming som etterprøvbart krav

Nettsider i Norge skal være universelt utformet, slik at alle kan bruke dem, også personer med nedsatt syn, hørsel eller motorikk. Kravene bygger på den internasjonale standarden WCAG, og Uutilsynet fører tilsyn. Skriv at nettsiden skal oppfylle gjeldende krav, og be leverandøren beskrive hvordan det blir testet.

Gjør kravet konkret nok til å kunne etterprøves. Kontrast, tastaturnavigasjon, tekstalternativ på bilder, merkede skjemafelt og lesbare dokumenter er ting du kan peke på i en gjennomgang. Be om at dette testes før lansering, ikke som et oppryddingsprosjekt året etter.

Kravet påvirker også redigeringen. Hvis du skal skrive innhold selv, må malene i publiseringsløsningen hjelpe deg å holde kravene uten at du kan standarden utenat.

Eierskap, data og veien ut av avtalen

Avtal hva som skjer den dagen du vil bytte leverandør. Leverandøren kan forsvinne, bli kjøpt opp eller endre forretningsmodell, og da er det dumt å stå på bar bakke med en nettside du har investert mye i. Skriv inn at løsningen skal kunne flyttes, eller at du skal kunne beholde den og bytte driftsleverandør.

Praktisk betyr det at domenet står i bedriftens navn, at du har egne innlogginger til publiseringsløsningen, og at du kan få ut innhold og data i et brukbart format. Be om dokumentasjon på oppsettet mens prosjektet er ferskt.

Ta med krav om at du kan endre tekst og bilder selv. Hvis alt må bestilles, påløper det kostnader hver gang du skal rette en pris eller legge ut en nyhet.

Slik bruker du dokumentet i tilbudsrunden

Send samme kravspesifikasjon til alle du ber om tilbud. Be dem svare punkt for punkt, slik at du ser hvor de er enige, hvor de foreslår noe annet, og hva de ikke har tenkt på. Da unngår du å sammenligne et enkelt nettsted med en løsning som inneholder booking og flere integrasjoner.

Vær skeptisk til tilbud som starter med en lav sum og en lang liste med tillegg. Når kravene er uklare, er det nettopp der kostnadene kan løpe løpsk etter at prosjektet er i gang. Be om pris på hele leveransen, og om hvordan endringer underveis håndteres.

Bruk dokumentet også etter lansering. Gå gjennom kravene mot det som faktisk er levert, og skriv en kort godkjenning når punktene er oppfylt. Trenger du støtte i vurderingen, finnes det hjelp fra en profesjonell som kan se på krav og tilbud sammen med deg.

Vil du se hva tjenesten for nettsider innebærer i praksis, kan du booke en demo hos Nettsaga: book en demo.

Vanlige spørsmål

Hvor detaljert må en kravspesifikasjon være?

Den trenger ikke være et langt teknisk dokument. Den må være presis nok til at to leverandører priser samme oppgave, og kort nok til at du selv forstår den.

Kan jeg skrive kravspesifikasjonen selv?

Ja, men få hjelp til det tekniske. Du kjenner kundene og arbeidsflyten best, mens en fagperson kan kvalitetssikre krav til sikkerhet, integrasjoner og universell utforming.

Bør jeg bruke en mal for kravspesifikasjon?

En mal er nyttig som sjekkliste, men må tilpasses bransjen din. Fjern krav som ikke gjelder, slik at dokumentet ikke fylles med punkter ingen har bruk for.

Hva koster en kravspesifikasjon for nettside?

Det avhenger av omfanget og av om den skrives internt eller av noen med erfaring. Be om pris på dokumentet som en egen leveranse, uavhengig av hvem som skal bygge nettsiden.

Hva om jeg ikke vet hvilke funksjoner jeg trenger?

Start med brukermålene: hva besøkende skal få gjort. Funksjoner som ikke støtter et brukermål, kan strykes. Det gir et kortere dokument og en enklere leveranse.