Use Case

Dalam rekayasa perangkat lunak dan sistem, use case adalah daftar tindakan atau langkah-langkah acara yang biasanya mendefinisikan interaksi antara peran (dikenal dengan Unified Modeling Language sebagai aktor) dan sebuah sistem untuk mencapai suatu tujuan. Aktor tersebut bisa menjadi manusia atau sistem eksternal lainnya. Dalam kasus penggunaan teknik sistem digunakan pada tingkat yang lebih tinggi daripada rekayasa perangkat lunak yang sering mewakili misi atau tujuan pemangku kepentingan. Persyaratan rinci kemudian dapat ditangkap dalam Sistem Pemodelan Bahasa (SysML) atau sebagai laporan kontraktual.

Analisis kasus penggunaan merupakan teknik analisis persyaratan penting dan berharga yang telah banyak digunakan dalam rekayasa perangkat lunak modern sejak diperkenalkan secara formal oleh Ivar Jacobson pada tahun 1992. Pengembangan use case driven adalah karakteristik utama dari banyak model dan kerangka proses seperti ICONIX, Unified Proses (UP), IBM Rational Unified Process (RUP), dan Oracle Unified Method (OUM). Dengan sifat iteratif, inkremental dan evolusioner yang melekat, use case juga sesuai untuk pengembangan tangkas.

History

Pada tahun 1986, Ivar Jacobson pertama kali merumuskan teknik pemodelan tekstual, struktural, dan visual untuk menentukan kasus penggunaan. Pada tahun 1992, buku yang ditulis bersamanya, Object-Oriented Software Engineering - Pendekatan Use Case Driven membantu mempopulerkan teknik untuk menangkap persyaratan fungsional, terutama dalam pengembangan perangkat lunak. Awalnya dia menggunakan istilah penggunaan skenario dan kasus penggunaan - yang terakhir merupakan terjemahan langsung dari istilah Swedianya användningsfall - namun menemukan bahwa kedua istilah ini tidak terdengar alami dalam bahasa Inggris, dan akhirnya dia menyelesaikan kasus penggunaan.

Sejak saat itu, para ahli lain juga menyumbang banyak teknik, terutama Alistair Cockburn, Larry Constantine, Dean Leffingwell, Kurt Bittner dan Gunnar Overgaard.

Pada tahun 2011, Jacobson menerbitkan sebuah update untuk karyanya, yang disebut Use Case 2.0, dengan maksud menggabungkan banyak pengalaman praktisnya dalam menerapkan kasus penggunaan sejak awal konsep aslinya.

Templates

Ada banyak cara untuk menulis use case dalam teks, mulai dari use case brief, casual, outline, sampai dressed dll, dan dengan beragam template. Menulis kasus penggunaan dalam template yang dibuat oleh berbagai vendor atau pakar adalah praktik industri umum untuk mendapatkan persyaratan sistem fungsional berkualitas tinggi

Design scopes

Cockburn menyarankan menganotasikan setiap kasus penggunaan dengan simbol untuk menunjukkan "Lingkup Desain", yang mungkin berupa kotak hitam (detail internal tersembunyi) atau kotak putih (detail internal ditunjukkan). Lima simbol tersedia:

Scope	Icon
Organization (black-box)	Filled House
Organization (white-box)	Unfilled House
System (black-box)	Filled Box
System (white-box)	Unfilled Box
Component	Screw or Bolt

Goal levels

Cockburn menyarankan menganotasikan setiap use case dengan simbol untuk menunjukkan "Goal Level"; tingkat yang lebih disukai adalah "User-goal"

Goal Level	Icon	Symbol
Very High Summary	Cloud	++
Summary	Flying Kite	+
User Goal	Waves at Sea	!
Subfunction	Fish	-
Too Low	Seabed Clam-Shell	--

Fully dressed

Cockburn menjelaskan struktur yang lebih rinci untuk kasus penggunaan, namun mengizinkannya disederhanakan bila diperlukan detail yang lebih sedikit. Template use case lengkap mencantumkan bidang berikut:

• Aktor Utama
• Tujuan dalam Konteks
• Cakupan
• Tingkat
• Pemangku kepentingan dan Minat
• Prasyarat
• Jaminan Minimal
• Jaminan Sukses
• Pelatuk
• Skenario Sukses Utama
• Ekstensi
• Daftar Variasi Teknologi & Data

Selain itu, Cockburn menyarankan menggunakan dua perangkat untuk menunjukkan sifat dari setiap kasus penggunaan: ikon untuk lingkup desain dan tingkat sasaran.

Pendekatan Cockburn telah mempengaruhi penulis lain; Sebagai contoh, Alexander dan Beus-Dukic menggeneralisasi template "Fully wired use case" dari perangkat lunak ke sistem dari semua jenis, dengan bidang berikut berbeda dari Cockburn:

Variasi skenario "(mungkin bercabang dari dan mungkin kembali ke skenario utama)"

Pengecualian "yaitu kejadian pengecualian dan skenario penanganan pengecualian mereka"

Casual

Cockburn mengakui bahwa proyek mungkin tidak selalu membutuhkan kasus penggunaan " lengkap". Dia menggambarkan kasus penggunaan kasual dengan petak berikut ini:

• Judul (tujuan)
• Aktor Utama
• Cakupan
• Tingkat

(Cerita): tubuh dari kasus penggunaan hanyalah sebuah paragraf atau dua teks, secara informal menggambarkan apa yang terjadi.

Fowler style

Martin Fowler menyatakan "Tidak ada cara standar untuk menulis konten dari kasus penggunaan, dan format yang berbeda bekerja dengan baik dalam kasus yang berbeda.": 100 Dia menggambarkan "gaya umum untuk digunakan" sebagai berikut: 101

• Judul: "tujuan kasus penggunaan sedang berusaha memuaskan" : 101
• Skenario Sukses Utama: daftar nomor urut : 101
• Langkah: "pernyataan sederhana tentang interaksi antara aktor dan sistem" : 101
• Ekstensi: daftar nomor terpisah, satu per Ekstensi : 101
• Ekstensi: "kondisi yang menghasilkan interaksi yang berbeda dari .. skenario sukses utama". Perpanjangan dari langkah utama 3 diberi nomor 3a, dan seterusnya. : 101

Gaya Fowler juga bisa dilihat sebagai varian sederhana dari template Cockburn.

Actors

Kasus penggunaan mendefinisikan interaksi antara aktor eksternal dan sistem yang sedang dipertimbangkan untuk mencapai suatu tujuan. Aktor harus bisa membuat keputusan, tapi tidak perlu menjadi manusia: "Seorang aktor mungkin seseorang, perusahaan atau organisasi, program komputer, atau sistem komputer-perangkat keras, perangkat lunak, atau keduanya."  Aktor selalu stakeholder, namun tidak semua pemangku kepentingan adalah aktor, karena mereka "tidak pernah berinteraksi langsung dengan sistem, walaupun mereka memiliki hak untuk peduli bagaimana sistem berperilaku."  Misalnya, "pemilik sistem, dewan perusahaan direktur, dan badan pengatur seperti Internal Revenue Service dan Department of Insurance "semuanya bisa menjadi pemangku kepentingan namun tidak mungkin menjadi aktor.

Demikian pula, seseorang yang menggunakan sistem dapat digambarkan sebagai aktor yang berbeda karena dia memainkan peran yang berbeda. Misalnya, pengguna "Joe" dapat berperan sebagai Pelanggan saat menggunakan Mesin Teller Otomatis untuk menarik uang tunai dari akunnya sendiri, atau memainkan peran sebagai Pengusaha Bank saat menggunakan sistem untuk mengisi kembali laci uang tunai atas nama bank.

Aktor sering bekerja atas nama orang lain. Cockburn menulis bahwa "Hari ini saya menulis 'sales rep untuk pelanggan' atau 'panitera untuk departemen pemasaran' untuk menangkap bahwa pengguna sistem tersebut bertindak untuk orang lain." Ini memberitahu proyek bahwa "antarmuka pengguna dan jarak bebas keamanan" harus dirancang untuk petugas penjualan dan juru tulis, namun departemen pelanggan dan pemasaran adalah peran yang terkait dengan hasilnya.

Pemangku kepentingan mungkin memainkan peran aktif dan tidak aktif: misalnya, Konsumen adalah "pembeli pasar massal" (tidak berinteraksi dengan sistem) dan Pengguna (seorang aktor, yang secara aktif berinteraksi dengan produk yang dibeli). Pada gilirannya, Pengguna adalah "operator normal" (aktor yang menggunakan sistem untuk tujuan yang dimaksudkan) dan "penerima manfaat fungsional" (pemangku kepentingan yang mendapatkan keuntungan dari penggunaan sistem). Misalnya, ketika pengguna "Joe" menarik uang dari akunnya, dia mengoperasikan Mesin Teller Otomatis dan mendapatkan hasilnya atas namanya sendiri.

Cockburn menyarankan untuk mencari aktor di antara pemangku kepentingan sebuah sistem, aktor utama dari kasus penggunaan, sistem yang dirancang (SuD) itu sendiri, dan akhirnya di antara "aktor internal", yaitu komponen sistem di bawah desain

Business Use Case

Visual modeling

Use case bukan hanya teks, tapi juga diagram, jika diperlukan. Dalam Unified Modeling Language, hubungan antara use case dan actor diwakili dalam use case diagram yang aslinya berdasarkan notasi Objectation Ivar Jacobson. SysML menggunakan notasi yang sama pada tingkat blok sistem.

Selain itu, diagram UML perilaku lainnya seperti diagram aktivitas, diagram urutan, diagram komunikasi dan diagram mesin negara juga dapat digunakan untuk memvisualisasikan use case yang sesuai. Secara khusus, Diagram Urutan Sistem (SSD) adalah diagram urutan yang sering digunakan untuk menunjukkan interaksi antara aktor eksternal dan sistem yang sedang dirancang (SuD), biasanya untuk memvisualisasikan skenario tertentu dari kasus penggunaan.

Use case analysis biasanya dimulai dengan menggambar use case diagram. Untuk pengembangan tangkas, model persyaratan dari banyak diagram UML yang menggambarkan kasus penggunaan ditambah beberapa deskripsi tekstual, catatan atau contoh kasus penggunaan akan sangat ringan dan cukup untuk penggunaan proyek kecil atau mudah. Sebagai pelengkap yang baik untuk menggunakan teks kasus, diagram visual representasi kasus penggunaan juga alat fasilitasi yang efektif untuk pemahaman, komunikasi dan perancangan persyaratan perilaku sistem yang lebih baik.

Examples

Berikut adalah contoh kasus penggunaan yang ditulis dengan versi modifikasi dari template bergaya Cockburn. Perhatikan bahwa tidak ada tombol, kontrol, bentuk, atau elemen UI lainnya dan operasi dalam deskripsi use case dasar, di mana hanya tujuan, sub tujuan, atau niat pengguna yang dinyatakan dalam setiap langkah aliran dasar atau ekstensi. Praktik ini membuat spesifikasi kebutuhan lebih jelas, dan memaksimalkan fleksibilitas desain dan implementasi

Use Case: Edit an article

• Primary Actor: Member (Registered User)
  Scope: a Wiki system
  Level: ! (User goal or sea level)
  Brief: (equivalent to a user story or an epic)

  The member edits any part (the entire article or just a section) of an article he/she is reading. Preview and changes comparison are allowed during the editing.

  Stakeholders
  ...
  Postconditions

  Minimal Guarantees:

  Success Guarantees:
  

  • The article is saved and an updated view is shown.
  • An edit record for the article is created by the system, so watchers of the article can be informed of the update later.

  Preconditions:

  The article with editing enabled is presented to the member.

  Triggers:

  The member invokes an edit request (for the full article or just one section) on the article.

  Basic flow:
  1. The system provides a new editor area/box filled with all the article's relevant content with an informative edit summary for the member to edit. If the member just wants to edit a section of the article, only the original content of the section is shown, with the section title automatically filled out in the edit summary.
  2. The member modifies the article's content till satisfied.
  3. The member fills out the edit summary, tells the system if he/she wants to watch this article, and submits the edit.
  4. The system saves the article, logs the edit event and finishes any necessary post processing.
  5. The system presents the updated view of the article to the member.
  Extensions:
  2-3.

  a. Show preview:
  

  1. The member selects Show preview which submits the modified content.
  2. The system reruns step 1 with addition of the rendered updated content for preview, and informs the member that his/her edits have not been saved yet, then continues.

  b. Show changes:
  

  1. The member selects Show changes which submits the modified content.
  2. The system reruns step 1 with addition of showing the results of comparing the differences between the current edits by the member and the most recent saved version of the article, then continues.

  c. Cancel the edit:
  

  1. The member selects Cancel.
  2. The system discards any change the member has made, then goes to step 5.

  4a. Timeout:
  ...

Advantages

Sejak dimulainya gerakan gesit, teknik cerita pengguna dari Extreme Programming sangat populer sehingga banyak yang mengira ini adalah satu-satunya solusi terbaik untuk persyaratan tangkas dari semua proyek. Alistair Cockburn mendaftar lima alasan mengapa ia masih menulis kasus penggunaan dalam pengembangan tangkas.

Daftar nama sasaran memberikan ringkasan singkat tentang apa yang akan ditawarkan sistem (bahkan dari cerita pengguna). Ini juga menyediakan kerangka perencanaan proyek, yang akan digunakan untuk membangun prioritas awal, perkiraan, alokasi tim dan waktu.

Skenario sukses utama dari setiap kasus penggunaan membuat setiap orang terlibat dengan kesepakatan mengenai apa yang pada dasarnya sistem akan lakukan dan apa yang tidak akan dilakukan. Ini menyediakan konteks untuk setiap item kebutuhan item tertentu (misalnya cerita pengguna halus), konteks yang sangat sulit didapat di tempat lain.

Kondisi perpanjangan dari setiap kasus penggunaan menyediakan kerangka kerja untuk menyelidiki semua hal kecil dan picik yang entah bagaimana mengambil 80% dari waktu dan anggaran pembangunan. Ini memberi mekanisme di depan, sehingga para pemangku kepentingan dapat melihat isu-isu yang cenderung membutuhkan waktu lama untuk mendapatkan jawaban. Isu-isu ini bisa dan kemudian harus diimbangi jadwalnya, agar jawabannya bisa siap saat tim pengembang berkeliling untuk mengerjakannya.

Fragmen skenario perpanjangan kasus penggunaan memberikan jawaban atas banyak pertanyaan bisnis yang terperinci, seringkali sulit dipahami dan diabaikan: "Apa yang harus kita lakukan dalam kasus ini?" Ini adalah kerangka pemikiran / dokumentasi yang sesuai dengan jika ... lalu ... pernyataan lain yang membantu pemrogram memikirkan masalah. Kecuali itu dilakukan pada waktu penyidikan, bukan waktu pemrograman.

Use case set lengkap menunjukkan bahwa para peneliti memikirkan kebutuhan setiap pengguna, setiap tujuan yang mereka miliki sehubungan dengan sistem, dan setiap varian bisnis terlibat.

Singkatnya, menentukan persyaratan sistem dalam kasus penggunaan memiliki manfaat nyata dibandingkan dengan pendekatan tradisional atau pendekatan lainnya:

User focused

Use case merupakan alat yang kuat dan user-centric untuk proses spesifikasi persyaratan perangkat lunak. Pemodelan kasus penggunaan biasanya dimulai dari identifikasi peran pemangku kepentingan utama (aktor) yang berinteraksi dengan sistem, dan tujuan atau sasaran yang harus dipenuhi sistem (perspektif luar). Tujuan pengguna ini kemudian menjadi kandidat ideal untuk nama atau judul dari kasus penggunaan yang mewakili fitur fungsional atau layanan yang diinginkan yang disediakan oleh sistem. Pendekatan yang berpusat pada pengguna ini memastikan bahwa apa yang memiliki nilai bisnis sebenarnya dan pengguna benar-benar ingin dikembangkan, bukan fungsi sepele yang berspekulasi dari perspektif pengembang atau sistem (dalam). Use case authoring telah menjadi alat analisis yang penting dan berharga dalam domain User-Centered Design (UCD) selama bertahun-tahun.

Better communication

Kasus penggunaan sering ditulis dalam bahasa alami dengan template terstruktur. Bentuk tekstual naratif ini (cerita kebutuhan yang mudah dibaca), dapat dimengerti oleh hampir semua orang, dilengkapi dengan diagram UML visual mendorong komunikasi yang lebih baik dan lebih dalam di antara semua pemangku kepentingan, termasuk pelanggan, pengguna akhir, pengembang, penguji dan manajer. Komunikasi yang lebih baik menghasilkan persyaratan kualitas dan dengan demikian sistem mutu disampaikan.

Quality requirements by structured exploration

Salah satu hal yang paling kuat tentang kasus penggunaan berada dalam format template use case, terutama skenario keberhasilan utama (aliran dasar) dan fragmen skenario ekstensi (ekstensi, arus luar biasa dan / atau alternatif). Menganalisis kasus penggunaan selangkah demi selangkah dari prasyarat hingga kondisi pasca, mengeksplorasi dan menyelidiki setiap langkah tindakan dari arus use case, dari dasar hingga ekstensi, untuk mengidentifikasi persyaratan yang rumit, biasanya tersembunyi dan diabaikan, yang tampaknya sepele tapi realistis seringkali mahal (seperti yang dilaporkan oleh Cockburn di atas), adalah cara terstruktur dan bermanfaat untuk mendapatkan persyaratan yang jelas, stabil dan berkualitas secara sistematis.

Meminimalkan dan mengoptimalkan langkah-langkah tindakan dari use case untuk mencapai tujuan pengguna juga berkontribusi terhadap desain interaksi dan pengalaman pengguna sistem yang lebih baik.

Facilitate testing and user documentation

Dengan konten berdasarkan struktur aktivitas tindakan atau peristiwa, model kasus penggunaan yang ditulis dengan baik juga berfungsi sebagai dasar yang sangat baik dan pedoman yang berharga untuk merancang kasus uji dan manual pengguna sistem atau produk, yang merupakan investasi yang layak untuk dilakukan di depan. Ada hubungan yang jelas antara jalur aliran dari kasus penggunaan dan kasus uji. Turunkan kasus uji fungsional dari kasus penggunaan melalui skenarionya (contoh kasus penggunaan) sangat mudah dilakukan.

Limitations

Keterbatasan kasus penggunaan meliputi:

Kasus penggunaan tidak sesuai untuk menangkap persyaratan berbasis sistem yang tidak berinteraksi (seperti persyaratan algoritma atau matematis) atau persyaratan non-fungsional (seperti aspek platform, kinerja, waktu, atau aspek kritis keselamatan). Ini lebih baik ditentukan secara dekaden di tempat lain.

Karena tidak ada definisi standar tentang kasus penggunaan, masing-masing proyek harus membentuk interpretasinya sendiri.

Beberapa hubungan use case, seperti meluas, tidak jelas dalam interpretasi dan dapat menjadi sulit bagi pemangku kepentingan untuk memahami seperti yang ditunjukkan oleh Cockburn

Pengembang use case sering merasa sulit untuk menentukan tingkat ketergantungan antar pengguna (UI) untuk disertakan dalam use case. Sementara teori use case menunjukkan bahwa UI tidak tercermin dalam kasus penggunaan, dapat menjadi aneh untuk menghilangkan aspek desain ini, karena membuat kasus penggunaan sulit untuk dipvisualisasikan. Dalam rekayasa perangkat lunak, kesulitan ini diselesaikan dengan menerapkan ketertelusuran persyaratan, misalnya dengan matriks traceability. Pendekatan lain untuk menghubungkan elemen UI dengan kasus penggunaan, adalah melampirkan desain UI ke setiap langkah dalam use case. Ini disebut papan cerita use case.

Kasus penggunaan bisa terlalu ditekankan. Bertrand Meyer membahas masalah-masalah seperti mendesain sistem mengemudi secara harfiah dari kasus penggunaan, dan menggunakan kasus penggunaan dengan mengesampingkan teknik analisis persyaratan potensial lainnya. 

Kasus penggunaan adalah titik awal untuk desain uji, namun karena setiap tes memerlukan kriteria keberhasilannya sendiri, kasus penggunaan mungkin perlu dimodifikasi untuk memberikan kondisi pasca-kondisi yang berbeda untuk setiap jalur. 

Meskipun kasus penggunaan mencakup tujuan dan konteks, apakah sasaran dan motivasi di balik sasaran (konflik pemangku kepentingan dan penilaian mereka termasuk non-interaksi) atau dampak negatif terhadap sasaran sistem lainnya tunduk pada teknik pemodelan persyaratan yang berorientasi pada tujuan (seperti BMM, I *, KAOS dan ArchiMate ARMOR).