D1041231091-WebGIS-All/05/SKPL_SRS_WEBGIS_POVERTY_MAPPING_PROJECT_05.md

SKPL / SRS WEBGIS POVERTY MAPPING PROJECT 05

Nama Dokumen: Spesifikasi Kebutuhan Perangkat Lunak / Software Requirements Specification
Nama Sistem: WebGIS Poverty Mapping
Versi: 1.0
Teknologi: PHP Native, MySQL/MariaDB, Leaflet.js, HTML, CSS, JavaScript Vanilla
Lingkungan Pengembangan: Laragon Localhost dan Hosting cPanel

---

1. Pendahuluan

1.1 Tujuan Dokumen

Dokumen ini menjelaskan kebutuhan perangkat lunak untuk aplikasi WebGIS Poverty Mapping Project 05. Dokumen ini dapat digunakan sebagai acuan pengembangan, pengujian, instalasi, dan evaluasi aplikasi.

1.2 Ruang Lingkup Sistem

WebGIS Poverty Mapping adalah aplikasi berbasis web untuk memetakan rumah ibadah dan penerima bantuan. Sistem digunakan untuk membantu proses pendataan, validasi, pengelolaan program bantuan, penyaluran bantuan, dan pelaporan penerima yang sudah atau belum memperoleh bantuan.

Sistem memiliki fitur utama:

1. Login dan manajemen role pengguna.
2. Registrasi akun penerima.
3. Pengelolaan akun pengguna.
4. Pemetaan rumah ibadah dan penerima bantuan menggunakan Leaflet.
5. Pengajuan dan persetujuan rumah ibadah.
6. Pengajuan dan persetujuan penerima bantuan.
7. Sinkronisasi penerima ke rumah ibadah terdekat dalam radius 300 meter.
8. Pengelolaan program bantuan.
9. Pencatatan penyaluran bantuan.
10. Laporan penyaluran bantuan per periode.
11. Riwayat status dan penyaluran.
12. Pengajuan dan persetujuan hapus marker/pin.

1.3 Definisi Istilah

Istilah	Definisi
WebGIS	Sistem informasi geografis berbasis web.
Rumah Ibadah	Entitas pemberi/penyalur bantuan yang memiliki lokasi pada peta.
Penerima	Pengguna atau warga yang mengajukan bantuan dan memiliki titik lokasi.
Super Admin	Pengguna dengan akses tertinggi.
Admin Rumah Ibadah	Pengguna yang mengelola satu atau lebih rumah ibadah.
Radius 300 Meter	Jarak maksimal penerima agar dapat dikaitkan dengan rumah ibadah.
Marker	Titik rumah ibadah pada peta.
Pin	Titik penerima pada peta.
Program Bantuan	Program penyaluran bantuan pada periode tertentu.
Penyaluran Bantuan	Catatan pemberian bantuan kepada penerima.
SKPL	Spesifikasi Kebutuhan Perangkat Lunak.
SRS	Software Requirements Specification.

1.4 Referensi Teknologi

Sistem dibangun menggunakan:

1. PHP Native tanpa framework.
2. MySQL/MariaDB sebagai basis data.
3. Leaflet.js sebagai library peta.
4. HTML, CSS, dan JavaScript Vanilla.
5. AJAX/fetch API untuk pertukaran data dengan file PHP backend.
6. Laragon sebagai lingkungan localhost.
7. cPanel sebagai contoh lingkungan hosting.

---

2. Deskripsi Umum Sistem

2.1 Perspektif Produk

Aplikasi ini merupakan sistem mandiri berbasis web yang berjalan pada server PHP dan database MySQL/MariaDB. Pengguna mengakses aplikasi melalui browser. Data spasial berupa latitude dan longitude ditampilkan menggunakan Leaflet.js.

2.2 Fungsi Umum Produk

Sistem menyediakan fungsi:

1. Autentikasi pengguna.
2. Otorisasi berdasarkan role.
3. Pengelolaan data pengguna.
4. Pengelolaan titik rumah ibadah.
5. Pengelolaan titik penerima bantuan.
6. Sinkronisasi area penerima dengan rumah ibadah.
7. Pengelolaan program bantuan.
8. Pencatatan penyaluran bantuan.
9. Pelaporan penerima sudah/belum diberi bantuan.
10. Riwayat perubahan status.

2.3 Kelas Pengguna

2.3.1 Super Admin

Super Admin adalah pengguna dengan hak akses penuh. Super Admin dapat mengelola semua akun, rumah ibadah, penerima, program bantuan, penyaluran bantuan, laporan, dan persetujuan hapus marker/pin.

2.3.2 Admin Rumah Ibadah

Admin Rumah Ibadah adalah pengguna yang mengelola satu atau lebih rumah ibadah. Admin dapat mengelola penerima yang masuk dalam wilayah rumah ibadahnya, membuat program bantuan, mencatat penyaluran, dan melihat laporan sesuai data miliknya.

2.3.3 Penerima

Penerima adalah pengguna yang dapat registrasi, login, mengajukan pin lokasi rumah, melihat status pengajuan, melihat riwayat bantuan, dan mengajukan hapus pin miliknya.

2.4 Batasan Sistem

1. Sistem menggunakan PHP Native tanpa framework.
2. Sistem menggunakan MySQL/MariaDB.
3. Sistem menggunakan Leaflet CDN sehingga peta membutuhkan koneksi internet.
4. Radius tanggung jawab rumah ibadah ditetapkan 300 meter.
5. Sistem tidak memakai API geocoding berbayar.
6. Sistem tidak menyediakan upload dokumen identitas.
7. Sistem tidak menyediakan notifikasi email/WhatsApp otomatis.
8. Sistem tidak menyediakan pencetakan laporan PDF otomatis.

2.5 Asumsi dan Ketergantungan

1. Browser pengguna mendukung JavaScript.
2. Server mendukung PHP dan MySQL/MariaDB.
3. Database sudah diimport sebelum aplikasi dijalankan.
4. File koneksi.php sudah disesuaikan dengan konfigurasi database.
5. Leaflet CDN dapat diakses dari jaringan pengguna.

---

3. Aktor Sistem

Kode	Aktor	Deskripsi
A-01	Super Admin	Pengelola utama sistem.
A-02	Admin Rumah Ibadah	Pengelola rumah ibadah dan penyaluran bantuan.
A-03	Penerima	Pengguna yang mengajukan dan menerima bantuan.

---

4. Kebutuhan Fungsional

4.1 Autentikasi dan Akun

Kode	Kebutuhan	Aktor	Prioritas
FR-01	Sistem harus menyediakan login menggunakan username dan password.	Semua aktor	Tinggi
FR-02	Sistem harus menolak login akun yang tidak aktif.	Semua aktor	Tinggi
FR-03	Sistem harus menyediakan logout.	Semua aktor	Tinggi
FR-04	Sistem harus menyimpan password menggunakan hash.	Sistem	Tinggi
FR-05	Sistem harus menyediakan registrasi akun penerima.	Penerima	Tinggi
FR-06	Sistem harus mengizinkan super admin membuat akun admin rumah ibadah dan penerima.	Super Admin	Tinggi
FR-07	Sistem harus mengizinkan admin rumah ibadah membuat akun penerima.	Admin Rumah Ibadah	Sedang
FR-08	Sistem harus menyediakan fitur edit akun.	Super Admin, Admin Rumah Ibadah	Sedang
FR-09	Sistem harus menonaktifkan akun yang sudah punya relasi data jika tidak dapat dihapus permanen.	Super Admin, Admin Rumah Ibadah	Tinggi

4.2 Peta WebGIS

Kode	Kebutuhan	Aktor	Prioritas
FR-10	Sistem harus menampilkan peta menggunakan Leaflet.	Semua aktor	Tinggi
FR-11	Sistem harus menampilkan marker rumah ibadah sesuai hak akses.	Semua aktor	Tinggi
FR-12	Sistem harus menampilkan pin penerima sesuai hak akses.	Semua aktor	Tinggi
FR-13	Sistem harus menampilkan lingkaran radius 300 meter untuk rumah ibadah aktif.	Semua aktor	Tinggi
FR-14	Sistem harus menyediakan popup detail pada marker/pin.	Semua aktor	Sedang
FR-15	Sistem harus memungkinkan input lokasi berdasarkan klik pada peta.	Semua aktor sesuai role	Tinggi

4.3 Pengelolaan Rumah Ibadah

Kode	Kebutuhan	Aktor	Prioritas
FR-16	Sistem harus mengizinkan super admin menambah rumah ibadah.	Super Admin	Tinggi
FR-17	Sistem harus mengizinkan admin rumah ibadah mengajukan rumah ibadah.	Admin Rumah Ibadah	Tinggi
FR-18	Sistem harus menyediakan status rumah ibadah: menunggu, diterima, ditolak.	Sistem	Tinggi
FR-19	Sistem harus mengizinkan super admin menyetujui/menolak rumah ibadah.	Super Admin	Tinggi
FR-20	Sistem harus menghubungkan rumah ibadah dengan akun admin rumah ibadah.	Super Admin	Tinggi
FR-21	Sistem harus mendukung satu admin mengelola lebih dari satu rumah ibadah.	Admin Rumah Ibadah	Tinggi
FR-22	Sistem harus melepas atau menyinkronkan ulang penerima jika rumah ibadah ditolak atau dihapus.	Sistem	Tinggi

4.4 Pengelolaan Penerima Bantuan

Kode	Kebutuhan	Aktor	Prioritas
FR-23	Sistem harus mengizinkan penerima mengajukan lokasi dirinya sendiri.	Penerima	Tinggi
FR-24	Sistem harus mengizinkan super admin/admin rumah ibadah menambahkan penerima berdasarkan username penerima.	Super Admin, Admin Rumah Ibadah	Tinggi
FR-25	Sistem harus menyimpan data nama, NIK, nomor HP, alamat, pekerjaan, penghasilan, tanggungan, kondisi rumah, jenis bantuan, latitude, dan longitude.	Sistem	Tinggi
FR-26	Sistem harus menyediakan status penerima: menunggu, diterima, ditolak, dibatalkan.	Sistem	Tinggi
FR-27	Sistem harus mengizinkan super admin menyetujui, menolak, mereset, atau membatalkan penerima.	Super Admin	Tinggi
FR-28	Sistem harus mengizinkan admin rumah ibadah menyetujui/menolak penerima dalam wilayahnya.	Admin Rumah Ibadah	Tinggi
FR-29	Sistem harus mencegah admin rumah ibadah mengembalikan status ke menunggu.	Admin Rumah Ibadah	Tinggi
FR-30	Sistem harus mencegah admin rumah ibadah membatalkan penerima yang sudah diterima.	Admin Rumah Ibadah	Tinggi
FR-31	Sistem harus membatasi satu akun penerima hanya memiliki satu pin aktif.	Sistem	Tinggi

4.5 Sinkronisasi Radius

Kode	Kebutuhan	Aktor	Prioritas
FR-32	Sistem harus menghitung jarak penerima ke rumah ibadah menggunakan koordinat.	Sistem	Tinggi
FR-33	Sistem harus mengaitkan penerima ke rumah ibadah terdekat dalam radius 300 meter.	Sistem	Tinggi
FR-34	Sistem harus membiarkan penerima belum terhubung jika tidak ada rumah ibadah dalam radius 300 meter.	Sistem	Sedang
FR-35	Sistem harus menyinkronkan ulang penerima saat rumah ibadah disetujui.	Sistem	Tinggi
FR-36	Sistem harus menyinkronkan ulang penerima saat lokasi penerima berubah.	Sistem	Tinggi
FR-37	Sistem harus memilih rumah ibadah paling dekat jika radius beberapa rumah ibadah saling beririsan.	Sistem	Tinggi

4.6 Pengajuan dan Persetujuan Hapus Marker/Pin

Kode	Kebutuhan	Aktor	Prioritas
FR-38	Sistem harus mengizinkan super admin menghapus marker rumah ibadah secara langsung dari peta aktif.	Super Admin	Tinggi
FR-39	Sistem harus mengizinkan super admin menghapus pin penerima secara langsung dari peta aktif.	Super Admin	Tinggi
FR-40	Sistem harus mengizinkan admin rumah ibadah mengajukan hapus rumah ibadah miliknya.	Admin Rumah Ibadah	Sedang
FR-41	Sistem harus mengizinkan admin rumah ibadah mengajukan hapus pin penerima yang dikelola.	Admin Rumah Ibadah	Sedang
FR-42	Sistem harus mengizinkan penerima mengajukan hapus pin miliknya sendiri.	Penerima	Sedang
FR-43	Sistem harus menyediakan panel persetujuan hapus marker/pin untuk super admin.	Super Admin	Tinggi
FR-44	Sistem harus menyembunyikan marker/pin yang sudah disetujui penghapusannya.	Sistem	Tinggi

4.7 Program Bantuan

Kode	Kebutuhan	Aktor	Prioritas
FR-45	Sistem harus mengizinkan super admin/admin rumah ibadah membuat program bantuan.	Super Admin, Admin Rumah Ibadah	Tinggi
FR-46	Program bantuan harus memiliki rumah ibadah, nama program, jenis bantuan, bulan, tahun, target frekuensi, nominal/item, deskripsi, dan status.	Sistem	Tinggi
FR-47	Sistem harus mengizinkan penghapusan/pembatalan program bantuan.	Super Admin, Admin Rumah Ibadah	Sedang
FR-48	Sistem harus mencegah penyaluran baru pada program berstatus selesai atau dibatalkan.	Sistem	Tinggi
FR-49	Sistem harus menampilkan daftar program bantuan sesuai hak akses.	Super Admin, Admin Rumah Ibadah, Penerima	Sedang

4.8 Penyaluran Bantuan

Kode	Kebutuhan	Aktor	Prioritas
FR-50	Sistem harus mengizinkan super admin/admin rumah ibadah mencatat penyaluran bantuan.	Super Admin, Admin Rumah Ibadah	Tinggi
FR-51	Sistem harus memastikan program dan penerima berada pada rumah ibadah yang sama.	Sistem	Tinggi
FR-52	Sistem harus memastikan penerima berstatus diterima sebelum bantuan disalurkan.	Sistem	Tinggi
FR-53	Sistem harus memastikan penerima masih berada dalam radius 300 meter rumah ibadah program.	Sistem	Tinggi
FR-54	Sistem harus mengambil jenis bantuan, nominal, dan jumlah item dari program.	Sistem	Sedang
FR-55	Sistem harus menghitung bantuan_ke secara otomatis.	Sistem	Tinggi
FR-56	Sistem harus memberi peringatan jika penyaluran melebihi target frekuensi program.	Sistem	Sedang

4.9 Laporan dan Riwayat

Kode	Kebutuhan	Aktor	Prioritas
FR-57	Sistem harus menyediakan laporan penyaluran berdasarkan bulan dan tahun.	Semua aktor sesuai hak akses	Tinggi
FR-58	Sistem harus menyediakan filter rumah ibadah, agama, program, jenis bantuan, dan status penyaluran.	Semua aktor sesuai hak akses	Sedang
FR-59	Sistem harus menampilkan status belum_diberi, sudah_diberi, belum_memenuhi_target, sesuai_target, dan melebihi_target.	Sistem	Tinggi
FR-60	Sistem harus menyediakan rekap laporan.	Semua aktor sesuai hak akses	Sedang
FR-61	Sistem harus menyimpan riwayat perubahan status penerima.	Sistem	Tinggi
FR-62	Sistem harus menampilkan riwayat pengajuan, status, dan penyaluran sesuai hak akses.	Semua aktor	Sedang

---

5. Kebutuhan Non-Fungsional

Kode	Kebutuhan	Keterangan	Prioritas
NFR-01	Keamanan Password	Password harus disimpan dengan password_hash() dan diverifikasi dengan password_verify().	Tinggi
NFR-02	Otorisasi Role	Akses fitur harus dibatasi berdasarkan role.	Tinggi
NFR-03	Validasi Input	Input wajib divalidasi di sisi server.	Tinggi
NFR-04	Prepared Statement	Query yang menerima input pengguna harus memakai prepared statement.	Tinggi
NFR-05	Kompatibilitas Browser	Sistem dapat berjalan pada browser modern seperti Chrome, Edge, dan Firefox.	Sedang
NFR-06	Responsivitas	Tampilan harus dapat digunakan pada laptop dan perangkat mobile.	Sedang
NFR-07	Ketersediaan	Sistem dapat berjalan pada server PHP dan MySQL/MariaDB standar.	Tinggi
NFR-08	Maintainability	Struktur file sederhana dan mudah dipelihara.	Sedang
NFR-09	Usability	Antarmuka harus mudah dipahami oleh admin dan penerima.	Sedang
NFR-10	Auditability	Perubahan status penting harus tercatat dalam riwayat.	Tinggi

---

6. Kebutuhan Data

6.1 Tabel users

Menyimpan data akun pengguna.

Kolom utama:

• id
• nama
• username
• password
• role
• status_akun
• created_at
• updated_at

Role yang tersedia:

• super_admin
• admin_rumah_ibadah
• penerima

Status akun:

• aktif
• nonaktif

6.2 Tabel rumah_ibadah

Menyimpan data rumah ibadah.

Kolom utama:

• id
• user_id
• nama_rumah_ibadah
• agama
• alamat
• nomor_hp
• latitude
• longitude
• status_pengajuan
• status_hapus
• alasan_hapus
• keterangan
• created_at
• updated_at

Status pengajuan:

• menunggu
• diterima
• ditolak

Status hapus:

• normal
• menunggu
• disetujui
• ditolak

6.3 Tabel penerima_bantuan

Menyimpan data penerima bantuan.

Kolom utama:

• id
• user_id
• rumah_ibadah_id
• nama_penerima
• nik
• no_hp
• alamat
• pekerjaan
• penghasilan
• jumlah_tanggungan
• kondisi_rumah
• jenis_bantuan
• latitude
• longitude
• jarak_meter
• status_pengajuan
• status_hapus
• pin_aktif_user_id
• alasan_hapus
• alasan_status
• sumber_pengajuan
• created_at
• updated_at

Status pengajuan:

• menunggu
• diterima
• ditolak
• dibatalkan

Aturan penting:

• pin_aktif_user_id digunakan untuk mencegah satu akun penerima memiliki lebih dari satu pin aktif.

6.4 Tabel program_bantuan

Menyimpan program bantuan.

Kolom utama:

• id
• rumah_ibadah_id
• nama_program
• jenis_bantuan
• deskripsi
• bulan
• tahun
• target_frekuensi
• nominal
• jumlah_item
• status_program
• created_at
• updated_at

Status program:

• aktif
• selesai
• dibatalkan

6.5 Tabel penyaluran_bantuan

Menyimpan catatan penyaluran bantuan.

Kolom utama:

• id
• program_id
• penerima_id
• rumah_ibadah_id
• admin_id
• jenis_bantuan
• nominal
• jumlah_item
• bantuan_ke
• keterangan
• tanggal_penyaluran
• created_at

6.6 Tabel riwayat_status

Menyimpan riwayat perubahan status penerima.

Kolom utama:

• id
• penerima_id
• user_id
• status_lama
• status_baru
• catatan
• created_at

---

7. Aturan Bisnis

Kode	Aturan Bisnis
BR-01	Setiap pengguna harus login untuk mengakses sistem.
BR-02	Akun nonaktif tidak boleh login.
BR-03	Registrasi umum hanya untuk role penerima.
BR-04	Admin rumah ibadah hanya boleh membuat akun penerima.
BR-05	Super admin dapat membuat akun admin rumah ibadah dan penerima.
BR-06	Satu akun penerima hanya boleh memiliki satu pin aktif.
BR-07	Penerima dikaitkan ke rumah ibadah terdekat dalam radius 300 meter.
BR-08	Jika tidak ada rumah ibadah dalam radius 300 meter, penerima belum memiliki rumah ibadah peninjau.
BR-09	Admin rumah ibadah hanya boleh mengelola rumah ibadah miliknya.
BR-10	Admin rumah ibadah tidak boleh membatalkan penerima yang sudah diterima.
BR-11	Penghapusan marker/pin oleh admin rumah ibadah dan penerima harus disetujui super admin.
BR-12	Marker/pin yang status hapusnya disetujui tidak tampil sebagai data aktif.
BR-13	Program dan penerima harus berada pada rumah ibadah yang sama agar penyaluran dapat dicatat.
BR-14	Program berstatus selesai atau dibatalkan tidak dapat menerima penyaluran baru.
BR-15	Target frekuensi menjadi acuan laporan dan peringatan, bukan penghapus data riwayat.
BR-16	Data yang sudah punya relasi tidak boleh dihapus sembarangan agar audit tetap aman.

