Kravspecifikation til en app: skabelon på én side

Kravspecifikation til en mobilapp: det korte svar

En god kravspecifikation til en mobilapp fylder én side, når du bygger din egen app. Den svarer på ti spørgsmål: til hvem, hvilket problem, hvilken hovedfunktion, hvordan appen tjener penge, hvad der sker uden konto, hvilke data der skal overleve, hvilken platform, hvad der ikke er med i første version, hvordan du ved, at det virker, og hvilke begrænsninger du har. Skabelonen, du kan kopiere, står længere nede. Du kan også downloade skabelonen og dens valideringstabel (.md) uden at oprette dig.

De 40-siders skabeloner, du finder online, er skrevet til et andet formål: en kunde, der bestiller en app hos et bureau og har brug for et kontraktligt dokument. Du er både den, der beslutter, og den, der bygger, ofte med hjælp fra AI. Din kravspecifikation har to formål: at træffe beslutningerne, før du koder, og at give Claude, ChatGPT eller Cursor en klar kontekst, så de bygger den rigtige app.

Jeg udgiver mine egne iOS-apps. Solys, et vækkeur med minispil, og TradaZen, en trading-simulator, ligger på App Store. Nolera og Clic blev afvist af Apple og derefter rettet. Det er metoden, jeg bruger til hver eneste af dem, og det er den, jeg foreslår her.

Hvorfor én side er nok til at rammesætte din egen app

Et langt dokument giver en følelse af at være kommet videre. I praksis bliver det skrevet én gang, sjældent læst igen, og projektet bevæger sig væk fra det allerede i de første uger. En side kan derimod læses igen på to minutter før hver arbejdssession.

Pladsbegrænsningen har også en nyttig effekt: den tvinger dig til at beslutte. Hvis et svar fylder mere end to sætninger, er beslutningen ofte ikke truffet. Det er bedre at opdage det på et stykke papir end i din kode tre uger senere.

Endelig er én side den rigtige størrelse til AI. Du kan indsætte den i sin helhed i en samtale eller lægge den i projektets kontekstfil. Et kort dokument er lettere at gennemlæse og giver færre modstridende instruktioner. Det garanterer ikke, at AI'en følger dem: tjek dens forslag op mod rammen.

Hvad skal en kravspecifikation til en mobilapp indeholde?

Svar på hvert af disse spørgsmål med en eller to sætninger.

1. Hvem bruger appen, og i hvilken situation? Ikke "18-35-årige". Hellere en bestemt person på et bestemt tidspunkt af dagen.
2. Hvilket problem løser appen, i én sætning? Hvis du har brug for "og også", beskriver du to apps.
3. Hvad er DEN ene hovedfunktion i første version? Kun én. De andre må vente på tallene. Siden MVP til en iOS-app forklarer, hvordan du vælger.
4. Hvordan tjener appen penge? Abonnement, engangskøb eller gratis. Svaret ændrer appen allerede fra første skærm. Hvis du er i tvivl, så læs abonnement eller engangskøb til en iOS-app.
5. Hvad kan man uden at oprette en konto? Beslutter du tidligt, hvad der er tilgængeligt uden oprettelse, slipper du for at lave hele onboarding-forløbet om.
6. Hvilke data skal overleve et telefonskifte? Det er spørgsmålet, der afgør, om du har brug for en backend som Supabase, eller om alt kan blive på enheden.
7. Kun iOS, eller iOS og Android? Mit råd, når du er nybegynder: iOS først. Jeg forklarer hvorfor i iOS- og Android-app på samme tid.
8. Hvad er udtrykkeligt UDE af første version? Dokumentets mest nyttige afsnit. Det stopper diskussionerne, før de opstår, både med dig selv og med AI'en.
9. Hvordan ved du, at det virker? Ét enkelt signal, målbart i ugerne efter lanceringen: startede gratis prøveperioder, abonnenter, brugere der kommer tilbage.
10. Hvad er dine reelle begrænsninger? Den tid, du kan bruge på det hver uge, dit udstyr og din Apple Developer-konto, der koster 99 $ om året. Ingen Mac? Det stopper dig ikke, som jeg forklarer i udgiv en iOS-app uden Mac.

Kravspecifikationsskabelonen til at kopiere

Kopiér skabelonen ind i en note eller en tekstfil i roden af dit projekt, og udfyld hver linje.

• Foreløbigt navn på appen: …
• Til hvem: en person, der … på det tidspunkt, hvor …
• Løst problem, i én sætning: …
• Hovedfunktion i version 1: …
• Hvad brugeren ser, når appen åbnes første gang: …
• Forretningsmodel: abonnement / engangskøb / gratis, og hvad der koster penge: …
• Uden konto kan man: …
• Data, der skal bevares mellem to telefoner: ingen / …
• Platform: iOS først (Android senere, hvis tallene er der)
• Ude af version 1: …, …, …
• Successignal: …
• Stack: React Native, Expo, Supabase hvis der skal bruges konti, RevenueCat til abonnementer
• Begrænsninger: … timer om ugen, Apple Developer-konto oprettet eller ej, Mac eller ej
• Apps, hvis oplevelse jeg kan lide, og hvorfor: …

Tilføj tre til fem skærmbilleder af apps, du kan lide, med et ord om, hvad du kan lide ved dem. Det siger mere end en designmanual, både for dig og for AI'en.

En kravspecifikation er ikke en ønskeseddel. Det er en liste over trufne beslutninger.

Eksempel: siden udfyldt for en fiktiv app

For at vise det forventede detaljeniveau er her skabelonen udfyldt for en app, der er opfundet til eksemplet: en timer til lektielæsning.

• Til hvem: en studerende, der læser alene om aftenen og mister fokus efter ti minutter.
• Problem: vedkommende kan ikke gennemføre en arbejdssession uden at røre telefonen.
• Hovedfunktion: starte en tidsindstillet session og se sin stribe af gennemførte dage.
• Første skærm: én enkelt knap til at starte en session.
• Forretningsmodel: abonnement for detaljerede statistikker, grundsession gratis.
• Uden konto: alt, undtagen backup mellem to telefoner.
• Ude af version 1: gruppetilstand, rangliste mellem venner, widgets, Android-version.
• Successignal: brugere, der kommer tilbage flere dage i træk.

Læg mærke til, hvad der bevidst mangler: ingen liste med tyve skærme, ingen fastlagte farver, ingen arkitektur. De valg kommer, mens du bygger, og siden hjælper dig med at tjekke, at de stadig tjener hovedfunktionen.

Sådan bruger du din kravspecifikation til at guide AI'en

Det er her, din side giver mest igen. En AI, der koder uden kontekst, gætter, og den gætter ofte på en anden app end din.

Læg siden i projektets permanente kontekst. Claude Code læser en CLAUDE.md-fil i roden, Cursor har sine egne regelfiler. Indsæt din kravspecifikation der sammen med din stack. Så tager hver forespørgsel udgangspunkt i det samme grundlag.

Henvis til afsnittet "ude af version 1", når AI'en gør for meget. Assistenterne foreslår gerne ekstra funktioner: dark mode, deling, en notifikation. Din eksklusionsliste giver dig et færdigt svar: ikke nu.

Bed om en plan, der respekterer siden. Før en større opgave skriver du: "her er min kravspecifikation, foreslå en plan for hovedfunktionen, kod ikke endnu". Du ser med det samme, om planen fjerner sig fra det, du har besluttet.

Lad den gennemlæse siden, ikke kun koden. Spørg: "hvilke spørgsmål i denne kravspecifikation er uklare eller modstridende?". Det er en undervurderet brug af AI, og den sparer dig for ugers arbejde i den forkerte retning.

Vil du gå videre med emnet, har jeg beskrevet faldgruberne og tjekkene i lav en iOS-app med AI.

Gør beslutningerne til valideringskriterier

En hovedfunktion skal have et observerbart resultat. For den fiktive timer i eksemplet er "timeren virker" for vagt. Skriv hellere: "Jeg starter en session, den resterende tid vises, jeg kan stoppe den og finde den sidst gennemførte session igen efter at have genåbnet appen." Beslut separat, om timeren skal fortsætte med låst skærm: det valg kan ændre det tekniske arbejde.

Tilføj tre linjer for hver funktion: handling, forventet resultat, bevis. Beviset kan være en automatiseret test for en beregning eller et tjek på enheden for et forløb. Notér også, hvad der ikke er testet. Den lille tabel forhindrer, at du forveksler en færdig skærm med en funktion, der er klar til brug.

Her er en udfyldt tabel for vores fiktive timer. Det er kriterier, der skal tjekkes, ikke tests, der allerede er bestået:

Beslutning i rammen	Skal testes	Forventet resultat
Grundsessionen er tilgængelig uden konto	Installér appen og start en session uden at oprette dig	Ingen oprettelsesformular blokerer starten
En afbrudt session tæller ikke med i striben	Stop en session før tid, og åbn derefter historikken	Ingen gennemført session bliver tilføjet
Historikken bliver på enheden	Gennemfør en session, luk og genåbn appen	Sessionen vises én gang med den rigtige varighed
Grundtimeren virker uden netværk	Slå flytilstand til og gennemfør en session	Timeren og den lokale lagring kan stadig bruges
De detaljerede statistikker koster penge	Åbn statistikkerne uden abonnement	Tilbuddet vises; grundsessionen er stadig tilgængelig

De emner, der stadig er uklare, bliver til beslutninger, der skal træffes. For eksempel: hvad skal der ske, hvis brugeren låser skærmen eller ændrer telefonens klokkeslæt under en session? Lad ikke agenten vælge i det stille. Skriv den ønskede adfærd ned, og tilføj tilfældet til tabellen. For at organisere testen på en rigtig installation kan du bruge guiden test din iPhone-app med TestFlight.

Beslut, hvad der skal ud, når første version vokser

Gå hver funktion igennem, og stil ét spørgsmål: "Kan brugeren stadig få det lovede resultat uden den?" For vores timer kan en rangliste mellem venner vente. At kunne finde en gennemført session igen er nødvendigt, hvis du lover en stribe af dage. En abonnementsskærm bliver kun nødvendig, hvis du faktisk sælger statistikkerne allerede i denne version.

Notér beslutningen og begrundelsen i loggen i den downloadbare skabelon. Så kan du vende tilbage til valget efter tests uden at miste begrundelsen for det oprindelige omfang. Tutorialen lav en app med Claude Code viser derefter, hvordan du gør rammen til afgrænsede og verificerbare forespørgsler.

Som et eksempel fra virkeligheden ændrede TradaZen omfang efter udgivelsen. Rammen skal hjælpe dig med at udgive en første målbar version og derefter beslutte den næste ud fra rigtig feedback.

Faldgruben med funktionskataloget

Den naturlige refleks er at liste alt, hvad appen "skal kunne": kortet, chatten, notifikationerne, henvisningsprogrammet, offline-tilstanden. Det katalog er det mest pålidelige tegn på et projekt, der aldrig bliver færdigt, af en simpel grund: hver funktion, du tilføjer før lanceringen, udskyder det øjeblik, hvor rigtige brugere fortæller dig, hvad der betyder noget.

En god første version gør én ting og gør den godt. Pas dog på det modsatte yderpunkt: Apple kræver, at en app er mere end en indpakket hjemmeside, ifølge regel 4.2 i App Review Guidelines. Én hovedfunktion, ja; en tom skal, nej: det er grunden til afvisninger efter guideline 4.2.

Hvad en kravspecifikation til en mobilapp ikke skal indeholde

• En komplet designmanual. Et par referenceskærmbilleder er nok i starten.
• En tidsplan dag for dag. Du har endnu ikke informationerne til at overholde den. Et ugemål er nok.
• En detaljeret teknisk arkitektur. Vælg en gennemprøvet stack, og lad detaljerne blive besluttet, mens du bygger.
• Funktioner "til senere" blandet med resten. De hører alle hjemme i afsnittet ude af version 1.

