Belajar System Analyst - Use Cases & User Stories

#Pendahuluan

Setelah di episode 4 kalian bisa memilah functional vs non-functional requirement dan mengurutkannya dengan MoSCoW, sekarang kita butuh format penulisan yang membuat kebutuhan itu mudah dikonsumsi tim. Dua format paling populer: use case (warisan dunia UML/RUP) dan user story (anak emas Agile).

Mengapa format penting? Karena kalimat requirement yang sama dibaca berbeda oleh tiap orang. Use case memaksa kalian memikirkan alur lengkap termasuk kegagalan; user story memaksa kalian menjawab "untuk siapa dan kenapa". Analyst yang kuat menulis keduanya dan tahu kapan masing-masing lebih tepat.

#Anatomi Use Case

Use case mendeskripsikan interaksi satu tujuan antara aktor dan sistem sampai hasil yang bernilai tercapai. Komponennya:

Contoh lengkap dalam format tabel:

ID              : UC-01
Nama            : Proses Penjualan Tunai
Aktor primer    : Kasir
Aktor sekunder  : Modul Inventori
Precondition    : Kasir sudah login shift aktif
Trigger         : Pelanggan selesai memilih barang di kasir
 
MAIN FLOW
1. Kasir memulai transaksi baru
2. Sistem membuka keranjang kosong
3. Kasir memindai barcode produk
4. Sistem menampilkan nama, harga satuan,
   dan menambahkan item ke keranjang
   [ulangi langkah 3-4 untuk tiap produk]
5. Kasir menekan tombol Bayar
6. Sistem menampilkan total belanja
7. Kasir memasukkan nominal uang diterima
8. Sistem menghitung kembalian
9. Kasir konfirmasi pembayaran tunai diterima
10. Sistem menyimpan transaksi, memotong stok,
    dan mencetak struk
11. Kasir menyerahkan struk & kembalian
 
ALTERNATIVE FLOW
A1 (di langkah 3): barcode tidak terbaca →
    kasir input kode manual → lanjut langkah 4
A2 (di langkah 7): uang pas → sistem langsung
    lanjut tanpa hitung kembalian
 
EXCEPTION FLOW
E1 (di langkah 7): nominal kurang dari total →
    sistem menolak, kasir minta tambahan atau batal item
E2 (di langkah 10): printer struk mati → transaksi
    tetap tersimpan, struk masuk antrian cetak ulang
 
POSTCONDITION
Transaksi tercatat permanen; stok produk terpotong;
laporan harian bertambah.

Perhatikan nilai terbesar use case: exception flow. Di sinilah requirement tersembunyi keluar — hal-hal yang stakeholder lupa sebut karena terjadi jarang tapi fatal.

#Use Case Diagram

Diagram use case memberi peta tingkat tinggi: siapa bisa melakukan apa. Bentuknya sederhana — aktor di luar garis batas sistem, oval-oval use case di dalamnya, garis asosiasi di antaranya:

Gunakan diagram ini untuk diskusi cakupan dengan stakeholder non-teknis, bukan sebagai spesifikasi detail — detailnya ada di tabel skenario.

#User Story

User story adalah format ringkas satu-dua kalimat dari sudut pandang pengguna:

Sebagai <peran>, saya ingin <kemampuan>, sehingga <nilai/manfaat>.
As a <role>, I want <capability>, so that <benefit>.

Contoh untuk fitur kasir TokoKita:

**US-12**
Sebagai kasir, saya ingin transaksi tetap bisa dicatat saat
internet mati, sehingga antrean pelanggan tidak mundur.
 
Acceptance Criteria:
- Given internet mati, when saya menyelesaikan penjualan tunai,
  then struk tercetak dan data tersimpan lokal
- Given koneksi pulih, then data tersinkron otomatis maksimal 60 detik
- Given ada transaksi ganda saat sinkron, then sistem mendeteksi
  dan tidak menduplikasi catatan
Estimasi: 8 poin | Prioritas: Must | Epic: POS Inti

Tiga bagian story punya fungsi berbeda: sebagai mengunci siapa pengguna sesungguhnya, saya ingin mendefinisikan kemampuan, sehingga menjelaskan nilai — bagian ketiga inilah yang sering dilupakan padahal ia alasan fitur layak dibangun.

Praktik penulisan yang baik disebut INVEST:

Story besar (epic) harus dipatahkan. Epic "Kelola Inventori" pecah menjadi: input produk, terima barang, stock opname, penyesuaian stok — masing-masing jadi story mandiri.

#Kapan Pakai yang Mana?

Keduanya hidup berdampingan di banyak proyek nyata:

Di TokoKita kita pakai kombinasi: user story untuk backlog sprint, use case untuk lima alur inti yang kompleks (penjualan, retur, stock opname, shift, sinkronisasi offline).

#Kesalahan Umum

1. Menulis solusi di dalam story — "saya ingin dropdown dengan warna biru" adalah desain UI, bukan kebutuhan. Kembali ke kemampuan & manfaat.
2. Aktor = jabatan organisasi — aktor adalah peran berhadapan dengan sistem. Satu orang bisa dua aktor; dua manajer satu aktor.
3. Lupa exception flow — use case tanpa kegagalan seperti rencana tanpa rem. Minimal pikirkan: apa jika input salah? jaringan putus? data tidak ada?
4. Story monster — "sebagai owner saya ingin sistem inventori lengkap" bukan story, itu proyek. Pecah sampai muat satu sprint.
5. AC ambigu — "sistem cepat merespons" tak bisa dites. Ganti: "respons di bawah 2 detik untuk 95 persen permintaan".

#Penutup

Inti yang harus dibawa pulang:

• Use case mendeskripsikan satu tujuan interaksi secara lengkap: preconditions, main/alternative/exception flow, postconditions — kekuatannya menangkap kegagalan.
• User story ringkas dengan pola peran-kemampuan-nilai, dilengkapi acceptance criteria, dan harus lolos uji INVEST.
• Diagram use case untuk peta cakupan; tabel skenario untuk spesifikasi.
• Pakai keduanya sesuai konteks: story untuk backlog sprint, use case untuk alur kompleks & konteks formal.

Dengan story dan AC siap, sekarang kita butuh cara mengomunikasikan perilaku sistem secara visual ke developer. Di episode 6 selanjutnya kita membahas UML & diagram: activity, sequence, dan class diagram — termasuk praktik membuatnya di draw.io untuk alur penjualan TokoKita. Pastikan tetap semangat!