Yazılım Gereksinim Dokümanı Nasıl Yazılır? Örnekli Rehber

Yazılım gereksinim dokümanı, bir yazılımın ne yapması gerektiğini, hangi kurallara uyacağını ve ne zaman "tamamlandı" sayılacağını tanımlayan belgedir. İyi bir gereksinim dokümanı uzun ve resmî olmak zorunda değildir; kullanıcı hikâyeleri, net kabul kriterleri, iş kuralları ve fonksiyonel olmayan gereksinimlerden oluşan, herkesin aynı şekilde anladığı bir belge olması yeterlidir. Bu yazıda bir gereksinim dokümanının bölümlerini ve kullanabileceğin örnekleri paylaşıyoruz.

Brief ile gereksinim dokümanı arasındaki fark

Proje brief'i "neden ve ne" sorularına kısa cevaplar verir: problemi, kullanıcıları, hedefleri ve kısıtları anlatır. Gereksinim dokümanı ise "tam olarak nasıl davranmalı" sorusuna cevap verir. Brief genellikle teklif almadan önce, gereksinim dokümanı ise kapsam netleştikten sonra, çoğu zaman geliştirme ekibiyle birlikte hazırlanır.

Bu ayrım önemlidir: Gereksinim dokümanını tek başına, ekiple konuşmadan çok ayrıntılı yazmak, teknik olarak zor veya gereksiz kararları önceden sabitlemene yol açabilir. En iyi sonuç, iş bilgisinin senden, teknik değerlendirmenin ekipten geldiği ortak bir çalışmayla elde edilir.

Yazılım gereksinim dokümanının bölümleri

1. Amaç ve kapsam

Belgenin kapsadığı sürümü ve sınırlarını yaz. Kapsam dışında kalanları açıkça belirtmek de en az kapsam kadar önemlidir: "Bu sürümde ödeme alma yoktur; ödemeler fatura ile manuel takip edilecektir."

2. Kullanıcı rolleri

Sistemi kullanacak her rolü ve yetkilerini tanımla. Örneğin: Yönetici, Satış Temsilcisi, Bayi. Her rol için ne görebildiğini ve ne yapabildiğini kısa bir tabloyla göstermek, yetkilendirme hatalarını baştan önler.

3. Kullanıcı hikâyeleri

Fonksiyonel gereksinimleri yazmanın en anlaşılır yolu kullanıcı hikâyeleridir. Kalıp şöyledir:

[Rol] olarak, [amaç] için [eylem] yapabilmek istiyorum.

Örnek:

Bayi olarak, stok durumunu bilmek için ürün listesinde her ürünün güncel stok bilgisini görebilmek istiyorum.

Bu kalıp, özelliğin kimin için ve neden yapıldığını da aktarır. Ekip, amacı bildiğinde daha iyi çözümler önerebilir.

4. Kabul kriterleri

Her kullanıcı hikâyesinin, tamamlandığını gösteren somut koşulları olmalıdır. Yaygın bir kalıp "Diyelim ki / Eğer / O zaman" yapısıdır:

• Diyelim ki bayi sisteme giriş yapmış durumda,
• Eğer ürün listesini açarsa,
• O zaman her ürünün yanında güncel stok adedi görünmelidir,
• Ve stok sıfırsa ürün "stokta yok" etiketiyle gösterilmeli ve sepete eklenememelidir.

Kabul kriterleri hem geliştiricinin neyi yapacağını hem de senin neyi test edeceğini netleştirir. "Kullanıcı dostu olmalı" gibi ölçülemeyen ifadeler yerine, doğrulanabilir koşullar yaz.

5. İş kuralları

Birden fazla hikâyeyi etkileyen kuralları ayrı bir bölümde topla. Örnekler:

• Bir sipariş, onaylandıktan sonra yalnızca yönetici tarafından iptal edilebilir.
• Bayi başına aylık kredi limiti aşıldığında yeni sipariş onaya düşer.
• Fiyatlar KDV hariç gösterilir, sepette KDV ayrıca hesaplanır.

İş kurallarını ayrı tutmak, aynı kuralın farklı yerlerde farklı yazılmasını önler.

6. Veri ve entegrasyonlar

Sistemin hangi verileri tutacağını (örneğin müşteri, ürün, sipariş) ve bu verilerin hangi dış sistemlerden gelip hangilerine gideceğini yaz. Entegrasyonlar için veri akışının yönünü, sıklığını ve hata durumunda ne olacağını belirt.

7. Fonksiyonel olmayan gereksinimler

Sistemin ne yaptığından çok, nasıl çalıştığıyla ilgili beklentilerdir:

• Performans: Sık kullanılan ekranların kabul edilebilir sürede açılması.
• Güvenlik: Parola politikası, iki adımlı doğrulama, oturum süresi.
• Erişilebilirlik: Klavye ile kullanım, yeterli renk kontrastı.
• Tarayıcı ve cihaz desteği: Hangi tarayıcılar ve ekran boyutları desteklenecek.
• Dil: Arayüz yalnızca Türkçe mi, yoksa birden fazla dil mi?
• Veri saklama ve KVKK: Saklama süreleri, silme ve dışa aktarma ihtiyaçları.
• Yedekleme: Yedekleme sıklığı ve geri yükleme beklentisi.

