Gereksinim Dokümantasyonu

Gereksinim Dokümantasyonu

1. Gereksinim Dokümanı Türleri ve Amacı

Gereksinimler, proje paydaşlarının ve geliştirme ekibinin ortak bir anlayışa sahip olmasını sağlamak için resmi olarak belgelendirilmelidir.

1.1. Neden Dokümantasyon Gereklidir?

Ortak Anlayış: Paydaşlar, geliştiriciler ve test uzmanları arasında tek, tutarlı bir bilgi kaynağı oluşturur.
İzlenebilirlik (Traceability): Her bir gereksinimin arkasındaki iş hedefini görmeyi sağlar.
Doğrulama ve Onay: Gereksinimlerin proje başında resmi olarak onaylanmasını ve test edilebilirliğini sağlar.
Kapsam Yönetimi: Projenin sınırlarını (scope) netleştirir ve kapsam kaymalarını (scope creep) önler.

1.2. Başlıca Gereksinim Dokümanı Türleri

Farklı detay seviyelerinde kullanılan üç ana doküman türü şunlardır:

Doküman Adı	Açılımı	Odak Noktası	Kimin İçin?	Ne Zaman Kullanılır?
BRD	Business Requirements Document (İş Gereksinimleri Belgesi)	Neden? (İş problemi ve hedefleri) ve Ne? (İşin ne istediği). Üst düzey kapsam.	Sponsor, PO, Üst Yönetim, Test Ekibi, Analist, Geliştiriciler	Genellikle proje yaşam döngüsünün erken aşamalarında kullanılır
FRD	Functional Requirements Document (Fonksiyonel Gereksinimler Belgesi)	Nasıl? (Sistemin hangi fonksiyonları, hangi iş kurallarıyla gerçekleştireceği). Detaylı.	İş Analisti, Paydaşlar	BRD onaylandıktan sonra. Geleneksel/Karma projelerde.
SRS	Software Requirements Specification (Yazılım Gereksinimleri Spesifikasyonu)	Nasıl/Teknik Detaylar? (Sistemin teknik mimarisi, veri modeli ve NFR’ler). Teknik odaklı.	Geliştirme Ekibi, Çözüm Mimarı	Geliştirme aşamasına yakın.

Not: Çevik (Agile) projelerde bu dokümanlar yerine çoğunlukla aynı bilgileri içeren daha kısa Kullanıcı Hikayeleri ve detaylı Kabul Kriterleri kullanılır ve bunlar Backlog‘da tutulur. Ancak temel mantık aynıdır.

2. BRD Örnek Şablonu İnceleme

İş Gereksinimleri Belgesi (BRD), bir projenin “neden” yapıldığını ve “ne” başarması gerektiğini tanımlayan resmi belgedir.

2.1. Standart BRD Şablonu Yapısı

Bölüm Adı	Amaç ve İçerik	BA Aksiyonu
1. Giriş/Özet	Projenin genel adını, yazarı (BA) ve revizyon geçmişini içerir.	Belgenin yönetimini sağlar.
2. İş Fırsatı/Problem Tanımı	Neden? Mevcut sorunun ne olduğunu veya ulaşılmak istenen iş fırsatını açıklar.	Paydaş görüşmelerinden gelen ana motivasyonu kaydeder.
3. Proje Amaçları ve Başarı Kriterleri	Ne? Projenin SMART hedeflerini (Örn: Hata oranını %15 azaltmak) ve bu hedeflere ulaşıldığında başarının nasıl ölçüleceğini tanımlar.	Sponsor ile birlikte net metrikleri belirler.
4. Kapsam (Scope)	Projenin sınırlarını netleştirir: Neler yapılacak (In-Scope) ve Neler yapılmayacak (Out-of-Scope).	Paydaşlardan gelen tüm fikirleri filtreler ve kapsamı dondurur.
5. İş Gereksinimleri (High-Level)	Çözümün yerine getirmesi gereken üst düzey gereksinimleri (Fonksiyonel olmayan dahil) listeler. Detay içermez.	Üst düzey istekleri kategorilere ayırır (Örn: “İzin süresi hesaplaması hatasız olmalıdır”).
6. Paydaşlar	Projeden etkilenen ana paydaşları ve rollerini listeler.	Paydaş Matrisi’nin özetini içerir.
7. Riskler ve Varsayımlar	Projenin başarılı olması için doğru kabul edilen varsayımları (Örn: Mevcut veri tabanı kullanılacak) ve riskleri içerir.	Risklerin ve sınırların yönetimini sağlar.