Bagaimana Anda mengumpulkan dan mengklarifikasi persyaratan?

Question

Accepted Answer

**Pengumpulan persyaratan** adalah proses untuk mengetahui apa yang benar-benar perlu dibangun — dan *mengapa* — sebelum membangunnya. Kesalahan terbesar yang dilakukan junior adalah mengambil permintaan secara harfiah tanpa memahami masalah yang mendasarinya.

## Cara mendekatinya

```text
1. ASK WHY → understand the problem behind the request, not just the request
2. TALK to the real users / stakeholders, not just the requester
3. CLARIFY scope → what's in, what's out, what "done" looks like
4. SURFACE assumptions and constraints (deadlines, budget, tech limits)
5. WRITE IT DOWN → confirm your understanding back to them
```

## Bedakan permintaan dari kebutuhan

Pemangku kepentingan mengatakan "tambahkan tombol ekspor ke PDF." Kebutuhan sebenarnya mungkin "Saya perlu berbagi laporan dengan atasan saya." Email, tautan bersama, atau dasbor bisa menyelesaikannya dengan lebih baik. Bertanya *mengapa* membuka solusi yang lebih baik.

## Pertanyaan klarifikasi yang baik

```text
✓ "What problem does this solve for the user?"
✓ "What happens today without it?"
✓ "How will we know it worked?"
✓ "What's explicitly out of scope?"
✓ "What are the edge cases / what could go wrong?"
```

## Kesalahan umum

Mengasumsikan Anda mengerti dan mulai membangun. Selalu cerminkan kembali persyaratan — "jadi yang Anda butuhkan adalah X, pada Y, dan Z di luar jangkauan?" — untuk menangkap celah sejak dini.

## Mengapa ini penting

Kesalahan persyaratan yang tetap pada tahap ide memakan waktu beberapa menit; kesalahan yang sama ditemukan setelah rilis memakan waktu berhari-hari atau berminggu-minggu untuk perbaikan.

Persyaratan yang jelas adalah asuransi paling murah terhadap pembangunan hal yang salah.

Bertanya *mengapa* mengubah Anda dari penerima pesanan menjadi pemecah masalah.