Kravspesifikasjon for nettside: en enkel mal

«Vi trenger en moderne nettside som gir flere kunder.» Det er et godt utgangspunkt for en samtale, men ikke nok til å vite hva som skal bygges eller hva tilbudet skal inneholde.

En kravspesifikasjon beskriver hva nettsiden skal gjøre, hvem den er for, og hvordan dere skal kontrollere at leveransen er ferdig. Den trenger ikke være full av tekniske uttrykk. Start med behovene dine, og avklar de tekniske valgene sammen med leverandøren.

Her får du en enkel mal, eksempler på tydelige krav og en sjekkliste du kan bruke før du bestiller en nettside.

1. Begynn med målet og brukeren

Skriv hva bedriften tilbyr, hvem som skal bruke siden, og hva de skal kunne gjøre. Beskriv heller kundens oppgave enn bare alder og kjønn.

Velg én hovedoppgave først. Andre mål kan være viktige, men ikke alle må få like mye plass på forsiden. Beskriv også hvilke land og språk nettsiden skal dekke.

2. Avklar hva som skal med i første versjon

Lag en liste over sidene: forside, tjenester, om oss, kontakt og eventuelle andre sider. Noter hva hver side skal hjelpe brukeren med. Skriv hvor mange tjenester, produkter eller språkversjoner leveransen omfatter.

Del ønskene i tre grupper:

• Må være med: Det som trengs for at løsningen skal kunne tas i bruk.
• Kan komme senere: Nyttige forbedringer som ikke stopper lanseringen.
• Er ikke inkludert: Arbeid dere foreløpig ikke bestiller.

For eksempel kan et kontaktskjema være nødvendig ved lansering, mens en kundeportal kan vente. En slik avklaring gjør det lettere å sammenligne tilbud som ellers kan se like ut.

Har dere en nettside fra før, skriv hva som skal beholdes, flyttes eller fjernes. Da blir ikke innholdsflytting en overraskelse mot slutten av prosjektet.

3. Beskriv hva som skal skje når kunden bruker siden

«Kontaktskjema» er en funksjon, men sier lite om hvordan den skal virke. Beskriv feltene, hva som er obligatorisk, hvem som mottar meldingen, og hva kunden ser etterpå.

Ta med det som kan gå galt: manglende informasjon, feil e-postadresse, gjentatte trykk eller en tjeneste som ikke svarer. Dere trenger ikke løse alt i første møte, men spørsmålene bør ha en ansvarlig.

4. Fordel ansvaret for tekst, bilder og design

Hvem skriver teksten? Hvem finner bilder? Hvem sjekker priser og oversettelser? Sett navn eller roller på oppgavene og avtal når materialet skal være klart.

Samle logo, farger og annet dere allerede bruker. Legg gjerne ved to eller tre nettsteder som referanser, men forklar hva du liker. «Tydelig meny og lettleste tjenestesider» er mer nyttig enn «lag noe lignende».

Avklar hvordan designet skal godkjennes før alle sidene bygges. Det kan være en skisse av forsiden og en tjenesteside, med eksempler for mobil og større skjerm. Les mer om hvordan vi jobber med UX/UI-design.

Ta også med hvem som oppdaterer innhold etter lansering. En løsning som er enkel for utvikleren, er ikke nødvendigvis enkel for den som skal bytte et bilde en travel arbeidsdag.

5. Gjør tekniske krav forståelige og mulige å teste

Du trenger ikke velge alle teknologier selv. Beskriv hva bedriften trenger å kunne gjøre, og be leverandøren forklare valg, kostnader og begrensninger.

• Hastighet: Avtal hvilke sidetyper som skal testes, med hvilket verktøy og under hvilke forhold.
• Tilgjengelighet: Avklar blant annet tastaturbruk, lesbarhet, feltnavn og forståelige feilmeldinger tidlig.
• Søk: Beskriv konkrete leveranser som sidetitler, interne lenker og håndtering av gamle nettadresser.
• Data og tilganger: Avklar hvilke opplysninger som samles inn, hvor de går, og hvem som trenger tilgang.
• Måling: Bestem hvilke handlinger dere vil registrere, for eksempel en sendt forespørsel, og hvem som tester oppsettet.

Hvis dere bruker Core Web Vitals som kvalitetsmål, er dagens måltall LCP, INP og CLS. De handler om lasting, respons og visuell stabilitet. En test før lansering er ikke det samme som målinger fra faktiske besøk. Avtal derfor både kontroll før lansering og eventuell oppfølging etterpå. Se Googles forklaring av Web Vitals.

Tilgjengelighet bør inngå i planleggingen, ikke legges til som en uklar sluttsjekk. W3C har veiledning om planlegging av tilgjengelighet. Avklar hvilke krav og kontroller som gjelder for deres løsning.

Skal den nye siden erstatte en gammel, bør dere kartlegge gamle og nye adresser og planlegge nødvendige videresendinger. Google beskriver dette i sin veiledning om flytting av nettsteder. Arbeidet kan inngå i teknisk SEO, men må være avtalt.

6. Avtal godkjenning, endringer og drift

For hvert viktig krav bør dere kunne svare på: Hvordan vet vi at dette er ferdig? Dette kalles ofte akseptansekriterier. I praksis er det en liste over hva løsningen må gjøre for å bli godkjent.

Avtal hvem som tester, hvem som samler tilbakemeldinger, og hvem som godkjenner lanseringen. Skill mellom feil i avtalt funksjonalitet og nye ønsker. Nye ønsker bør få en vurdering av pris og tid før arbeidet starter.

Be også om oversikt over løpende utgifter: drift, lisenser, eksterne tjenester og vedlikehold. Avklar hvilke tilganger og hvilken dokumentasjon bedriften får, hvordan sikkerhetskopier håndteres, og hvem dere kontakter når noe slutter å virke.

KI kan hjelpe med et første utkast til kravene, men innholdet må stemme med virksomheten. Se også hva KI kan bidra med i utvikling, og hva teamet bør kontrollere.

7. Kopier denne malen til ditt eget prosjekt

Du kan fylle ut punktene i et vanlig dokument. Skriv «må avklares» der du er usikker, og ta det med i samtalen med leverandøren.

En liten nettside trenger gjerne et kort dokument. Flere integrasjoner og kompliserte arbeidsprosesser krever mer avklaring. Målet er et felles arbeidsgrunnlag, ikke flest mulig sider med tekst.