Deskripsi use case menjelaskan bagaimana seorang aktor mencapai tujuan dengan berinteraksi dengan sistem. Ini melengkapi diagram use case:

• Diagram use case:Menampilkan aktor, ruang lingkup sistem, dan hubungan.

• Deskripsi use case:Menjelaskan perilaku rinci, kondisi, aturan, dan hasil.

Diagram menyediakan peta; deskripsi menyediakan rute.

1. Apa Itu Use Case?

Use case mewakili tujuan berharga yang dicapai oleh aktor eksternal melalui sistem.

Contoh:

• Pelanggan memesan barang

• Karyawan mengajukan klaim biaya

• Pasien menjadwalkan janji temu

• Administrator membuat akun pengguna

• Pelanggan mereset kata sandi

Use case yang baik adalah:

• Berorientasi pada tujuan

• Berguna bagi aktor

• Dijelaskan dari perspektif pengguna

• Independen dari tata letak layar tertentu

• Berfokus pada perilaku sistem yang dapat diamati

Nama use case yang buruk dan yang telah diperbaiki

Gunakan frasa kata kerja–kata benda singkat seperti Klaim Pengeluaran, Lacak Pengiriman, atau Setujui Permohonan Pinjaman.

2. Konsep Utama

2.1 Aktor

Aktor adalah peran eksternal yang berinteraksi dengan sistem.

Aktor dapat berupa:

• Seorang individu

• Sebuah organisasi

• Sistem perangkat lunak lain

• Perangkat keras

• Pemicu terjadwal atau berbasis waktu

Contoh:

• Pelanggan

• Agen Dukungan

• Kasir Gudang

• Gerbang Pembayaran

• Layanan Email

• Administrator

Sebuah aktor adalah peran, bukan necessarily seorang individu tertentu. Misalnya, “Pelanggan” biasanya lebih baik daripada “Jane Smith.”

Aktor utama dan aktor pendukung

Aktor utama memulai kasus penggunaan untuk mencapai tujuan.

Aktor pendukung membantu sistem selama eksekusi.

Contoh:

• Aktor utama: Pelanggan

• Aktor pendukung: Gerbang Pembayaran

• Kasus penggunaan: Tempatkan Pesanan

Pelanggan memulai pesanan, sementara gerbang pembayaran mengotorisasi pembayaran.

2.2 Batas Sistem

Batas sistem mendefinisikan apa yang berada di dalam sistem yang dimodelkan.

Untuk toko online, batasnya mungkin berisi:

• Jelajahi Produk

• Tambahkan Produk ke Keranjang

• Tempatkan Pesanan

• Lakukan Pembayaran

• Lacak Pesanan

Hal-hal berikut berada di luar batas:

• Pelanggan

• Gerbang Pembayaran

• Perusahaan Pengiriman

• Penyedia Email

Batas mencegah kebingungan mengenai tanggung jawab sistem.

2.3 Kasus Penggunaan

Kasus penggunaan harus menggambarkan interaksi lengkap yang menghasilkan hasil yang bermakna.

Sebagai contoh:

Tempatkan Pesanan:Seorang pelanggan memilih produk, memberikan informasi pengiriman, membayar pesanan, dan menerima konfirmasi pesanan.

“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 atau Lakukan Pembayaran.

2.4 Pra-kondisi

Pra-kondisi menyatakan apa yang harus sudah benar sebelum kasus penggunaan dimulai.

Contoh:

• Pelanggan memiliki akun aktif.

• Produk tersedia untuk dijual.

• Karyawan telah terautentikasi.

• Slot janji temu sudah ada.

• Keranjang belanja berisi setidaknya satu item.

Pra-kondisi bukan tindakan yang dilakukan oleh kasus penggunaan.

Pra-kondisi yang buruk:

Pelanggan masuk ke sistem.

Pra-kondisi yang lebih baik:

Pelanggan telah terautentikasi.

2.5 Pasca-kondisi

Pasca-kondisi menyatakan apa yang benar setelah kasus penggunaan selesai.

Contoh:

• Pesanan telah dicatat.

• Pembayaran telah diotorisasi.

• Sebuah email konfirmasi dikirim.

• Klaim pengeluaran memiliki status telah dikirim.

• Akun pengguna ditandai sebagai aktif.

Pasca-kondisi harus menggambarkan hasil, bukan detail implementasi.

Pasca-kondisi yang buruk:

Tabel pesanan diperbarui.

Pasca-kondisi yang lebih baik:

Pesanan disimpan dan tersedia untuk pemenuhan.

2.6 Skenario Keberhasilan Utama

Skenario keberhasilan utama, juga disebut alur dasar atau jalur bahagia, menggambarkan interaksi normal yang berhasil.

Setiap langkah harus menggambarkan:

1. Interaksi antara aktor dan sistem

2. Respons sistem

3. Tindakan bisnis yang bermakna

Contoh:

1. Pelanggan memilih produk.

2. Sistem menampilkan keranjang saat ini.

3. Pelanggan memasukkan informasi pengiriman.

4. Sistem memvalidasi informasi pengiriman.

5. Pelanggan mengirimkan pesanan.

6. Sistem meminta otorisasi pembayaran.

7. Gerbang pembayaran mengotorisasi pembayaran.

8. Sistem mencatat pesanan.

9. Sistem menampilkan konfirmasi pesanan.

Hindari detail spesifik antarmuka kecuali hal tersebut esensial bagi persyaratan.

Langkah yang buruk:

Pelanggan mengklik tombol biru di sudut kanan bawah.

Langkah yang lebih baik:

Pelanggan mengirimkan pesanan.

2.7 Alur Alternatif

Sebuah alur alternatif menggambarkan variasi yang valid dari skenario utama.

Contoh:

• Pelanggan memilih pengambilan di toko alih-alih pengiriman.

• Pelanggan membayar dengan metode pembayaran yang tersimpan.

• Administrator menyetujui klaim dengan ketentuan.

• Pengguna melakukan autentikasi menggunakan kode satu kali.

Alur alternatif dapat bergabung kembali dengan alur utama.

Contoh:

A1. Pelanggan menggunakan metode pembayaran yang tersimpan
Pada Langkah 6, pelanggan memilih metode pembayaran yang tersimpan. Sistem meminta otorisasi menggunakan metode tersebut, kemudian melanjutkan ke Langkah 7.

2.8 Alur Pengecualian

Sebuah alur pengecualian menggambarkan kondisi yang tidak berhasil atau abnormal.

Contoh:

• Pembayaran ditolak.

• Produk habis.

• Autentikasi gagal.

• Layanan eksternal tidak tersedia.

• Data yang diperlukan tidak valid.

Sebuah alur pengecualian harus menjelaskan:

• Di mana masalah terjadi

• Apa yang dilakukan sistem

• Apa yang dilihat oleh aktor

• Apakah kasus penggunaan berakhir atau dilanjutkan

Contoh:

E1. Pembayaran ditolak
Pada Langkah 7, Gerbang Pembayaran menolak transaksi. Sistem menampilkan alasannya, menandai pesanan sebagai belum dibayar, dan memungkinkan pelanggan memilih metode pembayaran lain.

2.9 Hubungan Include dan Extend

include

Gunakan include ketika satu kasus penggunaan selalu memanggil perilaku yang dapat digunakan kembali lainnya.

Contoh:

• Place Order includes Calculate Total

• Place Order includes Authenticate Customer

• Withdraw Cash includes Verify PIN

Perilaku yang di-include wajib dilakukan.

Place Order <<include>> Calculate Total

extend

Gunakan extend ketika perilaku opsional atau kondisional melengkapi kasus penggunaan dasar.

Contoh:

• Place Order dapat diperluas oleh Apply Discount Code

• Checkout dapat diperluas oleh Add Gift Message

Perilaku yang extend tidak selalu dieksekusi.

Apply Discount Code <<extend>> Place Order

Sebuah aturan yang berguna:

• Include: “Ini selalu terjadi sebagai bagian dari kasus penggunaan.”

• Extend: “Ini dapat terjadi dalam kondisi tertentu.”

Jangan gunakan include dan perluashanya untuk memecah setiap alur menjadi bagian-bagian kecil. Dekomposisi yang berlebihan membuat model sulit dipahami.

2.10 Generalisasi

Generalisasi merepresentasikan pewarisan antara aktor atau kasus penggunaan.

Contoh:

• Karyawan adalah aktor umum.

• Manajer adalah aktor khusus yang mewarisi perilaku Karyawan.

Manager --|> Karyawan

Gunakan generalisasi ketika elemen khusus benar-benar merupakan jenis dari elemen yang digeneralisasi, bukan hanya karena dua elemen berbagi beberapa langkah.

3. Templat Deskripsi Kasus Penggunaan Standar

Templat berikut bekerja dengan baik untuk dokumen persyaratan, spesifikasi proyek, dan model analisis.

ID Kasus Penggunaan:
Nama Kasus Penggunaan:
Tujuan:
Ruang Lingkup:
Tingkat:
Aktor Utama:
Aktor Pendukung:
Pemangku Kepentingan dan Kepentingan:

Pemicu:

Prasyarat:

Jaminan Minimal:

Jaminan Keberhasilan:

Skenario Keberhasilan Utama:
1.
2.
3.

Alur Alternatif:
A1.
A2.

Alur Pengecualian:
E1.
E2.

Persyaratan Khusus:
- Kinerja
- Keamanan
- Kegunaan
- Ketersediaan
- Kepatuhan

Aturan Bisnis:

Persyaratan Data:

Frekuensi dan Volume:

Asumsi:

Pertanyaan Terbuka:

Kasus Penggunaan Terkait:

Penjelasan bidang

4. Contoh: Tempatkan Pesanan

UC-001 — Tempatkan Pesanan

Tujuan:
Memungkinkan pelanggan membeli satu atau lebih produk.

Ruang Lingkup:
Toko Online

Tingkat:
Tujuan pengguna

Aktor utama:
Pelanggan

Aktor pendukung:

• Gerbang Pembayaran

• Layanan Persediaan

• Layanan Email

• Layanan Pengiriman

Pemangku kepentingan dan kepentingan:

• Pelanggan: Ingin membeli produk dengan sukses dan menerima konfirmasi.

• Toko: Ingin mencatat pesanan yang valid dan menerima pembayaran.

• Gudang: Memerlukan informasi pemenuhan yang akurat.

• Gerbang Pembayaran: Memerlukan permintaan pembayaran yang valid.

• Layanan Pengiriman: Memerlukan alamat pengiriman yang lengkap.

Pemicu:
Pelanggan menyerahkan keranjang belanja untuk proses pembayaran.

Prasyarat:

• Pelanggan memiliki setidaknya satu item di dalam keranjang.

• Produk tersedia untuk dipesan.

• Pelanggan menyediakan alamat pengiriman yang valid.

• Sistem dapat berkomunikasi dengan layanan pembayaran.

Jaminan minimal:

• Tidak ada pesanan yang belum dibayar diperlakukan sebagai dikonfirmasi.

• Pelanggan akan diberitahu jika pesanan tidak dapat diselesaikan.

• Persediaan yang dicadangkan akan dibebaskan jika pembayaran gagal.

Jaminan keberhasilan:

• Pembayaran telah diotorisasi.

• Pesanan telah dicatat.

• Stok telah dicadangkan.

• Pelanggan menerima konfirmasi.

• Informasi pemenuhan tersedia bagi gudang.

Skenario keberhasilan utama

1. Pelanggan meninjau keranjang belanja.

2. Sistem menampilkan produk, jumlah, harga, pajak, biaya pengiriman, dan total.

3. Pelanggan memberikan informasi pengiriman.

4. Sistem memvalidasi informasi pengiriman.

5. Pelanggan memilih metode pembayaran.

6. Pelanggan mengajukan pesanan.

7. Sistem memeriksa ketersediaan produk.

8. Sistem meminta otorisasi pembayaran dari Gerbang Pembayaran.

9. Gerbang Pembayaran mengotorisasi pembayaran.

10. Sistem membuat pesanan.

11. Sistem mencadangkan produk yang dipesan.

12. Sistem mengirimkan konfirmasi pesanan kepada pelanggan.

13. Sistem menampilkan nomor pesanan dan tanggal perkiraan pengiriman.

Alur alternatif

A1. Pelanggan menggunakan alamat yang tersimpan

Pada Langkah 3, pelanggan memilih alamat yang sebelumnya telah disimpan. Sistem menampilkan alamat tersebut dan melanjutkan ke Langkah 4.

