Kararın dayanağı
Teknolojiden önce gözlenebilir davranışı yazın: kişi, başlangıç durumu, işlem ve doğrulanabilir sonuç. Sonucu değiştiren yetkileri ve istisnaları ekleyin.
Somut bir örnek
Varsayımsal masraf aracında çalışan fiş yükler, yönetici onaylar veya gerekçeyle geri çevirir, muhasebe onaylananları aktarır. Okunamayan fişi, yöneticinin yokluğunu ve onaydan sonra tutarın değiştirilmesini tarif edin.
Uygulayarak anlatılabilecek bir örnek yazmak
Masraf başvurusunu somut, kurgu değerlerle tarif edin: çalışan belirli bir seyahatin fişini yükler, projeyi seçer ve gönderir. Yönetici yalnız incelemeye yetkili olduğu başvuruları görür. Geri çevirirken gerekçe girmesi gerekir; başvuru yeniden düzenlenebilir hale gelir. Onay, kabul edilen sürümü korur. Buradaki “kilitleme”nin anlamını ayrıca yazın: sonradan düzeltme yeni sürüm mü oluşturur, yeniden onay mı ister, yoksa reddedilir mi? Teknik uygulamaya geçmeden başka biri bu örneği kartlar veya basit bir çizimle canlandırabilmelidir.
Kuralları önerilerden ve varsayımlardan ayırmak
Zorunlu kuralı, tasarım önerisini ve açık soruyu ayrı işaretleyin. “Onaylanan masrafları yalnız muhasebe dışa aktarabilir” bir yetki kuralıdır. “Aktarma düğmesi sağ üstte olsun” tasarım önerisidir. “Muhasebenin tablo dosyasına ihtiyacı var” ise dosyanın kullanılacağı süreç bilinmeden varsayımdır. Bu ayrım, tasarımcının verilen sözü değiştirmeden arayüzü iyileştirmesini sağlar. Kuralın kaynağını ve açıklayabilecek kişiyi de yazın. Sözleşmesel veya hukuki koşullarda geliştiriciden aktarılan bir özetle tahmin yürütmesini istemek yerine yetkili metni veya uygun uzman yorumunu edinin.
Gereksinimi işlemin iki tarafıyla gözden geçirmek
Başvuran, yönetici ve muhasebe görevlisinden aynı örneği izlemelerini isteyin. Kesilen yükleme, bulunamayan yönetici, tekrarlanan aktarım ve onaydan sonra düzeltilen fiş gibi farklı sorunlar sorabilirler. Gerekli kararları ekleyip zorunlu olmayan tercihleri açık bırakın. Gösterimin neyi kanıtlayacağını ve hangi güvenli verilerle yapılacağını yazın. Onaylı gereksinimleri sürümleyerek sonraki değişiklikler için bilinen bir başlangıç noktası bırakın. Açık gereksinim, teknik terimi çok olan değil, ekip adına iş kararı uydurmadan geliştirilebilen ve sınanabilen tanımdır.
Değerlendirilecek seçenekler
Kısa anlatım bağlamı, notlu çizim etkileşimi, kabul örneği sınırları açıklar. Gerektiği kadar birleştirin; büyük belge güncel kararların yerini tutmaz.
Planın aksadığı yer
İş kuralını anlatmak için veritabanı tabloları önermeyin. “Hızlı” ve “kolay” ifadesine iş ve değerlendirme ölçütü ekleyin. Gerekli davranışla tasarım önerisini ayırıp çelişkileri çözecek kişiyi belirleyin.
İşe başlamadan önce
Başka biri bu tanımdan başarıyı ve hatayı gösterebilir mi? Roller belli mi? Örnek kayıtlar paylaşmaya uygun mu? Gereksinim ve açık durumları MVP görüşmesine getirin.