Template.1.1 (T.1.

1)

Template
Spesifikasi Kebutuhan
[NamaAplikasi]
Versi 1.0

Disahkan Oleh: Tanda Tangan

Tanggal:
Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

Daftar Revisi
Daftar Revisi ini mencatat semua revisi yang pernah dilakukan pada Dokumen Spesifikasi
Kebutuhan.

Tanggal Versi Keterangan Revisi Alasan Revisi

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 1

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

1. Tinjauan Sistem yang Ada

1.1. Penjelasan dari Sistem yang Ada
Berikut gambaran dari SIPATUH

Dari gambar di atas, terdapat 3 aplikasi yang dibutuhkan untuk SIPATUH 2018 ini yakni:

No. Aplikasi Fungsi Keterangan

1 SIPATUH Frontend - Aplikasi web yang Aplikasi ini dapat diakses dari
dapat diakses oleh luar dan dalam PPATK.
Pelapor, User
PPATK dan User
Admin
- Aplikasi yang
berupa webservice
yang berguna
sebagai penampung
Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 2
Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

data yang diupload

dari SIPATUH
Desktop
2 SIPATUH Backend - Aplikasi web yang Aplikasi ini hanya dapat diakses
dapat diakses oleh dari dalam jaringan PPATK saja.
user internal PPATK
saja. Data dari
SIPATUH Frontend
akan ditarik dari dan
disimpan di
Backend.
Selanjutnya user
dapat mengolah data
sesuai kebutuhan.
3 SIPATUH Desktop - Aplikasi desktop Aplikasi ini harus diinstall di
yang berguna untuk masing-masing PC/Laptop
membantu auditor
saat melakukan
audit kepatuhan
secara langsung(on-
site)

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 3

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

Teknologi yang digunakan

No Aplikasi Teknologi Keterangan
1 SIPATUH Frontend OS SLES (Suse Linux Enterprise Disediakan oleh PPATK
Server) 12 64 Bit
Apache 2 Webserver
PHP 7.1
Framework Laravel 5.6
Webservice Restful dengan PHP
Postgresql 9.x Database Server
2 SIPATUH Backend OS Windows Server 2008 R2
Enterprise 64 Bit
SharePoint Server 2010
SQL Server 2012 64 Bit Database Server
Infopath 2010 Form Existing
Webpart Form Existing dan Form
Pengembangan
Webservice asmx (WSDL-.Net 2) Webservice Existing
Webservice Restful(WCF-. Net 4) Webservice Pengembangan

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 4

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

3 SIPATUH Desktop WPF Aplikasi Existing dan

Pengembangan

1.2. Kendala dan Masalah yang Ada

Berikut beberapa kendala yang ditemui saat development pengembangan SIPATUH ini:
 Dokumentasi teknis development sebelumnya kurang memadai. Untuk
memahami alur aplikasi existing harus membaca coding sebelumnya.
 Server development belum tersedia di awal projek. Untuk memahami alur
hanya dari dokumen teknis dan pengoperasian. Tidak bisa langsung dicoba di
server real.
 Perubahan database dan topologi system yang berubah dikarenakan kendala
license yang belum ada.

2. Tujuan Pembuatan Sistem

Dalam pengembangan SIPATUH tahun 2018 ini terdapat pembuatan sistem baru dan
pengembangan yang melengkapi sistem yang sudah ada.
 SIPATUH Frontend = Merupakan aplikasi frontend untuk Audit kepatuhan off-
site ini bertujuan untuk mengumpulkan informasi dari pihak pelapor untuk
mengukur penilaian risiko terjadinya tindak pidana pencucian uang dan
pendanaan terorisme. Nilai yang dimaksud adalah nilai kualitatif rendah,
sedang dan tinggi. Tindak lanjut atas nilai risiko yang tinggi nantinya akan
dilakuan audit on-site yang prosesnya sudah terdapat pada aplikasi sipatuh saat
ini.
 SIPATUH Backend = Merupakan aplikasi backend untuk Audit kepatuhan
offsite dan onsite. Data dari SIPATUH Frontend akan dioleh di backend oleh
user-user yang ada dalam PPAT seperti Auditor, Ketua Kelompok, Direktur dan
Deputi.
 SIPATUH Desktop = merupakan aplikasi desktop yang bertujuan untuk
membantu auditor untuk melakukan audit kepatuhan secara langsung(on-site)

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 5

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

3. Definisi Lingkup Pekerjaan

