Business Requirements Document
Template & Panduan Penulisan
Untuk Project Manager, Business Analyst, Technical Writer, Quality Assurance, Programmer, dan Anggota Tim Lainnya
Versi 2.0 | 2026
Panduan Penggunaan Template
Template ini dirancang untuk membantu seluruh anggota tim proyek dalam membuat, membaca, dan memahami Business Requirements Document (BRD) dengan konsisten dan komprehensif.
Tujuan Dokumen Ini
- Mendokumentasikan kebutuhan bisnis secara lengkap sebelum pengembangan sistem dimulai
- Memastikan semua kebutuhan bisnis, proses, aturan, dan tujuan organisasi tercakup
- Menjadi dasar yang kuat untuk penyusunan PRD, FSD, dan dokumen teknis lainnya
- Memfasilitasi persetujuan formal dari seluruh stakeholders sebelum proyek berjalan
- Menjadi acuan tunggal (single source of truth) untuk seluruh keputusan bisnis proyek
Perbedaan BRD dan PRD
| Aspek | BRD | PRD |
|---|---|---|
| Fokus | Kebutuhan bisnis dan tujuan organisasi | Kebutuhan produk dan spesifikasi fungsional |
| Audiens | Manajemen, stakeholder bisnis, sponsor | Tim pengembang, QA, UI/UX |
| Tingkat detail | Bisnis, proses, ROI, regulasi | Fitur, modul, acceptance criteria |
| Pertanyaan | "Apa yang dibutuhkan bisnis?" | "Apa yang harus dibangun produk?" |
| Waktu penyusunan | Sebelum PRD | Setelah BRD disetujui |
Cara Menggunakan Template
- Baca seluruh template untuk memahami struktur dan ruang lingkup BRD
- Isi setiap bagian sesuai dengan panduan yang diberikan
- Bagian bertanda [OPSIONAL] boleh dihapus jika tidak relevan; bagian tanpa tanda tersebut wajib diisi
- Gunakan tanda
[ISI DI SINI]sebagai penanda bagian yang perlu diisi - Perbarui versi dokumen setiap kali ada perubahan signifikan
- Dapatkan tanda tangan persetujuan dari seluruh pihak berwenang sebelum dokumen dianggap final
Tingkat Kompleksitas BRD
Tidak semua proyek memerlukan BRD dengan tingkat detail yang sama. Gunakan panduan berikut:
| Tingkat | Karakteristik Proyek | Bagian yang Disarankan |
|---|---|---|
| Ringkas | Proyek kecil, scope terbatas, 1-2 modul, timeline pendek | Bagian 1-5, 11, 15, 16 |
| Standar | Proyek menengah, beberapa modul, melibatkan integrasi | Semua bagian wajib + bagian opsional yang relevan |
| Komprehensif | Proyek besar, enterprise, multi-stakeholder, regulasi ketat | Semua bagian termasuk seluruh bagian opsional |
Panduan Peran Tim
| Peran | Fokus Area | Kontribusi Utama |
|---|---|---|
| Project Manager | Keseluruhan dokumen, timeline, stakeholder, governance | Mengkoordinasi pembuatan BRD, memfasilitasi workshop, mengelola persetujuan |
| Business Analyst | Kebutuhan bisnis, proses AS-IS/TO-BE, aturan bisnis, data | Menggali dan mendokumentasikan kebutuhan dari stakeholder bisnis |
| Technical Writer | Struktur dokumen, kejelasan bahasa, konsistensi | Menyusun dan mengedit dokumen agar jelas, konsisten, dan mudah dibaca |
| Quality Assurance | Kriteria penerimaan, skenario pengujian, traceability | Memastikan kebutuhan bisnis dapat diuji dan memiliki acceptance criteria yang jelas |
| Programmer / Developer | Kebutuhan teknis, feasibility, constraint sistem | Memberikan masukan feasibility teknis dan implikasi implementasi |
Notasi dan Format yang Digunakan
- TIPS: Kotak tips berisi panduan, tips, atau penjelasan tambahan untuk membantu pengisian bagian tersebut.
- CONTOH: Teks dengan format
[ISI DI SINI]menunjukkan bagian yang harus diisi oleh tim proyek sesuai konteks proyek masing-masing. - [OPSIONAL]: Bagian yang boleh dihapus jika tidak relevan dengan proyek.
- Tag peran menunjukkan bagian yang paling relevan untuk peran tertentu:
PMProject ManagerBABusiness AnalystDEVDeveloper / ProgrammerQAQuality AssuranceTWTechnical Writer
Dokumen Masukan yang Direkomendasikan
PM Project Manager bertanggung jawab mengumpulkan dokumen masukan berikut sebelum penyusunan BRD dimulai. Semakin lengkap dokumen masukan, semakin akurat dan komprehensif BRD yang dihasilkan.
| No | Dokumen Masukan | Deskripsi | Wajib / Opsional |
|---|---|---|---|
| 1 | Notulensi rapat / hasil wawancara stakeholder | Catatan kebutuhan bisnis dari sesi penggalian kebutuhan (requirement gathering) | Wajib |
| 2 | Proposal proyek / Term of Reference (ToR) | Dokumen inisiasi yang menjelaskan latar belakang dan lingkup proyek | Wajib |
| 3 | SOP / proses bisnis saat ini (AS-IS) | Dokumen prosedur operasional atau alur kerja yang sedang berjalan | Wajib (jika ada sistem existing) |
| 4 | Kontrak / MoU / Perjanjian Kerja Sama | Dokumen legal yang mengatur batasan dan kewajiban proyek | Wajib |
| 5 | Struktur organisasi klien | Bagan organisasi yang relevan dengan proyek (stakeholder, pengguna, approver) | Wajib |
| 6 | Dokumen regulasi / kebijakan terkait | Peraturan pemerintah, standar industri, atau kebijakan internal yang harus dipatuhi | Wajib (jika ada regulasi) |
| 7 | Dokumentasi sistem existing | Screenshot, user manual, API docs, atau ERD dari sistem yang akan digantikan/diintegrasikan | Opsional |
| 8 | Laporan / dashboard yang digunakan saat ini | Contoh output yang diharapkan dari sistem baru | Opsional |
| 9 | Rencana strategis organisasi | Dokumen visi-misi dan rencana jangka menengah/panjang organisasi | Opsional |
| 10 | Data volume dan performa | Jumlah transaksi, jumlah pengguna, SLA existing | Opsional |
| 11 | Hasil audit / temuan sebelumnya | Temuan dari audit internal/eksternal yang relevan dengan kebutuhan sistem | Opsional |
TIPS: Untuk proyek tingkat Ringkas, minimal kumpulkan dokumen no. 1-4. Untuk tingkat Standar dan Komprehensif, usahakan mengumpulkan seluruh dokumen wajib dan sebanyak mungkin dokumen opsional.
1. Document Control
Bagian ini mencakup informasi administratif dan metadata dokumen untuk pengelolaan versi, pelacakan perubahan, dan proses persetujuan formal.
1.1 Document Identification and Metadata
PM Project Manager bertanggung jawab atas kelengkapan metadata dokumen.
| Field | Value |
|---|---|
| Document Title | [ISI DI SINI - Judul lengkap BRD] |
| Project Name | [ISI DI SINI - Nama proyek] |
| Project Code / ID | [ISI DI SINI - Kode atau ID proyek] |
| Client | [ISI DI SINI - Klien / pemilik proyek] |
| Consultant | PT. Tristar Surya Gemilang (TSG) |
| Document Version | [ISI DI SINI - Contoh: 1.0, 1.1, 2.0] |
| Document Date | [ISI DI SINI - Tanggal penulisan: dd/mm/yyyy] |
| Confidentiality Level | [ISI DI SINI - Internal / Confidential / Restricted] |
TIPS: Untuk proyek yang memerlukan kerahasiaan tinggi, tambahkan pernyataan kerahasiaan (confidentiality statement) di halaman awal dokumen.
CONTOH CONFIDENTIALITY STATEMENT: Dokumen Business Requirement Document (BRD) ini merupakan dokumen rahasia milik [Nama Klien]. Seluruh informasi yang terdapat di dalamnya hanya boleh digunakan untuk keperluan pengembangan sistem [Nama Sistem]. Penyebarluasan sebagian atau seluruh isi dokumen tanpa persetujuan tertulis dari [Nama Klien] dilarang.
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): Dokumen Business Requirement Document (BRD) ini merupakan dokumen rahasia milik Bank bjb. Seluruh informasi yang terdapat di dalamnya hanya boleh digunakan untuk keperluan pengembangan sistem New bjb GIFT. Penyebarluasan sebagian atau seluruh isi dokumen tanpa persetujuan tertulis dari Bank bjb dilarang.
1.2 Revision Log
PM Project Manager mengelola versi dan perubahan dokumen.
| Version | Date | Author | Description | Status |
|---|---|---|---|---|
[X.X] | [DD/MM/YYYY] | [Nama] | [Deskripsi perubahan] | [Draft/Approved] |
| 0.1 | [DD/MM/YYYY] | [Nama] | Initial BRD draft | Draft |
| 1.0 | [DD/MM/YYYY] | [Nama] | Approved final version | Approved |
1.3 Document Reviewers
PM Project Manager mendefinisikan reviewer dokumen.
| Role | Name | Company / Division |
|---|---|---|
| Author | [ISI DI SINI] | [ISI DI SINI] |
| Reviewer | [ISI DI SINI] | [ISI DI SINI] |
| Reviewer | [ISI DI SINI] | [ISI DI SINI] |
| Approver | [ISI DI SINI] | [ISI DI SINI] |
1.4 Document Acceptance
PM Project Manager mendefinisikan pihak yang menyetujui dokumen.
| Name / Designation | Signature | Date |
|---|---|---|
[ISI DI SINI] | _______________ | [DD/MM/YYYY] |
[ISI DI SINI] | _______________ | [DD/MM/YYYY] |
1.5 Reference Documents [OPSIONAL]
BA Business Analyst mengidentifikasi dan mengumpulkan dokumen referensi yang relevan.
| Reference | Description | Relevance |
|---|---|---|
[Dokumen 1] | [Deskripsi] | [Relevansi terhadap BRD] |
| Aturan Umum Validasi Form Isian (TSG) | Standar validasi form di semua sistem TSG | Diterapkan pada seluruh form input dalam sistem |
| Audit Trails, Activity Logs & History (TSG) | Standar pencatatan aktivitas dan perubahan data | Diterapkan pada modul audit dan monitoring |
| Daftar Fitur Utilitas Sistem (TSG) | Standar fitur monitoring, notifikasi, health check | Digunakan sebagai acuan fitur utilitas sistem |
| Kategori Temuan Major SIT (TSG) | 14 kategori temuan major dalam System Integration Testing | Digunakan sebagai acuan kesiapan sistem untuk SIT |
2. Introduction
TW Technical Writer memastikan kejelasan dan konsistensi bahasa dalam penjelasan pengantar dokumen.
[ISI DI SINI - Jelaskan konteks dokumen BRD ini secara singkat, mencakup:]
- Pernyataan bahwa BRD ini meresmikan kebutuhan bisnis yang telah disetujui
- Ruang lingkup dokumen dan batasan penggunaannya
- Hubungan dengan dokumen lain (PRD, FSD, kontrak)
CONTOH: Dokumen Business Requirement Document (BRD) ini meresmikan bahwa proyek [Nama Proyek] telah disetujui oleh Management untuk ditindaklanjuti ke tahap pengembangan. Setelah BRD ini ditandatangani, pihak-pihak terkait telah sepakat tentang apa yang akan disampaikan dan informasi yang terkandung di dalamnya akan menjadi dasar perumusan solusi teknis.
CONTOH (Sumber: BRD Artajasa CMS Revamp): Dokumen Bisnis (selanjutnya disebut sebagai "BRD") meresmikan bahwa Revamp CMS telah disetujui oleh Management untuk ditindaklanjuti ke Tahap Pengembangan Aplikasi dan persiapan seluruh kelengkapan Infrastruktur yang dibutuhkan. Setelah BRD ini ditandatangani, pihak-pihak terkait telah sepakat tentang apa yang akan disampaikan dan informasi yang terkandung di dalamnya akan menjadi dasar perumusan solusi. Dokumen ini adalah dokumen "Ruang Lingkup Proyek" dan seluruh inisiasi proyek yang diakui dan mungkin ada perubahan atau penambahan pada dokumen ini karena persyaratan khusus.
3. Executive Summary
Executive Summary memberikan gambaran singkat mengenai konteks bisnis, solusi yang diusulkan, dan tujuan proyek. Bagian ini harus dapat dibaca dan dipahami oleh manajemen senior dalam waktu singkat.
3.1 Overview
BA + PM Business Analyst dan Project Manager memberikan gambaran umum proyek.
[ISI DI SINI - Deskripsikan gambaran umum proyek, mencakup:]
- Latar belakang dan konteks bisnis
- Kondisi sistem saat ini dan keterbatasannya (jika ada)
- Solusi yang diusulkan secara ringkas
- Cakupan utama sistem yang akan dibangun
CONTOH: [Nama Klien] telah mengoperasikan [Nama Sistem Lama] sejak [tahun], namun sistem tersebut memiliki keterbatasan [jelaskan]. Oleh karena itu, [Nama Proyek] akan mengembangkan dan mengimplementasikan sistem baru yang mencakup [daftar cakupan utama].
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): Proyek New bjb GIFT merupakan inisiatif transformasi digital untuk menggantikan aplikasi bjb GIFT eksisting yang telah beroperasi sejak 2018. Sistem baru ini dibangun menggunakan teknologi modern, arsitektur modular, serta integrasi API-first untuk mendukung proses keuangan internal Bank bjb secara end-to-end. Aplikasi New bjb GIFT akan menjadi platform terpusat yang mencakup: pengelolaan uang muka, pengajuan dan persetujuan pembayaran operasional, pengelolaan rekening escrow, koreksi jurnal akuntansi, manajemen pajak internal, serta monitoring dan pelaporan keuangan real-time.
3.2 Goals and Objectives
BA Business Analyst mendefinisikan tujuan bisnis proyek.
[ISI DI SINI - Jelaskan tujuan yang ingin dicapai:]
- Tujuan bisnis utama (business goals)
- Target terukur yang diharapkan (measurable objectives)
- Manfaat yang diharapkan (kuantitatif dan kualitatif)
TIPS: Gunakan format SMART (Specific, Measurable, Achievable, Relevant, Time-bound) untuk setiap tujuan bisnis jika memungkinkan.
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb):
No Tujuan Deskripsi KPI 1 Meningkatkan Tata Kelola Keuangan Internal Proses keuangan lebih terkontrol, terdokumentasi, dan audit-ready 100% transaksi audited; zero manual reconciliation 2 Mendukung Transformasi Digital Standardisasi workflow & pengurangan proses manual 40-50% manual work reduction 3 Mengurangi Risiko Kesalahan & Fraud Validasi otomatis dan kontrol berlapis Error rate <0.5%; zero unauthorized approval
4. Business Context
Bagian ini memberikan latar belakang komprehensif mengenai konteks organisasi dan kondisi saat ini. Untuk proyek dengan scope besar atau transformasi digital, bagian ini sangat direkomendasikan.
4.1 Organization Overview
BA Business Analyst mengumpulkan informasi konteks organisasi.
[ISI DI SINI - Berikan gambaran umum organisasi:]
- Nama, jenis, dan sejarah singkat organisasi
- Struktur organisasi yang relevan dengan proyek
- Bidang usaha dan aktivitas utama
- Konteks strategis yang melatarbelakangi proyek
4.2 Current State Analysis (AS-IS)
BA Business Analyst melakukan analisis kondisi saat ini.
4.2.1 Current Process Overview
[ISI DI SINI - Deskripsikan proses bisnis saat ini:]
- Gambaran umum proses yang ada (manual, semi-digital, atau digital)
- Sistem atau aplikasi yang saat ini digunakan
- Alur proses dari awal hingga akhir
CONTOH (Sumber: BRD Artajasa CMS Revamp): Artajasa telah mengimplementasikan dan mengoperasionalkan Cash Management System (CMS), namun layanan tersebut kurang fleksibel dalam pengembangan produknya karena berimpact pada banyak services ketika terdapat perubahan, dan aksesibilitas Artajasa hanya sampai level 1. Oleh karena itu, Revamp CMS diharapkan mengembangkan dan mengimplementasikan design microservice (back-end) dan micro-ui (front-end) serta aksesibilitas Artajasa dapat sampai level 3 sehingga SLA produk dapat dikontrol.
4.2.2 Current System Landscape [OPSIONAL]
| Sistem / Aplikasi | Fungsi | Pemilik | Keterbatasan |
|---|---|---|---|
[Sistem 1] | [Fungsi] | [Pemilik] | [Keterbatasan] |
[Sistem 2] | [Fungsi] | [Pemilik] | [Keterbatasan] |
4.2.3 Pain Points and Challenges
[ISI DI SINI - Identifikasi pain points secara spesifik dan terukur:]
| No | Pain Point | Dampak | Severity | Frekuensi |
|---|---|---|---|---|
| 1 | [Pain point 1] | [Dampak terukur] | [High/Med/Low] | [Harian/Mingguan/dll.] |
| 2 | [Pain point 2] | [Dampak terukur] | [High/Med/Low] | [Harian/Mingguan/dll.] |
TIPS PAIN POINT ANALYSIS: Gali pain points melalui wawancara dengan pengguna langsung, bukan hanya dari manajemen. Pengguna operasional sering memiliki perspektif berbeda tentang masalah sehari-hari yang tidak terlihat dari atas.
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb):
Kategori Pain Point Dampak Stakeholder Terdampak Manual Data Entry Input berulang di banyak sistem Waste time 2-3 jam/hari, error tinggi Staff PKU, PIC Unit Kerja Slow Approval Approval memakan 2-4 hari Operasional terlambat Semua unit No Real-Time Data Data baru tersedia 1-3 hari Keputusan lambat, manajemen reaktif Direksi, Kepala Div PKU Manual Reconciliation Rekonsiliasi manual antar sistem Closing terlambat, error tinggi Akuntansi Weak Audit Trail Tidak lengkap, sering hilang Audit finding, compliance risk Audit & Compliance
4.3 Business Drivers
PM + BA Project Manager dan Business Analyst mengidentifikasi faktor pendorong bisnis.
| Driver | Deskripsi | Urgency |
|---|---|---|
[Driver Internal] | [Deskripsi] | [High/Med/Low] |
[Driver Eksternal] | [Deskripsi] | [High/Med/Low] |
[Regulatory Driver] | [Deskripsi] | [High/Med/Low] |
CONTOH:
Driver Deskripsi Urgency Inefisiensi proses manual Proses persetujuan dokumen masih manual, memerlukan rata-rata 14 hari kerja per siklus High Tuntutan regulasi OJK mewajibkan audit trail digital untuk seluruh transaksi keuangan mulai 2025 High Tekanan kompetitor Kompetitor sudah mengimplementasikan layanan digital serupa sejak 2023 Medium Pertumbuhan volume Volume transaksi meningkat 40% YoY, infrastruktur manual tidak scalable High
5. High-Level Business Process
BA Business Analyst memodelkan proses bisnis secara high-level, baik AS-IS maupun TO-BE.
TIPS PROCESS MODELING: Gunakan notasi BPMN (Business Process Model and Notation) atau swimlane diagram untuk menggambarkan alur proses. Dokumen BRD dapat menyertakan diagram sebagai lampiran atau embed image.
5.1 Process Overview
[ISI DI SINI - Deskripsikan proses bisnis utama yang dicakup sistem:]
5.1.1 [Nama Proses Bisnis 1]
Trigger: [ISI DI SINI - Apa yang memulai proses ini]
| No | Langkah | Pelaku | Aktivitas | Output |
|---|---|---|---|---|
| 1 | [Nama langkah] | [Pelaku] | [Aktivitas yang dilakukan] | [Output] |
| 2 | [Nama langkah] | [Pelaku] | [Aktivitas] | [Output] |
End State: [ISI DI SINI - Kondisi akhir yang menandai proses selesai]
5.1.2 [Nama Proses Bisnis 2]
[ISI DI SINI - Deskripsikan proses bisnis berikutnya]
CONTOH:
Proses Pengajuan Uang Muka
Trigger: Karyawan membutuhkan dana operasional untuk kegiatan dinas
No Langkah Pelaku Aktivitas Output 1 Pengajuan Pemohon Mengisi form pengajuan uang muka dengan nominal, tujuan, dan tanggal kegiatan Form pengajuan terisi 2 Verifikasi Atasan Langsung Memeriksa kesesuaian pengajuan dengan anggaran dan kegiatan Form terverifikasi 3 Approval VP / Pejabat Berwenang Menyetujui atau menolak berdasarkan threshold nominal Surat persetujuan 4 Pencairan Finance Memproses transfer dana ke rekening pemohon Bukti transfer 5 Pertanggungjawaban Pemohon Melaporkan penggunaan dana dengan bukti pengeluaran Laporan pertanggungjawaban End State: Selisih dana dikembalikan atau kekurangan diganti, laporan diarsipkan.
6. Business Rules
BA Business Analyst mendefinisikan aturan bisnis yang mengatur perilaku sistem. Bagian ini digunakan jika business rules cukup kompleks dan perlu didokumentasikan secara terpisah dari kebutuhan bisnis.
TIPS: Jika business rules sudah didokumentasikan di dalam setiap kebutuhan bisnis (Bagian 11), bagian ini bisa dilewati. Gunakan bagian ini untuk aturan bisnis yang berlaku lintas modul atau bersifat global.
6.1 [Kategori Aturan Bisnis: Nama Kategori]
BRU-001: [Nama Aturan Bisnis]
- ID: BRU-001
- Kategori:
[ISI DI SINI - Contoh: Validasi, Komputasi, Otorisasi, Workflow] - Deskripsi:
[ISI DI SINI - Pernyataan aturan yang jelas dan tidak ambigu] - Kondisi (IF):
[ISI DI SINI - Kondisi yang memicu aturan ini] - Tindakan (THEN):
[ISI DI SINI - Tindakan yang diambil jika kondisi terpenuhi] - Pengecualian (EXCEPT):
[ISI DI SINI - Kondisi pengecualian jika ada] - Contoh:
[ISI DI SINI - Contoh skenario konkret] - Source:
[ISI DI SINI - Regulasi, kebijakan, SOP]
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): Approval Rules:
Rule Keterangan Configurable Amount Threshold Jumlah approver disesuaikan berdasarkan nominal pengajuan Yes Segregation of Duty Submitter tidak boleh menjadi approver No Delegation Approval dapat didelegasikan sementara Yes Escalation Auto-escalate ketika SLA approval terlewati Yes Budget Rules:
Rule Validation Point Action Budget availability Saat submit Reject Plafond limit Saat submit uang muka Reject GL validity Saat submit Reject Threshold (80%, 90%) Monitoring Alert
7. Stakeholder Analysis
Identifikasi ekosistem stakeholders yang akan berinteraksi dengan, mendapat manfaat dari, atau terpengaruh oleh implementasi sistem.
7.1 Stakeholder Map
PM + BA Project Manager dan Business Analyst memetakan seluruh stakeholders.
[ISI DI SINI - Petakan semua stakeholders yang relevan:]
| Stakeholder | Peran | Kepentingan | Pengaruh |
|---|---|---|---|
[Stakeholder 1] | [Peran] | [High/Med/Low] | [High/Med/Low] |
[Stakeholder 2] | [Peran] | [High/Med/Low] | [High/Med/Low] |
CONTOH:
Stakeholder Peran Kepentingan Pengaruh VP Finance Sponsor, pemilik anggaran High High Tim Operasional Cabang Pengguna utama sistem sehari-hari High Medium Tim IT Internal Memaintain sistem setelah go-live Medium High Auditor Internal Membutuhkan laporan audit dari sistem Medium Low Vendor Pihak Ketiga Penyedia integrasi payment gateway Low Medium
TIPS STAKEHOLDER ANALYSIS: Jangan lupakan stakeholder "diam" — mereka yang tidak hadir dalam rapat tapi terdampak oleh sistem. Contoh: staf IT yang harus memaintain sistem, tim audit internal yang butuh laporan, atau unit compliance.
8. Regulatory and Compliance Requirements
PM + BA Project Manager dan Business Analyst mengidentifikasi regulasi yang berlaku. Bagian ini direkomendasikan untuk proyek di industri yang diregulasi (perbankan, keuangan, pemerintahan, kesehatan).
CATATAN: Jika tidak ada regulasi khusus yang berlaku, isi bagian ini dengan "Tidak ada regulasi khusus yang berlaku untuk proyek ini." Bagian ini wajib diisi untuk memastikan tim telah mempertimbangkan aspek kepatuhan.
8.1 Applicable Regulations
| Regulasi / Standar | Otoritas | Kewajiban Utama | Konsekuensi Ketidakpatuhan |
|---|---|---|---|
[Regulasi 1] | [Otoritas] | [Kewajiban] | [Konsekuensi] |
[Regulasi 2] | [Otoritas] | [Kewajiban] | [Konsekuensi] |
CONTOH:
Regulasi / Standar Otoritas Kewajiban Utama Konsekuensi Ketidakpatuhan PBI No. 19/10/PBI/2017 Bank Indonesia Anti pencucian uang, KYC untuk transaksi keuangan Sanksi administratif, pencabutan izin POJK No. 11/POJK.03/2022 OJK Manajemen risiko TI, keamanan data nasabah Denda, pembatasan layanan ISO 27001 ISO Keamanan informasi, kontrol akses, logging Gagal sertifikasi, kehilangan kepercayaan klien UU No. 27/2022 (PDP) Pemerintah RI Perlindungan data pribadi, consent management Denda hingga 2% pendapatan tahunan
8.2 Compliance Requirements
[ISI DI SINI - Detailkan kebutuhan kepatuhan:]
- Keamanan data dan privasi
- Audit dan akuntabilitas
- Continuity dan disaster recovery (jika belum dicakup di NFR)
9. Process Improvements / Gap Analysis
BA Business Analyst merangkum perbaikan proses atau gap yang teridentifikasi.
| No | Area / Gap | Kondisi Saat Ini | Kondisi Target | Cara Menutup Gap | Priority |
|---|---|---|---|---|---|
| 1 | [Area 1] | [Kondisi saat ini] | [Target] | [Solusi] | [High/Med/Low] |
| 2 | [Area 2] | [Kondisi saat ini] | [Target] | [Solusi] | [High/Med/Low] |
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb):
Aspek Kondisi Saat Ini (AS-IS) Kondisi Target (TO-BE) Value Added Improvement Submission Time 30-60 menit 10-15 menit Efisiensi waktu signifikan 50-75% Approval Cycle 2-4 hari 4-8 jam Cash flow lebih cepat 75-90% Budget Checking Manual Real-time Tidak ada delay 100% Journal Posting Manual, 1-2 hari Real-time Akurasi & kecepatan 90% Error Rate 5-10% < 0.5% Quality boost 90-95%
10. Scope
Definisi scope yang jelas sangat penting untuk mengelola ekspektasi stakeholders, mencegah scope creep, dan menetapkan batasan yang jelas.
10.1 In Scope
PM + BA Project Manager dan Business Analyst mendefinisikan scope.
10.1.1 Entity in Scope
[ISI DI SINI - Daftarkan entitas bisnis yang termasuk dalam scope:]
| Entity | Deskripsi | Cakupan |
|---|---|---|
[Entity 1] | [Deskripsi] | [Apa yang dicakup] |
[Entity 2] | [Deskripsi] | [Apa yang dicakup] |
10.1.2 Scope per Area Bisnis / Modul
[ISI DI SINI - Daftarkan secara detail area bisnis atau modul yang termasuk dalam scope:]
[Area / Modul 1]:
[Proses bisnis yang dicakup][Integrasi yang diperlukan]
[Area / Modul 2]:
[Proses bisnis yang dicakup][Integrasi yang diperlukan]
TIPS SCOPE DEFINITION: Buat daftar in-scope yang cukup detail agar tidak menimbulkan interpretasi berbeda. Ambiguitas dalam scope adalah sumber utama perselisihan. Jika suatu area "mungkin termasuk", lebih baik dimasukkan ke daftar out-of-scope dengan keterangan "pertimbangkan untuk fase berikutnya."
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): In-Scope: A. Pengembangan Aplikasi: (1) Modul Autentikasi & Login, (2) Modul Pengelolaan Uang Muka, (3) Modul Pengajuan Pembayaran Operasional, (4) Modul Sistem Pajak, (5) Modul Rekening Escrow, (6) Modul Koreksi Jurnal, (7) Modul Laporan & Dashboard, (8) Modul Admin & Master Data. B. Integrasi Sistem: UIM Next-G, HCS, DWH, bjb Fact, Core Banking (future-ready). C. Deliverables: Dokumen (BRD, TSD, SDD, API Docs), Aplikasi & source code, KT & pelatihan, Warranty 6 bulan + maintenance 1 tahun.
Out-of-Scope: Pengadaan infrastruktur, migrasi data legacy, modifikasi sistem eksternal, mobile app native, integrasi third-party eksternal, business process re-engineering besar.
10.1.3 Volume Information [OPSIONAL]
BA Business Analyst mendokumentasikan informasi volume.
| Parameter | Volume Saat Ini | Proyeksi | Catatan |
|---|---|---|---|
| Jumlah pengguna | [ISI DI SINI] | [ISI DI SINI] | |
| Transaksi per hari | [ISI DI SINI] | [ISI DI SINI] | |
| Volume data | [ISI DI SINI] | [ISI DI SINI] |
10.2 Out of Scope
[ISI DI SINI - Daftarkan secara eksplisit item yang TIDAK termasuk dalam scope:]
| Out of Scope Item | Alasan / Rencana Fase Berikutnya |
|---|---|
[Item 1] | [Alasan tidak termasuk] |
[Item 2] | [Rencana fase berikutnya] |
CONTOH:
Out of Scope Item Alasan / Rencana Fase Berikutnya Mobile app native (Android/iOS) Fase 1 fokus web app; mobile direncanakan fase 2 Migrasi data dari sistem legacy Dilakukan oleh tim DBA terpisah, bukan bagian dari proyek ini Integrasi payment gateway pihak ketiga Menunggu kontrak vendor selesai, direncanakan Q2 2026 Business process re-engineering Di luar scope IT; perubahan proses ditangani oleh unit bisnis
10.3 Assumptions and Constraints
BA + PM Business Analyst dan Project Manager mendokumentasikan asumsi dan batasan.
Assumptions:
| No | Asumsi | Dampak Jika Tidak Benar |
|---|---|---|
| 1 | [Asumsi 1] | [Dampak] |
| 2 | [Asumsi 2] | [Dampak] |
Constraints:
| Kategori | Constraint | Implikasi |
|---|---|---|
| Anggaran | [Batas anggaran] | [Implikasi terhadap scope] |
| Waktu | [Deadline yang tidak dapat diubah] | [Implikasi terhadap scope] |
| Teknologi | [Batasan teknologi/infrastruktur] | [Implikasi terhadap desain] |
| Regulasi | [Regulasi yang harus dipatuhi] | [Implikasi terhadap implementasi] |
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): Assumptions:
No Asumsi Dampak Jika Tidak Benar 1 Bank bjb akan menyediakan akses ke semua sistem yang perlu diintegrasikan (UIM Next-G, HCS, Budget System, GL System) Delay integrasi, scope reduction 2 API documentation untuk sistem eksternal tersedia dan up-to-date Integration delay 3 Infrastruktur Bank bjb (server, network, storage) memadai untuk hosting sistem baru Performance issues Constraints:
Kategori Constraint Implikasi Waktu Sistem harus live sebelum Q3 2025 (hard deadline) Agile methodology, MVP approach, parallel workstream Anggaran Budget sudah fixed, tidak bisa ditambah (sesuai RKAP) Prioritize must-have features, phase 2 untuk nice-to-have Sumber Daya Development team terbatas (max 8 developers) Prioritization fitur, gunakan framework/library yang mature
11. Detailed Business Requirements
BA + QA Business Analyst mendefinisikan kebutuhan bisnis; QA memastikan setiap kebutuhan memiliki acceptance criteria yang dapat diuji.
Bagian ini merupakan inti dari BRD. Kebutuhan bisnis dapat didokumentasikan dalam dua format tergantung kompleksitas proyek:
- Format Modular: Dikelompokkan per modul/area bisnis dengan Actor, Use Cases, Functional Requirements, dan Data Requirements per modul. Cocok untuk proyek besar dengan banyak modul (contoh: sistem perbankan, ERP).
- Format Flat: Daftar kebutuhan bisnis dengan ID unik (BR-xxx). Cocok untuk proyek dengan scope lebih terbatas.
TIPS MoSCoW PRIORITIZATION: Must Have = kebutuhan absolut, sistem tidak bisa berjalan tanpanya. Should Have = kebutuhan penting tapi ada workaround sementara. Could Have = nice-to-have. Won't Have (this time) = disepakati tidak dimasukkan saat ini.
Format A: Kebutuhan per Modul (Untuk Proyek Multi-Modul)
11.A.1 [Nama Modul 1]
Deskripsi Modul: [ISI DI SINI - Jelaskan tujuan dan cakupan modul ini]
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb): Deskripsi Modul: Modul Login & Authentication adalah gerbang utama aplikasi New bjb GIFT yang mengatur autentikasi user melalui integrasi dengan UIM Next-G, otorisasi akses berdasarkan role dan permission (RBAC), manajemen session (timeout, concurrent session limit), serta pencatatan security & audit log untuk aktivitas login/logout.
Actor / User:
[Aktor utama 1 — Peran][Aktor utama 2 — Peran]
Menu Structure: [OPSIONAL]
[Nama Menu Utama]
+-- [Sub-menu 1]
| +-- [Sub-sub-menu]
+-- [Sub-menu 2]
+-- [Sub-menu 3]
Key Use Cases:
UC-[MOD]-001: [Nama Use Case]
- Aktor:
[ISI DI SINI] - Deskripsi:
[ISI DI SINI - Ringkasan alur dari awal hingga akhir] - Kondisi Awal:
[ISI DI SINI - Prasyarat] - Skenario Sukses:
[ISI DI SINI - Alur normal] - Skenario Alternatif:
[ISI DI SINI - Alur alternatif dan error handling] - Business Rules:
[ISI DI SINI - Aturan bisnis yang berlaku]
CONTOH (Sumber: BRD Artajasa CMS Revamp): UC-CMS-003: Corporate Limit Configuration
- Aktor: User Back Office (Bank)
- Deskripsi: Mengatur limit transaksi per masing-masing corporate berdasarkan jenis transaksi (On Us, BI Fast, SKN, RTGS, RTOL).
- Business Rules: Limit corporate tidak boleh lebih besar atau lebih kecil dari pengaturan global limit. Secara default corporate limit mengacu pada global limit. Jika global limit diubah di bawah corporate limit, maka corporate limit otomatis menyesuaikan global limit.
Functional Requirements:
| FR ID | Requirement Statement | Acceptance Criteria (ringkas) | Priority |
|---|---|---|---|
| FR-[MOD]-001 | [Sistem HARUS/SEBAIKNYA...] | [Kriteria yang dapat diuji] | [Must/Should/Could] |
| FR-[MOD]-002 | [Sistem HARUS/SEBAIKNYA...] | [Kriteria yang dapat diuji] | [Must/Should/Could] |
TIPS FR STATEMENT: Gunakan kata "HARUS" (Must Have), "SEBAIKNYA" (Should Have), atau "DAPAT" (Could Have) untuk menunjukkan prioritas langsung pada pernyataan requirement.
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb):
FR ID Requirement Statement Acceptance Criteria (ringkas) Priority FR-AUTH-001 System HARUS terintegrasi dengan UIM Next-G untuk autentikasi user via REST API Login hanya valid bila token dari UIM menyatakan berhasil; error ditangani dengan pesan jelas Must Have FR-AUTH-005 System HARUS menerapkan account lockout setelah 5 failed login attempt dalam 30 menit Setelah melewati batas, login ditolak selama 30 menit; event tercatat di audit log Must Have FR-AUTH-006 System HARUS menerapkan session timeout 30 menit idle dengan warning 5 menit sebelumnya Setelah timeout, session diakhiri, audit "session timeout" tercatat, user kembali ke login Must Have
Data Requirements: [OPSIONAL]
[ISI DI SINI - Identifikasi entitas data utama modul ini:]
| Entity | Deskripsi | Atribut Kunci |
|---|---|---|
[Entity 1] | [Deskripsi] | [field1, field2, field3] |
TIPS DATA REQUIREMENTS: Detail field-level (tipe data, mandatory/optional, constraint) dapat didokumentasikan sebagai lampiran Data Dictionary jika terlalu banyak untuk body dokumen.
11.A.2 [Nama Modul 2]
[Ulangi struktur di atas untuk setiap modul]
Format B: Daftar Kebutuhan Bisnis Flat (Untuk Proyek Ringkas)
11.B.1 [Kelompok Kebutuhan 1: Nama Area Bisnis]
Deskripsi Area: [ISI DI SINI - Jelaskan area bisnis yang dicakup]
BR-001: [Nama Kebutuhan Bisnis]
- ID: BR-001
- Area Bisnis:
[ISI DI SINI] - Deskripsi:
[ISI DI SINI - "Sistem harus mampu... agar... sehingga..."] - Rationale:
[ISI DI SINI - Mengapa kebutuhan ini ada?] - Priority:
[Must Have / Should Have / Could Have / Won't Have] - Source:
[ISI DI SINI - Stakeholder, regulasi, atau proses bisnis] - Business Rules:
[Aturan bisnis yang relevan]
- Acceptance Criteria:
- AC-001-1:
[Diberikan [kondisi], ketika [aksi], maka [hasil yang diharapkan]] - AC-001-2:
[Kriteria berikutnya]
- AC-001-1:
- Dependencies:
[BR yang lain yang menjadi prasyarat, jika ada]
BR-002: [Nama Kebutuhan Bisnis]
- ID: BR-002
- Area Bisnis:
[ISI DI SINI] - Deskripsi:
[ISI DI SINI] - Rationale:
[ISI DI SINI] - Priority:
[Must Have / Should Have / Could Have / Won't Have] - Source:
[ISI DI SINI] - Acceptance Criteria:
- AC-002-1:
[ISI DI SINI]
- AC-002-1:
11.B.2 [Kelompok Kebutuhan 2: Nama Area Bisnis]
[Ulangi struktur di atas untuk setiap kelompok]
Format C: User Story / Epic (Untuk Proyek Agile) [OPSIONAL]
Format ini cocok untuk proyek yang menggunakan metodologi Agile dan membutuhkan kebutuhan dalam format User Story.
Epic: [Nama Epic]
[ISI DI SINI - Sebagai [peran], saya ingin [kemampuan], agar [manfaat bisnis].]
User Story 1: [Nama User Story]
Sebagai [peran pengguna],
Saya ingin [kemampuan/fitur],
Agar [manfaat/nilai bisnis].
Acceptance Criteria:
[Kriteria 1][Kriteria 2][Kriteria 3]
User Story 2: [Nama User Story]
[Ulangi format di atas]
CONTOH (Sumber: BRD SISAPPRA PPNS — Satpol PP DKI Jakarta): Epic: Sebagai Satpol PP DKI Jakarta, saya ingin menginisiasi Operasi Yustisi berdasarkan laporan pelanggaran atau instruksi pimpinan, agar tim dapat segera melaksanakan penindakan terhadap pelanggaran Perda/PerGub secara sah, terstruktur, dan terdokumentasi.
User Story 1: Input Laporan Pelanggaran Sebagai petugas pelaporan atau masyarakat, saya ingin menginput laporan pelanggaran secara digital, agar laporan tersebut bisa ditindaklanjuti secara resmi oleh Satpol PP.
Acceptance Criteria:
- Form pelaporan tersedia secara online dan internal
- Field wajib mencakup: lokasi kejadian, jenis pelanggaran, waktu kejadian, bukti (foto/video)
- Sistem memberikan nomor tiket laporan dan notifikasi bahwa laporan telah diterima
11.X Business Requirements Summary
QA QA menggunakan tabel ini untuk memastikan traceability dari kebutuhan bisnis ke test case.
| Req ID | Deskripsi Singkat | Area / Modul | Priority | Status |
|---|---|---|---|---|
[BR-001 / FR-MOD-001] | [Deskripsi singkat] | [Area] | [Must Have] | [Draft/Approved] |
[BR-002 / FR-MOD-002] | [Deskripsi singkat] | [Area] | [Should Have] | [Draft/Approved] |
12. Ekspektasi Non-Fungsional
BA + PM Business Analyst dan Project Manager mendefinisikan ekspektasi bisnis terhadap kualitas sistem. Bagian ini menangkap APA yang bisnis harapkan, bukan BAGAIMANA tim teknis mengimplementasikannya. Detail teknis (response time exact, arsitektur keamanan, backup schedule) didokumentasikan dalam PRD dan SDD.
| Aspek | Ekspektasi Bisnis | Priority |
|---|---|---|
| Kecepatan | [ISI DI SINI — contoh: Sistem harus responsif, halaman dan laporan terbuka tanpa waktu tunggu yang mengganggu produktivitas] | [Must/Should] |
| Kapasitas | [ISI DI SINI — contoh: Sistem harus mampu melayani seluruh pengguna secara bersamaan tanpa penurunan kualitas, terutama di jam sibuk] | [Must/Should] |
| Ketersediaan | [ISI DI SINI — contoh: Sistem harus tersedia selama jam operasional tanpa gangguan. Jika terjadi kegagalan, operasional bisnis harus dapat dilanjutkan dalam waktu wajar] | [Must/Should] |
| Keamanan | [ISI DI SINI — contoh: Data sensitif harus terlindungi, akses sesuai wewenang, seluruh aktivitas tercatat untuk keperluan audit] | [Must/Should] |
| Pemulihan | [ISI DI SINI — contoh: Jika terjadi kegagalan sistem, data tidak boleh hilang lebih dari batas yang dapat ditoleransi bisnis, dan layanan harus pulih dalam waktu yang disepakati] | [Must/Should] |
| Kemudahan Penggunaan | [ISI DI SINI — contoh: Pengguna baru harus dapat menggunakan fungsi utama sistem tanpa pelatihan intensif] | [Should/Could] |
| Pencatatan Aktivitas | [ISI DI SINI — contoh: Seluruh aktivitas penting (transaksi, persetujuan, perubahan data) harus tercatat dan dapat ditelusuri untuk keperluan audit dan investigasi] | [Must/Should] |
| Retensi Data | [ISI DI SINI — contoh: Data historis harus tersedia minimal sesuai kebutuhan regulasi dan operasional bisnis] | [Must/Should] |
CONTOH:
Aspek Ekspektasi Bisnis Priority Kecepatan Halaman harus terbuka dalam hitungan detik. Laporan bulanan harus tersedia dalam waktu kurang dari 10 detik Must Have Kapasitas Sistem harus mampu melayani 500 pengguna bersamaan tanpa kendala, dan siap untuk pertumbuhan hingga 2.000 pengguna Must Have Ketersediaan Sistem tersedia 24/7 dengan gangguan tidak melebihi 4 jam per tahun di luar jadwal pemeliharaan Must Have Keamanan Hanya pengguna berwenang yang dapat mengakses data sesuai perannya. Data keuangan terenkripsi. Setiap akses tercatat Must Have Pemulihan Jika sistem gagal, harus pulih dalam 4 jam. Data yang hilang maksimal 1 jam terakhir Must Have Kemudahan Penggunaan 80% pengguna mampu membuat pengajuan dan melakukan approval tanpa pelatihan formal Should Have Pencatatan Aktivitas Seluruh transaksi, approval, dan perubahan data master tercatat lengkap dan tidak dapat diubah. Tersedia untuk audit minimal 2 tahun Must Have Retensi Data Data transaksi tersimpan aktif 2 tahun, diarsip 5 tahun, sesuai kebijakan regulasi perbankan Must Have Detail implementasi teknis (response time target per endpoint, arsitektur keamanan, backup schedule, monitoring tools) didokumentasikan dalam PRD dan SDD.
13. Data Requirements [OPSIONAL]
BA + DEV Business Analyst mendefinisikan entitas data bisnis; Developer mendesain model data teknis. Bagian ini digunakan jika kebutuhan data belum tercakup dalam Bagian 11 (per modul).
13.1 Core Data Entities
| Entitas | Deskripsi Bisnis | Atribut Kunci | Pemilik Data |
|---|---|---|---|
[Entitas 1] | [Deskripsi] | [Atribut: nama, tanggal, status, dll.] | [Unit/peran pemilik data] |
[Entitas 2] | [Deskripsi] | [Atribut kunci] | [Unit/peran pemilik data] |
CONTOH:
Entitas Deskripsi Bisnis Atribut Kunci Pemilik Data Pengajuan Uang Muka Permohonan dana operasional oleh karyawan nomor pengajuan, pemohon, nominal, tujuan, tanggal kegiatan, status Finance Transaksi Pembayaran Catatan pembayaran ke vendor/pihak ketiga nomor transaksi, vendor, nominal, kategori, tanggal bayar, bukti Finance Karyawan Data pegawai yang menggunakan sistem NIP, nama, jabatan, unit kerja, email, role HR
13.2 Data Quality and Governance [OPSIONAL]
[ISI DI SINI - Tentukan kebijakan tata kelola data:]
- Kebijakan retensi data
- Kebijakan akses data
- Penanganan data pribadi (sesuai regulasi yang berlaku)
- Standar kualitas data minimum
CONTOH:
- Retensi: Data transaksi disimpan aktif selama 2 tahun, diarsip selama 5 tahun, dihapus setelah 7 tahun
- Akses: Data keuangan hanya dapat diakses oleh role Finance dan Auditor; karyawan hanya melihat data miliknya sendiri
- Kualitas: Tidak boleh ada duplikasi NIP; setiap transaksi harus memiliki bukti pendukung yang ter-upload
14. Risk Assessment
PM Project Manager bertanggung jawab atas manajemen risiko proyek.
14.1 Risk Register
| ID | Risiko | Kategori | Probability | Impact | Risk Score | Mitigation Strategy |
|---|---|---|---|---|---|---|
| R-001 | [Risiko 1] | [Kategori] | [H/M/L] | [H/M/L] | [H/M/L] | [Strategi mitigasi] |
| R-002 | [Risiko 2] | [Kategori] | [H/M/L] | [H/M/L] | [H/M/L] | [Strategi mitigasi] |
Kategori Risiko yang Umum: Bisnis, Teknologi, Sumber Daya, Regulasi, Keamanan, Manajemen Perubahan, Vendor/Pihak Ketiga, Data.
RISK SCORING: Risk Score = Probability x Impact. High-High = Critical (butuh perhatian segera). High-Medium = High Risk (perlu mitigasi aktif). Medium-Medium = Moderate (monitor dan siapkan contingency).
CONTOH (Sumber: BRD New bjb GIFT — Bank bjb):
ID Risiko Kategori Probability Impact Risk Score Mitigation Strategy TR-001 Integration dengan UIM Next-G gagal atau tidak stabil Integration High (70%) High Critical Early integration testing, dedicated integration team, regular sync dengan tim UIM TR-002 Performance sistem tidak memenuhi target (response time > 2 detik) Performance Medium (50%) High High Performance testing sejak awal, code review fokus performance, database indexing, caching (Redis) BR-001 User resistance to change (lebih nyaman dengan sistem lama) Change Mgmt High (60%) High Critical Program change management, user champion di tiap unit, early user involvement & pilot
14.2 Risk Details [OPSIONAL]
Untuk risiko dengan score High atau Critical, dokumentasikan detail berikut:
R-001: [Nama Risiko]
- Deskripsi:
[ISI DI SINI] - Penyebab Potensial:
[ISI DI SINI] - Dampak Jika Terjadi:
[ISI DI SINI] - Mitigation Strategy:
[ISI DI SINI] - Contingency Plan:
[ISI DI SINI] - Risk Owner:
[ISI DI SINI]
15. Project Governance and Timeline
PM Project Manager mendefinisikan tata kelola dan timeline proyek.
15.1 Project Governance
Project Working Committee
| Name | Contact | Role |
|---|---|---|
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] |
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] |
Project Steering Committee [OPSIONAL]
| Name | Contact | Role |
|---|---|---|
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] |
[ISI DI SINI - Jelaskan mekanisme governance: frekuensi pertemuan, eskalasi isu, decision-making]
CONTOH (Sumber: BRD Artajasa CMS Revamp): Steering Committee Proyek membentuk tim proyek bekerja dan akan bertemu (atau melalui konferensi telepon) mingguan untuk meninjau kemajuan, mengidentifikasi dan menyelesaikan masalah atau meningkatkannya ke PSC. Frekuensi pertemuan PSC akan dijadwalkan secara bulanan (month on month), dan dapat berubah untuk kemajuan proyek.
15.2 Project Timeline
[ISI DI SINI - Berikan gambaran timeline proyek:]
| Fase | Nama Fase | Durasi | Timeline | Deliverable Utama |
|---|---|---|---|---|
| 1 | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY - DD/MM/YYYY] | [ISI DI SINI] |
| 2 | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY - DD/MM/YYYY] | [ISI DI SINI] |
| 3 | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY - DD/MM/YYYY] | [ISI DI SINI] |
CONTOH:
Fase Nama Fase Durasi Timeline Deliverable Utama 1 Requirement & Design 6 minggu 01/01/2026 - 14/02/2026 BRD, PRD, SDD, UI Design 2 Development 12 minggu 15/02/2026 - 08/05/2026 Source code, unit test 3 SIT & Bug Fixing 4 minggu 09/05/2026 - 05/06/2026 Test report, bug fixes 4 UAT & Go-Live Prep 4 minggu 06/06/2026 - 03/07/2026 UAT sign-off, deployment 5 Go-Live & Warranty 4 minggu 04/07/2026 - 31/07/2026 Production release, support
15.3 Key Milestones [OPSIONAL]
| No | Milestone | Target Date | Kriteria Pencapaian | Dependensi |
|---|---|---|---|---|
| M-01 | BRD Final Approved | [DD/MM/YYYY] | Tanda tangan semua approval authority | - |
| M-02 | PRD Approved | [DD/MM/YYYY] | [Kriteria] | M-01 |
| M-03 | Development Complete | [DD/MM/YYYY] | [Kriteria] | M-02 |
| M-04 | SIT Passed | [DD/MM/YYYY] | 0 temuan major terbuka | M-03 |
| M-05 | UAT Approved | [DD/MM/YYYY] | [Kriteria] | M-04 |
| M-06 | Go-Live | [DD/MM/YYYY] | [Kriteria] | M-05 |
CONTOH:
No Milestone Target Date Kriteria Pencapaian Dependensi M-01 BRD Approved 15/01/2026 Tanda tangan seluruh stakeholder - M-02 PRD & SDD Approved 14/02/2026 Review oleh Tech Lead + BA M-01 M-03 Development Complete 08/05/2026 Seluruh modul selesai, unit test pass M-02 M-04 SIT Passed 05/06/2026 0 temuan major terbuka M-03 M-05 UAT Approved 03/07/2026 Sign-off dari business owner M-04 M-06 Go-Live 04/07/2026 Deployment sukses, monitoring 24 jam M-05
TIPS TIMELINE: Jangan underestimate waktu untuk UAT dan change management — ini selalu lebih lama dari yang diperkirakan.
16. Deliverables [OPSIONAL]
PM Project Manager mendefinisikan deliverables proyek.
| No | Deliverable | Deskripsi | PIC | Target |
|---|---|---|---|---|
| 1 | BRD | Business Requirements Document | BA | [Tanggal] |
| 2 | PRD | Product Requirements Document | BA | [Tanggal] |
| 3 | SDD | System Design Document | DEV | [Tanggal] |
| 4 | Source Code | Kode sumber aplikasi | DEV | [Tanggal] |
| 5 | Test Report | Laporan hasil testing (SIT, UAT) | QA | [Tanggal] |
| 6 | User Manual | Panduan penggunaan sistem | TW | [Tanggal] |
[N] | [Deliverable lain] | [Deskripsi] | [PIC] | [Tanggal] |
CONTOH:
No Deliverable Deskripsi PIC Target 1 BRD v1.0 Business Requirements Document final BA 15/01/2026 2 PRD v1.0 Product Requirements Document BA 14/02/2026 3 SDD v1.0 Software Design Document Tech Lead 14/02/2026 4 Source Code + Repository Kode sumber di GitLab Dev Team 08/05/2026 5 Test Report (SIT + UAT) Laporan hasil testing QA 03/07/2026 6 User Manual Panduan penggunaan untuk end user TW 03/07/2026 7 Knowledge Transfer Sesi pelatihan + dokumentasi admin PM + Dev 10/07/2026 8 Warranty Support Dukungan pasca go-live selama 6 bulan Dev Team 31/12/2026
17. Approval and Sign-off
Bagian ini mendokumentasikan persetujuan formal dari seluruh pihak berwenang yang menandakan BRD telah disetujui dan proyek dapat dilanjutkan ke tahap berikutnya.
17.1 Sign-off Records
Dengan menandatangani dokumen ini, pihak-pihak berikut menyatakan bahwa mereka telah membaca, memahami, dan menyetujui isi Business Requirements Document ini. Persetujuan ini memberikan wewenang kepada tim proyek untuk melanjutkan ke tahap pengembangan berdasarkan kebutuhan yang tertulis dalam dokumen ini.
| Nama | Jabatan | Divisi / Unit | Tanggal | Tanda Tangan |
|---|---|---|---|---|
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY] | _______________ |
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY] | _______________ |
[ISI DI SINI] | [ISI DI SINI] | [ISI DI SINI] | [DD/MM/YYYY] | _______________ |
CATATAN PENTING: Persetujuan pada dokumen ini tidak mengizinkan perubahan scope atau kebutuhan tanpa melalui proses Change Request formal. Setiap perubahan setelah BRD disetujui harus didokumentasikan, dinilai dampaknya, dan mendapatkan persetujuan ulang dari pihak yang berwenang.
17.2 Change Request Process (Post-Approval)
PM Project Manager mengelola proses perubahan setelah BRD disetujui.
Kriteria yang Memerlukan Change Request:
- Penambahan kebutuhan bisnis baru yang tidak ada dalam BRD ini
- Perubahan scope yang mempengaruhi anggaran atau timeline lebih dari
[ISI DI SINI - threshold, misal 10%] - Perubahan business rules yang mempengaruhi alur proses utama
- Perubahan yang mempengaruhi integrasi dengan sistem lain
Prosedur Change Request:
- Pemohon mengajukan Change Request Form kepada PM
- BA melakukan impact analysis (scope, biaya, timeline)
- Steering Committee mengevaluasi dan memutuskan
- Jika disetujui: update BRD, dapatkan tanda tangan ulang, komunikasikan ke tim
- Jika ditolak: dokumentasikan keputusan dan alasan penolakan
| CR ID | Tanggal Pengajuan | Deskripsi Perubahan | Dampak | Status | Diputuskan Oleh | Tanggal Keputusan |
|---|---|---|---|---|---|---|
| CR-001 | [DD/MM/YYYY] | [ISI DI SINI] | [ISI DI SINI] | [Approved/Rejected/Pending] | [Nama] | [DD/MM/YYYY] |
Lampiran A: Checklist Validasi BRD [OPSIONAL]
Gunakan checklist ini untuk memvalidasi kelengkapan BRD sebelum diserahkan untuk review.
| No | Checklist Item | Status | Catatan |
|---|---|---|---|
| 1 | Document control lengkap (metadata, revision log, reviewers) | [Ya/Tidak] | |
| 2 | Introduction dan Executive Summary jelas dan ringkas | [Ya/Tidak] | |
| 3 | Stakeholder teridentifikasi lengkap | [Ya/Tidak] | |
| 4 | Scope (in-scope dan out-of-scope) terdefinisi jelas | [Ya/Tidak] | |
| 5 | Assumptions dan constraints terdokumentasi | [Ya/Tidak] | |
| 6 | Proses bisnis high-level terdokumentasi | [Ya/Tidak] | |
| 7 | Seluruh kebutuhan bisnis memiliki ID unik | [Ya/Tidak] | |
| 8 | Setiap kebutuhan memiliki prioritas (MoSCoW) | [Ya/Tidak] | |
| 9 | Acceptance criteria dapat diuji (testable) | [Ya/Tidak] | |
| 10 | Non-functional requirements terdefinisi | [Ya/Tidak] | |
| 11 | Integrasi dengan sistem lain teridentifikasi | [Ya/Tidak] | |
| 12 | Risiko teridentifikasi dan ada mitigasi | [Ya/Tidak] | |
| 13 | Timeline dan milestones realistis | [Ya/Tidak] | |
| 14 | Approval matrix dan sign-off section tersedia | [Ya/Tidak] | |
| 15 | Referensi standar TSG (validasi, audit trail, utilitas) tercantum | [Ya/Tidak] | |
| 16 | Dokumen telah di-review oleh BA, PM, DEV, dan QA | [Ya/Tidak] |
Hanya digunakan untuk kalangan internal PT. Tristar Surya Gemilang dan tidak untuk didistribusikan secara umum.