Yazılım Mühendisliği

Gereksinim Mühendisliği

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

Giriş

“Rahat Bir Ev” İsteği

Mimarın yorumu

Geniş salon, açık mutfak.

Evde yaşayacakların ihtiyacı

Gece vardiyasından sonra uyuyabilecekleri sessiz bir oda ve basamaksız giriş.

İnşaata başlamadan hangi soruları sormalıydık?

Öğrenme Kazanımları

Bu dersin sonunda:

  • İşlevsel, işlevsel olmayan ve etki alanı gereksinimlerini ayırt edebilecek,
  • Belirsiz bir İOG’yi ölçülebilir ölçütlere ve altı parçalı kalite senaryosuna dönüştürebilecek,
  • Gereksinim mühendisliğinin üç iç içe faaliyetini (keşif ve analiz, belirleme, gereksinimlerin geçerlenmesi) ve değişiklik yönetiminin bu faaliyetlerle ilişkisini açıklayabilecek,
  • Gereksinimleri MoSCoW ve WSJF ile önceliklendirebilecek, belirsiz bir gereksinimi EARS kalıbıyla yeniden yazabilecek,
  • Gereksinim değişikliklerinin kimlik, izlenebilirlik matrisi ve değişiklik talebi ile nasıl yönetildiğini açıklayabilecek,
  • SRS ile ürün iş listesinin farklı amaçlarını ve birlikte nasıl kullanılabileceklerini açıklayabilecek,
  • Yapay zeka ve DevOps gibi güncel pratiklerin getirdiği yeni gereksinimleri örneklerle açıklayabilecek.

Gereksinim Mühendisliği

Gereksinim Mühendisliği Nedir?

Gereksinim mühendisliği, geliştirilecek sistem hakkında paydaşların aynı şeyi anlamasını sağlar.

01

Ne yapacak?

Sistemin sunacağı hizmetleri ve kullanıcıların hangi işleri yapacağını belirler.

02

Hangi koşullarda?

Güvenlik, performans, bütçe ve teslimat süresi gibi sınırları açıklar.

Bu ihtiyaçlar belirlenir, yazılır, doğrulanır ve değiştikçe yönetilir.

Hizmetler ve Kısıtlamalar

Akıl Sağlığı Hasta Yönetim Sistemi (AS-HYS), ruh sağlığı kliniklerinde hasta kayıtlarını, randevuları ve tedavi bilgilerini yönetir. Randevu aramaya bakalım:

Hizmet Ne yapacak?

Görevli, bir hastanın randevusunu tüm kliniklerin listelerinde arayabilir.

Kısıt Hangi koşulda?

Aramaya yalnızca yetkili roller erişebilir; yoğun saatlerde de yanıt süresi hedefi karşılanmalıdır.

Bu ifadeler, geliştirme ve değerlendirme sırasında başvurulacak gereksinimlerin başlangıcıdır.

Gereksinimin Ayrıntı Düzeyi

Erken aşama “Randevular hızlı bulunabilsin.”

İhtiyacı anlatır; çözümü ve ölçümü henüz belirlemez.

Geliştirme öncesi “Tüm kliniklerde hasta adı aramasında, dakikada 50 istekte p95 yanıt süresi 300 ms’yi aşmamalıdır.”

Koşul ve ölçüt artık açık. p95, aramaların %95’inin aşmadığı yanıt süresidir.

Teklifte genel bir çerçeve yeterli olabilir. Sözleşme ve uygulama için daha açık, doğrulanabilir gereksinimler gerekir.

Soyutlama Seviyeleri ve Paydaşlar

İhtiyaç başlangıçta çözümü peşinen belirlemeyecek kadar genel tutulur. Geliştirme ve doğrulama için sonra ayrıntılandırılır.

Kullanıcı gereksinimi İş ihtiyacı ve beklenen hizmet

Müşterinin ve son kullanıcının anlayacağı doğal dilde yazılır.

Sistem gereksinimi Uygulanacak ve sınanacak ayrıntı

Geliştiriciler ve test ekibi için davranışı ve kısıtları açıklar; sözleşmenin parçası olabilir.

Bu ayrım, Davis’in soyutlama yaklaşımındaki genel ihtiyaçtan ayrıntılı tanıma geçişi gösterir.

AS-HYS Örneği: Kullanıcı Gereksinimi

AS-HYS’de aylık ilaç maliyeti raporu

Kullanıcı gereksinimi
AS-HYS, her kliniğin ay boyunca reçete ettiği ilaçların maliyetini gösteren aylık yönetim raporları oluşturmalıdır.

Yönetimin istediği çıktı belli. Raporun ne zaman üretileceği, içeriği ve kimlerin erişeceği henüz açıklanmadı.

AS-HYS Örneği: Sistem Gereksinimleri

Aynı istek, uygulanabilir kurallara ayrıldığında:

1.1

Her ayın son iş gününde, reçete edilen ilaçları, maliyetlerini ve reçeteleyen klinikleri içeren bir özet oluşturulmalıdır.

1.2

Sistem, ayın son iş gününde saat 17.30’dan sonra raporu yazdırılmak üzere otomatik olarak üretmelidir.

1.3

Her klinik için ayrı rapor hazırlanmalı; ilaç adları, reçete sayıları, reçete edilen doz sayıları ve toplam ilaç maliyeti gösterilmelidir.

1.4

İlaç farklı dozlarda sunuluyorsa (ör. 10 mg, 20 mg), her doz için ayrı rapor oluşturulmalıdır.

1.5

Maliyet raporlarına yalnızca yönetimin erişim kontrol listesinde bulunan yetkili kullanıcılar erişebilmelidir.

Farklı Gereksinimlerin Okuyucuları

AS-HYS’nin aylık rapor isteği yönetici için tek cümleydi; geliştirici ve test ekibi için beş ayrı kurala dönüştü. Herkes aynı ayrıntıyı okumaz.

Okuyucu İlgilendiği Tür Amacı
Müşteri Yöneticileri Kullanıcı İş hedeflerinin karşılanıp karşılanmadığını kontrol etmek.
Son Kullanıcılar Kullanıcı İhtiyaçlarına cevap verilip verilmediğini anlamak.
Sistem Mimarları Her ikisi Üst düzey yapıyı tasarlamak, fizibiliteyi değerlendirmek.
Geliştiriciler Sistem Neyin kodlanacağını ayrıntısıyla anlamak.
Test Mühendisleri Sistem Doğrulama ve kabul/geçerleme testlerini türetmek.

Hasta Kaydına Erişim

AS-HYS’de acil bir görüşme öncesi

Doktor

“Hastanın geçmişine gecikmeden ulaşmam gerekiyor.”

Veri koruma sorumlusu

“Bu kayıtları yalnızca yetkili kişiler görmeli.”

Acil erişim hangi koşullarda açılmalı ve nasıl kayda geçmeli?

Fizibilite Çalışmaları (Olurluk İncelemesi)

Gereksinimleri ayrıntılandırmadan önce, bu sistemi geliştirmenin kuruluş için anlamlı ve uygulanabilir olup olmadığına bakılır.

  • Üç temel soruyu yanıtlamalıdır:
    1. Sistem, kuruluşun genel hedeflerine katkıda bulunuyor mu?
    2. Mevcut teknoloji, bütçe ve zaman çizelgesinde sistem uygulanabilir mi?
    3. Sistem, mevcut diğer sistemlerle entegre edilebilir mi?

Uyarı

Bir sorunun cevabı “hayır” ise kapsamı, bütçeyi veya yaklaşımı yeniden konuşmak gerekir.

Gereksinim Türleri

Gereksinim Türlerine Genel Bakış

Şimdi AS-HYS’de gördüğümüz ifadeleri türlerine ayıralım. İG ve İOG, gereksinimin neyi tanımladığını; etki alanı ise ihtiyacın nereden kaynaklandığını gösterir:

  • İşlevsel Gereksinimler (İG, Functional): Sistemin ne yapması gerektiğini: sunacağı hizmetleri, girdilere nasıl tepki vereceğini ve belirli durumlardaki davranışını tanımlar.

  • İşlevsel Olmayan Gereksinimler (İOG, Non-Functional): Sistemin karşılaması gereken kalite hedeflerini ve kısıtları tanımlar (performans, güvenlik, güvenilirlik gibi).

  • Etki Alanı Gereksinimleri (Domain): Sağlık, bankacılık veya havacılık gibi alanların kurallarından doğar; bir işlev ya da kalite/kısıt gereksinimi olarak ifade edilebilir.

Kimliklerde (ID) İngilizce FR- ve NFR- önekleri kullanılır.

İşlevsel Gereksinimler (İG)

Functional Requirements

  • Tanım: Sistemin sunması gereken hizmetlerin, belirli girdilere nasıl tepki vereceğinin ve belirli durumlarda nasıl davranması gerektiğinin beyanlarıdır.
  • Bazen sistemin ne yapmaması gerektiğini de belirtebilirler.
  • Örnek (AS-HYS): “Bir kullanıcı, tüm kliniklerin randevu listelerinde arama yapabilmelidir.”

Randevu Aramasındaki Belirsizlik

“Bir kullanıcı, tüm kliniklerin randevu listelerinde arama yapabilmelidir.”

Bu cümleden hangi ekran çıkar?

Yorum 1 Hasta adı bir kez girilir; bütün kliniklerde aranır.

Yorum 2 Önce klinik seçilir; yalnız o kliniğin listesi aranır.

Hasta yanlış kliniğe geldiyse ikinci yorum ihtiyacı karşılamaz.

İptal edilen randevuların gösterilip gösterilmeyeceği de henüz belirtilmemiştir.

İşlevsel Olmayan Gereksinimler (İOG)

Non-functional Requirements (NFR)

  • Tanım: Sistemin karşılaması gereken kalite hedefleri (performans, güvenlik, güvenilirlik gibi) ile geliştirme sürecine ilişkin kısıtlardır.
  • Tek bir işlevi ya da sistemin bütününü ilgilendirebilirler; bazıları sistem düzeyinde ortaya çıkan özelliklerle (emergent properties) ilişkilidir.
  • Etkisi: Bir İOG karşılanmadığında, işlevler çalışsa bile sistemin kullanımı mümkün olmayabilir (örn. uçak sisteminin güvenilirlik gereksinimleri).

İOG’ler İşlevsel Gereksinimleri Tetikler

Tek bir İOG, onu sağlayacak bir dizi İG doğurabilir. Örneğin “sistem güvenli olmalıdır” İOG’si; kimlik doğrulama, yetkilendirme ve denetim kaydı gibi işlevleri gerektirir. İOG’ler ayrıca mimariyi yönlendirir (örn. performans hedefi, önbellekleme kararını etkiler).

İOG Kaynakları

Not

İOG’ler üç kaynaktan gelir

  • Ürün: Çalışma zamanı davranışı (örn. p95 yanıt süresi, hizmet sürekliliği).
  • Organizasyonel: Süreç ve standartlar (örn. kullanılacak IDE, kod standartları).
  • Dış: Yasal, etik ve düzenleyici kurallar (örn. gizlilik mevzuatı).

Gereksinim mi, Tasarım mı?

Gereksinimler ve Tasarım Gereksinim, beklenen davranışı, kalite hedefini veya uyulacak kısıtı belirtir. Tasarım, bunları karşılamak için seçilen çözümü açıklar. Bazen belirli bir teknoloji kullanma zorunluluğu da (örn: “sistem belirli bir veritabanını kullanmalıdır”) entegrasyon ortamı veya yasal koşullar nedeniyle gereksinim haline gelir.

İOG’lerin Kapsamı

  • Güvenlik (Security): Kimlik doğrulama, yetkilendirme, denetim kayıtları, veri şifreleme.
  • Emniyet (Safety): Hata durumunda güvenli işlev kaybı (graceful degradation); tehlikeli çıktıları önleme.
  • Bakım Yapılabilirliği (Maintainability): Modülerlik, kod karmaşıklığı üst sınırları, dokümantasyon.
  • Erişilebilirlik (Accessibility - a11y): WCAG 2.2 AA; klavye ile gezinme; normal metinde kontrast ≥ 4.5:1, büyük metinde ≥ 3:1.
  • Uluslararasılaştırma (i18n/L10n): Unicode, çoklu dil/alfabe, tarih/sayı yerelleştirme.

İOG’lerin Belirtilmesi: Hedefler ve Metrikler

İOG’ler, belirsiz ifadeler yerine doğrulanabilir ölçütlerle belirtilmelidir.

  • Hedef (Goal): Genel bir niyeti belirten, yoruma açık ifadedir.
    • Örnek: “Sistem, sağlık personeli tarafından kullanımı kolay olmalıdır.”
  • Doğrulanabilir Gereksinim (Verifiable Requirement): Nesnel olarak test edilebilen, metrik tabanlı bir ifadedir.
    • Örnek: “Sağlık personeli, iki saatlik eğitimin ardından tüm sistem işlevlerini kullanabilecektir. Bu eğitimden sonra deneyimli kullanıcılar tarafından yapılan ortalama hata sayısı, sistem kullanım saatinde ikiyi geçmeyecektir.”

İOG’leri Ölçmek için Metrikler

Özellik Ölçüm / Metrik
Hız İşlem/saniye, kullanıcı-olay yanıt süresi, ekran yenileme süresi
Boyut Bellek kullanımı (MB), kurulum paketi veya konteyner imajı boyutu
Kullanılabilirlik (Usability) Eğitim süresi, görev tamamlama oranı, yardım menüsü sayısı
Güvenilirlik (Reliability) Arızaya kadar ortalama süre (MTTF), hata oranı
Hizmet Sürekliliği (Availability) Çalışma süresi yüzdesi (örn. %99,9), planlı kesinti süresi
Sağlamlık (Robustness) Hata sonrası yeniden başlama süresi, veri bozulma olasılığı

İOG ve Doğrulama Örnekleri

  • Hizmet sürekliliği (Availability): Aylık ≥ %99,5; planlı bakım toplamı ≤ 2 saat/ay.
  • Güvenlik: Yetkisiz rolün hasta kaydına erişimi reddedilir; deneme, denetim kaydına yazılır.
  • Maintainability: Her servis için CC ≤ 10 (ortalama döngüsel karmaşıklık); lint hatası = 0.
  • Erişilebilirlik: Ana iş akışları, WCAG 2.2 AA ölçütlerine göre otomatik tarama ve elle yapılan klavye/ekran okuyucu testleriyle değerlendirilir.

Örnekler: Hizmet Sürekliliği

Ölçüt, hedefin karşılanıp karşılanmadığını söyler. AES-256 gibi bir teknoloji seçimi ise bu hedefi karşılamak için alınabilecek tasarım kararlarından biridir; tek başına güvenliği kanıtlamaz.

  • Hizmet Sürekliliği (Availability):
    • Aylık ≥ %99,5: 30 günlük bir ayda sistem toplamda en fazla 3,6 saat kapalı kalabilir. Bu süreyi aşmak, sözleşmeyi ihlal etmektir.
    • planlı bakım ≤ 2 saat/ay: Bu örnekte planlı bakım da 3,6 saatin içinde sayılır; geriye kalan süre beklenmedik arızalar içindir. Birçok SLA planlı bakımı bu hesabın dışında tutar, bu yüzden sözleşmede açıkça yazılmalıdır.
  • Güvenlik:
    • Yetkisiz erişim reddedilir: Hasta kaydına yalnızca ilgili rolün erişebilmesi beklenen sonuçtur; farklı rollerle yapılan testlerde bu kural sınanır.
    • Şifreleme: Diskteki veriyi ve ağ trafiğini korumak için şifreleme kullanılabilir. Algoritma, anahtar yönetimi ve bağlantı ayarları tasarımda ayrıca belirlenir.

Örnekler: Bakım ve Erişilebilirlik

  • Maintainability (Bakım Yapılabilirlik):
    • CC ≤ 10: Kodun karmaşıklığı (“spagetti kod” olup olmadığı) ölçülebilir bir sınırın altında kalmalıdır; sonradan gelen geliştiricilerin kodu anlamasını kolaylaştırır.
    • lint hatası = 0: Kod, belirlenen stil ve kalite kurallarına tam uymalıdır; ekibi ortak bir standartta tutar.
  • Accessibility (Erişilebilirlik):
    • WCAG 2.2 AA değerlendirmesi: Otomatik taramada ihlal görülmemesi yeterli değildir; klavye kullanımı ve ekran okuyucuyla görev tamamlama da kontrol edilir.

Belirsiz Hedeften Kalite Senaryosuna

Belirsiz bir hız hedefini, altı parçalı bir kalite senaryosuyla ölçülebilir hâle getirelim.

“Randevu arama hızlı olmalıdır.” Kaynak: resepsiyon görevlisi. Uyarıcı: randevu araması başlatır. Eser: randevu arama uç noktası. Ortam: yoğun saat testinde tüm kliniklerde dakikada 50 arama. Tepki: sonuçları döndürür ve loglar. Ölçüt: p95 yanıt süresi ≤ 300 ms, hata oranı ≤ %1.

Kalite Senaryosundan Teste

Animasyonda neyi, hangi koşulda kabul edeceğimizi belirledik. Testi çalıştırmadan önce şu ayrıntılar da gerekir:

  1. Test verisi: Veritabanında kaç randevu bulunacak? Kayıtlar kliniklere nasıl dağılacak?
  2. Yük profili: Dakikada 50 arama yükü ne kadar sürecek? İstekleri hangi araç üretecek?
  3. Ölçüm ve kontrol: Yanıt süreleri ve hatalar nereden toplanacak? Dönen sonuçlar ve loglar nasıl doğrulanacak?

p95 ≤ 300 ms demek, ölçülen aramaların en az %95’inin 300 ms veya daha kısa sürede yanıtlanması demektir; ortalama süreyi ya da en yavaş aramayı göstermez. Hata oranı ayrıca en fazla %1 olmalıdır.

Etki Alanı Gereksinimleri

İşlev ve kaliteyi tanımladıktan sonra bir de gereksinimin kaynağını sorarız: Alanın kendi kuralları bize ne söylüyor?

  • Tanım: Yazılımın kullanıldığı alandaki iş kurallarından, fiziksel koşullardan veya düzenlemelerden kaynaklanır. Yeni bir işlev gerektirebilir ya da bir kalite hedefi veya kısıt getirebilir.
  • Örnek (Tren Koruma Sistemi): Yazılım, trenin yavaşlamasını hesaplarken, fren gücünün yanı sıra rayların eğiminden kaynaklanan fiziksel etkiyi de hesaba katmak zorundadır.
    • \(D_\text{train} = D_\text{control} + D_\text{gradient}\)
    • \(D_\text{control}\): fren sisteminin sağladığı yavaşlama; \(D_\text{gradient}\): rayın eğiminin yavaşlamaya etkisi.

Bu örnekte fren hesabı bir işlevdir; gereksinimin kaynağı demiryolu alanının fiziksel koşullarıdır.

Etki Alanı Gereksinimlerinin Zorlukları

  • Anlaşılabilirlik: Gereksinimler, genellikle yazılım mühendislerinin anlamadığı, alana özgü bir terminoloji ile ifade edilir.
  • Örtük Bilgi (Implicit Knowledge): Alan uzmanları, bazı temel bilgileri o kadar iyi bilirler ki bunları açıkça belirtmeye gerek duymazlar.

Kabul Kriteri Örnekleri

Şimdi AS-HYS’ye dönelim: Aynı arama hizmetinin davranışını, hızını ve erişim koşullarını ayrı ayrı nasıl sınarız?

  • FR-APPT-001 (Randevu Listesi)
    • Hasta adıyla arama, randevuları tüm kliniklerin listelerinde bulur; klinik seçimi zorunlu değildir.
    • Sonuçta klinik, gün ve saat gösterilir; iptal edilen randevuların gösterilip gösterilmeyeceği paydaşla ayrıca kararlaştırılır.
  • NFR-PERF-005 (Performans)
    • Tüm kliniklerde randevu aramasında p95 yanıt süresi ≤ 300 ms, hata oranı ≤ %1 (yoğun saatte, 1 dakikada 50 arama).
  • NFR-SEC-010 (Güvenlik)
    • Yetkisiz rolün hasta kaydı isteği reddedilir.
    • Reddedilen erişim denemesi denetim kaydına yazılır; saklama süresi kurumun kayıt politikasında belirtilir.
  • NFR-OBS-020 (Gözlemlenebilirlik)
    • Tüm istekler için correlation-id üretilir, loglanır.
    • Temel metrikler (QPS, p95, hata oranı) izleme ekranından görülebilir.

Alıştırma 1:

AS-HYS için şu İOG hedefi verilmiştir:

“Sistem, hasta kayıtlarına erişimde güvenli olmalıdır.”

  1. Bu hedefi doğrulanabilir en az iki ölçüte dönüştürün.
  2. Kalite senaryosunun altı parçasını (kaynak, uyarıcı, ortam, eser, tepki, ölçüt) doldurun.
  3. Bu İOG’nin tetikleyebileceği işlevsel gereksinimleri sıralayın.

Alıştırma 1: Örnek Çözüm

  • Ölçütler: Yetkisiz rolün kayıt açma denemesinde kayıt gösterilmez. Reddedilen her test denemesi için kullanıcı, zaman ve hedef kayıt bilgisi denetim kaydında bulunur.
  • Senaryo:
    • Kaynak: yetkisiz rol;
    • uyarıcı: başka bir kliniğin hasta kaydını açma isteği;
    • ortam: normal çalışma; eser: hasta kaydı servisi; tepki: erişim reddedilir ve olay kaydedilir;
    • ölçüt: testte kayıt gösterilmez ve ilgili denetim kaydı oluşur.
  • Tetiklenen İG’ler: kimlik doğrulama, rol tabanlı yetkilendirme, denetim kaydı oluşturma.

Gereksinim Mühendisliği Süreçleri

Süreçlere Genel Bakış

Buraya kadar gereksinimlerin nasıl göründüğünü konuştuk. Şimdi bunların nasıl ortaya çıktığına bakalım: keşif, belirleme ve geçerleme iç içe ilerler; yönetim ise değişiklikleri süreç boyunca izler.

Sarmalın her turunda üç faaliyet birbirini besler:

  1. Keşif (Elicitation) ve Analiz: Paydaşlarla etkileşim kurularak ihtiyaçların anlaşılması ve analiz edilmesi.
  2. Belirleme (Specification): Anlaşılan gereksinimlerin standart bir formatta yazılması ve belgelenmesi.
  3. Gereksinimlerin Geçerlenmesi (Validation): Yazılanların tutarlı, uygulanabilir ve müşterinin ihtiyacına uygun olup olmadığının kontrol edilmesi.

Süreç boyunca yönetim: Gereksinimlere kimlik verir, bağlantılarını tutar ve değişikliklerin etkisini izler.

Süreç 1: Keşif ve Analiz (Elicitation)

  • Amaç: Müşterinin yalnızca “ne söylediğini” değil, “neye ihtiyacı olduğunu” da anlamaktır.

  • Zorluk: İhtiyaçlar genellikle belirsiz, eksik veya çelişkilidir. Keşif sırasında bunları sorular ve gözlemlerle açıklığa kavuştururuz.

Paydaşlar

Paydaş, projeden doğrudan veya dolaylı olarak etkilenecek herkestir; tek bir paydaşı gözden kaçırmak bile projeyi riske atar. AS-HYS örneği:

Paydaş Grubu En Önemli Önceliği Potansiyel Çatışma Noktası
Hasta Verilerim güvende olsun, randevu kolay alınsın. Yüksek güvenlik, bazen kullanım kolaylığını yavaşlatabilir.
Doktor Hasta bilgilerine saniyeler içinde ulaşayım. Hız için yapılan optimizasyonlar, BT’nin bakım yükünü artırabilir.
BT Personeli Sistem çökmesin, bakımı kolay ve güvenli olsun. Aşırı güvenli bir sistem, doktor için yavaş ve hantal olabilir.
Veri koruma sorumlusu Hasta verileri ilgili mevzuata uygun işlensin. Veri toplama ve paylaşma istekleriyle çatışabilir.

Ana Fikir: Farklı öncelikler her zaman aynı anda karşılanamayabilir. Amaç, ihtiyaçları görünür kılıp gerekçeli bir denge kurmaktır.

Keşif Döngüsü ve Yaygın Engeller

Gereksinimleri ortaya çıkarma süreci genellikle dört adımlık bir döngüdür:

  1. Bilgi Toplama (Discovery): Paydaşlarla konuşarak, gözlemleyerek ham bilgiyi toplama.
  2. Sınıflandırma: Yüzlerce farklı isteği anlamlı gruplara ayırma.
  3. Önceliklendirme & Müzakere: En önemli ve acil olanları belirleme ve çatışmaları çözme.
  4. Belgeleme: Anlaşılan konuları yazıya dökme; yeni sorular çıkarsa yeniden keşfe dönme.

