Kravspesifikasjon for mobilapp: mal på én side

Kravspesifikasjon for en mobilapp: det korte svaret

En god kravspesifikasjon for en mobilapp får plass på én side når du lager din egen app. Den svarer på ti spørsmål: hvem den er for, hvilket problem den løser, hva hovedfunksjonen er, hvordan appen tjener penger, hva som skjer uten konto, hvilke data som må overleve, hvilken plattform, hva som ikke er med i første versjon, hvordan du vet at det fungerer, og hvilke begrensninger du har. Malen du kan kopiere finner du lenger ned. Du kan også laste ned malen med sjekklisten (.md), uten registrering.

Malene på 40 sider du finner på nettet er skrevet for et annet formål: en kunde som bestiller en app fra et byrå og trenger et kontraktsdokument. Du er både den som bestemmer og den som bygger, ofte med hjelp fra AI. Kravspesifikasjonen din har to jobber: å ta beslutningene før du koder, og å gi Claude, ChatGPT eller Cursor tydelig kontekst så de bygger riktig app.

Jeg publiserer mine egne iOS-apper. Solys, en vekkerklokke med minispill, og TradaZen, en tradingsimulator, ligger på App Store. Nolera og Clic ble avvist av Apple, og så rettet. Dette er metoden jeg bruker på hver av dem, og det er den jeg foreslår for deg her.

Hvorfor én side holder for å ramme inn din egen app

Et langt dokument gir følelsen av å ha kommet langt. I praksis blir det skrevet én gang, sjelden lest igjen, og prosjektet glir bort fra det allerede de første ukene. En side, derimot, leser du på to minutter før hver arbeidsøkt.

Plassbegrensningen har også en nyttig effekt: den tvinger deg til å bestemme deg. Hvis et svar blir lengre enn to setninger, er beslutningen ofte ikke tatt. Det er bedre å oppdage det på et ark enn i koden din tre uker senere.

Og én side er riktig størrelse for AI-en. Du kan lime inn hele siden i en samtale, eller legge den i kontekstfilen til prosjektet. Et kort dokument er lettere å lese gjennom og gir færre motstridende instruksjoner. Det garanterer ikke at AI-en følger dem: sjekk forslagene dens opp mot denne rammen.

Hva skal en kravspesifikasjon for en mobilapp inneholde?

Svar på hvert av disse spørsmålene med én eller to setninger.

1. Hvem bruker appen, og i hvilken situasjon? Ikke «18-35 år». Heller en konkret person, på et konkret tidspunkt i løpet av dagen.
2. Hvilket problem løser appen, i én setning? Trenger du «og i tillegg», beskriver du to apper.
3. Hva er DEN ene hovedfunksjonen i første versjon? Bare én. Resten venter på tallene. Siden MVP for iOS-app forklarer hvordan du velger.
4. Hvordan tjener appen penger? Abonnement, engangskjøp eller gratis. Svaret endrer appen fra første skjerm. Er du usikker, les abonnement eller engangskjøp for en iOS-app.
5. Hva kan man gjøre uten å opprette konto? Bestemmer du tidlig hva som er tilgjengelig uten registrering, slipper du å lage hele onboardingen på nytt.
6. Hvilke data må overleve et bytte av telefon? Dette spørsmålet avgjør om du trenger en backend som Supabase, eller om alt kan bli liggende på enheten.
7. Bare iOS, eller iOS og Android? Mitt råd når du er nybegynner: iOS først. Jeg forklarer hvorfor i iOS- og Android-app samtidig.
8. Hva er uttrykkelig UTENFOR første versjon? Den mest nyttige delen av dokumentet. Den stopper diskusjonene før de oppstår, både med deg selv og med AI-en.
9. Hvordan vet du at det fungerer? Ett enkelt signal, målbart i ukene etter lansering: startede gratisperioder, abonnenter, brukere som kommer tilbake.
10. Hva er de reelle begrensningene dine? Tiden du kan bruke på det hver uke, utstyret ditt og Apple Developer-kontoen din, som koster 99 $ i året. Ingen Mac? Det stopper deg ikke, som jeg forklarer i publisere en iOS-app uten Mac.

Malen for kravspesifikasjonen som du kan kopiere

Kopier malen inn i et notat eller en tekstfil i rotmappen til prosjektet, og fyll ut hver linje.

• Foreløpig navn på appen: …
• For hvem: en person som … i det øyeblikket …
• Problemet som løses, i én setning: …
• Hovedfunksjon i versjon 1: …
• Det brukeren ser første gang appen åpnes: …
• Forretningsmodell: abonnement / engangskjøp / gratis, og hva som koster penger: …
• Uten konto kan man: …
• Data som skal bevares mellom to telefoner: ingen / …
• Plattform: iOS først (Android senere hvis tallene tilsier det)
• Utenfor versjon 1: …, …, …
• Suksessignal: …
• Stack: React Native, Expo, Supabase hvis det trengs kontoer, RevenueCat for abonnementer
• Begrensninger: … timer i uka, Apple Developer-konto opprettet eller ikke, Mac eller ikke
• Apper med en opplevelse jeg liker, og hvorfor: …

Legg til tre til fem skjermbilder av apper du liker, med et ord om hva du liker. Det sier mer enn en designmanual, både for deg og for AI-en.

En kravspesifikasjon er ikke en ønskeliste. Det er en liste over beslutninger som er tatt.

Eksempel: siden utfylt for en oppdiktet app

For å vise hvor detaljert det skal være, her er malen utfylt for en app jeg har funnet på til eksempelet: en tidtaker for lesing.

• For hvem: en student som leser alene om kvelden og mister fokus etter ti minutter.
• Problem: hen klarer ikke å holde en arbeidsøkt uten å røre telefonen.
• Hovedfunksjon: starte en tidtatt økt og se rekken av dager man har holdt ut.
• Første skjerm: én knapp for å starte en økt.
• Forretningsmodell: abonnement for detaljert statistikk, grunnleggende økt gratis.
• Uten konto: alt, unntatt sikkerhetskopi mellom to telefoner.
• Utenfor versjon 1: gruppemodus, rangering mellom venner, widgets, Android-versjon.
• Suksessignal: brukere som kommer tilbake flere dager på rad.

Legg merke til hva som bevisst mangler: ingen liste over tjue skjermer, ingen påtvungne farger, ingen arkitektur. De valgene kommer mens du bygger, og siden hjelper deg å sjekke at de fortsatt tjener hovedfunksjonen.

Slik bruker du kravspesifikasjonen til å styre AI-en

Det er her siden din gir mest igjen. En AI som koder uten kontekst gjetter, og den gjetter ofte på en annen app enn din.

Legg siden i prosjektets faste kontekst. Claude Code leser en CLAUDE.md-fil i rotmappen, Cursor har sine egne regelfiler. Lim inn kravspesifikasjonen der, sammen med stacken din. Da starter hver forespørsel fra samme grunnlag.

Vis til delen «utenfor versjon 1» når AI-en gjør for mye. Assistentene foreslår gjerne ekstra funksjoner: mørk modus, deling, et varsel. Listen over det som er utelatt gir deg et ferdig svar: ikke nå.

Be om en plan som følger siden. Før en stor oppgave skriver du: «her er kravspesifikasjonen min, foreslå en plan for hovedfunksjonen, ikke kod ennå». Du ser med en gang om planen fjerner seg fra det du har bestemt.

La den lese gjennom siden, ikke bare koden. Spør: «hvilke spørsmål i denne kravspesifikasjonen er uklare eller motstridende?». Det er en undervurdert måte å bruke AI på, og den sparer deg for uker med arbeid i feil retning.

Vil du gå videre med dette, har jeg gått gjennom fallgruvene og sjekkene i lage en iOS-app med AI.

Gjør beslutningene om til akseptkriterier

En hovedfunksjon må ha et resultat du kan observere. For den oppdiktede tidtakeren i eksempelet er «tidtakeren fungerer» for vagt. Skriv heller: «Jeg starter en økt, gjenværende tid vises, jeg kan stoppe den og finne igjen den siste fullførte økten etter at jeg har åpnet appen på nytt.» Bestem separat om tidtakeren skal fortsette med låst skjerm: det valget kan endre det tekniske arbeidet.

Legg til tre linjer for hver funksjon: handling, forventet resultat, bevis. Beviset kan være en automatisert test for en beregning eller en sjekk på enheten for en brukerflyt. Skriv også ned hva som ikke er testet. Denne lille sjekklisten gjør at du ikke forveksler en ferdig skjerm med en funksjon som er klar til bruk.

Her er en utfylt sjekkliste for den oppdiktede tidtakeren vår. Dette er kriterier som skal sjekkes, ikke tester som allerede er bestått:

Beslutning i rammen	Hva som testes	Forventet resultat
Grunnleggende økt er tilgjengelig uten konto	Installer appen og start en økt uten å registrere deg	Ingen registreringsskjema blokkerer starten
En avbrutt økt teller ikke i rekken	Stopp en økt før den er ferdig, og åpne historikken	Ingen fullført økt blir lagt til
Historikken blir liggende på enheten	Fullfør en økt, lukk appen og åpne den igjen	Økten vises bare én gang med riktig varighet
Den grunnleggende tidtakeren fungerer uten nett	Slå på flymodus og fullfør en økt	Tidtakeren og den lokale lagringen kan fortsatt brukes
Detaljert statistikk koster penger	Åpne statistikken uten abonnement	Tilbudet vises; den grunnleggende økten er fortsatt tilgjengelig

Det som fortsatt er uklart, blir beslutninger som må tas. For eksempel: hva skjer hvis brukeren låser skjermen eller endrer klokka på telefonen under en økt? Ikke la agenten velge i det stille. Skriv ned ønsket oppførsel, og legg tilfellet til i sjekklisten. For å organisere denne testingen på en ekte installasjon, bruk guiden teste iPhone-appen din med TestFlight.

Bestem hva som skal ut når første versjon vokser seg for stor

Gå gjennom hver funksjon og still ett spørsmål: «Kan brukeren fortsatt få det lovede resultatet uten den?» For tidtakeren vår kan en rangering mellom venner vente. Å finne igjen en fullført økt er nødvendig hvis du lover en rekke av dager. En abonnementsskjerm blir nødvendig bare hvis du faktisk selger statistikken allerede i denne versjonen.

Skriv ned beslutningen og begrunnelsen i loggen i den nedlastbare malen. Da kan du endre valget etter testing uten å miste hvorfor det opprinnelige omfanget ble som det ble. Veiledningen lage en app med Claude Code viser deretter hvordan du gjør denne rammen om til avgrensede forespørsler du kan sjekke.

For en erfaring fra virkeligheten: TradaZen endret omfang etter at den ble publisert. Rammen er der for å få ut en første versjon som kan måles, og så bestemme den neste ut fra ekte tilbakemeldinger.

Fellen med funksjonskatalogen

Den naturlige refleksen er å liste opp alt appen «skal gjøre»: kartet, chatten, varslene, vervingen, frakoblet modus. Denne katalogen er det sikreste tegnet på et prosjekt som aldri blir ferdig, av en enkel grunn: hver funksjon du legger til før lansering utsetter tidspunktet der ekte brukere forteller deg hva som betyr noe.

En god første versjon gjør én ting, og gjør den bra. Men pass deg for det motsatte ytterpunktet: Apple krever at en app er mer enn en innpakket nettside, ifølge regel 4.2 i App Review Guidelines. Én hovedfunksjon, ja; et tomt skall, nei: det er avvisningsgrunnen i guideline 4.2.

Dette skal ikke stå i en kravspesifikasjon for en mobilapp

• En komplett designmanual. Noen referanseskjermbilder holder i starten.
• En dag-for-dag-plan. Du har ikke informasjonen til å holde den ennå. Et ukesmål holder.
• En detaljert teknisk arkitektur. Velg en velprøvd stack, og la detaljene avgjøres mens du bygger.
• Funksjoner «til senere» blandet med resten. De hører alle hjemme i delen utenfor versjon 1.

Når bør du oppdatere kravspesifikasjonen?

Les den i starten av hver arbeidsuke. Oppdater den bare når en beslutning endres av en ekte grunn: en test på iPhonen din som viser at en skjerm ikke fungerer, en tilbakemelding fra en tester, en begrensning fra Apple du oppdager underveis. Endrer du den hver dag, rammer den ikke inn noe lenger.

Når første versjon er publisert, blir siden grunnlaget for den neste: det som var utenfor versjon 1 kommer opp, sortert etter hva tallene forteller deg. Oversikten over hele løpet, fra idé til publisering, finner du på siden lage en iPhone-app.

Fra siden til den publiserte appen

Har du svart på de ti spørsmålene, har du allerede gjort jobben mange prosjekter hopper over. Det neste er å bygge hovedfunksjonen, teste den på iPhonen din, koble på abonnementene og forberede alt for Apple.

Dette løpet er det iOS Kit følger, i fire trinn i ditt eget tempo: det første handler om å velge appen som kan tjene penger, målgruppen og prisen, og kravspesifikasjonen din er utgangspunktet.

Usikker på om idéen din er klar til å få plass på én side? Den gratis diagnosen forteller deg hva som stopper prosjektet ditt i dag og hvilket trinn du bør ta først. Forsiden viser deretter hvordan du kan lage en mobilapp ut fra denne rammen, med Claude Code.

Jeg lover deg verken inntekt eller publisering: det er Apple som godkjenner, og markedet som avgjør resten. Uten kitet holder denne malen for å komme i gang.

Ofte stilte spørsmål

Hvordan skriver man en kravspesifikasjon for en mobilapp?

Hold kravspesifikasjonen på én side: ti spørsmål, én eller to setninger per svar. De handler om målgruppen, problemet, hovedfunksjonen, forretningsmodellen, hva som skjer uten konto, dataene som må overleve, plattformen, hva som er utenfor første versjon, suksessignalet og begrensningene. Hvis et svar blir lengre enn to setninger, er beslutningen ofte ikke tatt.

Hvilket program bør man bruke for å skrive en kravspesifikasjon for en app?

Et enkelt notat eller en tekstfil i rotmappen til prosjektet: du kopierer inn malen og fyller ut hver linje. Du kan også laste ned malen med sjekklisten (.md), uten registrering. For å styre en AI legger du den deretter i kontekstfilen til prosjektet.

Trenger man en kravspesifikasjon på 40 sider for en app?

Nei, ikke når du lager din egen app: én side holder. Malene på 40 sider du finner på nettet er skrevet for en kunde som bestiller en app fra et byrå og trenger et kontraktsdokument. Du bestemmer og bygger selv: siden din skal hjelpe deg å ta beslutningene før du koder og gi AI-en kontekst.

Hvordan gir man kravspesifikasjonen til en AI som koder?

Legg siden i prosjektets faste kontekst: Claude Code leser en CLAUDE.md-fil i rotmappen, Cursor har sine egne regelfiler. Vis til delen «utenfor versjon 1» når AI-en gjør for mye. Før en stor oppgave ber du om en plan som følger siden, uten å kode med en gang.

Hvordan sjekker man at en funksjon følger kravspesifikasjonen?

Legg til tre linjer for hver funksjon: handlingen, forventet resultat og beviset. Beviset kan være en automatisert test for en beregning, eller en sjekk på enheten for en brukerflyt. Skriv også ned hva som ikke er testet, så du ikke forveksler en ferdig skjerm med en funksjon som er klar til bruk.

Hva skal man ikke ha med i en kravspesifikasjon for en app?

Fire ting du bør unngå: en komplett designmanual, en dag-for-dag-plan, en detaljert teknisk arkitektur og funksjoner «til senere» blandet med resten. Noen referanseskjermbilder holder i starten, og et ukesmål holder som plan. Funksjonene til senere hører alle hjemme i delen utenfor versjon 1.