Projelerde 3 Gereksinim Türü
Gereksinim Analizi, projenin başarısını doğrudan etkileyen kritik bir faaliyet. Yüz yüze görüşme, beyin fırtınası, çalıştay, işi yerinde inceleme, süreç akışları ve bilgi kaynaklarının incelenmesi gibi birçok yöntem ile ihtiyaçların analizini gerçekleştirebiliyoruz.
Bunların ilki bilinen gereksinimler. Analiz tekniklerinin uygulanması ile ilgili paydaşlar tarafından bize iletilen veya farklı bilgi kaynaklarından tespit ettiğimiz ihtiyaçlar bunlar. Ancak yazılım analizi, diğer mühendislik dallarından farklı olarak soyut bir ürün üzerinde konuştuğumuz için ayrıca zor. Bazen analist olarak doğru soruları soramayabiliyoruz. Doğru paydaşlar her zaman katılım sağlayamayabiliyor. Görüşülen paydaş tatmin edici cevaplar veremeyebiliyor, doğal olarak her şeyi düşünemeyebiliyor. Toplantı paydaşların başka işleri sebebiyle kısa tutulabiliyor. Karşı tarafta yeterli sahiplenme olamayabiliyor. Bunlar vb. nedenlerden ötürü, karşı tarafın aslında bildiği ancak bir şekilde aktarılamayan veya bizim eksik anladığımız / tespit edemediğimiz gereksinimler muhakkak oluyor. Bunlar da bizim için gözden kaçan gereksinimler.
Gözden kaçan gereksinimleri çözdüğümüzde aslında sorunumuz büyük ölçüde çözülebilir gibi. Ancak farkında olmamız gereken bir gereksinim türü daha var. Sonradan ortaya çıkan gereksinimler. Bunlar yazılımın geliştirilmesi aşamasında ortaya çıkan, henüz kimsenin farkında olmadığı yeni gereksinimler. Kabiliyetli analistler, çok detaylı çalışsalar da, en iyi soruları sorsalar da, son kullanıcılar ne kadar kafa patlatsalar da ortaya çıkarabilecekleri gereksinimler değil. Yazılım kullanıldıkça ihtiyaç olduğunun farkına varılan gereksinimler. Proje açısından en fazla risk taşıyan gereksinimler de bunlar, henüz farkındalık yok, bize ne kadar maliyet ve süre gerektireceğini de bilmiyoruz. Bu nedenle bunların mümkün olduğunca erken dönemde belirlenmesi bizim için önem taşıyor. Bunun için erken dönemde yazılım teslimatları yaparak son kullanıcıdan hızlı bir şekilde geri bildirim almak gerekiyor. Sonradan ortaya çıkacak gereksinimlerin belirlenmesi için son kullanıcının yazılımı görmesi, kullanması, “Bir de buna ihtiyacım var aslında” demesi gerekiyor. Ne kadar erken, bizim için o kadar iyi. Çevik yaklaşımın çözmeye çalıştığı temel sorunlardan birisi de bu aslında, belirsizliğin getirdiği riski iterasyonlar aracılığıyla, erken teslimat-erken geri bildirim döngüleriyle ötelemek. Scrum kullanılıyorsa, Sprint Gözden Geçirme toplantılarına son kullanıcıları da davet etmek, henüz yazılımı kurmadan bu gereksinimleri belirleme konusunda bize yardımcı olacaktır.
Bunun için strateji, sonradan ortaya çıkabilecek gereksinimlerin varlığını bilerek hareket etmek, halı altında kalmalarına izin vermemek olmalı. Yazılımımız gerçekten ihtiyaçları karşılıyor mu, bunu dikkatle gözlemlemek gerekiyor. Projenin geç bir aşamasında “Ama bu bize söylenmemişti” demek, bizi kurtaramayabilir çünkü.
