Soru tarihçesi:
BT projelerinin ölçeği ve karmaşıklığı arttıkça, işverenlerden gelen gereksinimlerin soyut istekler biçiminde ifade edildiği ve bu gereksinimlerin geliştirici ekibe aktarıldığında başka bir şeye dönüştüğü durumlar sıkça yaşanmıştır. Bunun nedeni, iş dünyası ile BT arasındaki terminoloji, beklentiler ve soyutlama düzeyindeki kopukluktır.
Problem:
Eğer ayrıştırma aşaması düşünülmezse, gereksinimler ya eksik olur (kritik ayrıntılar atlanır), ya da aşırı belirsiz hale gelir (değerlendirmek ve gerçekleştirmek mümkün olmaz) ya da tamamen, kelime oyunları, dikkate alınmamış terminoloji ve çelişkiler nedeniyle çarpıtılır.
Çözüm:
Sistem analisti, her bir gereksinimi sırayla ayrıştırır: iş terimlerini biçimlendirir, iş hedeflerini fonksiyonlar ve görevler haline çevirir, kullanıcı senaryolarını ve sistem davranışını tanımlar, kabul kriterlerine/test senaryolarına bağlar. Modeller (UML, BPMN), sözlükler, kontrol listeleri ve ekipler arasında doğrudan gözden geçirme yapmak önemlidir.
Temel özellikler:
İş isteklerini serbest formatta bırakıp, geliştirme aşamasında daha sonra üzerinde çalışmak mümkün mü?
Hayır, yanlış anlama ve uygulama hatası riski yüksektir.
Analiz aşamasında gerçekleştirme detaylarına (örneğin, verileri nasıl saklayacağım) kadar inmeli miyim?
Hayır, analiz "ne" ve "neden" ile ilgilidir, "nasıl" ile değil. Teknik detaylar, mimari ve geliştirme sorumluluğundadır.
Her zaman bir gereksinim kaydı = bir modül/özellik midir?
Hayır, genellikle ayrıştırma gereklidir—büyük gereksinimler alt fonksiyonlara ve belirli kabul kriterlerine sahip kullanıcı hikayelerine bölünür.
Olumsuz durum: İşveren, "Kullanıcı tüm satış analitiğini görmeli" şeklinde bir istek listesi gönderdi, bu da teknik şartnamedeki haliyle kopyalandı.
Artılar:
Eksiler:
Olumlu durum: Analist, işvereni sorguladı, gerekli metriklerin bir listesini oluşturdu, kullanıcı rolleri belirledi, rapor prototipleri geliştirdi ve terminoloji sözlüğünü onayladı.
Artılar:
Eksiler: