Cara Menulis Kasus Penggunaan yang Efektif

Diterbitkan: 2015-08-21

Cara Menulis Kasus Penggunaan yang Efektif

Use case digunakan secara luas untuk mendokumentasikan logika bisnis dan proses sistem. Tetapi ada banyak pendapat tentang apakah mereka berguna dan bagaimana mereka harus terstruktur. Dalam beberapa proyek, pengembang tidak pernah melihat kasus penggunaan yang mengatakan bahwa mereka bertele-tele atau mereka benar-benar tidak mengerti banyak dari mereka. Apa yang dapat dilakukan seorang analis bisnis untuk membuat kasus penggunaan benar-benar efektif?

Sebagian besar dari kita menyadari bahwa use case menggambarkan proses bisnis dan merupakan spesifikasi untuk interaksi antara sistem dan aktor untuk tujuan tertentu. Dokumen use case berbeda dari dokumen persyaratan dan tidak sama dengan dokumen desain.

Mari kita lihat dua contoh kasus penggunaan untuk persyaratan. Manakah dari mereka yang menurut Anda lebih baik.

Contoh 1

Gunakan detail kasus Komentar

Nama Kasus Penggunaan – Pesan Tiket

Namanya bagus. Ini dengan jelas memberikan indikasi tentang apa use case

Sasaran – Pelanggan berhasil memesan tiket pertandingan sepak bola di situs web

Deskripsi- Aktor mengunjungi situs web, melihat
jadwal, pilih pertandingan
dan kursi, buku
tiket dan melakukan pembayaran untuk pertandingan sepak bola

Tujuan dan deskripsi disebutkan dengan jelas.
Ini akan membantu para desainer
dan pengembang memahami apa itu
tujuan dari dokumen dan kode desain mereka

Aktor – Pelanggan, Perwakilan Layanan Pelanggan
Prasyarat – Sistem aktif dan berjalan.
Pemicu – Aktor telah mengakses sistem untuk memesan tiket.
Post-Condition – Aktor dapat memesan tiket. Sistem memperbarui informasi.

Semua detail kasus penggunaan lainnya seperti Aktor,
prasyarat, kondisi pasca dan
pemicu disebutkan yang akan membantu
desain dan pengembangan aplikasi lebih mudah.

Alur Utama – Langkah

  1. Aktor mengakses situs web dan memilih untuk memesan tiket
  2. Sistem menampilkan informasi pemesanan
  3. Aktor mengonfirmasi detail kecocokan (Rincian lebih lanjut dalam spesifikasi UI)
  4. Aktor mengkonfirmasi detail kursi (Rincian lebih lanjut di Spesifikasi UI)
  5. Sistem mengonfirmasi ketersediaan
  6. Sistem menyajikan formulir untuk mendapatkan informasi pengguna
  7. Aktor memberikan informasi pengguna (Rincian dalam kasus penggunaan lain)
  8. Sistem menyajikan formulir untuk informasi pembayaran
  9. Aktor memberikan informasi pembayaran (Rincian dalam kasus penggunaan lain)
  10. Sistem mengonfirmasi detail dan memberikan ID pemesanan
  11. Aktor menyimpan tiket
  12. Aktor keluar dari sistem.

Kasus penggunaan yang disertakan

- Melakukan pembayaran

– Buat ID Pemesanan

Kasus Penggunaan yang Diperpanjang

– Buat Catatan Kegagalan Pembayaran

– Cetak Tiket

Langkah-langkah dalam alur utama jelas tapi
Detail UI ditinggalkan. Detail UI dalam kasus penggunaan
tentang pemilihan kursi dan pertandingan
seleksi dapat membuat use case menjadi berat.
Use case dengan jelas menunjukkan apa yang harus dilakukan aktor dan apa yang akan dilakukan sistem
Proses pembayaran dirinci dalam a
kasus penggunaan yang berbeda sehingga tugas dapat
mudah dipecah menjadi komponen desain yang berbeda.
Kasus penggunaan yang disertakan dan diperpanjang diberi nama
sehingga seseorang dapat
referensi mereka untuk rincian lebih lanjut.

Aliran Alternatif

-membatalkan Tiket

  1. Aktor membatalkan transaksi
  2. Sistem membatalkan transaksi

Aliran Pengecualian

-Tiket tidak tersedia untuk pertandingan yang dipilih/kursi yang dipilih

1. Sistem menampilkan pesan kesalahan

Aliran Alternatif dan Pengecualian dirinci.

* Kasus penggunaan dapat lebih rinci dalam hal referensi dan aliran alternatif dan pengecualian. Contoh ini adalah untuk menyoroti apa yang harus dicakup dalam use case yang ditulis dengan baik.

Contoh – 2

Gunakan detail kasus Komentar

Nama Kasus Penggunaan – Pemesanan Tiket

Nama tersebut bukan dari sudut pandang pengguna dan tampak seperti definisi proses bisnis.

Deskripsi – Aktor mengunjungi situs web, melihat jadwal, memilih pertandingan dan kursi, memesan tiket dan melakukan pembayaran untuk pertandingan sepak bola

Tujuan dari use case tidak ada. Desainer, Analis Uji, dan pengembang tidak akan mengerti mengapa fungsi ini harus dikembangkan.

Aktor – Pelanggan, Perwakilan Layanan Pelanggan
Pemicu – Aktor telah mengakses sistem untuk memesan tiket.
Post-Condition – Aktor dapat memesan tiket. Sistem memperbarui informasi.

Pra-kondisi hilang.

Langkah Aliran Utama

  1. Pelanggan mengakses situs web dan memilih opsi 'Pesan Tiket' 'untuk memesan tiket
  2. Sistem menampilkan daftar kecocokan dalam dropdown.
  3. Perwakilan Layanan Pelanggan memilih dari dropdown
  4. Sistem menampilkan detail kursi di peta kursi
  5. Aktor memilih kursi. Jika kursi tidak tersedia dan pesan kesalahan ditampilkan.
  6. Aktor memberikan detail pembayaran
  7. Aktor memesan tiket jika tidak membatalkan tiket.
  8. Sistem menghasilkan id pemesanan menggunakan nama depan pelanggan dan nomor 4 digit yang dihasilkan secara acak

Kasus penggunaan yang disertakan
- Melakukan pembayaran

Dalam langkah-langkah kasus penggunaan, ada beberapa referensi ke elemen UI aktual yang dapat membingungkan pembaca. Aliran alternatif ditulis dalam aliran utama yang membuat sulit untuk memahami seluruh proses.
Aktor ini disebut dengan banyak nama – 'Pelanggan, Aktor, dan Perwakilan Layanan Pelanggan yang membingungkan.
Pembuatan id pemesanan dijelaskan di sini meskipun tidak menjadi perhatian para aktor yang terkait dengan pemesanan tiket.
Tidak ada aliran alternatif, aliran pengecualian, dan tidak disebutkan semua kasus penggunaan terkait.

Kasus penggunaan ini tidak memiliki kejelasan dan perincian dan tidak akan membantu tim dalam mengembangkan fungsionalitas dengan benar.

Apa yang seharusnya ada dalam use case Apa yang seharusnya tidak ada dalam use case
  1. Nama
  2. Deskripsi/Tujuan
  3. Pra kondisi
  4. Pemicu
  5. Aliran Dasar dan Aliran Alternatif
  6. Skenario Pengecualian
  7. Kondisi posting
  8. Persyaratan khusus jika ada
  9. Tautan ke detail UI dan model/diagram terkait lainnya
  1. Detail implementasi
  2. Pemrosesan internal
  3. Persyaratan non-fungsional
  4. Detail Antarmuka Pengguna harus dilakukan secara bersamaan dengan kasus penggunaan tetapi dalam dokumen terpisah

.

Beberapa tip yang harus diikuti untuk menulis kasus penggunaan yang bermanfaat:

  1. Tulis langkah-langkah use case dari perspektif aktor.
  2. Kasus penggunaan tidak boleh memiliki detail desain dan arsitektur. Itu harus berkonsentrasi pada proses bisnis.
  3. Lebih baik jika langkah-langkah dalam use case ditulis dalam urutan waktu
  4. Bergantung pada persyaratan dan kerumitannya, putuskan apakah operasi CRUD (Buat, Baca, Perbarui, dan Hapus) perlu disimpan dalam kasus penggunaan terpisah atau dapat digabungkan menjadi satu.
  5. Penting untuk memberikan referensi ke dan dari aliran alternatif, aliran pengecualian, termasuk kasus penggunaan dan kasus penggunaan yang diperluas sehingga desain bisnis selesai.
  6. Pilih template (yang ditentukan proyek, yang ditentukan perusahaan, atau yang terperinci) dan ikuti struktur untuk semua kasus penggunaan.
  7. Penting untuk memiliki diagram kasus penggunaan.
  8. Di Agile, kami memiliki cerita pengguna untuk menangkap persyaratan. Kisah pengguna dapat dirinci menggunakan kasus penggunaan lean secara berulang.
  9. Validasi harus dirinci.

Setelah Anda menulis sebuah use case, ajukan pertanyaan-pertanyaan ini dan use case tersebut efektif jika jawabannya adalah “Ya” untuk semua pertanyaan –

  1. Akankah pengguna tahu kapan aliran bisnis yang ada dalam use case dieksekusi?
  2. Apakah jelas siapa yang akan melakukan langkah apa dari use case?
  3. Apakah deskripsi logika bisnis sedemikian rupa sehingga ada informasi yang cukup untuk analisis, desain, pengembangan, dan pengujian?
  4. Apakah ada referensi yang tepat dari aliran utama ke aliran alternatif dan pengecualian?
  5. Apakah ada diagram use case yang ada?

Use case adalah cara yang efektif untuk menangkap persyaratan dan secara formal mendokumentasikan proses bisnis jika ditulis dengan baik. Seluruh tim harus dilatih untuk menggunakan kasus penggunaan untuk melakukan tugas mereka. Use case dan use case diagram adalah cara yang bagus untuk mendiskusikan proses bisnis dengan klien. Lebih baik memiliki template use case standar dengan pedoman penulisan use case. Kasus penggunaan yang ditulis dengan cara ini akan dihargai oleh semua anggota tim proyek dan pemangku kepentingan.