Product Requirements Document

Template & Panduan Penulisan

Untuk Project Manager, Business Analyst, Technical Writer, Quality Assurance, Programmer, dan Anggota Tim Lainnya

Versi 1.0 | 2025

---

Panduan Penggunaan Template

Template ini dirancang untuk membantu seluruh anggota tim proyek dalam membuat, membaca, dan memahami Product Requirements Document (PRD) dengan konsisten dan komprehensif.

Tujuan Dokumen Ini

• Memberikan struktur standar untuk dokumen kebutuhan produk
• Memastikan semua aspek kebutuhan produk tercakup dengan lengkap
• Memfasilitasi komunikasi efektif antar anggota tim
• Menjadi acuan tunggal (single source of truth) selama siklus hidup proyek

Cara Menggunakan Template

1. Baca seluruh template untuk memahami struktur dan ruang lingkup PRD
2. Isi setiap bagian sesuai dengan panduan yang diberikan
3. Hapus bagian yang tidak relevan atau tambahkan bagian khusus jika diperlukan
4. Gunakan tanda [ISI DI SINI] sebagai penanda bagian yang perlu diisi
5. Perbarui versi dokumen setiap kali ada perubahan signifikan

Panduan Peran Tim

Peran	Fokus Area	Kontribusi Utama
Project Manager	Keseluruhan dokumen, timeline, stakeholder	Mengkoordinasi pembuatan PRD, memastikan kelengkapan, mengelola perubahan
Business Analyst	Kebutuhan fungsional, proses bisnis, aturan validasi	Mendetailkan kebutuhan fungsional, memetakan proses bisnis
Technical Writer	Struktur dokumen, kejelasan bahasa, konsistensi	Menyusun dan mengedit dokumen agar jelas dan konsisten
Quality Assurance	Kriteria penerimaan, skenario pengujian, kasus uji	Menderivasi test case dari kebutuhan dan acceptance criteria
Programmer / Developer	Kebutuhan teknis, arsitektur, integrasi API	Memahami kebutuhan untuk implementasi teknis
UI/UX Designer	Kebutuhan pengalaman pengguna, user journey	Mendesain interface berdasarkan kebutuhan UX

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.
• Tag peran menunjukkan bagian yang paling relevan untuk peran tertentu:
  • PM Project Manager
  • BA Business Analyst
  • DEV Developer / Programmer
  • QA Quality Assurance
  • TW Technical Writer

Dokumen Masukan yang Direkomendasikan

PM BA Project Manager dan Business Analyst bertanggung jawab mengumpulkan dokumen masukan berikut sebelum penyusunan PRD dimulai.

No	Dokumen Masukan	Deskripsi	Wajib / Opsional
1	BRD yang telah disetujui	Business Requirements Document sebagai dasar utama penyusunan PRD	Wajib
2	Notulensi rapat / hasil wawancara pengguna	Catatan kebutuhan fungsional dari sesi penggalian kebutuhan detail	Wajib
3	Wireframe / mockup / desain UI	Rancangan antarmuka pengguna dari tim UI/UX (Figma, Adobe XD, atau sketsa)	Wajib (jika ada tim UI/UX)
4	User persona / profil pengguna	Deskripsi karakteristik, kebutuhan, dan perilaku kelompok pengguna	Opsional
5	Flowchart / diagram proses bisnis TO-BE	Alur proses yang diinginkan setelah implementasi sistem	Wajib
6	Dokumentasi API sistem eksternal	Spesifikasi API dari sistem yang akan diintegrasikan (Swagger, Postman collection, dll.)	Wajib (jika ada integrasi)
7	Screenshot / dokumentasi sistem existing	Tampilan dan perilaku sistem yang akan digantikan sebagai referensi	Opsional
8	Daftar role dan hak akses	Matriks peran pengguna dan permission yang dibutuhkan	Wajib
9	Standar validasi form (TSG)	Aturan umum validasi form isian yang berlaku di seluruh proyek TSG	Wajib
10	Standar audit trail (TSG)	Panduan pencatatan audit trail, activity log, dan history	Wajib
11	Contoh laporan / output yang diharapkan	Sampel format laporan, export, atau notifikasi yang dibutuhkan pengguna	Opsional
12	Hasil UAT / feedback dari sistem sebelumnya	Temuan dari pengujian atau keluhan pengguna terhadap sistem lama	Opsional

TIPS: BRD yang disetujui (no. 1) adalah prasyarat utama — PRD tidak boleh disusun sebelum BRD final. Jika BRD belum ada, minimal kumpulkan notulensi rapat dan kontrak proyek sebagai pengganti sementara.

---

1. Document Control

Bagian ini mencakup informasi administratif dan metadata dokumen untuk pengelolaan versi, pelacakan perubahan, dan proses persetujuan.

1.1 Document Identification and Metadata

PM Project Manager bertanggung jawab atas kelengkapan metadata dokumen.

Field	Value
Document Title	[ISI DI SINI - Judul lengkap PRD]
Project Name	[ISI DI SINI - Nama proyek]
Prepared For	[ISI DI SINI - Klien / pemilik proyek]
Prepared By	[ISI DI SINI - Tim / vendor pengembang]
Document Version	[ISI DI SINI - Contoh: 1.0, 1.1, 2.0]
Document Date	[ISI DI SINI - Tanggal penulisan]
Document Owner	[ISI DI SINI - Product Owner / Project Lead]
Reviewers	[ISI DI SINI - Daftar reviewer]
Approval Authority	[ISI DI SINI - Pihak yang berwenang menyetujui]
Related Documents	[ISI DI SINI - Dokumen terkait]

1.2 Purpose of This Document

TW Technical Writer memastikan kejelasan dan konsistensi bahasa dalam penjelasan tujuan dokumen.

[ISI DI SINI - Jelaskan tujuan spesifik dokumen PRD ini, mencakup:]

• Apa yang akan dibangun (produk/sistem apa)
• Siapa pengguna dokumen ini (tim pengembang, stakeholder, QA, dll.)
• Bagaimana dokumen ini akan digunakan sebagai acuan
• Batasan dan ruang lingkup yang dicakup

CONTOH: Dokumen PRD ini berfungsi sebagai spesifikasi teknis otoritatif untuk pengembangan, implementasi, dan penerimaan Sistem X. Dokumen ini mengonsolidasikan kebutuhan dari berbagai sumber menjadi satu referensi komprehensif.

CONTOH (Ilustrasi: Sistem Pengelolaan Keuangan Internal — Bank bjb): Dokumen PRD ini berfungsi sebagai spesifikasi teknis otoritatif untuk pengembangan, implementasi, dan penerimaan Sistem New bjb GIFT. Dokumen ini mengonsolidasikan kebutuhan dari BRD, notulensi rapat stakeholder, hasil FGD, dan spesifikasi teknis menjadi satu referensi komprehensif yang menjadi acuan bagi seluruh tim pengembang, QA, UI/UX, dan stakeholder terkait. PRD ini mencakup spesifikasi fungsional per modul, kebutuhan non-fungsional, arsitektur teknis, acceptance criteria, dan roadmap implementasi.

1.3 Version Control and Change Management

PM Project Manager mengelola versi dan perubahan dokumen.

Version	Date	Author	Description of Changes	Approver	Status
[X.X]	[DD/MM/YYYY]	[Nama]	[Deskripsi perubahan]	[Nama]	[Draft/Approved]
0.1	[DD/MM/YYYY]	[Nama]	Initial PRD draft	[Nama]	Draft

1.4 Review and Approval Process

[ISI DI SINI - Jelaskan proses review dan persetujuan dokumen, termasuk:]

• Tahapan review (internal review, stakeholder review, final approval)
• Kriteria persetujuan
• Proses penanganan komentar dan revisi

1.5 Reference Documents and Standards

BA Business Analyst mengidentifikasi dan mengumpulkan dokumen referensi yang relevan.

Reference	Description	Relevance
[Dokumen 1]	[Deskripsi]	[Relevansi]
[Dokumen 2]	[Deskripsi]	[Relevansi]
[Standar/Regulasi]	[Deskripsi]	[Relevansi]

---

2. Executive Summary

Executive Summary memberikan gambaran singkat dan komprehensif mengenai produk, tantangan yang dihadapi, solusi yang ditawarkan, dan dampaknya bagi stakeholders. Bagian ini harus dapat dibaca dan dipahami dalam waktu singkat.

2.1 The Challenge

BA Business Analyst mendeskripsikan masalah bisnis yang mendasari kebutuhan produk.

[ISI DI SINI - Deskripsikan tantangan atau masalah yang ada, mencakup:]

• Konteks situasi saat ini
• Masalah spesifik yang dihadapi pengguna / organisasi
• Dampak dari masalah tersebut (biaya, efisiensi, kepuasan)
• Mengapa solusi dibutuhkan sekarang

CONTOH: Sektor kehutanan menghadapi tantangan sourcing kayu yang tidak transparan, industri kayu nasional yang kurang terstruktur, dan kurangnya sistem pemeriksaan. Kayu secara teratur "bocor" dari sistem dengan sedikit kontrol.

2.2 The Solution

[ISI DI SINI - Jelaskan solusi yang akan dibangun, termasuk:]

• Deskripsi singkat produk/sistem
• Kemampuan utama (core capabilities)
• Manfaat utama yang akan dihasilkan

CONTOH: Sistem New bjb GIFT akan menjadi platform terpusat berbasis web 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. Sistem dibangun dengan arsitektur microservices dan API-first untuk mendukung integrasi dengan UIM Next-G, HCS, DWH, dan Core Banking.

2.3 System Context

[ISI DI SINI - Jelaskan konteks sistem dalam ekosistem yang lebih besar:]

• Posisi sistem dalam arsitektur IT organisasi
• Sistem terkait yang akan berinteraksi
• Lingkup pengguna dan lokasi operasional

CONTOH: Sistem New bjb GIFT beroperasi sebagai platform keuangan internal yang terintegrasi dalam ekosistem IT Bank bjb. Sistem ini berinteraksi dengan UIM Next-G (autentikasi), HCS (data karyawan), DWH (data warehouse untuk pelaporan), bjb Fact (sistem faktur), dan Core Banking (future-ready). Pengguna mencakup seluruh unit kerja di kantor pusat dan 40+ cabang di Jawa Barat, dengan akses melalui jaringan intranet dan VPN untuk akses remote.

2.4 Technical Architecture Overview

DEV Architect / Lead Developer menyediakan gambaran arsitektur teknis.

[ISI DI SINI - Berikan gambaran singkat arsitektur teknis:]

• Jenis arsitektur (monolitik, microservices, dll.)
• Platform dan teknologi utama
• Persyaratan infrastruktur
• Kapasitas dan skalabilitas

CONTOH:

• Arsitektur: Microservices dengan API Gateway, event-driven untuk notifikasi dan audit
• Backend: Go (Fiber), RESTful API, PostgreSQL / SQL Server
• Frontend: React (TypeScript), SPA, responsive design
• Infrastruktur: Kubernetes on-premise, Redis (caching & session), MinIO (file storage), ELK Stack (logging)
• Kapasitas: Designed for 500 concurrent users, horizontal scaling via K8s pod autoscaler
• Keamanan: OAuth 2.0, JWT, TLS 1.3, AES-256 encryption at rest

2.5 Stakeholder Impact

[ISI DI SINI - Ringkasan dampak terhadap stakeholders utama:]

Stakeholder Group	Current Pain Points	Expected Benefits
[Grup 1]	[Masalah saat ini]	[Manfaat yang diharapkan]
[Grup 2]	[Masalah saat ini]	[Manfaat yang diharapkan]

CONTOH:

Stakeholder Group	Current Pain Points	Expected Benefits
Staff Operasional Cabang	Input manual berulang di 3 sistem berbeda (2-3 jam/hari terbuang)	Single entry, auto-sync antar modul, penghematan waktu 70%
Manajemen / Direksi	Data keuangan baru tersedia 1-3 hari setelah transaksi	Dashboard real-time, keputusan berbasis data terkini
Tim Audit Internal	Audit trail tidak lengkap, rekonsiliasi manual	Audit trail otomatis, laporan kepatuhan satu klik
Tim IT	Sistem legacy sulit dimaintain, tidak ada API standar	Arsitektur modern, API-first, CI/CD pipeline

---

3. Product Background and Context

Bagian ini memberikan latar belakang komprehensif mengenai konteks kebijakan, operasional, teknologis, dan regulasi di mana produk dikembangkan. Pemahaman konteks ini penting bagi tim teknis untuk membuat keputusan arsitektur dan implementasi yang tepat.

3.1 Policy and Sector Context

BA Business Analyst mengumpulkan informasi konteks bisnis dan kebijakan.

3.1.1 Sector Overview

[ISI DI SINI - Berikan gambaran umum sektor/industri terkait:]

• Statistik dan ukuran sektor
• Pemain utama dan struktur pasar
• Tren dan dinamika sektor

CONTOH (Ilustrasi: Sektor Perbankan): Industri perbankan Indonesia terdiri dari 107 bank umum (per 2024) dengan total aset Rp 11.800 triliun. Bank bjb merupakan Bank Pembangunan Daerah (BPD) terbesar di Indonesia dengan aset Rp 180 triliun, melayani Pemerintah Provinsi Jawa Barat dan masyarakat umum melalui 40+ kantor cabang. Tren utama sektor: digitalisasi layanan keuangan, peningkatan regulasi keamanan data (UU PDP), dan transformasi operasional menuju paperless banking.

3.1.2 Challenges Facing the Sector

[ISI DI SINI - Deskripsikan tantangan spesifik yang dihadapi sektor:]

• Tantangan operasional
• Tantangan regulasi dan kepatuhan
• Tantangan teknologis
• Tekanan dari regulasi internasional (jika ada)

CONTOH:

• Operasional: Proses persetujuan keuangan masih manual di banyak BPD, menyebabkan bottleneck 2-4 hari per siklus approval
• Regulasi: OJK mewajibkan audit trail digital untuk seluruh transaksi keuangan; UU PDP mensyaratkan perlindungan data nasabah dengan sanksi hingga 2% pendapatan
• Teknologi: Sistem legacy monolitik sulit dimaintain dan di-scale; integrasi antar sistem internal masih berbasis file transfer manual
• Internasional: Standar Basel III mensyaratkan peningkatan transparansi pelaporan keuangan

3.1.3 Regulatory and Policy Framework

[ISI DI SINI - Jelaskan kerangka kebijakan dan regulasi:]

• Regulasi nasional yang berlaku
• Kewajiban internasional (jika ada)
• Kebijakan organisasi terkait

CONTOH:

Regulasi	Otoritas	Implikasi terhadap Sistem
PBI No. 19/10/PBI/2017	Bank Indonesia	KYC dan anti pencucian uang pada transaksi keuangan
POJK No. 11/POJK.03/2022	OJK	Manajemen risiko TI, keamanan data, audit trail wajib
UU No. 27/2022 (PDP)	Pemerintah RI	Consent management, data retention policy, hak penghapusan
ISO 27001	ISO	Standar keamanan informasi, kontrol akses, logging
Kebijakan Internal BPD	Direksi	SOP pengelolaan keuangan, threshold approval, segregation of duty

3.2 System Context

3.2.1 System Purpose and Scope

[ISI DI SINI - Jelaskan tujuan dan ruang lingkup sistem:]

• Tujuan utama sistem
• Fungsi core yang akan diimplementasi
• Batasan sistem (apa yang TIDAK dilakukan sistem)

CONTOH:

• Tujuan: Menggantikan proses pengelolaan keuangan internal yang manual/semi-digital dengan platform terpusat berbasis web
• Fungsi core: Pengajuan & approval pembayaran, pengelolaan uang muka, rekening escrow, koreksi jurnal, manajemen pajak, dashboard & pelaporan
• Batasan: Sistem TIDAK menangani transaksi nasabah (customer-facing), TIDAK menggantikan Core Banking, dan TIDAK melakukan migrasi data dari sistem legacy

3.2.2 Project Governance Structure

PM Project Manager mendefinisikan struktur tata kelola proyek.

[ISI DI SINI - Jelaskan struktur tata kelola proyek, termasuk:]

• Struktur komite pengarah (steering committee)
• Tim manajemen proyek
• Tim implementasi lapangan
• Tanggung jawab dan wewenang masing-masing tingkatan

CONTOH:

Tingkatan	Peran	Tanggung Jawab	Frekuensi Meeting
Steering Committee	VP Finance, CTO, PM Senior	Keputusan strategis, eskalasi isu kritis, persetujuan perubahan scope	Bulanan
Project Management	PM, BA Lead, Tech Lead	Perencanaan sprint, monitoring progress, manajemen risiko	Mingguan
Tim Implementasi	Developer, QA, UI/UX, TW	Pengembangan, testing, dokumentasi	Daily standup
Tim Klien (Counterpart)	PIC Unit Kerja, IT Internal	UAT, feedback, data preparation	Per sprint review

3.2.3 Technical Standards and Frameworks

DEV Architect / Lead Developer menentukan standar teknis.

Standard/Framework	Application
[Standar 1]	[Bagaimana standar diterapkan]
[Standar 2]	[Bagaimana standar diterapkan]

CONTOH:

Standard/Framework	Application
OWASP Top 10	Acuan utama untuk secure coding dan security testing
ISO 27001	Framework keamanan informasi untuk desain access control dan audit logging
RESTful API Design Guidelines	Standar desain API: resource naming, HTTP methods, status codes, pagination
Clean Architecture	Separasi layer (Handler → Service → Repository) untuk maintainability
Standar Validasi Form TSG	Aturan validasi form isian berlaku di seluruh proyek TSG
Standar Audit Trail TSG	Pencatatan audit trail, activity log, dan history sesuai standar TSG

3.3 Product Scope

3.3.1 Scope Definition

[ISI DI SINI - Definisikan ruang lingkup produk secara spesifik:]

• Fitur dan fungsi yang termasuk dalam scope
• Alasan pemilihan scope ini
• Hubungan dengan fase pengembangan berikutnya (jika ada)

CONTOH: Fase 1 (Current Scope):

• Modul Autentikasi & Login (integrasi UIM Next-G)
• Modul Pengajuan & Approval Pembayaran Operasional
• Modul Pengelolaan Uang Muka
• Modul Dashboard & Pelaporan Keuangan
• Modul Admin & Master Data

Alasan: Modul di atas menangani proses bisnis dengan volume tertinggi dan pain point paling akut (approval bottleneck 2-4 hari).

Fase 2 (Planned): Modul Rekening Escrow, Modul Koreksi Jurnal, Integrasi Core Banking, Mobile App.

3.3.2 Critical Dependencies

[ISI DI SINI - Identifikasi dependensi kritis yang mempengaruhi scope]

CONTOH:

Dependensi	Tipe	Pemilik	Dampak Jika Terlambat
API UIM Next-G tersedia dan terdokumentasi	Eksternal	Tim IT Klien	Modul Login tidak dapat dikembangkan; blocking seluruh modul
Akses ke environment staging klien	Eksternal	Tim IT Klien	SIT terlambat, tidak dapat diuji di infrastruktur target
Finalisasi aturan threshold approval	Bisnis	VP Finance	Business rules approval tidak dapat di-implement
Desain UI/UX disetujui	Internal	UI/UX Lead	Development FE tertunda

---

4. Product Vision

Visi produk menggambarkan kondisi masa depan yang diinginkan setelah produk selesai dikembangkan. Visi ini menjadi panduan arah bagi seluruh tim dan stakeholders.

4.1 Vision Statement

PM Project Manager / Product Owner merumuskan vision statement.

[ISI DI SINI - Tulis vision statement yang:]

• Menggambarkan kondisi ideal masa depan
• Spesifik namun inspiratif
• Mudah diingat dan dikomunikasikan
• Dapat diukur pencapaiannya

FORMAT: "Pada [waktu target], [nama produk] akan menjadi [deskripsi posisi] yang memungkinkan [target audience] untuk [manfaat utama] melalui [cara/capability]."

4.2 Key Vision Elements

[ISI DI SINI - Jabarkan elemen-elemen kunci visi menjadi pilar-pilar strategis:]

4.2.1 [Pilar Visi 1]

[Deskripsikan pilar pertama visi produk]

4.2.2 [Pilar Visi 2]

[Deskripsikan pilar kedua visi produk]

4.2.3 [Pilar Visi 3]

[Deskripsikan pilar ketiga visi produk]

CONTOH:

Pilar 1: Digitalisasi End-to-End

Seluruh proses keuangan internal — dari pengajuan hingga pencairan — berjalan digital tanpa dokumen fisik, mengurangi waktu proses dari hari menjadi jam.

Pilar 2: Transparansi dan Akuntabilitas

Setiap transaksi tercatat secara immutable dengan audit trail lengkap, mendukung kepatuhan regulasi OJK dan audit internal tanpa effort tambahan.

Pilar 3: Data-Driven Decision Making

Dashboard real-time dan laporan otomatis memberikan visibilitas penuh kepada manajemen untuk pengambilan keputusan berbasis data terkini.

4.3 Long-Term Vision

[ISI DI SINI - Jelaskan visi jangka panjang di luar scope saat ini, termasuk:]

• Kemampuan yang akan ditambahkan di masa depan
• Integrasi dengan sistem lain
• Pengembangan teknologi yang direncanakan
• Arsitektur yang mendukung extensibility

CONTOH:

• Fase 2 (6 bulan): Integrasi Core Banking untuk posting jurnal real-time, modul rekening escrow
• Fase 3 (12 bulan): Mobile app native untuk approval on-the-go, notifikasi push
• Jangka panjang: AI-powered anomaly detection untuk deteksi fraud, predictive analytics untuk cash flow forecasting
• Extensibility: Arsitektur plugin-based memungkinkan penambahan modul baru tanpa mengubah core system

---

5. Product Objectives

Tujuan produk harus jelas, terukur, dapat diverifikasi, dan menjadi dasar untuk prioritization, progress tracking, dan evaluasi keberhasilan proyek.

5.1 Functional Objectives

BA Business Analyst mendetailkan tujuan fungsional berdasarkan kebutuhan bisnis.

[ISI DI SINI - Definisikan tujuan fungsional menggunakan format berikut untuk setiap tujuan:]

5.1.1 [Nama Objective 1]

• Deskripsi: [Jelaskan apa yang sistem harus LAKUKAN]
• Acceptance Criteria: [Definisikan kriteria penerimaan yang jelas dan terukur]
• Priority: [High/Medium/Low]

FORMAT OBJECTIVE YANG BAIK: "Sistem harus dapat [aksi] sehingga [pengguna] dapat [manfaat]." Acceptance Criteria harus mengikuti format: "Diberikan [kondisi], ketika [aksi], maka [hasil yang diharapkan]."

CONTOH:

Digitalisasi Proses Persetujuan

• Deskripsi: Sistem harus dapat memproses pengajuan dan persetujuan pembayaran secara digital end-to-end sehingga seluruh unit kerja dapat menyelesaikan siklus persetujuan dalam hitungan jam, bukan hari.
• Acceptance Criteria: Diberikan pengajuan pembayaran yang lengkap, ketika disubmit oleh pemohon, maka notifikasi terkirim ke approver dalam 1 menit dan seluruh siklus persetujuan (hingga 3 level) selesai rata-rata dalam 4 jam.
• Priority: High

5.1.2 [Nama Objective 2]

• Deskripsi: [Jelaskan apa yang sistem harus LAKUKAN]
• Acceptance Criteria: [Definisikan kriteria penerimaan yang jelas dan terukur]
• Priority: [High/Medium/Low]

5.1.3 [Nama Objective 3]

• Deskripsi: [Jelaskan apa yang sistem harus LAKUKAN]
• Acceptance Criteria: [Definisikan kriteria penerimaan yang jelas dan terukur]
• Priority: [High/Medium/Low]

5.2 Non-Functional Objectives

DEV Architect / Lead Developer mendefinisikan tujuan non-fungsional.

5.2.1 Security

[ISI DI SINI - Tujuan keamanan sistem:]

• Kebutuhan autentikasi dan otorisasi
• Kebutuhan enkripsi data
• Kebutuhan audit logging
• Standar kepatuhan keamanan

CONTOH:

• Hanya pengguna berwenang yang dapat mengakses data sesuai perannya (RBAC)
• Data sensitif (NIK, nomor rekening, nominal) terenkripsi baik saat disimpan maupun saat ditransmisikan
• Seluruh aktivitas penting (login, transaksi, perubahan data, approval) tercatat dalam audit log yang tidak dapat diubah
• Sistem memenuhi standar ISO 27001 dan regulasi UU PDP

5.2.2 Performance and Scalability

[ISI DI SINI - Target performa dan skalabilitas:]

• Jumlah pengguna yang didukung (registered & concurrent)
• Target waktu respon (page load, query)
• Kapasitas transaksi per satuan waktu
• Arsitektur yang mendukung scaling

CONTOH:

• 5.000 registered users, 500 concurrent users (peak hours)
• Page load: < 2 detik (standard pages), < 5 detik (dashboard/report)
• API response: < 500ms (95th percentile)
• Kapasitas: 10.000 transaksi per hari, scalable hingga 50.000
• Horizontal scaling via container orchestration (Kubernetes)

5.2.3 Availability and Reliability

[ISI DI SINI - Target ketersediaan dan keandalan:]

• Target uptime (contoh: 99.5% annually)
• Rencana backup dan recovery
• Prosedur failover dan redundancy

CONTOH:

• Sistem tersedia 24/7 dengan target uptime 99.5% per tahun (maks ~44 jam downtime)
• Jika terjadi kegagalan, sistem harus pulih dalam 4 jam (RTO) dengan kehilangan data maksimal 1 jam (RPO)
• Backup otomatis harian dengan retensi 30 hari

5.2.4 Maintainability

[ISI DI SINI - Kebutuhan maintainability:]

• Arsitektur modular
• Version control dan CI/CD
• Kebutuhan environment staging
• Kemampuan rollback

CONTOH:

• Arsitektur modular — setiap modul dapat di-deploy secara independen tanpa downtime modul lain
• CI/CD pipeline aktif — setiap merge ke branch utama otomatis di-build, di-test, dan di-deploy ke staging
• Environment staging yang identik dengan production untuk validasi sebelum release
• Rollback capability — setiap deployment dapat di-rollback ke versi sebelumnya dalam < 15 menit

5.2.5 Usability

BA + UI/UX Business Analyst dan UI/UX Designer mendefinisikan kebutuhan usability.

[ISI DI SINI - Kebutuhan usability:]

• Target user (tingkat literasi teknis)
• Dukungan multi-bahasa (jika diperlukan)
• Optimasi untuk kondisi jaringan (low-bandwidth)
• Dukungan aksesibilitas

CONTOH:

• 80% pengguna baru mampu menyelesaikan pengajuan pembayaran tanpa pelatihan formal
• Bahasa utama: Bahasa Indonesia; bahasa sekunder: English (untuk laporan dan dashboard)
• Responsif di desktop dan tablet; optimasi untuk koneksi minimal 1 Mbps
• WCAG 2.1 Level AA — keyboard navigation, screen reader compatible, contrast ratio ≥ 4.5:1

---

6. Product Scope

Definisi scope yang jelas sangat penting untuk mengelola ekspektasi stakeholders, mengontrol feature creep, dan menetapkan batasan yang jelas untuk kegiatan development, testing, dan acceptance.

6.1 In Scope

PM + BA Project Manager dan Business Analyst mendefinisikan scope.

[ISI DI SINI - Daftarkan secara detail semua yang termasuk dalam scope:]

6.1.1 [Fitur/Modul 1]

[Deskripsikan fitur/modul yang termasuk dalam scope, mencakup:]

• Deskripsi fungsionalitas
• Data yang dikelola
• Proses workflow
• Integration points

6.1.2 [Fitur/Modul 2]

[Deskripsikan fitur/modul berikutnya]

6.1.3 [Fitur/Modul 3]

[Deskripsikan fitur/modul berikutnya]

TIPS: Untuk setiap item in-scope, pastikan memiliki: 1. Deskripsi yang jelas 2. Kriteria penerimaan 3. Estimasi effort 4. Prioritas 5. Dependencies

CONTOH:

Modul Pengajuan & Approval Pembayaran

• Fungsionalitas: Submit pengajuan, multi-level approval (hingga 3 level), pencairan dana, tracking status
• Data: Pengajuan, vendor, dokumen pendukung, history approval
• Workflow: Draft → Submit → Approval L1 → Approval L2 → Approval L3 (jika threshold) → Pencairan
• Integration: Notifikasi email, lookup Master Vendor, cek sisa anggaran

Modul Dashboard & Pelaporan

• Fungsionalitas: Dashboard real-time (KPI keuangan), laporan operasional (harian/mingguan/bulanan), export PDF/Excel
• Data: Agregasi seluruh transaksi dari modul lain
• Workflow: Auto-generate laporan terjadwal, on-demand report builder
• Integration: Data warehouse (DWH) untuk historical analysis

6.2 Out of Scope

[ISI DI SINI - Daftarkan secara eksplisit item yang TIDAK termasuk dalam scope:]

Out of Scope Item	Reason / Planned for Future Phase
[Item 1]	[Alasan tidak termasuk / rencana fase berikutnya]
[Item 2]	[Alasan tidak termasuk / rencana fase berikutnya]
[Item 3]	[Alasan tidak termasuk / rencana fase berikutnya]

CONTOH:

Out of Scope Item	Reason / Planned for Future Phase
Mobile app native (Android/iOS)	Fase 1 fokus web app responsive; mobile native direncanakan fase 2
Migrasi data dari sistem legacy	Dilakukan oleh tim DBA terpisah, bukan bagian dari scope pengembangan aplikasi
Integrasi payment gateway pihak ketiga	Menunggu kontrak vendor selesai, direncanakan Q2 berikutnya
Business process re-engineering	Di luar scope IT; perubahan proses ditangani oleh unit bisnis

6.3 Scope Assumptions

[ISI DI SINI - Daftarkan asumsi yang mendasari definisi scope:]

• [Asumsi 1]
• [Asumsi 2]
• [Asumsi 3]

CONTOH:

• Klien akan menyediakan akses ke seluruh API sistem internal yang perlu diintegrasikan sebelum sprint 2
• Desain UI/UX akan difinalisasi sebelum development dimulai; perubahan desain setelah sprint 3 memerlukan Change Request
• Infrastruktur hosting (server, network, storage) sudah tersedia dan memadai; pengadaan infrastruktur bukan bagian scope
• Business rules untuk threshold approval sudah final dan tidak akan berubah selama fase development

---

7. Stakeholders and Users

Identifikasi ekosistem lengkap stakeholders dan pengguna yang akan berinteraksi dengan, mendapat manfaat dari, atau terpengaruh oleh implementasi produk. Pemahaman ini penting untuk merancang user interface, menentukan access controls, merencanakan program training, dan memastikan sistem memenuhi kebutuhan semua kelompok peserta.

7.1 Internal Stakeholders

BA Business Analyst mengidentifikasi stakeholders internal.

7.1.1 [Stakeholder Group 1]

[ISI DI SINI - Deskripsikan kelompok stakeholder, mencakup:]

• Nama/tipe organisasi atau unit
• Peran dan tanggung jawab dalam proyek
• Tingkat keterlibatan (inform, consult, accountable, responsible)
• Kebutuhan informasi dari sistem
• Akses yang diperlukan

7.1.2 [Stakeholder Group 2]

[ISI DI SINI - Deskripsikan kelompok stakeholder berikutnya]

7.1.3 [Stakeholder Group 3]

[ISI DI SINI - Deskripsikan kelompok stakeholder berikutnya]

CONTOH:

Direktorat Keuangan

• Tipe: Divisi internal klien
• Peran: Sponsor proyek, pemilik anggaran, pengguna utama
• Tingkat keterlibatan: Accountable — bertanggung jawab atas keberhasilan implementasi
• Kebutuhan: Dashboard real-time, laporan keuangan bulanan, audit trail lengkap
• Akses: Full access ke seluruh modul keuangan

Tim IT Internal Klien

• Tipe: Unit pendukung teknis
• Peran: Memaintain sistem setelah go-live, mengelola infrastruktur
• Tingkat keterlibatan: Responsible — melaksanakan operasional harian
• Kebutuhan: Dokumentasi teknis, admin panel, monitoring tools
• Akses: System Administrator access

7.2 External Users

[ISI DI SINI - Identifikasi pengguna eksternal yang akan berinteraksi dengan sistem:]

7.2.1 [User Type 1]

[ISI DI SINI - Deskripsikan tipe pengguna, mencakup:]

• Profil dan karakteristik pengguna
• Kemampuan teknis (literasi digital)
• Interaksi utama dengan sistem
• Pain points dan kebutuhan spesifik

7.2.2 [User Type 2]

[ISI DI SINI - Deskripsikan tipe pengguna berikutnya]

CONTOH:

Vendor / Rekanan

• Profil: Perusahaan penyedia barang/jasa yang menerima pembayaran melalui sistem
• Kemampuan teknis: Bervariasi — sebagian besar mampu mengakses web portal standar
• Interaksi: Submit invoice, tracking status pembayaran, download bukti transfer
• Pain points: Tidak ada visibilitas status pembayaran, harus menghubungi PIC secara manual untuk konfirmasi

7.3 System Administration Users

[ISI DI SINI - Identifikasi pengguna administrasi sistem:]

7.3.1 System Administrator

[Deskripsikan peran System Administrator]

7.3.2 Technical Support Staff

[Deskripsikan struktur help desk dan dukungan teknis]

7.3.3 [Other Admin Roles]

[Deskripsikan peran admin lainnya]

CONTOH:

System Administrator

• Peran: Mengelola konfigurasi sistem, manajemen user & role, monitoring kesehatan sistem
• Profil: Tim IT internal klien, familiar dengan admin panel dan basic troubleshooting
• Akses: Full access ke admin panel, user management, system configuration, log viewer

Help Desk / Technical Support

• Struktur: Tier 1 (vendor — support harian, bug fix), Tier 2 (IT internal klien — eskalasi infrastruktur)
• Channel: Email, ticketing system, WhatsApp group (untuk urgent)
• SLA: Response < 2 jam (critical), < 4 jam (high), < 1 hari kerja (medium/low)

TIPS STAKEHOLDER ANALYSIS: Gunakan framework RACI untuk setiap stakeholder: R = Responsible (melaksanakan), A = Accountable (bertanggung jawab), C = Consulted (dikonsultasikan), I = Informed (diberitahu)

---

8. User Roles and Access Control

Framework Role-Based Access Control (RBAC) menentukan pengguna mana yang dapat mengakses fungsi sistem mana, melihat data mana, dan melakukan operasi mana. RBAC yang baik penting untuk keamanan, privasi data, kepatuhan regulasi, dan efisiensi operasional.

8.1 Proposed User Roles

BA + DEV Business Analyst mendefinisikan peran; Architect mendesain RBAC.

[ISI DI SINI - Daftarkan peran pengguna yang diusulkan, untuk setiap peran sertakan:]

Role Name	Responsibilities	Typical Holders
[Role 1]	[Tanggung jawab]	[Penanggung jawab tipikal]
[Role 2]	[Tanggung jawab]	[Penanggung jawab tipikal]
[Role 3]	[Tanggung jawab]	[Penanggung jawab tipikal]

8.1.1 [Role Name 1]

[ISI DI SINI - Detailkan peran, mencakup:]

• Deskripsi tanggung jawab
• Profil pengguna tipikal
• Scope akses (data dan modul)
• Kebutuhan MFA (mandatory/recommended/optional)

8.1.2 [Role Name 2]

[ISI DI SINI - Detailkan peran berikutnya]

CONTOH:

Role Name	Responsibilities	Typical Holders
System Admin	Konfigurasi sistem, manajemen user & role, monitoring	Tim IT Internal
Approver	Review dan approval pengajuan sesuai threshold	VP, Kepala Divisi
Operator	Input data, submit pengajuan, upload dokumen	Staff operasional
Auditor	View-only akses ke seluruh data dan audit log	Tim Audit Internal
Viewer	Akses read-only ke dashboard dan laporan	Manajemen Senior

Approver

• Deskripsi: Mereview dan menyetujui/menolak pengajuan yang masuk berdasarkan threshold nominal dan kewenangan jabatan
• Profil: VP atau Kepala Divisi dengan kewenangan anggaran
• Scope akses: Hanya pengajuan dalam unit kerja/wilayahnya (jurisdiction-based)
• MFA: Mandatory untuk approval di atas threshold Rp 100 juta

8.2 Access Control Requirements

8.2.1 Role-Based Access Control (RBAC)

[ISI DI SINI - Definisikan mekanisme RBAC:]

• Pengguna dapat memiliki satu atau beberapa peran
• Izin diberikan ke peran, bukan individu pengguna
• Proses peninjauan akses berkala

8.2.2 Granular Permissions

[ISI DI SINI - Definisikan tingkat izin granular, misalnya:]

• None (tidak ada akses)
• View (read-only)
• Create (membuat record baru)
• Edit (mengubah record)
• Delete (menghapus record)
• Approve (menyetujui/menolak)
• Admin (akses administratif penuh)

CONTOH:

Level	Deskripsi	Contoh Penggunaan
None	Tidak ada akses, modul/menu tidak terlihat	Auditor tidak melihat menu Admin
View	Read-only, dapat melihat dan export data	Viewer melihat dashboard tanpa bisa edit
Create	Dapat membuat record baru	Operator membuat pengajuan baru
Edit	Dapat mengubah record milik sendiri atau dalam scope	Operator mengedit draft pengajuan sendiri
Delete	Dapat menghapus/membatalkan record (soft delete)	Admin membatalkan pengajuan yang salah input
Approve	Dapat menyetujui/menolak dengan komentar	Approver menyetujui pengajuan pembayaran
Admin	Full access termasuk konfigurasi dan user management	System Admin mengelola role dan permission

8.2.3 Scope/Jurisdiction Control

[ISI DI SINI - Jelaskan mekanisme pembatasan akses berdasarkan scope:]

• Scope geografis (provinsi, wilayah, cabang)
• Scope organisasional (departemen, unit)
• Scope data (hanya data milik sendiri, tim, atau organisasi)

CONTOH:

Scope Type	Mekanisme	Contoh
Geografis	Filter berdasarkan kode cabang/wilayah user	Regional Manager Jawa Barat hanya melihat data cabang di Jabar
Organisasional	Filter berdasarkan kode unit kerja	Kepala Divisi PKU hanya melihat pengajuan dari divisinya
Data pribadi	Filter berdasarkan creator ID	Operator hanya melihat dan mengedit pengajuan yang ia buat sendiri

8.2.4 Multi-Factor Authentication (MFA)

[ISI DI SINI - Kebutuhan MFA:]

• Peran mana yang wajib MFA
• Metode MFA yang didukung (TOTP, SMS, hardware token)
• Proses enrollment dan recovery

8.2.5 Session Management

[ISI DI SINI - Aturan manajemen sesi:]

• Auto-logout setelah inactivity (contoh: 30 menit)
• Durasi maksimum sesi
• Batas concurrent sessions per user
• Invalidasi sesi saat password/role berubah

CONTOH (Gabungan §8.2.4 + §8.2.5):

• MFA: Wajib untuk role Approver dan Admin; metode TOTP (Google Authenticator / Microsoft Authenticator); enrollment saat pertama kali login; recovery via email + verifikasi identitas oleh Admin
• Session timeout: 30 menit inactivity → auto-logout dengan warning popup 5 menit sebelumnya
• Max session duration: 8 jam (hard limit, wajib re-login)
• Concurrent sessions: Maks 1 session per user; login baru menginvalidasi session lama
• Invalidasi: Session langsung expired saat password diubah, role diubah, atau akun di-nonaktifkan

8.3 Permission Matrix

QA QA menggunakan permission matrix untuk memverifikasi implementasi akses control.

[ISI DI SINI - Buat matrix izin yang memetakan peran ke modul/operasi. Lihat Appendix B untuk format lengkap.]

---

9. Product Modules and Functional Requirements

BA + DEV + QA Semua tim terlibat dalam memastikan kebutuhan fungsional lengkap dan dapat diimplementasikan serta diuji.

Bagian ini merupakan inti dari PRD, menyediakan spesifikasi fungsional detail untuk setiap modul sistem. Untuk setiap modul, bagian ini harus mencakup: tujuan modul, kebutuhan fungsional dengan spesifikasi field-level, process flows, data validation rules, integration points, dan acceptance criteria yang komprehensif.

STRUKTUR PENULISAN KEBUTUHAN FUNGSIONAL: Setiap kebutuhan fungsional harus memiliki: ID unik (contoh: FR-xxx), Deskripsi yang jelas, Input/Output, Business rules / validasi, Error handling, Acceptance criteria.

9.1 [Module 1: Module Name]

Purpose: [ISI DI SINI - Jelaskan tujuan modul]

9.1.1 [Functional Requirement 1]

• ID: FR-001
• Description: [ISI DI SINI - Deskripsikan kebutuhan fungsional]
• Business Rules:
  • [Aturan bisnis 1]
  • [Aturan bisnis 2]
• Validation Rules:
  • [Validasi 1]
  • [Validasi 2]
• Acceptance Criteria: AC-xxx
  • [Kriteria penerimaan 1]
  • [Kriteria penerimaan 2]

9.1.2 [Functional Requirement 2]

• ID: FR-002
• Description: [ISI DI SINI]

9.1.3 [Module 1 Acceptance Criteria]

• AC-001: [Kriteria penerimaan komprehensif untuk modul]

9.2 [Module 2: Module Name]

Purpose: [ISI DI SINI]

9.2.1 [Functional Requirement 1]

• ID: FR-0xx
• Description: [ISI DI SINI]

9.3 [Module 3: Module Name]

Purpose: [ISI DI SINI]

9.3.1 [Functional Requirement 1]

• ID: FR-0xx
• Description: [ISI DI SINI]

TIPS UNTUK DEVELOPER: Gunakan bagian ini sebagai acuan utama untuk: 1. Database modeling (dari data entities dan relationships) 2. API development (dari integration points) 3. Business logic implementation (dari validation rules) 4. Unit testing (dari acceptance criteria)

TIPS UNTUK QA: Gunakan bagian ini untuk: 1. Test scenario dan test cases 2. Acceptance test plan 3. Regression testing scope 4. UAT scenarios

CONTOH (Ilustrasi: Modul Pengajuan Pembayaran):

Modul Pengajuan Pembayaran Operasional

Purpose: Mengelola seluruh siklus pengajuan pembayaran operasional dari submission hingga pencairan dana, termasuk multi-level approval dan integrasi dengan sistem akuntansi.

FR-PAY-001: Submit Pengajuan Pembayaran

• ID: FR-PAY-001
• Description: Sistem harus memungkinkan operator untuk membuat pengajuan pembayaran dengan informasi vendor, nominal, kategori biaya, dan dokumen pendukung.
• Business Rules:
  • Nominal pengajuan tidak boleh melebihi sisa anggaran unit kerja
  • Dokumen pendukung (invoice/kuitansi) wajib di-upload dalam format PDF/JPG (maks 10MB)
  • Nomor pengajuan di-generate otomatis: PAY-[UNIT]-[YYYY]-[NNNN]
• Validation Rules:
  • Nominal > 0 dan format currency IDR
  • Vendor harus terdaftar dalam Master Vendor aktif
  • Tanggal jatuh tempo minimal H+3 dari tanggal pengajuan
• Acceptance Criteria: AC-PAY-001
  • Diberikan operator yang sudah login, ketika mengisi form pengajuan lengkap dan submit, maka pengajuan tersimpan dengan status "Menunggu Approval" dan notifikasi terkirim ke approver level 1
  • Diberikan nominal yang melebihi sisa anggaran, ketika submit, maka sistem menampilkan error "Nominal melebihi sisa anggaran" dan pengajuan tidak tersimpan

---

10. Non-Functional Requirements

DEV + PM Architect mendefinisikan NFR; PM memvalidasi keselarasan dengan tujuan bisnis.

Kebutuhan non-fungsional (NFR) mendefinisikan KUALITAS sistem, bukan apa yang sistem lakukan. NFR yang baik harus spesifik, terukur, dapat diverifikasi, dan realistis.

10.1 Security Requirements

10.1.1 Authentication and Access Control

[ISI DI SINI - Kebutuhan autentikasi dan kontrol akses:]

• Metode autentikasi (username/password, SSO, OAuth, dll.)
• Kebijakan password (panjang, kompleksitas, expiry)
• Account lockout policy
• Multi-factor authentication requirements

CONTOH:

Aspek	Spesifikasi
Metode autentikasi	SSO via OAuth 2.0 + JWT. Integrasi dengan identity provider klien (UIM Next-G)
Password policy	Min 12 karakter, kombinasi huruf besar/kecil/angka/simbol, expiry 90 hari, 10 password history
Account lockout	Lockout setelah 5 failed attempts dalam 30 menit. Unlock otomatis setelah 30 menit atau manual oleh Admin
MFA	Wajib untuk role Approver dan Admin. Metode: TOTP (Google/Microsoft Authenticator). Enrollment saat first login

10.1.2 Data Encryption

[ISI DI SINI - Kebutuhan enkripsi data:]

• Enkripsi data at rest (algoritma, key management)
• Enkripsi data in transit (TLS version, certificate pinning)
• Enkripsi data sensitif di database

CONTOH:

Layer	Algoritma	Scope
In transit	TLS 1.3 (minimum TLS 1.2)	Seluruh komunikasi client-server dan antar-service
At rest (DB)	AES-256	Field sensitif: NIK, nomor rekening, NPWP, nominal transaksi
At rest (file)	AES-256	Dokumen pendukung di object storage (MinIO)
Key management	HashiCorp Vault atau AWS KMS	Rotasi key setiap 12 bulan, separation of duty untuk key access

10.1.3 Audit Logging

[ISI DI SINI - Kebutuhan audit logging:]

• Events yang harus dilog (login, CRUD operations, permission changes)
• Informasi yang dicatat (timestamp, user, IP, action, result)
• Retensi log
• Kebutuhan immutability (log tidak dapat diubah)

CONTOH:

Event Category	Events yang Dicatat	Informasi yang Disimpan
Authentication	Login berhasil/gagal, logout, MFA attempt, session timeout	Timestamp, user ID, IP, user agent, result (success/fail), failure reason
Data Mutation	Create, Update, Delete pada semua entitas bisnis	Timestamp, user ID, entity, record ID, old value, new value, action
Authorization	Access denied, role change, permission grant/revoke	Timestamp, user ID, resource, action attempted, result
System	Deployment, config change, scheduled job execution	Timestamp, actor (user/system), component, change description

Immutability: Append-only storage, hash chain per batch, retensi 3 tahun aktif + 5 tahun arsip. Tidak dapat diubah/dihapus oleh user manapun termasuk System Admin.

10.1.4 Compliance Requirements

[ISI DI SINI - Kebutuhan kepatuhan regulasi:]

• Standar keamanan (ISO 27001, NIST, dll.)
• Regulasi data privacy (GDPR, UU PDP, dll.)
• Kebutuhan sertifikasi

CONTOH:

Regulasi / Standar	Kebutuhan Sistem	Verifikasi
ISO 27001	Access control matrix, audit logging, incident response plan, data classification	Audit internal tahunan
UU PDP (No. 27/2022)	Consent management, hak akses/koreksi/hapus data pribadi, breach notification dalam 72 jam	Privacy impact assessment per modul
POJK Manajemen Risiko TI	Risk assessment, business continuity plan, penetration testing	Laporan kepatuhan triwulanan
OWASP Top 10	Input validation, output encoding, secure session management, CSRF protection	SAST/DAST scan setiap release

10.2 Performance and Scalability Requirements

10.2.1 User Capacity

[ISI DI SINI - Kapasitas pengguna:]

• Total registered users
• Concurrent users (peak)
• Projected growth

CONTOH:

Parameter	Fase 1 (Go-Live)	Proyeksi 2 Tahun	Catatan
Registered users	5.000	10.000	Seluruh karyawan kantor pusat + 40 cabang
Concurrent users (normal)	200-300	500	Jam kerja 08:00-17:00 WIB
Concurrent users (peak)	500	1.000	Akhir bulan (closing period), hari pertama kerja
Growth rate	—	~30% per tahun	Ekspansi cabang baru + digitalisasi unit kerja

10.2.2 Response Time Targets

Operation	Target Response Time	Measurement Condition
[Page load (standard)]	[X detik]	[Kondisi pengukuran]
[Database query (simple)]	[X detik]	[Kondisi pengukuran]
[Report generation]	[X menit]	[Kondisi pengukuran]

CONTOH:

Operation	Target Response Time	Measurement Condition
Page load (standard)	< 2 detik	500 concurrent users, jaringan LAN
Page load (dashboard)	< 5 detik	Dashboard dengan 6+ widget real-time
Database query (simple)	< 200ms	Single table, indexed query
Database query (complex/report)	< 3 detik	Multi-join, aggregate, 1 tahun data
Report generation (PDF)	< 30 detik	Laporan bulanan, max 100 halaman
File upload	< 10 detik	File max 10MB, jaringan 10Mbps
API response (95th percentile)	< 500ms	CRUD operations, normal load

10.2.3 Scalability Architecture

[ISI DI SINI - Kebutuhan skalabilitas arsitektur:]

• Horizontal vs vertical scaling
• Auto-scaling requirements
• Load balancing strategy

CONTOH:

• Scaling strategy: Horizontal scaling — tambah pod/instance, bukan upgrade server. Setiap service stateless, session disimpan di Redis
• Auto-scaling: Kubernetes HPA (Horizontal Pod Autoscaler) — scale up jika CPU > 70% selama 2 menit, scale down jika < 30% selama 5 menit. Min 2 pods, max 10 pods per service
• Load balancing: Nginx Ingress Controller dengan round-robin. Health check endpoint /health setiap 10 detik, unhealthy pod dikeluarkan dari pool setelah 3 failed checks

10.3 Availability and Reliability Requirements

10.3.1 Uptime Targets

[ISI DI SINI - Target uptime:]

• Standard SLA uptime (contoh: 99.5% annually)
• High availability target (contoh: 99.9%)
• Scheduled maintenance windows

CONTOH:

Target	Value	Catatan
Standard uptime	99.5% per tahun	Maks ~44 jam downtime/tahun (termasuk maintenance)
Maintenance window	Minggu 00:00-04:00 WIB	Diumumkan minimal 3 hari sebelumnya
Unplanned downtime limit	Maks 4 jam per insiden	Eskalasi ke steering committee jika melebihi

10.3.2 Backup and Recovery

[ISI DI SINI - Kebutuhan backup dan recovery:]

• Backup frequency (incremental dan full)
• Retention period
• Recovery Time Objective (RTO)
• Recovery Point Objective (RPO)
• Disaster recovery procedures

CONTOH:

Parameter	Target	Detail
Incremental backup	Setiap 1 jam	Transaction log backup
Full backup	Harian, jam 02:00 WIB	Full database + file storage snapshot
Backup retention	30 hari	Rotasi otomatis, oldest dihapus
RTO (Recovery Time Objective)	4 jam	Sistem harus kembali operasional dalam 4 jam setelah kegagalan
RPO (Recovery Point Objective)	1 jam	Data yang hilang maksimal 1 jam terakhir
DR (Disaster Recovery)	Active-passive failover	DR site di lokasi geografis berbeda, DR drill setiap 6 bulan

10.4 Maintainability Requirements

[ISI DI SINI - Kebutuhan maintainability:]

• Modular architecture (independently deployable modules)
• Version control requirements
• CI/CD pipeline requirements
• Staging environment requirements
• Rollback capability
• Documentation requirements (code docs, API docs, runbooks)

CONTOH:

• Modular: Setiap modul (Auth, Payment, Reporting) dapat di-deploy independen; perubahan di modul Payment tidak memerlukan redeploy modul lain
• Version control: GitLab, branch strategy (main → staging → feature branches), merge request wajib 1 reviewer
• CI/CD: Pipeline otomatis: lint → unit test → build → deploy ke staging. Production deploy manual dengan approval
• Staging: Environment staging identik dengan production (OS, DB version, konfigurasi); refresh data mingguan dari anonymized production data
• Rollback: Setiap deployment di-tag; rollback ke versi sebelumnya dalam < 15 menit via CI/CD pipeline
• Dokumentasi: API docs (Swagger/OpenAPI), code docs (inline + README per modul), runbook untuk deployment dan troubleshooting

10.5 Auditability and Traceability Requirements

[ISI DI SINI - Kebutuhan auditability dan traceability:]

• Transaction logging requirements
• Data versioning (track changes to records)
• Tamper evidence requirements
• Reporting untuk audit

CONTOH:

• Transaction logging: Setiap transaksi CRUD dicatat: timestamp, user ID, IP, action (CREATE/UPDATE/DELETE), entity, old value, new value
• Data versioning: Record perubahan disimpan dalam tabel history; setiap update menyimpan snapshot sebelum dan sesudah perubahan
• Tamper evidence: Audit log append-only, tidak dapat diubah atau dihapus oleh user manapun termasuk Admin; hash chain untuk deteksi modifikasi
• Reporting: Laporan audit on-demand: filter by user, tanggal, modul, action type; export ke PDF/Excel untuk kebutuhan audit internal/eksternal

---

11. Data Requirements

BA + DEV Business Analyst mendefinisikan entitas data; Database Architect mendesain model data.

Bagian ini mendefinisikan entitas data inti, aturan validasi, dan kebutuhan integritas data yang akan digunakan di seluruh sistem.

11.1 Core Data Entities

[ISI DI SINI - Daftarkan entitas data inti sistem, untuk setiap entitas sertakan:]

Entity Name	Description	Key Attributes
[Entity 1]	[Deskripsi]	[Atribut kunci: id, name, status, dll.]
[Entity 2]	[Deskripsi]	[Atribut kunci]
[Entity 3]	[Deskripsi]	[Atribut kunci]

11.1.1 [Entity 1] Detail

[ISI DI SINI - Detailkan entitas, mencakup:]

• Field/attribute dengan tipe data
• Constraint (nullable, unique, foreign key)
• Business rules
• Relationships dengan entitas lain

CONTOH:

Entity Name	Description	Key Attributes
Pengajuan Pembayaran	Permohonan pembayaran operasional	id, nomor_pengajuan, pemohon_id, vendor_id, nominal, kategori, status, tanggal_jatuh_tempo
Vendor	Penyedia barang/jasa	id, nama, NPWP, alamat, rekening_bank, status_aktif
Approval History	Riwayat persetujuan per pengajuan	id, pengajuan_id, approver_id, level, keputusan, komentar, timestamp
Dokumen Pendukung	File lampiran pengajuan	id, pengajuan_id, nama_file, tipe_file, ukuran, path_storage

Pengajuan Pembayaran Detail

Field	Type	Constraint	Keterangan
id	UUID	PK, not null	Auto-generated
nomor_pengajuan	VARCHAR(20)	Unique, not null	Format: PAY-[UNIT]-[YYYY]-[NNNN]
pemohon_id	UUID	FK → Users, not null	User yang membuat pengajuan
vendor_id	UUID	FK → Vendor, not null	Vendor penerima pembayaran
nominal	DECIMAL(15,2)	not null, > 0	Dalam IDR
status	ENUM	not null	Draft, Submitted, Approved, Rejected, Paid, Cancelled
created_at	TIMESTAMP	not null	Auto-set saat create

11.2 Data Validation Rules

[ISI DI SINI - Definisikan aturan validasi data:]

Field/Entity	Validation Rule	Error Message
[Field 1]	[Aturan validasi]	[Pesan error]
[Field 2]	[Aturan validasi]	[Pesan error]

CONTOH:

Field/Entity	Validation Rule	Error Message
Email	Format RFC 5322, unique per user	"Format email tidak valid" / "Email sudah terdaftar"
Nominal Pengajuan	Numeric > 0, max 15 digit, format IDR	"Nominal harus lebih dari 0"
Tanggal Jatuh Tempo	Tidak boleh di masa lalu, min H+3 dari submit	"Tanggal jatuh tempo minimal 3 hari dari hari ini"
File Upload	PDF/JPG/PNG, max 10MB, virus scan pass	"Format file tidak didukung" / "Ukuran file melebihi 10MB"
NIP Karyawan	18 digit numerik, exists in Master Karyawan	"NIP tidak ditemukan dalam database karyawan"

11.3 Data Retention and Archival

[ISI DI SINI - Kebutuhan retensi dan arsip data:]

• Kebijakan retensi data per jenis data
• Proses arsip data lama
• Kebijakan penghapusan data (data purging)

CONTOH:

Jenis Data	Retensi Aktif	Arsip	Hapus	Dasar Kebijakan
Data transaksi keuangan	2 tahun	5 tahun (cold storage)	Setelah 7 tahun	Regulasi perbankan
Audit log	3 tahun	5 tahun	Setelah 8 tahun	ISO 27001
Data pengguna	Selama akun aktif	1 tahun setelah nonaktif	Setelah 2 tahun nonaktif	UU PDP
Dokumen pendukung (PDF/scan)	2 tahun	5 tahun (compressed)	Setelah 7 tahun	Kebijakan internal

---

12. Integration Requirements

DEV + BA Architect mendesain integrasi; BA mendefinisikan kebutuhan bisnis integrasi.

Bagian ini mendefinisikan kebutuhan integrasi antara modul internal sistem dan dengan sistem eksternal.

12.1 Internal Module Integrations

[ISI DI SINI - Definisikan integrasi antar modul dalam sistem:]

Source Module	Target Module	Data/Trigger Flow
[Modul A]	[Modul B]	[Deskripsi aliran data]
[Modul C]	[Modul D]	[Deskripsi aliran data]

CONTOH:

Source Module	Target Module	Data/Trigger Flow
Pengajuan Pembayaran	Approval Engine	Trigger approval workflow saat submit; kirim data pengajuan + dokumen pendukung
Approval Engine	Notifikasi	Trigger email/push notification ke approver berikutnya saat status berubah
Approval Engine	Akuntansi	Setelah final approval, auto-generate jurnal pembayaran
Master Data	Seluruh Modul	Referensi data vendor, karyawan, unit kerja, kode GL
Seluruh Modul	Audit Log	Setiap CRUD operation mencatat log secara otomatis

12.2 External Integration Candidates

[ISI DI SINI - Definisikan integrasi dengan sistem eksternal:]

External System	Integration Type	Purpose / Data Exchanged
[Sistem Eksternal 1]	[API/ETL/File]	[Tujuan integrasi]
[Sistem Eksternal 2]	[API/ETL/File]	[Tujuan integrasi]

CONTOH:

External System	Integration Type	Purpose / Data Exchanged
UIM Next-G	REST API (real-time)	Autentikasi user, validasi token, single sign-on
HCS (Human Capital System)	REST API (real-time)	Lookup data karyawan: NIP, nama, jabatan, unit kerja
DWH (Data Warehouse)	ETL (nightly batch)	Push data transaksi harian untuk pelaporan enterprise
Core Banking	REST API (future-ready)	Posting jurnal otomatis, cek saldo rekening (fase 2)
Email Server (SMTP)	SMTP	Kirim notifikasi email untuk approval, reminder, alert

12.3 API Design Principles

[ISI DI SINI - Prinsip desain API:]

• API style (REST, GraphQL, gRPC, SOAP)
• Authentication mechanism (API key, OAuth, JWT)
• Versioning strategy
• Rate limiting requirements
• Error response format

CONTOH:

• API Style: RESTful API dengan JSON payload
• Authentication: OAuth 2.0 + JWT Bearer Token (access token 15 menit, refresh token 7 hari)
• Versioning: URL-based versioning (/api/v1/, /api/v2/)
• Rate Limiting: 100 requests/menit per user, 1000 requests/menit per API key
• Error Response Format:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Nominal melebihi sisa anggaran",
    "details": [
      { "field": "amount", "reason": "exceeds_budget", "limit": 50000000 }
    ]
  }
}

---

13. User Experience Requirements

UI/UX + BA UI/UX Designer mendesain pengalaman pengguna; BA memvalidasi keselarasan dengan kebutuhan bisnis.

Bagian ini mendefinisikan prinsip-prinsip dan kebutuhan pengalaman pengguna (UX) untuk memastikan sistem intuitif, efisien, dan menyenangkan digunakan.

13.1 General UX Principles

13.1.1 Simplicity and Clarity

[ISI DI SINI:]

• Interface yang bersih dan tidak berantakan
• Navigasi yang intuitif dan konsisten
• Terminologi yang familiar bagi pengguna target

CONTOH:

• Interface bersih: maksimal 5-7 elemen aksi per halaman, whitespace yang cukup, grouping visual yang jelas
• Navigasi: sidebar menu maksimal 3 level deep, breadcrumb di setiap halaman, search global di header
• Terminologi: menggunakan bahasa bisnis klien ("Pengajuan Pembayaran" bukan "Payment Request Entity"), tooltip untuk istilah teknis yang tidak dapat dihindari

13.1.2 Guided Workflows

[ISI DI SINI:]

• Step-by-step wizard untuk proses kompleks
• Inline help dan contextual guidance
• Progress indicators untuk multi-step processes

CONTOH:

• Wizard: Pengajuan pembayaran menggunakan wizard 4 langkah (Isi Data → Upload Dokumen → Review → Submit) dengan progress bar dan tombol Back
• Inline help: Setiap field memiliki placeholder text yang menunjukkan format yang diharapkan; field dengan aturan kompleks memiliki tooltip icon (?) yang menjelaskan aturan
• Progress indicator: Approval chain ditampilkan sebagai timeline visual (Step 1: Submitted ✓ → Step 2: Approval L1 [current] → Step 3: Approval L2 → Step 4: Pencairan)

13.1.3 Status Visibility

[ISI DI SINI:]

• Feedback segera untuk setiap aksi pengguna
• Status yang jelas untuk setiap record/proses
• Notification untuk perubahan status penting

CONTOH:

• Feedback: Toast notification hijau untuk aksi berhasil ("Pengajuan berhasil disubmit"), merah untuk gagal ("Nominal melebihi sisa anggaran") — muncul 3 detik lalu auto-dismiss
• Status record: Badge berwarna pada setiap record di tabel — hijau (Approved), kuning (Pending), merah (Rejected), abu-abu (Draft), biru (In Process)
• Notification: Bell icon di header dengan unread count; notifikasi push untuk approval pending, pengajuan ditolak, dan mendekati jatuh tempo

13.1.4 Responsive Design

[ISI DI SINI:]

• Desktop, tablet, dan mobile support
• Optimasi untuk kondisi jaringan terbatas (low-bandwidth)
• Offline capability (jika diperlukan)

CONTOH:

• Desktop (1920px): Layout full dengan sidebar navigation, data table lengkap, dashboard multi-widget
• Tablet (768px): Sidebar collapse ke hamburger menu, tabel horizontal-scrollable, approval action tetap accessible
• Mobile: Tidak diperlukan (sistem internal, akses via desktop/tablet di intranet). Jika dibutuhkan di masa depan, prioritaskan approval flow dan dashboard view
• Low-bandwidth: Lazy loading untuk data table, pagination server-side, image compression untuk dokumen thumbnail

13.1.5 Multi-Language Support

[ISI DI SINI:]

• Bahasa yang didukung
• Fallback language
• Text direction (LTR/RTL jika diperlukan)

CONTOH:

• Bahasa utama: Bahasa Indonesia (default untuk UI, form, validasi, error message)
• Bahasa sekunder: English (untuk laporan PDF, dashboard KPI, API documentation)
• Switcher: Dropdown di header, preference tersimpan per user
• Fallback: Jika terjemahan tidak tersedia, tampilkan dalam Bahasa Indonesia
• Text direction: LTR only (Bahasa Indonesia dan English)

13.1.6 Accessibility

[ISI DI SINI:]

• WCAG compliance level (A, AA, AAA)
• Screen reader compatibility
• Keyboard navigation support
• Color contrast requirements

CONTOH:

• WCAG: Target Level AA compliance
• Screen reader: ARIA labels pada seluruh interactive element, semantic HTML (heading hierarchy, landmark regions)
• Keyboard: Tab navigation untuk seluruh form dan action; Enter/Space untuk submit; Escape untuk close modal; skip-to-content link
• Color contrast: Minimum 4.5:1 untuk normal text, 3:1 untuk large text; status tidak hanya ditunjukkan oleh warna (tambah icon/text label)

13.2 Key User Journeys

[ISI DI SINI - Definisikan user journey kunci untuk setiap tipe pengguna utama:]

13.2.1 [User Type 1] - [Journey Name]

[ISI DI SINI - Deskripsikan user journey, mencakup:]

• Trigger (apa yang memulai journey)
• Steps (langkah-langkah yang dilalui)
• Expected outcome
• Pain points yang perlu diatasi

13.2.2 [User Type 2] - [Journey Name]

[ISI DI SINI - Deskripsikan user journey berikutnya]

CONTOH:

Operator - Pengajuan Pembayaran

• Trigger: Operator menerima invoice dari vendor yang perlu dibayarkan
• Steps:
  1. Login ke sistem → Dashboard menampilkan pengajuan aktif dan draft
  2. Klik "Buat Pengajuan Baru" → Form terbuka dengan field vendor, nominal, kategori, tanggal jatuh tempo
  3. Upload dokumen pendukung (invoice PDF) → Sistem validasi format dan ukuran file
  4. Submit pengajuan → Sistem cek sisa anggaran, generate nomor pengajuan, kirim notifikasi ke Approver
  5. Tracking → Operator dapat melihat status approval di halaman "Pengajuan Saya"
• Expected outcome: Pengajuan tercatat dengan status "Menunggu Approval", approver menerima notifikasi dalam 1 menit
• Pain points yang diatasi: Tidak perlu cetak fisik, tidak perlu antar dokumen manual, tracking real-time menggantikan telepon/WA

---

14. Security, Compliance, and Governance

DEV + PM Security Architect dan Project Manager mendefinisikan framework keamanan.

Bagian ini mendefinisikan framework governance, keamanan, dan kepatuhan yang menjadi landasan operasional sistem.

14.1 Security Governance Framework

14.1.1 Security Standards Alignment

[ISI DI SINI:]

• ISO 27001 alignment
• NIST Cybersecurity Framework alignment
• Industry-specific standards

CONTOH:

Standard	Scope Penerapan	Verifikasi
ISO 27001	Access control, audit logging, data classification, incident management	Audit internal tahunan, sertifikasi eksternal setiap 3 tahun
OWASP Top 10	Secure coding (injection, XSS, CSRF, broken auth, dll.)	SAST scan di CI/CD pipeline, code review checklist
NIST CSF	Risk assessment, continuous monitoring, recovery planning	Quarterly risk review oleh Security Lead
UU PDP (No. 27/2022)	Data pribadi: consent, hak akses/hapus, breach notification	Privacy impact assessment per modul, DPO review

14.1.2 Governance Structure

[ISI DI SINI:]

• Security roles and responsibilities
• Security review process
• Change management security review

CONTOH:

Role	Tanggung Jawab	Frekuensi Review
Security Lead	Menetapkan kebijakan keamanan, review arsitektur, approve exception	Setiap sprint (arsitektur), bulanan (kebijakan)
Tech Lead	Security review pada merge request, memastikan OWASP compliance	Setiap merge request
DevOps	Konfigurasi firewall, TLS, secret management, container scanning	Setiap deployment + mingguan (scan)
QA	Menjalankan DAST scan, validasi security test cases	Setiap release ke staging

Change Management: Setiap perubahan yang menyentuh autentikasi, otorisasi, atau enkripsi wajib security review tambahan oleh Security Lead sebelum merge.

14.2 Monitoring and Logging

14.2.1 Centralized Logging

[ISI DI SINI:]

• Log aggregation platform
• Log categories (application, security, access, error)
• Log retention policy

CONTOH:

Kategori Log	Isi	Contoh Event	Retensi
Application	Error, warning, info dari business logic	Payment submission failed, report generated	1 tahun aktif, 2 tahun arsip
Security	Autentikasi, otorisasi, policy violation	Login failed (5x), unauthorized access attempt, MFA bypass attempt	3 tahun aktif, 5 tahun arsip
Access	Siapa mengakses apa, kapan	User X viewed record Y, User Z exported report	3 tahun aktif, 5 tahun arsip
Audit	CRUD pada data bisnis (immutable)	Created payment #PAY-001, Approved by VP Finance, Amount changed from 10M to 15M	5 tahun aktif, 3 tahun arsip

Platform: ELK Stack (Elasticsearch + Logstash + Kibana). Log dikirim via structured JSON. Immutability dijamin via append-only index + hash chain.

14.2.2 Alert Classification

[ISI DI SINI:]

• Severity levels (Critical, High, Medium, Low)
• Escalation procedures
• Response time requirements per severity

CONTOH:

Severity	Definisi	Contoh	Response Time	Eskalasi
Critical	Sistem down total, data breach, data loss	Production 500 error rate > 50%, unauthorized data export detected	15 menit	Security Lead → CTO → Steering Committee
High	Fitur utama gagal, keamanan terdegradasi	Login service down, SSL certificate expired, audit log gap detected	1 jam	Tech Lead → Security Lead
Medium	Performa menurun, warning threshold terlampaui	Response time > 5 detik, disk usage > 90%, failed login spike	4 jam	Tim on-call (DevOps)
Low	Warning non-kritis, anomali minor	Deprecated API still called, minor log format inconsistency	1 hari kerja	Di-triage di sprint planning

14.3 Incident Response

[ISI DI SINI:]

• Incident response plan overview
• Escalation procedures
• Communication plan during incidents
• Post-incident review process
• Simulation exercise schedule

CONTOH:

Fase Response:

1. Deteksi (0-15 menit) — Alert otomatis dari monitoring → tim on-call di-notify via PagerDuty/WA
2. Triage (15-30 menit) — Identifikasi severity, scope dampak, dan root cause awal
3. Containment (30-60 menit) — Isolasi komponen terdampak, rollback jika perlu, komunikasi ke stakeholder
4. Resolution (sesuai SLA per severity) — Fix root cause, deploy patch, verifikasi
5. Post-Incident Review (dalam 48 jam untuk Critical/High) — Timeline kejadian, root cause analysis, action items, preventive measures

Komunikasi: Status page internal di-update setiap 30 menit selama incident aktif. Stakeholder bisnis diberitahu via email jika dampak > 1 jam.

Simulasi: DR drill setiap 6 bulan (failover ke DR site + restore dari backup). Tabletop exercise untuk incident response setiap quarter.

---

15. Maintenance and Support Requirements

Bagian ini mendefinisikan kebutuhan pemeliharaan preventif dan korektif, serta struktur dukungan operasional untuk memastikan sistem berjalan optimal sepanjang siklus hidupnya.

15.1 Preventive Maintenance

15.1.1 Regular Software Updates

[ISI DI SINI:]

• Frequency of updates
• Deployment windows
• Testing requirements before deployment

CONTOH:

• Frequency: Minor release setiap 2 minggu (sprint cycle), major release setiap quarter, hotfix kapan saja (untuk Critical/High bugs)
• Deployment window: Jumat 22:00-02:00 WIB (low traffic); emergency hotfix: kapan saja dengan approval Tech Lead
• Testing sebelum deploy: Staging testing minimal 3 hari sebelum production; smoke test otomatis post-deploy; rollback otomatis jika smoke test gagal

15.1.2 Security Patching

[ISI DI SINI:]

• SLA for critical security patches
• Vulnerability scanning schedule
• Patch testing procedures

CONTOH:

• SLA: Critical CVE: patch dalam 48 jam; High: patch dalam 1 minggu; Medium/Low: sprint berikutnya
• Vulnerability scanning: Mingguan — Trivy untuk container images, Dependabot untuk library dependencies, OWASP ZAP untuk DAST
• Patch testing: Patch di-test di staging sebelum production; regression test pada modul terdampak; jika urgent, minimal smoke test + approval Security Lead

15.1.3 Infrastructure Health Checks

[ISI DI SINI:]

• Monitoring parameters
• Health check frequency
• Automated alerting thresholds

CONTOH:

Parameter	Threshold Warning	Threshold Critical	Check Interval
CPU usage	> 70%	> 85%	30 detik
Memory usage	> 75%	> 90%	30 detik
Disk usage	> 80%	> 90%	5 menit
Response time (p95)	> 2 detik	> 5 detik	30 detik
Error rate	> 0.5%	> 2%	1 menit
DB connection pool	> 70% used	> 90% used	1 menit

Alerting: Warning → Slack/email ke tim DevOps. Critical → PagerDuty + WA ke on-call engineer + auto-create incident ticket.

15.2 Corrective Maintenance

15.2.1 Bug Reporting and Tracking

[ISI DI SINI:]

• Bug reporting channels
• Bug triage process
• Bug lifecycle workflow

15.2.2 Severity Classification

Severity	Definition	Response Time
Critical	[Definisi]	[X jam]
High	[Definisi]	[X jam]
Medium	[Definisi]	[X jam/hari]
Low	[Definisi]	[X hari]

CONTOH:

Severity	Definition	Response Time	Resolution Time
Critical	Sistem down total, data loss, security breach	30 menit	4 jam
High	Fitur utama tidak berfungsi, workaround tidak ada	2 jam	1 hari kerja
Medium	Fitur terganggu tapi ada workaround, performa menurun	4 jam	3 hari kerja
Low	Bug kosmetik, typo, enhancement request	1 hari kerja	Sprint berikutnya

15.2.3 Fix Deployment Process

[ISI DI SINI:]

• Hotfix vs regular fix process
• Testing requirements
• Rollback procedures

15.3 SLA Requirements

Service Level	Target	Measurement
Help Desk Response	[X menit/jam]	[Cara mengukur]
Issue Resolution (Critical)	[X jam]	[Cara mengukur]
System Uptime	[X%]	[Cara mengukur]

CONTOH:

Service Level	Target	Measurement
Help Desk Response (Critical)	30 menit	Waktu dari tiket masuk hingga first response
Help Desk Response (High)	2 jam	Waktu dari tiket masuk hingga first response
Issue Resolution (Critical)	4 jam	Waktu dari tiket masuk hingga fix deployed
Issue Resolution (High)	1 hari kerja	Waktu dari tiket masuk hingga fix deployed
System Uptime	99.5% per tahun	Monitoring otomatis (uptime robot / Prometheus)
Scheduled Maintenance	Maks 4 jam/bulan	Maintenance window yang disetujui

---

16. Reporting Requirements

BA + PM Business Analyst mendefinisikan kebutuhan laporan; PM memvalidasi keselarasan dengan kebutuhan governance.

Bagian ini mendefinisikan kebutuhan laporan dan dashboard untuk manajemen operasional, kepatuhan, dan pengambilan keputusan.

16.1 Operational Reports

[ISI DI SINI - Laporan operasional harian/bulanan:]

Report Name	Frequency	Audience	Key Metrics
[Laporan 1]	[Harian/Mingguan/Bulanan]	[Audience]	[Metrik utama]
[Laporan 2]	[Harian/Mingguan/Bulanan]	[Audience]	[Metrik utama]

CONTOH:

Report Name	Frequency	Audience	Key Metrics
Laporan Transaksi Harian	Harian	Finance Manager	Total transaksi, nominal, status (approved/pending/rejected)
Rekapitulasi Anggaran	Mingguan	VP Finance, Kepala Divisi	Realisasi vs anggaran per unit kerja, % terpakai
Aging Report Uang Muka	Bulanan	Finance, Audit	Outstanding uang muka > 30 hari, > 60 hari, > 90 hari
Laporan SLA Approval	Mingguan	PM, Management	Rata-rata waktu approval, % SLA terpenuhi, bottleneck unit

16.2 Compliance Reports

[ISI DI SINI - Laporan kepatuhan/regulasi:]

• [Laporan kepatuhan 1] - [Tujuan]
• [Laporan kepatuhan 2] - [Tujuan]

CONTOH:

• Laporan Audit Trail Bulanan — Rekap seluruh aktivitas user: login, transaksi, perubahan data, approval. Untuk kepatuhan POJK dan audit internal
• Laporan Segregation of Duty — Daftar user yang memiliki role conflicting (submitter + approver). Untuk validasi SoD compliance
• Laporan Data Privacy — Rekap permintaan akses/hapus data pribadi, consent status. Untuk kepatuhan UU PDP
• Laporan Failed Login Attempts — Daftar percobaan login gagal > threshold per user/IP. Untuk deteksi brute force dan security monitoring

16.3 Executive Dashboards

[ISI DI SINI - Dashboard eksekutif:]

16.3.1 [Dashboard Name 1]

[ISI DI SINI - Definisikan dashboard, mencakup:]

• Audience
• KPIs yang ditampilkan
• Filter dan parameter
• Refresh frequency

16.3.2 [Dashboard Name 2]

[ISI DI SINI - Definisikan dashboard berikutnya]

CONTOH:

Dashboard Eksekutif Keuangan

• Audience: Direksi, VP Finance
• KPIs: Total transaksi bulan ini, realisasi anggaran (%), outstanding uang muka, rata-rata waktu approval, top 5 unit kerja by volume
• Filter: Periode (harian/mingguan/bulanan/tahunan), unit kerja, kategori biaya
• Refresh: Real-time (data berubah saat transaksi terjadi)

Dashboard Monitoring Operasional

• Audience: Finance Manager, Kepala Unit
• KPIs: Antrian approval pending, pengajuan mendekati jatuh tempo, transaksi ditolak hari ini, SLA compliance rate
• Filter: Unit kerja (auto-filter berdasarkan login user), status, prioritas
• Refresh: Real-time

---

17. Acceptance Criteria and Definition of Done

QA + PM + DEV Semua tim berkontribusi pada definisi kriteria penerimaan dan definition of done.

Bagian ini mendefinisikan kriteria penerimaan di tingkat modul dan sistem, serta Definition of Done yang menjadi acuan bersama bahwa sebuah fitur atau requirement telah selesai sepenuhnya.

17.1 Module-Level Acceptance Criteria

[ISI DI SINI - Untuk setiap modul utama, definisikan acceptance criteria:]

17.1.1 [Module 1] Acceptance Criteria

• AC-001: [Kriteria penerimaan spesifik yang dapat diuji]
• AC-002: [Kriteria penerimaan spesifik yang dapat diuji]
• AC-003: [Kriteria penerimaan spesifik yang dapat diuji]

17.1.2 [Module 2] Acceptance Criteria

• AC-0xx: [Kriteria penerimaan]

CONTOH:

Modul Pengajuan Pembayaran — Acceptance Criteria

• AC-PAY-001: Operator dapat membuat pengajuan dengan semua field mandatory terisi, upload dokumen, dan submit berhasil dalam < 5 menit
• AC-PAY-002: Sistem menolak pengajuan yang melebihi sisa anggaran unit kerja dengan pesan error yang jelas
• AC-PAY-003: Notifikasi email terkirim ke approver level 1 dalam < 1 menit setelah submit
• AC-PAY-004: Approver dapat menyetujui/menolak pengajuan dengan komentar, dan status terupdate secara real-time
• AC-PAY-005: Audit trail lengkap mencatat seluruh perubahan status (submit, approve, reject, revise) dengan timestamp dan user ID

17.2 System-Level Acceptance Criteria

[ISI DI SINI - Kriteria penerimaan di tingkat sistem keseluruhan:]

• Selenium/end-to-end tests pass untuk critical user journeys
• Performance benchmarks terpenuhi untuk load X concurrent users
• Security scan (SAST/DAST) tidak menemukan vulnerability Critical/High
• Accessibility audit mencapai target WCAG level
• Cross-browser dan cross-device testing selesai
• User acceptance testing (UAT) oleh business users selesai dan disetujui

17.3 Definition of Done

Definition of Done (DoD) adalah checklist yang harus dipenuhi oleh setiap requirement/feature sebelum dapat dianggap selesai:

No	Criteria	Responsible	Verification
1	Code implemented following coding standards	Developer	Code review
2	Unit tests written and passing (minimum X% coverage)	Developer	Test report
3	Integration tests passing	Developer	CI/CD pipeline
4	Functional testing completed by QA	QA	Test report
5	Acceptance criteria verified	QA + BA	Sign-off
6	Documentation updated (technical + user)	Technical Writer	Doc review
7	UX review completed	UI/UX Designer	Review sign-off
8	Security review completed	Security	Security sign-off
9	Performance benchmarks met	QA + Developer	Perf report
10	Deployed to staging and verified	DevOps	Staging test

---

18. Implementation Roadmap

PM Project Manager membuat dan mengelola roadmap implementasi.

Roadmap implementasi menyediakan rencana fase demi fase untuk pengembangan, pengujian, dan deployment sistem.

18.1 Phase 1: [Phase Name]

• Timeline: [ISI DI SINI - Perkiraan timeline]
• Deliverables:
  • [Deliverable 1]
  • [Deliverable 2]
• Success Criteria: [ISI DI SINI - Kriteria keberhasilan fase]

18.2 Phase 2: [Phase Name]

• Timeline: [ISI DI SINI]
• Deliverables:
  • [Deliverable 1]
  • [Deliverable 2]

18.3 Phase 3: [Phase Name]

• Timeline: [ISI DI SINI]
• Deliverables:
  • [Deliverable 1]
  • [Deliverable 2]

TIPS ROADMAP: Setiap fase harus memiliki: 1. Timeline yang realistis 2. Deliverables yang spesifik dan terukur 3. Dependencies dengan fase lain 4. Resource requirements 5. Risk mitigations 6. Go/No-go criteria

CONTOH:

Fase	Nama Fase	Durasi	Timeline	Deliverable Utama
1	Requirement & Design	6 minggu	01/01 - 14/02	PRD final, SDD, UI/UX mockup, API contract
2	Development Sprint 1-4	8 minggu	15/02 - 11/04	Core modules (Auth, Master Data, Submission)
3	Development Sprint 5-8	8 minggu	12/04 - 06/06	Advanced modules (Approval, Reporting, Integration)
4	SIT & Bug Fixing	4 minggu	07/06 - 04/07	Test report, 0 critical/high bugs
5	UAT & Go-Live Prep	4 minggu	05/07 - 01/08	UAT sign-off, deployment runbook, training
6	Go-Live & Warranty	4 minggu	02/08 - 29/08	Production release, 24/7 monitoring, support

18.4 Infrastructure Requirements

[ISI DI SINI - Kebutuhan infrastruktur:]

• Server/Cloud requirements
• Database requirements
• Network requirements
• Security infrastructure
• Monitoring and logging infrastructure

CONTOH:

Komponen	Spesifikasi	Jumlah	Catatan
Application Server	4 vCPU, 8GB RAM, 100GB SSD	3 (min 2 active + 1 standby)	Kubernetes worker nodes
Database Server	8 vCPU, 32GB RAM, 500GB SSD (RAID 10)	2 (primary + replica)	SQL Server / PostgreSQL
Redis (Cache & Session)	2 vCPU, 4GB RAM	2 (primary + replica)	Session store, query cache
Object Storage (MinIO)	1TB	1 cluster	Dokumen pendukung, laporan PDF
Load Balancer	Nginx Ingress	2 (active-passive)	SSL termination, rate limiting
Monitoring	ELK Stack (Elasticsearch 3-node, Logstash, Kibana)	1 cluster	Centralized logging + alerting
Network	VLAN terpisah untuk app/db/management, firewall antar tier	—	Zero-trust antar service
Backup Storage	2TB NAS / cloud cold storage	1	30 hari retention, offsite DR

---

19. Risks, Assumptions, and Dependencies

PM Project Manager bertanggung jawab atas manajemen risiko dan identifikasi asumsi/dependencies.

Bagian ini mendokumentasikan risiko, asumsi, dan dependencies yang dapat mempengaruhi keberhasilan proyek.

19.1 Key Assumptions

[ISI DI SINI - Daftarkan asumsi kunci yang mendasari rencana proyek:]

No	Assumption	Impact if Invalid	Mitigation
1	[Asumsi 1]	[Dampak]	[Mitigasi]
2	[Asumsi 2]	[Dampak]	[Mitigasi]
3	[Asumsi 3]	[Dampak]	[Mitigasi]

CONTOH:

No	Assumption	Impact if Invalid	Mitigation
1	API sistem eksternal (UIM, HCS) tersedia dan terdokumentasi sebelum sprint 2	Delay integrasi, modul login tidak dapat dikembangkan	Early API exploration sprint 1, mock API untuk parallel dev
2	Infrastruktur hosting sudah tersedia (server, DB, network)	Development selesai tapi tidak bisa deploy ke staging	Koordinasi dengan IT klien dari kickoff, fallback ke cloud sementara
3	Business rules approval threshold sudah final	Workflow approval harus di-rework jika berubah	Lock business rules di BRD sign-off, CR process untuk perubahan

19.2 Key Dependencies

[ISI DI SINI - Daftarkan dependencies kunci:]

No	Dependency	Type	Owner	Target Date
1	[Dependensi 1]	[Internal/External]	[Penanggung jawab]	[Tanggal target]
2	[Dependensi 2]	[Internal/External]	[Penanggung jawab]	[Tanggal target]

CONTOH:

No	Dependency	Type	Owner	Target Date
1	API documentation UIM Next-G	External	Tim IT Klien	Sprint 1
2	Finalisasi desain UI/UX (Figma)	Internal	UI/UX Lead	Minggu ke-4
3	Akses ke staging environment klien	External	Tim IT Klien	Sprint 3
4	Data master vendor dan karyawan (seed data)	External	PIC Unit Kerja Klien	Sprint 2
5	Approval threshold rules dari VP Finance	External	VP Finance	Sprint 1

19.3 Key Risks

[ISI DI SINI - Daftarkan risiko kunci dengan assessment dan mitigation plan:]

No	Risk	Probability	Impact	Score	Mitigation Plan
1	[Risiko 1]	[High/Med/Low]	[High/Med/Low]	[H/M/L]	[Rencana mitigasi]
2	[Risiko 2]	[High/Med/Low]	[High/Med/Low]	[H/M/L]	[Rencana mitigasi]
3	[Risiko 3]	[High/Med/Low]	[High/Med/Low]	[H/M/L]	[Rencana mitigasi]

RISK SCORING: Risk Score = Probability x Impact. High-High = Critical (butuh perhatian segera), High-Medium atau Medium-High = High Risk, Medium-Medium = Moderate, Low-Low = Low (monitor saja).

CONTOH:

No	Risk	Probability	Impact	Score	Mitigation Plan
1	Integrasi dengan sistem legacy gagal atau tidak stabil	High	High	Critical	Early integration testing di sprint 1, dedicated integration team, mock API untuk parallel development
2	Performance tidak memenuhi target pada concurrent users tinggi	Medium	High	High	Load testing sejak sprint 3, database indexing optimization, caching layer (Redis)
3	User resistance — pengguna lebih nyaman dengan sistem lama	High	Medium	High	Program change management, user champion di tiap unit, pilot rollout sebelum full launch
4	Keterlambatan approval dokumen dari stakeholder klien	Medium	Medium	Moderate	Deadline approval di milestone, eskalasi ke steering committee jika terlambat > 3 hari
5	Perubahan regulasi selama pengembangan	Low	High	Moderate	Monitor update regulasi bulanan, arsitektur modular untuk absorb changes

---

Appendix A: Daftar Istilah dan Akronim

Istilah / Akronim	Definisi
PRD	Product Requirements Document — dokumen spesifikasi kebutuhan produk
BRD	Business Requirements Document — dokumen kebutuhan bisnis
FR	Functional Requirement — kebutuhan fungsional
NFR	Non-Functional Requirement — kebutuhan non-fungsional
AC	Acceptance Criteria — kriteria penerimaan
RBAC	Role-Based Access Control — kontrol akses berbasis peran
MFA	Multi-Factor Authentication — autentikasi multi-faktor
SLA	Service Level Agreement — perjanjian tingkat layanan
RTO	Recovery Time Objective — target waktu pemulihan
RPO	Recovery Point Objective — target titik pemulihan
UAT	User Acceptance Testing — pengujian penerimaan pengguna
CI/CD	Continuous Integration / Continuous Deployment
SSO	Single Sign-On — autentikasi terpusat
RACI	Responsible, Accountable, Consulted, Informed — framework pembagian tanggung jawab
DoD	Definition of Done — definisi selesai
[ISI DI SINI]	Penanda placeholder yang harus diisi sesuai konteks proyek

---

Appendix B: Template Permission Matrix

Template matriks izin ini digunakan untuk memetakan peran pengguna ke modul/operasi sistem. Gunakan tabel ini sebagai acuan untuk mendefinisikan akses kontrol granular di bagian 8.3.

Panduan Pengisian

1. Kolom pertama: Daftarkan setiap modul/fitur sistem dari bagian 9 (Product Modules)
2. Baris operasi: Untuk setiap modul, buat baris per operasi sesuai level granular dari bagian 8.2.2
3. Kolom peran: Satu kolom per peran dari bagian 8.1 (Proposed User Roles)
4. Isi sel: Gunakan tanda izin sesuai legenda di bawah

Legenda

Simbol	Arti
✓	Diizinkan (full access untuk operasi ini)
✗	Tidak diizinkan
○	Terbatas — hanya data milik sendiri (own data only)
△	Terbatas — hanya dalam scope unit/wilayah (jurisdiction-based, lihat bagian 8.2.3)
◈	Memerlukan MFA (lihat bagian 8.2.4)
—	Tidak berlaku (operasi tidak relevan untuk modul ini)

Template Matriks

[ISI DI SINI - Sesuaikan modul, operasi, dan peran dengan konteks proyek]

Modul / Fitur	Operasi	[Role 1]	[Role 2]	[Role 3]	[Role 4]	System Admin
[Modul 1]	View	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Create	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Edit	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Delete	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓ ◈
	Approve	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
[Modul 2]	View	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Create	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Edit	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Delete	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓ ◈
	Approve	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
[Modul 3]	View	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Create	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Edit	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓
	Delete	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓ ◈
	Approve	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	[✓/✗/○/△]	✓

TIPS: 1. Tambahkan baris modul sesuai jumlah modul di bagian 9. 2. Tambahkan kolom peran sesuai jumlah peran di bagian 8.1. 3. Untuk operasi yang memerlukan approval chain, gunakan catatan kaki untuk menjelaskan alur persetujuan. 4. Review matriks ini bersama stakeholder keamanan sebelum finalisasi.

Contoh Pengisian

Modul / Fitur	Operasi	Field Officer	Regional Manager	Director	System Admin
Registrasi Dokumen	View	○	△	✓	✓
	Create	✓	✗	✗	✓
	Edit	○	✗	✗	✓
	Delete	✗	✗	✗	✓ ◈
	Approve	✗	△	✓	✓
Laporan	View	○	△	✓	✓
	Create	✓	✓	✗	✓
	Edit	○	○	✗	✓
	Delete	✗	✗	✗	✓ ◈
	Export	○	△	✓	✓
Manajemen Pengguna	View	✗	✗	✗	✓
	Create	✗	✗	✗	✓ ◈
	Edit	✗	✗	✗	✓ ◈
	Delete	✗	✗	✗	✓ ◈
	Assign Role	✗	✗	✗	✓ ◈

Keterangan contoh: ○ = Field Officer hanya melihat/mengedit data yang ia buat sendiri. △ = Regional Manager melihat/menyetujui data dalam wilayah kerjanya. ◈ = Operasi kritis yang memerlukan MFA.

---

Hanya digunakan untuk kalangan internal PT. Tristar Surya Gemilang dan tidak untuk didistribusikan secara umum.