Bu Süreç Neden Zordur?

  • İstenen çözüm, asıl ihtiyacı gizleyebilir: “Daha fazla rapor ekleyin” diyen bir kullanıcı, aslında mevcut raporun geç açılmasından şikâyet ediyor olabilir.
  • Ortak bir dil yoktur: Doktor “epikriz” der, geliştirici “rapor objesi”.
  • Gizli politikalar vardır: Bazen bir özellik, teknik gereklilikten değil, departmanlar arası güç dengeleri nedeniyle istenir.
  • Her şey sürekli değişir: Bugünün en önemli ihtiyacı, yarının gereksiz detayı olabilir.

Keşif Teknikleri

Teknik Açıklama Güçlü Yönü
Görüşmeler Paydaşlarla kapalı (belirli sorular) veya açık (serbest) formatta yapılan toplantılar. Genel bir anlayış kazanmak, beklentileri öğrenmek.
Senaryolar Sistemin belirli bir durumda nasıl kullanılacağını anlatan yapılandırılmış hikayeler. Karmaşık etkileşimleri ve istisnai durumları detaylandırmak.
Kullanım Durumu Aktörün hedefini ve sistemle etkileşimini anlatır; UML diyagramıyla da gösterilebilir. Temel akışı ve istisnaları belirlemek.
Etnografi Analistin kullanıcıları iş başında gözlemlemesi (gölgeleme, sessiz gözlem). İfade edilmemiş, örtük gereksinimleri ortaya çıkarmak.

Tekniklere Derin Bakış: Söylenenler ve Gerçekler

Dört tekniğin ikisine yakından bakalım: biri insanların ne söylediğini, diğeri gerçekte ne yaptığını ortaya çıkarır.

Görüşme: İnsanların Ne Söylediğini Anlamak

  • Odak: Paydaşların düşünceleri, istekleri ve sorun olarak gördükleri şeyler.
  • Kullanım: Projenin başında genel bir çerçeve çizmek için idealdir.
  • Tuzak: İnsanlar her zaman yaptıklarını veya ihtiyaç duyduklarını doğru ifade edemeyebilirler.

Etnografi: İnsanların Gerçekte Ne Yaptığını Anlamak

  • Odak: Kullanıcıların doğal çalışma ortamındaki davranışları, kestirme yolları ve “sistemi kandırma” yöntemleri.
  • Senaryo: Bir analist, bir tıbbi sekreteri bir gün boyunca izler. Sekreterin, sistemin randevu raporu yavaş olduğu için her sabah verileri elle Excel’e kopyaladığını fark eder.
  • Bulgu (Örtük Gereksinim): Toplantıda kimse raporların yavaşlığından söz etmemiştir; gözlem ise bu gecikmenin sekreterin iş akışını etkilediğini gösterir. Etnografi, dile getirilmeyen ihtiyaçları belirlemeye yardımcı olur.

Önceliklendirme

Kitaptaki keşif döngüsünde önceliklendirme ve müzakere yer alır. MoSCoW ve WSJF, bu konuşmayı somutlaştırmak için eklediğimiz iki pratik araçtır; uzlaşmanın yerini almazlar.

Yöntem 1: MoSCoW

Must have, Should have, Could have, Won’t have (this time) - Must (Olmazsa Olmaz): Bu sürümde yerine getirilmesi zorunlu olan gereksinimler. Örn: Randevu oluşturma. - Should (Olmalı): Çok önemli ama bunlar olmadan da sistem bir şekilde çalışır. Örn: Randevu hatırlatma SMS’i. - Could (Olabilir): Güzel olurdu ama olmaması büyük eksiklik değil. Örn: Doktorun profil fotoğrafı. - Won’t (Bu Sürümde Olmayacak): Şimdi değil, belki gelecek versiyonda.

Yöntem 2: WSJF (Weighted Shortest Job First)

  • Formül: Gecikme maliyeti / iş büyüklüğü. SAFe’de gecikme maliyeti; iş değeri, zaman kritikliği ve risk azaltma/fırsat yaratma puanlarıyla tahmin edilir.
  • Amaç: İşleri, ertelenmelerinin göreli maliyetini ve büyüklüklerini birlikte değerlendirerek sıralamaktır.
  • Örnek: A özelliği: (8 + 3 + 2) / 5 = 2,6. B özelliği: (5 + 2 + 1) / 1 = 8. Bu göreli puanlarla B önce gelir; sayılar gerçek para veya süre değildir.

Alıştırma 2: WSJF ve MoSCoW ile Sıralayın

AS-HYS ürün birikiminde üç özellik var (puanlar 1-8 arası):

Özellik İş değeri Zaman kritikliği Risk azaltma / fırsat İş büyüklüğü
A: Randevu hatırlatma SMS’i 5 3 1 3
B: Hasta kaydına rol tabanlı erişim 8 8 8 5
C: Doktor profil fotoğrafı 2 1 1 2

İkili çalışın (5 dk): Her özelliğin WSJF puanını hesaplayın, sıralayın ve MoSCoW etiketi verin.

Önceliklendirme: Sonuçların Açılması

WSJF sonuçları: B = 4,8; A = 3,0; C = 2,0. Sıralama B, A, C. MoSCoW etiketleri sırasıyla Must, Should, Could; bu etiketler WSJF puanlarından otomatik çıkmaz.

Alıştırma 2: Örnek Çözüm

  • B: (8 + 8 + 8) / 5 = 4,8 → Must
  • A: (5 + 3 + 1) / 3 = 3,0 → Should
  • C: (2 + 1 + 1) / 2 = 2,0 → Could

Sıra: B → A → C. MoSCoW etiketi puandan bağımsız, bağlama göre verilir: B hasta verilerine erişim için zorunlu olduğundan Must’tır. WSJF ise bu örnekte işlerin göreli sırasını gösterir.

Çatışma ve Müzakere

