Ini adalah panduan membuat use case.

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: