Kazanimlar:
- Fonksiyonel ve fonksiyonel olmayan gereksinimleri ayırt edip yapay zeka desteğiyle net, ölçülebilir gereksinim ifadeleri yazabilme
- Görüşme notlarından kullanıcı hikayesi, kabul kriteri ve kapsam sınırı çıkarmada yapay zekayı yapılandırılmış promptlarla kullanabilme
- AI ile üretilen gereksinimleri belirsizlik, çelişki ve eksik kural açısından denetleyip paydaşla teyit etme alışkanlığı edinme
Gereksinim analizi, bir sistemin ne yapması gerektiğini eksiksiz, net ve doğrulanabilir biçimde tanımlama işidir. YBS uzmanının en çok değer ürettiği aşamalardan biridir; çünkü buradaki bir hata, projenin sonunda katlanarak büyür. Gereksinim analizinde iki temel tür vardır. Fonksiyonel gereksinim, sistemin yapması gereken işi anlatır: "Sistem, siparişi onayladığında müşteriye e-posta göndermelidir." Fonksiyonel olmayan gereksinim (İngilizce non-functional requirement) ise sistemin nasıl olması gerektiğini anlatır: performans, güvenlik, kullanılabilirlik, erişilebilirlik gibi nitelikler. "Rapor ekranı ortalama yükte 2 saniyeden kısa sürede açılmalıdır" bir fonksiyonel olmayan gereksinimdir.
İyi bir gereksinim üç özelliği taşır: net (tek yorumu vardır), ölçülebilir (test edilebilir bir eşiği vardır) ve izlenebilir (hangi iş ihtiyacından geldiği bellidir). "Sistem hızlı olmalı" bunların hiçbirini karşılamaz; "hızlı" özneldir, ölçülemez, test edilemez. Yapay zeka bu aşamada gereksinimleri taslaklaştırmada ve muğlak ifadeleri yakalamada güçlü bir yardımcıdır; ama hangi iş kuralının gerçek olduğuna yalnızca paydaş karar verir.
Kullanıcı Hikayesi ve Kabul Kriteri
Modern gereksinim yazımında sık kullanılan bir format kullanıcı hikayesidir (İngilizce user story): "Bir [rol] olarak, [amaç] için, [özellik] istiyorum." Örnek: "Bir satış temsilcisi olarak, sahada hızlı teklif verebilmek için, mobil ekrandan indirim hesaplaması istiyorum." Hikaye kısa ve iş odaklıdır; teknik çözümü dayatmaz.
Her hikayenin bir kabul kriteri (İngilizce acceptance criteria) olmalıdır: hikayenin "tamam" sayılması için sağlanması gereken, test edilebilir koşullar. Sık kullanılan bir kalıp "Verilen / Olduğunda / O zaman" (İngilizce Given/When/Then) kalıbıdır: "Verilen: müşteri VIP segmentinde. Olduğunda: 10.000 TL üzeri sipariş verir. O zaman: sistem %5 indirim uygular." Bu kalıp belirsizliği ortadan kaldırır, çünkü koşulu ve beklenen sonucu net bağlar.
Ipucu: Yapay zekaya kullanıcı hikayesi yazdırırken mutlaka "her hikaye için Given/When/Then formatında en az 2 kabul kriteri üret" deyin. Model kriter üretmeye zorlandığında, gereksinimdeki gizli boşluklar görünür hale gelir.
Adım Adım: AI Destekli Gereksinim Çıkarımı
Adım 1 — Ham girdiyi topla. Görüşme kayıtları, e-postalar, mevcut ekran görüntüleri, şikayet listeleri. Ne kadar çok gerçek girdi, o kadar az uydurma.
Adım 2 — İlk hikaye setini çıkart. Yapay zekaya ham girdiyi verip kullanıcı hikayesi taslakları ürettir. Bu aşama tam liste değil, ilk çırpıdır.
Adım 3 — Kabul kriteri ekle. Her hikaye için Given/When/Then kriterleri ürettir. Kriter üretilemeyen hikaye, aslında yeterince tanımlanmamış demektir.
Adım 4 — Çelişki ve boşluk taraması. Yapay zekaya "bu gereksinimler arasında çelişki, tekrar veya tanımsız durum var mı?" diye sorup denetlet. Sonucu insan olarak süz.
Adım 5 — Önceliklendir ve teyit et. Hikayeleri iş değeri ve aciliyete göre paydaşla önceliklendir. Öncelik kararı iş biriminindir, AI'nin değil.
Fonksiyonel Olmayan Gereksinimleri Unutmayın
Projelerin çoğu, fonksiyonel gereksinimler yazılırken fonksiyonel olmayanları unuttuğu için sahada zorlanır. Bir rapor "doğru" çalışabilir ama 45 saniyede açılıyorsa kimse kullanmaz. Aşağıdaki tablo, sık atlanan fonksiyonel olmayan gereksinim türlerini ve ölçülebilir yazım örneklerini gösterir.
Tür
Kötü ifade
Ölçülebilir ifade
Performans
"Hızlı olmalı"
"Ortalama yükte sorgu yanıtı < 2 sn"
Erişilebilirlik
"Herkes kullanabilmeli"
"WCAG 2.1 AA uyumlu; klavyeyle tam gezinilebilir"
Güvenlik
"Güvenli olmalı"
"Kişisel veri dinlenmede şifreli; erişim rol bazlı"
Kullanılabilirlik
"Kolay olmalı"
"Yeni kullanıcı eğitimsiz siparişi 3 adımda tamamlar"
Kullanılabilirlik/süreklilik
"Çökmemeli"
"Aylık çalışma süresi ≥ %99,5"
Üç Mini Vaka: Rakamlarla
Vaka 1 — Ölçülemeyen gereksinimin bedeli. Bir bankada "rapor ekranı hızlı açılmalı" gereksinimiyle geliştirilen ekran, saha yükünde 22 saniyede açılıyordu. Geliştirici "hızlı" sözünü kendi ortamında (2 saniye) sağladığını düşünüyordu. Gereksinim "en yoğun saatte, gerçek veri hacminde < 3 sn" diye yazılsaydı, sorun testte yakalanacaktı. Yeniden geliştirme 3 haftaya ve ölçülebilir ek maliyete mal oldu.
Vaka 2 — Kabul kriteriyle yakalanan boşluk. Bir e-ticaret projesinde "sistem indirim uygular" hikayesine kabul kriteri yazılırken paydaş, indirimin kupon ve VIP indirimiyle çakışması durumunda ne olacağının hiç konuşulmadığını fark etti. Tek bir Given/When/Then sorusu, canlıya çıkıştan önce çift indirim hatasını önledi; bu hata benzer projelerde ciddi gelir kaybı yaratmıştı.
Vaka 3 — AI'nin uydurduğu kural. Bir İK projesinde yapay zeka, gereksinim taslağına "izin talebi 24 saat içinde otomatik onaylanır" cümlesini ekledi. Görüşmede böyle bir otomatik onay konuşulmamıştı; model "makul" görünen bir kuralı uydurmuştu. Uzman, her gereksinimin yanına "kaynak: hangi görüşme/belge?" sütunu ekleterek kaynaksız 4 cümleyi ayıkladı.
Zayıf Prompt / Güçlü Prompt
Zayıf prompt:
Bu projeye kullanıcı hikayeleri yaz.
Güçlü prompt:
Rolün: YBS iş analistisin.Aşağıdaki görüşme notundan kullanıcı hikayeleri çıkar.Kurallar:- Format: "Bir [rol] olarak, [amaç] için, [özellik] istiyorum."- Her hikaye için Given/When/Then formatında EN AZ 2 kabul kriteri yaz.- Her hikayenin yanına "Kaynak" sütunu ekle: hangi cümleden çıktı?- Notta net olmayan her kuralı [BELİRSİZ] etiketle; uydurma.- Fonksiyonel olmayan gereksinimleri (performans, güvenlik, erişilebilirlik) ayrı bir bölümde ölçülebilir yaz.Görüşme notu:[metin]
Güçlü prompt hikaye formatını, kabul kriterini, kaynak izlenebilirliğini ve fonksiyonel olmayan gereksinimleri tek seferde zorunlu kılar; böylece çıktının denetimi kolaylaşır.
Dört Kopyalanabilir Şablon
1) Gereksinim netleştirme:
Aşağıdaki gereksinimi incele. Belirsiz, ölçülemez veya birden fazlayoruma açık her ifadeyi işaretle ve her biri için netleştirici birsoru yaz. Cevabı sen uydurma. Gereksinim: [metin]
2) Çelişki taraması:
Aşağıdaki gereksinim listesinde birbiriyle çelişen, tekrar eden veyamantıksal boşluk bırakan maddeleri bul. Her bulguyu madde numaralarıylave tek cümlelik gerekçeyle raporla. Liste: [metin]
3) Kabul kriteri üretme:
Aşağıdaki kullanıcı hikayesi için Given/When/Then formatında, sınırve istisna durumlarını da kapsayan en az 4 kabul kriteri yaz. Belirsizkalan noktaları ayrıca listele. Hikaye: [metin]
4) Kapsam sınırı (scope) taslağı:
Aşağıdaki gereksinimlere göre "Kapsam İçinde" ve "Kapsam Dışında"maddelerini iki sütunlu bir tablo olarak taslaklaştır. Emin olmadığınher maddeyi [TEYİT GEREKLİ] etiketle. Gereksinimler: [metin]
Sık yapılan hatalar
- Çözümü gereksinim sanmak. "Bir açılır menü ekleyin" bir çözümdür, gereksinim değil. Gereksinim "kullanıcı ülkeyi tanımlı listeden seçebilmeli" der; çözümü BT ekibi tasarlar.
- Fonksiyonel olmayanları atlamak. Sadece "ne yapacağını" yazıp "nasıl olacağını" (hız, güvenlik, erişilebilirlik) unutmak, en sık görülen ve en pahalı boşluktur.
- Ölçülemez sıfatlar kullanmak. "Hızlı, kolay, güvenli, kullanıcı dostu" gibi kelimeler eşik olmadan geçersizdir.
- AI'nin uydurduğu kuralı fark etmemek. Model "makul" ama gerçekte konuşulmamış kurallar ekleyebilir; her gereksinime kaynak isteyin.
- Önceliklendirmeyi AI'ye bırakmak. Neyin önce yapılacağı iş değeri kararıdır; bunu iş birimi verir.
Dikkat: Gereksinim analizinde en tehlikeli cümle "bunu herkes zaten biliyor"dur. Söylenmeyen varsayımlar dokümana geçmez, koda hiç geçmez ve sahada ortaya çıkar. AI'ye "bu gereksinimde varsayılan ama yazılmamış ne var?" diye sordurmak bu gizli varsayımları görünür kılar.
Özetle
Gereksinim analizi sistemin ne yapması gerektiğini net, ölçülebilir ve izlenebilir biçimde tanımlar. Fonksiyonel gereksinimler işi, fonksiyonel olmayanlar nitelikleri anlatır ve ikincisi sık unutulur. Kullanıcı hikayesi ile Given/When/Then kabul kriteri, belirsizliği ortadan kaldıran güçlü araçlardır. Yapay zeka hikaye taslakları, kabul kriterleri, çelişki taraması ve netleştirici sorular üretmede ciddi hız kazandırır; ancak iş kuralının doğruluğu, kapsam ve öncelik kararı ile her cümlenin kaynağı insanın sorumluluğundadır. Kaynaksız ve ölçülemez hiçbir gereksinimi kesinleştirmeyin.
Uygulama görevi
Hayali bir "çevrimiçi randevu sistemi" için tek paragraflık bir iş isteği yazın (ör. "Danışanlar internetten randevu alabilmeli, personel takvimi görebilmeli"). (1) Bu istekten güçlü promptla en az 5 kullanıcı hikayesi ve her biri için 2 kabul kriteri ürettirin. (2) Modelin ürettiği kriterlerde en az 2 gizli boşluk bulun (ör. aynı saate çift randevu, iptal kuralı). (3) En az 3 fonksiyonel olmayan gereksinimi ölçülebilir biçimde ekleyin. (4) "Kapsam Dışında" olarak en az 3 madde tanımlayın. (5) Modelin uydurmuş olabileceği bir kuralı işaretleyip nasıl teyit edeceğinizi yazın.
Kontrol listesi
- [ ] Fonksiyonel ve fonksiyonel olmayan gereksinimleri ayrı yazdım.
- [ ] Her gereksinim net, ölçülebilir ve test edilebilir.
- [ ] Her hikayenin Given/When/Then kabul kriteri var.
- [ ] Her gereksinimin kaynağını (görüşme/belge) izleyebiliyorum.
- [ ] AI'nin uydurduğu olası kuralları işaretleyip teyide bıraktım.
- [ ] Önceliklendirmeyi iş birimiyle birlikte yaptım.