Now Reading: Panduan Komprehensif tentang Elaborasi Use Case: Konsep Kunci, Metode, dan Contoh

1
  • 01

    Panduan Komprehensif tentang Elaborasi Use Case: Konsep Kunci, Metode, dan Contoh

Read this post in: de_DEen_USes_ESfr_FRhi_INjapl_PLpt_PTru_RUvizh_CNzh_TW

Panduan Komprehensif tentang Elaborasi Use Case: Konsep Kunci, Metode, dan Contoh

UMLYesterday

Pendahuluan

Elaborasi Use Case adalah tahap kritis dalam siklus pengembangan perangkat lunak, khususnya dalam konteks rekayasa kebutuhan dan analisis serta desain berorientasi objek. Ini menghubungkan kesenjangan antara use case tingkat tinggi dan spesifikasi sistem yang rinci, memungkinkan pengembang, analis, dan pemangku kepentingan untuk memahami bagaimanasistem berperilaku dalam merespons tujuan pengguna tertentu.

Panduan ini memberikan gambaran komprehensif tentang elaborasi use case, termasuk tujuannya, konsep kunci, metodologi langkah demi langkah, praktik terbaik, dan contoh dunia nyata.

1. Apa itu Elaborasi Use Case?

Elaborasi Use Case adalah proses menyempurnakan use case tingkat tinggi menjadi deskripsi rinci dan dapat dijalankan mengenai perilaku sistem. Ini mengubah narasi sederhana interaksi pengguna menjadi spesifikasi yang tepat, dapat diuji, dan dapat diimplementasikan.

✅ Tujuan: Untuk mendefinisikan apa yang harus dilakukan sistem, bagaimana harus melakukannya, dan dalam kondisi apa, dalam detail yang cukup untuk pengembangan dan pengujian.

2. Mengapa Elaborasi Use Case Penting

  • Mengurangi Ambiguitas: Mencegah salah pemahaman terhadap kebutuhan.

  • Meningkatkan Kemampuan Pelacakan: Menghubungkan kebutuhan dengan desain, kode, dan kasus pengujian.

  • Mendukung Desain & Implementasi: Menyediakan dasar untuk diagram kelas, diagram urutan, dan desain basis data.

  • Memungkinkan Pengujian: Memfasilitasi pembuatan skenario pengujian dan kriteria penerimaan.

  • Meningkatkan Kolaborasi: Memastikan pemahaman bersama di antara pemangku kepentingan, pengembang, dan penguji.

3. Konsep Kunci dalam Elaborasi Use Case

3.1 Use Case (UC)

Use case menggambarkan urutan tindakan yang dilakukan sistem untuk menghasilkan hasil yang bernilai bagi aktor (pengguna atau sistem eksternal).

Contoh: “Tarik Tunai” dari ATM.

3.2 Aktor

Entitas eksternal yang berinteraksi dengan sistem. Bisa berupa pengguna manusia, sistem lain, atau pemicu waktu.

Contoh: Pelanggan, Mesin ATM, Gateway Pembayaran.

3.3 Aktor Utama dan Aktor Sekunder

  • Aktor Utama: Memulai use case.

  • Aktor Sekunder: Mendukung aktor utama (misalnya, server bank).

3.4 Pra-kondisi

Kondisi yang harus benar sebelum use case dapat dimulai.

Contoh: Pengguna harus memiliki kartu yang valid dan PIN yang benar.

3.5 Pasca-kondisi

Kondisi yang harus benar setelah use case selesai.

Contoh: Uang tunai dikeluarkan, saldo rekening diperbarui.

3.6 Adegan Sukses Utama (Alur Dasar)

Jalur yang paling umum dalam use case yang mengarah pada keberhasilan.

Contoh: Masukkan kartu → Masukkan PIN → Pilih penarikan → Masukkan jumlah → Terima uang tunai.

3.7 Alur Alternatif (Alur Pengecualian)

Cabang dalam use case yang menangani pengecualian, kesalahan, atau variasi.

Contoh: PIN tidak valid → Coba lagi atau batalkan.

3.8 Ekstensi

Titik-titik dalam alur utama di mana perilaku alternatif dapat dimasukkan (misalnya, melalui “<>” dalam UML).

Contoh: “<>: Notifikasi bank tentang aktivitas mencurigakan.”

3.9 Persyaratan Non-Fungsional (NFRs)

Kendala pada perilaku sistem (misalnya, kinerja, keamanan, kenyamanan penggunaan).

Contoh: “Transaksi harus selesai dalam waktu 3 detik.”

4. Proses Penguraian Use Case (Langkah demi Langkah)

Langkah 1: Identifikasi Use Case

Mulai dengan use case tingkat tinggi (misalnya, “Tempatkan Pesanan”).

Gunakan template:
Nama Use Case: Tempatkan Pesanan
Aktor Utama: Pelanggan
Pihak Berkepentingan: Pelanggan, Sistem Manajemen Pesanan, Gateway Pembayaran

Langkah 2: Tentukan Pra-kondisi

Daftar semua kondisi yang harus dipenuhi sebelum use case dimulai.

  • Pelanggan telah masuk ke sistem.

  • Keranjang belanja berisi setidaknya satu item.

  • Metode pembayaran telah disimpan.

Langkah 3: Tentukan Pasca-kondisi

Nyatakan apa yang harus benar setelah use case selesai.

  • Pesanan dibuat dalam sistem.

  • Persediaan diperbarui.

  • Pembayaran diproses.

  • Email konfirmasi dikirim.

Langkah 4: Tulis Skenario Sukses Utama (Alur Dasar)

Rincian jalur ideal dan sukses.

  1. Pelanggan memilih “Checkout” dari keranjang belanja.

  2. Sistem menampilkan ringkasan pesanan.

  3. Pelanggan mengonfirmasi alamat pengiriman.

  4. Pelanggan memilih metode pembayaran.

  5. Sistem memproses pembayaran.

  6. Pembayaran dikonfirmasi.

  7. Sistem membuat pesanan dan menghasilkan konfirmasi.

  8. Konfirmasi ditampilkan dan email dikirim.

Langkah 5: Identifikasi Aliran Alternatif (Aliran Pengecualian)

Daftar kemungkinan penyimpangan dari aliran utama.

Aliran Alternatif A: Stok Tidak Cukup

  1. Sistem memeriksa persediaan.

  2. Barang habis stok.

  3. Sistem menampilkan pesan: “Barang tidak tersedia.”

  4. Pelanggan dapat menghapus barang atau melanjutkan tanpa barang tersebut.

Aliran Alternatif B: Pembayaran Ditolak

  1. Pembayaran ditolak.

  2. Sistem menampilkan kesalahan: “Pembayaran ditolak.”

  3. Pelanggan dapat mencoba lagi atau memilih metode lain.

Aliran Alternatif C: Alamat Pengiriman Tidak Valid

  1. Sistem memvalidasi alamat.

  2. Alamat tidak valid.

  3. Sistem meminta pelanggan untuk memperbaikinya.

Langkah 6: Tentukan Ekstensi (Hubungan <>)

Gunakan ekstensi gaya UML untuk menunjukkan perilaku opsional.

  • <>: Notifikasi Sistem Persediaan

    • Pemicu: Ketika suatu barang habis stok saat checkout.

    • Tujuan: Memberi tahu gudang untuk melakukan pengisian stok.

  • <>: Terapkan Kupon Diskon

    • Pemicu: Pelanggan memasukkan kode kupon yang valid.

    • Tujuan: Mengurangi total biaya.

Langkah 7: Tambahkan Persyaratan Non-Fungsional (NFRs)

Sertakan keterbatasan sistem.

  • Pesanan harus diproses dalam waktu 5 detik.

  • Pembayaran harus dienkripsi menggunakan TLS 1.3.

  • Sistem harus mendukung 10.000 pengguna bersamaan.

Langkah 8: Tinjau dan Validasi

Berkolaborasi dengan pemangku kepentingan untuk memastikan kelengkapan dan akurasi.

  • Tanyakan: “Apakah ini mencakup semua tujuan pengguna?”

  • Tanyakan: “Apakah semua kasus tepi dipertimbangkan?”

  • Tanyakan: “Apakah seorang pengembang dapat membangun berdasarkan ini?”

5. Alat dan Teknik untuk Elaborasi

Alat/Teknik Tujuan
Diagram Kasus Penggunaan (UML) Menggambarkan aktor dan kasus penggunaan.
Diagram Urutan Menampilkan alur pesan antar objek selama kasus penggunaan.
Diagram Aktivitas Memodelkan alur kerja yang kompleks dan titik keputusan.
Pemetaan Cerita Pengguna Menghubungkan kasus penggunaan dengan perjalanan pengguna dan prioritas.
Tabel Keputusan Memperjelas logika yang kompleks (misalnya, aturan diskon).

6. Praktik Terbaik

  1. Jaga Kasus Penggunaan Berpusat pada Pengguna: Fokus pada tujuan pengguna, bukan fitur sistem.

  2. Gunakan Penamaan yang Konsisten: Gunakan format kata kerja-kata benda (misalnya, “Perbarui Profil”).

  3. Hindari Istilah Teknis: Tulis untuk pemangku kepentingan non-teknis.

  4. Gunakan Bahasa Sederhana: Jelas dan ringkas.

  5. Iterasi: Sempurnakan kasus penggunaan seiring meningkatnya pemahaman.

  6. Tautkan ke Artefak Lain: Hubungkan kasus penggunaan dengan diagram kelas, kasus uji, dan cerita pengguna.

  7. Prioritaskan: Fokus pada kasus penggunaan bernilai tinggi atau berisiko tinggi terlebih dahulu.

7. Contoh Nyata: Perbankan Online – Transfer Uang

Kasus Penggunaan: Transfer Uang

Aktor Utama: Pelanggan
Aktor Sekunder: Server Bank, Sistem Deteksi Penipuan

Prasyarat

  • Pelanggan telah masuk sistem.

  • Akun sumber memiliki dana yang cukup.

  • Batas transfer belum dilampaui.

Kondisi Akhir

  • Dana dipindahkan dari akun sumber ke akun tujuan.

  • Transaksi dicatat di kedua akun.

  • Pemberitahuan dikirim ke kedua pihak.

Skenario Sukses Utama

  1. Pelanggan memilih “Transfer Uang” dari dasbor.

  2. Sistem menampilkan formulir transfer.

  3. Pelanggan memasukkan akun tujuan dan jumlah.

  4. Sistem memvalidasi akun dan jumlah.

  5. Pelanggan mengonfirmasi transfer.

  6. Sistem memeriksa aturan deteksi penipuan.

  7. Transaksi disetujui dan dieksekusi.

  8. Pesan konfirmasi ditampilkan.

Aliran Alternatif

  • A1: Dana Tidak Cukup
    → Sistem menampilkan: “Dana tidak cukup.”
    → Pelanggan dapat membatalkan atau menyesuaikan jumlah.

  • A2: Penipuan Terdeteksi
    → Sistem menghentikan transfer dan mengirim peringatan.
    → Pelanggan harus memverifikasi melalui 2FA atau menghubungi dukungan.

  • A3: Akun Tujuan Tidak Valid
    → Sistem menampilkan: “Akun tidak ditemukan.”
    → Pelanggan dapat memasukkan kembali atau menggunakan pencarian akun.

Ekstensi

  • <>: Kirim Pemberitahuan ke Penerima

    • Pemicu: Transfer selesai.

    • Tujuan: Memberi tahu penerima.

  • <>: Terapkan Biaya Transfer

    • Pemicu: Jumlah transfer > $1.000.

    • Tujuan: Potong biaya $5.

Persyaratan Non-Fungsional

  • Semua transfer harus dicatat dan dapat diaudit.

  • Waktu respons ≤ 2 detik.

  • Data dienkripsi saat dalam perjalanan dan saat disimpan.

8. Kesalahan Umum dan Cara Menghindarinya

Kesalahan Solusi
Terlalu samar (misalnya, “Sistem harus memproses pesanan”) Gunakan tindakan yang spesifik dan dapat diukur.
Bahasa yang terlalu teknis Gunakan bahasa alami; hindari istilah kode atau basis data.
Jalur pengecualian yang hilang Gunakan aliran alternatif untuk menangani kegagalan.
Tidak ada kriteria keberhasilan yang jelas Tentukan postcondition dengan jelas.
Tidak ada tinjauan dari pemangku kepentingan Libatkan pengguna, penguji, dan analis bisnis.

9. Kesimpulan

Elaborasi use case bukan hanya sebuah kegiatan dokumentasi—ini adalah proses strategis yang memastikan sistem memenuhi kebutuhan pengguna nyata dengan kejelasan, ketepatan, dan kelengkapan. Dengan secara sistematis mengembangkan use case tingkat tinggi menjadi spesifikasi rinci dan dapat diambil tindakan, tim mengurangi risiko, meningkatkan komunikasi, dan menetapkan fondasi yang kuat untuk pengiriman perangkat lunak yang sukses.

✅ Kiat Akhir: Anggap elaborasi use case sebagai percakapan iteratif—bukan tugas satu kali. Perbaiki secara terus-menerus seiring Anda memahami lebih dalam tentang sistem dan penggunanya.

Lampiran: Template untuk Elaborasi Use Case

# Nama Use Case: [contoh: Perbarui Profil]

**Aktor Utama**: [contoh: Pelanggan]  
**Aktor Sekunder**: [contoh: Database, Layanan Email]  
**Pemangku Kepentingan**: [contoh: Pelanggan, Tim Dukungan]

### Pra-kondisi
- [Daftar kondisi]

### Pasca-kondisi
- [Daftar hasil]

### Skenario Sukses Utama (Alur Dasar)
1. [Langkah 1]  
2. [Langkah 2]  
...

### Alur Alternatif
- **A1: [Nama]**  
  1. [Langkah]  
  2. [Langkah]  
- **A2: [Nama]**  
  ...

### Ekstensi (<<extend>>)
- **<<extend>>: [Nama]**  
  - Pemicu: [Kapan]  
  - Tujuan: [Mengapa]

### Persyaratan Non-Fungsional
- [Kinerja, Keamanan, Kegunaan, dll.]

### Catatan
- [Konteks tambahan atau asumsi]

Dengan mengikuti panduan ini, tim dapat menguasai seni elaborasi use case dan membangun sistem yang tidak hanya fungsional tetapi benar-benar selaras dengan harapan pengguna.

Lampiran – Deskripsi Use Case untuk Penarikan Uang Tunai dari ATM:

Nama Use Case

Tarik Uang Tunai

Aktor Utama

Pelanggan (pemegang rekening bank)

Aktor Sekunder

  • Mesin ATM

  • Server Bank (Sistem Perbankan Inti)

  • Gerbang Pembayaran (untuk pemrosesan transaksi)

  • Sistem Deteksi Penipuan

  • Printer (untuk pembuatan struk)

Pemangku Kepentingan & Kepentingan

  • Pelanggan: Ingin menarik uang tunai secara aman dan efisien.

  • Bank: Memastikan integritas transaksi, pencegahan penipuan, dan pembaruan rekening yang akurat.

  • Operator ATM: Menjaga ketersediaan mesin dan persediaan uang tunai.

  • Tim Keamanan: Memantau perilaku mencurigakan dan mencegah penipuan.

Prasyarat

  1. Pelanggan memiliki kartu bank yang valid yang dimasukkan ke ATM.

  2. Pelanggan telah berhasil melakukan otentikasi (memasukkan PIN yang benar).

  3. Akun pelanggan aktif dan tidak diblokir.

  4. ATM memiliki uang tunai yang cukup di brankas.

  5. Akun pelanggan memiliki saldo tersedia yang cukup.

  6. Batas penarikan harian belum dilampaui.

Pasca kondisi

  1. Jumlah uang tunai yang diminta dicairkan kepada pelanggan.

  2. Saldo akun pelanggan dikurangi sebesar jumlah penarikan.

  3. Riwayat transaksi dibuat dalam sistem bank.

  4. Kuitansi dicetak (jika diminta).

  5. ATM mencatat transaksi untuk audit dan penyesuaian.

Skenario Sukses Utama (Alur Dasar)

Langkah Aksi Sistem Respons Aktor
1 ATM menampilkan: “Harap masukkan PIN Anda.” Pelanggan memasukkan PIN.
2 ATM memvalidasi PIN dengan Server Bank. Sistem mengonfirmasi PIN benar.
3 ATM menampilkan menu utama: “Tarik Tunai, Cek Saldo, Transfer, Keluar.” Pelanggan memilih “Tarik Tunai.”
4 ATM menampilkan: “Masukkan jumlah yang ingin ditarik.” Pelanggan memasukkan jumlah (misalnya $100).
5 ATM memvalidasi:

  • Jumlah berada dalam batas harian.

  • Akun memiliki dana yang cukup.

  • ATM memiliki cukup uang tunai. | Sistem mengonfirmasi validitas. |
    | 6 | ATM meminta otorisasi dari Server Bank. | Server Bank menyetujui transaksi. |
    | 7 | ATM mencairkan uang dari brankas. | Pelanggan menerima uang. |
    | 8 | ATM menampilkan: “Apakah Anda ingin struk?” | Pelanggan memilih “Ya” atau “Tidak.” |
    | 9 | Jika “Ya”: ATM mencetak struk dengan:

  • Tanggal/waktu

  • Jumlah penarikan

  • Saldo sisa

  • ID Transaksi | Pelanggan mengambil struk. |
    | 10 | ATM menampilkan: “Terima kasih. Harap ambil kartu Anda.” | Pelanggan mengambil kartu. |
    | 11 | ATM kembali ke status idle. | Sistem diatur ulang. |

✅ Hasil Sukses: Pelanggan menerima uang tunai dan (secara opsional) struk. Akun diperbarui.

Alur Alternatif (Skenario Eksepsi)

A1: PIN Salah Dimasukkan (3 Kali)

  • Pemicu: Pelanggan memasukkan PIN yang salah tiga kali.

  • Aksi Sistem: ATM mengunci kartu dan menampilkan: “Kartu terkunci. Hubungi bank Anda.”

  • Aksi Pemain: Pelanggan keluar dan menghubungi bank.

  • Pasca kondisi: Kartu diblokir sementara; transaksi dicatat.

⚠️ Catatan: Ini adalah tindakan keamanan untuk mencegah akses yang tidak sah.

A2: Dana Tidak Cukup

  • Pemicu: Pelanggan memasukkan jumlah yang melebihi saldo yang tersedia.

  • Tindakan Sistem: ATM menampilkan: “Dana tidak mencukupi. Saldo saat ini: $X.”

  • Tindakan Aktor: Pelanggan memilih “Batal” atau memasukkan jumlah yang lebih rendah.

  • Pasca-kondisi: Tidak ada uang dikeluarkan; tidak ada perubahan pada akun.

A3: Uang di ATM Tidak Cukup

  • Pemicu: Pelanggan memasukkan jumlah yang valid, tetapi brankas ATM kosong atau di bawah minimum.

  • Tindakan Sistem: ATM menampilkan: “Uang tidak tersedia. Silakan coba lagi nanti.”

  • Tindakan Aktor: Pelanggan membatalkan atau kembali nanti.

  • Pasca-kondisi: Transaksi tidak diproses; tidak ada perubahan pada akun.

A4: Jumlah Penarikan Melebihi Batas Harian

  • Pemicu: Pelanggan mencoba menarik lebih dari batas harian (misalnya, $1.000).

  • Tindakan Sistem: ATM menampilkan: “Melebihi batas penarikan harian. Coba jumlah yang lebih kecil.”

  • Tindakan Aktor: Pelanggan mengurangi jumlah atau membatalkan.

  • Pasca-kondisi: Transaksi tidak diproses.

A5: Transaksi Ditolak oleh Server Bank

  • Pemicu: Server bank menolak transaksi (misalnya karena peringatan penipuan, akun dibekukan).

  • Aksi Sistem: ATM menampilkan: “Transaksi ditolak. Harap hubungi bank Anda.”

  • Aksi Aktor: Pelanggan membatalkan dan menghubungi bank.

  • Pasca kondisi: Tidak ada uang dikeluarkan; tidak ada perubahan akun.

Perluasan (Hubungan <>)

Perluasan Pemicu Tujuan
<>: Notifikasi Sistem Deteksi Penipuan Ketika penarikan dilakukan di negara asing atau melebihi perilaku biasa Tandai aktivitas mencurigakan untuk ditinjau
<>: Kirim Pemberitahuan SMS ke Pelanggan Setelah penarikan berhasil Beritahu pelanggan mengenai transaksi (keamanan ditingkatkan)
<>: Terapkan Biaya Penarikan Untuk pemegang akun non-utama atau jenis akun tertentu Tagih biaya untuk layanan tertentu
<>: Cetak Riwayat Transaksi Jika pelanggan memilih “Cetak Riwayat” di menu Berikan ringkasan cetak dari transaksi terkini

Persyaratan Non-Fungsional (NFRs)

Kategori Persyaratan
Kinerja Transaksi harus diproses dalam waktu 3 detik.
Keamanan Semua komunikasi dienkripsi (TLS 1.3). PIN tidak pernah disimpan atau dikirim dalam bentuk teks biasa.
Keandalan ATM tidak boleh mencairkan uang kecuali server bank mengonfirmasi otorisasi.
Kemudahan Penggunaan Antarmuka harus dapat diakses (misalnya, tombol besar, panduan suara untuk tunanetra).
Ketersediaan ATM harus beroperasi 99,9% dari waktu.
Audit & Kepatuhan Semua transaksi harus dicatat dan dapat dilacak selama 7 tahun (sesuai peraturan perbankan).

Catatan

  • ATM harus secara rutin dipelihara untuk memastikan ketersediaan uang tunai dan keandalan perangkat keras.

  • Jika kartu tidak diambil dalam waktu 30 detik setelah transaksi, maka akan secara otomatis disimpan (fitur anti-pencurian).

  • Sistem mendukung beberapa mata uang dan perhitungan nilai tukar (jika berlaku).

Diagram Kasus Penggunaan (Ringkasan UML)

[Pelanggan] --(Tarik Tunai)--> [ATM]
[ATM] --(Otentikasi PIN)--> [Server Bank]
[ATM] --(Periksa Dana)--> [Server Bank]
[ATM] --(Keluarkan Uang)--> [Brankas Uang]
[ATM] --(Cetak Kwitansi)--> [Printer]
[ATM] --(Notifikasi Sistem Penipuan)--> [Sistem Deteksi Penipuan]

(Catatan: Dalam diagram UML lengkap, hubungan kasus pengguna seperti <> dan <> akan ditampilkan.)

✅ Ringkasan

Ini kasus pengguna yang dirinci untuk “Tarik Tunai” memberikan spesifikasi yang jelas, terstruktur, dan dapat diuji yang:

  • Mencatat tujuan pengguna dan perilaku sistem.

  • Menangani pengecualian dunia nyata.

  • Mendukung keamanan, kepatuhan, dan kemudahan penggunaan.

  • Berfungsi sebagai dasar untuk desain, pengujian, dan implementasi.

Ini cocok digunakan dalam sprint agile, dokumen desain sistem, atau spesifikasi persyaratan formal.

📘 Langkah Selanjutnya:

  • Ubah ini menjadi diagram urutan untuk menunjukkan interaksi objek.

  • Buat kasus uji berdasarkan setiap alur (utama dan alternatif).

  • Tautkan ke diagram kelas (contoh, Akun, Transaksi, ATM, Pendeteksi Penipuan).

Related Posts

Recent Comments

Tidak ada komentar untuk ditampilkan.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...