Meskipun diagram alur kerja sudah mencukupi (work flow), pada bagian ini alur kerja
sistem baru (system work flow) dapat diusulkan serta didokumentasikan jika
memungkinkan.

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 6

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

3.1. Fungsi-Fungsi yang Akan Dikomputerisasi

Untuk tiap fungsi pekerjaan, deskripsikan kegunaan, spesifikasikan bagaimana input diolah menjadi output dan juga bagaimana
informasi dapat diambil, diproses dan dihasilkan. Hal ini dapat dikelompokan dalam topik sebagai berikut:
Input
No Fungsi Kegunaan
Sumber Tipe Volume Frekuensi Item Data

Proses
No Fungsi
Aturan Penyelesaian Urutan Proses Metode

Output
No Fungsi
Pengguna Tipe Volume Frekuensi Item Data

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 7

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

3.2. Fungsi yang Tidak Perlu Dikomputerisasi

Daftar fungsi dari tiap lingkup pekerjaan yang tidak perlu dikomputerisasikan dan buat alasannya.
No Fungsi Alasan tidak perlu dikomputerisasi

3.3. Hubungan dengan Sistem Lain

Tipe dari
Kebutuhan transfer hubungan
Frekuensi Spesifikasi
data dan karakteristik ()
No Sistem transfer kewenangan
media komunikasi
On- data akses
yang digunakan Batch
Line

4. Permintaan Performance
4.1. Response Time Sistem
Jelaskan response time untuk periode sibuk dan normal. Response time sistem untuk
tipe transaksi yang berbeda mungkin berbeda pula. Tipe transaksi yang mungkin
terjadi adalah entry/update, enquiry (apakah tipe pencarian yang mudah atau
pencarian karakter), image. Biasanya, response time sistem pada periode sibuk dan
harian mungkin berbeda.

Jenis Response time Response time

Keterangan
Transaksi periode normal periode sibuk

Untuk fungsi batch, spesifikasikan waktu yang dibutuhkan antara waktu penerimaan
permintaan sampai laporan dihasilkan. Apabila performance termasuk kategori kritis,
hitung response time-nya.
Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 8
Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

4.2. Ketersediaan Sistem

Untuk melihat ketersediaan sistem, pertimbangkan jam operasional pada jam kerja normal, akhir
minggu dan hari libur. Misalnya sistem dibutuhkan untuk beroperasi secara teratur 24 jam sehari,
7 hari seminggu termasuk hari libur dan hari Minggu.

Sistem beroperasi pada hari-hari Jam

Alasan
berikut (Pilih yang sesuai ) Operasional
Hari Kerja (Senin-Jumat)
Sabtu
Minggu
Hari Libur

5. Kebutuhan Pengendalian Pengamanan

5.1. Pengendalian kewenangan Kelompok User
Sumberdaya Komputer

Pembatasn Layanan
Peran/Roles

Keterangan
Transaksi
Identitas

Lokasi
Waktu
No Kelompok User

Manajemen Senior
Pemilik Aplikasi
Pemilik Informasi
Pemelihara Aplikasi
Database Administrator
User
Kelompok User Lain

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 9

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

5.2. Pengendalian pengamanan aplikasi

Memastikan bahwa ketentuan-ketentuan Pedoman Pengamanan Teknologi Informasi
telah dipenuhi, antara lain RPP – 05 Manajemen Operasional dan Komunikasi, RPP – 06
Pengendalian Akses, RPP - 07 Pengadaan, Pengembangan dan Pemeliharaan Sistem
Aplikasi, RPP – 09 Pemulihan Teknologi Informasi.
Point-point yang perlu diperhatikan antara lain mengenai perencanaan dan penerimaan
sistem aplikasi, backup dan restore, penggunaan password, identifikasi dan otentikasi
pengguna, sesi timeout, validasi data input, pengendalian proses internal, integritas data,
validasi data output, pengendalian kriptografi, pengamanan file pada sistem aplikasi dan
BCP.
Menjabarkan hal-hal lain yang perlu mendapatkan perhatian.

5.3. Audit Trail

Strategi akuntabilitas individu:

Strategi pendeteksian serangan:

5.4. Catatan Khusus

Catat segala kebutuhan pengamanan lainnya seperti enkripsi data, keabsahan message,
dsb. Gunakan standard dan peraturan Teknologi Informasi yang berlaku.

6. Permintaan Khusus
6.1. Konversi
Pada dasarnya terdapat 2 macam konversi yaitu :
a. Konversi data manual kedalam file komputer.
b. Konversi dari data yang telah dikomputerisasi.
Catat apakah dibutuhkan konversi data manual ke dalam file komputer. Jika dibutuhkan,
tetapkan tanggal cut-off data yang harus dikonversi.

6.2. Penyimpanan
Apa yang
Harus
Media Offline
Tipe Jadwal Dilakukan Keterangan
No (Jika
Informasi Retensi Setelah /Alasan
Diperlukan)
Jadwal
Retensi

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 10

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

7. Kebutuhan Pemulihan TI / BCP

Untuk fungsi pekerjaan yang kritis, diperlukan informasi mengenai :
a. Jangka waktu kegagalan sistem yang dapat ditolerir (Recovery Time
Objective – RTO).
b. Tanggal data terakhir yang harus tersedia saat dilakukan pemulihan TI
(Recovery Point Objective - RPO)
c. Jenis data, frekwensi (harian, mingguan dsb) dan jadwal retensi dari backup.
d. Mekanisme melanjutkan operasi selama waktu kegagalan sistem misalnya
mengganti ke sistem komputerisasi lainnya, menggunakan PC, kembali ke prosedur
manual.

8. Keterbatasan
Keterbatasan sistem misalnya hukum dan kebijakan kritis yang ada, ketergantungan
terhadap sistem lain, platform yang ada (h/w, s/w, komunikasi dsb), lingkungan operasi
dan arah teknologi harus dijelaskan.
9. Dampak dari Permintaan
Membuat kesimpulan akibat permintaan sistem baru dari sudut pandang user termasuk
struktur organisasi, sumber daya dan alur kerja.
10. Manajemen Risiko
Risiko yang terkait dengan Sistem Aplikasi yang akan dikembangkan, baik risiko yang
terkait dengan proses bisnis maupun risiko proyek harus dikelola dengan efektif dan
efisien dengan mengacu kepada ketentuan mengenai Manajemen Risiko Bank Indonesia.
Pengelolaan risiko dilakukan dengan cara:
 Identifikasi risiko
 Pengukuran risiko
 Pengendalian risiko
 Pemantauan risiko
Contoh matriks risiko:

Level
Tingkat Tingkat
Dampak
Kemungkinan Risiko
Risiko Penanggung
No Risiko (Probability) (Dampak x Mitigasi Risiko
(High, jawab
Risiko (High, Kemungkina
Medium,
Medium, Low) n)
Low)
I. Risiko terkait proyek
1. Perubahan High Low High - -

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 11

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

organisasi Bank
Indonesia terkait
dengan rencana
restrukturisasi
Direktorat...
2. Pengembangan High Medium High - Menyusun
aplikasi tidak rencana
sesuai dengan pengembangan
jadwal yang serinci mungkin
direncanakan
- Personil yang
karena target
menangani
waktu yang ketat
proyek baik di
(diamanatkan
satker user dan
oleh PBI/PDG)
DTI harus
ditugaskan
khusus
(dedicated)
II. Risiko terkait aplikasi
1. Perubahan High Medium High Sedapat mungkin DPAS
ketentuan yang program dirancang
dapat secara fleksibel
mempengaruhi (dengan
perhitungan menggunakan
parameter)
2. Adanya Medium Medium Medium Perlu koordinasi Direktorat
perubahan pada dengan pihak yang Pemilik
aplikasi yang terkait dengan Aplikasi,,
terkait dengan aplikasi-aplikasi DPAS
aplikasi yang tersebut
sedang
dikembangkan
3. Risiko terjadinya High Low High Perlu dirancang Direktorat
keadaan tidak kebutuhan sistem Pemilik
normal dan TI pengganti Aplikasi,
keadaan (DRC) serta BCP DOS, DPAS
darurat/bencana yang memadai
yang dapat
mempengaruhi
operasional
sistem aplikasi
4. Risiko terjadinya Medium Low Medium Perlu
perubahan dipertimbangkan
teknologi Benefit-Cost Ratio
teknologi baru
tersebut

Contoh matriks Penilaian Tingkat Risiko

Kemungkinan Dampak High Medium Low

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 12

Pedoman Pengajuan, Pengembangan dan Pemeliharaan Sistem Aplikasi (P3SA)

High High High High

Medium High Medium Medium
Low High Medium Low

11. Lain-Lain

Template Dokumen Spesifikasi Kebutuhan T.1.1 Halaman : 13