30 saniyelik özet
Use case, yani kullanım durumu, bir aktörün belirli bir hedefe ulaşmak için sistemle nasıl etkileştiğini anlatır. Aktör, sistemin dışından etkileşime katılan kişi rolü veya başka bir sistemdir. İyi bir kullanım durumu; başlangıç koşullarını, normal akışı, alternatifleri ve işlem sonunda oluşacak durumu görünür kılar. Ekrandaki düğmelerin sırasını anlatmak yeterli değildir. Asıl soru şudur: Kullanıcı hangi sonucu elde etmek istiyor ve sistem bu sonuca ulaşamadığında nasıl davranacak? Bu açıklık; iş analisti, geliştirici ve test uzmanının aynı davranış üzerinde anlaşmasına yardımcı olur.
Neden önemli?
“Yönetici çalışanı sisteme davet edebilsin” cümlesi ilk bakışta yeterince açıktır. Ancak geliştirme başladığında sorular çoğalır: Aynı adrese ikinci davet gönderilebilir mi? Yetkisi kaldırılmış bir yönetici açık ekranından işlem yapabilir mi? E-posta gönderilemezse davet kaydı geçerli sayılır mı? Davet oluşturmak, çalışanın hesabı kullanmaya başlamasıyla aynı sonuç mudur?
Bu sorular cevapsız kaldığında ekipler boşlukları kendi varsayımlarıyla doldurur. Geliştirici kayıt oluşturmayı başarı sayarken test uzmanı e-postanın teslimini bekleyebilir. Ürün yöneticisi ise kullanıcının gerçekten sisteme katılmasını hedefliyor olabilir. Üçü de aynı gereksinimi okur, fakat farklı sonuçları değerlendirir.
Kullanım durumu, bu farklılıkları geliştirmeden önce konuşulabilir hale getirir. Yönetici açısından değeri de buradadır: Belirsizliğin nerede olduğunu gösterir ve hangi kararların iş sahibinden gelmesi gerektiğini ortaya çıkarır. Her ayrıntıyı uzun bir belgeye dönüştürmek gerekmez. Yetki, veri bütünlüğü veya birden fazla sistem arasında işlem tamamlama söz konusuysa akışı açıkça yazmak özellikle yararlıdır.
Terim nedir?
Bir kullanım durumu, sistem sınırı içinde gerçekleşen ve aktör açısından anlamlı sonuç üreten davranışları tarif eder. Sistem sınırı, hangi sorumlulukların incelenen ürüne, hangilerinin dış hizmetlere ait olduğunu belirtir. Örneğin ürün davet kaydı oluşturabilir; e-postanın alıcının gelen kutusuna ulaşması dış hizmetlerin davranışına da bağlıdır.
Tanım genellikle hedef, aktör, tetikleyici, önkoşullar, ana akış, alternatif akışlar ve sonkoşullardan oluşur. Tetikleyici, işlemi başlatan olaydır. Önkoşul, akış başlayabilsin diye sağlanması gereken durumdur. Sonkoşul ise işlem bittiğinde sistemde doğru olması gereken durumdur. Başarısızlık sonunda korunacak durumları ayrıca belirtmek, yarım kalmış işlemleri anlamayı kolaylaştırır.
Ana akış, beklenen başarı yoludur. Alternatif akış, aynı hedefe farklı koşullarda ulaşmayı anlatabilir. İstisna akışı ise hata veya engel nedeniyle işlemin başka şekilde sonuçlanmasını açıklar. Bu ayrımın adından çok, her yolun nerede başlayıp nasıl bittiğinin açık olması önemlidir.
User story, yani kullanıcı hikâyesi, ihtiyacı kullanıcı, amaç ve değer üzerinden kısa biçimde ifade eder. Kullanım durumu bu ihtiyacın etkileşim davranışını açabilir. Aralarında zorunlu bir bire bir ilişki yoktur. Ayrıca kullanım durumu, ekran tasarımı veya teknik çözüm belgesi değildir; sistemin gözlemlenebilir davranışına odaklanır.
Gerçek vaka: Netflix Simone ile hata koşullarını görünür kılmak
Netflix’in 2017 tarihli teknik yazısı, cihaz ortaklarının Netflix uygulamasını olumlu ve olumsuz koşullarda sınamasına yardımcı olan Simone hizmetini anlatır. Örneklerden biri, eşzamanlı yayın sınırına ulaşılmışken başka bir cihazdan oynatma başlatılmasıdır. Bu koşulu elle kurmak, birden fazla cihazda yayın başlatmayı gerektirir.
Simone, seçilmiş bir cihazın lisans isteğine ilgili hata yanıtını üretecek simülasyon tanımlamayı mümkün kılar. Şablonlar davranışı ve tetikleyici koşulları tarif eder; belirli değerlerle oluşturulan örnekler test sırasında uygulanır. Etkinin cihaz veya hesap gibi koşullarla sınırlandırılması, testin kapsamını kontrol etmeye yardımcı olur.
Kaynak, Netflix’in resmi kullanım durumu belgelerini yayımlamıyor. Buradaki bağlantı analitik bir çıkarımdır: “Yayını başlat” hedefi, sınır dolduğunda sistemin vereceği tepkiyle birlikte ele alındığında sınanabilir hale gelir. Kullanım durumu yazarken de başarı yolunun yanına bu tür koşulları eklemek gerekir. Yalnızca oynatmanın başladığını doğrulamak, sınırın aşıldığı senaryoyu açıklamaz.
Kaynak: Netflix Technology Blog, Simone — A Distributed Simulation Service, 6 Haziran 2017.
Varsayımsal örnek: Kurumsal uygulamada çalışan daveti
Bir kurumsal yazılımda yönetici yeni çalışan daveti oluşturmak istiyor. Kullanım durumunun hedefini “çalışanı hesaba dahil etmek” yerine “geçerli bir davet oluşturmak” olarak belirleyelim. Çünkü davetin kabulü çalışanın daha sonra başlattığı ayrı bir etkileşimdir. Bu sınır, davet gönderilmesini aktif üyelikle karıştırmamızı önler.
Birincil aktör davet yetkisine sahip yöneticidir. Yönetici e-posta adresini ve atanacak rolü girer. Sistem işlem anında yetkiyi doğrular, adresin kullanılabilirliğini ve rol atama koşullarını kontrol eder. Uygun koşullarda bekleyen davet kaydı oluşturur ve bildirim gönderimini başlatır. Başarılı sonkoşul, davetin kayıtlı ve izlenebilir olmasıdır; çalışanın aktif üye olması değildir.
Bu varsayımsal ürün için, aynı adrese açık davet varsa yeni kayıt oluşturulmaması kararlaştırılsın. Sistem mevcut daveti gösterir ve yeniden gönderim seçeneği sunar. Bildirim hizmeti hata verirse davet kaydı korunur, gönderim durumu başarısız olarak işaretlenir ve yeniden deneme mümkün olur. Böylece kullanıcı, görünmeyen bir hatadan sonra tekrar işlem yapıp yinelenen kayıt üretmez.
Davetin kabulünde lisans uygunluğu yeniden kontrol edilecekse bunu ilişkili kabul kullanım durumunda tanımlarız. Davet anındaki uygunluk, kabul anında da uygunluk bulunacağını garanti etmez. Bu tercih ürünün iş kuralıdır; bütün kurumsal uygulamalara uygulanacak evrensel bir kural değildir.
Yaygın üç hata
- Kullanıcı hedefi yerine ekran adımlarını yazmak
“Menüye tıkla, formu aç, düğmeye bas” anlatımı tasarım değişince hızla eskir. Hedefi ve sistem yanıtlarını yazın. Ekran ayrıntısını yalnızca davranışı anlamak için gerekli olduğunda ekleyin. Aynı hedef farklı arayüzlerden gerçekleşebilir.
- Sadece başarılı yolu belgelemek
Geçersiz veri, yetki kaybı ve dış hizmet hataları sonradan düşünülürse farklı ekipler farklı çözümler üretir. Alternatifleri rastgele çoğaltmak yerine iş etkisine göre seçin. Para, erişim hakkı veya kayıt bütünlüğünü etkileyen yolları öncelikle açıklayın.
- Önkoşulları işlem boyunca değişmez kabul etmek
Kullanıcı ekranı açtığında yetkili olabilir, işlemi gönderdiğinde yetkisi kaldırılmış olabilir. Hangi koşulların işlem anında tekrar doğrulanacağını belirtin. Başarısızlıkta hangi kayıtların korunacağını ve kullanıcının ne göreceğini de yazın. “Hata gösterilir” ifadesi tek başına yeterli değildir.
Mini uygulama / şablon
Bir sonraki gereksiniminiz için aşağıdaki alanları doldurun. Önce tek bir aktör hedefi seçin; sonra başarı ve başarısızlık sonlarını karşılaştırın.
- Kullanım durumu adı ve kimliği
- —
- Aktörün hedefi
- —
- Birincil aktör ve yardımcı dış sistemler
- —
- Sistem sınırı
- —
- Tetikleyici
- —
- Önkoşullar
- —
- İşlem anında yeniden doğrulanacak koşullar
- —
- Ana akış
- Aktörün talebi ve sistemin karşılığı, sırayla.
- Alternatifler
- Ayrıldığı adım, koşul, sistem davranışı ve bitiş.
- Başarılı sonkoşul
- —
- Başarısızlıkta korunacak durum
- —
- İlişkili iş kuralları ve gereksinimler
- —
- Açık kararlar ve karar sahibi
- —
Ardından bir geliştirici ve test uzmanıyla metni okuyun. Aynı koşul için farklı sonuçlar bekliyorlarsa metni uzatmadan önce eksik kararı bulun. Her alternatifin gözlemlenebilir bir sonucu olup olmadığını kontrol edin. Bu kısa inceleme, kullanım durumunu belge olmaktan çıkarıp ortak karar aracına dönüştürür.
İlgili terimler
User Story, Acceptance Criteria, Business Rule, Functional Requirement, Requirements Elicitation, Scope ve Out of Scope, User Acceptance Testing, Requirements Traceability Matrix