Kravspecifikation för mobilapp: mall på en sida

Kravspecifikation för en mobilapp: det korta svaret

En bra kravspecifikation för en mobilapp får plats på en sida när du bygger din egen app. Den svarar på tio frågor: för vem, vilket problem, vilken huvudfunktion, hur appen tjänar pengar, vad som händer utan konto, vilken data som måste överleva, vilken plattform, vad som ligger utanför första versionen, hur du vet att det fungerar och vilka begränsningar du har. Mallen att kopiera finns längre ner. Du kan också ladda ner mallen och dess valideringstabell (.md), utan registrering.

Mallarna på 40 sidor som du hittar på nätet är skrivna för ett annat syfte: en kund som beställer en app av en leverantör och behöver ett avtalsdokument. Du är både den som bestämmer och den som bygger, ofta med hjälp av AI. Din kravspecifikation har två syften: att fatta besluten innan du kodar, och att ge Claude, ChatGPT eller Cursor tydlig kontext så att de bygger rätt app.

Jag publicerar mina egna iOS-appar. Solys, en väckarklocka med minispel, och TradaZen, en tradingsimulator, finns på App Store. Nolera och Clic blev avvisade av Apple och sedan rättade. Det här är metoden jag använder för var och en av dem, och det är den jag föreslår här.

Varför en sida räcker för att rama in din egen app

Ett långt dokument ger känslan av att man har kommit framåt. I praktiken skrivs det en gång, läses sällan om, och projektet glider ifrån det redan under de första veckorna. En sida läser du däremot om på två minuter före varje arbetspass.

Platsbristen har också en nyttig effekt: den tvingar dig att bestämma dig. Om ett svar blir längre än två meningar är beslutet ofta inte fattat. Bättre att upptäcka det på ett papper än i din kod tre veckor senare.

Till sist är en sida rätt storlek för AI:n. Du kan klistra in hela den i en konversation, eller lägga den i projektets kontextfil. Ett kort dokument är lättare att granska och minskar motstridiga instruktioner. Det garanterar inte att AI:n följer dem: kontrollera förslagen mot den här ramen.

Vad ska en kravspecifikation för en mobilapp innehålla?

Svara på varje fråga med en eller två meningar.

1. Vem använder appen, och i vilken situation? Inte "18-35-åringar". Snarare en specifik person vid ett specifikt tillfälle under dagen.
2. Vilket problem löser appen, i en mening? Om du behöver "och dessutom" beskriver du två appar.
3. Vilken är DEN huvudsakliga funktionen i första versionen? Bara en. De andra får vänta på siffrorna. Sidan MVP för en iOS-app förklarar hur du väljer.
4. Hur tjänar appen pengar? Prenumeration, engångsköp eller gratis. Svaret förändrar appen redan från första skärmen. Om du tvekar, läs prenumeration eller engångsköp för en iOS-app.
5. Vad kan man göra utan att skapa ett konto? Att tidigt bestämma vad som är tillgängligt utan registrering gör att du slipper bygga om hela introduktionsflödet.
6. Vilken data måste överleva ett telefonbyte? Det är frågan som avgör om du behöver en backend som Supabase, eller om allt kan ligga kvar på enheten.
7. Bara iOS, eller iOS och Android? Mitt råd när du är nybörjare: iOS först. Jag förklarar varför i iOS- och Android-app samtidigt.
8. Vad ligger uttryckligen UTANFÖR första versionen? Dokumentets mest användbara avsnitt. Det stoppar diskussionerna innan de uppstår, både med dig själv och med AI:n.
9. Hur vet du att det fungerar? En enda signal, mätbar under veckorna efter lanseringen: startade gratisperioder, prenumeranter, användare som kommer tillbaka.
10. Vilka är dina verkliga begränsningar? Tiden du kan lägga varje vecka, din utrustning och ditt Apple Developer-konto, som kostar 99 $ per år. Ingen Mac? Det stoppar dig inte, som jag förklarar i publicera en iOS-app utan Mac.

Mallen för kravspecifikationen att kopiera

Kopiera mallen till en anteckning eller en textfil i projektets rotmapp och ersätt sedan varje rad.

• Appens arbetsnamn: …
• För vem: en person som … när …
• Problemet som löses, i en mening: …
• Huvudfunktion i version 1: …
• Det användaren ser när appen öppnas första gången: …
• Affärsmodell: prenumeration / engångsköp / gratis, och vad som kostar: …
• Utan konto kan man: …
• Data som ska följa med mellan två telefoner: ingen / …
• Plattform: iOS först (Android senare om siffrorna håller)
• Utanför version 1: …, …, …
• Framgångssignal: …
• Stack: React Native, Expo, Supabase om konton behövs, RevenueCat för prenumerationer
• Begränsningar: … timmar per vecka, Apple Developer-konto öppnat eller inte, Mac eller inte
• Appar vars upplevelse jag gillar, och varför: …

Lägg till tre till fem skärmdumpar av appar du gillar, med ett ord om vad du gillar. Det säger mer än en grafisk profil, både för dig och för AI:n.

En kravspecifikation är inte en önskelista. Det är en lista över fattade beslut.

Exempel: sidan ifylld för en påhittad app

För att visa vilken detaljnivå som förväntas kommer här mallen ifylld för en app som är påhittad för exemplets skull, en plugg-timer.

• För vem: en student som pluggar ensam på kvällen och tappar fokus efter tio minuter.
• Problem: hen klarar inte ett arbetspass utan att röra telefonen.
• Huvudfunktion: starta ett tidtaget pass och se sin svit av dagar.
• Första skärmen: en enda knapp för att starta ett pass.
• Affärsmodell: prenumeration för detaljerad statistik, baspasset gratis.
• Utan konto: allt, utom säkerhetskopiering mellan två telefoner.
• Utanför version 1: gruppläge, topplista mellan vänner, widgets, Android-version.
• Framgångssignal: användare som kommer tillbaka flera dagar i rad.

Lägg märke till vad som medvetet saknas: ingen lista med tjugo skärmar, inga påtvingade färger, ingen arkitektur. De valen kommer medan du bygger, och sidan hjälper dig att kontrollera att de tjänar huvudfunktionen.

Så använder du din kravspecifikation för att styra AI:n

Det är här din sida gör mest nytta. En AI som kodar utan kontext gissar, och den gissar ofta på en annan app än din.

Lägg sidan i projektets permanenta kontext. Claude Code läser en CLAUDE.md-fil i rotmappen, Cursor har sina egna regelfiler. Klistra in din kravspecifikation där, tillsammans med din stack. Då utgår varje förfrågan från samma grund.

Hänvisa till avsnittet "utanför version 1" när AI:n gör för mycket. Assistenterna föreslår gärna extra funktioner: mörkt läge, delning, en notis. Din uteslutningslista ger dig ett färdigt svar: inte nu.

Be om en plan som följer sidan. Före ett stort arbetsmoment, skriv: "här är min kravspecifikation, föreslå en plan för huvudfunktionen, koda inte än". Du ser direkt om planen avviker från det du har bestämt.

Låt den granska sidan, inte bara koden. Fråga: "vilka frågor i den här kravspecifikationen är otydliga eller motstridiga?". Det är ett underskattat sätt att använda AI, och det besparar dig veckor av arbete åt fel håll.

Vill du gå vidare har jag beskrivit fallgroparna och kontrollerna i skapa en iOS-app med AI.

Gör om besluten till valideringskriterier

En huvudfunktion måste ha ett observerbart resultat. För exemplets påhittade timer är "timern fungerar" för vagt. Skriv hellre: "Jag startar ett pass, återstående tid visas, jag kan stoppa det och hitta det senast avslutade passet efter att ha öppnat appen igen." Bestäm separat om timern ska fortsätta med låst skärm: det valet kan ändra det tekniska arbetet.

Lägg till tre rader för varje funktion: handling, förväntat resultat, bevis. Beviset kan vara ett automatiserat test för en beräkning eller en kontroll på enheten för ett flöde. Anteckna också vad som inte har testats. Den här lilla tabellen gör att du inte blandar ihop en färdig skärm med en funktion som är redo att användas.

Här är en ifylld tabell för vår påhittade timer. Det är kriterier att kontrollera, inte tester som redan har gått igenom:

Beslut i ramverket	Att testa	Förväntat resultat
Baspasset är tillgängligt utan konto	Installera appen och starta ett pass utan att registrera dig	Inget registreringsformulär blockerar starten
Ett avbrutet pass räknas inte in i sviten	Stoppa ett pass innan det är slut, öppna sedan historiken	Inget avslutat pass läggs till
Historiken stannar på enheten	Avsluta ett pass, stäng och öppna appen igen	Passet visas en enda gång med rätt längd
Bastimern fungerar utan nätverk	Slå på flygplansläge och avsluta ett pass	Timern och den lokala sparningen går fortfarande att använda
Den detaljerade statistiken kostar pengar	Öppna statistiken utan prenumeration	Erbjudandet visas; baspasset är fortfarande tillgängligt

Frågor som fortfarande är oklara blir beslut att fatta. Till exempel: vad händer om användaren låser skärmen eller ändrar telefonens klocka under ett pass? Låt inte agenten välja i tysthet. Skriv ner det önskade beteendet och lägg sedan till fallet i tabellen. För att organisera den här testningen på en riktig installation, använd guiden testa din iPhone-app med TestFlight.

Bestäm vad som ska bort när första versionen svämmar över

Gå igenom varje funktion och ställ en fråga: "Kan användaren fortfarande få det utlovade resultatet utan den?" För vår timer kan en topplista mellan vänner vänta. Att hitta ett avslutat pass är nödvändigt om du lovar en svit av dagar. En prenumerationsskärm blir nödvändig bara om du faktiskt säljer statistiken redan i den här versionen.

Anteckna beslutet och skälet i loggen i den nedladdningsbara mallen. Du kan ompröva valet efter tester utan att tappa varför den ursprungliga omfattningen såg ut som den gjorde. Guiden skapa en app med Claude Code visar sedan hur du gör om ramverket till avgränsade och kontrollerbara förfrågningar.

För en erfarenhet från verkligheten: TradaZen ändrade omfattning efter publiceringen. Ramverket finns till för att släppa en första mätbar version och sedan bestämma nästa utifrån verklig feedback.

Fällan med funktionskatalogen

Den naturliga reflexen är att lista allt appen "ska göra": kartan, chatten, notiserna, värvning av vänner, offlineläget. Den katalogen är det säkraste tecknet på ett projekt som aldrig blir klart, av en enkel anledning: varje funktion som läggs till före lanseringen skjuter upp tidpunkten då riktiga användare berättar vad som spelar roll.

En bra första version gör en sak, och gör den bra. Se ändå upp med den motsatta överdriften: Apple kräver att en app går längre än en inpaketerad webbplats, enligt regel 4.2 i App Review Guidelines. En enda huvudfunktion, ja; ett tomt skal, nej: det är skälet bakom guideline 4.2.

Det här ska en kravspecifikation för en mobilapp inte innehålla

• En komplett grafisk profil. Några referensskärmdumpar räcker i början.
• Ett schema dag för dag. Du har ännu inte informationen för att hålla det. Ett veckomål räcker.
• En detaljerad teknisk arkitektur. Välj en beprövad stack och låt detaljerna avgöras medan du bygger.
• Funktioner "för senare" blandade med resten. De hamnar alla i avsnittet utanför version 1.

När ska du uppdatera din kravspecifikation?

Läs om den i början av varje arbetsvecka. Uppdatera den bara när ett beslut ändras av ett verkligt skäl: ett test på din iPhone som visar att en skärm inte fungerar, feedback från en testare, en begränsning från Apple som du upptäckt på vägen. Om du ändrar den varje dag ramar den inte längre in något.

När första versionen är publicerad blir sidan grunden för nästa: det som låg utanför version 1 flyttas upp, sorterat efter vad siffrorna säger. Översikten över hela resan, från idé till publicering, finns på sidan skapa en iPhone-app.

Från sidan till den publicerade appen

Om du har svarat på de tio frågorna har du redan gjort jobbet som många projekt hoppar över. Nästa steg är att bygga huvudfunktionen, testa den på din iPhone, koppla in prenumerationerna och förbereda underlaget för Apple.

Den resan är iOS Kit, i fyra steg som du följer i din egen takt: det första handlar om att välja appen som kan ge intäkter, dess målgrupp och pris, och din kravspecifikation är startpunkten.

Vet du inte om din idé är redo att rymmas på en sida? Den gratis diagnosen berättar vad som blockerar ditt projekt i dag och vilket steg du ska ta itu med först. Startsidan visar sedan hur du skapar en mobilapp utifrån det här ramverket, med Claude Code.

Jag lovar varken intäkter eller publicering: det är Apple som godkänner, och marknaden som avgör resten. Utan kitet räcker den här mallen för att komma igång.

Vanliga frågor

Hur skriver man en kravspecifikation för en mobilapp?

Håll din kravspecifikation på en sida: tio frågor, en eller två meningar per svar. De handlar om målgruppen, problemet, huvudfunktionen, affärsmodellen, vad som händer utan konto, vilken data som måste överleva, plattformen, vad som ligger utanför första versionen, framgångssignalen och begränsningarna. Om ett svar blir längre än två meningar är beslutet ofta inte fattat.

Vilket program ska man använda för att skriva en kravspecifikation för en app?

En enkel anteckning eller en textfil i projektets rotmapp: du kopierar in mallen och ersätter sedan varje rad. Du kan också ladda ner mallen och dess valideringstabell (.md), utan registrering. För att styra en AI lägger du den sedan i projektets kontextfil.

Behövs en kravspecifikation på 40 sidor för en app?

Nej, inte när du bygger din egen app: en sida räcker. Mallarna på 40 sidor som finns på nätet är skrivna för en kund som beställer en app av en leverantör och behöver ett avtalsdokument. Du bestämmer och bygger själv: din sida hjälper dig att fatta besluten innan du kodar och att ge AI:n kontext.

Hur ger man sin kravspecifikation till en AI som kodar?

Lägg sidan i projektets permanenta kontext: Claude Code läser en CLAUDE.md-fil i rotmappen, Cursor har sina egna regelfiler. Hänvisa till avsnittet "utanför version 1" när AI:n gör för mycket. Före ett stort arbetsmoment, be om en plan som följer sidan, utan att koda direkt.

Hur kontrollerar man att en funktion följer kravspecifikationen?

Lägg till tre rader för varje funktion: handlingen, det förväntade resultatet och beviset. Beviset kan vara ett automatiserat test för en beräkning, eller en kontroll på enheten för ett flöde. Anteckna också vad som inte har testats, så att du inte blandar ihop en färdig skärm med en funktion som är redo att användas.

Vad ska man inte ha med i en kravspecifikation för en app?

Fyra saker att undvika: en komplett grafisk profil, ett schema dag för dag, en detaljerad teknisk arkitektur och funktioner "för senare" blandade med resten. Några referensskärmdumpar räcker i början, och ett veckomål räcker som schema. Funktionerna för senare hamnar alla i avsnittet utanför version 1.