Bir iş analisti her bir gereksinim için kabul kriterlerini (acceptance criteria) formel hale getirmelidir, böylece bunlar proje katılımcıları için anlaşılır ve net olur: müşteri, geliştiriciler ve test uzmanları. Bunun için, Gherkin (Given-When-Then) notasyonlarında kriterler formüle etmek, kontrol listeleri ve kullanım durumları (use cases) gibi teknikler uygulanır. Analist kriterleri gereksinim belgelerinde dokümante eder ve her gereksinime, görevin yerine getirildiğini kesin bir şekilde onaylamak için bir dizi nesnel koşul seti sağlanmasına özen gösterir.
Ana özellikler:
Gereksinimleri açıklamak için yalnızca kullanıcı hikayeleri kullanmak mümkün mü, ek kabul kriterleri olmadan?
Hayır, açık kabul kriterleri olmayan kullanıcı hikayeleri çok soyut ve farklı şekillerde yorumlanabilir. Gereksinimin doğru bir şekilde yerine getirildiğini anlamak için kriterlere ihtiyaç vardır.
Kabul kriterlerine işlevsel olmayan gereksinimleri (örneğin, performans) dahil etmek gerekli mi?
Evet, işlevsel olmayan gereksinimlerin de kriterlerde yer alması gerektiği, aksi takdirde bunların unutulma veya tam olarak yerine getirilme riski vardır.
Kabul kriterlerini kim onaylamalı: sadece iş analisti mi?
Hayır, her zaman kriterlerin müşteri ile onaylanması ve mümkünse geliştirme ekibiyle de anlaşılması gereklidir, bu da yanlış anlamaları en aza indirir.
Olumsuz durum: İş analisti kabul kriterlerini müşteri ile onaylamadı ve geliştiriciler gereksinimleri kendi anlayışlarına göre yorumladı. Artılar: Hızlı geliştirme, herhangi bir görüşme süreci geciktirmedi. Eksiler: Yayından sonra fonksiyonelliğin %70'i gerçek beklentilere uymadı, çatışma ortaya çıktı.
Olumlu durum: Analist formal kabul kriterlerini detaylandırdı, her iki tarafla onayladı ve bunları kullanıcı hikayelerine ekledi. Artılar: Müşteri ile takım arasında anlayış ve yayın sonrası en az hata. Eksiler: Başlangıçta onay sürecine biraz daha fazla zaman harcandı.