Farklı paydaşların çelişen isteklerini yönetmek kaçınılmazdır.

  • Viewpoints (Bakış Açıları): Her grubun (doktor, hasta, BT) önceliklerini ayrı ayrı analiz edin. Çakışma noktalarını bulun ve bu noktalar üzerinden pazarlık yapın.

  • Win-Win (Kazan-Kazan): Tek bir tarafın talebini kabul etmek yerine, doktorun hız ihtiyacı ile BT’nin güvenlik ihtiyacını birlikte karşılayan bir çözüm aranır.

  • Karar Kayıtları (ADR, Architecture Decision Record): Alınan kararların gerekçesini daha sonra da erişilebilir kılar.
    • Ne yapar? Çatışma sonucu alınan kararın (örn: “Doktor ekranında ek doğrulama yerine tek oturum açma seçildi”) nedenini birkaç cümleyle kaydeder.
    • Neden kaydedilir? Altı ay sonra yeni bir ekip üyesi “Neden Y’yi kullanmadık?” diye sorduğunda, kararın hangi koşullarda alındığını görebilir. Böylece aynı değerlendirmeyi baştan yapmak gerekmez.

Süreç 2: Belirleme (Specification)

Keşifte ortaya çıkan ve müzakere edilen ihtiyaçlar şimdi farklı okurların kullanabileceği bir biçime girer. Çıktı bir Yazılım Gereksinimleri Belgesi (SRS - Software Requirements Specification), ürün iş listesi veya ikisi birlikte olabilir.

SRS ve Ürün İş Listesi (Product Backlog)

  • SRS: Gereksinimleri ayrıntılı ve izlenebilir biçimde toplar. Sözleşme, entegrasyon veya düzenleme gereksinimi olan projelerde yararlı olabilir. (Bkz. ISO/IEC/IEEE 29148.)
  • Ürün iş listesi: Ürünü geliştirmek için gereken işleri sıralı ve güncellenebilir biçimde tutar. Öğeler ihtiyaç oldukça ayrıntılandırılır.
  • Birlikte kullanım: İş listesi neyin sırada olduğunu gösterirken SRS, gerekli konularda ayrıntılı başvuru kaynağı olabilir.

SRS Belgesinin Yapısı

Bölüm İçerik
Önsöz Belgenin hitap ettiği okuyucu kitlesi, sürüm geçmişi ve değişikliklerin gerekçesi.
1. Giriş Sistemin amacı, kapsamı, hedefleri ve genel bir bakış.
2. Genel Tanım Ürün perspektifi, sistem arayüzleri, kullanıcı özellikleri, kısıtlamalar ve varsayımlar.
3. Özel Gereksinimler Detaylar. Örn: 3.1 Arayüz (UI, API), 3.2 İşlevsel, 3.3 Performans, 3.4 Güvenlik, 3.5 Loglama.
Ekler Sözlük (Glossary), analiz modelleri ve referanslar.

Belge Derinliği ve Değişkenlik

  • Artımlı/Çevik: ayrıntılar ihtiyaç duyuldukça eklenir; ürün iş listesi düzenli olarak güncellenir.
  • Sözleşmeli veya düzenlemeye tabi sistem: daha ayrıntılı ve izlenebilir belgeleme gerekebilir.

Büyük Sistemlerde SRS’e Eklenen Bölümler

  • Sistem mimarisi (özet): üst düzey bileşenler, veri akışları ve yeniden kullanılacak bileşenler (örn. kimlik sağlayıcı, mesaj kuyruğu).
  • Sistem modelleri: DFD, veri ve nesne modellerinin kısa diyagramları; sistem-çevre ilişkileri.
  • Sistem gelişimi: donanım/ekosistem varsayımları ve olası değişiklik noktaları (kullanıcı ihtiyaçları, mevzuat, entegrasyonlar).

Doğal Dil Kullanımı İçin İpuçları

  • Standart Format: Tüm gereksinimler için tutarlı bir şablon kullanın.
  • Tutarlı Dil: Zorunluluk düzeyini baştan tanımlayın ve metin boyunca aynı sözcükleri kullanın (örn. shall: zorunlu, should: önerilen, may: isteğe bağlı). Türkçe karşılıklarını da ekipçe belirleyin.
  • Vurgulama: Gereksinimin önemli kısımlarını kalın veya italik yaparak öne çıkarın.
  • Gerekçe (Rationale) Ekleyin: Her gereksinimin “neden” var olduğunu açıklayan kısa bir not ekleyin.

Uyarı

Doğal Dil Sorunları

  • Belirsizlik: aynı terime farklı anlamlar yüklenmesi.
  • Gereksinim Karmaşası: İG ve İOG’nin karışması.
  • Birleşme: birden fazla gereksinimin tek cümlede ifade edilmesi.

Yazım Yönergeleri

  • Her gereksinimde bağımsız doğrulanabilen tek bir beklenti tanımlayın ve benzersiz kimlik (ID) verin.
  • Jargondan kaçının; kısaltmaları ilk geçtikleri yerde açın.

Gereksinim Gösterim Biçimleri

  • Doğal Dil: numaralı, kısa, tek-anlamlı cümleler.
  • Yapılandırılmış Doğal Dil (Şablonlu): alan-adı, tetikleyici, ön/son koşul, gerekçe.
  • Grafik Modeller (UML/DFD): kullanım durumları + sıra diyagramları.
  • Biçimsel Özellikler: durum makineleri veya matematiksel gösterimler; kesinliği artırabilir, ancak alan uzmanları için ek açıklama gerektirebilir.

EARS Kalıpları

Kitaptaki yapılandırılmış doğal dil yaklaşımına ek bir uygulama olarak EARS (Easy Approach to Requirements Syntax), gereksinimleri tutarlı bir söz dizimiyle yazmak için birkaç kalıp sunar:

Kalıp Biçim
Sürekli Sistem <yanıtı> vermelidir.
Olay güdümlü <Olay> gerçekleştiğinde, sistem <yanıtı> vermelidir.
Durum güdümlü <Durum> süresince, sistem <yanıtı> vermelidir.
İstenmeyen durum <Koşul> oluşursa, sistem <yanıtı> vermelidir.
İsteğe bağlı özellik <Özellik> varsa, sistem <yanıtı> vermelidir.

EARS ile Yeniden Yazım

  • Kötü: “Sistem hızlı yanıt vermelidir.”

  • Daha açık (olay güdümlü): “Resepsiyon görevlisi randevu araması yaptığında, sistem sonuç listesini döndürmelidir.” Yanıt süresi hedefi, yük ve ölçüm aralığıyla birlikte ayrı bir İOG olarak yazılır.

  • Kötü: “Kullanıcı kolayca giriş yapar.”

  • Daha açık (olay güdümlü): “Kullanıcı geçerli kimlik bilgilerini girdiğinde, sistem oturumu açmalıdır.” Açılış süresi ayrıca ölçülebilir bir İOG olarak belirtilir.

Yapılandırılmış Özellik Örneği (AS-HYS)

  • Fonksiyon: Randevu oluşturma
  • Girdi: hasta kimliği, klinik, doktor, tarih ve saat
  • Çıktı: işlem sonucu ve başarılıysa randevu kimliği
  • Önkoşul: kullanıcı yetkili, hasta kayıtlı
  • Sonkoşul: Başarılı işlemde randevu kaydedilir. Reddedilen işlemde takvim değişmez.
  • Kısıt: Aynı doktorun aynı zaman diliminde iki randevusu olamaz.

Tablo Spesifikasyonu (Özet)

Durum Sistemin tepkisi
Doktorun seçilen saati boş Randevuyu oluşturur, kimliğini döndürür.
Doktorun seçilen saati dolu İsteği reddeder, takvimi değiştirmez.
Kullanıcının randevu oluşturma yetkisi yok İsteği reddeder, takvimi değiştirmez.

Bu özet, eşzamanlı istekler ve iptal kuralları gibi durumlar eklenmeden tam bir spesifikasyon sayılmaz.

Alıştırma 3: EARS ile Yeniden Yazın

Aşağıdaki iki gereksinimi uygun bir EARS kalıbıyla yeniden yazın:

  1. “Sistem, hasta bilgilerini hızlıca göstermelidir.”
  2. “Doktor hasta kaydını açtığında ilaç alerjileri ve önceki tedaviler görüntülenir ve sistem güvenli olmalıdır.”

İpucu: İkinci cümlede kaç farklı gereksinim var?

Alıştırma 3: Örnek Çözüm

  1. “Doktor bir hasta kaydını açtığında, sistem hasta özet ekranını göstermelidir.” Yanıt süresi hedefi, ölçüleceği yük ve zaman aralığıyla ayrı bir İOG olarak yazılır.
  2. İki gereksinime bölünür:
    • İG: “Doktor bir hasta kaydını açtığında, sistem ilaç alerjilerini ve önceki tedavileri listelemelidir.”
    • İOG: “Sistem, hasta kayıtlarına erişimi yalnızca kimliği doğrulanmış ve yetkili kullanıcılara vermelidir.”

Buradaki ayrımın nedeni cümle sayısı değil, farklı beklentilerin bağımsız olarak doğrulanabilmesidir.

Süreç 3: Gereksinimlerin Geçerlenmesi

Belirlemede yazdığımız metni şimdi paydaşlarla kontrol ederiz: Gereksinimler gerçek ihtiyacı anlatıyor mu, kendi aralarında tutarlı mı, uygulanabilir ve sınanabilir mi?

Ürünün sonradan spesifikasyona uygun yapılıp yapılmadığını sınamak ayrı bir doğrulama işidir. Kitabın bu bölümündeki odak, gereksinimlerin geçerlenmesidir.

Gereksinim Geçerleme Kontrolleri

  • Geçerlilik (Validity): Gereksinimler, kullanıcıların gerçek ihtiyaçlarını yansıtıyor mu?
  • Tutarlılık (Consistency): Gereksinimler arasında bir çelişki var mı?
  • Eksiksizlik (Completeness): Müşterinin istediği tüm işlevler dahil edilmiş mi?
  • Gerçekçilik (Realism): Mevcut bütçe, teknoloji ve zamanla uygulanabilir mi?
  • Doğrulanabilirlik (Verifiability): Gereksinimler objektif olarak test edilebilir mi?
  • İzlenebilirlik (Traceability): Her gereksinimin kaynağı (story, mevzuat, paydaş) belirtilmiş mi? Değişiklik etkisi görülebiliyor mu?
  • Uyarlanabilirlik (Adaptability): Gereksinim, diğerlerini bozup zincir etki yaratmadan değiştirilebilir mi?
  • Anlaşılırlık (Understandability): Gereksinim doğru ve tek anlamlı mı anlaşılır?

Geçerleme Teknikleri

  • Gereksinim İncelemeleri (müşteri + yüklenici)
  • Prototipleme (yürütülebilir model ile erken geri bildirim)
  • Test Durumu Türetme (test edilebilirlik kanıtı)

Gereksinimden Teste İzlenebilirlik (V&V)

  • Gereksinim yazılırken: İnceleme ve prototiplerle ifadenin açık olup olmadığı ve gerçek ihtiyacı karşılayıp karşılamadığı sorgulanır.
  • Ürün geliştirilirken: Birim, entegrasyon ve sistem testleri tanımlanan davranışı; kabul testleri kullanıcı ihtiyacını sınamaya yardımcı olur.
  • Pratik: Her İG için ilgili işlevsel testleri, her İOG için de kendi niteliğine uygun ölçüm veya değerlendirme yöntemini izlenebilir biçimde kaydedin.

Süreç 4: Yönetim (Management)

  • Bağlantı: Geçerleme her sorunu bir seferde bulamaz. Yeni bilgi ve koşullar geldikçe gereksinimler değişir; yönetim, bu değişikliklerin etkisini süreç boyunca izler.
  • Neden Gerekli?: Büyük yazılım sistemleri “çetrefilli” (wicked) sorunları ele aldığından, gereksinimlerin sürekli değişmesi kaçınılmazdır.

Değişen Gereksinimler – Neden?

  • Donanım/entegrasyon değişiklikleri, mevzuat, iş öncelikleri.
  • Müşteri (ödeyen) ≠ kullanıcı (kullanan) gerilimi.
  • Farklı kullanıcı toplulukları ve kaçınılmaz uzlaşma.

Gereksinim Yönetimi Planlaması

  1. Gereksinimlerin Tanımlanması: Her gereksinime benzersiz bir kimlik (ID) atanır.
  2. Değişiklik Yönetimi Süreci: Değişikliklerin nasıl talep edileceği, analiz edileceği ve onaylanacağını tanımlayan bir süreç oluşturulur.
  3. İzlenebilirlik Politikaları (Traceability): Bir gereksinimin diğer gereksinimlerle, tasarım elemanlarıyla ve test senaryolarıyla olan bağlantılarının nasıl takip edileceği belirlenir.
  4. Araç Desteği (Tool Support): Bu süreçleri yönetmek için hangi araçların (Jira, DOORS vb.) kullanılacağına karar verilir.

İzlenebilirlik Matrisi (Özet)

Req ID Kaynak/Story Tasarım Öğesi Test Senaryoları Kod/Modül
FR-APPT-001 US-12 SearchService.v1 TC-APPT-01..04 svc-search/
NFR-PERF-005 NFR-Backlog CacheStrategy-A TC-PERF-01..03 lib-cache/
NFR-SEC-010 Security Spec OAuth2 Gateway Config TC-SEC-01..05 gateway/

Değişiklik Yönetimi Süreci

  1. Problem Analizi ve Değişiklik Spesifikasyonu: Önerilen değişikliğin geçerliliği kontrol edilir.
  2. Değişiklik Analizi ve Maliyetlendirme: Değişikliğin sistem üzerindeki etkisi (ripple effect) ve maliyeti tahmin edilir.
  3. Değişiklik Uygulaması: Değişiklik kabul edilirse, ilgili tüm dokümanlar ve kod güncellenir.

Değişiklik Talep Formu (CR) Örneği

  • CR-ID / Başlık: CR-2026-014 – Randevu Filtreleme Geliştirmesi
  • Gerekçe: Klinik yoğunluk raporlamasında ek filtre ihtiyacı
  • Kapsam Etkisi: FR-APPT-001, NFR-PERF-005
  • Risk/Etki: Cache stratejisinde %10 daha fazla bellek kullanımı
  • Maliyet/Tahmin: 3 adam-gün geliştirme + 1 adam-gün test
  • Karar: (Onay/Red – Tarih – Yetkili)

Bir Değişikliğin Etkisi

CR-2026-014, FR-APPT-001 ve NFR-PERF-005 gereksinimlerini etkiler. Randevu arama servisi ve önbellek stratejisi gözden geçirilir. TC-APPT-01..04 ile TC-PERF-01..03 testleri yeniden değerlendirilir; bellek etkisi ayrıca ölçülür.

Güncel Eğilimler

Yapay Zeka ve Yazılım 2.0

Modern yazılım paradigmaları, gereksinim mühendisliği disiplinine yeni zorluklar ve fırsatlar getirmektedir.

Yapay Zeka (AI/ML) ve Yazılım 2.0

  • Yazılım 2.0: Davranışın kod yerine veriden öğrenen modellerle tanımlandığı sistemlerdir. Odak, veri kümesi kalitesi, veri boru hattı (data pipeline) sağlamlığı ve veri gizliliği gibi gereksinimlere kayar.

DevOps ve SRE Bağlamında İOG’ler

  • Gözlemlenebilirlik (Observability): Monitoring, Logging, Tracing gereksinimleri.
  • SLI/SLO/SLA:
    • SLI (Gösterge): Ölçülen değer, örn. başarılı isteklerin oranı.
    • SLO (Hedef): İç hedef, örn. aylık %99,9.
    • SLA (Sözleşme): Müşteriye verilen taahhüt, örn. aylık ≥ %99,5; ihlalde ceza veya hizmet kredisi.

Özet ve Değerlendirme

Özet

  • Gereksinim türleri: İG sistem davranışını, İOG kalite hedeflerini ve kısıtları tanımlar. Etki alanı kuralları her iki türde gereksinime dönüşebilir.
  • İOG’ler belirsiz hedeflerden ölçülebilir metriklere ve kalite senaryolarına dönüştürülmelidir.
  • Süreç: Keşif, belirleme ve gereksinimlerin geçerlenmesi iç içe ilerler; değişiklik yönetimi bu akışın tamamına eşlik eder.
  • Önceliklendirme (MoSCoW, WSJF) ve müzakere, paydaş çatışmalarını yönetir.
  • SRS ve ürün iş listesi farklı amaçlara hizmet eder; proje ihtiyacına göre birlikte kullanılabilir.
  • İzlenebilirlik ve değişiklik yönetimi, gereksinimden teste ve koda uzanan zinciri korur.
  • Yapay zeka ve DevOps; veri kalitesi, adillik ve gözlemlenebilirlik gibi yeni İOG’ler getirir.

Okuma: Sommerville, Software Engineering, 10. Baskı, Bölüm 4.

Öğrenme Değerlendirmesi

Senaryo: Akıllı Şehir Atık Yönetim Sistemi (AŞAYS)

AŞAYS, akıllı çöp kutularının doluluk oranlarını sensörler aracılığıyla takip ederek, atık toplama rotalarını dinamik olarak optimize edecektir.

Sorular

Soru 1 (İG vs İOG): “Sistem, dinamik rotaları hesaplayıp toplama araçlarına en geç 120 saniye içinde iletmelidir.” Bu bir İşlevsel Gereksinim midir, İşlevsel Olmayan Gereksinim midir? Neden?

Soru 2 (Keşif Tekniği): Eğer bu sistemin başarısızlık durumunda (örneğin bir sensör arızalandığında) saha personelinin gerçekte nasıl tepki verdiğini ve geçici çözümler ürettiğini anlamak istiyorsanız, hangi keşif tekniği (Görüşme, Etnografi, Senaryo) en etkili olur? Açıklayınız.

Soru 3 (Modern Kapsam): Eğer AŞAYS’a, toplanan atıkların türüne göre geri dönüşüm için optimal sıralamayı belirleyen bir Makine Öğrenimi (ML) modülü eklenirse, hangi yeni İşlevsel Olmayan Gereksinim türünü (AI/ML odaklı) dahil etmelisiniz?

Cevap Anahtarı

Soru 1: Cümlede iki ayrı beklenti vardır: rotaları hesaplayıp iletmek bir İG, bunu en geç 120 saniyede yapmak bir performans İOG’sidir. Ayrı yazılmaları, her birinin bağımsız doğrulanmasını kolaylaştırır.

Soru 2: Etnografi. Görüşmede personel kendi geçici çözümlerini dile getirmeyebilir; sahada gözlem, örtük gereksinimleri ortaya çıkarır.

Soru 3: Örneğin adillik/önyargı (bölgelere eşit hizmet), model doğruluğu ve açıklanabilirlik ya da veri kalitesi ve gizliliği. Bu İOG’ler ölçülebilir metriklere bağlanmalıdır (örn. gruplar arası hata oranı farkı ≤ eşik).

Başvuru Kaynakları