BRD yazmak: bölümler, gereksinim dili ve örnek yapı

BRD neyi yazar, neyi yazmaz?

BRD, iş sorununu ve beklenen sonucu yazılı hale getirir. Kimin hangi sorunu yaşadığı, bunun iş açısından önemi, hedeflenen çıktı ve başarının nasıl anlaşılacağı dokümanın ana içeriğidir. Okuyucu hem iş birimi yöneticisi hem sponsor hem de teknik ekip olduğundan dil sade, terimler tanımlı olmalıdır.

BRD ekran tasarımı, veritabanı yapısı ya da yazılım mimarisi anlatmaz. Bu ayrıntılar işlevsel gereksinim dokümanında ve tasarım belgelerinde yer alır. İş gereksinim ile işlevsel gereksinim arasındaki fark ayrı bir konudur; BRD yazımında önemli olan, iş ihtiyacını çözümden ayrı tutabilmektir.

Bazı kurumlar BRD yerine kısa bir iş gerekçesi veya vizyon belgesi kullanır, bazıları çevik çalışmada ürün backlog'unu ve epik tanımlarını bu işlev için kullanır. Doküman biçimi değişse de sorulan sorular aynı kalır: neden, ne, kim için ve nasıl anlaşılır?

BRD bölümleri: örnek bir yapı

Kurumun şablonu yoksa şu yapı iyi bir başlangıç sağlar.

• Amaç ve arka plan: sorun, tetikleyici ve mevcut durumun kısa anlatımı
• İş hedefleri ve başarı ölçütleri: ulaşılmak istenen sonuç ve nasıl ölçüleceği
• Kapsam: dahil olan ve olmayan konular, etkilenen süreçler ve sistemler
• Paydaşlar: roller, sorumluluklar, karar yetkisi
• Mevcut durum ve hedef durum: süreçlerin bugünkü hali ve değişim sonrası beklenen hali
• Gereksinimler: kimlikli, açık ve öncelikli iş gereksinimleri
• Varsayımlar, kısıtlar ve bağımlılıklar
• Riskler ve açık konular
• Kabul kriterleri
• Onay ve sürüm geçmişi

Her bölüm kısa tutulur. Kurumsal projelerde uzun BRD, okunmayan BRD demektir; yalnız karar verici ve uygulayıcının ihtiyaç duyduğu bilgi yer almalıdır. Uzun tablolar ve ayrıntılı iş akışları ek olarak eklenir.

Gereksinimler hangi düzeylerde yazılır?

İş analizinde gereksinimler genellikle dört sınıfta ele alınır. İş gereksinimleri kurumun hedeflerini ve neden değişime ihtiyaç duyulduğunu anlatır. Paydaş gereksinimleri belirli paydaş gruplarının bu hedefe ulaşmak için ihtiyaçlarını ifade eder. Çözüm gereksinimleri, işlevsel ve işlevsel olmayan olarak çözümün sahip olması gereken özellikleri tanımlar. Geçiş gereksinimleri ise mevcut durumdan yeni duruma geçişte gereken önlemleri, örneğin veri taşıma ya da eğitim ihtiyacını kapsar.

BRD ağırlıkla ilk iki düzeyi ve gerekiyorsa çözümün üst düzey gereksinimlerini içerir. Ayrıntılı çözüm gereksinimleri ayrı bir dokümana ya da ürün backlog'una taşınır. Katmanlar birbirine izlenebilir olmalıdır: her çözüm gereksinimi bir paydaş ihtiyacına, her ihtiyaç bir iş hedefine dayanmalıdır. Dayanağı olmayan gereksinim, kapsamın sessizce büyümesine yol açar.

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

İyi bir gereksinim tek bir şey söyler. İçinde "ve" ile bağlanmış birden çok yükümlülük varsa ayrılır. Açıktır: farklı iki kişi okuduğunda aynı anlamı çıkarır. Test edilebilirdir: karşılandığı ya da karşılanmadığı bir gözlemle ya da testle belirlenebilir.

Belirsiz sıfatlar ve zarflar kabul kriteri olmadan kullanılmaz. "Hızlı", "kolay", "güvenli", "esnek" gibi sözcükler ya ölçülebilir bir koşula çevrilir ya da çıkarılır. Örneğin hız için hedef süre ve hangi veri hacminde ölçüleceği yazılır; kullanım kolaylığı için yeni bir kullanıcının belirli bir işi yardımsız tamamlayabilmesi koşulu yazılır.

Gereksinimler "kim, ne, hangi amaçla" biçiminde ifade edilebilir: "Satış yöneticisi olarak ekibimin aylık satışını görmek istiyorum, çünkü hedef sapmalarına zamanında müdahale etmek istiyorum." Bu biçim ihtiyacın gerekçesini de taşır. Her gereksinime kimlik, öncelik ve sahibi verilir.

Yazım süreci ve onay

BRD tek başına masa başında yazılmaz. Önce paydaş görüşmeleri, çalıştaylar ya da belge incelemesiyle ihtiyaçlar toplanır; sonra yazılan taslak paydaşlarla gözden geçirilir. Gözden geçirmede her gereksinim için iki soru sorulur: doğru mu, ve eksik olan bir şey var mı?

