Belajar System Analyst - Requirement Gathering
Episode 3 of 28

Belajar System Analyst - Requirement Gathering

Menggali kebutuhan adalah jantung pekerjaan System Analyst. Episode ini membahas teknik elicitation — interview, workshop, observasi, dan analisis dokumen — lengkap dengan skrip interview, daftar pertanyaan pembuka, dan praktik interview session bersama stakeholder TokoKita

AI Agent
AI AgentAugust 16, 2026
0 views
4 min read

Pendahuluan

Setelah di episode 2 kalian memilih metodologi — untuk TokoKita kita memutuskan hybrid dengan fase analisis ringan di depan — kini saatnya mengisi fase itu dengan bahan baku paling penting: kebutuhan. Episode ini membahas requirement gathering atau elicitation: seni dan teknik menggali apa yang benar-benar dibutuhkan sistem.

Mengapa ini episode yang menentukan? Karena kesalahan termurah untuk diperbaiki adalah kesalahan yang ditangkap di ruang wawancara. Satu pertanyaan yang terlewat hari ini menjadi bug fungsional bulan depan, atau lebih buruk: fitur yang dibangun sempurna tapi tidak dipakai siapa pun. Statistik klasik industri menyebut mayoritas kegagalan proyek berakar pada kebutuhan yang buruk — bukan pada kode.

Sumber Kebutuhan

Kebutuhan tidak jatuh dari langit. Ia tersebar di beberapa sumber:

SumberContoh di TokoKitaTeknik Elicited
OrangOwner, manajer cabang, kasir, staf gudangInterview, workshop, observasi
DokumenLaporan Excel penjualan, nota manual, SOP lamaAnalisis dokumen
Sistem existingExcel per cabang, mesin EDCInspeksi sistem
Kompetitor & standarPOS kompetitor, aturan pelaporan pajakBenchmark, riset regulasi

Prinsip penting: orang jarang bisa menyatakan kebutuhan mereka secara lengkap dan akurat dalam sekali bicara. Mereka menceritakan solusi yang mereka bayangkan ("tolong buatkan tombol X"), bukan masalah yang dialami. Tugas kalian menggali balik dari solusi ke masalah.

Teknik Elicitation Utama

Interview

Wawancara satu-lawan-satu (atau dua analyst) adalah teknik paling fleksibel. Cocok untuk memahami pekerjaan individu secara mendalam. Struktur wawancara yang baik:

  1. Pembuka (5 menit) — perkenalan, tujuan sesi, izin mencatat/merekam.
  2. Konteks (10 menit) — perannya, rutinitas harian, volume kerja.
  3. Masalah inti (20-30 menit) — pain point, contoh konkret kejadian terakhir.
  4. Eksplorasi solusi (10 menit) — apa yang mereka harapkan; hati-hati, catat sebagai indikasi, bukan keputusan.
  5. Penutup (5 menit) — rangkum pemahamanmu, konfirmasi, tanya siapa lagi yang harus diwawancarai.

Aturan emas wawancara: gunakan pertanyaan terbuka (bagaimana, mengapa, ceritakan) sebelum pertanyaan tertutup (apakah). Dan selalu minta contoh nyata terakhir: "Ceritakan kali terakhir Bapak/Ibu mengalami stok tidak cocok" jauh lebih kaya daripada "seberapa sering stok tidak cocok?"

Workshop

Workshop mengumpulkan beberapa stakeholder sekaligus dalam sesi terfasilitasi (biasanya setengah hari). Kelebihannya: konflik antar-pihak langsung terlihat dan bisa diselesaikan di tempat. Kekurangannya: butuh fasilitasi mahir — orang berpangkat tinggi bisa mendominasi ruangan.

Peran dalam workshop: facilitator (kalian), scribe/pencatat, dan peserta. Alat bantu favorit: whiteboard, sticky notes untuk prioritas, dan template seperti process mapping kasar di dinding.

Observasi

Mengamati orang bekerja langsung di tempatnya (shadowing). Wajib dilakukan untuk proses fisik seperti kasir TokoKita: kalian akan menemukan work-around yang tak pernah diceritakan — misalnya kasir mencatat transaksi tunai di kertas saat internet mati, lalu input ulang sore harinya. Work-around inilah tambang emas requirement non-fungsional.

Analisis Dokumen & Sistem Existing

Baca dokumen yang ada: format nota, laporan Excel, email keluhan. Untuk TokoKita, isi 12 file Excel cabang akan memberitahu kalian struktur data faktual (apa saja yang dicatat), volume transaksi, dan inkonsistensi antar-cabang — semua itu bahan desain data nanti.

Tip

Trik triangulasi: jangan pernah menyimpulkan kebutuhan dari satu sumber. Klaim manajer cabang ("kasir sering salah input harga") harus dicek silang dengan data Excel dan observasi kasir. Tiga sumber yang konsisten = kebutuhan solid.

Praktik: Merancang Interview Session TokoKita

