30% perusahaan software dunia, memilih UML sebagai bahasa pemodelan yang berorientasi obyek (OOD). Saat mengenal UML pertama kali, kita akan dihadapkan pada Use Cases yang digunakan untuk mendeskripsikan suatu proses bisnis. Aktivitas ini sangat vital bagi kesuksesan pengembangan sistem, karena digunakan sebagai acuan dasar dalam proses pengembangan di tahap-tahap berikutnya.

Membuat Use Cases sekilas terkesan mudah (demikian juga menurut saya), namun sebenarnya hal ini adalah tidak benar. Kita mungkin telah mengerti konsep dasar dari Use Cases, namun menemukan cara bagaimana untuk menggambarkan suatu sistem dengan tepat akan menjadi masalah yang cukup berarti. Salah satu faktor penyebab permasalahan ini adalah kurangnya kriteria obyektivitas yang dapat membantu dalam memutuskan kualitas dan efektivitas dari suatu Use Cases.
Berdasarkan pada buku “Patterns for Effective Use Cases”, yang ditulis oleh Steve Adolph, Paul Bramble, Alistair Cockburn, dan Andy Pols, serta diterbitkan oleh Addison Wesley, 23 Agustus 2002, telah menyebutkan permasalahan-permasalahan yang umumnya terjadi pada suatu Use Cases, yaitu:

• Detil antarmuka (interfaces) yang terlalu banyak. Disain detil antarmuka bukanlah kebutuhan utama, tapi merupakan pilihan disain, dan dapat dilakukan setelah Use Cases ditulis dan direview. Pilihan disain awal seringkali akan mengalami perubahan selama pengembangan, dan tentunya dengan batasan bahwa perubahan yang dilakukan masih memuaskan kebutuhan secara keseluruhan. Pakar Use Case umumnya akan memperingatkan terhadap pembuatan disain antarmuka di dalam Use Case, karena hal ini akan menyebabkan penambahan biaya, waktu, dan usaha dalam menulis dan mereview kembali yang cukup banyak, dan menyebabkan lebih banyaknya dokumen kebutuhan yang diperlukan.
• Tujuan level rendah yang terlalu banyak pada disain Use Cases. Programer seringkali terjebak dengan tugas menulis dokumen kebutuhan, dan memiliki kecenderungan untuk menghasilkan berbagai Use Cases level rendah di level “Authorize User”. Walaupun mungkin akan menarik untuk menjelaskan fungsi-fungsi dan fitur-fitur sistem, tapi hal ini akan menyebabkan dokumen kebutuhan menjadi sangat panjang pada suatu level tertentu, dan menyulitkan bagi pengguna akhir untuk membacanya. Dokumen-dokumen ini tidak memperlihatkan secara tepat apa konstribusi dari sistem bagi pengguna akhir di dunia kerja nyata yang berkaitan dengan sistem yang dikembangkan.
• Penggunaan Use Case untuk informasi yang bukan tingkah laku (non-Behavioral). Kadang penulis akan mengatakan “Use Case bagus. Tulis apapun dalam Use Cases.” Tapi sebenarnya Use Case tidak untuk apa saja, ia hanya tepat untuk menjelaskan tingkah laku. Apapun yang seharusnya dilakukan oleh sistem harus ditulis di Use Case, tapi untuk selain itu seharusnya ditulis dalam format yang lain. Deskripsi tentang kebutuhan kinerja, aturan-aturan bisnis yang komplek, struktur-struktur datam dan lini produksi adalah sangat berharga, namun akan lebih baik bila dicatat dengan alat bantu kebutuhan yang lain, seperti tabel, formula, atau di seksi lain dari dokumen kebutuhan.
• Terlalu panjang. Ketiga kesalahan yang umum terjadi di atas, akan menyebabkan Use Cases menjadi terlalu panjang dan susah untuk dibaca. Disain Use Case yang baik harus pendek, biasanya hanya 3 sampai 9 tahap.
• Tidak mencapai tujuan akhir. Walaupun semakin pendek semakin baik, perlu diperhatikan bahwa Use Case harus dapat menangkap semua tingkah laku untuk menyelesaikan tujuan, tidak hanya menjelaskan beberapa fragmen dari tingkah laku tertentu saja. Karena hal ini akan menyebabkan masalah selama implementasi, dimana Use Case tidak berkaitan antara yang satu dengan yang lain, dan programer harus menebak bagaimana menghubungkannya.
• Fragmen-fragmen pernyataan. Kesalahan yang relatif minor, namun masih perlu diperhatikan, seperti mengabaikan nama aktor pada suatu aksi di tahapan tertentu akan dapat menyebabkan kebingungan atau kerancuan pada saat pelatihan pada pengguna.

Richard Denney, dalam bukunya “Succeeding with Use Cases Working Smart to Deliver Quality”, yang diterbitkan oleh Addison Wesley Professional, 26 April 2005, menawarkan beberapa pendekatan untuk mengatasi kesulitan-kesulitan ini, yaitu:

• Penggunaan pendekatan Quality Function Deployment (QFD) untuk memastikan produk yang kita luncurkan telah tepat sesuai dengan prespektif bisnis yang diharapkan.
• Penggunaan pendekatan Software Reliability Engineering (SRE) untuk memaksimalkan reliabilitas dan kepuasan pelanggan, saat meminimalkan biaya pengembangan.
• Penggunaan pendekatan Model-Based Specification untuk menajamkan analisa terhadap kegagalan-kegagalan yang potensial.
• Penggunaan pendekatan Configuration Management pada Use Cases untuk membantu dalam bekerja lebih pintar.
• Menganalisa Use Cases dengan pendekatan Project Portfolio Management, sehingga pengembangan proses yang paling bernilai dari yang dapat kita buat dapat diidentifikasi.

Demikian sedikit ulasan saya, dari hasil membaca 2 buku (ebook) yang menjadi tersebut di atas. Rupanya membuat Use Cases memang tidak semudah yang saya kira sebelumnya. Semoga berguna.

[ROM]