Görüşmeler bitti. Şimdi konuşulanları, başka biri okuyup aynı şeyi yapacak hâle getiriyorsun. İyi bir gereksinimin ölçüsü basit: geliştirici ve test uzmanı birbirine sormadan aynı sonuca varır.
Üç tür ifade
| Tür | Neyi söyler? | Kupon örneği |
|---|---|---|
| İşlevsel gereksinim (functional) | Sistem ne yapar | Sistem, geç teslim edilen siparişte müşteriye kupon oluşturur. |
| İşlevsel olmayan gereksinim (non-functional) | Sistem bunu hangi nitelikte yapar: hız, güvenlik, kayıt, erişilebilirlik | Kupon, teslim kaydından en geç 5 dakika sonra görünür. |
| İş kuralı (business rule) | Sistemden bağımsız şirket kararı | Bir müşteri bir takvim ayında en çok 2 kupon alır. |
Tutar değişirse kod değil, kural değişmelidir. Bu ayrımı yazmak, geliştiriciye “bu değer sabit mi, ayar mı?” sorusunu baştan sordurur.
Belirsizden açığa
| Belirsiz | Neden sorunlu? | Test edilebilir hâli |
|---|---|---|
| Geç teslimlerde hızlıca kupon verilir. | Geç ve hızlı kişiye göre değişir | Teslim süresi 2.700 saniyeyi aşan siparişte kupon, teslim kaydından en geç 5 dakika sonra oluşur. |
| Kupon makul bir tutarda olur. | Makul bir sayı değil | Süre 2.700 saniyeyi aşıp 3.600 saniyeyi aşmıyorsa 30 TL, 3.600 saniyeyi aşıyorsa 60 TL. |
| Kötüye kullanım engellenir. | Hangi davranış, ne olur? | Takvim ayında 2 kupon almış müşteriye yeni kupon üretilmez, kayıt “sınır dolu” nedeniyle loglanır. |
| Müşteri bilgilendirilir. | Hangi kanal, hangi metin? | Kupon oluşunca uygulama içi bildirim gider; metin ve kanal EK-2'dedir. |
“Hızlı, kolay, uygun, gerektiğinde, vb.” sözcüklerini gördüğünde dur. Yerine sayı, koşul ya da liste yaz.
Kullanıcı hikâyesi (user story)
Agile (çevik) ekiplerde iş çoğu zaman şu kalıpla yazılır: Bir [kim] olarak, [ne] istiyorum, böylece [neden].
Bir müşteri olarak, siparişim söz verilen süreyi aştığında otomatik telafi kuponu almak istiyorum, böylece destek ekibine yazmadan hakkım olanı alırım.
Hikâyenin yeterince iyi olup olmadığını INVEST ile sınarsın:
| Harf | Soru | Kuponda |
|---|---|---|
| Independent (bağımsız) | Başka hikâyeyi beklemeden yapılabilir mi? | Kupon üretimi ödeme ekranı değişikliğini beklemez |
| Negotiable (konuşulabilir) | Ayrıntı ekiple netleşebilir mi? | Bildirim metni birlikte yazılır |
| Valuable (değerli) | Birine değer sağlıyor mu? | Müşteri ve destek ekibi kazanır |
| Estimable (tahmin edilebilir) | Ekip büyüklüğünü kestirebilir mi? | Kurallar yazılıysa evet |
| Small (küçük) | Bir iterasyona sığıyor mu? | “Kupon sistemini kur” değil, “geç teslimde kupon üret” |
| Testable (test edilebilir) | Bitti diyebilir miyiz? | Kabul kriterleri var |
Kabul kriteri (acceptance criteria): Given / When / Then
Given başlangıç durumu, When olay, Then beklenen sonuçtur. Türkçe çalışan ekipler bunu “Diyelim ki / Eğer ki / O zaman” diye de yazabilir.
Senaryo: 60 dakikayı aşan teslim Given durumu "teslim" olan bir sipariş var And sipariş ile teslim arası 3.601 saniye And müşterinin bu ay aldığı kupon sayısı 1 When kupon işi siparişi değerlendirir Then müşteriye 60 TL kupon oluşur And kupon teslim kaydından en geç 5 dakika sonra görünür Senaryo: İade edilmiş sipariş Given durumu "iade" olan bir sipariş var And sipariş ile teslim arası 4.000 saniye When kupon işi siparişi değerlendirir Then kupon oluşmaz Senaryo: Kupondan sonra gelen iade Given 3.000 saniyede teslim edilen siparişe 30 TL kupon oluşmuş And kupon henüz kullanılmamış When sipariş iade edilir Then kupon iptal edilir And iptal, sipariş numarasıyla kayda geçer
Oluşturma senaryolarının tetikleyicisi tek: teslim kaydı kupon işini başlatır, iş siparişi değerlendirir. Her kriterde aynı cümleyi yaz; farklı yazarsan okuyan iki ayrı olay olduğunu sanar. Üçüncü senaryonun olayı gerçekten farklıdır: iade, kupondan sonra gelir.
Kenar durumları veriden bul
Toplantıda aklına gelmeyen durumları veri söyler. Her biri bir soru üretir, cevabı bir kural olur.
SELECT status, COUNT(*) AS siparis,
SUM(CASE WHEN delivered_at IS NULL THEN 1 ELSE 0 END) AS teslim_zamani_bos,
SUM(CASE WHEN courier_id IS NULL THEN 1 ELSE 0 END) AS kurye_bos
FROM lk_orders
WHERE placed_at >= '2024-10-01' AND placed_at < '2025-01-01'
GROUP BY status
ORDER BY status;
| Veride gördüğün | Doğan soru | Kural |
|---|---|---|
| 356 iptal siparişte teslim zamanı boş, 195 tanesinde kurye de yok | Süre hesaplanmayan kayıt ne olacak? | İptalde kupon yok; süre hesaplanmaz |
| 35 iade siparişi de 45 dakikayı aşmış | Parası iade edilene bir de kupon mu? | Yalnız “teslim” durumu kupon alır |
| 3 teslimat tam 2.700 saniye sürmüş | “Aşan” mı, “ve üzeri” mi? | 2.700 geç değildir; sınır dahil değil |
| 32 müşteri-ayda 2'den çok geç teslim var | Sınır gerçekten çalışır mı? | Ayda en çok 2; 35 kupon sınırdan düşer |
| Dönem sınırında 3 sipariş 1 Ocak 2025'e sarkmış | Hangi aya yazılır? | Ay, sipariş zamanına göre belirlenir |
| Dönemde 182 iade var, ama iadenin ne zaman yapıldığı tutulmuyor | Kupon 5 dakikada oluşur, iade sonra gelirse kupon geri alınır mı? | Öneri: kullanılmamış kupon iptal edilir; kullanılmışsa geri alınmaz. Karar finansın, açık soruya yazılır |
DATEDIFF(minute, ...) ifadesi dakika sınırı geçişlerini sayar. Bu yüzden kural saniye ile yazıldı. Böyle bir ayrıntı gereksinimde açık yazılmazsa testte değil canlıda ortaya çıkar.Çıktın: numaralı gereksinim listesi, iş kuralları tablosu, hikâyeler ve her hikâyenin kabul kriterleri. Bunlar BRD'nin kalbidir.