![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba3b59771b3.png\")
<\/p>\nDeskripsi use case menjelaskan bagaimana seorang aktor mencapai tujuan dengan berinteraksi dengan sistem. Ini melengkapi diagram use case:<\/p>\n
<\/p>\n
Diagram use case:<\/strong>Menampilkan aktor, ruang lingkup sistem, dan hubungan.<\/p>\n<\/li>\n Deskripsi use case:<\/strong>Menjelaskan perilaku rinci, kondisi, aturan, dan hasil.<\/p>\n<\/li>\n<\/ul>\n Diagram menyediakan peta; deskripsi menyediakan rute.<\/p>\n Use case mewakili tujuan berharga yang dicapai oleh aktor eksternal melalui sistem.<\/p>\n Contoh:<\/p>\n Pelanggan memesan barang<\/p>\n<\/li>\n Karyawan mengajukan klaim biaya<\/p>\n<\/li>\n Pasien menjadwalkan janji temu<\/p>\n<\/li>\n Administrator membuat akun pengguna<\/p>\n<\/li>\n Pelanggan mereset kata sandi<\/p>\n<\/li>\n<\/ul>\n Use case yang baik adalah:<\/p>\n Berorientasi pada tujuan<\/p>\n<\/li>\n Berguna bagi aktor<\/p>\n<\/li>\n Dijelaskan dari perspektif pengguna<\/p>\n<\/li>\n Independen dari tata letak layar tertentu<\/p>\n<\/li>\n Berfokus pada perilaku sistem yang dapat diamati<\/p>\n<\/li>\n<\/ul>\n Gunakan frasa kata kerja\u2013kata benda singkat seperti Klaim Pengeluaran<\/strong>, Lacak Pengiriman<\/strong>, atau Setujui Permohonan Pinjaman<\/strong>.<\/p>\n Aktor adalah peran eksternal yang berinteraksi dengan sistem.<\/p>\n Aktor dapat berupa:<\/p>\n Seorang individu<\/p>\n<\/li>\n Sebuah organisasi<\/p>\n<\/li>\n Sistem perangkat lunak lain<\/p>\n<\/li>\n Perangkat keras<\/p>\n<\/li>\n Pemicu terjadwal atau berbasis waktu<\/p>\n<\/li>\n<\/ul>\n Contoh:<\/p>\n Pelanggan<\/p>\n<\/li>\n Agen Dukungan<\/p>\n<\/li>\n Kasir Gudang<\/p>\n<\/li>\n Gerbang Pembayaran<\/p>\n<\/li>\n Layanan Email<\/p>\n<\/li>\n Administrator<\/p>\n<\/li>\n<\/ul>\n Sebuah aktor adalah peran<\/strong>, bukan necessarily seorang individu tertentu. Misalnya, \u201cPelanggan\u201d biasanya lebih baik daripada \u201cJane Smith.\u201d<\/p>\n Aktor utama<\/strong> memulai kasus penggunaan untuk mencapai tujuan.<\/p>\n Aktor pendukung<\/strong> membantu sistem selama eksekusi.<\/p>\n Contoh:<\/p>\n Aktor utama: Pelanggan<\/p>\n<\/li>\n Aktor pendukung: Gerbang Pembayaran<\/p>\n<\/li>\n Kasus penggunaan: Tempatkan Pesanan<\/p>\n<\/li>\n<\/ul>\n Pelanggan memulai pesanan, sementara gerbang pembayaran mengotorisasi pembayaran.<\/p>\n Batas sistem mendefinisikan apa yang berada di dalam sistem yang dimodelkan.<\/p>\n Untuk toko online, batasnya mungkin berisi:<\/p>\n Jelajahi Produk<\/p>\n<\/li>\n Tambahkan Produk ke Keranjang<\/p>\n<\/li>\n Tempatkan Pesanan<\/p>\n<\/li>\n Lakukan Pembayaran<\/p>\n<\/li>\n Lacak Pesanan<\/p>\n<\/li>\n<\/ul>\n Hal-hal berikut berada di luar batas:<\/p>\n Pelanggan<\/p>\n<\/li>\n Gerbang Pembayaran<\/p>\n<\/li>\n Perusahaan Pengiriman<\/p>\n<\/li>\n Penyedia Email<\/p>\n<\/li>\n<\/ul>\n Batas mencegah kebingungan mengenai tanggung jawab sistem.<\/p>\n Kasus penggunaan harus menggambarkan interaksi lengkap yang menghasilkan hasil yang bermakna.<\/p>\n Sebagai contoh:<\/p>\n Tempatkan Pesanan:<\/strong>Seorang pelanggan memilih produk, memberikan informasi pengiriman, membayar pesanan, dan menerima konfirmasi pesanan.<\/p>\n<\/blockquote>\n “Memvalidasi nomor kartu kredit” mungkin merupakan fungsi sistem, tetapi biasanya terlalu kecil untuk menjadi tujuan pengguna yang berdiri sendiri. Hal ini mungkin merupakan bagian dari Tempatkan Pesanan<\/strong> atau Lakukan Pembayaran<\/strong>.<\/p>\n Pra-kondisi menyatakan apa yang harus sudah benar sebelum kasus penggunaan dimulai.<\/p>\n Contoh:<\/p>\n Pelanggan memiliki akun aktif.<\/p>\n<\/li>\n Produk tersedia untuk dijual.<\/p>\n<\/li>\n Karyawan telah terautentikasi.<\/p>\n<\/li>\n Slot janji temu sudah ada.<\/p>\n<\/li>\n Keranjang belanja berisi setidaknya satu item.<\/p>\n<\/li>\n<\/ul>\n Pra-kondisi bukan tindakan yang dilakukan oleh kasus penggunaan.<\/p>\n Pra-kondisi yang buruk:<\/p>\n Pelanggan masuk ke sistem.<\/p>\n<\/blockquote>\n Pra-kondisi yang lebih baik:<\/p>\n Pelanggan telah terautentikasi.<\/p>\n<\/blockquote>\n Pasca-kondisi menyatakan apa yang benar setelah kasus penggunaan selesai.<\/p>\n Contoh:<\/p>\n Pesanan telah dicatat.<\/p>\n<\/li>\n Pembayaran telah diotorisasi.<\/p>\n<\/li>\n Sebuah email konfirmasi dikirim.<\/p>\n<\/li>\n Klaim pengeluaran memiliki status telah dikirim.<\/p>\n<\/li>\n Akun pengguna ditandai sebagai aktif.<\/p>\n<\/li>\n<\/ul>\n Pasca-kondisi harus menggambarkan hasil, bukan detail implementasi.<\/p>\n Pasca-kondisi yang buruk:<\/p>\n Tabel Pasca-kondisi yang lebih baik:<\/p>\n Pesanan disimpan dan tersedia untuk pemenuhan.<\/p>\n<\/blockquote>\n Skenario keberhasilan utama, juga disebut alur dasar<\/strong> atau jalur bahagia<\/strong>, menggambarkan interaksi normal yang berhasil.<\/p>\n Setiap langkah harus menggambarkan:<\/p>\n Interaksi antara aktor dan sistem<\/p>\n<\/li>\n Respons sistem<\/p>\n<\/li>\n Tindakan bisnis yang bermakna<\/p>\n<\/li>\n<\/ol>\n Contoh:<\/p>\n Pelanggan memilih produk.<\/p>\n<\/li>\n Sistem menampilkan keranjang saat ini.<\/p>\n<\/li>\n Pelanggan memasukkan informasi pengiriman.<\/p>\n<\/li>\n Sistem memvalidasi informasi pengiriman.<\/p>\n<\/li>\n Pelanggan mengirimkan pesanan.<\/p>\n<\/li>\n Sistem meminta otorisasi pembayaran.<\/p>\n<\/li>\n Gerbang pembayaran mengotorisasi pembayaran.<\/p>\n<\/li>\n Sistem mencatat pesanan.<\/p>\n<\/li>\n Sistem menampilkan konfirmasi pesanan.<\/p>\n<\/li>\n<\/ol>\n Hindari detail spesifik antarmuka kecuali hal tersebut esensial bagi persyaratan.<\/p>\n Langkah yang buruk:<\/p>\n Pelanggan mengklik tombol biru di sudut kanan bawah.<\/p>\n<\/blockquote>\n Langkah yang lebih baik:<\/p>\n Pelanggan mengirimkan pesanan.<\/p>\n<\/blockquote>\n Sebuah alur alternatif menggambarkan variasi yang valid dari skenario utama.<\/p>\n Contoh:<\/p>\n Pelanggan memilih pengambilan di toko alih-alih pengiriman.<\/p>\n<\/li>\n Pelanggan membayar dengan metode pembayaran yang tersimpan.<\/p>\n<\/li>\n Administrator menyetujui klaim dengan ketentuan.<\/p>\n<\/li>\n Pengguna melakukan autentikasi menggunakan kode satu kali.<\/p>\n<\/li>\n<\/ul>\n Alur alternatif dapat bergabung kembali dengan alur utama.<\/p>\n Contoh:<\/p>\n A1. Pelanggan menggunakan metode pembayaran yang tersimpan<\/strong> Sebuah alur pengecualian menggambarkan kondisi yang tidak berhasil atau abnormal.<\/p>\n Contoh:<\/p>\n Pembayaran ditolak.<\/p>\n<\/li>\n Produk habis.<\/p>\n<\/li>\n Autentikasi gagal.<\/p>\n<\/li>\n Layanan eksternal tidak tersedia.<\/p>\n<\/li>\n Data yang diperlukan tidak valid.<\/p>\n<\/li>\n<\/ul>\n Sebuah alur pengecualian harus menjelaskan:<\/p>\n Di mana masalah terjadi<\/p>\n<\/li>\n Apa yang dilakukan sistem<\/p>\n<\/li>\n Apa yang dilihat oleh aktor<\/p>\n<\/li>\n Apakah kasus penggunaan berakhir atau dilanjutkan<\/p>\n<\/li>\n<\/ul>\n Contoh:<\/p>\n E1. Pembayaran ditolak<\/strong> Gunakan Contoh:<\/p>\n Place Order includes Calculate Total<\/p>\n<\/li>\n Place Order includes Authenticate Customer<\/p>\n<\/li>\n Withdraw Cash includes Verify PIN<\/p>\n<\/li>\n<\/ul>\n Perilaku yang di-include wajib dilakukan.<\/p>\n Gunakan Contoh:<\/p>\n Place Order dapat diperluas oleh Apply Discount Code<\/p>\n<\/li>\n Checkout dapat diperluas oleh Add Gift Message<\/p>\n<\/li>\n<\/ul>\n Perilaku yang extend tidak selalu dieksekusi.<\/p>\n Sebuah aturan yang berguna:<\/p>\n Include:<\/strong> \u201cIni selalu terjadi sebagai bagian dari kasus penggunaan.\u201d<\/p>\n<\/li>\n Extend:<\/strong> \u201cIni dapat terjadi dalam kondisi tertentu.\u201d<\/p>\n<\/li>\n<\/ul>\n Jangan gunakan Generalisasi merepresentasikan pewarisan antara aktor atau kasus penggunaan.<\/p>\n Contoh:<\/p>\n Karyawan adalah aktor umum.<\/p>\n<\/li>\n Manajer adalah aktor khusus yang mewarisi perilaku Karyawan.<\/p>\n<\/li>\n<\/ul>\n Gunakan generalisasi ketika elemen khusus benar-benar merupakan jenis dari elemen yang digeneralisasi, bukan hanya karena dua elemen berbagi beberapa langkah.<\/p>\n Templat berikut bekerja dengan baik untuk dokumen persyaratan, spesifikasi proyek, dan model analisis.<\/p>\n Tujuan:<\/strong> Ruang Lingkup:<\/strong> Tingkat:<\/strong> Aktor utama:<\/strong> Aktor pendukung:<\/strong><\/p>\n Gerbang Pembayaran<\/p>\n<\/li>\n Layanan Persediaan<\/p>\n<\/li>\n Layanan Email<\/p>\n<\/li>\n Layanan Pengiriman<\/p>\n<\/li>\n<\/ul>\n Pemangku kepentingan dan kepentingan:<\/strong><\/p>\n Pelanggan:<\/strong> Ingin membeli produk dengan sukses dan menerima konfirmasi.<\/p>\n<\/li>\n Toko:<\/strong> Ingin mencatat pesanan yang valid dan menerima pembayaran.<\/p>\n<\/li>\n Gudang:<\/strong> Memerlukan informasi pemenuhan yang akurat.<\/p>\n<\/li>\n Gerbang Pembayaran:<\/strong> Memerlukan permintaan pembayaran yang valid.<\/p>\n<\/li>\n Layanan Pengiriman:<\/strong> Memerlukan alamat pengiriman yang lengkap.<\/p>\n<\/li>\n<\/ul>\n Pemicu:<\/strong> Prasyarat:<\/strong><\/p>\n Pelanggan memiliki setidaknya satu item di dalam keranjang.<\/p>\n<\/li>\n Produk tersedia untuk dipesan.<\/p>\n<\/li>\n Pelanggan menyediakan alamat pengiriman yang valid.<\/p>\n<\/li>\n Sistem dapat berkomunikasi dengan layanan pembayaran.<\/p>\n<\/li>\n<\/ul>\n Jaminan minimal:<\/strong><\/p>\n Tidak ada pesanan yang belum dibayar diperlakukan sebagai dikonfirmasi.<\/p>\n<\/li>\n Pelanggan akan diberitahu jika pesanan tidak dapat diselesaikan.<\/p>\n<\/li>\n Persediaan yang dicadangkan akan dibebaskan jika pembayaran gagal.<\/p>\n<\/li>\n<\/ul>\n Jaminan keberhasilan:<\/strong><\/p>\n Pembayaran telah diotorisasi.<\/p>\n<\/li>\n Pesanan telah dicatat.<\/p>\n<\/li>\n Stok telah dicadangkan.<\/p>\n<\/li>\n Pelanggan menerima konfirmasi.<\/p>\n<\/li>\n Informasi pemenuhan tersedia bagi gudang.<\/p>\n<\/li>\n<\/ul>\n Pelanggan meninjau keranjang belanja.<\/p>\n<\/li>\n Sistem menampilkan produk, jumlah, harga, pajak, biaya pengiriman, dan total.<\/p>\n<\/li>\n Pelanggan memberikan informasi pengiriman.<\/p>\n<\/li>\n Sistem memvalidasi informasi pengiriman.<\/p>\n<\/li>\n Pelanggan memilih metode pembayaran.<\/p>\n<\/li>\n Pelanggan mengajukan pesanan.<\/p>\n<\/li>\n Sistem memeriksa ketersediaan produk.<\/p>\n<\/li>\n Sistem meminta otorisasi pembayaran dari Gerbang Pembayaran.<\/p>\n<\/li>\n Gerbang Pembayaran mengotorisasi pembayaran.<\/p>\n<\/li>\n Sistem membuat pesanan.<\/p>\n<\/li>\n Sistem mencadangkan produk yang dipesan.<\/p>\n<\/li>\n Sistem mengirimkan konfirmasi pesanan kepada pelanggan.<\/p>\n<\/li>\n Sistem menampilkan nomor pesanan dan tanggal perkiraan pengiriman.<\/p>\n<\/li>\n<\/ol>\n A1. Pelanggan menggunakan alamat yang tersimpan<\/strong><\/p>\n Pada Langkah 3, pelanggan memilih alamat yang sebelumnya telah disimpan. Sistem menampilkan alamat tersebut dan melanjutkan ke Langkah 4.<\/p>\n A2. Pelanggan menggunakan metode pembayaran yang tersimpan<\/strong><\/p>\n Pada Langkah 5, pelanggan memilih metode pembayaran yang tersimpan. Sistem menggunakan metode tersebut dan melanjutkan ke Langkah 6.<\/p>\n A3. Pelanggan memilih pengambilan di toko<\/strong><\/p>\n Pada Langkah 3, pelanggan memilih pengambilan di toko alih-alih pengiriman. Sistem menampilkan toko yang tersedia dan tanggal pengambilan, kemudian melanjutkan ke Langkah 5.<\/p>\n E1. Produk tidak tersedia<\/strong><\/p>\n Pada Langkah 7, sistem menentukan bahwa suatu produk tidak tersedia. Sistem mengidentifikasi produk yang tidak tersedia, memperbarui keranjang, dan meminta pelanggan meninjau pesanan.<\/p>\n E2. Pembayaran ditolak<\/strong><\/p>\n Pada Langkah 9, Payment Gateway menolak pembayaran. Sistem tidak mengonfirmasi pesanan, melepaskan cadangan inventaris, menampilkan pesan kegagalan, dan memungkinkan pelanggan memilih metode pembayaran lain.<\/p>\n E3. Payment Gateway tidak tersedia<\/strong><\/p>\n Pada Langkah 8, Payment Gateway tidak merespons dalam batas waktu yang dikonfigurasi. Sistem menandai upaya pembayaran sebagai tertunda, memberi tahu pelanggan, dan mencegah pengiriman pesanan ganda.<\/p>\n Pesanan harus berisi setidaknya satu produk.<\/p>\n<\/li>\n Jumlah produk harus lebih besar dari nol.<\/p>\n<\/li>\n Produk tidak dapat dipesan jika stok yang tersedia tidak mencukupi.<\/p>\n<\/li>\n Pembayaran harus diotorisasi sebelum pesanan dikonfirmasi.<\/p>\n<\/li>\n Harga dan pajak dihitung menggunakan aturan harga yang berlaku saat ini.<\/p>\n<\/li>\n Pelanggan hanya dapat membatalkan pesanan sebelum pemenuhan dimulai.<\/p>\n<\/li>\n<\/ul>\n Ringkasan pesanan harus ditampilkan dalam waktu dua detik di bawah beban normal.<\/p>\n<\/li>\n Informasi pembayaran tidak boleh disimpan dalam teks biasa.<\/p>\n<\/li>\n Pengiriman ganda tidak boleh menciptakan pesanan ganda.<\/p>\n<\/li>\n Sistem harus mencatat jejak audit untuk perubahan status pembayaran dan pesanan.<\/p>\n<\/li>\n<\/ul>\n Deskripsi use case dapat ditulis pada tingkat detail yang berbeda.<\/p>\n Use case ringkasan menggambarkan proses bisnis yang luas.<\/p>\n Contoh:<\/p>\n Penuhi Pesanan Pelanggan<\/p>\n<\/blockquote>\n Ini dapat mencakup:<\/p>\n Terima pesanan<\/p>\n<\/li>\n Ambil produk<\/p>\n<\/li>\n Kemas pesanan<\/p>\n<\/li>\n Kirim pesanan<\/p>\n<\/li>\n<\/ul>\n Ini biasanya merupakan tingkat yang paling berguna untuk analisis persyaratan.<\/p>\n Contoh:<\/p>\n Tempatkan Pesanan<\/p>\n<\/blockquote>\n Ini menggambarkan tujuan yang dapat dicapai oleh aktor utama dalam satu sesi.<\/p>\n Ini menggambarkan perilaku sistem yang lebih kecil dan dapat digunakan kembali.<\/p>\n Contoh:<\/p>\n Hitung Total Pesanan<\/p>\n<\/li>\n Validasi Pembayaran<\/p>\n<\/li>\n Buat Faktur<\/p>\n<\/li>\n<\/ul>\n Use case tingkat subfungsi berguna ketika perilaku digunakan kembali atau kompleks secara teknis, namun mereka tidak boleh menggantikan use case tujuan pengguna.<\/p>\n Tulis dari perspektif aktor:<\/p>\n Pelanggan mengajukan pesanan.<\/p>\n<\/blockquote>\n Hindari kata-kata yang berpusat pada implementasi:<\/p>\n OrderController memanggil layanan pesanan.<\/p>\n<\/blockquote>\n Yang terakhir ini termasuk dalam dokumentasi desain, bukan dalam use case bisnis.<\/p>\n Hindari menggabungkan terlalu banyak tindakan:<\/p>\n Pelanggan memasukkan detail, memilih pembayaran, mengonfirmasi pesanan, dan menerima email.<\/p>\n<\/blockquote>\n Perbaiki dengan memisahkan interaksi:<\/p>\n Pelanggan memasukkan informasi pengiriman.<\/p>\n<\/li>\n Sistem memvalidasi informasi tersebut.<\/p>\n<\/li>\n Pelanggan memilih metode pembayaran.<\/p>\n<\/li>\n Pelanggan mengonfirmasi pesanan.<\/p>\n<\/li>\n Sistem mengirimkan konfirmasi.<\/p>\n<\/li>\n<\/ol>\n Pembaca harus dapat menentukan apakah persyaratan telah diimplementasikan.<\/p>\n Lemah:<\/p>\n Sistem memproses permintaan.<\/p>\n<\/blockquote>\n Lebih Kuat:<\/p>\n Sistem memvalidasi permintaan, mencatat klaim, menetapkan nomor klaim, dan menampilkan status pengiriman.<\/p>\n<\/blockquote>\n Gunakan:<\/p>\n Pelanggan memberikan informasi pengiriman.<\/p>\n<\/blockquote>\n Daripada:<\/p>\n Pelanggan memasukkan alamat ke dalam kotak teks dan mengklik tombol Lanjutkan berwarna hijau.<\/p>\n<\/blockquote>\n Versi kedua secara tidak perlu membatasi antarmuka.<\/p>\n Jangan isi alur dasar dengan setiap kemungkinan kesalahan. Masukkan kesalahan ke dalam alur pengecualian.<\/p>\n Aturan bisnis sering kali berlaku untuk beberapa kasus penggunaan. Menjaga mereka terpisah mencegah pengulangan teks yang tidak konsisten.<\/p>\n Untuk setiap kegagalan penting, tentukan:<\/p>\n Apakah data disimpan<\/p>\n<\/li>\n Apakah transaksi dibatalkan kembali<\/p>\n<\/li>\n Apakah aktor dapat mencoba lagi<\/p>\n<\/li>\n Apakah administrator diberitahu<\/p>\n<\/li>\n Apakah kasus penggunaan berakhir atau dilanjutkan<\/p>\n<\/li>\n<\/ul>\n Alur kerja praktis adalah:<\/p>\n Identifikasi sistem yang sedang dimodelkan.<\/p>\n<\/li>\n Daftarkan aktor eksternal.<\/p>\n<\/li>\n Tanyakan apa yang ingin dicapai oleh setiap aktor.<\/p>\n<\/li>\n Ubah setiap tujuan menjadi nama kasus penggunaan.<\/p>\n<\/li>\n Tentukan batas sistem.<\/p>\n<\/li>\n Tuliskan skenario keberhasilan utama.<\/p>\n<\/li>\n Tambahkan alur alternatif dan pengecualian.<\/p>\n<\/li>\n Tambahkan aturan bisnis dan persyaratan khusus.<\/p>\n<\/li>\n Gambar diagram kasus penggunaan.<\/p>\n<\/li>\n Tinjau model bersama pemangku kepentingan.<\/p>\n<\/li>\n Hubungkan kasus penggunaan dengan persyaratan, pengujian, dan artefak desain.<\/p>\n<\/li>\n<\/ol>\n Pertanyaan yang berguna adalah:<\/p>\n Hasil bisnis apa yang dibutuhkan aktor ini dari sistem?<\/p>\n<\/blockquote>\n Elemen yang paling umum adalah:<\/p>\n Aktor:<\/strong>Peran eksternal<\/p>\n<\/li>\n Kasus penggunaan:<\/strong> Kapabilitas sistem atau tujuan aktor<\/p>\n<\/li>\n Batas sistem:<\/strong> Ruang lingkup sistem<\/p>\n<\/li>\n Asosiasi:<\/strong> Aktor berpartisipasi dalam sebuah kasus penggunaan<\/p>\n<\/li>\n Include:<\/strong> Perilaku yang diperlukan dan dapat digunakan kembali<\/p>\n<\/li>\n Extend:<\/strong> Perilaku opsional atau bersyarat<\/p>\n<\/li>\n Generalisasi:<\/strong> Aktor atau kasus penggunaan yang terspesialisasi<\/p>\n<\/li>\n<\/ul>\n Diagram kasus penggunaan tidak boleh mencoba menampilkan:<\/p>\n Setiap langkah alur kerja<\/p>\n<\/li>\n Tabel basis data<\/p>\n<\/li>\n Atribut kelas<\/p>\n<\/li>\n Aturan bisnis yang terperinci<\/p>\n<\/li>\n Tata letak layar<\/p>\n<\/li>\n Algoritma internal<\/p>\n<\/li>\n<\/ul>\n Hal-hal tersebut seharusnya ada dalam diagram aktivitas, diagram kelas, diagram urutan, atau persyaratan tertulis.<\/p>\n Contoh berikut memodelkan Tempatkan Pesanan<\/strong> kasus penggunaan dan perilaku terkait.<\/p>\n1. Apa Itu Use Case?<\/h2>\n
\n
\n
Nama use case yang buruk dan yang telah diperbaiki<\/h3>\n
\n\n
\n \nNama buruk<\/th>\n Nama yang diperbaiki<\/th>\n Alasan<\/th>\n<\/tr>\n<\/thead>\n \n Layar masuk<\/td>\n Mengautentikasi pengguna<\/td>\n Menggambarkan sebuah tujuan<\/td>\n<\/tr>\n \n Pembaruan basis data<\/td>\n Mencatat pembayaran<\/td>\n Menggambarkan nilai bisnis<\/td>\n<\/tr>\n \n Klik tombol kirim<\/td>\n Klaim pengeluaran<\/td>\n Menghindari kata-kata yang spesifik untuk antarmuka pengguna<\/td>\n<\/tr>\n \n Validasi akun<\/td>\n Buat akun pelanggan<\/td>\n Memperjelas hasil<\/td>\n<\/tr>\n \n Proses pesanan<\/td>\n Tempatkan pesanan<\/td>\n Menggunakan tujuan yang berpusat pada aktor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 2. Konsep Utama<\/h1>\n
2.1 Aktor<\/h2>\n
\n
\n
Aktor utama dan aktor pendukung<\/h3>\n
\n
2.2 Batas Sistem<\/h2>\n
\n
\n
2.3 Kasus Penggunaan<\/h2>\n
\n
2.4 Pra-kondisi<\/h2>\n
\n
\n
\n
2.5 Pasca-kondisi<\/h2>\n
\n
\n
pesanan<\/code> diperbarui.<\/p>\n<\/blockquote>\n\n
2.6 Skenario Keberhasilan Utama<\/h2>\n
\n
\n
\n
\n
2.7 Alur Alternatif<\/h2>\n
\n
\n
\nPada Langkah 6, pelanggan memilih metode pembayaran yang tersimpan. Sistem meminta otorisasi menggunakan metode tersebut, kemudian melanjutkan ke Langkah 7.<\/p>\n<\/blockquote>\n2.8 Alur Pengecualian<\/h2>\n
\n
\n
\n
\nPada Langkah 7, Gerbang Pembayaran menolak transaksi. Sistem menampilkan alasannya, menandai pesanan sebagai belum dibayar, dan memungkinkan pelanggan memilih metode pembayaran lain.<\/p>\n<\/blockquote>\n2.9 Hubungan Include dan Extend<\/h2>\n
include<\/code><\/h3>\ninclude<\/code> ketika satu kasus penggunaan selalu memanggil perilaku yang dapat digunakan kembali lainnya.<\/p>\n\n
Place Order <<include>> Calculate Total\r\n<\/code><\/pre>\nextend<\/code><\/h3>\nextend<\/code> ketika perilaku opsional atau kondisional melengkapi kasus penggunaan dasar.<\/p>\n\n
Apply Discount Code <<extend>> Place Order\r\n<\/code><\/pre>\n\n
include<\/code> dan perluas<\/code>hanya untuk memecah setiap alur menjadi bagian-bagian kecil. Dekomposisi yang berlebihan membuat model sulit dipahami.<\/p>\n2.10 Generalisasi<\/h2>\n
\n
Manager --|> Karyawan\r\n<\/code><\/pre>\n3. Templat Deskripsi Kasus Penggunaan Standar<\/h1>\n
ID Kasus Penggunaan:\r\nNama Kasus Penggunaan:\r\nTujuan:\r\nRuang Lingkup:\r\nTingkat:\r\nAktor Utama:\r\nAktor Pendukung:\r\nPemangku Kepentingan dan Kepentingan:\r\n\r\nPemicu:\r\n\r\nPrasyarat:\r\n\r\nJaminan Minimal:\r\n\r\nJaminan Keberhasilan:\r\n\r\nSkenario Keberhasilan Utama:\r\n1.\r\n2.\r\n3.\r\n\r\nAlur Alternatif:\r\nA1.\r\nA2.\r\n\r\nAlur Pengecualian:\r\nE1.\r\nE2.\r\n\r\nPersyaratan Khusus:\r\n- Kinerja\r\n- Keamanan\r\n- Kegunaan\r\n- Ketersediaan\r\n- Kepatuhan\r\n\r\nAturan Bisnis:\r\n\r\nPersyaratan Data:\r\n\r\nFrekuensi dan Volume:\r\n\r\nAsumsi:\r\n\r\nPertanyaan Terbuka:\r\n\r\nKasus Penggunaan Terkait:\r\n<\/code><\/pre>\nPenjelasan bidang<\/h2>\n
\n\n
\n \nBidang<\/th>\n Tujuan<\/th>\n<\/tr>\n<\/thead>\n \n ID Kasus Penggunaan<\/td>\n Menyediakan referensi stabil, seperti UC-001<\/td>\n<\/tr>\n \n Nama Kasus Penggunaan<\/td>\n Menamai tujuan aktor<\/td>\n<\/tr>\n \n Tujuan<\/td>\n Meringkas hasil bisnis yang diinginkan<\/td>\n<\/tr>\n \n Ruang Lingkup<\/td>\n Mengidentifikasi sistem atau subsistem<\/td>\n<\/tr>\n \n Tingkat<\/td>\n Menunjukkan apakah itu tujuan pengguna, ringkasan, atau subfungsi<\/td>\n<\/tr>\n \n Aktor Utama<\/td>\n Mengidentifikasi siapa yang memulai kasus penggunaan<\/td>\n<\/tr>\n \n Aktor Pendukung<\/td>\n Mendaftar peserta eksternal<\/td>\n<\/tr>\n \n Pemangku Kepentingan dan Kepentingan<\/td>\n Menangkap harapan setiap pemangku kepentingan<\/td>\n<\/tr>\n \n Pemicu<\/td>\n Menjelaskan apa yang memulai kasus penggunaan<\/td>\n<\/tr>\n \n Prasyarat<\/td>\n Mendefinisikan apa yang harus sudah benar<\/td>\n<\/tr>\n \n Jaminan Minimal<\/td>\n Mendeskripsikan apa yang tetap benar setelah kegagalan<\/td>\n<\/tr>\n \n Jaminan Keberhasilan<\/td>\n Mendeskripsikan hasil yang berhasil<\/td>\n<\/tr>\n \n Skenario Keberhasilan Utama<\/td>\n Mendokumentasikan alur normal<\/td>\n<\/tr>\n \n Alur Alternatif<\/td>\n Mendeskripsikan variasi yang valid<\/td>\n<\/tr>\n \n Alur Pengecualian<\/td>\n Mendeskripsikan kegagalan dan pemulihan<\/td>\n<\/tr>\n \n Persyaratan Khusus<\/td>\n Menangkap batasan nonfungsional<\/td>\n<\/tr>\n \n Aturan Bisnis<\/td>\n Mencatat kebijakan dan aturan domain<\/td>\n<\/tr>\n \n Persyaratan Data<\/td>\n Mendaftar informasi yang dimasukkan, dibaca, atau dihasilkan<\/td>\n<\/tr>\n \n Pertanyaan Terbuka<\/td>\n Melacak masalah yang belum terselesaikan<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 4. Contoh: Tempatkan Pesanan<\/h1>\n
UC-001 \u2014 Tempatkan Pesanan<\/h2>\n
\nMemungkinkan pelanggan membeli satu atau lebih produk.<\/p>\n
\nToko Online<\/p>\n
\nTujuan pengguna<\/p>\n
\nPelanggan<\/p>\n\n
\n
\nPelanggan menyerahkan keranjang belanja untuk proses pembayaran.<\/p>\n\n
\n
\n
Skenario keberhasilan utama<\/h3>\n
\n
Alur alternatif<\/h3>\n
Alur pengecualian<\/h3>\n
Aturan bisnis<\/h3>\n
\n
Persyaratan khusus<\/h3>\n
\n
5. Tingkat Use Case<\/h1>\n
Use case tingkat ringkasan<\/h2>\n
\n
\n
Use case tingkat tujuan pengguna<\/h2>\n
\n
Use case tingkat subfungsi<\/h2>\n
\n
6. Menulis Deskripsi Use Case Berkualitas Tinggi<\/h1>\n
Gunakan bahasa yang berpusat pada aktor<\/h2>\n
\n
\n
Jadikan setiap langkah bersifat atomik<\/h2>\n
\n
\n
Deskripsikan perilaku yang dapat diamati<\/h2>\n
\n
\n
Hindari desain antarmuka pengguna yang terburu-buru<\/h2>\n
\n
\n
Jaga alur utama tetap berhasil<\/h2>\n
Identifikasi aturan bisnis secara terpisah<\/h2>\n
Jadikan perilaku kegagalan eksplisit<\/h2>\n
\n
7. Dari Persyaratan ke Kasus Penggunaan<\/h1>\n
\n
Analisis aktor-tujuan<\/h2>\n
\n\n
\n \nAktor<\/th>\n Tujuan<\/th>\n Kasus penggunaan kandidat<\/th>\n<\/tr>\n<\/thead>\n \n Pelanggan<\/td>\n Membeli produk<\/td>\n Tempel Pesanan<\/td>\n<\/tr>\n \n Pelanggan<\/td>\n Periksa kemajuan pengiriman<\/td>\n Lacak Pesanan<\/td>\n<\/tr>\n \n Agen Dukungan<\/td>\n Menyelesaikan keluhan<\/td>\n Selesaikan Keluhan<\/td>\n<\/tr>\n \n Karyawan Gudang<\/td>\n Menyiapkan pesanan<\/td>\n Ambil Pesanan<\/td>\n<\/tr>\n \n Gerbang Pembayaran<\/td>\n Mengotorisasi pembayaran<\/td>\n Otorisasi Pembayaran<\/td>\n<\/tr>\n \n Administrator<\/td>\n Mengontrol akses<\/td>\n Mengelola Akun Pengguna<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
8. Notasi Diagram Kasus Penggunaan<\/h1>\n
\n
\n
9. Contoh Diagram PlantUML<\/h1>\n
![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba3bd13facb.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n