Bir yazılım projesinde en pahalı hata, yanlış şeyi doğru biçimde inşa etmektir. Kod temiz, ekranlar şık, testler geçiyor; ama kullanıcılar sistemi kullanmıyor, çünkü asıl iş başka türlü yürüyor. İhtiyaç analizi, bu riski proje başında azaltmak için yapılan çalışmadır: kimin hangi sorunu yaşadığını, yazılımın neyi yapması ve neyi yapmaması gerektiğini, hangi kısmın ilk sürüme gireceğini yazılı hâle getirir. Bu rehberde ihtiyaç analizini ve kapsam belirlemeyi, paydaş görüşmelerinden kapsam sürünmesini kontrol altında tutmaya kadar adım adım anlatıyoruz. Yöntem, ister küçük bir iç araç ister birkaç departmanı kapsayan bir sistem olsun aynı şekilde işler; değişen yalnızca derinliktir.
İhtiyaç analizi neden ayrı bir aşama?
"Ne istediğimizi biliyoruz, hemen başlayalım" cümlesi projelerin başında çok duyulur. Çoğu zaman da doğrudur: işletme ne istediğini bilir. Bilmediği şey, o isteğin arkasındaki ayrıntılardır. "Teklifleri sistemden hazırlayalım" talebinin içinde onlarca soru saklıdır: Teklifi kim hazırlıyor, kim onaylıyor, iskonto sınırı var mı, döviz kuru nereden geliyor, teklif kabul edilince ne oluyor?
Bu sorular geliştirme sırasında ortaya çıkarsa iki şey olur: ya geliştirici kendi tahminiyle karar verir ve yanlış yapar, ya da proje her soruda durur ve takvim kayar. İhtiyaç analizi bu soruları proje başında, değişikliğin en ucuz olduğu anda sorar. Kâğıt üzerinde bir akışı değiştirmek dakikalar alır; aynı değişiklik veri tabanı tasarlandıktan ve ekranlar yazıldıktan sonra günler sürebilir.
Analiz aşamasının çıktısı, hem yazılımı yaptıran hem de geliştiren taraf için ortak bir referanstır. Teklif, takvim ve kabul testleri bu belgeye dayanır. Henüz hazır paket mi özel yazılım mı kullanacağınıza karar vermediyseniz, bu analiz o kararın da temelini oluşturur; seçenekleri özel yazılım ve hazır paket karşılaştırmamızda ele aldık.
Adım adım ihtiyaç analizi ve kapsam belirleme
Projenin amacını ve başarı ölçütünü yazın. Neden: Amaç belli değilse her istek eşit derecede önemli görünür ve önceliklendirme imkânsızlaşır. Nasıl: "Bu proje bittiğinde neyin değişmiş olmasını istiyoruz?" sorusunu tek paragrafla cevaplayın ve ölçülebilir bir hedefe bağlayın. Örnek: "Satış ekibinin teklif hazırlama süresini kısaltmak ve onaylanan tekliflerin siparişe aktarılırken yeniden girilmesini ortadan kaldırmak." Bu cümle, ileride gelen her yeni isteğin "amaca hizmet ediyor mu?" testinden geçmesini sağlar.
Paydaşları belirleyin. Neden: Sistemi kullanacak, etkilenecek ya da onaylayacak herkes paydaştır; atlanan bir paydaş, yayından sonra "bizim işimiz böyle yürümüyor" diyen kişi olur. Nasıl: Basit bir liste çıkarın: karar verici (bütçe ve onay), günlük kullanıcılar (satış temsilcisi, depo sorumlusu), dolaylı etkilenenler (muhasebe, müşteri), teknik paydaşlar (BT sorumlusu, entegre olunacak sistemlerin sahipleri). Her biri için "bu sistemden ne bekliyor, ne kaybetmekten korkuyor?" sorularını not edin.
Paydaş görüşmeleri yapın ve işi yerinde izleyin. Neden: Yöneticinin anlattığı süreç ile sahada uygulanan süreç çoğu zaman farklıdır. Asıl ihtiyaçlar, kullanıcının geliştirdiği küçük çözümlerde, yani Excel tablolarında, renkli kâğıtlarda ve WhatsApp gruplarında saklıdır. Nasıl: Her kullanıcı grubuyla ayrı görüşün ve görüşmeyi geçmiş olaylar üzerine kurun: "Dün gelen son teklif talebini baştan sona nasıl hazırladınız?" Mümkünse kullanıcının yanında oturup işi yaparken izleyin. Kullanılan belgeleri, formları ve tabloları örnek olarak isteyin; bunlar veri modelinin ilk taslağıdır. Hızlı fikir toplamak için bir atölye düzenleyebilirsiniz, ama ayrıntılar bire bir görüşmelerde çıkar.
Mevcut süreci haritalayın. Neden: Yeni sistemi tasarlamadan önce bugünkü akışı, darboğazları ve tekrar eden işleri görmek gerekir. Nasıl: Süreci adım adım çizin: kim, neyi, hangi bilgiyle, hangi araçta yapıyor ve bir sonraki adıma ne aktarıyor? Aynı verinin birden fazla yere girildiği, beklemelerin yaşandığı ve hataların çıktığı noktaları işaretleyin. Bu harita, yazılımın en çok değer katacağı yerleri gösterir. Kâğıt formlarla yürüyen onay süreçleri varsa dijital form ve onay süreçleri yazımız bu adımda yol gösterici olur.
İhtiyaçları kullanıcı hikâyelerine dönüştürün. Neden: "Teklif modülü" gibi geniş başlıklar tahmin edilemez ve test edilemez; kullanıcı hikâyesi ise kimin, ne için, neyi istediğini netleştirir. Nasıl: Yaygın kalıp şudur: "Bir [rol] olarak, [amaç] için [işlem] yapabilmek istiyorum." Örnek: "Bir satış temsilcisi olarak, müşterinin geçmiş siparişlerini teklif ekranında görmek istiyorum; böylece fiyatı daha hızlı belirleyebilirim." Her hikâyeye kabul kriterleri ekleyin: "Son 12 ayın siparişleri tarih sırasıyla listelenir; satırdan ürüne tıklanınca teklife eklenir." Agile Alliance'ın da andığı INVEST ölçütü, yani bağımsız, konuşulabilir, değer taşıyan, tahmin edilebilir, küçük ve test edilebilir olma koşulu, iyi bir hikâyeyi kontrol etmek için kullanışlı bir listedir.
İşlevsel olmayan gereksinimleri yazın. Neden: Performans, güvenlik ve erişim gibi konular kullanıcı hikâyelerinde kendiliğinden çıkmaz; ama mimariyi en çok bunlar belirler. Nasıl: Şu soruların cevabını kayda geçirin: Sistemi aynı anda kaç kişi kullanacak? Sahada mobil cihazdan, zayıf internetle kullanılacak mı? Hangi roller hangi veriyi görebilmeli? Kişisel veri işleniyor mu, nerede saklanacak, ne kadar süre tutulacak? Yedekleme ve kesinti toleransı nedir? Kişisel veriler söz konusuysa KVKK yükümlülüklerini bu aşamada ele almak, sonradan eklemekten çok daha kolaydır.
Entegrasyonları ve veri taşımayı listeleyin. Neden: Projelerde en çok sürpriz çıkan kalem genellikle entegrasyondur; karşı sistemin API'si eksik, belgesiz ya da ücretli olabilir. Nasıl: Yazılımın veri alacağı ve vereceği her sistemi yazın: muhasebe programı, e-fatura entegratörü, e-ticaret sitesi, kargo firması, banka. Her biri için bağlantı yöntemini (API, dosya aktarımı, elle) ve sorumlu kişiyi belirleyin. Eski sistemden taşınacak verinin hacmini ve temizliğini de değerlendirin. Basit veri aktarımlarında n8n gibi iş akışı otomasyonu araçları özel geliştirme ihtiyacını azaltabilir; e-fatura tarafındaki bağlantı akışını ise e-Fatura entegrasyonu yazımızda ayrıca anlattık.
Önceliklendirin: MoSCoW yöntemi. Neden: Her istek ilk sürüme girerse proje hem gecikir hem pahalanır; üstelik en önemli özellikler kalabalığın içinde kaybolur. Nasıl: Her hikâyeyi dört gruptan birine yerleştirin. Must have (olmazsa olmaz): Bu olmadan sistem amacına ulaşamaz. Should have (önemli): Değerlidir ama geçici bir çözümle idare edilebilir. Could have (olsa iyi olur): Zaman kalırsa eklenir. Won't have this time (bu sefer yok): Bu sürümde yapılmayacağı açıkça kararlaştırılır. DSDM'nin önerisine göre olmazsa olmazlar toplam eforun yaklaşık yüzde 60'ını geçmemeli; geri kalan pay, beklenmedik durumlar için esneklik sağlar. "Bu sefer yok" listesini yazmak en çok atlanan ama en çok işe yarayan adımdır: konuşulmuş ve ertelenmiş istekler, sessizce kapsama geri sızmaz.
Kapsamı ve kapsam dışını belgeleyin. Neden: Yazılı olmayan kapsam, her iki tarafın da farklı hatırladığı kapsamdır. Nasıl: Kısa ama net bir belge hazırlayın. İçinde şunlar olmalı: amaç ve başarı ölçütü, kullanıcı rolleri, ilk sürümdeki kullanıcı hikâyeleri ve kabul kriterleri, işlevsel olmayan gereksinimler, entegrasyon listesi, kapsam dışı maddeler, varsayımlar ve açık sorular. Mümkünse ana ekranların taslaklarını ekleyin; bir ekran taslağı, sayfalarca metnin anlatamadığını gösterir. Belgeyi paydaşlarla birlikte gözden geçirin ve onaylatın.
Değişiklik sürecini baştan kurun. Neden: Kapsam sürünmesi, yani projenin küçük ve tek tek masum görünen eklemelerle büyümesi, takvim ve bütçe aşımının en yaygın sebebidir. Değişiklik isteği kötü bir şey değildir; kontrolsüz değişiklik kötüdür. Nasıl: Her yeni isteğin aynı yoldan geçmesini sağlayın: yazılı talep, amaca etkisi, tahmini süre ve maliyet, öncelik kararı. Yeni bir istek "olmazsa olmaz" ise, aynı büyüklükte başka bir maddenin sonraki sürüme kayması gerekip gerekmediğini konuşun. Değişiklikleri sürüm notlarıyla birlikte kaydedin ki proje sonunda neyin neden değiştiği görülebilsin.
Örnek: teklif ve sipariş takibi projesi
Varsayımsal bir örnek üzerinden gidelim: endüstriyel ekipman satan, 12 kişilik satış ve operasyon ekibi olan bir firma. Talep "teklifleri sistemden hazırlayalım" olarak gelir. Görüşmelerde şunlar ortaya çıkar: teklifler Excel şablonunda hazırlanıyor, fiyatlar ayrı bir tabloda tutuluyor, yüzde 10'un üzerindeki iskontolar satış müdürünün onayına gidiyor, kabul edilen teklif muhasebe programına elle yeniden giriliyor.
MoSCoW sonucunda ilk sürümün kapsamı şöyle şekillenir: teklif oluşturma, fiyat listesinden ürün seçme, iskonto onayı ve teklifin PDF olarak gönderilmesi olmazsa olmazlar arasında yer alır. Kabul edilen teklifin muhasebeye otomatik aktarımı önemli bulunur ama ilk sürümde dışa aktarılan bir dosyayla geçici olarak çözülür. Müşteri portalı ve mobil uygulama "bu sefer yok" listesine yazılır. Başarı ölçütü olarak teklif hazırlama süresi ve elle yeniden girilen kayıt sayısı belirlenir. Yayından sonra bu ölçütler takip edilerek ikinci sürümün önceliği verilerle belirlenir. Excel şablonlarıyla yürüyen bir süreci yazılıma taşırken nelere dikkat edileceğini Excel'den web uygulamasına geçiş yazımızda ayrıca ele aldık.
Sık yapılan hatalar
- Yalnızca yöneticiyle görüşmek: Kararı yönetici verir, ama işin ayrıntısını kullanıcı bilir. İkisini de dinleyin.
- Çözümle başlamak: "Bir mobil uygulama istiyoruz" bir çözümdür. Önce problemi tanımlayın; çözüm belki bir web paneli ya da mevcut aracın bir ayarıdır.
- Mevcut süreci olduğu gibi kopyalamak: Kâğıttaki her adımı ekrana taşımak, verimsizliği dijitalleştirmektir. Haritalama aşamasında gereksiz adımları sorgulayın.
- Kabul kriterlerini atlamak: "Raporlama olsun" gibi bir madde test edilemez; teslimde tartışmaya dönüşür.
- Analizi bir kerelik iş sanmak: Belge yaşayan bir referanstır; değişiklik kararlarıyla güncellenmelidir.
- Belirsizliği gizlemek: Cevabı bilinmeyen sorular "açık sorular" başlığında görünür olmalı; aksi hâlde en kötü anda ortaya çıkar.
Sık Sorulan Sorular
İhtiyaç analizi ne kadar sürer?
Projenin büyüklüğüne ve paydaş sayısına bağlıdır. Tek bir ekibin kullanacağı sade bir araç için birkaç görüşme ve kısa bir belge yeterli olabilir. Birden fazla departmanı ve entegrasyonu kapsayan projelerde analiz birkaç haftaya yayılır. Analize ayrılan süre, geliştirme sırasında kaybedilecek zamanın yanında genellikle küçüktür.
Çevik (agile) çalışıyorsak ayrıntılı analize gerek var mı?
Çevik çalışma, her şeyi baştan ayrıntılandırmak yerine öğrendikçe ilerlemeyi önerir; ama amaç, kapsam sınırları, öncelikler ve işlevsel olmayan gereksinimler yine baştan bilinmelidir. Fark, kullanıcı hikâyelerinin ayrıntısının her geliştirme döngüsünden önce derinleştirilmesidir.
İhtiyaç analizini kim yapmalı?
İdeal olarak hem işi bilen hem de yazılımın nasıl inşa edileceğini anlayan biri: iş analisti ya da bu rolü üstlenen deneyimli bir geliştirici. İşletme tarafından da karar yetkisi olan ve zaman ayırabilen bir proje sahibi gerekir.
Analiz sonucunda proje iptal edilebilir mi?
Evet ve bu bir başarısızlık sayılmaz. Analiz, ihtiyacın hazır bir araçla karşılanabileceğini ya da beklenen faydanın maliyeti karşılamadığını gösterebilir. Bunu geliştirmeye başlamadan öğrenmek, analizin en değerli sonuçlarından biridir.
Teklif almadan önce analiz belgesi hazırlamak gerekir mi?
Kısa bir ihtiyaç özeti bile tekliflerin karşılaştırılabilir olmasını sağlar. Amaç, kullanıcı rolleri, ana işlemler ve entegrasyonlar listelenmişse, farklı firmaların teklifleri aynı kapsam üzerinden verilir. Ayrıntılı analiz ise genellikle projenin ilk aşaması olarak birlikte yapılır.
Kapsam sürünmesini tamamen önlemek mümkün mü?
Tamamen önlemek gerekmez; projeler ilerledikçe yeni şeyler öğrenilir ve bazı değişiklikler gerçekten değer katar. Amaç, her değişikliğin bilinçli bir kararla, etkisi konuşularak ve kayıt altına alınarak yapılmasıdır.
Kullanıcı hikâyeleri yerine klasik gereksinim listesi kullanabilir miyiz?
Kullanabilirsiniz. Önemli olan biçim değil, her gereksinimin kime hizmet ettiğinin, neden gerektiğinin ve nasıl test edileceğinin açık olmasıdır. Büyük ve sözleşmeye bağlı projelerde ISO/IEC/IEEE 29148 gibi standartlardaki gereksinim yapısı da referans alınabilir.
Projenize sağlam bir başlangıç yapalım
İyi bir ihtiyaç analizi; amacı net, paydaşları dinlenmiş, öncelikleri yazılı ve değişiklik süreci belli bir projedir. Özel yazılım projelerimize bu aşamayla başlıyor, analiz sonunda hem kapsam belgesini hem de ekran taslaklarını sizinle birlikte netleştiriyoruz. Özel yazılım hizmetimizi inceleyebilir ya da projenizi anlatmak için bizimle iletişime geçebilirsiniz.