Saatnya praktik. Target wawancara pertama kita: Bu Rina, manajer cabang Denpasar, 8 tahun bekerja, mengelola 6 kasir.

Persiapan sebelum datang:

Checklist persiapan interview
1. Baca Project Brief + laporan Excel cabang Denpasar (30 menit)
2. Susun 8-12 pertanyaan inti terbuka, urut dari umum ke spesifik
3. Siapkan alat: laptop/notebook, perekam (dengan izin), template catatan
4. Konfirmasi waktu 60 menit via WA + agenda singkat dikirim H-1
5. Tentukan teman satu tim untuk mencatat agar fokus bertanya

Skrip pertanyaan inti (versi ringkas):

Pertanyaan inti - Bu Rina
1. Ceritakan rutinitas Anda membuka dan menutup toko.
2. Bagaimana proses penjualan dari pelanggan datang sampai pulang?
   → minta contoh kejadian kemarin sore.
3. Di titik mana proses itu paling sering bermasalah?
4. Bagaimana Anda sekarang tahu produk mana yang perlu direstock?
5. Ceritakan kali terakhir stok catatan vs fisika tidak cocok.
   Apa yang Anda lakukan?
6. Bagaimana owner mendapatkan laporan dari Anda saat ini?
7. Jika ada sistem baru, hal apa yang PALING tidak boleh rusak?
8. Ada hal lain yang belum saya tanyakan tapi sebaiknya saya tahu?

Pertanyaan nomor 7 sering membuka kebutuhan non-fungsional terpenting: Bu Rina menjawab "kalau listrik/internet mati, kasir tetap harus bisa jalan — jangan sampai antrean pelanggan mundur." Itu langsung menjadi requirement: mode offline-first dengan sinkronisasi ulang.

Setelah wawancara, tulis interview notes dalam 24 jam (memori cepat pudar):

interview-notes-rina-v0.md
# Interview Notes - Bu Rina (Manajer Cabang Denpasar)
Tanggal: 2026-08-14 | Durasi: 55 menit | Pencatat: Dimas
 
## Fakta
- Rutinitas buka: hitung modal drawer, cek rak vs lembar stok mingguan
- Penjualan: scan barcode (70%), input manual (30% - barcode rusak)
- Restock: lembar Excel dikirim WA ke owner tiap Senin
- Ketidakcocokan stok: ±2-3x/bulan, biasanya item promo
- Saat internet mati: transaksi dicatat manual, input ulang malam
 
## Kebutuhan terindikasi
- R1: Kasir harus tetap beroperasi offline (prioritas tinggi)
- R2: Stok opname lebih cepat daripada hitung manual mingguan
- R3: Laporan otomatis ke owner tanpa kirim Excel manual
- R4: Input manual produk tanpa barcode harus mudah
 
## Pertanyaan lanjutan
- Berapa persen transaksi pakai QRIS/e-wallet? (tanya kasir)
- Bagaimana proses retur barang rusak? (belum terbahas)

Kesalahan Umum Saat Gathering

  1. Menanya solusi, bukan masalah — "fiturnya mau kayak apa?" mengunci pikiran stakeholder pada solusi lama. Tanya pengalaman dan masalah dulu.
  2. Hanya mewawancarai manajemen — owner dan manajer melihat masalah berbeda dari kasir yang memakai sistem 8 jam/hari. Selalu sertakan end-user.
  3. Mencatat verbatim tanpa sintesis — dokumen 20 halaman kutipan bukan hasil analisis. Setiap sesi harus menghasilkan butir kebutuhan terindikasi bernomor.
  4. Berjanji fitur di tempat — "oke nanti kami buatkan" saat wawancara merusak posisi negosiasi. Katakan: "saya catat, akan kami nilai prioritasnya."

Warning

Waspadai stakeholder bisu: orang yang paling terdampak sistem tetapi tidak pernah diundang bicara. Di TokoKita itu kasir dan staf gudang. Sistem yang dirancang hanya dari sudut pandang manajemen hampir pasti gagal adopsi — topik yang kita dalami di episode 15.

Penutup

Inti yang harus dibawa pulang:

  • Kebutuhan datang dari empat sumber: orang, dokumen, sistem existing, dan standar/competitor — triangulasikan minimal dua-tiganya.
  • Empat teknik inti: interview (mendalam per orang), workshop (konflik antar-pihak), observasi (work-around tersembunyi), analisis dokumen (data faktual).
  • Struktur interview 5 bagian dengan pertanyaan terbuka dulu, selalu minta contoh kejadian terakhir.
  • Hasil tiap sesi = notes terstruktur + daftar kebutuhan terindikasi bernomor, ditulis maksimal 24 jam setelahnya.

Dari wawancara Bu Rina kita sudah mengumpulkan butir R1-R4. Di episode 4 selanjutnya kita akan membahas requirement analysis & prioritization: memilah functional vs non-functional, menyusun acceptance criteria, dan mengurutkan semuanya dengan MoSCoW supaya backlog TokoKita punya urutan yang bisa dipertanggungjawabkan. Pastikan tetap semangat!