Web Yazılım İhtiyaç Dokümanı Nasıl Hazırlanır? Gereksinim Şablonu

Web yazılım ihtiyaç dokümanı; projenin iş amacını, kullanıcılarını, süreçlerini, iş kurallarını, verisini, entegrasyonlarını, teknik kalite beklentilerini ve kabul koşullarını ortak bir referansta toplar. İyi bir doküman yalnızca “üyelik, raporlama ve yönetim paneli yapılacak” demez. Her gereksinimin kim için, hangi durumda, hangi sonucu üretmesi gerektiğini ve nasıl doğrulanacağını açıklar.

Dokümanın amacı bütün teknik kararları müşteri tarafından önceden vermek değildir. İşletmenin bildiği ihtiyaçları görünür hâle getirmek, belirsizlikleri işaretlemek ve ürün, tasarım, yazılım, test ve operasyon ekiplerinin aynı problem üzerinde çalışmasını sağlamaktır.

Bu rehber üç katmanlı bir model kullanır:

1. Proje özeti: İş hedefi, kullanıcılar, kapsam sınırları, varsayımlar ve öncelikler.
2. Gereksinim kartları: Her işlev, iş kuralı, veri veya teknik kalite ihtiyacı için test edilebilir kayıt.
3. İzlenebilirlik matrisi: Hedef, gereksinim, tasarım/geliştirme işi, test ve onay arasındaki bağlantı.

Bu yapı küçük projelerde tek bir çalışma dosyasında tutulabilir. Daha karmaşık uygulamalarda iş analizi, arayüz, API, veri, güvenlik ve test belgelerine ayrılabilir; ancak kayıtlar arasındaki ilişki korunmalıdır.

Web sitesi briefi ile web yazılım gereksinim dokümanı arasındaki fark

Kurumsal web sitesi ihtiyaç dokümanı çoğunlukla hedef kitle, sayfalar, içerikler, görsel yön, formlar, diller ve proje sorumluluklarına odaklanır. Üyelik, farklı kullanıcı rolleri, özel hesaplamalar, onay akışları, yoğun veri veya sistemler arası bağlantı bulunan bir web uygulamasında bu çerçeve tek başına yeterli olmayabilir.

Web yazılım gereksinim dokümanı ayrıca şunları tanımlar:

• kullanıcı rolleri ve yetki sınırları,
• başlangıçtan sonuca kadar iş akışları,
• hesaplama, limit, onay ve durum kuralları,
• veri alanları, kaynakları, sahipliği ve yaşam döngüsü,
• API ve üçüncü taraf servis davranışları,
• hata, istisna ve geri dönüş senaryoları,
• güvenlik, erişilebilirlik, performans ve süreklilik gereksinimleri,
• kabul kriterleri ve doğrulama yöntemi,
• sürüm kapsamı ve değişiklik kaydı.

Bir kurumsal tanıtım sitesi planlıyorsanız mevcut web sitesi ihtiyaç dokümanı rehberi daha doğru başlangıçtır. Uygulama işletmenin operasyonunu yürütüyor, kullanıcıya özel veri gösteriyor veya başka sistemlerle işlem yapıyorsa bu makaledeki ayrıntılı model kullanılmalıdır.

Dokümanı kim hazırlamalı?

Gereksinimler yalnızca yazılım ekibinin veya yalnızca yöneticinin görevi değildir. Bilginin kaynağına göre farklı kişiler katkı verir:

• Proje/ürün sahibi: İş hedefi, öncelik, bütçe sınırı ve nihai karar.
• Süreç sahibi: Mevcut iş akışı, istisnalar ve operasyon kuralları.
• Gerçek kullanıcılar: Günlük görevler, sorunlar ve kullanım bağlamı.
• İş analisti veya proje yöneticisi: Bilgiyi tutarlı, öncelikli ve doğrulanabilir gereksinimlere dönüştürme.
• Tasarım ekibi: Kullanıcı yolculuğu, etkileşim, içerik ve erişilebilirlik etkileri.
• Yazılım/teknik ekip: Uygulanabilirlik, mimari, veri, entegrasyon, güvenlik ve işletim bağımlılıkları.
• Test ve kabul sahipleri: Kabul kriterleri, test verisi ve onay kanıtı.
• Hukuk, bilgi güvenliği veya uyum sorumluları: Projenin koşullarına göre uzman incelemesi.

Tek bir kişi belge sahibi olmalıdır. Bu kişi bütün kararları tek başına vermek yerine çelişkili yorumları toplar, açık soruların sahibini belirler ve onaylı sürümü korur.

1. İş hedefini ve başarı sonucunu yazın

Dokümana ekran listesinden başlamayın. Önce projenin neden yapılacağını ve hangi iş sonucunun değişmesi beklendiğini tanımlayın.

Zayıf ifade:

Modern bir bayi portalı yapılacak.

Daha yararlı ifade:

Yetkili bayiler, kendilerine tanımlı ürün ve fiyatlarla sipariş talebi oluşturabilmeli; merkez ekip talepleri tek sistemde inceleyip durumunu yönetebilmelidir. İlk sürüm, e-posta ve tablo üzerinden yürütülen talep toplama sürecinin tanımlı bayi grubunda uçtan uca çalışmasını doğrulamalıdır.

Başarı sonucu doğrudan gelir artışı gibi kanıtlanması zor bir vaat olmak zorunda değildir. İlk sürüm için tamamlanan temel işlem, veri doğruluğu, manuel müdahale ihtiyacı, işlem süresi, kritik hata veya kullanıcı geri bildirimi gibi ölçülebilir göstergeler seçilebilir.

Proje özeti alanları

2. Kapsam sınırlarını ve varsayımları kaydedin

Bir gereksinim dokümanı yalnızca yapılacakları değil yapılmayacakları da göstermelidir. “Raporlama dahil” ifadesi sınırsız rapor geliştirme beklentisi yaratabilir. Hangi raporların, hangi alanlarla, hangi kullanıcı için ve hangi dışa aktarma seçenekleriyle ilk sürümde bulunduğunu yazın.

Kapsamı dört listeyle ayırın:

• ilk sürüme dahil,
• sonraki sürüm adayı,
• araştırma veya doğrulama bekliyor,
• açıkça kapsam dışı.

Varsayımları gereksinim gibi sunmayın. Örneğin “ERP gerçek zamanlı stok servisi sağlayacaktır” doğrulanmadıysa bunu entegrasyon gereksiniminin altına kesin bilgi olarak yazmak yerine sahibi ve doğrulama tarihi bulunan bir varsayım/bağımlılık kaydı oluşturun.

3. Kullanıcı rollerini ve yetkileri tanımlayın

“Kullanıcı” tek bir rol değildir. Müşteri, bayi çalışanı, bayi yöneticisi, operasyon personeli, finans sorumlusu ve sistem yöneticisi aynı veriyi ve işlemleri görmemelidir.

Her rol için şu soruları yanıtlayın:

• Sisteme nasıl davet edilir veya kayıt olur?
• Kimliğini nasıl doğrular?
• Hangi kuruluş, hesap veya kayıtlarla ilişkilidir?
• Hangi veriyi görüntüleyebilir?
• Hangi işlemi başlatabilir, onaylayabilir, değiştirebilir veya iptal edebilir?
• Yetkisi kim tarafından ve nasıl kaldırılır?
• Kritik işlem kaydı gerekli midir?
• Başka bir kullanıcı adına işlem yapabilir mi?

Basit rol-yetki matrisi

Bu tablo örnektir; gerçek yetkiler proje riskine göre tanımlanmalıdır. “Yönetici her şeyi yapabilir” yaklaşımı veri ve operasyon riskini artırabileceği için ayrı idari yetkiler tercih edilebilir.

4. Kullanıcı akışlarını uçtan uca yazın

Kullanıcı hikâyeleri, rolü, ihtiyacı ve amacı kısa biçimde ifade etmek için yararlıdır. GOV.UK Service Manual, kullanıcı hikâyesinde aktör, ihtiyaç ve hedefin bulunmasını; kabul kriterlerinin de hizmetin kullanıcı ihtiyacını karşılayıp karşılamadığını doğrulayan sonuçlar olarak yazılmasını önerir (Writing user stories).

Örnek kullanıcı hikâyesi:

Bayi sipariş yetkilisi olarak, kendi bayime tanımlı ürün ve fiyatları görmek istiyorum; böylece geçersiz ürün veya fiyatla talep oluşturmam.

Tek bir hikâye bütün akışı açıklamaz. Akış diyagramı veya numaralı senaryo ile şu aşamaları ekleyin:

1. başlangıç koşulu,
2. kullanıcının girdisi,
3. sistem kontrolü,
4. iş kuralı veya entegrasyon,
5. başarılı sonuç,
6. kullanıcıya gösterilen bilgi,
7. kaydedilen veri,
8. hata ve geri dönüş davranışı.

Mutlu yolun yanında yetkisiz erişim, eksik veri, yinelenen işlem, zaman aşımı ve üçüncü taraf servis hatası gibi etkili istisnaları belirleyin.

5. İşlevsel gereksinimleri gereksinim kartlarıyla yazın

İşlevsel gereksinim sistemin ne yapacağını tanımlar. Her gereksinime benzersiz kimlik vermek, toplantı notu, tasarım, geliştirme görevi ve test kaydı arasında aynı maddeden söz edilmesini kolaylaştırır.

Gereksinim kartı şablonu

Bir gereksinim aynı cümlede birden fazla bağımsız davranışı toplamamalıdır. “Sistem siparişi kaydeder, ERP’ye gönderir, e-posta yollar ve rapora ekler” ifadesini doğrulanabilir alt gereksinimlere ayırın.

6. İş kurallarını arayüzden ayrı kaydedin

İş kuralı, işletmenin karar veya hesaplama mantığıdır. Arayüz değişse bile aynı kural devam edebilir.

Örnekler:

• 50.000 TL üzerindeki talepler ikinci onay gerektirir.
• İptal yalnızca “İncelemede” durumundaki taleplerde yapılabilir.
• Özel müşteri fiyatı varsa genel fiyat listesinden önce uygulanır.
• Bir kullanıcı yalnızca bağlı olduğu kuruluşun kayıtlarını görebilir.

Her kural için kaynak, istisna, karar sahibi ve örnek veri sağlayın. “İndirim otomatik hesaplanır” gibi ifadeler oran, öncelik, yuvarlama, vergi ve para birimi davranışını açıklamıyorsa geliştirme ve kabul sırasında farklı yorumlanabilir.

Karar tablosu, çok sayıda koşulun farklı sonuç ürettiği durumlarda yararlıdır:

Gerçek karar tablosu finans ve süreç sahiplerince onaylanmalıdır; bu örnek bir fiyat politikası iddiası değildir.

7. Veri gereksinimlerini tanımlayın

Veri modeli yalnızca geliştiricinin teknik tercihi değildir. İşletme; hangi bilginin gerekli, doğru, hassas, saklanabilir ve raporlanabilir olduğunu açıklamalıdır.

Her temel veri varlığı için kaydedin:

• alan adı ve iş anlamı,
• veri tipi/format beklentisi,
• zorunlu veya isteğe bağlı oluşu,
• kaynağı ve sahibi,
• doğrulama kuralı,
• kimlerin görebileceği ve değiştirebileceği,
• saklama veya silme ihtiyacı,
• geçmiş değişikliklerin tutulup tutulmayacağı,
• dışa aktarım ve taşıma gereksinimi,
• kişisel veya hassas veri sınıfı.

Örnek veri sözlüğü satırı:

Saklama süresi ve hukuki yükümlülükler proje bağlamına göre yetkili uzmanlarca belirlenmelidir; örnek bir şablon hukuki kararın yerine geçmez.

8. Entegrasyon gereksinimlerini davranışla açıklayın

“ERP entegrasyonu yapılacak” kapsam belirlemek için yetersizdir. Hangi işlemde, hangi verinin, hangi yönde ve hangi hata davranışıyla aktığı belirtilmelidir.

Entegrasyon kaydında şunlar bulunmalıdır:

• gönderen ve alan sistem,
• işlem ve tetikleyici,
• veri alanları ve eşleştirme,
• veri yönü,
• gerçek zamanlı veya zamanlanmış çalışma,
• kimlik doğrulama ve yetki sahipliği,
• hız veya kullanım sınırı,
• zaman aşımı ve yeniden deneme,
• yinelenen işlem önleme,
• hata kaydı ve bildirim,
• test ortamı ve örnek veri,
• servis değişikliği ve sürüm sorumluluğu.

API belgesinin varlığı entegrasyonun hazır olduğunu kanıtlamaz. Erişim, yetki, örnek yanıtlar, hata kodları, veri kalitesi ve test ortamı uygulama öncesinde doğrulanmalıdır.

9. İşlevsel olmayan gereksinimleri ölçülebilir yazın

İşlevsel olmayan gereksinimler sistemin hangi kalite koşullarında çalışacağını tanımlar. “Hızlı, güvenli, kullanıcı dostu ve ölçeklenebilir” ifadeleri yön gösterir; ancak ölçülemediği için kabul koşulu oluşturmaz.

Performans ve kapasite

Şunları belirtin:

• beklenen eşzamanlı ve toplam kullanıcı,
• işlem ve veri hacmi,
• ölçülecek kritik sayfa/API,
• hedef yanıt veya tamamlama süresi,
• test ortamı ve veri büyüklüğü,
• ani yük senaryosu,
• kabul edilebilir hata davranışı.

Kesin değerleri internetten kopyalamayın. Kullanıcı ihtiyacı, altyapı, işlem türü ve bütçeye göre proje özelinde belirleyin.

Güvenlik ve gizlilik

Güvenlik gereksinimlerini uygulamanın veri, rol ve işlem riskine göre oluşturun. NIST SSDF, güvenlik gereksinimlerinin belirlenmesini, operasyon sırasında karşılaşılabilecek risklerin değerlendirilmesini ve tasarımın bu riskleri nasıl azaltacağının açıklanmasını önerir (NIST SSDF SP 800-218).

Gereksinim alanları şunları içerebilir:

• kimlik doğrulama ve oturum,
• rol ve kayıt düzeyinde yetkilendirme,
• kritik işlem doğrulaması,
• veri aktarımı ve saklama koruması,
• dosya yükleme sınırları,
• güvenlik kayıtları ve olay bildirimi,
• bağımlılık/güncelleme yönetimi,
• yedek ve geri yükleme,
• erişim verme ve kaldırma,
• güvenlik doğrulama kapsamı.

OWASP ASVS, web uygulaması güvenlik kontrollerini test edilebilir gereksinimlere dönüştürmek için kullanılabilir; ancak uygulanacak bölüm ve doğrulama düzeyi risk ve sözleşme kapsamında kararlaştırılmalıdır (OWASP ASVS).

Erişilebilirlik

Erişilebilirlik hedefini tasarım tamamlandıktan sonra eklemeyin. W3C WAI, erişilebilirlik için hedef, sorumluluk, kaynak ve izleme yaklaşımının planlama sürecine dahil edilmesini önerir (Planning and Managing Web Accessibility).

Dokümanda hedef standart/uygunluk düzeyi, kapsanan kullanıcı akışları, klavye davranışı, odak, form etiketleri ve hataları, kontrast, alternatif metin, dinamik içerik ve doğrulama yöntemi tanımlanabilir. Hukuki gereklilikler ülke ve hizmete göre ayrıca değerlendirilmelidir.

Süreklilik, bakım ve gözlemlenebilirlik

• çalışma zamanı ve planlı bakım beklentisi,
• hata ve performans kayıtları,
• kritik uyarıların sahibi,
• yedek sıklığı ve saklama sorumluluğu,
• geri yükleme hedefi ve test yöntemi,
• üçüncü taraf hizmet kesintisi davranışı,
• bakım, hata düzeltme ve yeni geliştirme ayrımı,
• kaynak kod, veri, hesap ve dokümantasyon teslimi.

Bu başlıkların ayrıntısı sistemin önemine göre değişir. Küçük bir iç araçla kesintinin satış veya hizmet sunumunu durdurduğu kritik uygulama aynı gereksinim seviyesine sahip değildir.

10. Kabul kriterlerini ve doğrulama yöntemini ekleyin

Her kritik gereksinim için “bitti” denmesini sağlayacak gözlemlenebilir koşullar yazın. NASA Systems Engineering Handbook, iyi gereksinimlerin açık, doğru, eksiksiz, uygulanabilir ve doğrulanabilir olmasını; gereksinimlerin paydaş beklentileriyle izlenebilmesini vurgular (NASA Systems Engineering Handbook). Bu rehber web yazılım projeleri için zorunlu bir standart değildir; gereksinim kalitesini kontrol etmek için yararlı bir ilkedir.

Örnek kabul kriterleri:

• aktif ve yetkili bayi kullanıcısı yalnızca bağlı olduğu bayinin ürünlerini görür,
• farklı bayiye ait doğrudan kayıt isteği yetkisiz sonuç verir ve veri göstermez,
• fiyat kaynağı yanıt vermezse kullanıcıya işlem tamamlandı mesajı gösterilmez,
• başarılı talebe benzersiz numara atanır ve durum geçmişi başlatılır,
• operasyon rolü kaynağı ve oluşturulma zamanını görebilir,
• olay, tanımlı test kaydında kullanıcı ve zaman bilgisiyle doğrulanabilir.

Doğrulama yöntemi gereksinime göre inceleme, fonksiyon testi, kullanıcı kabul testi, otomatik test, performans ölçümü, güvenlik değerlendirmesi veya belge kontrolü olabilir. Tek bir ekran görüntüsü bütün davranışı kanıtlamaz.

11. İzlenebilirlik matrisi oluşturun

İzlenebilirlik, bir gereksinimin neden var olduğunu ve nasıl doğrulandığını gösterir. Her küçük projede ağır bir araç gerekmez; basit bir tablo yeterli olabilir.

Matris şu soruları yanıtlamalıdır:

• Sahibi veya iş hedefi olmayan gereksinim var mı?
• Gereksinimi karşılayan tasarım ve geliştirme işi var mı?
• Her kritik gereksinimin testi var mı?
• Test sonucu ve kabul kararı kaydedildi mi?
• Bir hedef değiştiğinde etkilenecek işler görülebiliyor mu?

NASA’nın gereksinim yazma kontrolü de gereksinimlerin üst seviye ihtiyaçlarla çift yönlü izlenebilirliğini önerir (How to Write a Good Requirement).

12. Değişiklikleri sürüm ve karar kaydıyla yönetin

Gereksinim dokümanı bir kez yazılıp unutulacak dosya değildir. Ancak herkesin haberi olmadan değişen ortak belge de güvenilir referans olamaz.

Her onaylı sürümde şu bilgiler bulunmalıdır:

• sürüm numarası ve tarih,
• değişen gereksinimler,
• değişiklik nedeni,
• kapsam, tasarım, veri, entegrasyon, güvenlik, test, bütçe ve takvim etkisi,
• kararı veren kişi,
• açık sorular ve hedef tarihleri.

Yeni talebi önce problem ve kullanıcı sonucu açısından değerlendirin. Mevcut kapsamı genişletiyorsa hangi kalemin çıkarılacağı, bütçenin veya tarihin nasıl değişeceği açıkça kararlaştırılmalıdır.

Kopyalanabilir web yazılım gereksinim dokümanı şablonu

Aşağıdaki başlıklar tek bir belge, çalışma tablosu veya proje yönetim sistemi içinde kullanılabilir:

1. Belge sahibi, sürüm, tarih ve onaylayanlar
2. Şirket/süreç özeti
3. Problem ve iş hedefi
4. Hedef kullanıcılar ve roller
5. Temel kullanıcı sonuçları
6. Başarı göstergeleri
7. İlk sürüm kapsamı
8. Sonraki sürüm ve kapsam dışı maddeler
9. Varsayımlar, bağımlılıklar ve açık sorular
10. Kullanıcı akışları ve istisnalar
11. İşlevsel gereksinimler
12. İş kuralları ve karar tabloları
13. Veri sözlüğü ve veri yaşam döngüsü
14. Entegrasyon ve API gereksinimleri
15. Güvenlik ve gizlilik gereksinimleri
16. Erişilebilirlik gereksinimleri
17. Performans ve kapasite gereksinimleri
18. Yedekleme, izleme ve işletim
19. Test verisi ve ortam sorumlulukları
20. Kabul kriterleri ve doğrulama yöntemleri
21. Teslim, hesap, kod, veri ve dokümantasyon
22. Bakım, destek ve değişiklik yönetimi
23. İzlenebilirlik matrisi
24. Karar ve revizyon günlüğü

Sık yapılan hatalar

Çözümü ihtiyaç gibi yazmak

“React ile geliştirilecek” veya “şu ürün kullanılacak” bir teknoloji kararıdır. Gerçek ihtiyaç; desteklenen kullanıcı senaryosu, entegrasyon, performans, bakım veya ekip kısıtı olabilir. Teknoloji zorunluysa gerekçesi ve sorumluluğu yazılmalıdır.

Belirsiz sıfat kullanmak

“Hızlı”, “güvenli”, “kolay” ve “modern” hedefi gösterir fakat testi tanımlamaz. Kullanıcı akışı, koşul, ölçüm yöntemi ve kabul sınırı ekleyin.

Yalnızca mutlu yolu anlatmak

Eksik veri, yetkisiz erişim, servis kesintisi, tekrarlı işlem ve kullanıcı vazgeçmesi ele alınmazsa gerçek kullanımda önemli boşluklar oluşur.

Her isteği aynı öncelikte tutmak

MVP çekirdeği, yayın kapısı, sonraki sürüm ve araştırma maddelerini ayırın. “Önemli” etiketi bütün işlerde kullanılırsa karar verilemez.

Sorumluluğu belirsiz bırakmak

İçeriği, test verisini, entegrasyon erişimini, hukuki metni, kabulü veya canlı desteği kimin sağlayacağı yazılmadığında teknik iş beklemeye girebilir.

Dokümanı kullanıcıyla doğrulamamak

Yönetici beklentisi gerçek günlük iş akışından farklı olabilir. Temel senaryoları süreci uygulayan kişilerle gözden geçirin ve anlaşılmayan terimleri proje sözlüğüne ekleyin.

Doküman ne kadar ayrıntılı olmalı?

Belge uzunluğu proje kalitesini göstermez. Ayrıntı; risk, rol sayısı, iş kuralı, entegrasyon, veri hassasiyeti ve kabul ihtiyacıyla orantılı olmalıdır.

Doküman şu sorulara yanıt veriyorsa geliştirme planlaması için yeterli bir temel oluşturabilir:

• Hangi kullanıcı hangi sonucu tamamlayacak?
• Sistem hangi kurallara göre davranacak?
• Hangi veri nereden gelecek ve kim tarafından kullanılacak?
• Hangi dış sistemlerle nasıl etkileşilecek?
• Hangi kalite ve risk koşulları zorunlu?
• Sonucun doğru olduğu nasıl test edilip onaylanacak?
• Belirsizlik veya değişiklik nasıl yönetilecek?

Bütün soruların ilk gün kesin yanıtı olmayabilir. Bilinmeyenleri görünmez bırakmak yerine “TBD/karar bekliyor” olarak kaydedin; sahibi, çözüm tarihi ve etkisini ekleyin.

Dokümanı tamamlamadan önce web yazılımın genel proje sürecini ve MVP ilk sürüm kararını netleştirin. Ardından gereksinimleri bütçe alanlarıyla, entegrasyon kayıtlarıyla ve güvenlik ile bakım sorumluluklarıyla karşılıklı doğrulayın.

Sonuç

Web yazılım ihtiyaç dokümanı bir özellik listesi değil, iş hedefinden kabul testine uzanan karar sistemidir. Proje özeti neden ve sınırları; gereksinim kartları beklenen davranışı; izlenebilirlik matrisi ise her maddenin tasarım, geliştirme ve test karşılığını gösterir.

İyi gereksinim açık, gerekli, tutarlı, uygulanabilir ve doğrulanabilir olmalıdır. Kullanıcı rolleri, iş kuralları, veri, entegrasyon, güvenlik, erişilebilirlik ve işletim gereksinimlerini başlangıçta görünür kılmak; tekliflerin aynı kapsam üzerinden değerlendirilmesini ve proje değişikliklerinin etkisiyle birlikte yönetilmesini sağlar.