Bu bölüm sıklıkla unutulur ve yayına yakın dönemde sürprizlere yol açar.

8. Ekran taslakları

Tel kafes çizimler veya basit ekran taslakları, uzun açıklamalardan daha hızlı anlaşılır. Taslakları ilgili kullanıcı hikâyelerine bağla.

9. Açık sorular

Henüz karar verilmemiş konuları bir liste hâlinde tut ve her birine bir sorumlu ata. Açık soruları gizlemek yerine görünür kılmak, ileride yanlış varsayımlarla ilerlemeyi önler.

Kopyalanabilir gereksinim şablonu

Her özellik için aşağıdaki yapıyı kullanabilirsin:

• Özellik adı:
• Kullanıcı hikâyesi: [Rol] olarak, [amaç] için [eylem] yapabilmek istiyorum.
• Öncelik: Olmazsa olmaz / Olmalı / Olabilir
• Kabul kriterleri: Diyelim ki... Eğer... O zaman...
• İlgili iş kuralları:
• İlgili ekran taslağı:
• Açık sorular:

Örnek: Doldurulmuş bir gereksinim kaydı

Şablonun pratikte nasıl görünebileceğine dair bir bayi portalı örneği:

• Özellik adı: Sipariş oluşturma
• Kullanıcı hikâyesi: Bayi olarak, telefonla aramak zorunda kalmadan sipariş verebilmek için ürünleri sepete ekleyip siparişi gönderebilmek istiyorum.
• Öncelik: Olmazsa olmaz
• Kabul kriterleri:
  • Diyelim ki bayi giriş yapmış ve sepetinde en az bir ürün var; eğer "Siparişi gönder" düğmesine basarsa, o zaman sipariş "Onay bekliyor" durumunda oluşturulmalı ve bayiye sipariş numarası gösterilmelidir.
  • Diyelim ki sepetteki bir ürünün stoku sipariş sırasında tükendi; eğer bayi siparişi göndermeye çalışırsa, o zaman hangi ürünün stokta olmadığı gösterilmeli ve sipariş oluşturulmamalıdır.
  • Diyelim ki sipariş oluşturuldu; o zaman satış ekibine bildirim e-postası gitmelidir.
• İlgili iş kuralları: Aylık kredi limiti kuralı, KDV gösterim kuralı.
• İlgili ekran taslağı: Sepet ekranı ve sipariş onay ekranı.
• Açık sorular: Bayi, onay bekleyen siparişini kendisi iptal edebilecek mi? Sorumlu: satış müdürü.

Bu kadar kısa bir kayıt bile; geliştiricinin ne yapacağını, test eden kişinin neyi kontrol edeceğini ve hangi kararın hâlâ beklendiğini netleştirir.

Gereksinim yazarken sık yapılan hatalar

• Çözümü tarif etmek: "Açılır menü olsun" yerine "kullanıcı beş seçenekten birini seçebilmeli" demek, ekibe daha iyi bir arayüz önerme alanı bırakır.
• İstisnaları atlamak: "Kullanıcı sipariş verir" cümlesi; stok yoksa, ödeme başarısız olursa, kullanıcı yarıda bırakırsa ne olacağını söylemez.
• Belgeyi dondurmak: Gereksinimler proje boyunca netleşir. Değişiklikleri sürüm notlarıyla belgeye işlemek, belgenin güncel kalmasını sağlar.
• Herkesin onayını almamak: Belgeyi sahada sistemi kullanacak kişilere de okut; günlük işleyişi en iyi onlar bilir.

Belgeyi nerede ve nasıl tutmalı?

Gereksinim dokümanı, herkesin erişebildiği ve güncel sürümün tek olduğu bir yerde tutulmalıdır. E-postayla gidip gelen dosya sürümleri, hangi kararın geçerli olduğu konusunda karışıklık yaratır. Paylaşılan bir doküman, bir proje yönetim aracı veya kod deposundaki bir belge klasörü kullanılabilir. Önemli olan, değişikliklerin kim tarafından ve ne zaman yapıldığının görülebilmesi ve onaylanan kapsamın açıkça işaretlenmesidir.

Sonuç

İyi bir yazılım gereksinim dokümanı, geliştirme ekibine ne yapacağını, sana ise neyi test edeceğini söyler. Kullanıcı hikâyeleri, net kabul kriterleri, ayrı tutulan iş kuralları ve unutulmayan fonksiyonel olmayan gereksinimler, projedeki yanlış anlaşılmaların büyük kısmını önler. Weras Labs'te yazılı teklif aşamasında kapsamı bu yapıya yakın şekilde netleştiriyor ve geliştirme boyunca kabul kriterlerini önizleme bağlantıları üzerinden birlikte doğruluyoruz; ayrıntılar hizmetler sayfamızda.