Telefon: 0 (552) 380 25 25  |  Hafta içi 10:00–18:00 · Teknik destek 7/24

🇬🇧 EN

Digital Bridge Blog

Yazılım Geliştirme

Yazılım İhtiyaç Analizi Nasıl Yapılır? Doğru Kapsam İçin 9 Adımlık Yöntem ve Örnek Çıktılar

Yazılım ihtiyaç analizi nasıl yapılır? Süreç haritası, veri envanteri, önceliklendirme ve kabul kriterleriyle doğru kapsamı çıkaran 9 adımlık yöntem.

7 dk okuma  · Digital Bridge Mühendislik Ekibi
Yazılım İhtiyaç Analizi Nasıl Yapılır? Doğru Kapsam İçin 9 Adımlık Yöntem ve Örnek Çıktılar

Yazılım ihtiyaç analizi, bir yazılımın hangi sorunu çözeceğini, kimin hangi işi nasıl yapacağını, hangi verilerle ve hangi sistemlerle çalışacağını kod yazılmadan önce netleştirme işidir. İyi bir analizin çıktısı; mevcut ve hedef süreç haritası, önceliklendirilmiş gereksinim listesi, veri ve entegrasyon envanteri ile kabul kriterleridir.

Analiz şirket içi bir keşiftir ve "neye ihtiyacımız var?" sorusunu cevaplar; bu ihtiyacı tedarikçilerin teklif vereceği satın alma belgesine dönüştürmek ise teknik şartname hazırlama adımının işidir. Analiz dokümanı olmadan alınan teklifler karşılaştırılamaz, proje sırasında kapsam kayar ve bütçe aşılır.

Analiz neden atlanır, atlanınca ne olur?

Pek çok işletme ihtiyaç analizini ya gereksiz bir masraf ya da yazılım firmasının kendi başına halledeceği bir iş olarak görür. Yönetici ne istediğini bildiğini düşünür: "Siparişleri takip edebileceğimiz bir program." Oysa bu cümlenin içinde onlarca karar gizlidir:

  • Sipariş kim tarafından, hangi kanaldan giriliyor?
  • Fiyat nereden geliyor, stok ne zaman düşüyor?
  • Onay gerekiyor mu, kimden?
  • Muhasebeye ne zaman, hangi bilgiyle aktarılıyor?

Bu soruların cevabı analizde verilmezse, proje sırasında verilir; ama o zaman her cevap bir değişiklik talebi, her değişiklik ek süre ve ek bedel demektir. Daha kötüsü, bazı sorular hiç sorulmaz ve yazılım canlıya alındıktan sonra kullanıcılar eksik kalan işleri yeniden Excel'e taşır. Bu dönüşün işaretlerini Excel ile iş takibinin sınırları yazımızda anlattık.

Bir örnek: Bir gıda toptancısı, depo çıkışlarını takip edecek bir uygulama ister. Analiz yapılmadan başlanan projede uygulama zamanında teslim edilir, ama ilk hafta iki sorun ortaya çıkar. Birincisi, bazı ürünler son kullanma tarihine göre sevk edilmelidir ve bu kural hiç konuşulmamıştır. İkincisi, depodaki el terminalleri kablosuz ağın zayıf olduğu raflarda bağlantıyı kaybeder.

İki sorun da yarım günlük bir analiz görüşmesinde ortaya çıkabilirdi; proje bitiminde ise ikisi de yeni bir geliştirme aşaması demektir.

Analizsiz projenin maliyeti

Analiz eksikliğinin bedeli ölçülebilir biçimde karşımıza çıkıyor. Kurumsal yazılım projelerinin en iyi belgelenen türü olan ERP'de:

Panorama Consulting Group'un 2026 ERP Raporu'na göre katılımcıların dörtte birinden fazlası projesinin bütçeyi aştığını bildirdi ve bütçe aşımının en yaygın nedeni beklenmedik ek teknoloji ihtiyacı oldu.

"Beklenmedik" kelimesi burada kilit rol oynar: analizde görülmesi gereken bir entegrasyon, rapor ya da modül, proje sırasında fark edilmiştir. İyi bir ihtiyaç analizi bu sürprizleri projenin başına çeker; orada maliyeti en düşüktür.

Genel başarı tablosu da aynı yöne işaret ediyor. BCG'nin 2020 tarihli "Flipping the Odds of Digital Transformation Success" araştırmasına göre dijital dönüşümlerin %70'i hedeflerinin gerisinde kaldı. Hedefi baştan ölçülebilir biçimde tanımlanmamış bir projenin hedefe ulaşıp ulaşmadığını söylemek de mümkün değildir; analiz, hedefi ölçülebilir hale getirdiği için başarının da ön koşuludur.

Veri boyutu çoğu zaman en çok ihmal edilen kısımdır. Veri kalitesi uzmanı Thomas C. Redman, MIT Sloan Management Review'daki 2017 tarihli "Seizing Opportunity in Data Quality" yazısında kötü verinin çoğu şirkete maliyetini gelirin %15-25'i olarak tahmin ediyor. Yeni yazılıma taşınacak verinin nerede, hangi biçimde ve ne kalitede olduğu analizde incelenmezse, yeni sistem eski hataları daha hızlı çoğaltan bir araca dönüşebilir. Temizlik yöntemini veri kalitesi ve mükerrer kayıt yazımızda anlattık.

Adım adım yazılım ihtiyaç analizi

  1. Hedefi ölçülebilir yazın. "Sipariş takibini kolaylaştırmak" değil; "siparişin girilmesinden sevkiyata kadar geçen süreyi görünür kılmak ve sipariş başına elle yapılan kopyalama işini kaldırmak" gibi. Her hedefin yanına bugünkü durumu not edin. Analiz daha geniş bir dönüşüm planının parçasıysa dijital dönüşüm yol haritası yazımıza da bakın.
  2. Paydaşları belirleyin. Yazılımı kullanacak, verisini besleyecek, raporunu okuyacak ve onaylayacak herkes. Sahada çalışan kullanıcıyı atlamak, en sık yapılan analiz hatasıdır.
  3. Mevcut süreci haritalayın. İşin bugün gerçekte nasıl yapıldığını adım adım çizin; prosedürde yazanı değil, masada olanı. Excel dosyaları, e-posta ile gönderilen onaylar ve telefonla verilen bilgiler bu haritada görünmelidir. Satış süreci için paket arıyorsanız bu haritayı CRM seçim kriterleri listesiyle birlikte kullanın.
  4. Hedef süreci tasarlayın. Hangi adım kalkacak, hangisi otomatikleşecek, hangisi yeni yazılımda yapılacak? Burada kötü bir süreci olduğu gibi dijitalleştirmemeye dikkat edin.
  5. Veri envanteri çıkarın. Hangi veri nerede tutuluyor, kim güncelliyor, ne kadar temiz? Kişisel veri içeren alanları ayrıca işaretleyin; bu, KVKK açısından hangi verinin kimler tarafından görüleceğini tasarlamanın temelidir. Çalışan verisi işleyen sistemlerde, örneğin İK yazılımı seçimi sırasında, bu adım özellikle kritiktir.
  6. Entegrasyonları listeleyin. Muhasebe/ERP, e-Fatura entegratörü, e-ticaret, kargo, banka, üretim sistemleri... Her biri için hangi verinin hangi yöne, ne sıklıkla akacağını ve hangi sistemin "asıl kayıt" olduğunu yazın. Üretim yapan firmalarda malzeme ihtiyacını hangi sistemin hesaplayacağı (MRP nedir) da bu listede netleşmelidir.
  7. Gereksinimleri yazın. Fonksiyonel gereksinimler (yazılım ne yapacak) ile fonksiyonel olmayan gereksinimleri (kaç kullanıcı, hangi cihazlar, yanıt süresi, yedekleme, erişim yetkileri) ayrı listeleyin. Mobil uygulama gerekiyorsa cihaz ve teknoloji seçimini native mi cross-platform mu yazımızda ele aldık.
  8. Önceliklendirin. Her gereksinimi MoSCoW yöntemiyle "olmazsa olmaz" (Must), "olmalı" (Should), "olsa iyi olur" (Could) ve "bu aşamada yok" (Won't) olarak sınıflandırın. İlk aşamaya yalnızca olmazsa olmazlar ve kendi başına değer üreten işler girsin.
  9. Kabul kriterlerini tanımlayın. Her gereksinim için "bu iş şu koşulda tamam sayılır" cümlesini yazın. Kabul kriteri olmayan bir gereksinim, teslimde tartışma konusu olur.

Analiz dokümanında neler olmalı?

BölümİçerikKime yarar?
Hedefler ve ölçütlerÖlçülebilir hedefler, bugünkü durumYönetim, proje sonu değerlendirmesi
Süreç haritalarıMevcut ve hedef süreçKullanıcılar, tasarım ekibi
Roller ve yetkilerKim neyi görür, kim neyi onaylarGüvenlik, KVKK uyumu
Veri envanteriVeri kaynakları, kalite, kişisel veri alanlarıVeri taşıma, entegrasyon
Entegrasyon listesiSistemler, veri akışı, sıklık, asıl kayıtGeliştirme ekibi
Gereksinim listesiFonksiyonel ve fonksiyonel olmayan, öncelikliTeklif ve kapsam
Kabul kriterleriHer gereksinim için "tamam" tanımıTeslim ve kabul
Aşama planıİlk aşama ve sonraki aşamalarBütçe ve takvim

Bu doküman, teklif almak için de en güçlü aracınızdır. Aynı dokümanı birden çok firmaya gönderdiğinizde teklifler aynı kapsamı fiyatlar ve karşılaştırılabilir hale gelir; firmaları nasıl değerlendireceğinizi yazılım firması seçerken dikkat edilecekler yazımızda anlattık. Dokümanı resmî bir ihale ya da satın alma sürecine taşıyacaksanız sonraki adım, yukarıda değindiğimiz teknik şartnamedir.

Analizin bir başka çıktısı da stratejik bir karardır. Gereksinim listesinde "standart" ve "bize özgü" işler ayrıştığında, hangi işin hazır paketle, hangisinin özel geliştirmeyle çözüleceği büyük ölçüde belli olur; bu kararın ölçütlerini özel yazılım mı hazır paket mi rehberinde topladık. Satın alma yolculuğunun diğer adımları Yazılım Geliştirme yazılarımızın tamamında bir arada.

Sık yapılan hatalar

  • Yalnızca yöneticiyle konuşmak. Süreci en iyi bilen, onu her gün yapan kişidir. Saha, depo ve muhasebe kullanıcılarıyla yapılmayan görüşme eksik analiz demektir.
  • Çözümle başlamak. "Bir mobil uygulama istiyoruz" bir çözümdür, ihtiyaç değil. Önce sorunu tarif edin; çözüm analizin sonunda çıkar.
  • İstisnaları atlamak. İade, iptal, kısmi sevkiyat, yetkili izindeyken onay... Yazılım maliyetinin önemli bir kısmı istisnalardadır.
  • Veriyi sona bırakmak. Veri taşıma ve temizlik, analizde planlanmazsa canlıya alma tarihini en çok geciktiren iş olur.
  • Her şeyi ilk aşamaya koymak. Önceliklendirme yapılmamış bir analiz, büyük ve riskli bir tek parça projeye dönüşür.

Digital Bridge'de ihtiyaç analizini nasıl yürütüyoruz?

İhtiyaç analizi bizde teklifin ön koşuludur ve analizi belirli bir ürüne uydurmuyoruz. Çalışma biçimimiz şöyle:

  • Sahada ve masada dinliyoruz. Yöneticilerin yanı sıra işi her gün yapan kullanıcılarla görüşüyor, süreci yerinde ya da uzaktan izliyoruz. Türkiye'nin tüm illerinde uzaktan ve yerinde çalışabiliyoruz.
  • Süreci ve veriyi birlikte ele alıyoruz. Süreç haritasının yanında veri envanterini ve entegrasyon noktalarını çıkarıyoruz; veri kalitesi sorunları varsa veri yönetişimi ve kalite tarafında ele alınacak işleri ayrıca belirtiyoruz.
  • Dönüşümün büyük resmini kaçırmıyoruz. Analiz tek bir yazılımın ötesine geçiyorsa dijital dönüşüm danışmanlığı kapsamında öncelikleri ve yol haritasını birlikte kuruyoruz; kişisel veri işleyen süreçlerde KVKK uyum danışmanlığı ekibimiz tasarıma baştan dahil oluyor. Tüm danışmanlık hizmetlerimizi tek sayfada görebilirsiniz.
  • Her ihtiyaç özel geliştirme gerektirmez. İhtiyaç kartlı geçiş, personel devam takibi ve yemekhane sayımıysa SmartPass, kurumsal e-posta ve dosya yönetimiyse Smart360 gibi hazır ürünlerimiz yeterli olabilir; analiz bunu gösteriyorsa açıkça söylüyoruz.
  • Analizi yazılı teklife çeviriyoruz. Kapsam, aşamalar ve bedel yazılı olarak ortaya konur; kapsam dışında kalanlar da açıkça yazılır.
  • Donanım gerekiyorsa fizibiliteyi ücretsiz yapıyoruz. Saha terminali, barkod ya da sensör gerektiren işlerde teknik fizibilite ücretsizdir; üretim tesislerinde Endüstri 4.0 ihtiyaçları için ücretsiz saha değerlendirmesi yapıyoruz.

Analizin ardından geliştirme, yazılım çözümleri ekibimiz tarafından aynı dokümana dayanarak yürütülür; böylece analizde konuşulan her karar teslimde de izlenebilir kalır.

Sonraki adım

Analize hazırlanmak için bir sayfa yeterli: çözmek istediğiniz üç sorunu, bu sorunlardan etkilenen kişileri ve bugün kullandığınız programları yazın. Bu sayfayla bizimle iletişime geçin; ihtiyaç analizini birlikte yürütelim ve sonucu kapsamı, aşamaları ve bedeli belli yazılı bir teklife dönüştürelim. Maliyet kalemlerini önceden görmek isterseniz yazılım projesi maliyeti rehberimize de göz atabilirsiniz.

Sizin durumunuza birlikte bakalım

Sürecinizi anlatın; ihtiyaç analizinin ardından kapsamı, aşamaları ve bedeli içeren yazılı teklif gönderelim.

Teklif İsteyin 0 (552) 380 25 25
En çok sorulan sorular

Sık Sorulan Sorular

İhtiyaç analizi ne kadar sürer?

Kapsama göre değişir. Tek bir süreci kapsayan bir uygulama için birkaç görüşme yeterli olabilirken, birden çok departmanı ve entegrasyonu kapsayan bir projede analiz daha uzun sürer. Süreyi belirleyen, görüşülmesi gereken kişi sayısı ve incelenecek sistem sayısıdır. Görüşmelere doğru kişilerin zamanında katılması, analizin takvimini en çok etkileyen etkendir.

İhtiyaç analizini kendimiz yapabilir miyiz?

Hedefleri, paydaşları ve mevcut süreci kendiniz çıkarabilirsiniz ve bu çok değerli bir başlangıçtır. Entegrasyon, veri yapısı ve fonksiyonel olmayan gereksinimler ise teknik deneyim gerektirir. En verimli yol, iç ekibin hazırladığı taslağı yazılım ekibiyle birlikte tamamlamaktır. Böylece süreç bilgisi sizden, teknik tasarım deneyimi yazılım ekibinden gelir.

İhtiyaç analizi ile teknik şartname aynı şey mi?

Hayır. İhtiyaç analizi neye ihtiyaç duyduğunuzu ortaya çıkarır; teknik şartname ise bu ihtiyacı tedarikçilerin teklif verebileceği resmî bir metne dönüştürür. Şartname, iyi yapılmış bir ihtiyaç analizinin üzerine kurulur. Analiz yapılmadan yazılan bir şartname, eksik ya da yanlış bir ihtiyacı resmî bir belgeye dönüştürme riski taşır.

Analizden sonra kapsam değişirse ne olur?

Değişiklik normaldir; önemli olan yönetilmesidir. Her değişiklik yazılı bir talep olarak kaydedilmeli, süre ve bedel etkisi değerlendirilmeli ve karar verici tarafından onaylanmalıdır. Analiz dokümanı bu değerlendirmenin referans noktasıdır; neyin gerçekten değişiklik, neyin baştan kapsamda olduğunu tartışmasız biçimde bu doküman gösterir.

Hazır paket alacaksak da ihtiyaç analizi gerekir mi?

Evet. Analiz, paketin ihtiyacınızın ne kadarını karşıladığını ve hangi özelleştirme ya da entegrasyonların gerekeceğini gösterir. Paketi demo verisiyle değil, analizde çıkan gerçek iş örnekleriyle test etmek yanlış seçimin önüne geçer. Karşılanmayan her gereksinim, ya özelleştirme ya entegrasyon ya da Excel'e dönüş olarak geri gelir.

Sorunuz burada yok mu? Bize Sorun

Bir Mühendisle Konuşun

Çözmek istediğiniz işi anlatın, yazılı teklifle dönelim.