Hopp til innhold
apphavn
[email protected]Be om tilbud

Guider

Kravspesifikasjon mal for app – med utfylt eksempel

Av AppHavn. Sist oppdatert: 18. september 2026.

Det første et byrå spør om når dere ber om pris, er hva appen skal gjøre. Svarer dere med tre setninger på e-post, får dere tre helt forskjellige tilbud fra tre leverandører, fordi hver av dem har gjettet på resten. Svarer dere med en kravspesifikasjon, får dere tilbud som kan legges ved siden av hverandre.

Be om tilbudPrøv appkalkulatoren
Kort oppsummert

En kravspesifikasjon for app er et dokument på 3–8 sider som beskriver hva appen skal gjøre, for hvem, og hva som må være med i første versjon. Den trenger ikke være teknisk. Med den i hånden priser alle leverandørene samme app, tilbudene kan sammenlignes, og endringer underveis blir færre og mindre kostbare. Under finner dere en tom kravspesifikasjon som mal, med elleve deler, og et eksempel på hvordan en ferdig utfylt spesifikasjon for en treningssenter-app ser ut.

Denne guiden gir dere en mal for kravspesifikasjon til app som er laget for bedrifter uten teknisk bakgrunn, og et utfylt eksempel dere kan bruke som utgangspunkt. Malen følger samme struktur som kravspesifikasjonen dere får i en appavklaring hos oss. De elleve delene fungerer også for andre IKT-prosjekter, som et fagsystem eller en kundeportal.

01

Hvorfor en kravspesifikasjon gir bedre og mer presise tilbud

En app prises som timer ganger timepris, og timene bestemmes av hvor mange skjermer, flyter, integrasjoner og krav som skal bygges. Uten en spesifikasjon må leverandøren enten gjette lavt for å vinne jobben, og ta det igjen på endringer, eller gjette høyt for å dekke risikoen. Begge deler taper dere på.

Med en spesifikasjon priser leverandørene det samme, så dere kan sammenligne. Dere oppdager selv hva dere ikke har tenkt på, før det koster noe. Og dere har et dokument å peke på når noen senere sier «det var jo avtalt». Spesifikasjonen trenger ikke være perfekt, bare ærlig om hva dere vet og ikke vet.

02

Kravspesifikasjon: mal for app, del for del

Bruk overskriftene under som de er. Under hver står hva som skal inn, og hvor mye. Last ned malen som dokument:

  1. 01

    Bakgrunn og mål

    To til fem setninger om hvem dere er, hvilket problem appen løser, og hva som skjer i dag uten den. Skriv målet som noe som kan måles: færre telefoner til kundeservice, flere bookinger, mindre papir i felt.

  2. 02

    Målgrupper

    Hvem skal bruke appen, hvor mange er de, hvilke telefoner har de, og i hvilken situasjon bruker de den. En ansatt med hansker i en kald bil stiller andre krav enn en kunde i sofaen. Skill mellom brukergrupper med forskjellige behov, for eksempel medlemmer og ansatte.

  3. 03

    Brukerhistorier og flyter

    Beskriv det viktigste brukeren skal gjøre, én ting per linje, i formen «Som [bruker] vil jeg [gjøre noe] for å [oppnå noe]». Velg deretter den ene flyten som er viktigst, og beskriv den steg for steg fra brukeren åpner appen til oppgaven er løst. Det er denne flyten som avgjør om appen er en MVP eller en bedriftsapp.

  4. 04

    Funksjoner, prioritert etter MoSCoW

    List opp alle funksjonene dere kan komme på, og sorter dem i fire grupper: Must have (må være med i første versjon), Should have (bør være med, men kan vente kort), Could have (fint hvis budsjettet tillater det) og Won't have (bevisst utelatt nå). Vær streng med Must have. Alt som havner der, skal finnes før appen kan lanseres.

  5. 05

    Plattformer

    iPhone, Android eller begge? Nettbrett? Webversjon? Hvilke versjoner av iOS og Android må støttes, gjerne uttrykt som «telefoner yngre enn fire år». Skriv om dere har en mening om native eller kryssplattform, eller vil ha leverandørens anbefaling. Se guiden native, hybrid eller webapp.

  6. 06

    Integrasjoner

    Hvilke systemer skal appen snakke med: Vipps, BankID, ID-porten, regnskap som Fiken eller Tripletex, medlemssystem, kassesystem, kart. For hvert system: har det et API, har dere avtale og tilgang, og hvem hos dere kan svare på spørsmål. Integrasjoner er den vanligste kilden til forsinkelser, så vær konkret.

  7. 07

    Ikke-funksjonelle krav

    Kravene til hvordan appen skal oppføre seg. Ytelse: hvor mange brukere samtidig. Offline: må appen fungere uten dekning. Sikkerhet: hvilke data er sensitive, hvem skal ha tilgang til hva. Personvern: hvilke personopplysninger behandles, hvor skal dataene lagres, trengs det en vurdering av personvernkonsekvenser etter Datatilsynets kriterier. Universell utforming: er appen rettet mot allmennheten, og dermed omfattet av WCAG-kravene, 29 minstekrav for private virksomheter og 42 for offentlige.

  8. 08

    Innhold og språk

    Hvem leverer tekster, bilder, ikoner og logo, og når. Hvilke språk skal appen ha. Finnes det en designprofil som skal følges. Manglende innhold er en vanlig grunn til at ferdige apper ikke lanseres.

  9. 09

    Drift og forvaltning

    Hvem skal drifte backend og betale hosting. Hvem eier App Store- og Google Play-kontoene. Hvilket nivå av vedlikehold og support forventer dere etter lansering, og hvor raskt skal feil rettes. Se vedlikehold og drift av app.

  10. 10

    Budsjett og tid

    Oppgi et budsjettspenn, også om det er omtrentlig, så leverandøren kan foreslå et omfang som passer i stedet for å gjette. Skriv ønsket lanseringsdato og hvorfor. Se prisnivåene i hva koster det å lage en app.

  11. 11

    Suksesskriterier

    Hvordan vet dere om appen har lykkes etter tre måneder? Tall som andel av medlemmene som bruker appen ukentlig, eller antall skjemaer levert i appen i stedet for på papir. Skriv også hvordan det skal måles.

03

Eksempel: kravspesifikasjon for en treningssenter-app

Eksempelet under er skrevet for et tenkt treningssenter, Treningssenter AS, med ett senter og rundt 1 200 medlemmer. Det er kortet ned, men alle delene er med.

  • 01Bakgrunn og målTreningssenter AS driver ett senter med gruppetimer og fri trening. Booking av gruppetimer skjer i dag via nettside og telefon, og resepsjonen bruker mye tid på avbestillinger og ventelister. Målet er at 60 prosent av bookingene skjer i appen innen tre måneder, og at telefoner om booking halveres.
  • 02MålgrupperMedlemmer, ca. 1 200 personer i alderen 16–75, med både iPhone og Android. Ansatte i resepsjon og instruktører, 12 personer, som trenger oversikt over påmeldte. Appen brukes hjemme, på jobb og i garderoben, ofte med dårlig dekning i kjelleren.
  • 03Brukerhistorier og flyterSom medlem vil jeg se timeplanen og booke en gruppetime for å sikre plass. Som medlem vil jeg få beskjed når det åpner seg plass på en full time. Som medlem vil jeg sjekke inn med telefonen for å slippe kort. Som instruktør vil jeg se hvem som er påmeldt timen min. Kjerneflyt: åpne app, se dagens timer, velge time, bekrefte, få kvittering, få påminnelse en time før.
  • 01

    Must have

    Funksjoner
    Innlogging med e-post og engangskode, timeplan, booking og avbestilling, venteliste med push-varsel, påminnelse, deltakerliste for instruktør
  • 02

    Should have

    Funksjoner
    Innsjekk med QR-kode i døra, medlemsprofil med medlemskapstype, norsk og engelsk
  • 03

    Could have

    Funksjoner
    Treningsprogram fra PT, statistikk over egen trening, Vipps-betaling av drop-in-timer
  • 04

    Won't have

    Funksjoner
    Chat, sosiale funksjoner, kostholdslogg, egen nettbutikk
  • 05PlattformeriPhone og Android, telefoner yngre enn fire år. Ingen nettbrett- eller webversjon i første omgang. Vi ønsker leverandørens anbefaling om kryssplattform.
  • 06IntegrasjonerMedlemssystemet har et API vi har tilgang til; daglig leder hos oss er kontaktperson. Vipps ePayment for drop-in-timer er Could have, og vi har ikke Vipps-avtale ennå. Adgangssystemet i døra støtter QR-kode, dokumentasjon finnes.
  • 07Ikke-funksjonelle kravInntil 300 samtidige brukere ved timeslipp mandag kl. 20. Timeplanen skal kunne leses uten dekning, booking krever nett. Appen behandler navn, e-post, telefonnummer og bookinghistorikk, ingen helseopplysninger. Data skal lagres i EØS, og vi trenger databehandleravtale. Appen er rettet mot medlemmer, altså allmennheten, og skal følge WCAG-kravene for private virksomheter, med minst 4,5:1 kontrast og støtte for skjermleser og tekstskalering.
  • 08Innhold og språkVi leverer logo, farger og timeplan. Tekster i appen skrives av leverandøren og godkjennes av oss. Norsk først, engelsk som Should have.
  • 09Drift og forvaltningVi oppretter egne kontoer hos Apple og Google. Leverandøren drifter backend på vår hostingkonto. Vi ønsker en vedlikeholdsavtale med svar innen én virkedag.
  • 10Budsjett og tidBudsjett 120 000–200 000 kr eks. mva. for første versjon. Ønsket lansering 1. januar, fordi januar er største innmeldingsmåned.
  • 11Suksesskriterier60 prosent av bookinger i appen etter tre måneder, målt i medlemssystemet. Minst 40 prosent av medlemmene har logget inn i appen minst én gang per uke. Telefoner om booking halvert, målt av resepsjonen i én uke før og én uke etter.

Med denne spesifikasjonen ville et byrå kunne prise appen ganske presist. Must have-listen tilsvarer en bedriftsapp med innlogging, backend, push og én integrasjon, som hos oss starter på 100 000 kr. Med budsjettet på 120 000–200 000 kr er en bedriftsapp innen rekkevidde, og forslaget vil likevel være å lansere en MVP først, fra 20 000 kr: booking med venteliste og push først, deltakerlisten for instruktører hentet fra medlemssystemet de allerede har, og innsjekk og engelsk i runde to. Nettopp den samtalen er poenget med dokumentet. Se også hva vi bygger for treningssentre, idrettslag og foreninger.

04

Vanlige feil i kravspesifikasjoner

Den vanligste er at alt er Must have. Da har dere ikke prioritert, og leverandøren må gjøre det for dere. Den nest vanligste er å beskrive løsningen i stedet for behovet: «en knapp øverst til høyre som åpner et kart» i stedet for «brukeren må finne nærmeste senter». Løsninger er byråets jobb, behov er deres.

Andre vanlige feil: integrasjoner som nevnes uten at noen har sjekket om systemet har et API, ingen ord om personvern eller universell utforming, og ingen suksesskriterier. Alle fire koster mer å rette etter at kontrakten er signert.

05

Vanlige spørsmål om kravspesifikasjon for app

Hvor lang bør en kravspesifikasjon for app være?

Tre til åtte sider holder for de fleste bedriftsapper. Lengre dokumenter blir sjelden lest, og kortere svarer ikke på det leverandøren trenger. Bruk tabeller for funksjonslisten og skriv resten som vanlig prosa. Skisser eller skjermbilder fra lignende apper er verdt mer enn to ekstra sider tekst.

Må vi ha kravspesifikasjon før vi ber om tilbud?

Nei, men uten den får dere tilbud som ikke kan sammenlignes, og fast pris blir gjetting. Alternativet er å la en leverandør lage spesifikasjonen sammen med dere først, som i vår appavklaring, og bruke den til å hente tilbud, også fra andre.

Hva er MoSCoW?

MoSCoW er en prioriteringsmetode der hver funksjon sorteres som Must have, Should have, Could have eller Won't have. O-ene er bare med for å gjøre ordet uttalbart. Metoden ble laget av Dai Clegg i 1994 og brukes fordi den tvinger fram et valg om hva som må være med i første versjon.

Kan dere lage kravspesifikasjonen for oss?

Ja. I appavklaringen bruker vi to dager sammen med dere på mål, brukere, flyter, integrasjoner og prioritering, og leverer kravspesifikasjon, skisser, teknisk arkitektur og bindende pristilbud innen en uke. Prisen er 20 000 kr eks. mva., og dokumentene er deres uansett hvem som bygger appen.

06

Les også

Neste steg

Få kravspesifikasjonen laget på to dager

Vil dere heller ha hjelp til spesifikasjonen? I appavklaringen går vi gjennom alle elleve delene sammen med dere, og dere får kravspesifikasjon, skisser og et bindende pristilbud innen en uke. Beløpet på 20 000 kr trekkes fra prosjektprisen om dere går videre med oss.

Book appavklaring (20 000 kr)Be om tilbud

Eller skriv til[email protected]

Kilder