Belajar System Analyst - Requirement Analysis & Prioritization

#Pendahuluan

Setelah di episode 3 kalian menggali kebutuhan lewat interview, workshop, dan observasi — dan sudah punya daftar butir R1-R4 dari Bu Rina — sekarang saatnya mengolah bahan mentah itu. Episode ini membahas requirement analysis: memilah, merumuskan, menguji kualitas, dan memprioritaskan kebutuhan.

Mengapa tahap ini tidak boleh dilompati? Karena gathering tanpa analysis menghasilkan daftar keluhan, bukan spesifikasi. Developer tidak bisa membangun dari "kasir harus tetap bisa jalan pas internet mati" tanpa tahu persis apa artinya: berapa lama offline? data kemana? bagaimana sinkron ulang? Analysis adalah proses mengubah kata-kata stakeholder menjadi pernyataan yang jelas, terukur, dan dapat diverifikasi.

#Functional vs Non-Functional

Dua kategori besar yang wajib kalian pisahkan sejak awal:

NFR adalah pihak yang paling sering dikorbankan karena tak terlihat di demo — dan paling sering membuat proyek gagal secara diam-diam. Kategori NFR standar yang layak kalian hafal: performance, availability/reliability, security, usability, scalability, compatibility/portability, maintainability, compliance.

#Anatomi Requirement yang Baik

Pernyataan kebutuhan yang baik punya empat sifat (sering disingkat agar clear, unambiguous, testable, traceable):

MENTAH (dari wawancara):
"Kasir harus tetap bisa jalan pas internet mati."
 
TERANALISIS:
FR-07: Saat koneksi internet tidak tersedia, aplikasi kasir
       harus tetap dapat mencatat transaksi tunai dan QRIS
       (mode offline), termasuk cetak struk dan pembaruan stok
       pada basis data lokal.
NFR-03: Data transaksi offline harus tersinkronisasi otomatis ke
        server pusat dalam waktu maksimal 60 detik setelah
        koneksi pulih, tanpa duplikasi transaksi.

Perhatikan tiga hal: bernomor (traceable), spesifik perilaku (testable), dan tidak menyebut solusi implementasi tertentu (biar tim dev yang memilih cara). Format kalimat yang lazim untuk FR:

[Aktor] harus dapat [aksi] [objek] [syarat/kendala].

Contoh: "Kasir harus dapat menerapkan diskon promo dengan batas persentase yang ditetapkan manajer cabang."

#Acceptance Criteria

Acceptance criteria (AC) mendefinisikan kapan sebuah requirement dinyatakan selesai. Format populer adalah Gherkin (Given-When-Then):

Feature: Transaksi kasir mode offline
 
Scenario: Penjualan tunai saat internet mati
  Given internet cabang sedang mati
  And kasir sudah login sebelum koneksi putus
  When kasir menyelesaikan penjualan tunai Rp 45.000
  Then struk berhasil dicetak
  And transaksi tersimpan di database lokal
  And stok produk terpotong di database lokal

AC yang baik bersifat biner: lulus atau tidak — tidak ada "agak selesai". Satu user story biasanya punya 3-7 AC.

#Prioritization dengan MoSCoW

Tidak semua kebutuhan sama pentingnya, dan resource pasti terbatas. MoSCoW membagi kebutuhan ke empat ember:

Aturan mainnya ketat: Must tidak boleh melebihi ±60% kapasitas — kalau semuanya Must, artinya belum diprioritaskan. Dan "Won't have" bukan pembuangan; ia dokumen eksplisit supaya stakeholder tidak mengira fiturnya lupa.

#Praktik: Memrioritaskan Backlog TokoKita

Ambil kebutuhan hasil episode 3 plus temuan lanjutan, lalu urutkan untuk rilis pilot satu cabang:

Teknik pendukung lain yang patut kalian kenal:

• Value vs Effort matrix — plot nilai bisnis terhadap effort; kerjakan kuadran high-value low-effort dulu. Bagus untuk sesi workshop bersama stakeholder.
• Kano model — klasifikasi fitur jadi basic needs, performance, dan delighter; berguna saat mendesain pengalaman, bukan hanya urutan kerja.
• Weighted scoring — beri bobot kriteria (nilai, risiko, dependensi) lalu skor tiap item; objektif tapi butuh kesepakatan bobot.

#Kesalahan Umum

1. Semua stakeholder bilang Must — MoSCoW hanya bekerja jika ada otoritas yang berani memangkas. Perankan owner sebagai final arbiter.
2. NFR tidak diberi nomor — NFR yang tidak masuk daftar bernomor akan hilang di testing dan baru ketahuan di produksi.
3. Requirement campur solusi — "pakai fingerprint untuk login" adalah solusi; kebutuhannya "otentikasi kasir per shift yang tidak bisa dipinjam antar-karyawan". Simpan kebutuhan murni, lampirkan usulan solusi terpisah.
4. Prioritas sekali tulis — backlog hidup. Re-prioritaskan tiap akhir sprint berdasarkan pelajaran baru.

#Penutup

Inti yang harus dibawa pulang:

• Pisahkan functional (apa sistem lakukan) dari non-functional (seberapa baik) — NFR harus diubah jadi angka terukur, bukan kata sifat.
• Requirement baik bernomor, spesifik perilaku, testable, dan bebas detail implementasi; acceptance criteria Given-When-Then membuat "selesai" jadi biner.
• MoSCoW mengurutkan nilai: jaga proporsi Must maksimal ±60%, dan catat Won't-have secara eksplisit.
• Backlog TokoKita pilot: scan+struk+offline+stok real-time sebagai Must; member & integrasi supplier ditunda sadar.

Di episode 5 selanjutnya kita membahas use cases & user stories: dua format populer menuliskan kebutuhan dari sudut pandang pengguna, kapan pakai yang mana, dan praktik menulis user stories untuk fitur kasir TokoKita sampai siap dimasukkan sprint. Pastikan tetap semangat!