Use Case Senaryosu Yazmak: Ana Akış, Alternatif Akış ve Koşullar
Use case senaryosu, bir kullanıcının hedefine sistemle nasıl ulaştığını adım adım anlatan metindir. Şablonun alanlarını, ana ve alternatif akışın nasıl kurulacağını ve kütüphane örneğini adım adım göreceksiniz.
Bir bakışta
- Diyagram hedefleri gösterir, senaryo ise ayrıntıyı yazar. Use case diyagramı kimin ne yaptığını özetler; metin spesifikasyonu etkileşimin adım adım nasıl geçtiğini belgeler.
- Ana akış, her şeyin yolunda gittiği tek yoldur. Adımlar aktör ile sistem arasında dönüşümlü yazılır ve hedefin gerçekleşmesiyle biter.
- Sapmalar alternatif ve istisna akışlarında yazılır. Her sapma, ana akışın bir adımına bağlanır ve ya hedefe döner ya da güvenli biçimde sonlanır.
- Ön ve son koşul, kullanım durumunun sınırını çizer. Ön koşul başlamadan önce doğru olması gerekeni, son koşul bittiğinde doğru olması gerekeni söyler.
- Adımlar kullanıcının gördüğü dilde yazılır. "Sistem veri tabanını günceller" yerine "Sistem ödünç kaydını gösterir" gibi gözlemlenebilir ifadeler tercih edilir.
Use case metni neden yazılır?
Bir use case diyagramı "üye, kitap ödünç alır" der ama bunun nasıl olduğunu söylemez. Kimlik doğrulama gerekli mi? Kitap rafta yoksa ne olur? Üyenin cezası varsa işlem sürer mi? Bu soruların yanıtı use case senaryosunda yazılır.
Senaryo, gereksinimleri kullanıcı hedefi çevresinde toplar. Böylece geliştirici ekran ve kurallara, test uzmanı test senaryolarına, iş birimi de doğrulama toplantısına aynı belgeden bakar. Metin, kullanıcı hikâyesinden daha ayrıntılı ve daha yapılıdır.
İyi bir use case, tek bir kullanıcı hedefine odaklanır. "Kitap ödünç al" bir hedeftir; "Kütüphaneyi yönet" ise çok genel bir başlıktır ve birkaç ayrı use case'e bölünmelidir.
Şablonun alanları
Birçok ekip benzer bir şablon kullanır. Alanlar projeye göre azaltılabilir ya da genişletilebilir.
- Ad: fiil ile başlayan kısa bir hedef ifadesi ("Kitap ödünç al").
- Amaç ve kapsam: kullanım durumunun neden var olduğu ve hangi sistemi kapsadığı.
- Birincil aktör: hedefi olan kişi ya da rol. İkincil aktörler varsa ayrıca yazılır.
- Ön koşul: başlamadan önce doğru olması gerekenler (üye girişi yapılmış olması gibi).
- Tetikleyici: kullanım durumunu başlatan olay.
- Ana akış: numaralandırılmış adımlar.
- Alternatif akışlar: hangi adımdan ayrıldığı, koşulu ve devamı.
- İstisna akışları: hata ve vazgeçme durumları.
- Son koşul: başarı durumunda sistemin durumu, başarısızlık durumunda sistemin durumu.
- İş kuralları ve notlar: ilgili kurallar, arayüz notları, açık sorular.
Bu alanların hepsini doldurmak zorunda değilsiniz; ama ön koşul, ana akış, alternatif akış ve son koşul bir use case'in çekirdeğini oluşturur.
Bir use case, hedeften son koşula kadar katman katman anlatılır
Şablonun mantığı
- Hedef ve aktörKim, ne için sisteme geliyor.
- Ön koşul ve tetikleyiciNeyin doğru olduğu ve neyin başlattığı.
- AkışlarAna akış, alternatif ve istisna yolları.
- Son koşulBittiğinde sistemin ve kullanıcının durumu.
Ana akış nasıl yazılır?
Ana akış, her şeyin sorunsuz geçtiği yolu anlatır. Adımlar numaralandırılır, her adımda tek bir olay vardır ve özne açıktır: ya aktör bir şey yapar ya da sistem bir şey yapar.
Kütüphane örneğinde ana akış şöyle yazılabilir.
- Üye, ödünç alacağı kitabın barkodunu okutur.
- Sistem kitabın bilgilerini ve rafta olduğunu gösterir.
- Sistem üyenin ödünç alma hakkını denetler.
- Üye ödünç almayı onaylar.
- Sistem ödünç kaydını oluşturur ve iade tarihini gösterir.
- Üye makbuzu alır; kullanım durumu sona erer.
Adımları yazarken şu kurallara dikkat edin: kullanıcının gözlemleyebildiği şeyleri yazın, arayüz ayrıntısına (hangi düğmeye basıldığına) girmeyin, aktif cümleler kullanın ve her adımın bir önceki adımın doğal sonucu olduğundan emin olun. Bir adımda sistem ile aktörün birlikte yaptığı birden çok iş varsa adımı bölün.
Ana akışı kısa tutun. Çok uzun bir ana akış genellikle birden çok hedefi birleştirdiğinin işaretidir.
Alternatif ve istisna akışları
Gerçek hayat ana akışa her zaman uymaz. Alternatif akışlar bu sapmaları kayıt altına alır. Her alternatif akış şu bilgileri taşır: ana akışın hangi adımından ayrıldığı, ayrılma koşulu ve nereye döndüğü ya da nasıl bittiği.
Kütüphane örneğinden birkaç sapma.
- Kitap bilgisinin gösterildiği adımdan ayrılma: Kitap rafta değil. Sistem kitabın ödünçte olduğunu ve beklenen iade tarihini gösterir; üye isterse rezervasyon bırakır. Kullanım durumu rezervasyon kaydıyla biter.
- Hak denetimi adımından ayrılma: Üyenin ödünç alma hakkı dolmuş. Sistem bunu bildirir ve kullanım durumu ödünç kaydı oluşmadan sonlanır.
- Herhangi bir adımda: Üye işlemden vazgeçer. Sistem hiçbir kayıt oluşturmadan ana ekrana döner.
Alternatif akışı istisna akışından ayırmak yararlıdır. Alternatif akış çoğunlukla hedefe yine ulaşan başka bir yoldur. İstisna akışı ise hedefe ulaşılamadığı, hata ya da vazgeçme durumunu anlatır. Bu ayrım test tasarımında işe yarar: her akış ayrı bir test senaryosuna dönüşür.
Sapmaları bulmak için ana akışın her adımına "burada ne ters gidebilir?" ve "başka bir seçenek var mı?" sorularını sorun. Bu soruları paydaşla birlikte sormak, çoğu zaman gereksinimlerin eksik kalan kısımlarını ortaya çıkarır.
Ön koşul, son koşul ve sık hatalar
Ön koşul, kullanım durumunun başlayabilmesi için önceden sağlanması gereken durumdur: "Üye sisteme giriş yapmıştır." Ön koşul sistemin denetlediği bir şey değildir; kullanım durumu bunun doğru olduğunu varsayar. Ön koşul olarak yazdığınız şeyin denetimi gerekiyorsa, onu ana akışa adım olarak alın.
Son koşul, kullanım durumu bittiğinde doğru olan durumu söyler. Başarı için: "Ödünç kaydı oluşmuştur ve kitabın durumu ödünçte olarak güncellenmiştir." Başarısızlık için: "Hiçbir kayıt oluşmamıştır." Son koşul test için doğrudan bir doğrulama ölçütüdür.
Sık yapılan hatalar şunlardır.
- Arayüz ayrıntısını yazmak: "Sağ üstteki mavi düğmeye tıklar" ifadesi ekran değişince geçersiz olur.
- Birden çok hedefi tek use case'e koymak.
- Adımları pasif ya da öznesiz yazmak: "Kayıt oluşturulur" kimin yaptığını söylemez.
- Alternatif akışları atlayıp yalnızca mutlu yolu belgelemek.
- Veri tabanı işlemlerini adım olarak yazmak.
Gözlemlenebilir adımlar, arayüz ve teknik ayrıntıdan iyidir
Aynı adımın farklı yazımları
Bu beceriyi Mindset programlarında nerede çalışırsınız
İş Analizi Uzmanlığı Sertifika Programı'nın gereksinim analizi ve tasarım tanımı başlığı, use case gibi gereksinim tanımlama biçimlerinin çalışıldığı alana yakındır. Metni yazmak ile paydaşla doğrulamak arasındaki ilişki, gereksinim ortaya çıkarma modülüyle birlikte düşünülebilir.
Yapay Zeka Destekli İş Analistliği Sertifika Programı ise gereksinim yazımı ve dokümantasyon başlığıyla, taslak senaryoları hızlıca çıkarmak ve ardından analist gözüyle gözden geçirmek isteyen ekipler için bir tamamlayıcıdır.
İlgili Mindset programı
İş Analistliği Uzmanlığı Sertifika Programı (BABOK® v3 Temelli)
Sık sorulan sorular
Use case ile kullanıcı hikâyesi arasında hangisini seçmeliyim?
Çevik ve hafif bir ortamda, sık değişen ihtiyaçlar için hikâye daha uygundur. Düzenlemeye tabi, çok paydaşlı ya da sözleşmeyle bağlı projelerde, adımların ve istisnaların açık yazılması gerektiğinde use case öne çıkar. Birçok ekip ikisini birlikte kullanır; Hangisinin seçileceği kurumun çalışma biçimine bağlıdır.
Bir use case ne kadar ayrıntılı olmalı?
Geliştirici ve test uzmanının tahmin yürütmeden iş yapabileceği kadar, ancak ekran tasarımını belirlemeyecek kadar. Adımlar aktörün hedefine dönük kalmalı; arayüz ayrıntıları ayrı bir tasarım belgesine bırakılmalıdır. Aşırı ayrıntı belgeyi hızla eskitir.
Include ve extend ilişkileri metinde nasıl yazılır?
Ortak bir davranış başka bir use case'te tanımlanmışsa ana akışta o use case'e atıf yapılır; bu, include mantığıdır. Seçimli bir davranış için ilgili adımda koşulla birlikte genişleme use case'ine atıf verilir. Atıfları kısa tutmak ve atıf yapılan use case'in adını aynen kullanmak belgeyi sade bırakır.
Alternatif akış ile istisna akışını ayırmak şart mı?
Şart değildir ama yararlıdır. Alternatif akışlar çoğunlukla hedefe ulaşan başka yollardır; istisna akışları hedefin gerçekleşmediği durumlardır. Ayrım, test senaryolarını planlarken ve hata iletilerini tasarlarken işi kolaylaştırır.
Use case metnini kim yazar, kim onaylar?
Taslağı genellikle iş analisti yazar; içeriği iş birimi temsilcisi ve ürün sahibi doğrular, teknik uygulanabilirliği geliştirici ekip gözden geçirir. Onay sürecinin kim tarafından ve hangi kayıtla yapıldığı, proje başında belirlenmelidir.