Software Requirements

Specification

Dimas Tubagus R.I (I0022009)

Firman Ardy Prasetyo (I00220010)
Fany Indra Zulindra (
Ariani Dwi Septi (
Natasya Wahyu Ningsih (I0022020)
 1. Pendahuluan
1.1 Tujuan (Purpose)
Dokumen Software Requirements Specification (SRS) ini disusun untuk memberikan
acuan yang jelas dan terstruktur mengenai kebutuhan sistem informasi keuangan
Universitas Bhamada Slawi. Tujuan utama dokumen ini adalah sebagai pedoman
utama bagi tim pengembang, penguji, dan pemangku kepentingan lainnya selama
proses perencanaan, pengembangan, pengujian, dan implementasi sistem. SRS ini
juga bertujuan untuk memastikan bahwa sistem yang dibangun memenuhi
kebutuhan pengguna akhir serta sejalan dengan tujuan institusi.
1.2 Cakupan (Scope)
Sistem Keuangan yang akan dikembangkan merupakan platform berbasis web yang
mencakup pengelolaan tagihan mahasiswa, pencatatan transaksi keuangan,
pembuatan jurnal dan laporan keuangan, pengelolaan pembayaran gaji pegawai, dan
integrasi dengan sistem pembayaran pihak ketiga. Sistem ini akan menggantikan
proses manual berbasis dokumen dan spreadsheet yang selama ini digunakan,
sehingga dapat meningkatkan efisiensi, akurasi, transparansi, dan kecepatan dalam
proses keuangan kampus.
Masalah utama yang ingin diselesaikan:
 Ketergantungan pada proses manual yang rawan kesalahan.
 Lamanya proses pelaporan dan verifikasi transaksi.
 Sulitnya melacak histori keuangan secara real-time.
 Keterbatasan pelaporan keuangan untuk keperluan audit dan manajemen.

1.3 Definisi, Akronim, dan Singkatan

Istilah / Penjelasan
Akronim
SRS Software Requirements Specification – Dokumen
kebutuhan perangkat lunak
PID Project Initiation Document – Dokumen inisiasi proyek
UI/UX User Interface / User Experience – Antarmuka dan
pengalaman pengguna
UAT User Acceptance Testing – Pengujian penerimaan oleh
pengguna akhir
API Application Programming Interface – Antarmuka
pemrograman aplikasi
ERD Entity Relationship Diagram – Diagram relasi antar-
entitas basis data
SOP Standard Operating Procedure – Prosedur operasi
standar
UKT Uang Kuliah Tunggal – Skema pembayaran kuliah di
 Indonesia
BOP Biaya Operasional Pendidikan – Biaya pendidikan non-
UKT

1.4 Referensi
 Project Initiation Document (PID) Sistem Keuangan Universitas Bhamada
Slawi, Versi 1.0, 14 April 2025.
 Dokumen Wawancara Keuangan Universitas Bhamada Slawi.

2. Deskripsi Umum (Overall Description)

Menjelaskan konteks umum sistem, tanpa terlalu detail.
2.1 Perspektif Produk
Sistem Keuangan ini merupakan sistem berdiri sendiri namun dirancang agar dapat
diintegrasikan dengan sistem akademik lain seperti SIAKAD (Sistem Informasi
Akademik) di masa depan. Sistem ini menggantikan proses manual pengelolaan
keuangan di lingkungan Universitas Bhamada Slawi dan berfungsi sebagai sistem
utama dalam pengolahan data keuangan internal kampus.
Sistem akan beroperasi secara berbasis web dan disimpan pada infrastruktur server
yang tersedia di dalam kampus. Sistem ini dibangun secara in-house oleh tim
internal universitas untuk memastikan kesesuaian dengan kebutuhan spesifik
institusi.

2.2 Fungsi Produk

Sistem keuangan kampus yang akan dikembangkan memiliki fungsi utama untuk
mendukung pengelolaan keuangan secara terintegrasi, transparan, dan efisien di
lingkungan institusi pendidikan tinggi. Sistem ini bertujuan untuk memfasilitasi
proses keuangan mulai dari penerimaan pembayaran mahasiswa, gaji pegawai,
pengelolaan anggaran dan pelaporan keuangan institusi.
2.3 Karakteristik Pengguna
Sistem ini akan digunakan oleh berbagai tipe pengguna dengan tingkat kemampuan
teknis berbeda:
Pengguna Peran / Akses Utama
Staf Keuangan Input & validasi transaksi, membuat laporan,
pengelolaan data, validasi proposal keuangan
Mahasiswa Melihat tagihan dan status pembayaran, mengajukan
proposal kegiatan mahasiswa
Pegawai (Non- Mengajukan proposal kegiatan operasional/fakultas,
keuangan) menerima informasi dan slip gaji
Admin Sistem Mengelola user, hak akses, dan konfigurasi sistem
 Pimpinan Melihat dashboard keuangan dan laporan strategis
Universitas
Sebagian besar pengguna berasal dari latar belakang non-teknis, oleh karena itu
antarmuka sistem dirancang agar sederhana, intuitif, dan mudah digunakan.

2.4 Keterbatasan (Constraints)

Sistem ini memiliki beberapa batasan sebagai berikut:
 Sistem hanya digunakan di lingkungan internal Universitas Bhamada Slawi.
 Infrastruktur server tetap menggunakan fasilitas kampus tanpa cloud hosting
eksternal.
 Tidak mencakup pengembangan aplikasi mobile.
 Tidak langsung terhubung dengan sistem perpajakan nasional.
 Hanya mendukung browser modern (Chrome, Firefox, Edge).
 Tidak semua unit siap integrasi karena belum memiliki sistem pencatatan
digital.

2.5 Asumsi dan Ketergantungan

Pengembangan proyek mengasumsikan:
 Data keuangan tersedia dalam format yang bisa dimigrasikan
 Staf keuangan tersedia untuk pelatihan sistem
 Server kampus memiliki kapasitas dan keamanan yang memadai
 Dukungan manajemen terhadap pengembangan sistem terjamin

2.6 Pembagian Kebutuhan (Apportioning of Requirements)

Beberapa fitur tidak akan disertakan dalam versi awal sistem (versi 1.0), yaitu:
 Pengembangan aplikasi mobile untuk mahasiswa dan staf.
 Integrasi penuh dengan sistem akademik dan sistem perpustakaan.
 Modul penganggaran berbasis skenario atau simulasi.
 Integrasi langsung ke sistem pajak nasional.
Fitur-fitur tersebut akan dipertimbangkan untuk pengembangan tahap lanjut
setelah sistem inti stabil dan teruji.

3. Kebutuhan Spesifik (Specific Requirements)

Bagian utama dari SRS yang berisi detail teknis dan fungsional sistem.
3.1 External Interface Requirements
3.1.1 Antarmuka Pengguna (User Interfaces)
Sistem memiliki antarmuka berbasis web dengan pendekatan role-based login.
Berikut desain antarmukanya:

 Login Page
Input: Username dan Password.
Role redirect otomatis berdasarkan tipe pengguna: Mahasiswa, Loket 3, Atasan,
Keuangan, Yayasan.
Tombol: "Login", "Lupa Password".
  Dashboard Mahasiswa
Menampilkan status pembayaran dan VA aktif.
Tombol: “Bayar Sekarang”, “Lihat Status”, “Unduh Bukti Pembayaran”.

 Form Pengajuan Proposal

Input: Judul, deskripsi, dana yang diajukan, file proposal.
Tombol: “Ajukan Proposal”, “Simpan Draft”.

 Validasi Proposal (Loket 3 & Atasan)

Fitur: Checklist validasi, kolom catatan revisi.
Tombol: “Setujui”, “Revisi”, “Disposisi ke Keuangan”.

 Dashboard Keuangan
Tampilan: Tabel status pembayaran mahasiswa, daftar proposal masuk,
penyusunan RAB.
Tombol: “Cairkan Dana”, “Ajukan RAB”, “Cetak LPJ”.

 Presensi Pegawai (View Only)

Menampilkan data terhubung dari sistem kepegawaian: nama pegawai,
kehadiran, keterlambatan.

 LPJ Upload Interface

Input: File LPJ, tanggal kegiatan, uraian penggunaan dana.
Tombol: “Unggah LPJ”, “Lihat Status”.

3.1.2 Hardware Interfaces

 Sistem berjalan di lingkungan berbasis web.

 Tidak bergantung pada perangkat keras khusus.

 Diperlukan:

 Server/cloud dengan spesifikasi minimal CPU 4-core, RAM 8GB, SSD

256GB.
 Client: Laptop/smartphone dengan browser modern.

3.1.3 Software Interfaces

 Sistem Akademik

 Sinkronisasi status aktif mahasiswa (aktif/tidak berdasarkan

pembayaran).

 Sistem Kepegawaian

 Mengambil data presensi dan keterlambatan untuk perhitungan gaji.

  Database

 MySQL/PostgreSQL (relasional), digunakan untuk menyimpan semua

entitas: transaksi, proposal, gaji, dsb.

 Payment Gateway API

 Digunakan untuk verifikasi pembayaran melalui VA.

 Email/Notification Service

 Untuk notifikasi jatuh tempo VA, revisi proposal, validasi LPJ.

3.1.4 Communications Interfaces

 Komunikasi utama:
o REST API berbasis HTTP/HTTPS untuk pertukaran data antar
modul dan sistem eksternal.
o Format data: JSON.
 Pengamanan komunikasi:
o SSL/TLS (HTTPS)
o Token-based Authentication (JWT/OAuth2)

3.2 Functional Requirements

3.2.1 User Class 1 – Pengguna (Mahasiswa, BEM, Dosen, Unit)

 FR1: Mahasiswa dapat login menggunakan NIM dan password.

 FR2: Mahasiswa memilih metode pembayaran (lunas/angsuran) dan meng-

generate VA.

 FR3: Mahasiswa menerima notifikasi H-1 sebelum VA jatuh tempo.

 FR4: Mahasiswa dapat melihat status akademik aktif/tidak.

 FR5: Unit/BEM/Dosen dapat mengajukan proposal + unggah dokumen.

 FR6: Pengusul menerima notifikasi revisi jika proposal ditolak.

3.2.2 User Class 2 – Petugas Loket 3 & Atasan

 FR7: Loket 3 dapat melihat daftar proposal dan melakukan validasi awal.

 FR8: Loket 3 mengirimkan notifikasi revisi kepada pengusul.

  FR9: Atasan menerima proposal valid dari Loket 3 dan melakukan validasi
akhir.

 FR10: Atasan dapat merevisi atau menyetujui proposal/LPJ dan

mendisposisikan ke Keuangan.

3.2.3 User Class 3 – Administrator Keuangan dan Yayasan

 FR11: Keuangan dapat melihat semua transaksi pembayaran mahasiswa.

 FR12: Keuangan menyusun RAB berdasarkan proposal disetujui dan gaji

pegawai.

 FR13: Keuangan melakukan pencairan dana dan pengiriman gaji.

 FR14: Sistem secara otomatis mengurangi gaji dosen jika ada

absensi/keterlambatan.

 FR15: Keuangan menyusun laporan keuangan bulanan + LPB.

 FR16: Yayasan memverifikasi dan menyetujui RAB/laporan keuangan

bulanan.

3.3 Performance Requirements

PR1: Waktu respons halaman maksimal 2 detik (95% dari waktu penggunaan).

PR2: Uptime sistem minimum 99.5%.

PR3: Data pembayaran VA harus tersinkronisasi dengan status akademik maksimal

dalam 5 menit.

PR4: Notifikasi dikirimkan maksimal 3 menit setelah trigger.

PR5: Sistem mendukung minimal 5000 pengguna aktif harian secara bersamaan.

3.4 Design Constraints

DC1: Harus menggunakan arsitektur REST API.

DC2: Database harus relasional (PostgreSQL/MySQL).

DC3: Harus mendukung integrasi dengan sistem kepegawaian & akademik.

DC4: Desain antarmuka wajib responsive (mobile dan desktop).

DC5: Seluruh transaksi dan log harus dicatat untuk keperluan audit.

3.5 Software System Attributes

Atribut Deskripsi
Keamanan Semua data dikirim dengan enkripsi TLS, autentikasi berbasis token
(JWT), dan role-based access control.
Keandalan Sistem dapat menangani kegagalan transaksi, retry otomatis, dan
backup harian.
Kegunaan Antarmuka ramah pengguna, didesain responsif, dengan panduan di
(Usability) setiap tahap proses.
Maintainability Modul terpisah (microservice ready), dokumentasi teknis lengkap.
Portabilitas Dapat diakses dari browser modern di desktop maupun mobile.
Auditability Semua transaksi dan aksi pengguna dicatat dalam audit log yang
tidak dapat diubah.
4. Prioritas dan Rencana Rilis (Prioritization and Release Plan)
4.1 Metode Prioritasi
Menjelaskan metode yang digunakan untuk menentukan prioritas fitur, misalnya
berdasarkan biaya dan manfaat.

Lampiran (Appendix)
Lampiran I: Pemilihan Metode Cost-Value
Penjelasan kenapa pendekatan cost-value digunakan untuk menentukan prioritas
fitur.
Lampiran II: Hasil Prioritasi 10 Kebutuhan
Tabel atau grafik hasil dari prioritas fitur berdasarkan metode cost-value.
Lampiran III: Skema Prioritas Lima-Tingkatan
Pembagian kebutuhan berdasarkan 5 tingkat prioritas (mungkin: sangat penting,
penting, sedang, rendah, sangat rendah).
Lampiran IV: Rencana Rilis
Tahapan peluncuran fitur dalam beberapa iterasi atau versi sistem.
Lampiran V: I-star
Model visual (biasanya menggunakan diagram i*) untuk menunjukkan tujuan,
aktor, dan relasi antar fungsi dalam sistem.