SRS, geliştirilecek sistemle ilgili tüm gereksinimleri tanımlayan yapılandırılmış bir belgedir. Amaç, iş beklentilerini proje ekibinin diline mümkün olduğunca net ve eksiksiz bir şekilde "tercüme" etmektir. Temel bölümler:
1. Giriş (amaçlar, uygulama alanı, terminoloji) 2. Ürün ve iş bağlamı açıklaması 3. Kullanıcılar ve rolleri açıklamaları 4. Fonksiyonel gereksinimler (use cases, kullanıcı hikayeleri) 5. Fonksiyonel olmayan gereksinimler (güvenlik, performans, kullanılabilirlik) 6. Kısıtlamalar 7. Arayüzler 8. Dışsal bağımlılıklar 9. Gereksinimlerin kabul kriterleri 10. Terim sözlüğü
Anahtar özellikler:
Tamlık ve kaliteyi kontrol etmek için analist, doğrulama kontrol listeleri, şablonlar, IEEE 830 standartları ve kilit paydaşlarla düzenli mutabakat kullanır.
Tam bir SRS için yalnızca kullanıcı hikayelerini tanımlamak yeterli midir?
Hayır. Kullanıcı hikayeleri işlevsel yönü gösterirken, fonksiyonel olmayan gereksinimleri, kısıtlamaları, arayüzleri, istisna senaryolarını ve kabul kriterlerini kapsamaz.
Belge içinde aynı varlık için farklı terimler kullanmak mümkün müdür?
Hayır. Terminolojinin tutarlılığı muhakkak sağlanmalıdır: bunun için bir terim sözlüğü oluşturulur ve belgenin çapraz incelemesi yapılır.
SRS, güvenlik ve performans gereksinimlerini içermeli mi?
Evet. Fonksiyonel olmayan gereksinimler kritik öneme sahiptir: bunların eksikliği, teknik borç veya sistemin işletilememesi ile sonuçlanabilir.
SRS yalnızca kullanıcı hikayelerine dayanarak yazılmış, performans ve güvenlik gereksinimleri unutulmuştur.
Artılar:
Eksiler:
SRS, gerekli tüm özellikleri kapsıyor—fonksiyon, fonksiyonel olmayan gereksinimler, kabul kriterleri, sözlük.
Artılar:
Eksiler: