Panduan membuat use case untuk product manager dan product developer
Download as DOCX, PDF3 likes1,641 views
Dokumen ini merupakan panduan untuk membuat use case bagi product manager dan developer, menjelaskan konsep dasar use case, aktor, dan skenario interaksi. Prosesnya meliputi mendefinisikan kebutuhan, menetapkan aktor dan use case, serta menyusun skenario yang mencakup berbagai kondisi. Contoh detail use case untuk sistem pemesanan makanan juga diberikan, mencakup langkah-langkah dan pengecualian yang mungkin terjadi.
Panduan membuat use case untuk product manager dan product developer
- 1. Panduan Membuat Use Case Untuk Product Manager dan Product Developer Ditulis oleh: M. Rachmat Gunawan Product Development Group Head PT INTI © 2014
- 2. 1. Tentang Use Case Use Case diperkenalkan sebagai bagian dari metodologi pengembangan berorientasi obyek oleh Ivar Jacobson pada tahun 1992. Namun begitu, Larry Constantine, dkk, telah mengembangkan Use Case ini bukan hanya untuk penggunaan di pemrograman berorientasi obyek melainkan untuk keperluan pendefinisian kebutuhan dan desain User Interface. Setiap Use Case menggambarkan sebuah skenario di mana seorang user berinteraksi dengan sistem yang sedang dibuat untuk menyelesaikan satu tugas tertentu. Sebuah Use Case dapat dibuat dalam bentuk tekstual ataupun berbentuk diagram. Terminologi yang perlu dipahami di dalam Use Case adalah: a. Aktor: adalah orang, organisasi, atau sistem eksternal yang berinteraksi dengan sistem yang akan dibuat b. Use Case: menggambarkan serangkaian aksi yang terukur yang dilakukan oleh aktor terhadap sistem dan memberikan nilai tertentu terhadap aktor. c. Hubungan atau Relasi: menggambarkan jenis interaksi antara aktor dengan use case, antara use case dengan use case, dan antara aktor dengan aktor. 2. Mendefinisikan Kebutuhan menggunakan Use Case Menggambarkan Use Case hanyalah bagian kecil dari pendefinisian kebutuhan. Deskripsi tekstual yang lebih lengkap diperlukan untuk membantu Product Developer di dalam pekerjaan desain dan prototyping produk, serta diperlukan pula sebagai sarana komunikasi antara Product Manager dengan tim Product Developer. Berikut ini adalah langkah-langkah sederhana untuk mendefinisikan kebutuhan menggunakan Use Case: a. Berdasarkan rumusan masalah dan tujuan, tetapkan sebuah sistem yang akan dibuat Sistem adalah suatu himpunan keadaan yang memetakan serangkaian masukkan ke dalam sistem menjadi serangkaian keluaran dari sistem. Ia adalah himpunan terbatas yang memiliki batas-batas yang jelas yang memisahkannya dari sistem yang lain. Dalam langkah
- 3. pertama ini, perjelaslah sistemnya, tentukan batas-batasnya, dan sistem apa saja yang berbatasan dengannya. b. Menetapkan Aktor Setelah jelas definisi sistem yang akan dibuat, langkah kedua adalah menetapkan aktor yang terlibat di dalamnya. Aktor bisa berupa orang atau sistem lain di luar sistem yang sedang dibuat. Misalnya, GSM Model adalah sistem di luar sistem software SMS Gateway. Catatan: bisa jadi banyak sekali aktor yang akan berinteraksi terhadap sistem yang dibuat, namun begitu tidak semua aktor perlu dipertimbangkan. Kadangkala ada faktor tertentu yang mengharuskan kita mengabaikannya. Jadikanlah itu sebagai batasan alih-alih memasukkannya ke dalam dokumen kebutuhan dan menyebabkan kalian menjadi sakit kepala nantinya. c. Menetapkan Use Case untuk Setiap Aktor Untuk setiap aktor, tetapkanlah ‘kerja’ apa yang akan dia lakukan terhadap sistem. Misalnya, untuk aktor Mahasiswa, maka Use Casenya adalah ’memesan makanan’. d. Menetapkan skenario untuk setiap Use Case Untuk setiap Use Case, buatkan sebuah skenario. Skenario yang dibuat dapat mirip sebuah skenario di dalam film. Skenario tersebut harus menyebutkan prekondisi (kondisi aktor dan sistem sebelum aktor melakukan aksi), postkondisi (kondisi aktor dan sistem setelah aktor melakukan aksi), langkah-langkah kejadian normal, langkah-langkah kejadian alternatif (bila langkah normal tidak terpenuhi), skenario pengecualian, prioritas skenario, aturan-aturan yang harus dipenuhi (misalnya rumus-rumus, formula, algoritma, dll), dan frekuensi kejadian dari Use Case ini. Langkah keempat inilah yang terberat karena kita diminta untuk membayangkan apa yang seharusnya terjadi, apa yang mungkin terjadi, dan apa yang tidak boleh terjadi untuk setiap Use Case. Untuk itu, dalam menyusun skenario ini perlu dilibatkan calon pengguna sistem yang memahami skenario-skenario yang mungkin terjadi. Contoh Deskripsi Use Case
- 4. Use Case ID: 1 Nama Use Case: Memesan Makanan Created By: Rachmat Gunawan Date Created: 01/01/2009 Aktor: Mahasiswa Deskripsi: Mahasiswa mengaksis Sistem Pemesanan Makanan dari intranet Politeknik Telkom, melihat menu untuk tanggal tertentu, memilih makanan, dan melakukan pemesanan untuk makanan untuk diantarkan ke alamat tertentu dalam rentang waktu 30 menit. Preconditions : 1. Mahasiswa Log In ke Sistem Pemesanan Makanan. 2. Mahasiswa terdaftar di sistem pemesanan makanan untuk pembayaran Postconditio ns: 1. Pesanan tersimpan di dalam sistem dengan status ‘Diterima’. 2. Data Keberadaan makanan dimutakhirkan sesuai dengan makanan yang dipesan. Normal Course/ Skenario Normal 1.0 Pesan Satu Jenis Makanan 1. Mahasiswa melihat menu untuk tanggal tertentu 2. Sistem menampilkan menu yang tersedia untuk tanggal tersebut dan penawaran khusus di hari itu. 3. Mahasiswa memilih satu atau lebih makanan dari menu. 4. Mahasiswa menyatakan bahwa pemesanan telah selesai dan lengkap. 5. Sistem menampilkan makanan yang dipesan, harga satuannya, dan harga keseluruhannya, termasuk pajak dan biaya pengantaran. 6. Mahasiswa menyetujui persetujuan tersebut, bila tidak setuju atau ingin merubah, kembali ke nomor 3. 7. Mahasiswa memilih cara pembayaran 8. Sistem menerima cara pembayaran tersebut. 9. Sistem mengirim email ke mahasiswa tersebut untuk konfirmasi menyangkuit detail pemesanan, harga, dan cara pembayaran. 10. Sistem menyimpan pemesanan tersebut dalam database, mengirim email ke staf kafetaria, mengirimkan informasi stok makanan ke sistem inventory kafetaria. Alternative Courses/ 1.1 Memesan banyak makanan (mencabang setelah langkah ke 4) 1. Mahasiswa ditanya untuk memesan makanan lain. 2. kembali ke langkah nomor 2.
- 5. Skenario Lain 1.2 Memesan banyak makanan sejenis (setelah langkah ke 3) 1. Mahasiswa diminta memasukkan jumlah makanan sejenis yang dipesan 2. kembali ke langkah 4. 1.3. Memesan pesanan khusus hari itu (setelah langkah ke 2) 1. Mahasiswa memesan makanan khusus hari itu. 2. Kembali ke langkah 5. Exceptions/ Pengecualian : 1.0.E.1 Sekarang sudah lewat waktu pemesanan (di langkah 1) 1. Sistem memberi tahu mahasiswa bahwa waktu pemesanan sudah habis untuk hari ini. 2a. Mahasiswa membatalkan pemesanan 2b. Sistem membatalkan Use Case. 3a. Mahasiswa meminta tanggal yang lain 3b. Sistem mengulangi Use Case. 1.2.E.1 Tidak dapat memenuhi pesanan banyak untuk makanan sejenis (langkah 1) 1. Sistem memberi tahu mahasiswa bahwa makanan sejenis yang dapat dipesan telah mencapai maksimum 2. Mahasiswa mengubah jumlah makanan sejenis yang dipesan atau membatalkan pemesanan makanan. Includes: None Priority: High Frequency of Use: Kira-kira 400 pelanggan, biasanya 1 kali pesan per hati Aturan yang harus dipenuhi:
- 6. Kebutuhan khusus: 1. Mahasiswa harus dapat membatalkan pemesanan makanan kapanpun sebelum mengkonfirmasi pemesanan. 2. Mahasiswa harus dapat melihat seluruh makanan yang dia pesan dalam 6 bulan ke belakang. (Prioritas = medium) Asumsi: 1. Asumsi bahwa 30% mahasiswa akan memesan makanan tiap hari. Catatan: