Mobil Uygulama İhtiyaç Analizi ve Geliştirme Planı

Yayın Tarihi: 24.10.2026 | Güncelleme Tarihi: 24.10.2026 | Editör: Naron Editör Ekibi

Mobil uygulama ihtiyaç analizi, geliştirme başlamadan önce kullanıcıların yapacağı işleri, kullanılacak verileri ve kabul koşullarını tanımlama çalışmasıdır. Kapsam; ekranlarla birlikte iş kurallarını, erişim yetkilerini, cihazları ve entegrasyonları içerir. Açık bir geliştirme planı, işletmeyle yazılım ekibinin aynı beklentiler üzerinden ilerlemesini sağlar. Öncelikler ve değişiklikler bu plan üzerinden izlenir.

İlgili Mobil Yazılım ve Proje Rehberleri

İhtiyaç analizi, mobil yazılımın kullanım alanını ve işletmenin mevcut süreçlerini birlikte değerlendirir. Aşağıdaki rehberler hizmet kapsamını, proje hazırlığını ve bağlantı kurulabilecek operasyonları incelemek için kullanılabilir.

• Kurumsal Mobil Yazılım: Telefon, tablet ve saha süreçlerinde mobil kullanım alanları.
• Mobil Uygulama Yaptırmak İstiyorum: Fikirden proje görüşmesine hazırlık.
• Özel Yazılım Geliştirme: İşletmenin kendine özgü iş kurallarının değerlendirilmesi.

Uygulamanın Çözeceği İş Problemi Nasıl Tanımlanır?

Mobil uygulama ihtiyaç analizi, önce işletmenin çözmek istediği işi ve bu işi yapan kişileri tanımlar. Hedef, uygulamanın var olması değil, belirli bir görevin doğru bilgilerle tamamlanmasıdır. Bu nedenle ilk belgeye ekran adlarından önce mevcut problem, kullanıcı ve beklenen değişim yazılmalıdır.

Örneğin teknik servis çalışanı müşteride yaptığı işi kağıda not ediyor, ofis çalışanı da aynı bilgiyi tekrar sisteme giriyor olabilir. Böyle bir durumda ihtiyaç yalnızca mobil form oluşturmak değildir. İş emrinin doğru personele atanması, kullanılan parçanın kaydedilmesi, inceleme gerektiren kaydın ayrılması ve kapanışın kim tarafından onaylanacağı da konuşulmalıdır. Birbirine bağlı adımlar görülmeden hazırlanan ekran listesi, asıl sorunun bir bölümünü dışarıda bırakabilir.

İlk görüşmede şu cümleyi tamamlayın: Hangi kullanıcı, hangi koşulda, hangi işi yapmak istiyor ve bugün nerede zorlanıyor? Ardından başarıyı nasıl gözlemleyeceğinizi belirleyin. Örneğin aynı servis kaydının iki kez girilmemesi veya onay bekleyen işlemlerin görünür olması somut hedeflerdir. Genel hizmet kapsamını incelemek için kurumsal mobil yazılım sayfasından yararlanabilirsiniz.

Mevcut İş Akışı ve Kullanıcı Görüşmeleri Nasıl İncelenir?

İhtiyaç analizi sırasında işlem, başladığı noktadan tamamlandığı noktaya kadar izlenir. Kullanıcı görüşmeleri gerçek belge, örnek kayıt ve gözlenen görevlerle desteklenir. Yöneticinin beklentisi ile uygulamayı her gün kullanacak çalışanın ihtiyacı birlikte değerlendirilmelidir.

Süreci yalnız toplantı odasındaki anlatımla sınırlandırmayın. Depoda ürün kabulünün nasıl yapıldığını, saha çalışanının hangi bilgiyi telefonla sorduğunu ve ofisin hangi eksik alanlar nedeniyle kaydı geri çevirdiğini inceleyin. Gerekiyorsa boş bir form üzerinde örnek işlem yürütün. Böylece zorunlu görünen fakat kullanılmayan alanlar ile belgede bulunmayan fakat her işte sorulan bilgiler ayrılabilir.

Görüşme notunda mevcut işlem, yaşanan aksama, kullanılan belge ve karar veren kişi ayrı alanlar olsun. Aynı işin farklı şubelerde farklı biçimde yürütülmesi özellikle kaydedilmelidir. Uygulama bu farklılığı koruyacak mı, yoksa ortak bir iş akışına mı geçilecek? Bu kararın yazılım ekranları çizilmeden verilmesi, sonraki geliştirme görüşmelerinin daha açık yürütülmesini sağlar.

Ekran Listesi ile İş Gereksinimi Arasındaki Fark Nedir?

Ekran listesi kullanıcının göreceği alanları tarif eder; iş gereksinimi ise yapılacak işlemin kuralını açıklar. Bir sipariş ekranının bulunması, siparişin ne zaman onaya gideceğini veya hangi durumda kaydedilemeyeceğini açıklamaz. Her önemli ekran en az bir iş akışı ve doğrulanabilir kuralla ilişkilendirilmelidir.

Bir ihtiyaç kaydını kısa ama tam bir yapı içinde yazabilirsiniz: kullanıcı rolü, başlangıç koşulu, yapılacak işlem, zorunlu veri, beklenen kayıt ve hata davranışı. Örneğin depo çalışanı barkodu okutarak bir ürünün kabul miktarını girmek istiyor olsun. Siparişte olmayan ürün okutulduğunda uygulamanın ne yapacağı, eksik teslimin nasıl kaydedileceği ve işlemin stok bakiyesini hangi anda etkileyeceği açıklanmalıdır.

İşletme açısından gerekli olmayan ayrıntıları yalnız başka bir uygulamada görüldüğü için eklemeyin. Her gereksinimin dayandığı kullanıcı ihtiyacı belli olsun. Bir alanın neden istendiği açıklanamıyorsa önce kullanım amacı araştırılmalıdır. Yazılım yaptırma sürecinin genel hazırlığı için mobil uygulama projesine başlama rehberi de ayrı bir kaynak olarak değerlendirilebilir.

Kullanıcı Rolleri ve Onay Yetkileri Nasıl Belirlenir?

Yetki analizi, her kullanıcının hangi veriyi görebileceğini ve hangi işlemi yapabileceğini tanımlar. Görüntüleme, oluşturma, değiştirme ve onaylama yetkileri ayrı değerlendirilir. İşten ayrılma veya görev değişikliği durumunda erişimin nasıl güncelleneceği de kapsamda bulunmalıdır.

Bir saha çalışanının kendi görev listesini görmesiyle bütün şirketin müşteri kayıtlarını görmesi aynı ihtiyaç değildir. Benzer şekilde taslak oluşturma yetkisi, onaylanmış bir işlemi değiştirme yetkisi anlamına gelmez. Şube, bölge veya ekip sınırları varsa bunlar yalnız ekran filtresi olarak değil, işlem kuralları olarak tanımlanmalıdır. Böylece farklı görevlerin aynı hesapta toplanmasının oluşturacağı belirsizlik azaltılabilir.

Yetki matrisini gerçek örneklerle kontrol edin. Çalışan başka şubenin kayıt numarasını doğrudan kullanırsa ne olur? Onaylayan kişi kendi oluşturduğu kaydı da onaylayabilir mi? Yanlış onay geri alınacaksa önceki kayıt nasıl korunur? Bu soruların yanıtı, yalnız ekrandaki düğmelerin yerini değiştirmekle tamamlanmayacak bir iş tasarımı gerektirir.

Veri Alanları ve Mevcut Sistemlerle Entegrasyon Nasıl Planlanır?

Entegrasyon planında her verinin hangi sistemde üretildiği, hangi yöne aktarıldığı ve çelişki halinde hangi kaydın esas alınacağı belirlenir. Ürün, müşteri, iş emri ve stok hareketi gibi kayıtların kimliği açık olmalıdır. Bağlantının mümkün olduğu, mevcut sistemin desteklediği yöntemlerle ayrıca doğrulanır.

Örnek bir ürün kartında barkod, ürün kodu, ad, birim ve varyant alanları bulunabilir. Mobil uygulama ürün adını serbestçe değiştirirken merkezde başka bir ad kullanılıyorsa eşleştirme sorunu oluşabilir. Bu nedenle yalnız alan isimlerini sıralamak yerine veri sahipliğini yazın. Hangi alan kullanıcı tarafından değiştirilebilir, hangisi merkezden gelir ve hangisi yalnız işlem sırasında hesaplanır?

Örnek veri aktarımı yapılmadan entegrasyonun hazır olduğunu varsaymayın. Eksik alan, farklı karakter, kapatılmış ürün kartı ve geçersiz birim gibi durumları test listesine ekleyin. Stok hareketleriyle bağlantı kurulacaksa stok programı tarafındaki belge ve bakiye mantığını da inceleyin. Aktarım hatasının kim tarafından görüleceği ve nasıl düzeltileceği anlaşılır olmalıdır.

Bağlantı Kesildiğinde Uygulamanın Davranışı Nasıl Tanımlanır?

Bağlantı ihtiyacı, mobil uygulama geliştirmede baştan verilmesi gereken kararlardan biridir. İnternet yokken yalnız görüntüleme yapılmasıyla yeni işlem kaydedilmesi farklı teknik ve operasyonel ihtiyaçlar doğurur. Kullanıcı hangi kaydın yalnız cihazda beklediğini ve hangisinin merkeze ulaştığını anlayabilmelidir.

Çevrimdışı işlem isteniyorsa cihazda tutulacak veri kapsamı, bekleyen işlemlerin sırası ve bağlantı geri geldiğinde uygulanacak kurallar yazılmalıdır. Aynı iş emri başka kullanıcı tarafından değiştirilmişse hangi sürüm kabul edilecek? Gönderim yarıda kesilirse yeniden deneme aynı belgeyi iki kez oluşturacak mı? Bu sorular, yalnız bağlantı simgesi eklenerek çözülemez.

İşlem durumu için anlaşılır ifadeler seçin: cihazda bekliyor, gönderiliyor, merkezde kaydedildi veya inceleme gerekiyor gibi. Kullanıcının ekrana dokunmuş olması kaydın merkeze ulaştığını kanıtlamaz. Testte bağlantı kapatılıp açılarak bekleyen kaydın davranışı gözlenmelidir. Çevrimdışı çalışma, tüm Naron veya Posingo çözümlerinde hazır bulunan bir özellik olarak varsayılmamalı; projeye özel doğrulanmalıdır.

Cihaz, Barkod Okuma ve Ekran Tasarımı Nasıl Değerlendirilir?

Mobil arayüz, kullanılacak cihaz ve çalışma koşullarıyla birlikte tasarlanır. Telefon kamerası, el terminali okuyucusu ve tablet ekranı aynı kullanım biçimini gerektirmez. Gerçek cihazda yapılan örnek görev, masaüstündeki bir tasarım görselinden farklı ihtiyaçlar gösterebilir.

Depoda eldivenle çalışan personelin dokunma alanları, sahada güneş altında okunan ekranın kontrastı ve vardiya boyunca kullanılan cihazın şarj düzeni dikkate alınmalıdır. Uzun ürün adlarının taşması, sayısal klavyenin doğru açılması ve yanlış barkod okutulduğunda verilen mesaj da kullanıcı deneyiminin parçasıdır. Sadece hoş görünen bir ekran, işlemin güvenilir yürüdüğünü göstermez.

Prototipte kullanıcının görevini baştan sona denemesini isteyin. Hazır bir kayıtla başlayan gösteri yerine bulunamayan ürün, boş zorunlu alan ve geri dönme gibi durumları da uygulayın. saha satış otomasyonu gibi hareketli işlerde, bilgi girişinin nerede ve hangi cihazla yapılacağı özellikle önemlidir. Desteklenecek cihaz listesi kabul planına eklenmelidir.

İlk Sürümün Kapsamı ve Geliştirme Sırası Nasıl Seçilir?

İlk sürüm, seçilen temel iş akışının gerçek kullanıcıyla denenebilen bütününü içermelidir. Ekranların yarısının hazırlanmasıyla bir işin baştan sona tamamlanması aynı teslim değildir. Önceliklendirme, iş değeri, bağımlılık ve doğrulama ihtiyacı birlikte değerlendirilerek yapılır.

Örneğin iş emri oluşturulabiliyor fakat personele atanamıyor ve tamamlanan işlem merkeze kaydedilemiyorsa temel akış henüz tamamlanmamıştır. Buna karşılık gelişmiş raporların ilk sürümde bulunmaması, günlük işlemi zorunlu olarak engellemez. Kapsamı yalnız özellik sayısına göre küçültmek yerine çalışır iş zincirini koruyun. Kritik veri ve yetki kontrollerini sonraya bırakılabilecek süsleme gibi görmeyin.

Gereksinimleri ilk sürüm, sonraki sürüm ve ayrıca değerlendirilecek istek olarak ayırabilirsiniz. Her tercihin gerekçesini ve bağlı olduğu diğer işi kaydedin. Bir entegrasyon hazır değilse onun yerine sahte başarı mesajı gösterilmesi kabul edilmemelidir. Test için kullanılan geçici veri veya temsilî bağlantı açıkça belirtilmeli, gerçek entegrasyonun tamamlanma koşulu ayrıca yazılmalıdır.

Güvenlik ve Veri Kullanımı İhtiyaç Belgesine Nasıl Yazılır?

Güvenlik gereksinimleri, uygulamanın tuttuğu veri ve kullanıcının yaptığı işlemler üzerinden tanımlanır. Erişim, cihazda saklanan bilgi, aktarım, oturum ve işlem kaydı ihtiyaçları birlikte değerlendirilir. Genel bir güvenli olsun ifadesi yerine test edilebilir kurallar yazılmalıdır.

Örneğin görev ekranında müşteriye ait hangi bilginin gerçekten gerekli olduğunu belirleyin. İşlem için gerekmeyen alanların telefona taşınması, uygulamanın kullanımını karmaşıklaştırabilir ve korunacak veri kapsamını genişletebilir. Ortak cihaz kullanılıyorsa kullanıcı değişiminde önceki hesaba ait verinin görünmemesi beklenebilir. Bu davranış, kabul testinde ayrı bir senaryoyla kontrol edilmelidir.

Güvenlik beklentilerinin geliştirme boyunca korunması ve güncellenmesi, güvenli yazılım geliştirme çerçevesinde de ele alınan bir yaklaşımdır. Proje belgesinde erişim yetkileri, güvenlik bulgularının takibi ve sürüm değişikliklerinin kaydı için sorumlular belirlenebilir. Kullanıcıların gerçek bilgilerini ilk tasarım dosyalarına taşımak yerine anonimleştirilmiş örneklerle çalışmak daha kontrollü bir hazırlık sağlar.

Kabul Kriterleri ve Test Senaryoları Nasıl Hazırlanır?

Kabul kriteri, geliştirilen işlevin hangi koşullarda uygun sayılacağını açıklayan doğrulanabilir ifadedir. Kriterde başlangıç durumu, kullanıcı işlemi ve beklenen kayıt değişikliği bulunmalıdır. Başarılı işlem kadar reddedilmesi veya beklemeye alınması gereken durumlar da tanımlanır.

Örneğin görevli kullanıcı geçerli barkodu okutup kabul miktarını girdiğinde, seçilen depoda tek bir kabul kaydı oluşması beklenebilir. Yetkisiz kullanıcı aynı işlemi denediğinde kayıt oluşturulamaması gerekir. Gönder düğmesine tekrar dokunulursa sistemin nasıl davranacağı da açık olmalıdır. Böyle bir test, yalnız ekran açılıyor kontrolünden daha anlamlıdır.

Yazılım kabul kriterleri rehberinde de teslimden önce müşteriyle kabul ölçütlerinin belirlenmesi vurgulanır. İşletme projesinde bu yaklaşım, teknik ekiple operasyon ekibinin aynı işi aynı şekilde değerlendirmesine yardımcı olur. Test listesinde kullanılan cihaz, veri örneği ve beklenen kayıt ayrıca belirtilmelidir; bu yazıdaki senaryolar temsili hazırlık örnekleridir.

Değişiklik Talepleri ve Kararlar Nasıl Kayda Alınır?

Geliştirme sırasında ortaya çıkan istekler, mevcut kapsamla karşılaştırılarak değerlendirilmelidir. Bir alan eklemek bazen yalnız ekrandaki düzeni, bazen veri yapısını ve bütün entegrasyonu etkiler. Bu nedenle talep, etki, karar ve yeni kabul ölçütü birlikte kaydedilir.

Örneğin müşteri kartına yeni teslimat adresi eklenmesi istendiğinde, adresin yalnız görüntülenmesi mi yoksa siparişte seçim yapılması mı gerektiği sorulmalıdır. Geçmiş belgeler yeni adresten etkilenecek mi? Aktif bir görev sırasında adres değiştirilirse hangi kayıt esas alınacak? Küçük görünen bir istek, farklı iş kuralları içeriyorsa geliştirme sırasını değiştirebilir.

Karar kaydında talebi kimin ilettiği, neden gerekli olduğu ve hangi sürüme alındığı bulunsun. Reddedilen veya ertelenen isteklerin gerekçesi de korunmalıdır. Böylece aynı konu farklı toplantılarda yeniden açıldığında önceki karar görülebilir. Onaylanan her değişiklik için ilgili test senaryosunu güncellemek, belgenin uygulamadan kopmasını önlemeye yardımcı olur.

Pilot Kullanım ve Teslim Planı Nasıl Kurulur?

Pilot kullanım, uygulamanın sınırlı bir kullanıcı ve işlem grubunda gerçek iş koşullarıyla denenmesidir. Hangi verinin taşınacağı, hangi görevlerin yapılacağı ve sorunların nasıl kaydedileceği önceden belirlenir. Pilotun bitişi yalnız takvimle değil, üzerinde anlaşılan kabul ölçütleriyle değerlendirilmelidir.

Bir ekip veya şubeyle başlayıp günlük işin temsilî örneklerini seçin. Kullanıcı eğitimi sırasında normal akışın yanında yanlış kayıt, bağlantı sorunu ve onay bekleme durumlarını da gösterin. Hata bildirimi için ekran görüntüsü kadar işlem numarası, cihaz ve zaman bilgisi de önemlidir. Canlı müşteri verisi içeren kayıtların kimlerle paylaşılabileceği ayrıca sınırlandırılmalıdır.

Teslim dosyasında kullanıcı rolleri, desteklenen cihazlar, entegrasyon bilgileri, sürüm notları ve işletmenin sorumluları yer almalıdır. Güncellemenin kim tarafından dağıtılacağı ve sorun yaşanırsa hangi önceki sürüme dönülebileceği kararlaştırılır. Kullanıcıların eğitim almasıyla teknik kabulün yapılması farklı işlerdir; ikisinin de kayıt altına alınması gerekir.

Naron ile Mobil Uygulama Projesi Nasıl Değerlendirilir?

Naron ile proje değerlendirmesine, iş problemini ve örnek işlem akışını anlatarak başlanabilir. Mevcut yazılımlar, kullanılacak cihazlar ve ihtiyaç duyulan kullanıcı rolleri birlikte incelenir. Özel geliştirme gereksinimi, kullanılabilir hazır işlevler ve entegrasyon sınırları bu incelemeyle netleştirilmelidir.

Özel yazılım geliştirme görüşmesine başlamadan bütün teknik kararları vermiş olmanız gerekmez. İşin bugün nasıl yapıldığını, hangi kaydın nerede tutulduğunu ve hangi aşamada bekleme yaşandığını açıklamanız daha yararlıdır. Geliştirme yaklaşımı bu iş ihtiyaçlarına göre değerlendirilebilir; uygulama mimarisi yalnız bir teknoloji adı seçilerek belirlenmemelidir.

İhtiyaç barkod, satış ve stok süreçleriyle kesişiyorsa Naron ekosistemindeki Posingo bulut tabanlı barkod ve satış çözümü de değerlendirme kapsamına alınabilir. Hazır çözümün karşılayabildiği alanlar ile projeye özel geliştirme gereken alanlar örnek işlemlerle ayrılır. Her entegrasyon veya mobil özellik için desteklenen kapsam ayrıca doğrulanır; bu rehber herhangi bir pakete ek özellik taahhüdü vermez.

Sıkça Sorulan Sorular

Mobil uygulama geliştirme hazırlığında kapsam ve kabul koşulları birlikte netleştirilmelidir. Aşağıdaki yanıtlar proje görüşmelerinde sık karşılaşılan soruları açıklar.