Yazılım Projesinde Kabul Kriteri Nasıl Yazılır?

Bir teklifin içinde “stok yönetimi yapılacaktır” yazması, teslim edilecek davranışı açıklamaz. Kullanıcı son ürünü iki farklı kanaldan sattığında ne olacağı, iptal edilen siparişin stoğu nasıl serbest bırakacağı ve hangi ekibin düzeltme yapabileceği hâlâ belirsizdir. Kabul kriteri, bu belirsizliği test edilebilir bir sonuca dönüştürür. Amaç yazılımcıya her satırın nasıl kodlanacağını söylemek değil, işletmenin hangi davranışı doğru kabul ettiğini ortaya koymaktır.

Özellik listesini iş sonucuna dönüştürün

Her kriterin bir başlangıç durumu, kullanıcı işlemi ve gözlenebilir sonucu olmalıdır. “Depoda beş adet bulunan ürün için iki adetlik onaylı sipariş oluşturulduğunda satılabilir miktar üç olur” cümlesi denenebilir. “Sistem hızlı çalışır” cümlesi ise yük, veri hacmi ve ölçüm noktası olmadan doğrulanamaz. Performans beklentisini gerçekçi bir örnek katalog ve eşzamanlı kullanıcı sayısıyla birlikte yazın. Ölçümü hangi ortamda yapacağınızı da belirtin; geliştiricinin küçük deneme verisi işletmenin gerçek çalışma koşullarını temsil etmeyebilir.

Bir kriterin üç sınırını belirleyin

Önce olumlu akışı kaydedin. Ardından geçersiz girişin nasıl karşılanacağını tarif edin. Son olarak aynı işin tekrarlanması veya yarıda kesilmesi durumunu ekleyin. Sipariş kaydeden personelin bağlantısı kesildiğinde tekrar denemesi ikinci sipariş oluşturmamalıdır. Buna karşılık farklı bir müşteri için yeni işlem açılması engellenmemelidir. Hangi girdinin aynı iş sayıldığını ekip birlikte tanımlamalıdır; yalnızca butonu devre dışı bırakmak iş kuralının yerine geçmez.

Teslim toplantısında kullanılabilecek örnek

Bir bayi sipariş ekranı düşünün. Bayi kendisine atanmış fiyatı görür; başka bayinin adresini veya iskonto bilgisini göremez. Limit aşımı varsa sipariş otomatik onaylanmak yerine belirlenmiş inceleme durumuna geçer. Yönetici onayı verdiğinde işlem zamanı ve onaylayan kişi kaydedilir. Fiyat listesi daha sonra değiştiğinde geçmiş siparişin birim fiyatı değişmez. Bu dört cümle tek bir “bayi modülü” maddesinden çok daha açık bir teslim çerçevesi oluşturur.

• Deneme hesabının rolünü, örnek ürünleri ve başlangıç bakiyesini kaydedin.
• Her kriteri tek başına geçti veya kaldı şeklinde değerlendirilebilir yazın.
• Sonuç kanıtına kayıt numarası, ekran görüntüsü veya uygun bir işlem günlüğü ekleyin.
• Başarısız kriteri ilgili hata kaydıyla eşleştirin; sözlü notla kapatmayın.

Değişiklik ile hatayı ayırın

Onaylanmış kriterin sağlanmaması hata olarak ele alınabilir. Daha önce konuşulmamış yeni bir onay basamağı ise kapsam değişikliğidir. Bu ayrımın proje başında yapılması tarafların aynı tartışmayı her teslimde yeniden yaşamasını önler. Kriterler değiştirilemez belgeler değildir; değişikliğin gerekçesi, etkilediği ekranlar ve yeniden test gereksinimi görünür tutulmalıdır. Eski sürümleri saklamak, kabulün hangi beklenti üzerinden verildiğini açıklamayı kolaylaştırır.

Küçük bir kabul oturumu planlayın

İlk oturuma onlarca özellik taşımak yerine bir uçtan uca süreci seçin. İş birimi temsilcisi işlemi kendi hesabıyla yapsın, geliştirici yalnızca gözlemlesin. Beklenmeyen bir durumda kullanıcıya yönlendirme yapılması gerekiyorsa bunu kullanım sorunu olarak kaydedin. Oturum sonunda açık hataların önem derecesini, tekrar deneme tarihini ve kabul kararını yazılı hale getirin. Canlıya geçiş için engelleyici sayılacak durumlar önceden kararlaştırıldığında, teslim kararı kişisel izlenimden ölçülebilir kanıta taşınır.

İlgili rehber: Özel Yazılım Fiyatları: Kapsam ve Bütçe Planlama.