Gereksinim Analizi: Ham Talepten Doğrulanabilir Gereksinime

Gereksinim analizi nedir, gereksinim toplamadan farkı ne?

Gereksinim analizi, paydaşlardan gelen talepleri inceleyip netleştiren, birbiriyle tutarlı hale getiren, önceliklendiren ve bir çözüm ekibinin üzerine iş kurabileceği biçimde yazan çalışmadır. Toplama aşaması bilgiyi ortaya çıkarır: görüşme, atölye, gözlem ve doküman incelemesiyle ne istendiği öğrenilir. Analiz aşaması ise bu ham bilgiyi işler.

Bir paydaşın "rapor daha hızlı gelsin" demesi bir taleptir, henüz gereksinim değildir. Hangi rapor, kim için, şu an ne kadar sürede ve hangi koşulda yeterince hızlı sayılacak? Analiz, bu soruları sorup cevabı test edilebilir bir ifadeye dönüştürür.

Gereksinim türleri: neyi analiz ediyoruz?

Talepleri ayırmadan analiz etmek, farklı düzeydeki ihtiyaçları birbirine karıştırır. IIBA'nın BABOK Kılavuzu'nda da kullanılan yaygın sınıflandırma şöyledir: • İş gereksinimleri: Kurumun neden bu değişikliği istediği. Örneğin şikâyet çözüm süresini kısaltmak. • Paydaş gereksinimleri: Belirli bir paydaş grubunun ihtiyacı. Örneğin çağrı merkezi temsilcisinin müşteri geçmişini tek ekranda görmesi. • Çözüm gereksinimleri: Çözümün sağlaması gereken özellikler. Bunlar fonksiyonel (sistemin ne yapacağı) ve fonksiyonel olmayan (performans, güvenlik, erişilebilirlik gibi nasıl yapacağı) olarak ikiye ayrılır. • Geçiş gereksinimleri: Eski durumdan yeni duruma geçerken gereken geçici yetenekler, örneğin veri taşıma ve kullanıcı eğitimi.

Her gereksinimin bir üst gereksinime bağlanabilmesi gerekir. İş gereksinimine bağlanamayan bir çözüm özelliği, kapsam dışına itilmeye adaydır.

Gereksinim analizi adım adım nasıl yapılır?

Aşağıdaki adımlar her toplama turundan sonra tekrarlanır; gereksinim analizi tek seferlik bir iş değildir. • Ham talepleri tek listede toplayın: Görüşme notları, e-postalar ve atölye çıktılarındaki her ifadeyi kaynağıyla birlikte yazın. • Sınıflandırın: Her ifadenin iş, paydaş, çözüm ya da geçiş gereksinimi mi, yoksa bir varsayım, kısıt ya da çözüm önerisi mi olduğunu belirleyin. • Netleştirin: Belirsiz kelimeleri (hızlı, kolay, kullanıcı dostu) ölçülebilir ifadelere çevirmek için paydaşa geri dönün. • Modelleyin: Süreç akışı, veri modeli ya da durum diyagramıyla gereksinimleri görselleştirin; boşluklar ve çelişkiler modelde görünür hale gelir. • Çelişkileri çözün: İki paydaşın çatışan isteklerini karar yetkisi olan kişiyle birlikte netleştirin. • Önceliklendirin: İş değerine, riske ve bağımlılığa göre sıralayın. • Doğrulayın: Her gereksinimin kabul ölçütünü yazın ve paydaşla birlikte gözden geçirin. • İzlenebilirlik kurun: Gereksinimi kaynağına, tasarıma ve test senaryosuna bağlayın.

Bir iş örneği: izin talebi sürecini dijitalleştirmek

İnsan kaynakları ekibi, kâğıt formla yürüyen izin talebi sürecini bir uygulamaya taşımak istiyor. Görüşmelerde şu ifadeler toplanıyor: "Yönetici onayı çok uzun sürüyor", "Kalan izin günlerimi göremiyorum", "Bordroya yanlış yansıyor", "Mobilden de girilebilsin".

Analiz başlar. "Onay uzun sürüyor" bir iş sorunudur; kök neden incelendiğinde formun yöneticinin masasında beklediği anlaşılır. Buradan çözüm gereksinimi çıkar: sistem, talep oluşturulduğunda yöneticiye bildirim gönderir ve belirlenen süre içinde yanıt verilmezse talebi yöneticinin vekiline yönlendirir. Belirlenen sürenin ne olacağı insan kaynakları politikasıyla netleştirilmesi gereken bir karar olarak kayda alınır.

