Yazılım Mühendisliği

Gereksinim Mühendisliği

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

2026

Giriş

Öğ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 dört sürecini (keşif ve analiz, belirleme, doğrulama ve geçerleme, yönetim) ve aralarındaki ilişkiyi 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 birikimi yaklaşımlarının hangi koşullarda uygun olduğunu 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, “Ne inşa edeceğiz?” ve “Hangi kurallar çerçevesinde inşa edeceğiz?” sorularını sistemli biçimde yanıtlama sürecidir. Geliştirilecek sisteme ilişkin ortak bir anlayış oluşturur.

Süreç iki şeyi ortaya koyar:

Hizmetler (Ne yapacak?): Sistemin sunacağı özellikler, yerine getireceği görevler ve karşılayacağı kullanıcı ihtiyaçları.
Kısıtlamalar (Hangi kurallara uyacak?): Performans, güvenlik, bütçe, teslimat süresi gibi projenin uymak zorunda olduğu sınırlar ve standartlar.

Bu sürecin çıktısı gereksinimlerdir; geliştirme ve değerlendirme sırasında başvurulacak ortak çerçeveyi oluştururlar.

Gereksinim (Requirement) Nedir?

Bir projenin en başındaki genel bir fikirden (“kullanıcı dostu bir sistem”), geliştiricinin kod yazabileceği teknik bir detaya (“giriş butonu 300ms içinde tepki vermeli”) kadar uzanan tanımlardır.

Pratikte bu terim iki farklı düzeyde kullanılır:

Teklif aşamasında: Yoruma açık, genel bir çerçeve sunar.
Sözleşme aşamasında: Uygulama için detaylı ve net bir tanım içerir.

Soyutlama Seviyeleri ve Paydaşlar

Davis’in Soyutlama Yaklaşımı: Büyük projelerde, çözümün önceden tanımlanmaması için ihtiyaçlar başlangıçta soyut olmalıdır. Sözleşme imzalandıktan sonra ise, doğrulama ve geliştirme için daha ayrıntılı bir tanım yazılmalıdır.

Kullanıcı ve Sistem Gereksinimleri

Bu iki seviye, gereksinimleri farklı paydaş grupları için ayırır:

Kullanıcı Gereksinimleri: Sistemin son kullanıcıları ve müşteriler için doğal dilde ve şemalarla yazılmış, genel hizmet ve kısıtlamaları tanımlayan ifadelerdir.
Sistem Gereksinimleri: Sistemin işlevlerinin, hizmetlerinin ve operasyonel kısıtlamalarının ayrıntılı açıklandığı, yapılandırılmış bir belgedir. Geliştiriciler için yazılır ve yüklenici ile müşteri arasındaki sözleşmenin bir parçası olabilir.

Farklı Gereksinimlerin Okuyucuları

Gereksinim belgeleri, farklı rollere ve beklentilere sahip paydaşlar tarafından okunur.

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.

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

Gereksinim mühendisliği sürecinin başında, projenin hayata geçirilip geçirilmeyeceğine karar vermek için yapılan kısa ve odaklı bir çalışmadı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ı

Eğer bu sorulardan herhangi birinin cevabı “hayır” ise, projeye devam etmek risklidir.

Gereksinim Türleri

Örnek Vaka: AS-HYS

Akıl Sağlığı Hasta Yönetim Sistemi (AS-HYS), ruh sağlığı kliniklerinde hasta kayıtlarını, randevuları ve tedavi bilgilerini yöneten bir bilgi sistemidir.

Bu dersteki örneklerin çoğu bu vakadan gelir. Sistemi Sistem Modelleme dersinde ayrıntılı inceleyeceğiz.

Gereksinim Türlerine Genel Bakış

İ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 klinikler için randevu listelerini arayabilmelidir.”

Belirsizlik, Eksiklik ve Tutarsızlık

Belirsizlik: “arama” gibi terimler, kullanıcı ve geliştirici tarafından farklı yorumlanabilir. Bu durum, teslimat sonrası anlaşmazlıklara ve maliyet artışına yol açar.
Eksiklik ve Tutarsızlık: Büyük sistemlerde, tüm işlevleri kapsayan (eksiksiz) ve kendi içinde çelişmeyen (tutarlı) bir gereksinim belgesi hazırlamak güçtür.

İş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; kontrast ≥ 4.5: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ığı

Ölçülebilir İOG Örnekleri

Hizmet sürekliliği (Availability): Aylık ≥ %99,5; planlı bakım toplamı ≤ 2 saat/ay.
Security: Tüm PII (kişisel tanımlanabilir bilgi) alanları AES-256 ile at-rest; TLS 1.3 in-transit.
Maintainability: Her servis için CC ≤ 10 (ortalama döngüsel karmaşıklık); lint hatası = 0.
Accessibility (Erişilebilirlik): Ana akış sayfalarında WCAG 2.2 AA ihlali = 0 (axe-core taraması).

Örnekler: Hizmet Sürekliliği

Bu metrikler, soyut hedefleri (“güvenli olsun”) somut mühendislik görevlerine (“AES-256 kullan”) dönüştürür.

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.

Security (Güvenlik):
- AES-256 at-rest: Veritabanı çalınsa bile, içindeki kişisel veriler (at-rest: diskte dururken) endüstri standardı AES-256 ile şifrelendiği için okunamaz olmalıdır.
- TLS 1.3 in-transit: Veri, kullanıcının tarayıcısından sunucuya giderken (in-transit: hareket halindeyken) ağ trafiğini dinleyenler tarafından okunamasın diye modern TLS 1.3 protokolü ile şifrelenmelidir.

Ö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 ihlali = 0: Sistem, engelli kullanıcıların da rahatça kullanabilmesi için uluslararası kurallara (renk kontrastı, klavye ile kullanım vb.) uymalıdır.

Kalite Özelliği Senaryosu: Hedeften Teste

Metrik tek başına yetmez: kim, hangi koşulda, neyi yaparken ölçüleceği de belli olmalıdır. Kalite özelliği senaryosu bunu altı parçada yazar.

Belirsiz hedef: “Randevu arama hızlı olmalıdır.”

Parça	Sorduğu soru	AS-HYS örneği
Kaynak (Source)	Kim başlatıyor?	Resepsiyon görevlisi
Uyarıcı (Stimulus)	Sisteme ne oluyor?	Aynı klinik için 1 dakikada 50 arama
Ortam (Environment)	Hangi koşulda?	Yoğun saat (09:00-10:00), üretim
Eser (Artifact)	Sistemin hangi parçası?	Randevu arama uç noktası
Tepki (Response)	Sistem ne yapar?	Sonuçları döndürür ve loglar
Ölçüt (Measure)	Başarı nasıl ölçülür?	p95 yanıt süresi ≤ 300 ms, hata oranı ≤ %1

Senaryoyu Okumak: Kim, Neyi, Nerede?

Bir önceki tablodaki ilk dört parça, testin koşullarını netleştirir:

Kaynak & Eser (Kim, Neyi?): Resepsiyon görevlisi, sistemin randevu arama özelliğini kullanıyor. Testin odağı netleşir.
Uyarıcı & Ortam (Nasıl ve Nerede?): Tek bir arama değil, 1 dakikada 50 arama gibi bir stres yükü altında ve en yoğun saatteki üretim ortamında test edilir; böylece gerçek dünya performansı ölçülür.

Senaryoyu Okumak: Tepki ve Ölçüt

Son iki parça, testin geçme koşulunu belirler:

Tepki (Ne Olmalı?): Sistemin sadece çökmemesi değil, beklenen işlevi (sonuçları döndürme) doğru bir şekilde yerine getirmesi gerekir.
Ölçüt (Başarı Nedir?):
- p95 yanıt süresi ≤ 300 ms: “Yapılan 100 isteğin 95 tanesi 300 milisaniyeden hızlı olmalı” demektir. Ortalama yerine p95 (95. persentil) kullanmak, isteklerin büyük bölümündeki yanıt süresini görmemizi sağlar.
- hata oranı ≤ %1: Yoğun yük altında bile sistemin hata verme payının en fazla %1 olabileceğini belirtir. %100 başarı her zaman gerçekçi bir hedef değildir.

Aynı sayılar, Kabul Kriteri Örnekleri slaytında NFR-PERF-005 olarak yeniden karşımıza çıkacak.

Etki Alanı Gereksinimleri

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

FR-APPT-001 (Randevu Listesi)
- Seçilen tek klinik ve tek gün için randevular listelenir.
- İptal/ertelenen randevular hariç tutulur.
- Liste saat alanına göre artan sıralıdır.
NFR-PERF-005 (Performans)
- Randevu arama uç noktasında p95 yanıt süresi ≤ 300 ms, hata oranı ≤ %1 (yoğun saatte, 1 dakikada 50 arama).

NFR-SEC-010 (Güvenlik)
- Tüm API uçları OAuth2 ile korunur.
- Yetkisiz erişim girişimi loglanır ve 30 gün saklanır.
NFR-OBS-020 (Gözlemlenebilirlik)
- Tüm istekler için correlation-id üretilir, loglanır.
- Temel metrikler (QPS, p95, hata oranı) 3 graf ile izlenir.
NFR-ML-030 (Adillik/Fairness)
- Modelin iki demografik grup arasındaki False Positive Rate farkı ≤ 0.05.

Alıştırma 1: Belirsiz Hedefi Ölçülebilir Yazın

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

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

Sıra sizde (3 dk, ikili çalışın):

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

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

Ölçütler: Her kayıt erişimi kimlik doğrulaması gerektirir; yetkisiz erişim girişimlerinin %100’ü loglanır; oturum 15 dakika hareketsizlikte kapanır.
Senaryo: Kaynak: yetkisiz kullanıcı · Uyarıcı: başka bir kliniğin hasta kaydını açma girişimi · Ortam: normal çalışma · Eser: hasta kaydı servisi · Tepki: erişim reddedilir ve olay loglanır · Ölçüt: ret yanıtı en geç 1 sn, loglanan girişim oranı %100.
Tetiklenen İG’ler: kimlik doğrulama, rol tabanlı yetkilendirme, denetim kaydı, oturum zaman aşımı.

Gereksinim Mühendisliği Süreçleri

Süreçlere Genel Bakış

Gereksinim mühendisliği, birbiriyle iç içe geçmiş, yinelemeli (iterative) bir süreçtir. Genellikle bir sarmal (spiral) model olarak görselleştirilir.

Ana faaliyetler şunlardır:

Keşif (Elicitation) ve Analiz: Paydaşlarla etkileşim kurularak ihtiyaçların anlaşılması ve analiz edilmesi.
Belirleme (Specification): Anlaşılan gereksinimlerin standart bir formatta yazılması ve belgelenmesi.
Doğrulama ve Geçerleme (V&V): Gereksinimlerin doğru ve eksiksiz olduğunun, müşterinin gerçek ihtiyacını karşıladığının kontrol edilmesi.
Yönetim (Management): Geliştirme süreci boyunca ortaya çıkan değişikliklerin yönetilmesi.

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.
Etik Yöneticisi	Sistem tüm yasalara (KVKK) %100 uysun.	Yasal kurallar, bazı pratik özelliklerin eklenmesini engelleyebilir.

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:

Bilgi Toplama (Discovery): Paydaşlarla konuşarak, gözlemleyerek ham bilgiyi toplama.
Sınıflandırma: Yüzlerce farklı isteği anlamlı gruplara ayırma.
Önceliklendirme & Müzakere: En önemli ve acil olanları belirleme ve çatışmaları çözme.
Belirleme: Anlaşılan konuları net bir şekilde yazıya dökme.

Bu Süreç Neden Zordur?

Paydaşlar ne istediklerini bilmeyebilir: Henry Ford’a atfedilen söze göre: “İnsanlara ne istediklerini sorsaydım, daha hızlı atlar isterlerdi.”
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örler ile sistem arasındaki etkileşimleri modelleyen UML tabanlı teknik.	Sistem davranışını formal olarak modellemek.
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

Toplanan gereksinimleri önem ve aciliyetlerine göre sıralamak için farklı yöntemler kullanılır.

Yöntem 1: MoSCoW

Must have, Should have, Could have, Won’t have (this time) - Must (Olmazsa Olmaz): Bunlar olmadan sistemin bir anlamı yok. Ö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: (İş Değeri + Zaman Kritikliği + Risk Azaltma) / Efor
Amaç: “En az eforla en çok değeri” getiren işi bulmaktır (SAFe çerçevesinden).
Örnek: A özelliği: (8 + 3 + 2) / 5 = 2,6. B özelliği: (5 + 2 + 1) / 1 = 8. B önce yapılır; çünkü değeri daha düşük olsa da çok daha ucuzdur.

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	Efor
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

Sıra sizde (3 dk): Her özelliğin WSJF puanını hesaplayın, sıralayın ve MoSCoW etiketi verin.

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 yasal ve güvenlik zorunluluğu nedeniyle Must’tır; WSJF yalnızca sıralamayı belirler.

Ç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)

Bu süreç, keşfedilen gereksinimlerin Yazılım Gereksinimleri Belgesi (SRS - Software Requirements Specification) içine yazılmasını içerir.

Modern Yaklaşım: SRS vs. Ürün Birikimi (Product Backlog)

Geleneksel SRS: Kapsamlı, sözleşmeye dayalı ve genellikle yavaş değişen (kritik, büyük) sistemler için kullanılır. (Bkz. ISO/IEC/IEEE 29148 Standardı)
Çevik Yöntemler ve Ürün Birikimi: Gereksinimlerin çok hızlı değiştiği durumlarda, detaylı SRS zaman kaybı olarak görülür. Bunun yerine, önceliklendirilmiş özelliklerin ve kullanıcı hikayelerinin tutulduğu canlı bir doküman olan Ürün Birikimi (Product Backlog) kullanılır.

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: daha az ayrıntı, canlı ürün birikimi (backlog) desteği.
Kritik/büyük sistem: yüksek ayrıntı düzeyi, standart (ISO/IEC/IEEE 29148) uyumu.

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: Zorunlulukları belirtmek için standart fiiller kullanın (shall: zorunlu, should: tercihen, may: isteğe bağlı; Türkçede sırasıyla “-malıdır”, “-ması tercih edilir”, “-abilir”). Must yalnızca düzenleyici/yasal zorunluluklar için kullanılmalıdır.
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

Tek gereksinim = tek cümle, benzersiz kimlik (ID).
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ı.
Matematiksel Özellikler: resmi (FSM/kümeler) — doğruluk ↑, anlaşılabilirlik ↓.

EARS Kalıpları

EARS (Easy Approach to Requirements Syntax), gereksinimi birkaç sabit cümle kalıbıyla yazmayı öğretir:

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.”
İyi (olay güdümlü): “Resepsiyon görevlisi randevu araması yaptığında, sistem sonuç listesini en geç 300 ms içinde (p95) döndürmelidir.”
Kötü: “Kullanıcı kolayca giriş yapar.”
İyi (olay güdümlü): “Kullanıcı geçerli kimlik bilgilerini girdiğinde, sistem oturumu en geç 2 saniye içinde açmalıdır.”

Yapılandırılmış Özellik Örneği (Tıbbi Cihaz)

Süreç Modelleri dersindeki insülin pompası senaryosunu hatırlayın.

Fonksiyon: Kan şekeri ölçümü ve doz iletimi
Girdi: sensör_glukoz, önceki_ölçümler
Çıktı: insülin_dozu
Önkoşul: cihaz çevrimiçi
Sonkoşul: doz iletildi ve loglandı
Kısıt: ölçüm aralığı 10±1 dk

Tablo Spesifikasyonu (Özet)

Durum	Aksiyon
Glukoz düşüyor / sabit	`insülin_dozu = 0`
Glukoz artıyor, artış hızı ↓	`insülin_dozu = 0`
Glukoz artıyor, artış hızı sabit/artan (Δ: son iki ölçüm farkı)	`insülin_dozu = round(Δ/4)`; sonuç 0 ise `MinDose`

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

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

“Sistem, hasta bilgilerini hızlıca göstermelidir.”
“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

“Doktor bir hasta kaydını açtığında, sistem hasta özet ekranını en geç 2 saniye içinde (p95) göstermelidir.”
İ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.”

“Tek gereksinim = tek cümle” ilkesi, İG ve İOG’nin karışmasını da önler.

Süreç 3: Doğrulama ve Geçerleme (V&V)

Önemi: Geliştirme sonrasında fark edilen bir gereksinim hatasını düzeltmek, bir kodlama hatasını düzeltmekten genellikle çok daha pahalıdır (literatürde sıkça on ila yüz kat denir).
V&V Ayrımı:
- Verification (Doğrulama): “Ürünü doğru mu inşa ettik?” (Spesifikasyonlara uygunluk)
- Validation (Geçerleme): “Doğru ürünü mü inşa ettik?” (Müşteri ihtiyacını karşılama)

Gereksinim Doğrulama 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?

Doğrulama 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ı)

SRS’ten Teste İzlenebilirlik (V&V)

Verification (Doğrulama): Birim/Entegrasyon/Sistem Testleri → “Spesifikasyonları doğru uyguladık mı?”
Validation (Geçerleme): Kabul Testleri / UAT → “Müşterinin istediği doğru şeyi mi yaptık?”
Pratik: Her İşlevsel Gereksinim (İG) için en az bir işlevsel test senaryosu, her İşlevsel Olmayan Gereksinim (İOG) için en az bir ölçülebilir performans/güvenlik/vb. testi yazılmalıdır.

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

Tanım: Sistem geliştirme sürecinde ve sistem kullanıma alındıktan sonra değişen gereksinimleri yönetme sürecidir.
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ı

Gereksinimlerin Tanımlanması: Her gereksinime benzersiz bir kimlik (ID) atanır.
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.
İ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.
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

Problem Analizi ve Değişiklik Spesifikasyonu: Önerilen değişikliğin geçerliliği kontrol edilir.
Değişiklik Analizi ve Maliyetlendirme: Değişikliğin sistem üzerindeki etkisi (ripple effect) ve maliyeti tahmin edilir.
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)

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.
Dört süreç: keşif ve analiz, belirleme, doğrulama ve geçerleme, yönetim; hepsi yinelemelidir.
Önceliklendirme (MoSCoW, WSJF) ve müzakere, paydaş çatışmalarını yönetir.
SRS büyük ve kritik sistemlerde, ürün birikimi hızlı değişen projelerde öne çıkar.
İ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ümle iki gereksinimi birleştirir: “rotaları hesaplayıp iletmek” bir İG, “en geç 120 saniye” ise bir performans İOG’sidir. “Tek gereksinim = tek cümle” ilkesi gereği ikiye ayrılmalıdı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).