---

8. Use Case Sistem

8.1 Daftar Use Case

Kode	Use Case	Aktor
UC-01	Login	Semua aktor
UC-02	Logout	Semua aktor
UC-03	Registrasi Akun Penerima	Penerima
UC-04	Kelola Akun	Super Admin, Admin Rumah Ibadah
UC-05	Lihat Peta	Semua aktor
UC-06	Tambah/Ajukan Rumah Ibadah	Super Admin, Admin Rumah Ibadah
UC-07	Setujui/Tolak Rumah Ibadah	Super Admin
UC-08	Tambah/Ajukan Penerima	Semua aktor sesuai hak akses
UC-09	Setujui/Tolak Penerima	Super Admin, Admin Rumah Ibadah
UC-10	Ajukan Hapus Marker/Pin	Admin Rumah Ibadah, Penerima
UC-11	Setujui/Tolak Hapus Marker/Pin	Super Admin
UC-12	Buat Program Bantuan	Super Admin, Admin Rumah Ibadah
UC-13	Hapus/Batalkan Program Bantuan	Super Admin, Admin Rumah Ibadah
UC-14	Catat Penyaluran Bantuan	Super Admin, Admin Rumah Ibadah
UC-15	Lihat Laporan Penyaluran	Semua aktor sesuai hak akses
UC-16	Lihat Riwayat	Semua aktor sesuai hak akses

8.2 Deskripsi Use Case Utama

UC-01 Login

Aktor memasukkan username dan password. Sistem memeriksa akun pada tabel users. Jika akun aktif dan password benar, sistem membuat session dan mengarahkan pengguna ke dashboard.

UC-04 Kelola Akun

Super Admin dapat membuat, mengedit, menonaktifkan, dan menghapus akun admin rumah ibadah atau penerima. Admin Rumah Ibadah hanya dapat mengelola akun penerima.

UC-06 Tambah/Ajukan Rumah Ibadah

Super Admin atau Admin Rumah Ibadah memilih titik pada peta dan mengisi data rumah ibadah. Data disimpan dengan status pengajuan sesuai role. Super Admin dapat menyetujui data agar rumah ibadah aktif.

UC-08 Tambah/Ajukan Penerima

Pengguna memilih lokasi rumah penerima pada peta dan mengisi data penerima. Sistem mengecek satu pin aktif dan menghitung rumah ibadah terdekat dalam radius 300 meter.

UC-14 Catat Penyaluran Bantuan

Admin memilih program dan penerima yang sudah diterima. Sistem memastikan program dan penerima berada pada rumah ibadah yang sama, lalu menyimpan catatan penyaluran.

---

9. Matriks Hak Akses

Fitur	Super Admin	Admin Rumah Ibadah	Penerima
Login	Ya	Ya	Ya
Registrasi akun sendiri	Tidak	Tidak	Ya
Kelola akun admin rumah ibadah	Ya	Tidak	Tidak
Kelola akun penerima	Ya	Ya	Tidak
Lihat peta	Ya	Ya	Ya
Tambah rumah ibadah	Ya	Ajukan	Tidak
Setujui rumah ibadah	Ya	Tidak	Tidak
Tambah penerima	Ya	Ya, sesuai radius	Ajukan diri sendiri
Setujui penerima	Ya	Ya, sesuai wilayah	Tidak
Reset/batalkan penerima diterima	Ya	Tidak	Tidak
Buat program bantuan	Ya	Ya, miliknya	Tidak
Catat penyaluran bantuan	Ya	Ya, miliknya	Tidak
Lihat laporan	Ya, semua	Ya, miliknya	Ya, miliknya
Hapus marker/pin langsung	Ya	Tidak	Tidak
Ajukan hapus marker/pin	Tidak perlu	Ya	Ya, pin sendiri
Setujui hapus marker/pin	Ya	Tidak	Tidak

