T.2.2 Template Spesifikasi Disain SIPATUH

Template.2.2(T.2.
2)
Template
Spesifikasi Disain
SIPATUHTahun 2018
Versi 1.0
Dilakukan 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 Disain ini.
Tanggal Versi Keterangan Revisi Alasan Revisi
Template Spesifikasi Disain T.2.2

Halaman : 1
1. Pendahuluan
1.1. Latar Belakang
Aplikasi SIPATUH dikembangkan pada tahun 2014, dan saat ini sudah
berjalan digunakan untuk kegiatan pengawasan dan kepatuhan oleh
Direktorat Pengawasan dan Kepatuhan. Aplikasi sipatuh saat ini dikembangkan
menggunakan teknologi sharepoint 2010 untuk aplikasi webnya dan microsoft
WPF untuk aplikasi desktop yang digunakan untuk kegiatan audit kepatuhan
secara langsung (on-site).
Modul yang ada pada aplikasi SIPATUH eksisting, dapat digambarkan

sebagai berikut:
Gambar 1.Modul SIPATUH existing
Catatan: modul 1 sd. 4 merupakan modul audit On-Site
Seiring dengan berjalannya waktu terdapat perubahan peraturan dan

kebijakan sehingga perlu dilakukan perubahan dan penambahan modul.
Salah satu perubahan peraturan yang berdampak pada aplikasi SIPATUH

ini adalah terkait dengan kegiatan audit dari yang sebelumnya hanya kegiatan
audit kepatuhan secara langsung (on-site), ditambahkan juga audit kepatuhan
secara tidak langsung (off-site). 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.
Kemudian ada juga kegiatan DPK yang sebelumnya belum difasilitasi

pada aplikasi SIPATUH saat ini yaitu kegiatan pemantauan komitment audit
terkait dengan APU-PPT yang dilakukan oleh Lembaga Pengawas dan
Pengatur.
(LPP). Pada aplikasi sipatuh saat ini perlu ditambahkan fungsi untuk
memantau komitment audit pihak pelapor yang telah dilakukan audit oleh LPP.
Dengan adanya perubahan tersebut, maka modul yang ada di

dalam Aplikasi SIPATUH, akan menjadi sebagai berikut:
1.2. Tujuan
Tujuan pengembangan SIPATUH ini adalah:
a. Untuk memudahkan DPK untuk mengelola dokumen terkait dengan
kegiatan audit off-site.
b. Mengetahui tingkat risiko Pihak Pelapor setelah dilakukan off-site
audit untuk selanjutnya dapat dilakukan audit on-site
c. Menambahkan beberapa fitur pada aplikasi SIPATUH yang eksisting saat
ini.
d. Menambahkan beberapa fungsi baru pada aplikasi SIPATUH desktop.
1.3. Konvensi Dokumen
Dokumen Spesifikasi Kebutuhan Perangkat Lunak ini menggunakan
standar penulisan Software Requirements Specification ANSI/IEEE std 830-
1984.
1.4. Ruang Lingkup

Aplikasi SIPATUH ini terdiri atas 3 jenis yakni:
a) SIPATUH Frontend = SIPATUH front end merupakan aplikasi
berbasis web yang menggunakan laman web site dengan kontens
yang dapat dikelola oleh admin dengan mudah dan dapat diakses
oleh pengguna (users) menggunakan web browser yang umum
digunakan (IE, Chrome, mozilla). User yang dapat menggunakan
aplikasi ini yakni Auditee, User PPATK dan Admin PPATK
a.
b) SIPATUH Backend= Aplikasi existing yang berbasis web. Dibangun

diatas menggunakan teknologi SharePoint 2010. Digunakan oleh
Internal PPATK
c) SIPATUH Desktop= Aplikasi yang digunakan untuk kegiatan audit
kepatuhan secara langsung (on-site)
2. Arsitektur Sistem
2.1. Arsitektur Sistem
Berikut konfigurasi aplikasi SIPATUH
Webserver : Apache 2.0
Application : PHP 5, Jquery, framework codeigniter 3.0
Database : MSSQL Server
Desain / Layout : Twitter Bootstrap, HTML 5, CSS 3

Gambar 2. 1 Konfigurasi Aplikasi
Aplikasi E-RKA mengolah data dan anggaran dengan sumber data awal
dari aplikasi RKAKL yang dikembangkan oleh Kementerian Keuangan RI. Data
dari aplikasi E-RKA dapat digunakan dan diexport kembali ke aplikasi RKAKL,
berikut gambaran arsitektur aplikasi
Gambar 2. 2 Konfigurasi Aplikasi
2.2. Asumsi dan Dependensi
Asumsi Sistem Aplikasi E-RKA adalah sistem yang disetujui sebagai alat
bantu untuk dapat mempermudah dalam penyusunan rencana kerja dan
anggaran di lingkungan PPATK. Sistem Aplikasi E-RKA memiliki ketergantungan
terhadap :
1) Data User yang sudah didaftarkan sebagai sarana bantu untuk:

a. mengidentifikasi ID dari pengguna;
b. mengidentifikasi status;
c. mengidentifikasi unit kerja yang bersangkutan.
2) Koneksi jaringan intranet yang stabil agar sistem dapat diakses melalui browser.
3. Diagram Model
3.1 Use Case Diagram
Diagram Use Case menggambarkan aktor dengan sekumpulan aksi yang

berkolaborasi dengan satu atau lebih eksternal aktor dari beberapa aksi di
sistem tersebut. Berikut ini adalah beberapa simbol yang digunakan dalam
Diagram Use Case.
Tabel 3.1 – Simbol Diagram Use Case
Aktor adalah pengguna sistem. Aktor tidak terbatas hanya

manusia saja, jika sebuah sistem berkomunikasi dengan
aplikasi lain dan membutuhkan input atau memberikan output,
maka aplikasi tersebut juga bisa dianggap sebagai aktor.
Pengguna E-RKA dapat dibagi menjadi beberapa kelas

pengguna sesuai dengan yang terdefinisi pada tabel Tabel 2.14
pada dokumen SRS. Inilah yang akan menjadi aktor yang
terlibat pada use case.
Use case digambarkan sebagai lingkaran elips dengan nama

use case dituliskan didalam elips tersebut.
Asosiasi digunakan untuk menghubungkan aktor dengan use

case. Asosiasi digambarkan dengan sebuah garis yang
menghubungkan antara Aktor dengan Use case.
Dependency digambarkan berupa garis putus dengan

stereotype diatasnya. digunakan untuk menghubungkan use
case dengan use case. Dependency menggambarkan operasi
antar use case. Pada diagram ini digunakan tiga notasi
dependency, yaitu :
 Include digunakan untuk melanjutkan perilaku use case
sebelumnya.
 Extend, digunakan untuk memperluas perilaku use case
yang dituju. Karena sifatnya memperluas, maka extend
bersifat opsional, bisa terjadi bisa juga tidak.
Sebuah relasi generalization sepadan dengan sebuah relasi
inheritance pada konsep berorientasi obyek. Sebuah
generalization dilambangkan dengan sebuah panah dengan
kepala panah yang tidak solid yang mengarah ke kelas
“parent”- nya/induknya.
3.1.1 UCD.01 – Use Case Diagram User Management
Gambar 3. 1 Diagram Use Case User Management
3.1.1.1 UC.01.1 – Use Case Role User
Tabel 3.2 – Kartu Use Case Role User

Kode : UC.01.1
Nama Use Case : Role User
Deskripsi
User yang terlibat di Sistem E-RKA terbagi menjadi beberapa kelompok yang masing-masing
memiliki wewenang yang berbeda.
Pada aktivitas ini juga tersedia pengelolaan hak akses sistem.

Aktor :  Admin PPATK

Pre-Conditions :
User berhasil log in menggunakan user dan password yang
berlaku.
Skenario
User Sistem
1. Pengguna melakukan log in ke sistem
E-RKA
2. Sistem mencatat informasi pengguna ybs.
3. Sistem menampilkan menu utama berdasarkan
hak akses pengguna.
4. Memilih menu kelola Role.
5. Menampilkan daftar role yang sudah ada.
6. Melakukan penyuntingan role dan
menyimpannya.
7. Menyimpan perubahan yang dilakukan user.
8. Sistem mencatat id dan waktu penyimpanan
data oleh user.
9. User melihat respon dari sistem.
Post-Conditions :  Sistem berhasil menyimpan perubahan role.

 Perubahan role akan terlihat setelah user melakukan login ulang.
Exceptions
-
3.1.1.2 UC.01.2 – Use Case Manage User
Tabel 3.3 – Kartu Use Case Manage User

Kode : UC.01.2
Nama Use Case : Manage User
Deskripsi
Mengelola semua user yang terlibat dalam sisem E-RKA.
Aktor :  Admin PPATK

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. Pengguna melakukan log in ke sistem
E-RKA
hak akses pengguna.
4. Pengguna melihat daftar menu
administrasi pengguna
5. Pengguna memilih menu Kelola User,
melakukan administrasi pengguna
dan menyimpannya.
6. Sistem melakukan proses berdasarkan menu
administrasi yang dipilih oleh pengguna dan
menyimpan segala perubahan yang dilakukan.
7. Sistem mengirim notifikasi ke pengguna melalui
email.
data oleh user.
9. Pengguna melihat respon dari
sistem.
Post-Conditions :  Sistem berhasil menyimpan data perubahan user.

 User mendapatkan e-mail notifikasi.
 Khusus penghapusan, sistem tidak benar-benar menghapus data
dari storage, hanya memberikan flag saja sebagai data terhapus.
Exceptions
 Sistem menampilkan pesan kegagalan bila Admin PPATK tidak berhasil melakukan
administrasi pengguna.
3.1.2 UCD.02 – Use Case Diagram Master Management
Gambar 3. 2 Diagram Use Case Master Management
3.1.1.3 UC.02.1 – Use Case Kelola Eselon II
Tabel 3.4 – Kartu Use Case Kelola Eselon II

Kode : UC.02.1
Nama Use Case : Kelola Eselon II
Deskripsi
Aktor :  Operator

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. User melakukan log in ke sistem E-
RKA.

hak akses pengguna.
4. User memilih menu Kelola Eselon II.
5. Sistem menampilkan daftar Eselon II yang
sudah ada.
Kondisi 1 : User melakukan penambahan data
6. User memilih tombol Tambah Data
7. Sistem menampilkan form isian.
8. User mengisi form dan klik tombol
Simpan.
9. Sistem menyimpan segala perubahan yang
dilakukan.
data oleh user.
Kondisi 2 : User melakukan penyuntingan
6. User memilih salah satu data Eselon
II yang hendak disunting datanya,
kemudian menekan tombol Edit.
7. Sistem menampilkan form berisi data dari
Eselon II yang dipilih.
8. User melakukan perubahan data dan
klik tombol Simpan.
dilakukan.
data oleh user.
Kondisi 3 : User melakukan penghapusan
6. User memilih salah satu data Eselon
II yang hendak dihapus, kemudian
menekan tombol Hapus.
7. Sistem menampilkan konfirmasi penghapusan
untuk memastikan.
Kasus 3.1 : User memilih melanjutkan penghapusan
8. Sistem menghapus memberikan “flag” hapus
ke data yang dimaksud.
dilakukan.
data oleh user.
Kasus 3.2 : User membatalkan penghapusan
8. Sistem tidak melanjutkan proses

penghapusan dan menutup laman konfirmasi.
User kembali diarahkan ke skenario nomor 5.
data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Eselon II.
Exceptions

3.1.1.4 UC.02.2 – Use Case Kelola Kegiatan
Tabel 3.5 – Kartu Use Case Kelola Kegiatan

