Sebuah narasi use case yang dirancang dengan baik mengubah tujuan sistem yang abstrak menjadi spesifikasi yang dapat diambil tindakan, langkah demi langkah. Dengan mendokumentasikan interaksi yang tepat, titik keputusan, dan jalur penanganan kesalahan, tim membangun satu sumber kebenaran yang menyelaraskan pemilik produk, pengembang, penguji, dan analis bisnis. Studi kasus ini mengeksplorasi struktur dokumentasi use case yang efektif, menunjukkan bagaimana narasi terstruktur, templat standar, dan model visual pendukung berkonvergensi untuk menghasilkan spesifikasi fungsional yang tidak ambigu. Melalui skenario penarikan tunai ATM yang praktis, kita akan meninjau bagaimana menangkap logika bisnis, mengelola penyimpangan, dan mempertahankan pelacakan dari konsep hingga implementasi.<\/p>\n
![\"Mastering](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ff6c455a21.png\")
<\/p>\n
\n
1. Konsep Dasar<\/h2>\n
Sebelum menulis spesifikasi rinci, sangat penting untuk memahami komponen inti yang memberikan integritas struktural pada use case:<\/p>\n
- \n
- \n
Aktor:<\/strong>\u00a0Setiap entitas (manusia, sistem eksternal, atau perangkat keras) yang berinteraksi dengan sistem untuk mencapai tujuan.<\/p>\n
- \n
- \n
Aktor Utama:<\/em>\u00a0Memicu interaksi untuk memenuhi tujuan tertentu (misalnya, Pelanggan Bank).<\/p>\n<\/li>\n
- \n
Aktor Sekunder\/Pendukung:<\/em>\u00a0Menyediakan layanan atau data yang diperlukan ke sistem selama eksekusi (misalnya, API Perbankan Inti atau Gerbang Pembayaran).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Prasyarat:<\/strong>\u00a0Keadaan sistem atau lingkungan yang harus sudah ada sebelum use case dapat dimulai. Ini diasumsikan benar dan tidak divalidasi dalam alur.<\/p>\n<\/li>\n
- \n
Pemicu:<\/strong>\u00a0Kejadian tertentu atau tindakan pengguna yang memicu use case.<\/p>\n<\/li>\n
- \n
Skenario Sukses Utama (Alur Dasar):<\/strong>\u00a0Urutan langkah optimal tanpa kesalahan yang mengarah pada penyelesaian sukses tujuan aktor. Sering disebut sebagai ‘jalur bahagia’.<\/p>\n<\/li>\n
- \n
Alur Ekstensi \/ Alternatif & Penyimpangan:<\/strong>\u00a0Penyimpangan yang didokumentasikan dari alur utama.<\/p>\n
- \n
- \n
Alur Alternatif:<\/em>\u00a0Jalur yang berbeda namun valid untuk mencapai tujuan yang sama (misalnya, menggunakan metode pembayaran yang berbeda).<\/p>\n<\/li>\n
- \n
Alur Penyimpangan:<\/em>\u00a0Kondisi kesalahan, kegagalan validasi, atau keterbatasan sistem yang mengganggu tujuan dan memerlukan penanganan khusus.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Pasca kondisi:<\/strong>\u00a0Keadaan yang dijamin dari sistem, data, atau lingkungan setelah penyelesaian use case yang sukses.<\/p>\n<\/li>\n<\/ul>\n
\n2. Templat Spesifikasi Standar<\/h2>\n
Konsistensi sangat penting untuk kemudahan pemeliharaan. Templat berikut menyediakan struktur yang banyak diadopsi yang menjamin kelengkapan tanpa kelebihan kata-kata yang tidak perlu:<\/p>\n
\n\n
\n \nBidang<\/th>\n Deskripsi<\/th>\n<\/tr>\n<\/thead>\n \n ID dan Nama Kasus Penggunaan<\/strong><\/td>\n Identifikasi unik dan judul verba-benda (contoh:\u00a0 UC-201: Tarik Tunai<\/code>).<\/td>\n<\/tr>\n\n Pemain(s)<\/strong><\/td>\n Mencantumkan semua peserta utama dan sekunder.<\/td>\n<\/tr>\n \n Deskripsi<\/strong><\/td>\n Ringkasan singkat mengenai tujuan dan nilai bisnis kasus penggunaan.<\/td>\n<\/tr>\n \n Prasyarat<\/strong><\/td>\n Keadaan sistem atau lingkungan yang diperlukan sebelum dimulai.<\/td>\n<\/tr>\n \n Pemicu<\/strong><\/td>\n Peristiwa tepat yang memulai interaksi.<\/td>\n<\/tr>\n \n Skenario Sukses Utama<\/strong><\/td>\n Langkah-langkah berurutan yang diberi nomor yang menjelaskan jalur sukses standar.<\/td>\n<\/tr>\n \n Perluasan \/ Penyimpangan<\/strong><\/td>\n Aliran bercabang yang dipetakan ke langkah-langkah skenario utama tertentu (contoh:\u00a0 3a<\/code>,\u00a08b<\/code>).<\/td>\n<\/tr>\n\n Pasca-kondisi<\/strong><\/td>\n Keadaan sistem akhir setelah penyelesaian yang sukses.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n3. Narasi Studi Kasus: UC-201 Tarik Tunai<\/h2>\n
Spesifikasi berikut menunjukkan bagaimana template dan konsep dasar diterapkan pada skenario perbankan dunia nyata.<\/p>\n
ID dan Nama Kasus Penggunaan:<\/strong>\u00a0
UC-201 - Tarik Tunai<\/code>
\nPemain Utama:<\/strong>\u00a0Pelanggan Bank
\nPemain Sekunder:<\/strong>\u00a0Sistem Perbankan Inti \/ Jaringan ATM
\nDeskripsi:<\/strong>\u00a0Mendeskripsikan bagaimana seorang pelanggan bank yang telah diautentikasi menarik uang tunai dari rekening tabungan atau rekening giro mereka menggunakan mesin anjungan tunai otomatis (ATM).
\nPrasyarat:<\/strong>\u00a0ATM mempertahankan koneksi jaringan aktif dan memiliki cukup uang tunai fisik.
\nPemicu:<\/strong>\u00a0Pelanggan memasukkan kartu bank mereka ke dalam pembaca kartu ATM.<\/p>\nSkenario Sukses Utama (Alur Dasar)<\/h3>\n
- \n
- \n
Sistem membaca kartu bank dan meminta nomor identifikasi pribadi (PIN).<\/p>\n<\/li>\n
- \n
Pelanggan memasukkan PIN mereka.<\/p>\n<\/li>\n
- \n
Sistem memvalidasi PIN dengan Sistem Perbankan Inti.<\/p>\n<\/li>\n
- \n
Sistem menampilkan opsi transaksi yang tersedia.<\/p>\n<\/li>\n
- \n
Pelanggan memilih \u201cTarik Uang Tunai\u201d.<\/p>\n<\/li>\n
- \n
Sistem meminta jenis rekening (Giro\/Tabungan) dan jumlah penarikan.<\/p>\n<\/li>\n
- \n
Pelanggan memilih rekening tujuan dan memasukkan jumlah yang tersedia.<\/p>\n<\/li>\n
- \n
Sistem memverifikasi ketersediaan dana dengan Sistem Perbankan Inti.<\/p>\n<\/li>\n
- \n
Sistem mengurangi saldo rekening dan memerintahkan penarik uang tunai untuk melepaskan jumlah yang ditentukan.<\/p>\n<\/li>\n
- \n
Sistem menyalurkan uang tunai, mengeluarkan kartu, dan mencetak bukti transaksi.<\/p>\n<\/li>\n
- \n
Pelanggan mengambil uang tunai, kartu, dan bukti transaksi.<\/p>\n<\/li>\n<\/ol>\n
Perluasan (Alur Alternatif & Penyimpangan)<\/h3>\n
- \n
- \n
3a. PIN Tidak Valid:<\/strong><\/p>\n
- \n
- \n
Sistem memberi tahu Pelanggan bahwa PIN salah dan meminta untuk dimasukkan kembali.<\/p>\n<\/li>\n
- \n
Pelanggan memasukkan PIN baru.<\/p>\n<\/li>\n
- \n
Lanjutkan dari langkah 3.<\/em><\/p>\n<\/li>\n
- \n
Penyimpangan:<\/em>\u00a0Jika pelanggan memasukkan PIN yang tidak valid tiga kali berturut-turut, sistem akan menyimpan kartu dan menghentikan sesi.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n
- \n
8a. Dana Tidak Cukup:<\/strong><\/p>\n
- \n
- \n
Sistem menampilkan pesan kesalahan \u201cDana Tidak Cukup\u201d dan meminta Pelanggan untuk memasukkan jumlah yang lebih rendah atau membatalkan.<\/p>\n<\/li>\n
- \n
Pelanggan memilih \u201cBatal\u201d.<\/p>\n<\/li>\n
- \n
Sistem mengeluarkan kartu dan menghentikan sesi.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n
Pasca kondisi<\/h3>\n
Transaksi dicatat dengan aman, saldo akun diperbarui secara akurat, persediaan uang tunai ATM fisik berkurang sesuai, dan terminal kembali ke layar selamat datang siaga.<\/p>\n
\n4. Praktik Terbaik Penulisan<\/h2>\n
Untuk memastikan deskripsi use case tetap dapat diambil tindakan, dapat diskalakan, dan ramah bagi pengembang, patuhi pedoman yang telah ditetapkan ini:<\/p>\n
- \n
- \n
Pertahankan Perspektif Kotak Hitam:<\/strong>\u00a0Dokumentasikan\u00a0apa<\/em>\u00a0yang dilakukan sistem dari sudut pandang pengguna, bukan\u00a0bagaimana<\/em>\u00a0mencapainya secara internal. Hindari merujuk skema basis data, titik akhir API, atau penempatan piksel antarmuka pengguna.<\/p>\n<\/li>\n
- \n
Gunakan Kalimat Aktif & Tata Bahasa Jelas:<\/strong>\u00a0Gunakan konstruksi subjek-verb langsung untuk menghilangkan ambiguitas.<\/p>\n
- \n
- \n
Hindari:<\/em>\u00a0\u201cPIN dievaluasi oleh sistem.\u201d<\/p>\n<\/li>\n
- \n
Disarankan:<\/em>\u00a0\u201cSistem memvalidasi PIN.\u201d<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
- \n
Peta Ekstensi Secara Jelas:<\/strong>\u00a0Selalu kaitkan aliran alternatif dan pengecualian langsung ke nomor langkah tempat mereka bercabang (misalnya,\u00a0
5a<\/code>\u00a0bercabang dari langkah 5). Ini menjaga kemampuan pelacakan dan menyederhanakan pembuatan kasus uji.<\/p>\n<\/li>\n- \n
Sasaran Proses Bisnis Dasar (EBP):<\/strong>\u00a0Setiap use case harus mewakili tugas lengkap dan bernilai yang dilakukan oleh satu aktor sebagai respons terhadap satu peristiwa bisnis tunggal. Hindari mendokumentasikan klik UI yang sangat detail atau interaksi mikro sistem.<\/p>\n<\/li>\n
- \n
Pisahkan Pra kondisi dari Pemicu:<\/strong>\u00a0Pra kondisi adalah keadaan statis (misalnya, \u201cPengguna memiliki sesi aktif\u201d), sedangkan pemicu adalah tindakan dinamis (misalnya, \u201cPengguna mengklik \u2018Kirim Pesanan\u2019\u201d). Menjaga keduanya terpisah mencegah tumpang tindih logis dan kebingungan cakupan.<\/p>\n<\/li>\n<\/ol>\n
\n5. Memvisualisasikan Interaksi Sistem<\/h2>\n
Meskipun narasi teks memberikan kedalaman, model visual memberikan kejelasan struktural langsung. Mengintegrasikan Diagram Use Case dan Diagram Urutan bersama spesifikasi memastikan para pemangku kepentingan memiliki pemahaman yang seragam mengenai batas sistem dan eksekusi temporal.<\/p>\n
A. Diagram Hubungan Use Case<\/h3>\n
Diagram ini memetakan interaksi aktor, menentukan batas sistem, dan menggambarkan hubungan inklusi antar perilaku yang dapat digunakan kembali.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ff6731cd78.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n