Mei 28, 2026 · 6 min read
Series: Memahami SDLC — Post 1 dari 10
Pernah gak sih kamu selesai bikin fitur, terus pas demo ke bos, dia bilang: “Lho, kok bukan ini yang saya minta?”
Atau lebih parah: kamu udah coding berbulan-bulan, eh taunya fitur yang kamu bangun gak dipakai karena gak nyelesain masalah bisnis yang sebenarnya.
Ini bukan masalah kamu coding salah. Ini masalah komunikasi.
Dan dokumen yang benerin komunikasi ini namanya BRD: Business Requirements Document.
BRD Itu Apa Sih?
Simpelnya: BRD adalah dokumen yang nerjemahin masalah bisnis jadi bahasa yang dimengerti semua orang — dari bos, marketing, sampe developer.
BRD bukan dokumen teknis. Gak ada bahasan soal database, API, atau framework. BRD cuma jawab 3 pertanyaan:
- Masalah apa yang mau diselesain? (bukan “fitur apa yang mau dibangun”)
- Kenapa masalah ini penting? (ROI, KPI, duit yang hilang)
- Gimana kita tau kalau sudah sukses? (metric yang terukur)
Kalau PRD, SRS, dan dokumen lain itu untuk tim produk dan developer, BRD itu untuk stakeholder non-teknis. Bos, investor, kepala departemen — mereka baca ini.
Kapan BRD Dibuat?
BRD selalu dokumen pertama di SDLC. Sebelum ada desain, sebelum ada kode, bahkan sebelum ada PRD.
Flow-nya gini:
Ide/Masalah Bisnis ↓ BRD (disetujui stakeholder) ↓ PRD (tim produk mulai kerja) ↓ SRS (developer mulai coding) Kalau kamu langsung loncat ke coding tanpa BRD yang approved, kamu basically building on sand. Kapan aja bisa roboh.
Struktur BRD yang Baik
BRD gak perlu panjang. 3-5 halaman udah cukup. Yang penting jelas. Ini struktur minimal:
1. Executive Summary (1 paragraf)
Jelasin masalah dan solusi dalam 1 paragraf yang bisa dimengerti orang awam.
Contoh:
“Tim sales saat ini menghabiskan 4 jam per minggu untuk rekap manual data dari WhatsApp, email, dan spreadsheet ke CRM. Ini menyebabkan 15% lead hilang karena follow-up telat. Solusi: automasi input lead dari semua channel ke CRM dalam 1 menit.”
2. Business Problem (Apa yang Sakit?)
Jelasin masalahnya dengan angka. Bukan “sales ribet”, tapi:
| Metric | Saat Ini | Target |
|---|---|---|
| Waktu rekap manual | 4 jam/minggu | 0 menit |
| Lead hilang karena telat | 15% | <2% |
| Response time ke customer | 6 jam | <30 menit |
3. Business Objectives (Mau Ngapain)
Tujuan bisnis yang terukur. Pakai format SMART:
- Specific: Automasi input lead dari WhatsApp, email, web form ke CRM
- Measurable: Kurangi waktu rekap dari 4 jam jadi 0 menit
- Achievable: Teknologi sudah ada (Zapier, Make, API)
- Relevant: Langsung impact revenue (lead gak hilang)
- Time-bound: Go-live dalam 6 minggu
4. Scope (Apa yang Masuk, Apa yang Enggak)
Ini penting banget buat mencegah scope creep.
In Scope:
- Integrasi WhatsApp Business API → CRM
- Integrasi Gmail → CRM
- Web form → CRM
- Dashboard monitoring lead masuk
Out of Scope:
- Automasi follow-up email (ini Phase 2)
- Chatbot untuk qualify lead (ini Phase 3)
- Mobile app untuk sales (ini tahun depan)
5. Success Metrics (Gimana Tau Kalau Berhasil)
KPI yang jelas:
- 100% lead dari semua channel masuk CRM dalam <1 menit
- Waktu rekap manual = 0 menit/minggu
- Lead hilang karena telat <2%
- ROI: 3x dalam 6 bulan (biaya develop vs revenue yang diselamatkan)
6. Stakeholders (Siapa yang Terlibat)
| Role | Nama | Tanggung Jawab |
|---|---|---|
| Sponsor | Head of Sales | Approve budget, prioritas |
| Product Owner | [Nama] | Terjemah BRD ke PRD |
| Tech Lead | [Nama] | Estimasi effort, feasibility |
| End Users | Tim Sales (5 orang) | UAT, feedback |
7. Timeline & Budget (Kapan & Berapa)
- Timeline: 6 minggu (2 minggu desain, 3 minggu develop, 1 minggu UAT)
- Budget: Rp 75 juta (developer cost + tools subscription)
- Go-live: 15 Juli 2026
Kesalahan Umum yang Sering Terjadi
❌ BRD Kebanyakan Teknis
Salah:
“Sistem akan menggunakan PostgreSQL dengan indexing pada kolom lead_id untuk query yang lebih cepat.”
Bener:
“Sales bisa cari lead dalam <2 detik, bahkan dengan 10.000+ data.”
Yang pertama itu SRS. Yang kedua itu BRD.
❌ Metric Gak Terukur
Salah: “Meningkatkan kepuasan customer”
Bener: “Response time turun dari 6 jam jadi 30 menit”
“Gimana tau udah puas?” — metric harus jawab ini.
❌ Scope Creep
Bos bilang: “Wah, sekalian bikin chatbot aja biar lebih keren!”
Kamu: “Pak, itu di out of scope. Bisa kita masukin Phase 2 kalau Phase 1 udah sukses.”
BRD yang approved adalah kontrak. Kalau mau nambah, buat BRD baru atau change request.
❌ Gak Ada Approval
BRD tanpa tanda tangan stakeholder = saran, bukan requirement.
Pastikan ada section Approval di akhir dokumen:
Disetujui oleh: Head of Sales: _________________ Tanggal: _______ CTO: _________________________ Tanggal: _______ Project Sponsor: ______________ Tanggal: _______ Template BRD Siap Pakai
Saya bikinin template sederhana yang bisa langsung kamu pakai:
# Business Requirements Document (BRD) ## Project Name [Nama Project] ## Executive Summary [1 paragraf: masalah + solusi + impact] ## Business Problem [Masalah saat ini dengan angka/metric] ## Business Objectives - [Objective 1 - SMART] - [Objective 2 - SMART] - [Objective 3 - SMART] ## Scope ### In Scope - [Fitur 1] - [Fitur 2] ### Out of Scope - [Yang gak termasuk] ## Success Metrics | Metric | Current | Target | |--------|---------|--------| | [Metric 1] | [X] | [Y] | ## Stakeholders | Role | Name | Responsibility | |------|------|----------------| | [Role] | [Name] | [Responsibility] | ## Timeline & Budget - Timeline: [X] minggu - Budget: [Rp X] - Go-live: [Tanggal] ## Approval [Signature section] BRD vs PRD vs SRS — Jangan Ketuker!
| Dokumen | Untuk Siapa | Fokus | Contoh Isi |
|---|---|---|---|
| BRD | Stakeholder, Bos | Masalah bisnis, ROI | “Lead hilang 15%, perlu automasi” |
| PRD | PM, Designer, Dev | Fitur, user journey | “User klik tombol, sistem simpan ke DB” |
| SRS | Developer, QA | Spesifikasi teknis | “API POST /leads, response 200 OK” |
BRD = WHY (kenapa kita bangun ini)
PRD = WHAT (apa yang akan dibangun)
SRS = HOW (gimana cara build-nya)
Kapan BRD Gak Perlu?
Ada situasi dimana BRD overkill:
- Bug fix kecil: Gak perlu BRD, langsung tiket
- Feature tweak minor: PRD aja cukup
- Startup early stage: 1 halaman problem-solution udah cukup
Tapi kalau ada budget >Rp 50 juta, timeline >2 minggu, atau impact ke revenue — wajib BRD.
Penutup
BRD itu asuransi project. Dokumentasi 3-5 halaman yang bisa nyelamatin kamu dari:
- Scope creep yang gak kelar-kelar
- Bos yang tiba-tiba ganti requirement
- Feature yang dibangun tapi gak dipakai
- Debat “kok bukan ini yang saya minta”
Next post: PRD (Product Requirements Document) — gimana nerjemahin BRD jadi fitur yang bisa di-design dan di-code.
Series: “Memahami SDLC” — Part 1 dari 10. Follow di teknologinow.com
Discover more from teknologi now
Subscribe to get the latest posts sent to your email.