Slik skriver du en kravspesifikasjon for appen din

Av Weapp · Oppdatert 2025-05-10

En god kravspesifikasjon for en app beskriver formål, målgruppe, de viktigste brukerflytene, integrasjoner og ikke-funksjonelle krav som ytelse og sikkerhet, på 5–15 sider. Den skal være tydelig nok til å gi sammenlignbare tilbud, men beskrive hva appen skal oppnå, ikke låse hvordan løsningen skal bygges. Detaljnivået øker med prosjektets faser.

Kravspesifikasjonen har én eneste jobb i tilbudsfasen: å få flere leverandører til å prissette det samme, uten å låse fast en løsning som viser seg å være feil. De fleste kravspesifikasjoner bommer i den ene eller den andre retningen. Enten er de så vage at tilbudene blir gjetting, eller så detaljstyrte at leverandørens kompetanse aldri kommer til nytte. Slik finner du riktig nivå.

Strukturmalen: seks avsnitt som tar deg langt

En kravspesifikasjon for tilbudsfasen trenger sjelden å være mer enn 5–15 sider, strukturert omtrent slik:

Formål og mål. Hvilket problem løser appen, for hvem, og hvordan vet dere om den lykkes? Et par målbare mål (f.eks. andelen henvendelser som flyttes fra telefon til app) styrer tusen detaljbeslutninger senere.
Målgruppe og brukssituasjon. Hvem er brukerne, hvor ofte bruker de appen, og i hvilket miljø? En app som brukes daglig av feltpersonell med hansker, stiller andre krav enn en som åpnes i sofaen én gang i måneden.
Brukerflyter. Beskriv de 5–10 viktigste tingene en bruker skal kunne gjøre, som brukerflyter: «brukeren tar bilde av kvitteringen, velger prosjekt, attestanten blir varslet». Prioriter i må/bør/kan. Det er prioriteringen som gjør tilbudene sammenlignbare og etapper mulige.
Integrasjoner. Hvilke systemer skal appen snakke med: ERP-system, innlogging, betaling, kart? Oppgi hva som finnes i dag (API-er? dokumentasjon?) for hvert system. Integrasjoner er blant de største kostnadsdriverne, og ukjente integrasjoner er den vanligste årsaken til sprukne budsjetter.
Ikke-funksjonelle krav. Ytelse, sikkerhet, GDPR, universell utforming, offlinestøtte, språk, plattformer og versjoner. Skriv bare krav dere mener alvor med. Hvert «appen skal fungere offline» koster faktisk penger.
Rammer og forutsetninger. Budsjettspenn, ønsket tidsplan, hvem hos dere som tar beslutninger, og hva som skal skje etter lansering (forvaltning, videreutvikling).

Feilene som gjør tilbudene umulige å sammenligne

Når tre tilbud på den samme kravspesifikasjonen skiller seg med en faktor på tre, er det som regel kravspesifikasjonen, ikke leverandørene, som er problemet. De vanligste årsakene:

Funksjoner uten prioritering. Hvis alt virker like viktig, prissetter én leverandør alt og en annen et fornuftig utvalg, og summene blir umulige å sammenligne.
Usynlige integrasjoner. «Kobling til ERP-systemet vårt» uten opplysninger om hvilket system, hvilken versjon og om det finnes et API. Én leverandør antar det enkle, en annen tar høyde for det vanskelige.
Løsningskrav forkledd som behov. «Appen skal ha en chattefunksjon.» Eller er behovet at brukerne raskt får svar? Kanskje holder det med FAQ og varsler. Beskriv behovet, og la løsningen være åpen.
Udefinerte begreper. «Enkel administrasjon», «høy sikkerhet», «rask». Sett tall eller eksempler på alt som lar seg tallfeste: Hva skal en administrator kunne gjøre, hvilke data er sensitive, og hvor raskt er raskt?
Ingen opplysninger om hva som finnes. Eksisterende design, grafisk profil, backend, kontoer? Det som allerede finnes, skal ikke prissettes på nytt.

En god test: Kan to personer lese kravspesifikasjonen og tegne omtrent den samme appen på en tavle? Hvis ikke, må brukerflytene bli tydeligere.

Riktig detaljnivå i riktig fase

Kravspesifikasjonen er ikke et dokument som blir ferdig én gang. Detaljnivået skal vokse med prosjektet:

Idéfase: én side. Problem, målgruppe, forretningsidé. Det holder for å teste ideen på kolleger og få grove prisindikasjoner.
Tilbudsfase: 5–15 sider etter malen ovenfor. Tydelige brukerflyter og rammer, åpen løsning. Det er her sammenlignbarheten avgjøres.
Oppstartsfase: Kravspesifikasjonen brytes ned sammen med den valgte leverandøren til en prioritert backlog, skisser og tekniske beslutninger. Nå kan detaljene komme, med kunnskapen til utviklerne og designerne i rommet.
Under utviklingen: Kravene finpusses for hver etappe. Å detaljere flyt 8 før flyt 1 er bygd, er bortkastet, for dere kommer til å lære ting som endrer planen.

Å skrive hele den detaljerte kravspesifikasjonen på forhånd føles trygt, men bygger på illusjonen om at dere allerede vet alt. De beste prosjektene låser målbildet tidlig og detaljene sent.

Kom i gang

Begynn med formål, målgruppe og de fem viktigste brukerflytene. Det er 80 prosent av verdien. Vil du ha et ekstra par øyne på kravspesifikasjonen din, eller hjelp til å utarbeide den gjennom en kort forstudie? Vi i Weapp gjør det jevnlig for kunder, fra MVP-er til store systemapper. Ta kontakt, så ser vi på den sammen.

Ofte stilte spørsmål

Hvor lang skal en kravspesifikasjon være?

I tilbudsfasen holder det som regel med 5–15 sider. Er den kortere, blir tilbudene gjetting. Er den lengre, har du sannsynligvis begynt å designe løsningen for leverandøren. Detaljene vokser deretter frem i løpet av prosjektet, brukerflyt for brukerflyt, sammen med teamet som bygger.

Trenger jeg skisser eller design i kravspesifikasjonen?

Enkle skisser av de viktigste skjermbildene hjelper mer enn lange tekstbeskrivelser, også håndtegnede. De viser hva du mener, og avslører hull i tankegangen. Men ikke bestill ferdig design før leverandøren er valgt. Designen er en del av arbeidet du kjøper og formes best i fellesskap.

Hva er ikke-funksjonelle krav?

Krav til hvordan appen skal fungere, heller enn hva den skal gjøre: ytelse, universell utforming, sikkerhet, etterlevelse av GDPR, oppførsel uten nett, skalerbarhet og hvilke plattformversjoner som skal støttes. De blir ofte glemt i kravspesifikasjoner, men driver en stor del av kostnaden, så leverandører som ikke får dem, antar ulike ting.

Bør jeg kreve en bestemt teknologi i kravspesifikasjonen?

Bare hvis du har en reell grunn, for eksempel en eksisterende kodebase eller intern kompetanse som skal forvalte løsningen. Ellers: Beskriv behovet, og la leverandørene begrunne teknologivalgene sine i tilbudet. Hvordan de resonnerer rundt valget, sier mye om hvor erfarne de er, og du unngår å låse deg til feil løsning.

Kan leverandøren hjelpe til med å skrive kravspesifikasjonen?

Ja, mange byråer tilbyr forstudier der kravene utarbeides i fellesskap. Det gir ofte en bedre kravspesifikasjon enn om du skriver den alene, men gjør det hos en part du kan tenke deg ikke å bruke til selve byggingen. Ellers blir kravspesifikasjonen lett formet etter nettopp den partens løsning. Eierskapet til dokumentet skal være ditt.