---

10. Antarmuka Sistem

10.1 Halaman Login

Komponen:

• Input username.
• Input password.
• Tombol Login.
• Link Registrasi Penerima.
• Informasi akun demo.

10.2 Halaman Register

Komponen:

• Nama lengkap.
• Username.
• Password.
• Konfirmasi password.
• Tombol Daftar.

10.3 Halaman Peta

Komponen:

• Peta Leaflet.
• Marker rumah ibadah.
• Pin penerima.
• Popup detail.
• Form tambah/ajukan rumah ibadah.
• Form tambah/ajukan penerima.
• Tombol setujui/tolak.
• Tombol hapus/ajukan hapus.

10.4 Halaman Dashboard

Komponen:

• Statistik data.
• Panel persetujuan hapus marker/pin.
• Form kelola akun.
• Daftar akun.
• Monitoring penyaluran per periode.
• Rekap penyaluran.
• Form program bantuan.
• Daftar program bantuan.
• Form penyaluran bantuan.
• Tabel laporan penerima.
• Riwayat pengajuan dan bantuan.

---

11. Kebutuhan Lingkungan

11.1 Localhost

Komponen	Kebutuhan
Web server	Apache dari Laragon
Database	MySQL/MariaDB
PHP	PHP versi yang mendukung MySQLi dan password_hash
Browser	Chrome, Edge, Firefox, atau browser modern lain
Internet	Dibutuhkan untuk Leaflet CDN

11.2 Hosting

Komponen	Kebutuhan
Hosting	cPanel atau hosting PHP sejenis
PHP	Mendukung MySQLi
Database	MySQL/MariaDB
SSL	Disarankan menggunakan HTTPS
File Manager/FTP	Untuk upload file aplikasi

---

12. Kriteria Penerimaan Sistem

Sistem dianggap berhasil jika:

1. Pengguna dapat login sesuai role.
2. Akun nonaktif tidak dapat login.
3. Super admin dapat mengelola akun.
4. Admin rumah ibadah dapat mengelola akun penerima.
5. Peta dapat menampilkan rumah ibadah dan penerima.
6. Rumah ibadah dapat diajukan dan disetujui.
7. Penerima dapat diajukan dan disetujui.
8. Sistem mencegah satu akun penerima memiliki lebih dari satu pin aktif.
9. Sistem menghubungkan penerima ke rumah ibadah terdekat dalam radius 300 meter.
10. Program bantuan dapat dibuat.
11. Penyaluran bantuan dapat dicatat.
12. Laporan bulanan dapat menampilkan status bantuan.
13. Riwayat perubahan status tersimpan.
14. Pengajuan hapus marker/pin dapat diproses oleh super admin.
15. Aplikasi dapat berjalan di localhost dan hosting.

---

13. Risiko dan Mitigasi

Risiko	Dampak	Mitigasi
File SQL gagal diimport	Sistem tidak dapat berjalan	Sediakan panduan import dan troubleshooting.
Password akun salah	Pengguna tidak bisa login	Gunakan akun demo dengan password password.
Leaflet CDN tidak bisa diakses	Peta tidak muncul	Pastikan koneksi internet aktif atau siapkan Leaflet lokal jika diperlukan.
Data penerima ganda	Laporan tidak akurat	Terapkan aturan satu pin aktif per akun penerima.
Admin salah mengelola data RI lain	Data tidak valid	Terapkan pembatasan akses berdasarkan user_id rumah ibadah.
Hapus data merusak audit	Riwayat hilang	Gunakan status hapus/nonaktif, bukan hapus permanen untuk data berelasi.

---

14. Penutup

Dokumen SKPL/SRS ini menjadi acuan kebutuhan aplikasi WebGIS Poverty Mapping Project 05. Sistem dirancang untuk membantu pendataan penerima bantuan berbasis lokasi, pengelolaan rumah ibadah, pencatatan program bantuan, penyaluran bantuan, dan pelaporan penerima yang sudah atau belum menerima bantuan.