Kode : UC.02.2
Nama Use Case : Kelola Kegiatan
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
4. User memilih menu Kelola Kegiatan.
5. Sistem menampilkan daftar Kegiatan yang
sudah ada.
Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data
Kegiatan yang hendak disunting
datanya, kemudian menekan tombol
Edit.
Kegiatan yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
Kegiatan yang hendak dihapus,
kemudian menekan tombol Hapus.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Kegiatan.
Exceptions
3.1.1.5 UC.02.3 – Use Case Kelola Output
Tabel 3.6 – Kartu Use Case Kelola Output

Kode : UC.02.3
Nama Use Case : Kelola Output
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
4. User memilih menu Kelola Output.
5. Sistem menampilkan daftar Output yang sudah
ada.
Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data Output
yang hendak disunting datanya,
Output yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data Output
yang hendak dihapus, kemudian
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Output.
Exceptions

3.1.1.6 UC.02.4 – Use Case Kelola Program
Tabel 3.7 – Kartu Use Case Kelola Program

Kode : UC.02.4
Nama Use Case : Kelola Program
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
4. User memilih menu Kelola Program.
ada.
Simpan.
dilakukan.
data oleh user.
Program yang hendak disunting
datanya, kemudian menekan tombol
Edit.
Program yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
Program yang hendak dihapus,
kemudian menekan tombol Hapus.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Program.
Exceptions

3.1.1.7 UC.02.5 – Use Case Kelola Akun
Tabel 3.8 – Kartu Use Case Kelola Akun

Kode : UC.02.5
Nama Use Case : Kelola Akun
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
4. User memilih menu Kelola Akun.
ada.
Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data Akun
7. Sistem menampilkan form berisi data dari Akun
yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data Akun
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Akun.
Exceptions

3.1.1.8 UC.02.6 – Use Case Kelola Rencana Strategis
Tabel 3.9 – Kartu Use Case Kelola Rencana Strategis

Kode : UC.02.6
Nama Use Case : Kelola Rencana Strategis
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
ada.
Simpan.
dilakukan.
data oleh user.
Rencana Strategis yang hendak
disunting datanya, kemudian
menekan tombol Edit.
Rencana Strategis yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
Rencana Strategis yang hendak
dihapus, kemudian menekan tombol
Hapus.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data Rencana Strategis.
Exceptions

3.1.3 UCD.03 – Use Case Diagram Collection and Management
Gambar 3. 3 Diagram Use Case Collection and Management
3.1.1.9 UC.03.1 – Use Case Mengisi TOR
Tabel 3.10 – Kartu Use Case Mengisi TOR

Kode : UC.03.1
Nama Use Case : Mengisi TOR
Deskripsi
Aktor :  PIC

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
ada.
Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data TOR
7. Sistem menampilkan form berisi data dari TOR
yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Kondisi 4: User melakukan pencetakan
yang hendak dicetak, kemudian
memilih tommbol Cetak.
7. Sistem mencetak data TOR yang dipilih.
Post-Conditions :  Sistem berhasil menyimpan data TOR.

Exceptions

3.1.1.10 UC.03.2 – Use Case Mengisi RAB
Tabel 3.11 – Kartu Use Case Mengisi RAB

Kode : UC.03.2
Nama Use Case : Mengisi RAB
Deskripsi
Aktor :  PIC

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.

hak akses pengguna.
ada.
Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data RAB
7. Sistem menampilkan form berisi data dari RAB
yang dipilih.
klik tombol Simpan.
dilakukan.
data oleh user.
6. User memilih salah satu data RAB
untuk memastikan.
dilakukan.
data oleh user.
data oleh user.
Kondisi 4: User melakukan pencetakan

RAB yang hendak dicetak, kemudian
memilih tommbol Cetak.
9. Sistem mencetak data RAB yang dipilih.
Post-Conditions :  Sistem berhasil menyimpan data TOR.

Exceptions

3.1.4 UCD.04 – Use Case Diagram Reports Management and Statistic
Gambar 3. 4 Diagram Use Case Reports Management and Statistic

3.1.1.11 UC.04.1 – Use Case Aktifitas User
Tabel 3.12 – Kartu Use Case Lihat Aktifitas User

Kode : UC.04.1
Nama Use Case : Lihat Aktifitas User
Deskripsi
Setiap user akan tercatat segala aktivitasnya sejak dia log in sampai log out. Log activity ini
dibutuhkan sebagai kontrol jika terjadi hal-hal yang tidak diinginkan di masa datang.

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. Sistem mencatat dan menyimpan setiap

aktivitas user selama log in di dalam sistem E-
RKA.
2. User melakukan log in ke sistem

E-RKA.
4. Sistem menampilkan menu utama

berdasarkan hak akses pengguna.
5. User memilih menu Aktifitas

User.
6. User mencari nama pengguna

yang hendak dilihat aktivitasnya.
7. Sistem menampilkan historikal aktivitas

user dalam menggunakan E-RKA.
Post-Conditions :
Exceptions

3.1.1.12 UC.04.2 – Use Case Perjanjian Kinerja, TOR dan RAB
Tabel 3.13 – Kartu Use Case Lihat Perjanjian Kinerja, TOR dan RAB
Kode : UC.04.2
Nama Use Case : Lihat Perjanjian Kinerja, TOR dan RAB
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.

4. User memilih menu untuk

menampilkan laporan Perjanjian
Kinerja, TOR dan RAB.
5. User memilih periode pelaporan

beserta parameter filter lainnya yang
disediakan.
6. Sistem menampilkan data sesuai

parameter yang ditentukan.
Post-Conditions :
Exceptions

3.1.1.13 UC.04.3 – Use Case Program per Periode
Tabel 3.14 – Kartu Use Case Lihat Program per Periode

Kode : UC.04.3
Nama Use Case : Lihat Program per Periode
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
E-RKA.


menampilkan laporan Program per
Periode.

disediakan.

Post-Conditions :
Exceptions

3.1.1.14 UC.04.4 – Use Case Rencana Anggaran
Tabel 3.15 – Kartu Use Case Lihat Rencana Anggaran

Kode : UC.04.4
Nama Use Case : Lihat Rencana Anggaran
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


menampilkan laporan Rencana
Anggaran.
disediakan.

Post-Conditions :
Exceptions

3.1.1.15 UC.04.5 – Use Case Pelaporan per Jenis Akun
Tabel 3.16 – Kartu Use Case Lihat Pelaporan per Jenis Akun
Kode : UC.04.5
Nama Use Case : Lihat Pelaporan per Jenis Akun
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


menampilkan Pelaporan per Jenis
Akun.

disediakan.

Post-Conditions :
Exceptions

3.1.1.16 UC.04.6 – Use Case Statistik per Jenis Akun
Tabel 3.17 – Kartu Use Case Lihat Statistik per Jenis Akun
Kode : UC.04.6
Nama Use Case : Lihat Statistik per Jenis Akun
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


menampilkan Statistik per Jenis Akun.

disediakan.
6. Sistem menampilkan data berupa pie chart

sesuai parameter yang ditentukan.
Post-Conditions :
Exceptions

3.1.1.17 UC.04.7 – Use Case Statistik Anggaran per Jenis Akun
Tabel 3.18 – Kartu Use Case Lihat Statistik Anggaran per Jenis Akun
Kode : UC.04.7
Nama Use Case : Lihat Statistik per Jenis Akun
Deskripsi
Statistik anggaran dari masing-masing unit kerja.

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


menampilkan Statistik Anggaran per
Jenis Akun.

disediakan.
6. Sistem menampilkan data berupa pie chart

sesuai parameter yang ditentukan.
Post-Conditions :
Exceptions

3.1.5 UCD.05 – Use Case Diagram Penyusunan TOR dan RAB
Gambar 3. 5 Diagram Use Case Penyusunan TOR dan RAB.
3.1.1.18 UC.05.1 – Use Case Draft TOR dan RAB
Tabel 3.19 – Kartu Use Case Draft TOR dan RAB

Kode : UC.05.1
Nama Use Case : Draft TOR dan RAB
Deskripsi
Entry draft TOR dan RAB.

Pre-Conditions :
berlaku.
Skenario
User Sistem
RKA.
hak akses pengguna.
4. User memilih menu TOR.
5. Sistem menampilkan TOR yang sudah ada.
6. User memilih tambah data.
7. Sistem menampilkan form isian TOR.
8. User mengisi data sesuai urutan sbb:
Tahun Anggaran, Program, Kegiatan,
Output, Satuan Ukur dan Jenis
Keluaran, Volume, Narasi Gambaran
Umum, Manfaat dari Output,
Penerima Manfaat, Metode
Pelaksanaan, Suboutput (jika ada),
Tahapan, Waktu Pelaksanaan dan
Tabel Perhitungan.
9. User melakukan penyimpanan
10. Sistem menyimpan data TOR.
data oleh user.
12. User memilih tombol tambah RAB
13. Sistem menampilkan tabel RAB
14. User memilih tombol Tambah Sub
Komponen
15. Sistem menampilkan form sub komponen
dengan field kode akan otomatis terisi
berurutan sesuai abjad.
16. User memilih tombol Tanpa Sub
Komponen
17. Sistem akan otomatis mengisikan field uraian
dengan teks Tanpa Sub Komponen.
18. User melakukan penyimpanan.
19. Sistem menyimpan data RAB.
data oleh user.
Post-Conditions :  Sistem berhasil menyimpan data TOR dan RAB.
Exceptions

3.1.1.19 UC.05.2 – Use Case Penyusunan Konsep Dokumen
Tabel 3.20 – Kartu Use Case Penyusunan Konsep Dokumen

Kode : UC.05.2
Nama Use Case : Penyusunan Konsep Dokumen
Deskripsi
TOR dan RAB yang sudah di entry, dipersiapkan untuk diajukan.
Aktor :  PIC

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. User melakukan pengisian data TOR
dan RAB sesuai dengan skenario
pada use case [UC.05.1].
2. User memilih tombol penyuntingan
data untuk melakukan review.
3. User melakukan penyimpanan.
4. Sistem menyimpan data TOR dan RAB.
data oleh user.
Exceptions

3.1.1.20 UC.05.3 – Use Case Pengajuan Konsep Dokumen
Tabel 3.21 – Kartu Use Case Pengajuan Konsep Dokumen

Kode : UC.05.3
Nama Use Case : Pengajuan Konsep Dokumen
Deskripsi
TOR dan RAB yang sudah di entry dan di review, bisa langsung diajukan.
Aktor :  PIC

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. User melakukan pengisian data TOR
dan RAB sesuai dengan skenario
pada use case [UC.05.1] dan
[UC.05.2].
2. User memilih tombol Kirim.
3. Sistem akan mengirim data TOR untuk
diverifikasi.
4. Sistem mengubah status TOR dan menyimpan
data.
data oleh user.
Exceptions

3.1.1.21 UC.05.4 – Use Case Monitoring
Tabel 3.22 – Kartu Use Case Monitoring

Kode : UC.05.4
Nama Use Case : Monitoring
Deskripsi
TOR dan RAB yang sudah di entry dan diajukan dapat dilihat statusnya.
Aktor :  PIC
 Ketua Kelompok

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.

4. User memilih menu TOR.

5. Sistem menampilkan TOR yang sudah ada
beserta status pengajuannya.
Exceptions

3.1.1.22 UC.05.5 – Use Case Verifikasi
Tabel 3.23 – Kartu Use Case Verifikasi

Kode : UC.05.5
Nama Use Case : Verifikasi
Deskripsi
TOR dan RAB yang sudah diajukan dapat diverifikasi.
Aktor :  Ketua Kelompok

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.

4. User memilih menu Verifikasi.

5. Sistem menampilkan TOR final yang sudah
diajukan.
6. User memilih data untuk dilihat
detilnya.
7. Sistem menampilkan detil data TOR dan RAB
yang diajukan.
8. [Jika data sudah valid] User

memilih tombol Verifikasi.
9.
Sistem mengubah status TOR dan RAB menjadi
“Terverifikasi”.
data oleh user.
Post-Conditions :  Sistem berhasil merubah status pengajuan TOR dan RAB.
Exceptions

3.1.1.23 UC.05.6 – Use Case Persetujuan
Tabel 3.24 – Kartu Use Case Persetujuan

Kode : UC.05.6
Nama Use Case : Persetujuan
Deskripsi
TOR dan RAB yang sudah diverifikasi dapat langsung disetujui.
Aktor :  Ketua Kelompok

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.

4. User memilih menu Approval.

5. Sistem menampilkan TOR yang sudah
terverifikasi saja.
6. User memilih data untuk dilihat
detilnya.
7. Sistem menampilkan detil data TOR dan RAB
yang terverifikasi tersebut.
8. [Jika data sudah valid] User

memilih tombol Approve.
9. Sistem mengubah status TOR dan RAB menjadi
“Approved”.
data oleh user.
Post-Conditions :  Sistem berhasil merubah status pengajuan TOR dan RAB.
Exceptions

3.1.6 UCD.06 – Use Case Diagram Logs Management
Gambar 3. 6 Diagram Use Case Logs Management.
3.1.1.24 UC.06.1 – Use Case Pencatatan Waktu Login/Logout
Tabel 3.25 – Kartu Use Case Pencatatan Waktu Login/Logout

Kode : UC.06.1
Nama Use Case : Pencatatan Waktu Login/Logout
Deskripsi
Sistem mencatat waktu login dan logout dari user.
Aktor :  All User

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. User melakukan log in ke atau

log out dari sistem E-RKA.
Post-Conditions :  Sistem mencatat waktu login/logout.
Exceptions

3.1.1.25 UC.06.2 – Use Case Pencatatan Waktu Isi/Update Data
Tabel 3.26 – Kartu Use Case Pencatatan Waktu Isi/Update Data

Kode : UC.06.2
Nama Use Case : Pencatatan Waktu Isi/Update Data
Deskripsi
Sistem mencatat id dan waktu dari user pada saat melakukan penyimpanan data.

Pre-Conditions :
berlaku.
Skenario
User Sistem
1. User melakukan penyimpanan

data di suatu menu dalam
lingkungan sistem E-RKA.
2.
Sistem mencatat id dan waktu penyimpanan
data oleh user.
Post-Conditions :  Sistem mencatat waktu penyimpanan data.
Exceptions

3.1.7 UCD.07 – Use Case Diagram Statistic
Gambar 3. 7 Diagram Use Case Statistic
3.1.1.26 UC.07.1 – Use Case Statistik per Unit Kerja
Tabel 3.27 – Kartu Use Case Lihat Statistik per Unit Kerja
Kode : UC.07.1
Nama Use Case : Lihat Statistik per Unit Kerja
Deskripsi
Statistik jumlah anggaran tiap unit kerja per tahun (selama 5 tahun).

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.

menampilkan Statistik Jumlah
Anggaran per Unit Kerja per Tahun.
5. Sistem menampilkan data statistik.
Post-Conditions :
Exceptions

3.1.1.27 UC.07.2 – Use Case Statistik per Belanja Pegawai
Tabel 3.27 – Kartu Use Case Lihat Statistik per Belanja Pegawai
Kode : UC.07.2
Nama Use Case : Lihat Statistik per Belanja Pegawai
Deskripsi
Statistik jumlah anggaran belanja pegawai.

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


Anggaran Belanja Pegawai.
Post-Conditions :
Exceptions

3.1.1.28 UC.07.3 – Use Case Statistik per Operasional Perkantoran
Tabel 3.28 – Kartu Use Case Lihat Statistik per Operasional Perkantoran
Kode : UC.07.3
Nama Use Case : Lihat Statistik per Operasional Perkantoran
Deskripsi
Statistik jumlah anggaran operasional perkantoran.

Pre-Conditions :
berlaku.
Skenario
User Sistem

E-RKA.


Anggaran Belanja Operasional
Perkantoran.
Post-Conditions :
Exceptions

4. Data Desain
Merancang data merupakan tentang menemukan dan mendefinisikan

