Rekayasa persyaratan membentuk dasar dari setiap proyek perangkat lunak yang sukses. Di antara berbagai teknik yang tersedia, deskripsi use case tetap menjadi salah satu metode paling efektif untuk menangkap persyaratan fungsional dari sudut pandang pengguna. Use case yang ditulis dengan baik menghubungkan kesenjangan antara kebutuhan bisnis dan implementasi teknis, memastikan semua pemangku kepentingan memiliki pemahaman yang seragam mengenai perilaku sistem.
Namun, ambiguitas dalam deskripsi ini sering menyebabkan kesalahan pengembangan, perluasan cakupan, dan kegagalan pengujian. Panduan ini menyediakan pendekatan terstruktur untuk membuat deskripsi use case yang tepat dan dapat diambil tindakan, menggunakan standar Unified Modeling Language (UML). Dengan mengikuti pola yang telah ditetapkan, tim dapat membuat dokumentasi yang berfungsi sebagai gambaran desain dan daftar periksa verifikasi.
🔍 Memahami Komponen Utama
Sebelum menyusun teks naratif, sangat penting untuk menentukan elemen-elemen struktural yang membentuk use case yang lengkap. Komponen-komponen ini memastikan bahwa skenario tersebut memiliki batasan dan dapat diukur.
1. Aktor 🧍
Seorang aktor mewakili peran yang dimainkan oleh entitas yang berinteraksi dengan sistem. Aktor berada di luar batas sistem. Mereka dapat berupa:
- Aktor Manusia:Orang sungguhan, seperti pelanggan, administrator, atau teknisi.
- Sistem Eksternal:Antarmuka perangkat lunak atau perangkat keras lain yang memicu atau menerima data.
- Aktor Berbasis Waktu:Kejadian yang dipicu oleh jam atau pengatur waktu, seperti proses cadangan yang dijadwalkan.
Saat menentukan aktor, berikan peran tertentu alih-alih jabatan tertentu. Misalnya, gunakan “Pengguna Terdaftar” alih-alih “John Doe.” Ini memastikan persyaratan tetap valid meskipun terjadi perubahan personel.
2. Batas Sistem ⬜
Batas sistem menentukan apa yang berada di dalam perangkat lunak dan apa yang berada di luar. Ini menjelaskan tanggung jawab. Semua yang berada di dalam kotak adalah sistem; semua yang berada di luar adalah lingkungan. Perbedaan ini sangat penting untuk menentukan siapa yang bertanggung jawab atas kesalahan atau tindakan tertentu.
3. Tujuan 🎯
Setiap use case mewakili satu tujuan tunggal yang ingin dicapai oleh aktor. Jika sebuah deskripsi berisi beberapa tujuan yang tidak saling berkaitan, maka harus dibagi menjadi use case yang terpisah. Satu tujuan memastikan use case tetap dapat diuji dan dikelola.
📋 Anatomi Deskripsi Use Case
Deskripsi yang komprehensif melampaui diagram sederhana. Ia membutuhkan spesifikasi teks yang mendetailkan alur interaksi. Di bawah ini adalah struktur standar yang digunakan dalam dokumentasi persyaratan profesional.
Metadata dan Identifikasi
- ID Use Case:Identifikasi unik (misalnya, UC-001) untuk pelacakan.
- Nama Use Case:Frasa kata kerja-kata benda yang menggambarkan tindakan (misalnya, “Kirim Pesanan”).
- Aktor Utama:Pengguna utama yang memulai tindakan.
- Aktor Sekunder:Sistem atau pengguna pendukung apa pun.
- Prioritas: Kritis, Tinggi, Sedang, atau Rendah.
Prasyarat
Prasyarat mendefinisikan keadaan sistem sebelum use case dimulai. Jika kondisi-kondisi ini tidak terpenuhi, use case tidak dapat dimulai. Ini membantu tester memahami persiapan yang diperlukan.
- Pengguna harus masuk ke dalam sistem.
- Keranjang belanja harus berisi setidaknya satu item.
- Gerbang pembayaran harus dalam keadaan online.
Pasca kondisi
Pasca kondisi menggambarkan keadaan sistem setelah use case selesai secara sukses. Mereka berfungsi sebagai kriteria penerimaan untuk fitur tersebut.
- Catatan pesanan baru dibuat di database.
- Konfirmasi email dikirim ke pengguna.
- Tingkat persediaan diperbarui.
Alur Kejadian
Ini adalah inti dari deskripsi. Ini menguraikan urutan langkah yang diambil oleh aktor dan sistem. Biasanya dibagi menjadi Adegan Sukses Utama dan Ekstensi.
🚀 Adegan Sukses Utama (Jalur Bahagia)
Adegan Sukses Utama menggambarkan jalur ideal di mana segalanya berjalan dengan baik. Tidak ada kesalahan, gangguan, atau keputusan alternatif. Setiap langkah harus bersifat atomik, artinya merupakan satu tindakan tunggal yang tidak dapat dibagi lebih lanjut tanpa kehilangan makna.
Saat menulis langkah-langkah ini, ikuti pedoman berikut:
- Berilah nomor pada langkah-langkah: Gunakan 1, 2, 3… untuk menunjukkan urutan.
- Tentukan sumbernya: Jelaskan dengan jelas siapa yang memulai langkah tersebut (Aktor atau Sistem).
- Gunakan kata kerja aktif: Mulailah dengan kata kerja aksi seperti “Pilih,” “Masukkan,” “Tampilkan,” atau “Validasi.”
- Hindari istilah teknis: Gambarkan apa yang dilihat pengguna, bukan query database di baliknya.
🛑 Alur Alternatif dan Penyimpangan
Penggunaan dunia nyata jarang mengikuti jalur yang sempurna. Ekstensi menangani penyimpangan dari alur utama. Ini sangat penting untuk pengumpulan persyaratan yang kuat.
Alur Alternatif
Ini terjadi ketika aktor membuat pilihan yang berbeda dari jalur utama. Mereka tetap mengarah pada tujuan yang sama, hanya melalui rute yang berbeda.
- Contoh: Pengguna memilih untuk menerapkan kode diskon saat melakukan checkout.
Aliran Penyimpangan
Ini terjadi ketika sesuatu mengalami masalah. Sistem harus menangani kesalahan secara baik. Tujuan dari use case mungkin gagal, atau mungkin dapat dipulihkan.
- Contoh: Gateway pembayaran mengembalikan pesan kesalahan.
- Contoh: Pengguna memiliki dana yang tidak mencukupi.
Ekstensi harus merujuk pada nomor langkah tertentu dalam Skenario Sukses Utama di mana terjadi penyimpangan.
📝 Contoh Praktis: “Proses Pembayaran”
Untuk mengilustrasikan konsep-konsep ini, pertimbangkan skenario pemrosesan pembayaran yang umum. Contoh ini menunjukkan bagaimana menerjemahkan ide-ide abstrak menjadi langkah-langkah konkret.
| Langkah | Aktor/Sistem | Aksi | Respons |
|---|---|---|---|
| 1 | Aktor | Memilih tombol “Bayar Sekarang”. | – |
| 2 | Sistem | Menampilkan formulir pembayaran. | Formulir muncul dengan kolom kartu. |
| 3 | Aktor | Memasukkan detail kartu. | – |
| 4 | Sistem | Memvalidasi data kartu. | Memeriksa format dan masa berlaku. |
| 5 | Sistem | Mengirim transaksi ke gateway. | – |
| 6 | Gateway | Mengembalikan otorisasi. | Kode sukses atau kesalahan. |
| 7 | Sistem | Mengonfirmasi pembayaran. | Menampilkan layar sukses. |
Alur Alternatif A (Kartu Tidak Valid):
- Pada Langkah 4, jika validasi gagal, tampilkan pesan kesalahan.
- Izinkan pengguna untuk memasukkan data kembali.
Alur Alternatif B (Waktu Habis):
- Pada Langkah 5, jika gateway tidak merespons dalam waktu 10 detik, tampilkan pesan waktu habis.
- Izinkan pengguna untuk mencoba lagi atau membatalkan.
🛠 Praktik Terbaik untuk Kejelasan dan Ketepatan
Menulis persyaratan adalah keterampilan yang membaik dengan latihan. Mematuhi standar tertentu mengurangi kesalahpahaman antara analis bisnis, pengembang, dan pengujicoba.
1. Pertahankan Granularitas
Jangan menggabungkan beberapa tindakan menjadi satu langkah. Jika suatu langkah mengharuskan pengguna mengklik tombol lalu mengetik teks, bagi menjadi dua langkah. Granularitas memastikan bahwa kasus pengujian dapat ditulis untuk setiap interaksi khusus.
2. Hindari Asumsi
Jangan pernah mengasumsikan pengguna mengetahui istilah teknis. Hindari kata-kata seperti ‘parse’, ‘commit’, atau ‘cache’ kecuali antarmuka secara eksplisit menampilkannya. Jelaskan hasilnya, bukan mekanismenya.
3. Konsistensi dalam Terminologi
Gunakan kosakata yang terkendali. Jika Anda menyebutnya ‘Produk’ di satu bagian, jangan menyebutnya ‘Barang’ di bagian lain. Ketidakkonsistenan membingungkan pengembang dan menyebabkan kesalahan pemetaan basis data.
4. Fokus pada Perilaku, Bukan Implementasi
Jelaskan apa yang dilakukan sistem, bukan bagaimana melakukannya. Misalnya, tulis ‘Sistem memeriksa persediaan’ alih-alih ‘Sistem menanyakan tabel persediaan SQL’. Yang pertama memungkinkan tim implementasi memilih teknologi terbaik.
⚠️ Kesalahan Umum yang Harus Dihindari
Bahkan penulis berpengalaman membuat kesalahan. Mengenali pola-pola ini sejak dini mencegah pekerjaan ulang di tahap selanjutnya dalam siklus pengembangan.
Kesalahan 1: ‘Use Case Tuhan’
Ini terjadi ketika satu use case mencoba melakukan terlalu banyak hal. Jika satu use case memiliki 50 langkah, kemungkinan besar mencakup beberapa tujuan. Pisahkan menjadi use case yang lebih kecil dan fokus.
Kesalahan 2: Pra-syarat yang Hilang
Melewatkan pra-syarat membuat penguji bingung tentang keadaan awal. Ini sering menghasilkan uji coba yang tidak stabil yang gagal secara acak karena lingkungan tidak disiapkan dengan benar.
Kesalahan 3: Kata Kerja yang Tidak Jelas
Hindari kata-kata seperti ‘kelola’, ‘tangani’, atau ‘proses’. Kata-kata tersebut terlalu umum. Sebaliknya, gunakan ‘Perbarui’, ‘Hapus’, ‘Hitung’, atau ‘Kirim’. Ketepatan menghilangkan ambiguitas.
Kesalahan 4: Menggabungkan Tingkat Detail yang Berbeda
Jangan mencampur tujuan bisnis tingkat tinggi dengan klik antarmuka pengguna tingkat rendah. Pertahankan Skenario Sukses Utama pada tingkat logis. Detail antarmuka pengguna dapat didokumentasikan secara terpisah dalam wireframe atau spesifikasi antarmuka pengguna.
🔗 Integrasi dengan Spesifikasi Lain
Use case tidak ada secara terpisah. Mereka terhubung dengan artefak lain dalam dokumentasi kebutuhan.
- Pelacakan:Setiap use case harus dipetakan ke cerita pengguna atau tujuan bisnis tertentu. Ini memastikan setiap fitur memiliki tujuan.
- Kasus Uji:Langkah-langkah dalam Skenario Sukses Utama secara langsung diterjemahkan menjadi kasus uji positif. Ekstensi diterjemahkan menjadi kasus uji negatif.
- Desain Antarmuka: Aktor dan langkah-langkah memberikan informasi tentang struktur navigasi dan tata letak layar.
- Desain Basis Data: Data yang disebutkan dalam langkah-langkah (misalnya, ‘Masukkan Kartu Kredit’) memberikan informasi tentang kebutuhan model data.
📊 Perbandingan: Deskripsi yang Efektif vs. Tidak Efektif
Perbedaan antara kebutuhan yang baik dan yang buruk sering terletak pada tingkat detail dan kejelasan. Tabel di bawah ini menyoroti perbedaan-perbedaan tersebut.
| Fitur | ❌ Deskripsi yang Tidak Efektif | ✅ Deskripsi yang Efektif |
|---|---|---|
| Aktor | “Pengguna” | “Admin Terdaftar” |
| Langkah | “Tangani proses login” | “Masukkan nama pengguna dan kata sandi” |
| Hasil | “Sistem memeriksa akses” | “Sistem memvalidasi kredensial terhadap basis data” |
| Pengecualian | “Jika gagal” | “Jika kredensial salah, tampilkan pesan kesalahan dan atur ulang bidang” |
| Cakupan | “Kelola semua hal” | “Lihat dan sunting profil pengguna” |
Perhatikan bagaimana deskripsi yang efektif memberikan tindakan spesifik dan batasan yang jelas. Ini mengurangi beban kognitif bagi pengembang yang menerapkan fitur tersebut.
🧩 Menangani Adegan yang Kompleks
Tidak semua persyaratan cocok dengan alur linier yang sederhana. Beberapa skenario melibatkan proses paralel atau logika bersyarat.
Hubungan Inklusi dan Ekstensi
Dalam UML, use case dapat saling berhubungan. Sebuah Inklusihubungan terjadi ketika satu use case selalu membutuhkan use case lain untuk berfungsi. Sebagai contoh, “Tempatkan Pesanan” selalu mencakup “Validasi Pembayaran.” Ini mengurangi pengulangan dalam deskripsi.
Sebuah Ekstensihubungan memungkinkan satu use case menambahkan perilaku ke use case lain di bawah kondisi tertentu. Sebagai contoh, “Terapkan Diskon” memperluas “Tempatkan Pesanan” hanya jika pengguna memiliki kode kupon.
Proses Paralel
Untuk sistem yang kompleks, satu alur mungkin tidak cukup. Gunakan sub-alur atau diagram terpisah untuk mewakili aktivitas paralel. Pastikan titik interaksi antara alur-alur ini didefinisikan dengan jelas.
🔍 Tinjauan dan Validasi
Setelah deskripsi ditulis, harus divalidasi. Dokumen tidak lengkap hingga telah ditinjau oleh pemangku kepentingan yang relevan.
- Panduan: Lakukan panduan bersama pemilik bisnis. Minta mereka membaca langkah-langkah dan konfirmasi bahwa sesuai dengan model mental mereka.
- Pemeriksaan Kelayakan: Konsultasikan dengan pengembang utama. Pastikan langkah-langkah tersebut dapat dilakukan secara teknis dalam batasan proyek.
- Kelengkapan: Periksa jalur kesalahan yang hilang. Apa yang terjadi jika koneksi internet terputus? Apa yang terjadi jika basis data penuh?
- Konsistensi: Pastikan istilah-istilah konsisten di seluruh dokumen persyaratan.
🛠 Alat dan Format
Format dari deskripsi use case dapat bervariasi tergantung kebutuhan proyek. Format umum meliputi:
- Teks Terstruktur: Format daftar bernomor yang sesuai untuk Word atau Google Docs.
- Format Tabel: Tata letak tabel untuk pemindaian cepat, sering digunakan dalam spreadsheet.
- Masukan Basis Data: Disimpan dalam alat manajemen kebutuhan untuk pelacakan.
- Halaman Wiki: Halaman kolaboratif yang memungkinkan riwayat versi dan tautan.
Terlepas dari media yang digunakan, struktur konten tetap sama. Tujuannya adalah aksesibilitas dan kejelasan, bukan jenis file tertentu.
🔗 Dari Kebutuhan ke Pengujian
Nilai utama dari deskripsi use case terletak pada manfaatnya selama tahap pengujian. Pengujian menggunakan Adegan Sukses Utama untuk menentukan pengujian Jalur “Bahagia”. Mereka menggunakan Ekstensi untuk menentukan pengujian Jalur “Negatif”.
Jika deskripsi use case samar, kasus pengujian akan tidak lengkap. Ini menyebabkan celah dalam cakupan dan bug mencapai produksi. Deskripsi yang jelas berfungsi sebagai kontrak antara tim bisnis dan tim rekayasa.
📈 Mengukur Kualitas
Bagaimana Anda tahu jika use case Anda berkualitas baik? Perhatikan indikator-indikator berikut:
- Uji Coba: Dapatkah seorang pengujian menulis kasus pengujian hanya dari teks ini?
- Tidak Ambigu: Apakah hanya ada satu interpretasi yang mungkin?
- Pelacakan: Dapatkah Anda menghubungkan ini kembali ke tujuan bisnis?
- Kelengkapan: Apakah semua jalur utama dan pengecualian telah dicakup?
🏁 Ringkasan Poin Penting
Membuat deskripsi use case yang efektif membutuhkan disiplin dan perhatian terhadap detail. Ini bukan sekadar mendokumentasikan apa yang dilakukan sistem, tetapi menentukan batasan perilakunya. Dengan fokus pada langkah-langkah atomik, prasyarat yang jelas, dan penanganan pengecualian yang kuat, tim dapat mengurangi ambiguitas dan meningkatkan kualitas pengiriman.
Elemen penting yang perlu diingat meliputi:
- Tentukan aktor dan batas sistem dengan jelas.
- Gunakan format terstruktur dengan ID, Nama, dan Aliran.
- Pisahkan Adegan Sukses Utama dari aliran Alternatif dan Pengecualian.
- Gunakan kata kerja aktif dan istilah khusus.
- Validasi deskripsi dengan pemangku kepentingan sebelum pengembangan dimulai.
Menginvestasikan waktu untuk menulis persyaratan yang jelas memberikan keuntungan sepanjang siklus hidup proyek. Ini mengurangi pekerjaan ulang, memperjelas ekspektasi, dan memastikan produk akhir memenuhi kebutuhan sebenarnya pengguna.