A2. Pelanggan menggunakan metode pembayaran yang tersimpan

Pada Langkah 5, pelanggan memilih metode pembayaran yang tersimpan. Sistem menggunakan metode tersebut dan melanjutkan ke Langkah 6.

A3. Pelanggan memilih pengambilan di toko

Pada Langkah 3, pelanggan memilih pengambilan di toko alih-alih pengiriman. Sistem menampilkan toko yang tersedia dan tanggal pengambilan, kemudian melanjutkan ke Langkah 5.

Alur pengecualian

E1. Produk tidak tersedia

Pada Langkah 7, sistem menentukan bahwa suatu produk tidak tersedia. Sistem mengidentifikasi produk yang tidak tersedia, memperbarui keranjang, dan meminta pelanggan meninjau pesanan.

E2. Pembayaran ditolak

Pada Langkah 9, Payment Gateway menolak pembayaran. Sistem tidak mengonfirmasi pesanan, melepaskan cadangan inventaris, menampilkan pesan kegagalan, dan memungkinkan pelanggan memilih metode pembayaran lain.

E3. Payment Gateway tidak tersedia

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.

Aturan bisnis

• Pesanan harus berisi setidaknya satu produk.

• Jumlah produk harus lebih besar dari nol.

• Produk tidak dapat dipesan jika stok yang tersedia tidak mencukupi.

• Pembayaran harus diotorisasi sebelum pesanan dikonfirmasi.

• Harga dan pajak dihitung menggunakan aturan harga yang berlaku saat ini.

• Pelanggan hanya dapat membatalkan pesanan sebelum pemenuhan dimulai.

Persyaratan khusus

• Ringkasan pesanan harus ditampilkan dalam waktu dua detik di bawah beban normal.

• Informasi pembayaran tidak boleh disimpan dalam teks biasa.

• Pengiriman ganda tidak boleh menciptakan pesanan ganda.

• Sistem harus mencatat jejak audit untuk perubahan status pembayaran dan pesanan.

5. Tingkat Use Case

Deskripsi use case dapat ditulis pada tingkat detail yang berbeda.

Use case tingkat ringkasan

Use case ringkasan menggambarkan proses bisnis yang luas.

Contoh:

Penuhi Pesanan Pelanggan

Ini dapat mencakup:

• Terima pesanan

• Ambil produk

• Kemas pesanan

• Kirim pesanan

Use case tingkat tujuan pengguna

Ini biasanya merupakan tingkat yang paling berguna untuk analisis persyaratan.

Contoh:

Tempatkan Pesanan

Ini menggambarkan tujuan yang dapat dicapai oleh aktor utama dalam satu sesi.

Use case tingkat subfungsi

Ini menggambarkan perilaku sistem yang lebih kecil dan dapat digunakan kembali.

Contoh:

• Hitung Total Pesanan

• Validasi Pembayaran

• Buat Faktur

Use case tingkat subfungsi berguna ketika perilaku digunakan kembali atau kompleks secara teknis, namun mereka tidak boleh menggantikan use case tujuan pengguna.

6. Menulis Deskripsi Use Case Berkualitas Tinggi

Gunakan bahasa yang berpusat pada aktor

Tulis dari perspektif aktor:

Pelanggan mengajukan pesanan.

Hindari kata-kata yang berpusat pada implementasi:

OrderController memanggil layanan pesanan.

Yang terakhir ini termasuk dalam dokumentasi desain, bukan dalam use case bisnis.

Jadikan setiap langkah bersifat atomik

Hindari menggabungkan terlalu banyak tindakan:

Pelanggan memasukkan detail, memilih pembayaran, mengonfirmasi pesanan, dan menerima email.

Perbaiki dengan memisahkan interaksi:

1. Pelanggan memasukkan informasi pengiriman.

2. Sistem memvalidasi informasi tersebut.

3. Pelanggan memilih metode pembayaran.

4. Pelanggan mengonfirmasi pesanan.

5. Sistem mengirimkan konfirmasi.

Deskripsikan perilaku yang dapat diamati

Pembaca harus dapat menentukan apakah persyaratan telah diimplementasikan.

Lemah:

Sistem memproses permintaan.

Lebih Kuat:

Sistem memvalidasi permintaan, mencatat klaim, menetapkan nomor klaim, dan menampilkan status pengiriman.

Hindari desain antarmuka pengguna yang terburu-buru

Gunakan:

Pelanggan memberikan informasi pengiriman.

Daripada:

Pelanggan memasukkan alamat ke dalam kotak teks dan mengklik tombol Lanjutkan berwarna hijau.

Versi kedua secara tidak perlu membatasi antarmuka.

Jaga alur utama tetap berhasil

Jangan isi alur dasar dengan setiap kemungkinan kesalahan. Masukkan kesalahan ke dalam alur pengecualian.

Identifikasi aturan bisnis secara terpisah

Aturan bisnis sering kali berlaku untuk beberapa kasus penggunaan. Menjaga mereka terpisah mencegah pengulangan teks yang tidak konsisten.

Jadikan perilaku kegagalan eksplisit

Untuk setiap kegagalan penting, tentukan:

• Apakah data disimpan

• Apakah transaksi dibatalkan kembali

• Apakah aktor dapat mencoba lagi

• Apakah administrator diberitahu

• Apakah kasus penggunaan berakhir atau dilanjutkan

7. Dari Persyaratan ke Kasus Penggunaan

Alur kerja praktis adalah:

1. Identifikasi sistem yang sedang dimodelkan.

2. Daftarkan aktor eksternal.

3. Tanyakan apa yang ingin dicapai oleh setiap aktor.

4. Ubah setiap tujuan menjadi nama kasus penggunaan.

5. Tentukan batas sistem.

6. Tuliskan skenario keberhasilan utama.

7. Tambahkan alur alternatif dan pengecualian.

8. Tambahkan aturan bisnis dan persyaratan khusus.

9. Gambar diagram kasus penggunaan.

10. Tinjau model bersama pemangku kepentingan.

11. Hubungkan kasus penggunaan dengan persyaratan, pengujian, dan artefak desain.

Analisis aktor-tujuan

Pertanyaan yang berguna adalah:

Hasil bisnis apa yang dibutuhkan aktor ini dari sistem?

8. Notasi Diagram Kasus Penggunaan

Elemen yang paling umum adalah:

• Aktor:Peran eksternal

• Kasus penggunaan: Kapabilitas sistem atau tujuan aktor

• Batas sistem: Ruang lingkup sistem

• Asosiasi: Aktor berpartisipasi dalam sebuah kasus penggunaan

• Include: Perilaku yang diperlukan dan dapat digunakan kembali

• Extend: Perilaku opsional atau bersyarat

• Generalisasi: Aktor atau kasus penggunaan yang terspesialisasi

Diagram kasus penggunaan tidak boleh mencoba menampilkan:

• Setiap langkah alur kerja

• Tabel basis data

• Atribut kelas

• Aturan bisnis yang terperinci

• Tata letak layar

• Algoritma internal

Hal-hal tersebut seharusnya ada dalam diagram aktivitas, diagram kelas, diagram urutan, atau persyaratan tertulis.

9. Contoh Diagram PlantUML

Contoh berikut memodelkan Tempatkan Pesanan kasus penggunaan dan perilaku terkait.

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

Interpretasi

• The Pelanggan memulai Tempatkan Pesanan.

• Tempatkan Pesanan selalu mencakup perhitungan, pengecekan stok, otorisasi pembayaran, reservasi inventaris, dan konfirmasi.

• Terapkan Kode Diskon bersifat opsional, sehingga memperluas Tempatkan Pesanan.

• Layanan eksternal berpartisipasi dalam perilaku sistem tertentu.

• Batas sistem adalah Toko Online persegi panjang.

Penempatan elemen yang tepat dikendalikan oleh mesin rendering. Keputusan pemodelan yang penting adalah aktor, kasus penggunaan, batas, dan hubungan.

10. Membuat Diagram di Visual Paradigm VPasCode

VPasCode adalah platform berbasis browser untuk mengubah teks menjadi diagram yang mendukung PlantUML, Mermaid, Graphviz, dan format diagram lainnya. Platform ini menyediakan pengeditan sumber dan rendering langsung, memungkinkan diagram diperbarui seiring perubahan kode.

Alur kerja dasar

1. Buka editor VPasCode.

2. Buat diagram PlantUML baru.

3. Tempelkan sumber PlantUML.

4. Konfirmasi bahwa editor mengenali sintaks PlantUML.

5. Tinjau pratinjau langsung.

6. Edit aktor, kasus penggunaan, hubungan, dan gaya di panel sumber.

7. Ekspor atau salin diagram yang telah dirender.

8. Tambahkan diagram ke dokumentasi proyek.

VPasCode mendukung diagram kasus penggunaan PlantUML dan menawarkan rendering real-time di browser. Platform ini juga menyediakan contoh dan opsi gaya untuk diagram PlantUML.

Contoh perintah untuk generasi yang dibantu AI

Jika menggunakan fitur generasi diagram berbasis AI, perintah yang berguna adalah:

Buat diagram kasus penggunaan PlantUML untuk toko online.

Aktor utama:
- Pelanggan

Aktor pendukung:
- Gerbang Pembayaran
- Layanan Inventaris
- Layanan Email
- Layanan Pengiriman

Kasus penggunaan utama:
- Jelajahi Produk
- Kelola Keranjang
- Tempatkan Pesanan
- Lacak Pesanan

Tempatkan Pesanan harus mencakup:
- Hitung Total Pesanan
- Periksa Ketersediaan Produk
- Otorisasi Pembayaran
- Reservasi Inventaris
- Kirim Konfirmasi Pesanan

Terapkan Kode Diskon harus memperluas Tempatkan Pesanan.

Gunakan batas sistem bernama Toko Online.

Anggap kode yang dihasilkan sebagai titik awal. Tinjau apakah:

• Aktor benar-benar eksternal

• Kasus penggunaan merepresentasikan tujuan pengguna

• termasuk dan memperluasdigunakan dengan benar

• Batas sistem akurat

• Hubungan mencerminkan perilaku bisnis yang nyata

VPasCode juga mendukung perpindahan antara pengeditan diagram berbasis teks dan alat pemodelan grafis Visual Paradigm, yang dapat berguna ketika tim menginginkan pengeditan berbasis sumber untuk versi dan pengeditan visual untuk penyempurnaan tata letak.

11. Memelihara Diagram Kasus Penggunaan PlantUML

Gunakan alias yang bermakna

Alias membuat hubungan lebih mudah dipelihara:

usecase "Tempatkan Pesanan" sebagai PlaceOrder
Pelanggan --> PlaceOrder

Tambahkan komentar

' Transaksi pelanggan inti
usecase "Tempatkan Pesanan" sebagai PlaceOrder

Komentar membantu anggota tim lain memahami sumber dan memelihara diagram.

Jaga agar diagram tetap fokus

Jika sebuah diagram berisi terlalu banyak kasus penggunaan:

• Buat diagram konteks

• Buat diagram terpisah berdasarkan area bisnis

• Gunakan pengelompokan paket

• Hubungkan diagram terkait melalui dokumentasi

• Hindari menampilkan setiap subfungsi pada tingkat tertinggi

Gunakan penamaan yang konsisten

Pilih satu konvensi dan terapkan secara konsisten:

• Tempatkan Pesanan

• Batalkan Pesanan

• Lacak Pesanan

Hindari mencampur gaya seperti:

• Tempatkan Pesanan

• OrderCancellation

• tracking_function

Simpan sumber bersama proyek

Struktur repositori yang khas mungkin berupa:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Menjaga .puml sumber di bawah kontrol versi membuat perubahan dapat ditinjau dan direproduksi.

12. Keterlacakan

Proses persyaratan yang matang menghubungkan kasus penggunaan dengan artefak proyek lainnya.

Pelacakan membantu menjawab:

• Persyaratan mana yang tercakup?

• Kasus penggunaan mana yang belum diuji?

• Komponen desain mana yang mendukung tujuan bisnis?

• Apa yang terpengaruh jika persyaratan berubah?

13. Kesalahan Umum

Memodelkan komponen internal sebagai aktor

Basis data atau layanan internal biasanya bukan aktor jika berada di dalam batas sistem.

Seorang aktor harus berada di luar sistem yang dimodelkan.

Memperlakukan layar sebagai kasus penggunaan

Layar adalah elemen antarmuka pengguna, belum tentu tujuan pengguna.

Gunakan:

Klaim Pengeluaran

Alih-alih:

