Yazılım Gereksinim Spesifikasyonu (SRS): Yazılımın Ne Yapacağını Tanımlayan Belge

SRS nedir?

SRS, yazılım projesinde herkesin aynı şeyi konuştuğunu sağlamaya çalışan referans belgedir. İş tarafı, analist, geliştirici, test uzmanı ve yönetici belgeye bakarak "bu sistem ne yapacak, neyi yapmayacak, hangi sınırlar içinde çalışacak" sorularına aynı yanıtı bulmalıdır.

Bir iş gereksinim belgesi (BRD) işin neden yapıldığını ve iş hedeflerini anlatır; SRS ise bunu yazılımın davranışına çevirir. SRS bir tasarım belgesi de değildir: sistemin nasıl kodlanacağını değil, ne yapması gerektiğini tanımlar. Bu ayrım, geliştiricilere uygulama özgürlüğü tanırken beklentiyi netleştirir.

Bir SRS'nin içeriği

Kurumdan kuruma biçim değişse de tipik bir SRS şu bölümleri taşır: • Amaç ve kapsam: sistemin neyi çözdüğü, neyin kapsam dışı olduğu. • Tanımlar ve kısaltmalar: belgede kullanılan terimlerin ortak sözlüğü. • Genel tanım: ürünün çevresi, kullanıcı sınıfları, varsayımlar ve bağımlılıklar. • İşlevsel gereksinimler: sistemin yerine getireceği davranışlar ve işlemler. • Dış arayüz gereksinimleri: kullanıcı arayüzü, diğer sistemlerle bağlantı, donanım. • İşlevsel olmayan gereksinimler: performans, güvenlik, kullanılabilirlik, güvenilirlik, bakım yapılabilirlik. • Kısıtlar ve uyum: yasal ve teknik zorunluluklar. • Ekler ve izlenebilirlik: gereksinimlerin kaynaklarıyla ve testlerle bağı.

Kurumun kullandığı şablon ya da uluslararası gereksinim mühendisliği standardı varsa, başlıklar ona göre uyarlanır.

İyi bir gereksinimin özellikleri

SRS'de yazılan her gereksinim şu ölçütleri karşılamaya çalışır: açık (tek bir okumaya sahip), tam (gerekli bilgiyi taşıyor), tutarlı (diğer gereksinimle çelişmiyor), doğrulanabilir (test edilerek karşılandığı gösterilebiliyor), izlenebilir (kaynağına ve testine bağlanabiliyor) ve benzersiz tanımlı (her birinin kimliği var).

"Sistem hızlı olmalıdır" doğrulanabilir değildir. "Arama sonuçları X saniye içinde listelenmelidir" ise test edilebilir bir gereksinimdir (X, projede belirlenen eşiktir). "Olmalı" ve "gerekir" gibi kesin kipler, "mümkünse" ya da "uygun şekilde" gibi esnek ifadelere tercih edilir.

Küçük bir örnek

Örneğin bir klinik için randevu sistemi tasarlanıyor. SRS'de işlevsel gereksinim şöyle yazılabilir: "Hasta, uygun saat aralıklarını görüp randevu oluşturabilmelidir. Sistem, aynı saat için tekrar randevuya izin vermemelidir." Her gereksinim bir kimlik taşır ve bir test senaryosuna bağlanır.

İşlevsel olmayan bir gereksinim ise şöyle olabilir: "Randevu verileri yalnızca yetkili personel tarafından görüntülenebilmelidir." Bu cümle kişisel verilerin korunmasına ilişkin bir güvenlik beklentisini ifade eder ve erişim denetimi testiyle doğrulanır.

Çevik süreçlerde SRS

Çevik ekiplerde kullanıcı hikayeleri ve ürün biriktirme listesi gereksinim ifadesinin ana biçimidir; ağır bir SRS yazmak kimi ekiplerde gereksiz görülür. Buna rağmen düzenlemeye tabi alanlarda (savunma, sağlık, finans), sözleşmeli projelerde ve güvenlik açısından kritik sistemlerde yazılı, izlenebilir bir spesifikasyon hâlâ beklenir.

Pratikte bu yaklaşımlar birleştirilir: değişmeyen iş kuralları ve işlevsel olmayan gereksinimler belge halinde tutulur, işlevsel davranışlar hikayeler ve kabul ölçütleriyle sürdürülür. Karar, projenin riskine ve sözleşme yapısına göre verilir.

Sık yapılan hatalar

• Çözümü gereksinim diye yazmak: "Veritabanında şu tablo olsun" bir tasarım kararıdır, ihtiyaç değil.
• Belirsiz sıfatlar kullanmak: "kolay", "hızlı", "esnek" gibi sözcükler test edilemez.
• Paydaşları tamamen dışarıda bırakmak: gereksinimler yalnızca analistin tahminlerine dayanır.
• Değişikliği izlememek: sürüm ve onay kaydı olmayan belge hızla güncelliğini yitirir.
• Tüm işlevsel olmayan gereksinimleri atlamak: güvenlik ve performans beklentileri sonradan eklenince maliyetlidir.

Bu konuyu Mindset programlarında nerede çalışırsınız?

Gereksinim Analistliği Sertifika Programı, "Gereksinim Yazımı ve Dokümantasyon Kalitesi", "Doğrulama, Onaylama ve Gereksinim Kalitesi" ve "İzlenebilirlik ve Değişiklik Yönetimi" gibi modüllerle SRS'nin yazım ve kalite tarafını kapsar. İş analistleri, ürün sahipleri ve proje yöneticileri için uygundur.

Gereksinim Yönetimi ve İzlenebilirlik (Savunma Projeleri) programı ise gereksinimin yazımı, ayrıştırılması ve izlenebilirliği üzerine odaklanır; düzenleyici nitelikli projelerde çalışan ekipler için daha yakın bir çerçeve sunar.