View metadata, citation and similar papers at core.ac.uk Volume 2 Nomor 3, Oktober 2006 Penerapan Analisis Kebutuhan Metode Use Case pada Metode Pengembangan Terstruktur Nyimas Artina STMIK MDP Palembang Email: nyimas@stmik-mdp.net Abstrak: Salah satu faktor terbesar dalam keberhasilan pengembangan perangkat lunak adalah memahami kebutuhan dari pengguna. Kebutuhan ini dituangkan dalam fitur-fitur yang disediakan dalam perangkat lunak tersebut. Kegagalan dalam memahami kebutuhan pengguna akan menyebabkan produk perangkat lunak yang dihasilkan tidak sesuai dengan keinginan dan kebutuhan pengguna. Untuk itu perlu dilakukan analisis kebutuhan yang disusun dari kebutuhan bisnis pengguna dan diwujudkan dalam kebutuhan sistem. Analisis kebutuhan dengan metode use case merupakan salah satu metode yang paling banyak digunakan. Meskipun metode ini berawal dari penggunaannya pada pengembangan berorientasi objek namun tidak menutup kemungkinan penerapannya pada metode pengembangan terstruktur. Pada artikel ini dibahas penggunaan metode use case pada metode pengembangan terstruktur. Dari pembahasan ini dapat dibuktikan bahwa analisis kebutuhan dengan metode use case dapat dengan mudah diterapkan pada pengembangan terstruktur karena use case sendiri tidak tidak memiliki sifat-sifat objek. Kata Kunci: use case, analisis kebutuhan, analisis terstruktur, kebutuhan sistem. 1 PENDAHULUAN lebih tinggi dibandingkan dengan biaya identifikasi dan perbaikannya pada awal pengembangan. Tantangan terbesar yang dihadapi oleh pengembang perangkat lunak adalah mendiskusikan produk akhir dengan pengguna/pelanggan. Kadang kala semua yang terlibat baik dari sisi pengembang maupun dari sisi pengguna sudah mendapatkan tentang produk yang akan gambaran umum dihasilkan tapi terkadang juga ada yang kaget karena produk yang dihasilkan tidak sesuai dengan harapan. Untuk itu, diperlukan suatu cara untuk menangkap secara akurat, menginterpretasikan, dan mewujudkan apa yang menjadi keinginan pengguna/pelanggan dalam menetapkan kebutuhan (requirement) untuk suatu produk perangkat lunak. Pada artikel ini akan dibahas penerapan analisis kebutuhan metode use case pada metode pengembangan terstruktur. Sebenarnya use case merupakan metode analisis yang biasa digunakan dalam pengembangan berorientasi objek namun tidak tertutup kemungkinan untuk digunakan dalam pengembangan perangkat lunak menggunakan metode terstruktur. 2 PEMBAHASAN 2.1 Analisis Terstruktur Dalam rekayasa perangkat lunak, analisis kebutuhan merupakan bagian yang relatif mudah. Meskipun demikian, bagian ini tidak bisa diabaikan karena merupakan bagian yang vital. Kegagalan dalam mengidentifikasi dapat menyebabkan kegagalan dalam memenuhi kebutuhan pengguna/pelanggan atau menyelesaikan produk secara tepat waktu. Di samping itu, penanganan masalah pada waktu pengembangan sebagai akibat dari masalah kebutuhan memerlukan biaya yang kebutuhan terstruktur dipopulerkan (1978) dan pertama kali oleh De Marco Gane&Sarson (1979). Istilah ini tidak serupa dengan pemrograman terstruktur yang sudah ada sejak sebelum tahun 1978. Analisis terstruktur merupakan reaksi dari metode informal yang sebelumnya banyak digunakan. Fitur utama dari metode informal ini adalah deskripsi naratif yang tersusun secara berurutan dari apa yang akan dilakukan sistem yang Istilah analisis Hal - 1 brought to you by CORE provided by STMIK GI MDP
Volume 2 Nomor 3, Oktober 2006 diusulkan. Spesifikasinya berupa tata letak rekaman (record), bentuk laporan, dan bagan alir (flowchart). Ide utama dari istilah terstruktur adalah bahwa metode ini mengandung enam kriteria: 1. titik awal yang jelas, baik bagi analis yang membuat spesifikasi maupun bagi siapapun yang membacanya, tempat yang jelas bagi setiap bagian informasi kebutuhan yang relevan serta hubungan yang jelas antar komponen dari spesifikasi sistem, 2. 3. dihindarinya pengulangan, 4. konsistensi antar komponen, 5. dihindarinya ambigu, dan 6. akhir spesifikasi berakhir. 3. dihindarinya pengulangan, 4. konsistensi antar komponen, 5. dihindarinya ambigu, dan 6. akhir spesifikasi berakhir. Metode terstruktur tidak mengharuskan untuk menggunakan tehnik dokumentasi yang spesifik. Ada kebebasan dalam memilih tehnik dokumentasi sehingga tidak terikat pada salah satu tehnik tertentu dalam setiap komponennya. Dengan kata lain, jika kita tidak suka menggunakan salah satu tehnik dokumentasi pada suatu komponen maka bisa digunakan tehnik lain untuk tujuan yang sama. 2.2 Manajemen Kebutuhan Manajemen kebutuhan adalah pendekatan sistematis untuk mendapatkan, mendokumentasikan, mengatur, dan melacak perubahan kebutuhan. Serangkaian kegiatan dan dokumentasi dibutuhkan untuk dapat membuat suatu manajemen kebutuhan yang lengkap dan memadai. Salah satu alat bantu yang cukup handal untuk digunakan dalam manajemen kebutuhan adalah menggunakan use case. Penyusunannya dapat dibantu dengan menggunakan perangkat lunak Rational Requisite Pro. Gambar 1 mengilustrasikan hubungan antara keperluan (need) dari pengguna. Keperluan ini akan diwujudkan dalam fitur perangkat lunak. Fitur inilah yang akan menjadi kebutuhan perangkat lunak dan kebutuhan. dikelola Sederhananya, dari hal-hal yang diperlukan oleh pengguna disusun fitur-fitur perangkat lunak yang dikelola dalam manajemen kebutuhan. dalam manajemen Hal - 2 Keperluan Fitur Kebutuhan Perangkat Lunak Gambar 1: Piramida Kebutuhan Keperluan (need) adalah refleksi dari masalah bisnis, pribadi, atau operasional (dan juga kesempatan) yang harus dikemukakan untuk menjustifikasi pengembangan atau pembelian sistem baru. Keperluan tersebut diwujudkan dalam fitur yang berupa layanan dan atribut yang disediakan sistem untuk memenuhi keperluan pengguna. Fitur ini akan dikelola dalam kebutuhan yang merupakan kemampuan dari sistem yang diperlukan pengguna untuk menyelesaikan masalah atau untuk mencapai suatu sasaran tertentu. 2.3 Use Case Setelah pemrograman berorientasi objek menjadi mapan pada tahun 1990-an, para ahli metodologi mulai mengadopsi beberapa konsepnya dan membuatnya menjadi sistem berorientasi objek. Pada awalnya metode ini tidak terstruktur secara bisa menggantikan analisis keseluruhan. Ada aspek yang tidak terpenuhi yaitu dalam hal spesifikasi sistem eksternal atau kebutuhan pengguna. Sebagian analis mengadopsi sebagian dan komponen metode memadukannya dengan analisis terstruktur. Hal ini dilakukan karena perwakilan pengguna tidak dapat jika mengerti dokumentasi yang dihasilkan menggunakan analisis berorientasi objek murni. analisis berorientasi objek Jacobson memperkenalkan use case yang jika diamati serupa dengan cara naratif dari tahun 1960-an dalam melakukan spesifikasi sistem aplikasi. Metode ini berhasil melengkapi metodologi berorientasi objek Pada tahun 1992, Ivar
Volume 2 Nomor 3, Oktober 2006 dari sisi analisis kebutuhan. Dengan adanya use case maka sisi lemah metodologi berorientasi objek dapat dilengkapi. Sejak tahun 1990-an, use case dengan cepat menjadi praktek yang paling banyak digunakan dalam menangkap kebutuhan fungsional. Hal ini khususnya terjadi pada komunitas berorientasi objek di mana metode ini berasal. Penerapannya tidak hanya terbatas pada sistem berorientasi objek saja karena use case sebenarnya tidak bersifat berorientasi objek. Gambar 2: Notasi Utama Diagram Use Case Use case merupakan tehnik menangkap kebutuhan-kebutuhan fungsional dari sistem baru atau sistem yang diubah. Setiap use case terdiri dari satu atau lebih skenario yang menerangkan bagaimana sistem berinteraksi dengan pengguna atau sistem yang lain untuk mencapai suatu sasaran bisnis tertentu. Dalam tehnik ini tidak diterangkan cara kerja maupun implementasinya. Yang ditunjukkan adalah langkah- dalam dilakukan langkah menggunakan perangkat lunak. sistem secara internal yang pengguna manajemen kebutuhan karena membutuhkan dokumentasi yang panjang. Pendekatan yang dilakukan adalah memaparkan keperluan pengguna yang kemudian diwujudkan dalam fitur dan kemudian dibuatkan use case-nya. Setelah itu use case tersebut dibuatkan pemodelan prosesnya menggunakan digram aliran data (DFD - Data Flow Diagram). Diagram aliran data merupakan tehnik pemodelan proses yang umum digunakan dalam pengembangan sistem metode terstruktur. Pada dasarnya ada dua jenis use case yaitu diagram use case dan naratif use case. Diagram use case menggambarkan secara grafis hubungan aktor dan satu atau (gambar 2). Penggambarannya menggunakan notasi gambar orang, anak panah, dan elips. lebih use case Contoh kasusnya adalah PT. ABC yang akan membuat aplikasi helpdesk untuk para karyawannya sebagai sarana penyampaian, penanganan, dan pelacakan permintaan bantuan teknis. Berikut ini adalah sebagian keperluan, fitur, dan use case yang digunakan pada pengembangan sistem yang akan dibangun. Naratif use case ditinjau dari formatnya dibagi menjadi tiga jenis yaitu ringkas (brief), kasual (casual), dan lengkap (fully dressed). Pemilihan format peruntukannya. Gambaran lengkap yang berisi langkah-langkah interaksi antara aktor dan sistem dituangkan dalam naratif use case dengan format lengkap. Bentuk penampilannya namun mengandung komponen-komponen yang sama. disesuaikan dengan bisa berbeda-beda a. Keperluan 1. Memerlukan dibangun suatu media akses yang baru dan mudah untuk mengirimkan dan menampung pengguna teknologi informasi dalam organisasi. 2. Memerlukan sistem yang mudah untuk memantau/melacak masalah yang ada dan siapa yang menyampaikannya. keluhan 2.4 Penerapan Use Case Selanjutnya kita akan membahas penerapan use case dalam metode pengembangan sistem terstruktur. Pada pembahasan ini tidak dilakukan pemaparan yang menyeluruh dari semua aspek 3. Memerlukan basis data yang mampu menampung keluhan yang ada, yang selesai, maupun yang sedang dalam proses penyelesaian. 4. Memerlukan sistem yang dapat menugaskan staf untuk menangani masalah. 5. Lain-lain. Hal - 3
Volume 2 Nomor 3, Oktober 2006 b. Fitur 1. Sistem memiliki fungsi yang dapat digunakan pengguna untuk menyampaikan keluhan masalah. 2. Sistem memiliki fungsi bagi pengguna untuk mengetahui status permasalahan yang disampaikan. 3. Sistem memiliki fungsi untuk menampung keluhan masalah. 4. Sistem memiliki fungsi untuk menugaskan staf untuk menangani masalah. 5. Lain-lain. c. Use case 1. Kirim permintaan 2. Lacak permintaan. 3. Penugasan. 4. Lain-lain. Sebagian dari hubungan antara keperluan dan fitur digambarkan dalam tabel 1 berikut. Tabel 1: Hubungan keperluan dan fitur Keperluan Fitur 1 2 3 4 1 V 2 V 3 V 4 V Sebagian dari hubungan antara fitur dan use case digambarkan dalam tabel 2 berikut. Tabel 2: Hubungan fitur dan use case Fitur Use case 1 2 3 4 1 2 3 V V V Tabel 1 dan 2 merupakan hubungan antara keperluan dan fitur serta hubungan antara fitur dan use case. Hubungan yang digambarkan tidak selalu bersifat pemetaan satu-satu. Bisa saja satu keperluan dipetakan dalam dua fitur dan sebagainya. Hal - 4 Tabel 3: Glosarium use case (sebagian) Use case Deskripsi 1 2 3 Use case ini menggambarkan proses pengiriman permintaan oleh pengguna. Pengguna mengirimkan permintaan sesuai dengan masalah yang terjadi untuk akan selanjutnya diklasifikasikan berdasarkan jenis permasalahan penyelesaian permasalah. Aktornya adalah pengguna sistem. Use case ini menggambarkan proses yang dilakukan oleh pengguna untuk mengetahui sampai sejauh mana penyelesaian suatu permintaan yang telah dikirim. Aktornya adalah pengguna sistem. Use case ini menggambarkan proses pemberian tugas kepada staf Helpdesk. Setiap tugas akan diklasifikasikan menjadi tiga tingkat masalah yaitu mudah, sedang, rumit serta tiga tingkat prioritas yaitu mendesak, umum, tidak mendesak. Tingkat masalah akan menentukan spesifikasi petugas yang tersebut akan menangani prioritas sedangkan menentukan kecepatan/prioritas penyelesaian permasalahan. Untuk tingkat masalah yang mudah dan sedang maka cukup ditangani oleh petugas tingkat 1 sedangkan tingkat masalah yang rumit akan langsung ditangani oleh petugas tingkat 2 dan 3. Tingkat prioritas mendesak harus didahulukan untuk segera diselesaikan dibandingkan tingkat prioritas umum dan tidak mendesak. Aktornya adalah staf Helpdesk. dan prioritas tugas tingkat Deskripsi use case digambarkan dalam tabel 3. Ini merupakan use case dalam format ringkas.
Volume 2 Nomor 3, Oktober 2006 Tabel 4: Spesifikasi Use case Nama use case Pembuat Tanggal Versi Deskripsi Singkat Kirim Permintaan Nyimas Artina 10/11/2006 1.0 Use case ini menggambarkan proses pengiriman permintaan oleh pengguna. Pengguna mengirimkan permintaan sesuai dengan masalah yang terjadi untuk selanjutnya akan diklasifikasikan berdasarkan jenis permasalahan dan prioritas penyelesaian permasalah. Pengguna Sistem Aktor Utama Aliran Kejadian 1. Aliran Dasar Aktor 1. Use case mulai ketika pengguna memilih untuk mengirimkan permintaan. Sistem 2. Sistem meminta Nama Pengguna dan Kata Sandi. 3. Pengguna memasukkan Nama Pengguna dan Kata Sandi. 4. Sistem memvalidasi Nama Pengguna dan Kata Sandi. 5. Sistem membuka layar Permintaan yang berisi: Nama (otomatis terisi) Tanggal (otomatis terisi) Deskripsi masalah Jenis masalah Prioritas 6. Pengguna mengisikan informasi permintaan berikut: Deskripsi masalah Jenis masalah Prioritas 7. Pengguna mengirimkan permintaan. 8. Sistem memasukkan permintaan ke dalam basis data dan merespon dengan menampilkan pesan bahwa permintaan telah diterima dan memberikan No. Tiket dan use case berakhir. 2. Aliran Alternatif Nama Pengguna dan Kata Sandi salah no. 3, pengguna Pada aliran memasukkan Pengguna Nama dan/atau Kata Sandi yang tidak valid. Sistem menampilkan pesan kesalahan yang menyatakan bahwa Nama Pengguna dan/atau Kata Sandi tidak valid. Use case melanjutkan ke aliran no. 2. Kebutuhan Khusus 1. Kebutuhan Kinerja No. Tiket digenerasi secara otomatis dalam waktu kurang dari satu menit Prakondisi Pasca Kondisi Tidak ada Tidak ada Hal - 5
Volume 2 Nomor 3, Oktober 2006 Gambaran lengkap use case terdapat dalam spesifikasi use case (tabel 4). Selanjutnya adalah menggambarkan diagram aliran data berdasarkan rincian yang terdapat dalam Penekanan pembahasan hanya difokuskan pada penyusunan keperluan pengguna yang kemudian menjadi fitur dari aplikasi. Fitur-fitur inilah yang kemudian dibuatkan use case-nya. Tahap selanjutnya adalah melakukan pemodelan proses menggunakan Gambar 3: DAD Logis Proses Kirim Permintaan use case. Gambar 3 memperlihatkan diagram aliran data logis dari proses pengiriman permintaan layanan bantuan teknis. Proses ini berkorelasi dengan use case "Kirim Permintaan". diagram aliran data berdasarkan use case yang sudah dibuat. DAFTAR PUSTAKA 3 PENUTUP [1] Firesmith, D.G. Use Cases: The Pros and Cons, Diakses pada 15/11/2006. Analisis kebutuhan menggunakan metode use case dapat dengan mudah diterapkan pada perancangan sistem dengan metode terstruktur. Hal ini memungkinkan karena meskipun use case umumnya pengembangan berorientasi objek namun pada dasarnya use case tidak memiliki sifat-sifat objek. Use case lebih ke arah urut-urutan aksi dari aktor dan respon dari sistem. Maka dari itu penerapannya pada metode pengembangan terstruktur tidak mengalami masalah sama sekali. Bahkan dengan penggunaan use case, penggambaran diagram aliran data menjadi lebih mudah dilakukan. digunakan dalam [2] Haumer, Peter. Requirement Management with Use Cases, Diakses pada 15/11/2006. [3] Weisert, Analysis Methodology Backwards, Sliding Diakses pada 20/11/2006. Conrad. Systems [4] Whitten, Jeffrey L., Lonnie D. Bentley, dan Kevin C. Dittman, 2004. Systems Analysis and Design Methods, Boston: McGraw Hill. Artikel ini tidak membahas secara rinci keseluruhan aspek analisis dan perancangan. [5] _______. analysis.htm. Diakses pada 20/11/2006. Requirement Analysis, Hal - 6