BRD mi FRD mi? İki Gereksinim Dokümanını Ayıran Çizgi

BRD ve FRD aynı zincirin iki halkası

BRD (Business Requirements Document, iş gereksinim dokümanı) ve FRD (Functional Requirements Document, fonksiyonel gereksinim dokümanı) bir projede gereksinimin iki farklı düzeyini kayda geçirir. BRD işin neden ve ne için bir değişikliğe ihtiyaç duyduğunu anlatır. FRD ise bu ihtiyacı karşılamak için sistemin ya da çözümün ne yapması gerektiğini tarif eder.

İki doküman da aynı amaca hizmet eder: Paydaşlar ile çözümü inşa edecek ekip arasında yanlış anlamayı azaltmak. Ortak noktaları şunlardır: ikisi de onaylanır, sürümlenir, değişiklikleri izlenir ve test ekibi için başvuru kaynağı olur. Bu adlar resmî bir standardın değil, sektörde yerleşmiş uygulamanın ürünüdür; bu yüzden kurumdan kuruma şablon ve kapsam değişebilir.

BRD neyi anlatır?

BRD, iş tarafının dilinde yazılır. Sorduğu sorular şunlardır: Hangi problem çözülüyor, hangi fırsat yakalanmak isteniyor, başarı nasıl ölçülecek, kapsamda ne var ve ne yok, kimler etkileniyor?

Tipik bir BRD şu bölümleri içerir: • Proje arka planı ve iş problemi • İş hedefleri ve başarı ölçütleri • Kapsam ve kapsam dışı konular • Paydaş listesi ve etkilenen birimler • Üst düzey iş gereksinimleri • Varsayımlar, kısıtlar ve bağımlılıklar

Örnek bir iş gereksinimi: “Müşteri hizmetleri ekibi, iade taleplerini tek ekrandan takip edebilmeli ve talebin hangi aşamada olduğunu müşteriye anında söyleyebilmelidir.” Burada ekran tasarımı, alan adları ya da sistem davranışı yoktur; yalnızca işin ihtiyacı vardır.

FRD neyi anlatır?

FRD, BRD'deki ihtiyacı sistemin davranışına çevirir. Hedef okuru tasarımcılar, yazılım geliştiriciler ve test uzmanlarıdır. Her gereksinim test edilebilir, tek anlamlı ve izlenebilir olmalıdır.

Tipik bir FRD şu bölümleri içerir: • Fonksiyonel gereksinimler (sistem ne yapacak) • Kullanıcı rolleri ve yetkiler • Ekran akışları, iş kuralları ve doğrulama kuralları • Veri alanları ve entegrasyonlar • Hata durumları ve istisnalar • Gerekirse fonksiyonel olmayan gereksinimlere atıf (performans, güvenlik)

Aynı örneğin FRD karşılığı şöyle olabilir: “Sistem, müşteri hizmetleri rolündeki kullanıcıya iade talebi listesini talep numarası, müşteri adı, oluşturma tarihi ve durum alanlarıyla göstermelidir. Durum alanı yalnızca tanımlı değerlerden birini alabilir.” Bu cümle test edilebilir ve geliştiriciye neyi inşa edeceğini söyler.

Ölçüt ölçüt BRD ve FRD

Temel soru: BRD / iş neye ihtiyaç duyuyor ve neden? FRD / sistem bu ihtiyacı karşılamak için ne yapacak?

Hedef okur: BRD / sponsor, iş birimi yöneticileri, karar vericiler. FRD / tasarım, yazılım ve test ekipleri.

Dil: BRD / iş dili, teknik ayrıntıdan arınmış. FRD / kesin, test edilebilir, kural ve davranış odaklı.

Ayrıntı düzeyi: BRD / üst düzey, kapsam ve hedef. FRD / alan, kural, akış ve istisna düzeyinde.

Yazım zamanı: BRD / proje başlangıcında, iş gerekçesi netleşirken. FRD / BRD onaylandıktan sonra, çözüm tasarımı başlarken.

Onaylayan: BRD / iş sponsoru. FRD / iş birimi ile teknik ekip birlikte.

