Gereksinim toplama ve kullanıcı hikayesi yazımında yapay zekayı kullanmak

Yapay zeka gereksinim analizinde neyi değiştirir, neyi değiştirmez?

Gereksinim analizi, paydaşların ihtiyacını yazılı, test edilebilir ve izlenebilir ifadelere dönüştürme işidir. Bu işin zaman alan kısmı çoğunlukla yazım ve düzenlemedir: görüşme notlarını temize çekmek, tekrar eden talepleri birleştirmek, tutarsızlıkları bulmak, kullanıcı hikayelerini ve kabul kriterlerini biçime sokmak. Büyük dil modelleri tam da bu tür metin işlerinde hızlandırıcıdır.

Değişmeyen kısım ise sorumluluktur. Doğru soruyu doğru kişiye sormak, söylenmeyeni sezmek, çelişen taleplerde taraflar arasında arabuluculuk yapmak, bir gereksinimin iş değerini tartmak analistin işidir. Model, toplantıda olmadı; kurumun bağlamını, politik dengelerini, teknik kısıtlarını bilmez. Eksik bilgiyi makul görünen uydurmalarla tamamlayabilir ve bu, gereksinim dokümanında en pahalı hata türlerinden biridir.

Pratik ilke: yapay zeka taslak üretir, analist karar verir. Model çıktısı her zaman bir paydaşla doğrulanmadan 'gereksinim' sayılmaz. Bu ilkeyi benimseyen analistler, zamanlarını yazım işinden doğrulama ve paydaş görüşmesine kaydırır.

Adım adım: ham notlardan gereksinim listesine

Verimli bir akış şu aşamalardan oluşur.

Bağlamı hazırlayın. Modele yalnız metni vermek yerine projenin amacını, kullanıcı rollerini, kapsamı ve kapsam dışını kısa bir giriş paragrafıyla verin. Bağlam ne kadar net olursa çıktı o kadar isabetli olur.

Ham notları temizleyin. Toplantı transkripti ya da el notları üzerinde ilk işlem, konuşmacıları ve konu başlıklarını ayırmaktır. Model, dağınık notlardan 'talep', 'kısıt', 'varsayım', 'açık soru' ayrımı yapabilir.

Gereksinim taslağı çıkarın. Her talebi tek bir gereksinim cümlesine indirgetin: 'Sistem … yapabilmelidir' gibi. Fonksiyonel ve fonksiyonel olmayan gereksinimleri ayrı listelemesini isteyin.

Boşlukları sorgulatın. 'Bu notlarda yanıtlanmamış hangi sorular var, hangi gereksinimler belirsiz?' diye sormak, görüşme sonrası yeni bir tura girmeden eksikleri listelemenin iyi yoludur.

Çakışmaları bulun. Farklı paydaşların talepleri arasında çelişki varsa modelden bunları gerekçeleriyle birlikte işaretlemesini isteyin. Karar yine analiste ve paydaşlara aittir.

Çıktıyı sabit bir şablonda alın: kimlik numarası, açıklama, kaynak, öncelik önerisi, açık soru. Şablonlu çıktı, izlenebilirlik matrisine aktarımı kolaylaştırır.

Kullanıcı hikayesi yazmak

Kullanıcı hikayesi, bir ihtiyacı kullanıcının gözünden anlatan kısa bir cümledir. Yaygın kalıp: 'Bir [rol] olarak, [amaç] istiyorum, böylece [fayda] sağlayabilirim.' Bu kalıbın en önemli parçası 'böylece' kısmıdır; fayda yazılamıyorsa gereksinim sorgulanmalıdır.

Modeli kullanırken şu yönlendirmeler işe yarar: • Rolü belirtin. 'Muhasebe uzmanı', 'saha satış temsilcisi', 'sistem yöneticisi' gibi gerçek roller verin; 'kullanıcı' sözcüğü çıktıyı genelleştirir. • Hikâyenin küçük olmasını isteyin. Büyük bir ihtiyaç (destansı hikâye) tek hikâyede kalamaz; modelden parçalamasını isteyin. • INVEST ölçütlerini kontrol listesi olarak verin: bağımsız, pazarlığa açık, değerli, kestirilebilir, küçük, test edilebilir. Modelden her hikâyeyi bu ölçütlerle değerlendirmesini isteyin. • Her hikâye için kabul kriterlerini ayrı üretin. Kabul kriterleri, hikâyenin tamamlandığını gösteren gözlemlenebilir koşullardır. 'Verilen-Olduğunda-Ise' (Given-When-Then) biçimi test edilebilirlik sağlar.

Örneğin 'saha satış temsilcisi, ziyaret notunu çevrimdışıyken kaydedebilmek ister' hikâyesi için kabul kriterleri bağlantı kopukken kayıt, bağlantı gelince eşitleme ve çakışma durumunu ele almalıdır. Modelin ilk taslağında çakışma senaryosu çoğu zaman eksik gelir; bu eksiği yakalamak analistin işidir.

Doğrulama: yapay zeka çıktısına güvenmeden kullanmak

Model çıktısının ağır riski, ikna edici ama yanlış olmasıdır. Doğrulama için sistematik bir yöntem kullanın.

Kaynağa bağlayın. Her gereksinimin hangi görüşmeden ya da dokümandan geldiğini yazdırın. Kaynağı gösterilemeyen gereksinim, uydurma şüphesi taşır.

Uydurma tespiti yapın. Çıktıyı ham notlarla yan yana koyup 'bu gereksinim notlarda geçiyor mu?' kontrolü yapın. Özellikle sayısal eşikler, ad ve tarihler gibi somut ifadeler dikkat ister.

Paydaşa geri götürün. Hazırlanan taslak, ilgili paydaşa 'doğru anladık mı?' sorusuyla sunulur. Onay alınmayan madde taslakta kalır.

Gizliliği gözetin. Müşteri adı, kişisel veri ya da ticari sır içeren notları kurumun onaylamadığı araçlara yüklemeyin. Kişisel verileri maskeleyin ve kurumun yapay zeka kullanım politikasını izleyin.

Tutarlılığı test edin. Aynı girdiyi farklı yönlendirmelerle verip çıktıları karşılaştırmak, modelin kararsız kaldığı noktaları gösterir; bu noktalar genellikle girdinin belirsiz olduğu yerlerdir.

İzlenebilirlik kaydını insan tutar. Gereksinim, hikâye, test ve sürüm bağını yapay zeka yerine analistin sorumluluğunda yönetin.

Örnek iş akışı: fatura onay süreci için gereksinim paketi

Örneğin bir iş analisti, kurum içi fatura onay sürecini dijitalleştirecek bir proje için farklı birimlerle görüşme yaptı: muhasebe, satın alma ve birim yöneticileri. Elinde karışık görüşme notları var.

Önce analist modele proje amacını, kullanıcı rollerini ve kapsam dışı konuları anlatır. Sonra notları verir ve talepleri 'fonksiyonel', 'fonksiyonel olmayan' ve 'kısıt' diye sınıflandırmasını ister. Model, onay limiti, vekil atama ve denetim izi gibi başlıklar çıkarır.

Sonra analist modelden çelişkileri işaretlemesini ister. Muhasebe tek aşamalı onay isterken yöneticiler ek onay istemektedir; model bu çatışmayı gerekçeleriyle listeler. Analist kararı vermez, ilgili paydaşlarla yeni bir toplantı planlar.

Ardından onaylanan gereksinimler için kullanıcı hikâyeleri yazdırılır. Rol olarak 'birim yöneticisi' ve 'muhasebe uzmanı' kullanılır. Her hikâyenin kabul kriterleri ayrıca üretilir ve analist, eksik uç durumları (reddedilen fatura, vekil yokluğu) ekler.

Sonunda analist hikâyeleri, kaynak notlarla karşılaştırıp doğrular ve ürün sahibine sunar. Modelin hızlandırdığı kısım yazımdır; analistin değeri doğrulamada ve paydaş yönetimindedir.

Sık yapılan hatalar

Bu alanda tekrarlayan hatalar şunlardır: • Bağlamsız yönlendirme. 'Bana kullanıcı hikâyeleri yaz' demek jenerik hikâyeler üretir. Rol, hedef ve kısıt vermek şarttır. • Doğrulamayı atlamak. Modelin ürettiği makul görünen bir gereksinim, aslında hiçbir paydaşın istemediği bir özellik olabilir. • Her şeyi tek seferde istemek. Uzun, çok amaçlı bir yönlendirme dağınık çıktı verir. Adımları ayırın; her adımın çıktısını kontrol edip bir sonrakine verin. • Ölçülemeyen kabul kriteri. 'Hızlı çalışmalı' gibi ifadeler test edilemez. Modelden ölçülebilir ifadeye çevirmesini isteyin; sayısal eşiği ise paydaşla belirleyin, modelin tahmin etmesine bırakmayın. • Önceliklendirmeyi modele bırakmak. Öncelik, iş değeri ve kısıt bilgisi gerektirir. Model öneri sunabilir, karar paydaşlardadır. • Gizli veriyi kontrolsüz yüklemek. Kurum politikasını bilmeden müşteri verisi içeren notları kullanmak ciddi bir uyum riski doğurur. • Dokümanı kopyalayıp yapıştırmak. Yapay zeka çıktısı kurumun şablon ve terminolojisine uymayabilir; son dil ve biçim kontrolü analiste aittir.

Mindset programlarında nerede çalışılır?

Yapay Zeka Destekli İş Analistliği Sertifika Programı, bu becerinin farklı katmanlarını ayrı modüllerde işler: 'Gereksinim Toplama Teknikleri', 'Yapay Zeka Destekli Bulgu Çıkarma ve Sentez', 'Gereksinim Yazımı ve Dokümantasyon', 'Çevik Ortamda İş Analizi ve Kullanıcı Hikayeleri' ve 'Gereksinim Yönetimi: Önceliklendirme, İzlenebilirlik ve Kapsam'. 'Komut Tasarımı ve Komut Zincirleri Atölyesi' ve 'Büyük Dil Modelleri ve Analist Araç Seti' modülleri ise modelle çalışma tarafını kapsar.

Program, iş analistleri, ürün sahipleri ve proje ekiplerinde gereksinim süreci yürüten çalışanlar için uygundur; analiz ekibinin ortak bir yönteme geçmesini isteyen kurumlar için grup programı olarak planlanabilir.