Mobil uygulama gereksinim dokümanı: tek sayfalık şablon

Mobil uygulama gereksinim dokümanı: kısa cevap

Kendi uygulamanı yapıyorsan, iyi bir mobil uygulama gereksinim dokümanı tek sayfaya sığar. On soruya cevap verir: kimin için, hangi sorun, hangi ana özellik, uygulama nasıl para kazanıyor, hesap açmadan ne oluyor, hangi veriler korunmalı, hangi platform, ilk sürümün dışında ne kalıyor, işe yaradığını nasıl anlayacaksın ve hangi kısıtlarla çalışıyorsun. Kopyalayacağın şablon aşağıda. İstersen şablonu ve doğrulama tablosunu da indirebilirsin (.md), kayıt gerekmiyor.

İnternette bulduğun 40 sayfalık şablonlar başka bir iş için yazılmış: bir ajansa uygulama sipariş eden ve sözleşmeye dayanak bir belgeye ihtiyaç duyan müşteri için. Sen ise hem karar veren hem de inşa eden kişisin, çoğu zaman yapay zekânın yardımıyla. Senin dokümanın iki işe yarar: kodlamadan önce kararları netleştirmek ve Claude, ChatGPT ya da Cursor'a doğru uygulamayı yapmaları için net bir bağlam vermek.

Kendi iOS uygulamalarımı yayınlıyorum. Mini oyunlu bir çalar saat olan Solys ve bir trading simülatörü olan TradaZen App Store'da. Nolera ve Clic Apple tarafından reddedildi, sonra düzeltildi. Her birinde uyguladığım yöntem bu, sana da bunu öneriyorum.

Kendi uygulamanı çerçevelemek için neden tek sayfa yeter

Uzun bir belge ilerlemiş gibi hissettirir. Pratikte bir kez yazılır, nadiren tekrar okunur ve proje ilk haftalardan itibaren ondan uzaklaşır. Tek sayfa ise her çalışma seansından önce iki dakikada okunur.

Alan kısıtının faydalı bir etkisi de var: seni karar vermeye zorlar. Bir cevap iki cümleyi aşıyorsa, genelde karar henüz verilmemiştir. Bunu üç hafta sonra kodunda değil, bir kâğıt üzerinde fark etmek çok daha iyi.

Son olarak, tek sayfa yapay zekâ için doğru boyut. Tamamını bir sohbete yapıştırabilir ya da projenin bağlam dosyasına koyabilirsin. Kısa bir belge okumayı kolaylaştırır ve çelişkili talimatları azaltır. Yapay zekânın onlara uyacağını garanti etmez: önerilerini bu çerçeveye göre kontrol et.

Bir mobil uygulama gereksinim dokümanında neler olmalı?

Bu soruların her birine bir ya da iki cümleyle cevap ver.

1. Uygulamayı kim kullanıyor ve hangi durumda? "18-35 yaş arası" değil. Daha çok belirli bir kişi, gününün belirli bir anında.
2. Uygulama hangi sorunu çözüyor, tek cümleyle? "Bir de şu" demen gerekiyorsa, iki uygulama anlatıyorsun.
3. İlk sürümün TEK ana özelliği ne? Sadece bir tane. Diğerleri rakamları bekleyecek. iOS uygulaması MVP sayfası nasıl seçeceğini anlatıyor.
4. Uygulama nasıl para kazanıyor? Abonelik, tek seferlik satın alma ya da ücretsiz. Bu cevap uygulamayı ilk ekrandan itibaren değiştirir. Kararsızsan iOS uygulaması için abonelik mi tek seferlik satın alma mı yazısını oku.
5. Hesap açmadan neler yapılabiliyor? Kayıt olmadan nelere erişilebileceğine erken karar vermek, tüm karşılama akışını baştan yapmaktan seni kurtarır.
6. Telefon değişikliğinde hangi veriler korunmalı? Supabase gibi bir backend'e ihtiyacın olup olmadığını ya da her şeyin cihazda kalıp kalamayacağını belirleyen soru bu.
7. Sadece iOS mu, iOS ve Android mi? Yeni başlıyorsan tavsiyem: önce iOS. Nedenini aynı anda iOS ve Android uygulaması yazısında anlatıyorum.
8. Açıkça ilk sürümün DIŞINDA kalan ne? Belgenin en faydalı bölümü. Tartışmaları daha başlamadan bitirir, hem kendinle hem yapay zekâyla.
9. İşe yaradığını nasıl anlayacaksın? Yayından sonraki haftalarda ölçülebilen tek bir sinyal: başlatılan ücretsiz denemeler, aboneler, geri dönen kullanıcılar.
10. Gerçek kısıtların neler? Her hafta ayırabileceğin zaman, donanımın ve yılda 99 $ tutan Apple Developer hesabın. Mac'in yok mu? Engel değil, Mac olmadan iOS uygulaması yayınlamak yazısında anlattığım gibi.

Kopyalanacak gereksinim dokümanı şablonu

Bu şablonu bir nota ya da projenin kök dizinindeki bir metin dosyasına kopyala, sonra her satırı doldur.

• Uygulamanın geçici adı: …
• Kimin için: … anında … yapan biri
• Çözülen sorun, tek cümleyle: …
• 1. sürümün ana özelliği: …
• Kullanıcının uygulamayı ilk açtığında gördüğü şey: …
• İş modeli: abonelik / tek seferlik satın alma / ücretsiz, ve ücretli olan kısım: …
• Hesap olmadan yapılabilenler: …
• İki telefon arasında korunacak veriler: yok / …
• Platform: önce iOS (rakamlar izin verirse Android sonra)
• 1. sürümün dışında: …, …, …
• Başarı sinyali: …
• Stack: React Native, Expo, hesap gerekiyorsa Supabase, abonelikler için RevenueCat
• Kısıtlar: haftada … saat, Apple Developer hesabı açık mı değil mi, Mac var mı yok mu
• Deneyimini sevdiğim uygulamalar ve nedeni: …

Üç ila beş tane sevdiğin uygulamalardan ekran görüntüsü ekle, neyini beğendiğine dair bir not düş. Hem senin için hem yapay zekâ için bir kurumsal kimlik kılavuzundan daha açıklayıcıdır.

Gereksinim dokümanı bir dilek listesi değildir. Verilmiş kararların listesidir.

Örnek: hayali bir uygulama için doldurulmuş sayfa

Beklenen ayrıntı seviyesini görmen için, örnek amaçlı uydurulmuş bir uygulamanın, bir ders çalışma zamanlayıcısının doldurulmuş şablonu:

• Kimin için: akşamları tek başına ders çalışan ve on dakika sonra dağılan bir öğrenci.
• Sorun: telefonuna dokunmadan bir çalışma seansını sürdüremiyor.
• Ana özellik: süreli bir seans başlatmak ve kesintisiz gün serisini görmek.
• İlk ekran: seans başlatmak için tek bir buton.
• İş modeli: detaylı istatistikler için abonelik, temel seans ücretsiz.
• Hesap olmadan: iki telefon arasında yedekleme hariç her şey.
• 1. sürümün dışında: grup modu, arkadaşlar arası sıralama, widget'lar, Android sürümü.
• Başarı sinyali: birkaç gün üst üste geri dönen kullanıcılar.

Bilerek eksik bırakılanlara dikkat et: yirmi ekranlık liste yok, dayatılmış renk yok, mimari yok. Bu seçimler inşa ederken gelecek. Sayfa ise onların ana özelliğe hizmet etmeye devam ettiğini kontrol etmene yarar.

Gereksinim dokümanını yapay zekâya yol göstermek için nasıl kullanırsın

Sayfanın en çok işe yaradığı yer burası. Bağlamsız kod yazan bir yapay zekâ tahmin eder ve çoğu zaman seninkinden farklı bir uygulama tahmin eder.

Sayfayı projenin kalıcı bağlamına koy. Claude Code kök dizindeki bir CLAUDE.md dosyasını okur, Cursor'ın da kendi kural dosyaları var. Dokümanını stack'inle birlikte oraya yapıştır. Böylece her istek aynı temelden başlar.

Yapay zekâ fazlasını yaptığında "1. sürümün dışında" bölümünü hatırlat. Asistanlar ekstra özellik önermeye pek heveslidir: karanlık mod, paylaşım, bildirim. Hariç tutulanlar listen sana hazır bir cevap verir: şimdi değil.

Sayfaya uyan bir plan iste. Büyük bir işe girişmeden önce şunu yaz: "işte gereksinim dokümanım, ana özellik için bir plan öner, henüz kod yazma". Planın kararlarından uzaklaşıp uzaklaşmadığını hemen görürsün.

Sadece kodu değil, sayfayı da okut. Şunu sor: "bu dokümandaki hangi sorular belirsiz ya da çelişkili?". Yapay zekânın hafife alınan bir kullanımı bu ve seni haftalarca yanlış yönde çalışmaktan kurtarır.

Bu konuda daha fazlası için tuzakları ve kontrolleri yapay zekâ ile iOS uygulaması yapmak yazısında ayrıntılı anlattım.

Kararları doğrulama kriterlerine dönüştürmek

Bir ana özelliğin gözlemlenebilir bir sonucu olmalı. Bu örnekteki hayali zamanlayıcı için "zamanlayıcı çalışıyor" fazla belirsiz. Bunun yerine şunu yaz: "Bir seans başlatıyorum, kalan süre görünüyor, durdurabiliyorum ve uygulamayı yeniden açtıktan sonra son tamamlanan seansı bulabiliyorum." Zamanlayıcının ekran kilitliyken devam edip etmeyeceğine ayrıca karar ver: bu seçim teknik işi değiştirebilir.

Her özellik için üç satır ekle: eylem, beklenen sonuç, kanıt. Kanıt, bir hesaplama için otomatik test ya da bir akış için cihaz üzerinde kontrol olabilir. Test edilmemiş olanı da not et. Bu küçük tablo, bitmiş bir ekranla kullanıma hazır bir özelliği karıştırmanı engeller.

İşte hayali zamanlayıcımız için doldurulmuş bir tablo. Bunlar kontrol edilecek kriterler, geçilmiş testler değil:

Çerçeveleme kararı	Test edilecek	Beklenen sonuç
Temel seansa hesap olmadan erişilebilir	Uygulamayı yükle ve kayıt olmadan bir seans başlat	Hiçbir kayıt formu başlatmayı engellemiyor
Yarıda bırakılan seans seriye sayılmaz	Bir seansı bitmeden durdur, sonra geçmişi aç	Tamamlanmış hiçbir seans eklenmiyor
Geçmiş cihazda kalır	Bir seansı bitir, uygulamayı kapatıp yeniden aç	Seans doğru süreyle yalnızca bir kez görünüyor
Temel zamanlayıcı internetsiz çalışır	Uçak modunu aç ve bir seansı bitir	Zamanlayıcı ve yerel kayıt kullanılabilir kalıyor
Detaylı istatistikler ücretli	Abonelik olmadan istatistikleri aç	Teklif görünüyor; temel seans erişilebilir kalıyor

Hâlâ belirsiz olan konular verilmesi gereken kararlara dönüşür. Örneğin: kullanıcı seans sırasında ekranı kilitlerse ya da telefonun saatini değiştirirse ne olacak? Bunu ajanın sessizce seçmesine bırakma. İstediğin davranışı yaz, sonra durumu tabloya ekle. Bu kontrolleri gerçek bir kurulum üzerinde düzenlemek için TestFlight ile iPhone uygulamanı test etmek rehberini kullan.

İlk sürüm taştığında neyi çıkaracağına karar vermek

Her özelliği tek tek ele al ve şunu sor: "Bu olmadan kullanıcı vaat edilen sonuca yine de ulaşabilir mi?" Zamanlayıcımız için arkadaşlar arası sıralama bekleyebilir. Gün serisi vaat ediyorsan tamamlanan bir seansı geri bulmak gerekli. Abonelik ekranı ise ancak istatistikleri bu sürümden itibaren gerçekten satıyorsan gerekli hale gelir.

Kararı ve nedenini indirilebilir şablonun günlüğüne not et. Testlerden sonra bu seçime geri dönebilirsin, ilk kapsamın nedenini kaybetmeden. Claude Code ile uygulama yapmak eğitimi de bu çerçevelemeyi sınırlı ve doğrulanabilir isteklere nasıl dönüştüreceğini gösteriyor.

Sahadan bir örnek için: TradaZen yayından sonra kapsam değiştirdi. Çerçeveleme, ölçülebilir bir ilk sürüm çıkarmaya ve sonrakine gerçek geri bildirimlerle karar vermeye yarar.

Özellik kataloğu tuzağı

Doğal refleks, uygulamanın "yapması gereken" her şeyi listelemektir: harita, sohbet, bildirimler, davet sistemi, çevrimdışı mod. Bu katalog, sonuçlanmayan bir projenin en güvenilir işaretidir ve nedeni basit: yayından önce eklenen her özellik, gerçek kullanıcıların sana neyin önemli olduğunu söyleyeceği anı geciktirir.

İyi bir ilk sürüm tek bir şey yapar ve onu iyi yapar. Yine de ters uçtan kaçın: Apple, App Review Guidelines'ın 4.2 kuralına göre bir uygulamanın paketlenmiş bir web sitesinin ötesine geçmesini ister. Tek bir ana özellik, evet; boş bir kabuk, hayır: guideline 4.2 reddinin nedeni bu.

Bir mobil uygulama gereksinim dokümanında olmaması gerekenler

• Eksiksiz bir kurumsal kimlik kılavuzu. Başlangıçta birkaç referans ekran görüntüsü yeter.
• Gün gün bir planlama. Ona uyacak bilgiye henüz sahip değilsin. Haftalık bir hedef yeter.
• Ayrıntılı bir teknik mimari. Kendini kanıtlamış bir stack seç, ayrıntıların inşa ederken belirlenmesine izin ver.
• Geri kalanla karışmış "sonra için" özellikler. Hepsi 1. sürümün dışında bölümüne gider.

Gereksinim dokümanını ne zaman güncellemelisin?

Her çalışma haftasının başında yeniden oku. Sadece bir karar gerçek bir nedenle değiştiğinde güncelle: iPhone'unda yaptığın bir testin bir ekranın çalışmadığını göstermesi, bir test kullanıcısının geri bildirimi, yolda keşfedilen bir Apple kısıtı. Her gün değiştiriyorsan, artık hiçbir şeyi çerçevelemiyor demektir.

İlk sürüm yayınlandıktan sonra sayfa bir sonrakinin temeli olur: 1. sürümün dışında kalanlar, rakamların söylediğine göre sıralanarak yukarı çıkar. Fikirden yayına tüm sürecin genel görünümü iPhone uygulaması yapmak sayfasında.

Sayfadan yayınlanmış uygulamaya

On soruya cevap verdiysen, birçok projenin atladığı işi zaten yapmışsın demektir. Devamı: ana özelliği inşa etmek, iPhone'unda test etmek, abonelikleri bağlamak ve Apple için dosyayı hazırlamak.

Bu süreç, kendi hızında izleyeceğin dört adımlık iOS Kit sürecidir: ilk adım para kazandırabilecek uygulamayı, kitlesini ve fiyatını seçmeye yarar ve gereksinim dokümanın bunun başlangıç noktasıdır.

Fikrinin tek sayfaya sığmaya hazır olup olmadığından emin değil misin? Ücretsiz teşhis bugün projeni neyin tıkadığını ve önce hangi adıma girişmen gerektiğini söyler. Ana sayfa da bu çerçevelemeden yola çıkarak Claude Code ile nasıl mobil uygulama yapacağını gösteriyor.

Sana ne gelir ne de yayın sözü veriyorum: onayı Apple verir, gerisine pazar karar verir. Kit olmadan da bu şablon başlamana yeter.

Sık sorulan sorular

Mobil uygulama için gereksinim dokümanı nasıl yazılır?

Dokümanını tek sayfada tut: on soru, her cevap için bir ya da iki cümle. Sorular kitle, sorun, ana özellik, iş modeli, hesap olmadan ne olduğu, korunması gereken veriler, platform, ilk sürümün dışında kalanlar, başarı sinyali ve kısıtlarla ilgili. Bir cevap iki cümleyi aşıyorsa, genelde karar henüz verilmemiştir.

Uygulama gereksinim dokümanı yazmak için hangi programı kullanmalı?

Basit bir not ya da projenin kök dizininde bir metin dosyası: şablonu oraya kopyalar, sonra her satırı doldurursun. Ayrıca şablonu ve doğrulama tablosunu indirebilirsin (.md), kayıt gerekmiyor. Bir yapay zekâya yol göstermek için sonra onu projenin bağlam dosyasına koy.

Bir uygulama için 40 sayfalık gereksinim dokümanı gerekir mi?

Hayır, kendi uygulamanı yapıyorsan tek sayfa yeter. İnternette bulunan 40 sayfalık şablonlar, bir ajansa uygulama sipariş eden ve sözleşmeye dayanak bir belgeye ihtiyaç duyan müşteri için yazılmış. Sen karar veriyor ve inşa ediyorsun: sayfan, kodlamadan önce kararları netleştirmeye ve yapay zekâya bağlam vermeye yarar.

Gereksinim dokümanı kod yazan bir yapay zekâya nasıl verilir?

Sayfayı projenin kalıcı bağlamına koy: Claude Code kök dizindeki bir CLAUDE.md dosyasını okur, Cursor'ın kendi kural dosyaları var. Yapay zekâ fazlasını yaptığında "1. sürümün dışında" bölümünü hatırlat. Büyük bir işten önce, hemen kod yazmadan sayfaya uyan bir plan iste.

Bir özelliğin gereksinim dokümanına uyduğu nasıl kontrol edilir?

Her özellik için üç satır ekle: eylem, beklenen sonuç ve kanıt. Kanıt, bir hesaplama için otomatik test ya da bir akış için cihaz üzerinde kontrol olabilir. Bitmiş bir ekranla kullanıma hazır bir özelliği karıştırmamak için test edilmemiş olanı da not et.

Uygulama gereksinim dokümanına neler konmamalı?

Kaçınılacak dört şey: eksiksiz bir kurumsal kimlik kılavuzu, gün gün bir planlama, ayrıntılı bir teknik mimari ve geri kalanla karışmış "sonra için" özellikler. Başlangıçta birkaç referans ekran görüntüsü, planlama için de haftalık bir hedef yeter. Sonra için olan özelliklerin hepsi 1. sürümün dışında bölümüne gider.