karakteristik dan proses dari suatu aplikasi. Desain data adalah proses
perbaikan yang bertahap, dari pertanyaan kasar "Data apa yang aplikasi Anda
butuhkan?" dengan struktur data yang tepat dan proses yang disediakannya.
Dengan desain data yang baik, akses data aplikasi akan cepat, mudah
dipelihara, dan dapat menerima tambahan data di masa depan.
Gambar 3. 8 Diagram Relasi Basis Data Aplikasi E-RKA.
Untuk desain basis data yang digunakan oleh sistem E-RKA ini dapat dilihat
selengkapnya pada Lampiran B.

T.2.2 Template Spesifikasi Disain SIPATUH

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

T.2.2 Template Spesifikasi Disain SIPATUH

Diunggah oleh

Hak Cipta:

Format Tersedia

Template.2.2(T.2.

Dilakukan Oleh: Tanda Tangan

Tanggal Versi Keterangan Revisi Alasan Revisi

Template Spesifikasi Disain T.2.2

Modul yang ada pada aplikasi SIPATUH eksisting, dapat digambarkan

Gambar 1.Modul SIPATUH existing

Catatan: modul 1 sd. 4 merupakan modul audit On-Site

Seiring dengan berjalannya waktu terdapat perubahan peraturan dan

Salah satu perubahan peraturan yang berdampak pada aplikasi SIPATUH

Kemudian ada juga kegiatan DPK yang sebelumnya belum difasilitasi

Dengan adanya perubahan tersebut, maka modul yang ada di

1.4. Ruang Lingkup

b) SIPATUH Backend= Aplikasi existing yang berbasis web. Dibangun

Berikut konfigurasi aplikasi SIPATUH

Webserver : Apache 2.0

Application : PHP 5, Jquery, framework codeigniter 3.0

Database : MSSQL Server

Desain / Layout : Twitter Bootstrap, HTML 5, CSS 3

Gambar 2. 2 Konfigurasi Aplikasi

2.2. Asumsi dan Dependensi

1) Data User yang sudah didaftarkan sebagai sarana bantu untuk:

3.1 Use Case Diagram

Diagram Use Case menggambarkan aktor dengan sekumpulan aksi yang

Tabel 3.1 – Simbol Diagram Use Case

Aktor adalah pengguna sistem. Aktor tidak terbatas hanya

Pengguna E-RKA dapat dibagi menjadi beberapa kelas

Use case digambarkan sebagai lingkaran elips dengan nama

Asosiasi digunakan untuk menghubungkan aktor dengan use

Dependency digambarkan berupa garis putus dengan

3.1.1 UCD.01 – Use Case Diagram User Management

Gambar 3. 1 Diagram Use Case User Management

3.1.1.1 UC.01.1 – Use Case Role User

Tabel 3.2 – Kartu Use Case Role User

Pada aktivitas ini juga tersedia pengelolaan hak akses sistem.

Post-Conditions :  Sistem berhasil menyimpan perubahan role.

3.1.1.2 UC.01.2 – Use Case Manage User

Tabel 3.3 – Kartu Use Case Manage User

Post-Conditions :  Sistem berhasil menyimpan data perubahan user.

3.1.2 UCD.02 – Use Case Diagram Master Management

Gambar 3. 2 Diagram Use Case Master Management

3.1.1.3 UC.02.1 – Use Case Kelola Eselon II

Tabel 3.4 – Kartu Use Case Kelola Eselon II

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

3.1.1.4 UC.02.2 – Use Case Kelola Kegiatan

Tabel 3.5 – Kartu Use Case Kelola Kegiatan

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

3.1.1.5 UC.02.3 – Use Case Kelola Output

Tabel 3.6 – Kartu Use Case Kelola Output

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

3.1.1.6 UC.02.4 – Use Case Kelola Program

Tabel 3.7 – Kartu Use Case Kelola Program

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

3.1.1.7 UC.02.5 – Use Case Kelola Akun

Tabel 3.8 – Kartu Use Case Kelola Akun

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

3.1.1.8 UC.02.6 – Use Case Kelola Rencana Strategis

Tabel 3.9 – Kartu Use Case Kelola Rencana Strategis

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses