Kullanım durumu - Use case

Çok basit bir kullanım durumunda diyagramıdır a Wiki sistemi.

Gelen yazılım ve sistem mühendisliği , ifade kullanma durumu bir olduğunu polyseme iki ile duyuları :

Bir yazılım parçası için bir kullanım senaryosu; genellikle çoğul olarak bir yazılım parçasının yararlı olabileceği durumları önermek için kullanılır.
Bir sistemin harici bir istek (kullanıcı girişi gibi) aldığı ve buna yanıt verdiği olası bir senaryo.

Bu makale ikinci anlamı tartışıyor.

Bir kullanım örneği eylem veya tipik (bilinen bir rol arasındaki etkileşimleri tanımlayan olay adımların bir listesi Unified Modeling Language bir şekilde (UML) aktör ) ve bir hedefe ulaşmak için bir sistem. Aktör, bir insan veya başka bir dış sistem olabilir. Sistem mühendisliğinde, kullanım durumları yazılım mühendisliğinden daha yüksek bir düzeyde kullanılır ve genellikle görevleri veya paydaş hedeflerini temsil eder . Ayrıntılı gereksinimler daha sonra Sistem Modelleme Dili'nde (SysML) veya sözleşme beyanları olarak yakalanabilir .

Tarih

1987'de Ivar Jacobson , OOPSLA '87 konferansında kullanım durumları üzerine ilk makaleyi sundu . Bu tekniğin Ericsson'da , nesne yönelimli analiz ve tasarımı yönlendirmek için metinsel, yapısal ve görsel modelleme tekniklerini kullanarak bir sistemin gereksinimlerini yakalamak ve belirlemek için nasıl kullanıldığını anlattı . Başlangıçta o terimler kullanmıştı kullanım senaryoları ve kullanım durumda İsveçli terim ikinci doğrudan çevirisini - användningsfall - ama bu terimlerin ne İngilizce olarak doğal geliyordu ve sonunda o yerleşmiş olduğu tespit kullanım durumunda .

1992'de , OOSE sistem mühendisliği yönteminin temelini atan ve özellikle yazılım geliştirmede işlevsel gereksinimleri yakalamak için kullanım durumlarının yaygınlaşmasına yardımcı olan Nesneye Yönelik Yazılım Mühendisliği - Bir Kullanım Durumuna Dayalı Yaklaşım kitabının yazarlarından biridir . 1994 yılında iş modelleri ve iş süreçlerinin yeniden mühendisliğine uygulanan kullanım örnekleri ve nesne yönelimli teknikler hakkında bir kitap yayınladı .

Aynı zamanda, Grady Booch ve James Rumbaugh , sırasıyla nesne yönelimli analiz ve tasarım yöntemlerini, Booch yöntemini ve Nesne Modelleme Tekniği'ni (OMT) birleştirmeye çalıştılar . 1995'te Ivar Jacobson onlara katıldı ve birlikte kullanım senaryosu modellemeyi içeren Birleşik Modelleme Dili'ni (UML) yarattılar . UML, 1997 yılında Object Management Group (OMG) tarafından standardize edildi . Jacobson, Booch ve Rumbaugh da Objectory yazılım geliştirme sürecinin iyileştirilmesi üzerinde çalıştı . Ortaya çıkan Birleşik Süreç 1999'da yayınlandı ve kullanım senaryosu odaklı bir yaklaşımı destekledi.

O zamandan beri, birçok yazar, tekniğin geliştirilmesine katkıda bulunmuştur, özellikle: Larry Constantine , 1995 yılında, eylem dizilerinden ziyade kullanıcı niyetlerini tanımlamayı amaçlayan "temel kullanım durumları" olarak adlandırılan kullanım merkezli tasarım bağlamında geliştirilmiştir. veya kullanıcı arayüzünün tasarımını kısıtlayabilecek veya önyargı oluşturabilecek senaryolar; Alistair Cockburn , 2000 yılında metin anlatımlarına ve tablo özelliklerine dayalı, amaca yönelik bir kullanım senaryosu uygulaması yayınladı; Kurt Bittner ve Ian Spence, 2002'de kullanım senaryolarıyla işlevsel gereksinimleri analiz etmek için gelişmiş uygulamalar geliştirdi; Dean Leffingwell ve Don Widrig, yönetim ve paydaş iletişim faaliyetlerini değiştirmek için kullanım örneklerini uygulamayı önerdi; Gunnar Overgaard, 2004 yılında tasarım modellerinin ilkelerini kullanım durumlarını kapsayacak şekilde genişletmeyi önerdi.

2011'de Jacobson , tekniği çevik bir bağlama uyarlamak, artan kullanım senaryosu "dilimleri" ile zenginleştirmek ve yenilenen yaklaşımı sunduktan sonra tüm geliştirme yaşam döngüsü boyunca kullanımını teşvik etmek için Ian Spence ve Kurt Bittner ile birlikte Use Case 2.0 e-kitabı yayınladı. yıllık IIBA konferansında.

Genel prensip

Kullanım durumları, bir sistemin gereksinimlerini yakalamak, modellemek ve belirtmek için kullanılan bir tekniktir. Kullanım durumu, sistemin aktörleri ile etkileşim içinde gerçekleştirebileceği ve amaçlarına katkıda bulunan gözlemlenebilir bir sonuç üreten bir dizi davranışa karşılık gelir. Aktörler, insan kullanıcıların veya diğer sistemlerin etkileşimdeki rolünü temsil eder.

In gereksinim analizi , onların kimlik de, bir kullanma durumu onun birincil aktör için temsil ettiği belirli kullanıcı hedefe göre adlandırılır. Durum, metinsel bir açıklama veya genel etkinlik ve olayların sırasını ve ayrıca özel koşullar, istisnalar veya hata durumları gibi değişkenleri açıklayan ek grafik modellerle daha da detaylandırılır.

Göre Bilgi Yazılım Mühendisliği Vücut (SWEBOK) , kullanım durumları senaryo bazlı ait gereksinimi ortaya çıkarma teknikleri, hem de model tabanlı analiz teknikleri. Ancak kullanım senaryoları ayrıca anlatı tabanlı gereksinim toplamayı, artımlı gereksinim alımını, sistem belgelerini ve kabul testini de destekler.

Varyasyonlar

Teknikte farklı kullanım durumları ve varyasyonları vardır:

Sistem kullanım durumları, geliştirilecek bir sistemin gereksinimlerini belirtir. Ayrıntılı açıklamalarında yalnızca aktörlerle olan etkileşimleri değil, aynı zamanda işlemeye dahil olan varlıkları da tanımlarlar. Bunlar, daha ileri analiz modelleri ve tasarım aktiviteleri için başlangıç noktasıdır.
İş kullanım durumları, bir yazılım sistemi yerine bir iş organizasyonuna odaklanır. İş süreci yeniden yapılandırma girişimleri bağlamında iş modellerini ve iş süreci gereksinimlerini belirtmek için kullanılırlar.
Soyut kullanım durumları olarak da adlandırılan temel kullanım durumları, herhangi bir sıra tanımlamadan veya bir senaryo tanımlamadan, aktörlerin potansiyel amaçlarını ve sistemin bunları nasıl ele aldığını açıklar. Bu uygulama, kullanıcı merkezli tasarımı desteklemek ve sistem spesifikasyonlarının erken aşamasında kullanıcı arayüzü hakkında önyargı oluşturmaktan kaçınmak amacıyla geliştirilmiştir.
Use Case 2.0, tekniği çevik geliştirme yöntemleri bağlamına uyarlar. Bu teknik, kullanıcı hikayesi anlatıları desteği ile gereksinim toplama uygulamasını zenginleştirir. Ayrıca, gereksinimlerin artımlı olarak ortaya çıkarılmasını kolaylaştırmak ve artımlı uygulamayı etkinleştirmek için kullanım senaryosu "dilimleri" sağlar.

Dürbün

Kullanım senaryosunun kapsamı, konuya ve hedeflere göre tanımlanabilir:

Konu, etkileşimleri sağlayacak sistem, alt sistem veya bileşeni tanımlar.
Hedefler, hedefle ilgilenen organizasyonel seviye (örneğin şirket, departman, kullanıcı) ve kullanıcının hedefinin alt hedeflere ayrıştırılması dikkate alınarak hiyerarşik olarak yapılandırılabilir. Hedefin ayrıştırılması, geleneksel fonksiyonel ayrıştırmadan farklı olarak, kullanıcıların bakış açısından ve sistemden bağımsız olarak gerçekleştirilir.

kullanım

Kullanım senaryolarının aşağıdaki bağlamlarda uygulandığı bilinmektedir:

Object Oriented Software Engineering (OOSE) , sürücü eleman olarak;
Bir davranışsal modelleme aracı olarak Birleşik Modelleme Dili (UML);
Birleşik Yazılım Geliştirme Süreci (UP) ve öncüsü IBM Rational Unified Process (RUP) ;
işlevsel gereksinimler için alternatif yapı olarak yazılım gereksinimleri belirtiminin (SRS) önceden belgelenmesi ;
tasarım, varlık-kontrol-sınır yaklaşımını kullanarak gereksinimlerden türetmek ;
ve çevik geliştirme .

şablonlar

Kullanım senaryosu kısa , gündelik , anahat , tamamen giyinmiş vb.'ye ve çeşitli şablonlara kadar metinde bir kullanım senaryosu yazmanın birçok yolu vardır . Çeşitli satıcılar veya uzmanlar tarafından tasarlanan şablonlarda kullanım senaryoları yazmak, yüksek kaliteli işlevsel sistem gereksinimleri elde etmek için yaygın bir endüstri uygulamasıdır.

horoz yanığı tarzı

Alistair Cockburn tarafından Etkili Kullanım Vakaları Yazma kitabında tanımlanan şablon , kullanım senaryolarının en yaygın kullanılan yazı stillerinden biri olmuştur.

Tasarım kapsamları

Cockburn, kara kutu (dahili detay gizlidir) veya beyaz kutu (dahili detay gösterilir) olabilen "Tasarım Kapsamını" göstermek için her bir kullanım durumunu bir sembolle açıklamayı önerir. Beş sembol mevcuttur:

Dürbün	Simge
Organizasyon (kara kutu)	Dolu Ev
Organizasyon (beyaz kutu)	Doldurulmamış Ev
Sistem (kara kutu)	Dolu Kutu
Sistem (beyaz kutu)	Doldurulmamış Kutu
Bileşen	Vida veya Cıvata

Diğer yazarlar bazen Organizasyon düzeyindeki kullanım senaryolarını "Ticari kullanım senaryoları" olarak adlandırırlar.

Hedef seviyeleri

Hedef seviyelerinin hiyerarşisi

Cockburn, "Hedef Düzeyini" göstermek için her bir kullanım durumunu bir sembolle açıklamayı önerir; tercih edilen seviye "Kullanıcı hedefi"dir (veya halk dilinde "deniz seviyesi").

Hedef Seviyesi	Simge	Sembol
Çok Yüksek Özet	Bulut	++
Özet	Uçan uçurtma	+
Kullanıcı Hedefi	Denizde Dalgalar	!
Alt fonksiyon	Balık	-
Çok düşük	Deniz dibi İstiridye Kabuğu	--

Bazen metin yazarken, alternatif bir metin sembolü (!, +, -, vb.) tarafından takip edilen bir kullanım durumu adı, seviyeleri belirtmek için daha özlü ve kullanışlı bir yoldur, örneğin bir sipariş vermek! , giriş- .

Tamamen giyinmiş

Cockburn, bir kullanım durumu için daha ayrıntılı bir yapı tanımlar, ancak daha az ayrıntı gerektiğinde basitleştirilmesine izin verir. Tamamen giydirilmiş kullanım örneği şablonu aşağıdaki alanları listeler:

Başlık: "birincil aktörün hedefini adlandıran bir etkin fiil hedef ifadesi"
Birincil Aktör
Bağlamdaki Hedef
Dürbün
Seviye
Paydaşlar ve Çıkarlar
ön koşul
Asgari Garantiler
Başarı Garantileri
Tetiklemek
Ana Başarı Senaryosu
Uzantılar
Teknoloji ve Veri Varyasyonları Listesi

Ayrıca Cockburn, her bir kullanım durumunun doğasını belirtmek için iki cihaz kullanılmasını önerir: tasarım kapsamı ve hedef düzeyi için simgeler.

Cockburn'ün yaklaşımı diğer yazarları da etkilemiştir; örneğin, Alexander ve Beus-Dukic, Cockburn'ün "Tam giydirilmiş kullanım durumu" şablonunu yazılımdan her türlü sisteme, aşağıdaki alanlarla Cockburn'den farklı olarak genelleştirir:

Varyasyon senaryoları "(belki ana senaryodan ayrılarak ve belki de ana senaryoya geri dönülerek)"
İstisnalar "yani istisna olayları ve istisna işleme senaryoları"

Gündelik

Cockburn, projelerin her zaman ayrıntılı "tam hazır" kullanım senaryolarına ihtiyaç duymayabileceğinin farkındadır. Alanlarla birlikte bir Gündelik kullanım durumunu açıklar:

Başlık (hedef)
Birincil Aktör
Dürbün
Seviye
(Öykü): Kullanım senaryosunun gövdesi, ne olduğunu gayri resmi olarak açıklayan bir veya iki metin paragrafıdır.

Fowler tarzı

Martin Fowler , "Bir kullanım senaryosunun içeriğini yazmanın standart bir yolu yoktur ve farklı biçimler, farklı durumlarda iyi çalışır." "Kullanılacak ortak bir tarz"ı şöyle tanımlıyor:

Başlık: "kullanım senaryosunun karşılamaya çalıştığı hedef"
Ana Başarı Senaryosu: numaralı adımların listesi
- Adım: "aktör ve sistem arasındaki etkileşimin basit bir ifadesi"
Uzantılar: Uzantı başına bir tane olmak üzere ayrı numaralandırılmış listeler
- Uzantı: "ana başarı senaryosundan farklı etkileşimlerle sonuçlanan bir durum". Ana adım 3'ten bir uzantı 3a, vb. olarak numaralandırılmıştır.

Fowler stili, Cockburn şablonunun basitleştirilmiş bir çeşidi olarak da görülebilir.

Aktörler

Kullanım senaryosu, bir amacı gerçekleştirmek için dış aktörler ile incelenen sistem arasındaki etkileşimleri tanımlar. Aktörler karar verebilmelidir, ancak insan olması gerekmez: "Bir aktör, bir kişi, bir şirket veya kuruluş, bir bilgisayar programı veya bir bilgisayar sistemi olabilir - donanım, yazılım veya her ikisi olabilir." Aktörler her zaman paydaştır , ancak tüm paydaşlar aktör değildir, çünkü "sistemin nasıl davrandığını umursama hakları olsa bile, sistemle asla doğrudan etkileşime girmezler." Örneğin, "sistemin sahipleri, şirketin yönetim kurulu ve Gelir İdaresi Başkanlığı ve Sigorta Departmanı gibi düzenleyici kurumlar" tümü paydaş olabilir, ancak aktör olmaları muhtemel değildir.

Benzer şekilde, bir sistemi kullanan bir kişi, farklı roller oynaması nedeniyle farklı aktörler olarak temsil edilebilir. Örneğin, "Joe" kullanıcısı, kendi hesabından nakit çekmek için bir Otomatik Vezne Makinesi kullanırken bir Müşteri rolünü oynuyor olabilir veya müşteri adına kasa çekmecesini yeniden doldurmak için sistemi kullanırken Banka Veznedarı rolünü oynuyor olabilir. banka.

Aktörler genellikle başkası adına çalışırlar. Cockburn, "Bugünlerde sistem kullanıcısının başka biri adına hareket ettiğini anlamak için 'müşteri için satış temsilcisi' veya 'pazarlama departmanı için memur' yazıyorum. Bu, projeye "kullanıcı arayüzü ve güvenlik izinlerinin" satış temsilcisi ve katip için tasarlanması gerektiğini, ancak müşteri ve pazarlama departmanının sonuçlarla ilgili roller olduğunu söyler.

Bir paydaş hem aktif hem de aktif olmayan bir rol oynayabilir: örneğin, bir Tüketici hem "kitlesel pazar alıcısı" (sistemle etkileşime girmeyen) hem de Kullanıcıdır (satın alınan ürünle aktif olarak etkileşime giren bir aktör). Buna karşılık, bir Kullanıcı hem "normal operatör" (sistemi amaçlanan amaç için kullanan bir aktör) hem de "fonksiyonel yararlanıcı" (sistemin kullanımından yararlanan bir paydaş). Örneğin, "Joe" kullanıcısı hesabından nakit çektiğinde, Otomatik Vezne Makinesini işletiyor ve kendi adına bir sonuç alıyor.

Cockburn, bir sistemin paydaşları arasında aktörler, bir kullanım senaryosunun birincil ve destekleyici (ikincil) aktörleri, tasarlanan sistemin (SuD) kendisi ve son olarak "iç aktörler", yani sistemin bileşenleri arasında aktörler aramayı tavsiye eder. tasarım altında.

İş kullanım örneği

Bir kullanım senaryosunun bir kullanıcı (veya başka bir Aktör türü) ile bir sistem arasındaki bir dizi olayı ve etkileşimi tanımlamasıyla aynı şekilde, bir değer (hedef) sonucu üretmek için bir iş kullanım senaryosu daha genel etkileşimi tanımlar. değerli iş sonuçları üretmek için bir iş sistemi ile bu sistemin kullanıcıları/aktörleri arasında Birincil fark, bir iş kullanım senaryosu modelinde ele alınan sistemin teknolojik sistemlere ek olarak insanları da içerebilmesidir. Bu "sistemdeki insanlara" iş işçileri denir. Bir restoran örneğinde, her bir kişiye bir aktör (dolayısıyla sistemin dışında) veya bir iş çalışanı (sistemin içinde) olarak mı davranılacağına karar verilmelidir. Bir garson, aşağıdaki örnekte gösterildiği gibi bir oyuncu olarak kabul edilirse, restoran sistemi garsonu içermez ve model, garson ile restoran arasındaki etkileşimi ortaya çıkarır. Bir alternatif, garsonu restoran sisteminin bir parçası (işçi) olarak kabul ederken, müşteriyi sistemin dışında (aktör) olarak düşünmek olabilir.

Bir iş kullanım senaryosu diyagramı , bir restoran (iş sistemi) ile birincil paydaşları ( iş aktörleri ve iş çalışanları ) arasındaki etkileşimleri temsil eden çeşitli iş kullanım durumlarının (hedeflerinin) bir modelini gösterir .

Görsel modelleme

Kullanım durumları yalnızca metinler değil, aynı zamanda gerekirse diyagramlardır. In Unified Modeling Language , kullanım durumları ve aktörler arasındaki ilişkiler temsil edilir kullanma durumu diyagramları aslen dayalı Ivar Jacobson 'ın Objectory gösterimde. SysML , sistem bloğu düzeyinde aynı gösterimi kullanır.

Ayrıca, kullanım durumlarını buna göre görselleştirmek için etkinlik diyagramları , sıra diyagramları , iletişim diyagramları ve durum makinesi diyagramları gibi diğer davranışsal UML diyagramları da kullanılabilir. Spesifik olarak, bir Sistem Sıralama Şeması (SSD), genellikle bir kullanım senaryosunun belirli bir senaryosunu görselleştirmek için, dış aktörler ile tasarım altındaki sistem (SuD) arasındaki etkileşimleri göstermek için sıklıkla kullanılan bir sıra diyagramıdır.

Kullanım durumu analizi genellikle kullanım durumu diyagramları çizerek başlar. Çevik geliştirme için, kullanım senaryolarını ve bazı metinsel açıklamaları, notları veya kullanım senaryosu özetlerini gösteren birçok UML diyagramından oluşan bir gereksinim modeli çok hafif ve küçük veya kolay proje kullanımı için yeterli olacaktır. Vaka metinlerini kullanmak için iyi tamamlayıcılar olarak, kullanım senaryolarının görsel diyagram temsilleri de karmaşık sistem davranışsal gereksinimlerinin daha iyi anlaşılması, iletilmesi ve tasarımı için etkili kolaylaştırıcı araçlardır.

Örnekler

Aşağıda, Cockburn tarzı şablonun biraz değiştirilmiş bir versiyonuyla yazılmış örnek bir kullanım durumu bulunmaktadır. Temel akış veya uzantıların her adımında yalnızca kullanıcı hedeflerinin, alt hedeflerinin veya niyetlerinin ifade edildiği temel kullanım senaryosu açıklamasında hiçbir düğme, kontrol, form veya diğer UI öğeleri ve işlemleri olmadığını unutmayın. Bu uygulama, gereksinim belirtimini daha net hale getirir ve tasarım ve uygulamaların esnekliğini en üst düzeye çıkarır.

Kullanım Örneği : Bir makaleyi düzenleyin

Birincil Aktör : Üye (Kayıtlı Kullanıcı)

Kapsam : bir Wiki sistemi

Seviye : ! (Kullanıcı hedefi veya deniz seviyesi)

Özet : (bir kullanıcı hikayesine veya bir destana eşdeğer )

Üye, okuduğu bir makalenin herhangi bir bölümünü (makalenin tamamını veya sadece bir bölümünü) düzenler. Düzenleme sırasında önizleme ve değişiklik karşılaştırmasına izin verilir.

Paydaşlar

...

son koşullar

Asgari Garantiler :

Başarı Garantileri :

Makale kaydedilir ve güncellenmiş bir görünüm gösterilir.
Makalenin edit kaydı sistem tarafından oluşturulmakta, bu sayede makaleyi izleyenler daha sonra güncellemeden haberdar olabilmektedir.

Ön koşullar :

Düzenleme yapılan makale üyeye sunulur.

Tetikleyiciler :

Üye, makale üzerinde (makalenin tamamı veya sadece bir bölüm için) bir düzenleme isteğinde bulunur.

Temel akış :

Sistem, üyenin düzenlemesi için bilgilendirici bir düzenleme özeti ile tüm makalenin ilgili içeriğiyle dolu yeni bir editör alanı/kutusu sağlar. Üye sadece makalenin bir bölümünü düzenlemek isterse, bölümün yalnızca orijinal içeriği gösterilir ve bölüm başlığı düzenleme özetinde otomatik olarak doldurulur.
Üye memnun kalana kadar makalenin içeriğini değiştirir.
Üye, düzenleme özetini doldurur, sisteme bu makaleyi izlemek isteyip istemediğini söyler ve düzenlemeyi gönderir.
Sistem makaleyi kaydeder, düzenleme olayını günlüğe kaydeder ve gerekli tüm son işlemleri tamamlar.
Sistem, makalenin güncel görünümünü üyeye sunar.

Uzantılar :

2-3.

a. Önizlemeyi Göster:

Üye , değiştirilen içeriği gönderen Önizlemeyi göster'i seçer .
Sistem, önizleme için oluşturulan güncellenmiş içeriğin eklenmesiyle 1. adımı yeniden çalıştırır ve üyeye düzenlemelerinin henüz kaydedilmediğini bildirir ve ardından devam eder.

B. Değişiklikleri göster:

Üye , değiştirilen içeriği gönderen Değişiklikleri göster'i seçer .
Sistem, üye tarafından yapılan mevcut düzenlemeler ile makalenin en son kaydedilen sürümü arasındaki farkları karşılaştırmanın sonuçlarını göstererek 1. adımı yeniden çalıştırır ve devam eder.

C. Düzenlemeyi iptal edin:

Üye İptal'i seçer .
Sistem, üyenin yaptığı tüm değişiklikleri atar ve ardından 5. adıma geçer.

4a. Zaman aşımı:

...

Avantajlar

Çevik hareketin başlangıcından bu yana, Extreme Programming'in kullanıcı hikayesi tekniği o kadar popüler oldu ki, birçok kişi bunun tüm projelerin çevik gereksinimleri için tek ve en iyi çözüm olduğunu düşünüyor. Alistair Cockburn , çevik geliştirmede hala kullanım senaryoları yazmasının beş nedenini sıralıyor .

Hedef adlarının listesi , sistemin sunacaklarının en kısa özetini sağlar ( kullanıcı hikayelerinden bile ). Ayrıca, ilk öncelikleri, tahminleri, ekip tahsisini ve zamanlamayı oluşturmak için kullanılacak bir proje planlama iskeleti sağlar.
Her bir kullanım senaryosunun ana başarı senaryosu, ilgili herkesin sistemin temelde ne yapacağı ve ne yapmayacağı konusunda bir anlaşmaya varmasını sağlar. Her bir özel satır öğesi gereksinimi için bağlam sağlar (örneğin, ayrıntılı kullanıcı öyküleri), başka bir yerde elde edilmesi çok zor olan bir bağlam.
Her bir kullanım durumunun genişletme koşulları, bir şekilde geliştirme süresinin ve bütçesinin %80'ini alan tüm küçük, önemsiz şeyleri araştırmak için bir çerçeve sağlar. Paydaşların yanıt alması uzun zaman alacak sorunları tespit edebilmeleri için ileriye dönük bir mekanizma sağlar. Bu sorunlar daha sonra programın önüne konulabilir ve alınmalıdır, böylece geliştirme ekibi onlar üzerinde çalışmaya başladığında yanıtlar hazır olabilir.
Kullanım senaryosu uzantısı senaryo parçaları, birçok ayrıntılı, genellikle zor ve göz ardı edilen iş sorularına yanıt sağlar: "Bu durumda ne yapmamız gerekiyor?" Programcıların sorunlar üzerinde düşünmesine yardımcı olan if...then...else ifadesiyle eşleşen bir düşünme/dokümantasyon çerçevesidir. Bunun dışında, programlama zamanında değil, araştırma zamanında yapılır.
Eksiksiz kullanım durumu seti, müfettişlerin her kullanıcının ihtiyaçlarını, sistemle ilgili her hedefi ve ilgili her iş değişkenini düşündüklerini göstermektedir.

Özetle, kullanım durumlarında sistem gereksinimlerinin belirlenmesi, geleneksel veya diğer yaklaşımlarla karşılaştırıldığında şu belirgin avantajlara sahiptir:

Kullanıcı odaklı

Kullanım senaryoları, yazılım gereksinimleri belirtim süreci için güçlü, kullanıcı merkezli bir araç oluşturur. Kullanım senaryosu modellemesi, tipik olarak , sistemle etkileşime giren kilit paydaş rollerini ( aktörler ) ve sistemin yerine getirmesi gereken amaç veya hedefleri (dışarıdan bir bakış açısı) belirlemekle başlar. Bu kullanıcı hedefleri daha sonra sistem tarafından sağlanan istenen işlevsel özellikleri veya hizmetleri temsil eden kullanım durumlarının adları veya başlıkları için ideal adaylar haline gelir. Bu kullanıcı merkezli yaklaşım, bir geliştirici veya sistem (içeriden) perspektifinden tahmin edilen önemsiz işlevlerin değil, gerçek iş değerine sahip olan ve kullanıcının gerçekten istediği şeyin geliştirilmesini sağlar.

Kullanım senaryosu yazma, yıllardır Kullanıcı Merkezli Tasarım (UCD) alanında önemli ve değerli bir analiz aracı olmuştur .

Daha iyi iletişim

Kullanım senaryoları genellikle yapılandırılmış şablonlarla doğal dillerde yazılır. Görsel UML diyagramları ile tamamlanan, hemen hemen herkes tarafından anlaşılabilen bu anlatımsal metinsel form (okunaklı gereksinim öyküleri), müşteriler, son kullanıcılar, geliştiriciler, testçiler ve yöneticiler dahil olmak üzere tüm paydaşlar arasında daha iyi ve daha derin iletişimi teşvik eder. Daha iyi iletişim, kalite gereksinimleri ve dolayısıyla sunulan kalite sistemleri ile sonuçlanır.

Yapılandırılmış keşif yoluyla kalite gereksinimleri

