İş Analistiİş Analisti

Gereksinim spesifikasyonunda (SRS, Software Requirements Specification) hangi bilgiler zorunlu olarak yer almalıdır ve iş analisti bunun tamlığını ve netliğini nasıl sağlar?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap.

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:

  • SRS, hem fonksiyonel hem de fonksiyonel olmayan gereksinimleri içerir.
  • Gereksinimler, en az anlamsızlıkla net bir şekilde formüle edilmelidir.
  • SRS'nin içinde, kullanım senaryoları, kısıtlamalar, başarılı sonuç kriterleri mutlaka yer almalıdır.

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.

Zorlayıcı Sorular.

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.

Tipik Hatalar ve Anti-Desenler

  • Gereksinimlerin yetersiz detaylandırılması, örneklerin ve kabul kriterlerinin eksikliği.
  • Anlamsız ifadelerin kullanımı: "hızlı", "rahat", "güvenilir" gibi, sayısal özellikler olmadan.
  • Fonksiyonel olmayan gereksinimlerin göz ardı edilmesi.

Hayattan Örnek

Olumsuz Vaka

SRS yalnızca kullanıcı hikayelerine dayanarak yazılmış, performans ve güvenlik gereksinimleri unutulmuştur.

Artılar:

  • Belgenin hızlı hazırlanması.

Eksiler:

  • Proje güvenlik denetiminden geçemedi, gerekli olan eşzamanlı kullanıcı sayısını karşılamadı.

Olumlu Vaka

SRS, gerekli tüm özellikleri kapsıyor—fonksiyon, fonksiyonel olmayan gereksinimler, kabul kriterleri, sözlük.

Artılar:

  • Denetime hazır, tüm katılımcılar için net gereksinimler, değişikliklerin yüksek yönetilebilirliği.

Eksiler:

  • Belgelerin hazırlanması ve onaylanması için artan iş gücü maliyetleri.