Layar Klaim Pengeluaran

Menggunakan include untuk setiap langkah bersama

Kata-kata bersama saja tidak membenarkan kasus penggunaan yang disertakan. Gunakan include ketika perilaku tersebut wajib dan bermakna secara mandiri.

Menggunakan extend untuk langkah normal

Jika suatu perilaku selalu terjadi, perilaku tersebut tidak boleh dimodelkan sebagai ekstensi.

Menulis detail implementasi

Hindari referensi ke:

• Kontroler

• Tabel basis data

• Titik akhir API

• Kelas

• Metode internal

kecuali dokumen tersebut secara khusus merupakan desain teknis.

Mengabaikan perilaku kegagalan

Sebuah kasus penggunaan tidak lengkap jika hanya menjelaskan keberhasilan. Penolakan pembayaran, data tidak valid, waktu habis, kegagalan otorisasi, dan sumber daya yang tidak tersedia harus ditangani.

Membuat kasus penggunaan terlalu luas

“Kelola Seluruh Bisnis” tidak dapat ditindaklanjuti. Pecah tujuan yang luas menjadi kasus penggunaan pada tingkat tujuan pengguna.

Membuat kasus penggunaan terlalu kecil

“Validasi bidang” dan “Tampilkan pesan” umumnya merupakan langkah sistem, bukan tujuan aktor yang independen.

14. Daftar Periksa Tinjauan

Sebelum menyetujui deskripsi kasus penggunaan, periksa:

Ruang lingkup dan aktor

• Apakah batas sistem jelas?

• Apakah semua aktor eksternal telah diidentifikasi?

• Apakah aktor berupa peran daripada nama individu?

• Apakah sistem pendukung dimodelkan hanya ketika mereka eksternal?

Kualitas tujuan

• Apakah kasus penggunaan memberikan nilai kepada aktor utama?

• Apakah nama tersebut merupakan frasa kata kerja–kata benda yang jelas?

• Apakah kasus penggunaan berada pada tingkat yang sesuai?

Kualitas alur

• Apakah skenario utama menggambarkan hasil yang berhasil?

• Apakah setiap langkah bersifat atomik dan dapat diamati?

• Apakah jalur alternatif telah didokumentasikan?

• Apakah jalur pengecualian telah didokumentasikan?

• Apakah perilaku pemulihan jelas?

Kondisi dan hasil

• Apakah prasyarat dapat diuji?

• Apakah jaminan keberhasilan dinyatakan secara eksplisit?

• Apakah jaminan minimal telah didefinisikan?

• Apakah aturan bisnis dipisahkan dari langkah-langkah prosedural?

Kualitas diagram

• Apakah semua kasus penggunaan berada di dalam batas yang benar?

• Apakah asosiasi aktor bermakna?

• Apakah “include” wajib?

• Apakah “extend” opsional atau bersyarat?

• Apakah diagram dapat dibaca tanpa detail yang berlebihan?

Kualitas persyaratan

• Apakah setiap langkah penting dapat diuji?

• Apakah persyaratan non-fungsional disertakan?

• Apakah pertanyaan yang belum terjawab telah dicatat?

• Apakah kasus penggunaan dikaitkan dengan persyaratan dan kasus uji?

15. Struktur Hasil Kerja yang Direkomendasikan

Untuk paket proyek yang lengkap, gunakan struktur berikut:

1. Konteks sistem
2. Katalog aktor
3. Diagram kasus penggunaan
4. Katalog kasus penggunaan
5. Deskripsi kasus penggunaan terperinci
6. Aturan bisnis
7. Persyaratan non-fungsional
8. Matriks keterlacakan
9. Pertanyaan terbuka dan asumsi
10. File sumber PlantUML

Deskripsi kasus penggunaan yang kuat cukup presisi untuk analis, dapat dipahami oleh pemangku kepentingan, dan dapat diuji oleh tim jaminan kualitas. Alur kerja terbaik adalah menggunakan deskripsi tertulis untuk menetapkan perilaku, diagram kasus penggunaan untuk mengomunikasikan ruang lingkup dan hubungan, serta PlantUML di VPasCode untuk menjaga model visual agar mudah diedit dan dipelihara.

Referensi

This post is also available in Deutsch, English, Español, فارسی, Français and English.