"Bordroya yanlış yansıyor" ifadesinin arkasında bir veri gereksinimi vardır: onaylanan izinler, bordro sistemine hangi alanlarla ve ne zaman aktarılacak? "Mobilden girilebilsin" ise fonksiyonel olmayan bir erişim gereksinimidir. Dört ifade, analiz sonunda kaynağı belli, kabul ölçütü yazılmış ve önceliklendirilmiş bir gereksinim setine dönüşür.

İyi bir gereksinim nasıl yazılır?

İyi yazılmış bir gereksinim tek anlamlıdır, test edilebilir, tek bir ihtiyacı anlatır, bir çözüm dayatmaz ve kaynağı bellidir. Kötü ve iyi örnekleri yan yana görmek farkı netleştirir: • Kötü: Sistem kullanıcı dostu olmalı. İyi: Yeni bir çalışan, eğitim almadan ilk izin talebini yardım almadan oluşturabilmeli; bu durum kullanılabilirlik testinde doğrulanır. • Kötü: Raporlar hızlı açılmalı. İyi: Aylık izin raporu, tam yıl verisiyle, yönetici panelinden istendiğinde kabul edilen süre içinde görüntülenmeli. Kabul süresi paydaşla birlikte sayısal olarak yazılır. • Kötü: Onay için açılır menü kullanılsın. İyi: Yönetici, talebi onaylayabilmeli ya da gerekçe yazarak reddedebilmeli.

Son örnekte ilk ifade bir arayüz kararını dayatıyor; iyi ifade ihtiyacı anlatıp tasarımı ekibe bırakıyor. Çevik ekiplerde aynı ilke kullanıcı hikâyesi ve kabul ölçütleri biçiminde uygulanır.

Gereksinim analizinde kullanılan teknikler

Tek bir teknik her durumu çözmez; analist ihtiyaca göre seçer: • Süreç modelleme: Mevcut ve hedef süreci BPMN gibi bir gösterimle çizip adımları, karar noktalarını ve rolleri görünür kılmak. • Kullanım senaryoları ve kullanıcı hikâyeleri: Kullanıcının sistemle etkileşimini adım adım ya da kısa hikâyeler halinde anlatmak. • Karar tabloları: Çok koşullu iş kurallarını (izin türü, kıdem, kalan gün) eksiksiz listelemek. • Veri modeli ve sözlük: Hangi verinin tutulacağını ve terimlerin aynı anlamda kullanılmasını sağlamak. • Prototip ve ekran taslağı: Paydaşın soyut tarifini somut bir ekranda doğrulamak. • Önceliklendirme yöntemleri: MoSCoW gibi tekniklerle zorunlu ve ertelenebilir gereksinimleri ayırmak. • İzlenebilirlik matrisi: Her gereksinimin kaynağını, tasarımını ve testini aynı tabloda izlemek.

Sık yapılan hatalar ve öğrenme yolu

En yaygın hatalar şunlardır: paydaşın önerdiği çözümü gereksinim diye yazmak, fonksiyonel olmayan gereksinimleri sona bırakmak, kabul ölçütü yazmamak, tek paydaş grubuyla konuşup diğerlerini atlamak ve değişen gereksinimleri kayda almadan uygulamak.

Öğrenmeye kendi işinizden küçük bir süreçle başlayın: mevcut durumu çizin, birkaç ham talep toplayın ve bunları sınıflandırıp kabul ölçütleriyle yeniden yazın. Ardından süreç modelleme, karar tabloları ve önceliklendirme tekniklerini aynı örnek üzerinde deneyin. İleri aşamada strateji analizi, çözüm değerlendirme ve BABOK Kılavuzu'ndaki bilgi alanları üzerinden bütünlüklü bir iş analizi çerçevesi kurabilirsiniz.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

İş Analizi Uzmanlığı Sertifika Programı; gereksinim ortaya çıkarma ve paydaş işbirliği, gereksinim yaşam çemberi yönetimi, gereksinim analizi ve tasarım tanımı ile çözüm değerlendirmesi modülleriyle bu adımların tamamını BABOK çerçevesinde ele alır.

Yapay Zeka Destekli İş Analistliği Sertifika Programı ise gereksinim toplama teknikleri, gereksinim yazımı ve dokümantasyon, önceliklendirme ve izlenebilirlik, süreç analizi ve BPMN modüllerini yapay zeka araçlarıyla birlikte çalışır.