Kullanım senaryolarıyla ilgili en güçlü şeylerden biri , özellikle ana başarı senaryosu (temel akış) ve uzantı senaryosu parçaları (uzantılar, istisnai ve/veya alternatif akışlar) olmak üzere , kullanım senaryosu şablonlarının biçimlerinde bulunur . Bir kullanım senaryosunu ön koşullardan son koşullara kadar adım adım analiz etme, karmaşık, normalde gizli ve göz ardı edilen, görünüşte önemsiz ama gerçekçi olarak çoğu zaman maliyetli gereksinimleri belirlemek için kullanım senaryosu akışlarının temelden uzantılara kadar her eylem adımını araştırmak ve araştırmak (Cockburn'ün belirttiği gibi) yukarıda), sistematik olarak açık, istikrarlı ve kalite gereksinimleri elde etmenin yapılandırılmış ve faydalı bir yoludur.

Kullanıcı hedefine ulaşmak için bir kullanım senaryosunun eylem adımlarını en aza indirmek ve optimize etmek , sistemin daha iyi etkileşim tasarımına ve kullanıcı deneyimine de katkıda bulunur .

Testi ve kullanıcı belgelerini kolaylaştırın

Bir eylem veya olay akışı yapısına dayalı içerikle, iyi yazılmış bir kullanım senaryoları modeli, aynı zamanda, çabaya değer bir yatırım olan sistem veya ürünün test senaryolarının ve kullanıcı kılavuzlarının tasarımı için mükemmel bir temel ve değerli kılavuzlar olarak hizmet eder. ön ödeme. Bir kullanım senaryosunun akış yolları ile test senaryoları arasında bariz bağlantılar vardır. Bir kullanım senaryosundan senaryoları (kullanım senaryosu örneklerinin çalıştırılması) aracılığıyla işlevsel test senaryolarının türetilmesi basittir.

sınırlamalar

Kullanım durumlarının sınırlamaları şunları içerir:

Kullanım durumları, bir sistemin etkileşime dayalı olmayan gereksinimlerini (algoritma veya matematiksel gereksinimler gibi) veya işlevsel olmayan gereksinimleri (platform, performans, zamanlama veya güvenlik açısından kritik yönler gibi) yakalamak için uygun değildir . Bunlar, başka yerlerde bildirimsel olarak daha iyi belirtilmiştir.
Kullanım senaryolarının tam olarak standart tanımları olmadığından, her proje kendi yorumunu oluşturmalıdır.
Gibi bazı kullanım durumunda ilişkiler, uzanır , yorumlanmasında belirsizdir ve Cockburn (Problem # 6) tarafından işaret edildiği gibi paydaşların anlamak için zor olabilir
Kullanım senaryosu geliştiricileri , bir kullanım senaryosuna dahil etmek için kullanıcı arabirimi (UI) bağımlılığı düzeyini belirlemeyi genellikle zor bulur . Kullanım senaryosu teorisi, kullanıcı arayüzünün kullanım senaryolarına yansıtılmadığını öne sürse de, kullanım senaryolarının görselleştirilmesini zorlaştırdığından tasarımın bu yönünü soyutlamak zor olabilir. Yazılım mühendisliğinde bu zorluk, örneğin bir izlenebilirlik matrisi ile gereksinim izlenebilirliği uygulanarak çözülür . UI öğelerini kullanım durumları ile ilişkilendirmeye yönelik başka bir yaklaşım, kullanım durumundaki her adıma bir UI tasarımı eklemektir. Buna kullanım senaryosu storyboard denir.
Kullanım durumları aşırı vurgulanabilir. Bertrand Meyer , sistem tasarımını tam anlamıyla kullanım durumlarından yola çıkarak ve diğer potansiyel olarak değerli gereksinim analizi tekniklerini hariç tutarak kullanım durumlarını kullanmak gibi konuları tartışıyor.
Kullanım senaryoları, test tasarımı için bir başlangıç noktasıdır, ancak her testin kendi başarı kriterlerine ihtiyacı olduğundan, her yol için ayrı son koşullar sağlamak üzere kullanım senaryolarının değiştirilmesi gerekebilir.
Kullanım senaryoları, hedefleri ve bağlamları içerse de, bu hedeflerin ve hedeflerin arkasındaki motivasyonların (paydaşların endişeleri ve etkileşimsizlik de dahil olmak üzere değerlendirmeleri) çatışır veya diğer sistem hedeflerini olumsuz/olumlu etkileyip etkilemediği, hedefe yönelik gereksinim modelleme tekniklerine ( BMM , I gibi) tabidir. * , KAOS ve ArchiMate ZIRH).

kavram yanılgıları

Kullanım durumları hakkında yaygın yanlış anlamalar şunlardır:

Kullanıcı hikayeleri çeviktir; kullanım durumları değildir.

Agile ve Scrum , gereksinim teknikleri konusunda tarafsızdır. Scrum Primer'ın belirttiği gibi,

Ürün İş Listesi kalemleri açık ve sürdürülebilir bir şekilde ifade edilir. Yaygın yanlış anlamanın aksine, Ürün İş Listesi "kullanıcı hikayeleri" içermez; sadece öğeleri içerir. Bu öğeler, kullanıcı öyküleri, kullanım durumları veya grubun yararlı bulduğu diğer gereksinimler yaklaşımı olarak ifade edilebilir. Ancak yaklaşım ne olursa olsun, çoğu öğe müşterilere değer sunmaya odaklanmalıdır.

Kullanım senaryosu teknikleri, bir kullanım senaryosunu aşamalı olarak zenginleştirmek için kullanım senaryosu dilimlerini kullanarak Çevik yaklaşımları dikkate alacak şekilde geliştirilmiştir.

Kullanım durumları esas olarak diyagramlardır.

Craig Larman , "kullanım senaryoları diyagram değil, metindir" diye vurguluyor.

Kullanım senaryolarında çok fazla kullanıcı arayüzü ile ilgili içerik var.

Bazılarının dediği gibi,

Kullanım senaryoları genellikle, sıfırdan yeni bir sistemin gereksinimlerini yakalamak için pek uygun olmayan bir ayrıntı düzeyi (yani etiketlerin ve düğmelerin adlandırılması) içerecektir.

Acemi yanlış anlamalar. İyi yazılmış bir kullanma durumu her adım sunmalıdır aktör hedeflerini veya niyetlerini (fonksiyonel gereksinimleri özü) ve normalde herhangi bir kullanıcı arabirimi ayrıntılarını UI işlemleri vb etiket ve düğmeler, ör adlandırma, bir olduğunu içermemelidir kötü kullanım senaryosu yazımı gereksiz yere karmaşıklaştıracak ve uygulanmasını sınırlayacaktır.

Yeni bir sistemin gereksinimlerini sıfırdan yakalamaya gelince, kullanım senaryosu şemaları ve kullanım senaryosu özetleri genellikle kullanışlı ve değerli araçlar olarak kullanılır, en az kullanıcı hikayeleri kadar hafiftir .

Büyük sistemler için kullanım senaryoları yazmak sıkıcı ve zaman kaybıdır.

Bazılarının dediği gibi,

Kullanım senaryosunun formatı, büyük bir sistemi (örn. CRM sistemi) birkaç yüz sayfadan daha kısa bir sürede tanımlamayı zorlaştırıyor. Zaman alıcıdır ve kendinizi gereksiz miktarda yeniden çalışma yaparak zaman harcarken bulacaksınız.

Hiç değer katmayan veya çok az değer katan ve çok fazla yeniden çalışmayla sonuçlanan sıkıcı kullanım senaryoları yazmak için çok zaman harcamak, kötü bir kokudur, bu da yazarların iyi becerili olmadıklarını ve kaliteli kullanım senaryolarını hem verimli hem de etkili bir şekilde nasıl yazacakları konusunda çok az bilgiye sahip olduklarını gösterir. Kullanım senaryoları yinelemeli, artımlı ve evrimsel ( çevik ) bir şekilde yazılmalıdır . Kullanım senaryosu şablonlarının uygulanması, bir kullanım senaryosu şablonunun tüm alanlarının baştan veya özel olarak ayrılmış bir aşamada, yani geleneksel şelale geliştirme modelindeki gereksinim aşamasında kullanılması ve kapsamlı bir şekilde doldurulması gerektiği anlamına gelmez .

Aslında, bu popüler şablon stilleri tarafından formüle edilen kullanım senaryosu biçimleri , örneğin RUP'lar ve Cockburn'ler (ayrıca OUM yöntemi tarafından benimsenmiştir ) vb., karmaşık gereksinimleri yakalamak, analiz etmek ve belgelemek için pratikte değerli ve yardımcı araçlar olarak kanıtlanmıştır. büyük sistemler. İyi bir kullanım durumu belgesinin ( model ) kalitesi, büyük ölçüde veya yalnızca boyutuna göre değerlendirilmemelidir. Büyük bir sistemin kaliteli ve kapsamlı bir kullanım senaryosu modelinin , yazarlarının zayıf yazma becerileri nedeniyle değil, esas olarak eldeki sorunun doğal karmaşıklığı nedeniyle nihayet yüzlerce sayfaya dönüşmesi de mümkündür.

Araçlar

Kullanım senaryoları yazmak için genellikle şablon destekli metin düzenleyiciler ve/veya kelime işlemciler kullanılır. Büyük ve karmaşık sistem gereksinimleri için özel kullanım senaryosu araçları yardımcı olur.

İyi bilinen kullanım senaryosu araçlarından bazıları şunlardır:

Vaka Tamamlandı
Kurumsal Mimar
MagicDraw
Rational Software'in RequisitePro'su - 1990'larda erken, iyi bilinen kullanım durumu ve gereksinim yönetimi araçlarından biri.
Yazılım Fikirleri Modelleyici
Wiki yazılımı - ekiplerin ortaklaşa kullanım senaryoları yazması ve yönetmesi için iyi araçlar.

Çoğu UML aracı , kullanım senaryolarının hem metin yazmayı hem de görsel modellemesini destekler.

Ayrıca bakınız

Referanslar

daha fazla okuma

Alexander, Ian ve Beus-Dukic, Ljerka. Gereksinimleri Keşfetme: Ürünler ve Hizmetler Nasıl Belirlenir . Wiley, 2009.
Alexander, Ian ve Maiden, Neil. Senaryolar, Hikayeler, Kullanım Örnekleri . Wiley 2004.
Zırh, Frank ve Granville Miller. Gelişmiş Kullanım Durumu Modellemesi: Yazılım Sistemleri . Addison-Wesley, 2000.
Kurt Bittner, Ian Spence, Use Case Modeling , Addison-Wesley Professional, 20 Ağustos 2002.
Cockburn, Alistair. Etkili Kullanım Örnekleri Yazma. Addison-Wesley, 2001.
Larry Constantine, Lucy Lockwood, Kullanım için Yazılım: Kullanım Merkezli Tasarımın Temel Modelleri ve Yöntemleri için Pratik Bir Kılavuz , Addison-Wesley, 1999.
Denney, Richard. Kullanım Örnekleriyle Başarıya Ulaşmak: Kaliteyi Sunmak İçin Akıllı Çalışmak . Addison-Wesley, 2005.
Fowler, Martin. UML Distile (Üçüncü Baskı) . Addison-Wesley, 2004.
Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering - A Use Case Driven Approach , Addison-Wesley, 1992.
Jacobson Ivar, Spence I., Bittner K. Use Case 2.0: The Guide to Successing with Use Cases , IJI SA, 2011.
Dean Leffingwell, Don Widrig, Yazılım Gereksinimlerini Yönetme: Kullanım Örneği Yaklaşımı , Addison-Wesley Professional. 7 Aralık 2012.
Kulak, Daryl ve Eamonn Guiney. Kullanım durumları: bağlamdaki gereksinimler. Addison-Wesley, 2012.
Meyer, Bertrand. Nesneye Yönelik Yazılım İnşaatı. (2. Baskı). Prentice Salonu, 2000.
Schneider, Geri ve Winters, Jason P. Kullanım Durumlarını Uygulamak 2. Baskı: Pratik Bir Kılavuz . Addison-Wesley, 2001.
Wazlawick, Raul S. Bilgi Sistemleri için Nesneye Dayalı Analiz ve Tasarım: UML, OCL ve IFML ile Modelleme . Morgan Kaufmann, 2014.

Dış bağlantılar

Alistair Cockburn tarafından hazırlanan kullanım durumu sütunu ve Temel Kullanım Örneği Şablonu
GSA'nın Usability.gov sitesinde Kullanım Örnekleri
Academia.edu'da paydaş analizi "Project Icarus" için kullanım senaryolarının uygulanması
"Kullanım durumunda" araması at IBM Geliştirici

Languages

In other projects