Kullanıcı Hikayesi mi Use Case mi? İki Gereksinim Biçiminin Farkı

Aynı amaç, farklı ayrıntı düzeyi

Kullanıcı hikayesi (user story) ve use case (kullanım senaryosu), bir sistemin kullanıcıya ne sağlaması gerektiğini kullanıcının bakış açısından anlatan iki gereksinim biçimidir. İkisi de “sistem şu tabloyu güncellemeli” gibi teknik bir dil yerine “kullanıcı şunu yapabilmeli” diliyle başlar; ikisi de kullanıcı değerini merkeze koyar.

Farkları ayrıntı düzeyinde ve kullanım amacındadır. Kullanıcı hikayesi bilinçli olarak kısa tutulur ve ayrıntının ekip içi konuşmayla netleşmesini bekler. Use case ise kullanıcı ile sistem arasındaki etkileşimi ana akış, alternatif akışlar ve istisnalarla birlikte yazılı olarak baştan tanımlar.

Kullanıcı hikayesi nasıl yazılır?

Kullanıcı hikayesi yaygın olarak şu kalıpla yazılır: “Bir [kullanıcı rolü] olarak, [bir amaç] için [bir şey yapmak] istiyorum.” Örneğin: “Bir online mağaza müşterisi olarak, siparişimin ne zaman geleceğini bilmek için kargo durumunu hesabımdan takip etmek istiyorum.”

Hikaye tek başına eksiktir; onu tamamlayan iki parça vardır: • Kabul kriterleri: Hikayenin tamamlanmış sayılması için sağlanması gereken koşullar. Örneğin “Kargo firması bilgi göndermediyse müşteriye tahmini teslim aralığı gösterilir.” • Konuşma: Ürün sahibi, geliştiriciler (Developers) ve gerekirse iş analisti arasında, backlog iyileştirme sırasında ayrıntının netleştiği tartışma.

İyi bir hikaye bağımsız, konuşmaya açık, değerli, tahmin edilebilir, küçük ve test edilebilir olmalıdır; bu ölçütler İngilizce baş harfleriyle INVEST olarak bilinir. Scrum Guide kullanıcı hikayesini zorunlu tutmaz, ürün backlog öğesinin biçimini ekibe bırakır; kullanıcı hikayesi bu öğeleri yazmanın yaygın yollarından biridir.

Use case nasıl yazılır?

Use case, belirli bir aktörün sistemle etkileşerek bir hedefe ulaşmasını adım adım anlatır. Kavram, nesne yönelimli yazılım geliştirme yaklaşımlarıyla yaygınlaştı ve UML'de kullanım senaryosu diyagramıyla görselleştirilir.

Tipik bir use case şablonu şu alanları içerir: • Ad ve hedef (örneğin “Kargo durumunu görüntüle”) • Birincil aktör ve varsa diğer aktörler (müşteri, kargo firması sistemi) • Ön koşullar (müşteri oturum açmış, en az bir siparişi var) • Ana başarı akışı (müşteri siparişlerim sayfasını açar, sistem siparişleri listeler, müşteri bir siparişi seçer, sistem kargo durumunu gösterir) • Alternatif akışlar ve istisnalar (kargo bilgisi yok, kargo firması servisi yanıt vermiyor) • Son koşullar

Bu yapı, bir hikayenin konuşmayla netleştireceği ayrıntıyı önceden yazıya döker.

Ölçüt ölçüt kullanıcı hikayesi ve use case

Uzunluk: Kullanıcı hikayesi / tek cümle ve kabul kriterleri. Use case / bir ila birkaç sayfalık yapılandırılmış metin.

Ayrıntının yeri: Kullanıcı hikayesi / konuşmada ve kabul kriterlerinde. Use case / dokümanın kendisinde.

Kapsam: Kullanıcı hikayesi / tek bir sprintte bitirilebilecek küçük bir değer parçası. Use case / bir hedefe ulaşmanın tüm akışı; genellikle birden fazla hikayeye bölünebilir.

Alternatif ve hata durumları: Kullanıcı hikayesi / kabul kriterlerinde ya da ayrı hikayelerde. Use case / alternatif akış ve istisna bölümlerinde sistematik olarak.

Tipik ortam: Kullanıcı hikayesi / çevik ekipler, ürün backlog'u. Use case / ayrıntılı sözleşmeli projeler, düzenlemeye tabi alanlar, karmaşık etkileşimli sistemler.

Hedef okur: Kullanıcı hikayesi / ürün sahibi ve geliştiriciler. Use case / analistler, tasarımcılar, test uzmanları ve gerektiğinde dış tedarikçi.

Hangi durumda hangisi?

Kullanıcı hikayesi daha uygundur, eğer: • Ekip çevik çalışıyor ve iş küçük parçalar halinde teslim ediliyorsa • Ürün sahibi ve geliştiriciler sık ve yakın iletişimdeyse • Gereksinimin geri bildirimle değişmesi bekleniyorsa

Use case daha uygundur, eğer: • Etkileşimde çok sayıda alternatif yol ve istisna varsa (ödeme, başvuru, onay akışları) • Gereksinim dış bir tedarikçiye ya da başka bir ekibe yazılı olarak devredilecekse • Denetim, sözleşme ya da mevzuat gereği izlenebilir ve ayrıntılı kayıt gerekiyorsa

Sık yapılan hata, kullanıcı hikayesini use case uzunluğunda yazmak ya da use case'i tek cümlelik bir hikayeye indirip istisnaları unutmaktır. Her biçim kendi güçlü yanıyla kullanıldığında anlamlıdır.

İkisini birlikte kullanmak

İki biçim bir arada da kullanılabilir. Örneğin karmaşık bir iade süreci önce use case olarak modellenir; ana akış ve istisnalar ekiple birlikte netleşir. Ardından bu use case backlog'a birden fazla kullanıcı hikayesi olarak bölünür: “iade talebi oluşturma”, “iade kargo kodu alma”, “iade durumunu görüntüleme” gibi. Use case'teki alternatif akışlar da ilgili hikayelerin kabul kriterlerine dönüşür.

Bu yaklaşım, use case'in bütünlüklü bakışını kaybetmeden çevik teslimatın küçük adımlarını korur. Kullanıcı hikayesi haritalama (story mapping) da benzer bir amaçla, hikayeleri kullanıcı yolculuğunun adımları altında dizerek büyük resmi görünür tutar.

Aynı gereksinim iki biçimde: yan yana örnek

Örneğin bir sipariş iptali gereksinimini ele alalım.

Kullanıcı hikayesi olarak: “Bir müşteri olarak, yanlış ürünü seçtiğimde siparişimi kargoya verilmeden iptal etmek istiyorum.” Kabul kriterleri: kargoya verilmemiş sipariş için iptal düğmesi görünür, iptal sonrası müşteriye bilgi e-postası gider, ödeme iadesi başlatılır.

Use case olarak: hedef “Siparişi iptal et”, birincil aktör müşteri, ön koşul oturum açılmış ve sipariş kargoya verilmemiş olmalıdır. Ana akışta müşteri siparişi seçer, iptal nedenini belirtir, sistem onay ister, sipariş iptal edilir ve ödeme sistemine iade talebi iletilir. Alternatif akışlarda sipariş iptal sırasında kargoya verilmişse sistem iptali reddeder ve iade seçeneklerini gösterir; ödeme sistemi yanıt vermezse iade kuyruğa alınır.

İki metin aynı gereksinimi anlatır. Hikaye ekibi konuşmaya çağırır, use case ise konuşma yapılamayacak okurlar için (tedarikçi, test ekibi, denetçi) açıklığı yazıya taşır.

Yazarken sık düşülen tuzaklar

• Hikayeyi arayüz tarifine çevirmek: “Sağ üstte kırmızı bir düğme olsun” bir çözümdür, kullanıcı ihtiyacı değildir. Hikaye “ne” ve “neden” sorusunu yanıtlamalıdır.
• Kabul kriteri olmadan hikayeyi backlog'a almak: Test edilemeyen hikaye, tamamlandı sayılıp sayılmayacağı tartışmasına yol açar.
• Use case'i sistemin iç işleyişiyle doldurmak: Adımlar aktörün ve sistemin dışarıdan görünen davranışını anlatmalıdır; veritabanı işlemleri ayrıntısı başka bir dokümana aittir.
• İstisnaları sona bırakmak: Ödeme, onay ve başvuru akışlarında hataya düşen yollar çoğu zaman ana akıştan daha çok geliştirme emeği ister; bunları ilk taslakta görünür kılın.
• Her ikisini de herkese zorunlu kılmak: Biçim, ekibin çalışma şekline ve okurun ihtiyacına göre seçilmelidir.

Mindset programlarında gereksinim yazımı

Agile (Scrum) Ortamında İş Analizi Eğitimi; ürün backlog yönetimi, sprint planlama ve gereksinim akışı, önceliklendirme ve review ile retrospektif süreçlerinde analiz katkısı modülleriyle kullanıcı hikayelerinin çevik akış içinde nasıl yönetildiğini işler. Backlog Refinement Pratikleri eğitimi ise kaliteli user story yazımı, kabul kriterleri ve Definition of Ready konularına odaklanır.

Gereksinim Analistliği Sertifika Programı, çevik gereksinimler (kullanıcı hikayeleri ve backlog) modülünün yanında gereksinim yazımı, doğrulama ve izlenebilirlik modülleriyle iki biçimin arkasındaki ortak becerileri ele alır.