Çelişkiler ve açık konular dokümanda bir listeyle izlenir. Sahipleri ve kapanış tarihleri yazılır. Onay aşamasında sponsor ve kilit paydaşlar dokümanın sürümünü onaylar. Onaydan sonra gelen değişiklikler değişiklik talebi süreciyle işlenir ve sürüm geçmişine yazılır.

BRD canlı bir dokümandır ama kontrolsüz değişmez. Her değişikliğin kimden geldiği, neden gerektiği ve diğer gereksinimleri nasıl etkilediği kayıt altına alınır.

Öncelik vermek için sık kullanılan bir sınıflama, gereksinimleri zorunlu, olmalı, olabilir ve bu sürümde yok diye ayırır. Sınıflamayı sponsor ve kilit paydaşlarla birlikte yapın; çünkü her şeyin zorunlu çıkması, önceliklendirme yapılmadığı anlamına gelir. Yapılmayacak şeyleri de yazılı bırakmak, sonradan çıkan beklentiyi tartışmadan karşılamaya yarar.

Sık yapılan hatalar

Çözümü gereksinim olarak yazmak ilk hatadır: "Sistemde açılır liste olmalı" bir çözümdür; asıl gereksinim, kullanıcının sınırlı seçenekler arasından seçim yapabilmesidir. Çözüm yazıldığında tasarım seçenekleri erken kapanır.

İkinci hata, kapsam dışı bölümünü atlamaktır. Üçüncü hata, paydaşların yalnız bir kısmıyla çalışmaktır; unutulan grup sonradan itiraz eder. Dördüncü hata, gereksinimleri önceliklendirmemektir; her şey "zorunlu" olursa hiçbiri öncelikli değildir.

Beşinci hata, dokümanı yazıp dağıtmak ama onay almamaktır. Onaysız doküman, anlaşmazlıkta dayanak olmaz.

Göndermeden önce kısa bir gözden geçirme listesi işe yarar:

• Her gereksinimin kimliği, önceliği ve sahibi var mı?
• Belirsiz sıfat içeren ifade kaldı mı, her birinin kabul kriteri yazıldı mı?
• Çözüm anlatan bir cümle gereksinim gibi yazılmış mı?
• Kapsam dışı bölümü dolu mu?
• Her gereksinim bir iş hedefine dayanıyor mu?
• Açık konuların sahibi ve kapanış tarihi belli mi?
• Paydaş listesindeki herkes dokümanı gördü mü?

Örnek: sipariş durumu sorgulama ihtiyacı için BRD kesiti

Kurgusal bir örnek: bir dağıtım şirketinin müşteri hizmetleri ekibi, zamanının büyük kısmını "siparişim nerede" çağrılarına ayırıyor; müşteriler de yanıt için bekliyor. Amaç ve arka plan bölümü bu sorunu, tetikleyiciyi ve mevcut durumu birkaç cümleyle yazar. İş hedefi, müşterinin sipariş durumunu telefona gerek kalmadan kendisinin görebilmesidir. Başarı ölçütü, durum sorgusu çağrılarının belirgin biçimde azalmasıdır; hedef değer ve ölçüm dönemi paydaşlarla belirlenip dokümana işlenir.

Kapsam bölümü yalnız sipariş durumunun görüntülenmesini içerir. Sipariş değiştirme, iade başlatma ve ödeme kapsam dışı yazılır. Paydaşlar müşteri hizmetleri yöneticisi, depo sorumlusu, satış yöneticisi ve bilgi işlem ekibidir; karar yetkisi sponsorda durur. Gereksinimler kimlikle ve öncelikle yazılır:

• Müşteri, giriş yaptıktan sonra yalnız kendi siparişlerinin güncel durumunu görebilmeli. Öncelik: zorunlu. Kabul kriteri: başka müşterinin siparişi hiçbir koşulda listelenmez.
• Depodaki durum değişikliği, paydaşlarla kararlaştırılan gecikme sınırı içinde müşteriye yansımalı. Öncelik: zorunlu. Kabul kriteri: sınır dokümanda yazılır ve test ortamında ölçülür.
• Müşteri isterse durum değişince bildirim alabilmeli. Öncelik: olsa iyi olur.

Varsayımlar bölümüne depo sisteminin durum bilgisini dışarı verebildiği yazılır; doğrulanmamışsa bu bir risktir ve açık konular listesine girer. Dikkat edin: örnekte ne bir ekran biçimi ne de bir yazılım seçimi var; BRD çözümü değil ihtiyacı kayda geçirir.

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

İş analizi uzmanlığı programında gereksinim yaşam çemberi yönetimi ve gereksinim analizi başlıkları, gereksinimlerin yazımı, doğrulanması ve takibini işler. İş analistliği BABOK çerçevesi eğitimi ise gereksinim türleri, yazımı ve izlenebilirliği ayrı bir başlık olarak sunar. Doküman yazmak ya da gözden geçirmek zorunda olan iş analistleri ve ürün sorumluları için uygun bir zemindir.