Hvornår skal du opdatere din kravspecifikation?

Læs den igen i starten af hver arbejdsuge. Opdatér den kun, når en beslutning ændres af en reel grund: en test på din iPhone, der viser, at en skærm ikke virker, feedback fra en tester, et krav fra Apple, du opdager undervejs. Hvis du ændrer den hver dag, rammesætter den ikke længere noget.

Når første version er udgivet, bliver siden grundlaget for den næste: det, der var ude af version 1, rykker op, sorteret efter hvad tallene fortæller dig. Overblikket over hele forløbet, fra idé til udgivelse, finder du på siden lav en iPhone-app.

Fra siden til den udgivne app

Har du svaret på de ti spørgsmål, har du allerede gjort det arbejde, som mange projekter springer over. Næste skridt er at bygge hovedfunktionen, teste den på din iPhone, koble abonnementerne på og forberede materialet til Apple.

Det forløb er iOS Kit, i fire trin, du følger i dit eget tempo: det første handler om at vælge den app, der kan tjene penge, dens målgruppe og dens pris, og din kravspecifikation er udgangspunktet.

Er du ikke sikker på, om din idé er klar til at stå på én side? Den gratis diagnose fortæller dig, hvad der blokerer dit projekt i dag, og hvilket trin du skal tage fat på først. Forsiden viser derefter, hvordan du laver en mobilapp ud fra denne ramme med Claude Code.

Jeg lover dig hverken indtægter eller udgivelse: det er Apple, der godkender, og markedet, der bestemmer resten. Uden kittet er denne skabelon nok til at komme i gang.

Ofte stillede spørgsmål

Hvordan skriver man en kravspecifikation til en mobilapp?

Hold din kravspecifikation på én side: ti spørgsmål, en eller to sætninger pr. svar. De handler om målgruppen, problemet, hovedfunktionen, forretningsmodellen, hvad der sker uden konto, de data der skal overleve, platformen, hvad der er ude af første version, successignalet og begrænsningerne. Hvis et svar fylder mere end to sætninger, er beslutningen ofte ikke truffet.

Hvilket program skal man bruge til at skrive en kravspecifikation til en app?

En simpel note eller en tekstfil i roden af dit projekt: du kopierer skabelonen ind og udfylder hver linje. Du kan også downloade skabelonen og dens valideringstabel (.md) uden at oprette dig. For at guide en AI lægger du den derefter i projektets kontekstfil.

Skal en kravspecifikation til en app fylde 40 sider?

Nej, ikke når du bygger din egen app: én side er nok. De 40-siders skabeloner, man finder online, er skrevet til en kunde, der bestiller en app hos et bureau og har brug for et kontraktligt dokument. Du beslutter og bygger selv: din side skal træffe beslutningerne, før du koder, og give AI'en kontekst.

Hvordan giver man sin kravspecifikation til en AI, der koder?

Læg siden i projektets permanente kontekst: Claude Code læser en CLAUDE.md-fil i roden, Cursor har sine egne regelfiler. Henvis til afsnittet "ude af version 1", når AI'en gør for meget. Før en større opgave beder du om en plan, der respekterer siden, uden at kode med det samme.

Hvordan tjekker man, at en funktion overholder kravspecifikationen?

Tilføj tre linjer for hver funktion: handlingen, det forventede resultat og beviset. Beviset kan være en automatiseret test for en beregning eller et tjek på enheden for et forløb. Notér også, hvad der ikke er testet, så du ikke forveksler en færdig skærm med en funktion, der er klar til brug.

Hvad skal man ikke skrive i en kravspecifikation til en app?

Fire ting, du skal undgå: en komplet designmanual, en tidsplan dag for dag, en detaljeret teknisk arkitektur og funktioner "til senere" blandet med resten. Et par referenceskærmbilleder er nok i starten, og et ugemål er nok til tidsplanen. Funktionerne til senere hører alle hjemme i afsnittet ude af version 1.