Başarı ölçüsü: BRD / doğru problemin çözülmesi. FRD / çözümün doğru inşa edilmesi.

İki doküman nasıl birbirine bağlanır?

İyi bir projede FRD'deki her fonksiyonel gereksinim, BRD'deki bir iş gereksinimine geri bağlanır. Bu bağ izlenebilirlik matrisiyle tutulur. Böylece bir iş hedefi değiştiğinde hangi fonksiyonların etkilendiği görülür; tersinden bakıldığında hiçbir iş ihtiyacına bağlanmayan bir fonksiyonun gereksiz kapsam genişlemesi olup olmadığı sorgulanabilir.

Örneğin iade talebi örneğinde “talebin aşamasını müşteriye anında söylemek” iş gereksinimi, FRD'de birden fazla fonksiyona açılır: durum alanının tanımlı değerleri, durum değiştiğinde müşteriye bildirim gönderilmesi ve temsilcinin yetkisine göre hangi durum geçişlerini yapabileceği. İzlenebilirlik matrisinde bu fonksiyonların her biri aynı iş gereksinimine bağlanır. Test ekibi de kabul testlerini bu bağdan çıkarır: iş gereksinimi karşılandı mı, sorusu fonksiyonların testlerinin toplamıyla yanıtlanır.

İki dokümanın gözden geçirilmesi de farklı yapılır. BRD'yi sponsor ve iş birimi yöneticileri “doğru problemi mi çözüyoruz, kapsam kabul edilebilir mi” diye okur. FRD'yi ise tasarım, yazılım ve test ekipleri “belirsiz ya da çelişkili gereksinim var mı, her biri test edilebilir mi” diye inceler. Gözden geçirmede çıkan belirsizlikler doküman onaylanmadan önce kapatılmalıdır; çünkü yazılım başladıktan sonra bulunan gereksinim hatası daha pahalıya düşer.

Sık yapılan hatalar şunlardır: • BRD'ye ekran ve alan ayrıntısı yazmak, iş sponsorunu teknik ayrıntıda boğmak • FRD'yi BRD olmadan yazmak, yani neden sorusunu atlayıp doğrudan çözüme geçmek • “Kullanıcı dostu olmalı”, “hızlı çalışmalı” gibi ölçülemeyen ifadeler kullanmak • Değişiklikleri BRD'de güncelleyip FRD'yi eski bırakmak

Çevik projelerde BRD ve FRD hâlâ gerekir mi?

Çevik ekipler genellikle kalın bir FRD yerine ürün backlog'u, kullanıcı hikayeleri ve kabul kriterleriyle çalışır. Bu durumda FRD'nin işlevi parçalara bölünür: Her kullanıcı hikayesi ve kabul kriterleri küçük bir fonksiyonel gereksinim gibi davranır.

BRD'nin karşılığı ise kaybolmaz; ürün vizyonu, iş gerekçesi, hedef ölçütler ve kapsam yine bir yerde yazılı olmalıdır. Düzenlemeye tabi sektörlerde (bankacılık, sağlık, kamu) ya da dış tedarikçiyle sözleşmeli projelerde, çevik çalışılsa bile resmî bir gereksinim dokümanı sözleşme ve denetim gereği talep edilebilir. Seçim, ekibin çalışma biçimine ve dokümanın kim tarafından, ne amaçla okunacağına göre yapılmalıdır.

Mindset programlarında gereksinim dokümantasyonu

Gereksinim Analistliği Sertifika Programı; bilgi toplama teknikleri, gereksinim yazımı ve dokümantasyon kalitesi, doğrulama ve onaylama, izlenebilirlik ve değişiklik yönetimi ile çevik gereksinimler (kullanıcı hikayeleri ve backlog) modülleriyle BRD ve FRD yazımının arkasındaki becerileri ele alır.

İş Analizi Uzmanlığı Sertifika Programı ise gereksinim ortaya çıkarma, gereksinim yaşam çemberi yönetimi ve gereksinim analizi ve tasarım tanımı modülleriyle aynı konuyu BABOK çerçevesinden işler.