Template Spesifikasi Disain: (Nama Aplikasi)

Template.2.2(T.2.
2)
Template
Spesifikasi Disain
[NamaAplikasi]
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 Perencanaan Keuangan ini adalah aplikasi yang dirancang untuk
membantu tugas pokok dan fungsi Biro Perencanaan dan Keuangan dalam
rangka pengelolaan usulan rencana kerja dan anggaran unit kerja di PPATK
untuk tahun berikutnya. Aplikasi ini diharapkan dapat terintegrasi dengan
sistem informasi yang ada di PPATK dan Aplikasi yang dikembangkan oleh
Kementerian Keuangan RI
1.2. Tujuan
Tujuan dari dokumen ini adalah untuk menjelaskan deskripsi dari Sistem
Informasi E-RKA secra detail. Dokumen ini akan menjelaskan tujuan dan fitur
dari sistem, interface dari sistem, apa yang sistem lakukan, batasan dimana
sistem beroperasi dan bagaimana sistem berinteraksi.
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 E-RKA ini berbentuk web karena akan diakses oleh setiap unit
kerja yang menangani perencanaan kegiatan, ketua kelompok, pejabat eselon
II, dan pejabat eselon I. Adapun pembagian kewenangan pengguna aplikasi ini
sebagai berikut:
a. PIC masing – masing unit kerja yang menangani Rencana Kerja, yaitu
yang bertugas pada level pembuatan konsep dokumen.
b. Ketua Kelompok / Kepala Bagian yang menangani administrasi dan
bertugas sebagai verifikasi konsep dokumen.
c. Direktur / Pejabat Eselon 2 yang bertugas sebagai approver dokumen
unit kerja.
d. Pejabat Eselon 1 yang bertugas untuk memberikan arahan dan
pemantauan.
e. PA dan KPA berwenang menyetujui usulan seluruh unit kerja.
f. Seluruh Staf bagian Perencanaan dan Penganggaran yang bertugas
untuk mengelola dokumen.
g. Operator (Staf Bagian Perencanaan dan Penganggaran) yang bertugas
untuk memasukan master data.
2. Arsitektur Sistem
2.1. Arsitektur Sistem
Berikut konfigurasi aplikasi E-RKA
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 – Perencanaan Audit
Gambar 3. 1 Diagram Use Case Perencanaan Audit
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 Pra Audit
Gambar 3. 2 Diagram Use Case Pra Audit
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
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.
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 Pelaksanaan
Gambar 3. 3 Diagram Use Case Pelaksanaan
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 Pasca Audit
Gambar 3. 4 Diagram Use Case Pasca Audit
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 Pemantauan
Gambar 3. 5 Diagram Use Case Pemantauan
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.
3.1.1.29 UC.02.1 – Use Case Master Data Akun

Tabel 3.4 – Kartu Use Case Master Data Akun
Kode : UC.02.1
Nama Use Case : Master Data Akun
Deskripsi
Aktor :  Administrator

Pre-Conditions :
berlaku.
Skenario
User Sistem
Sipatuh.

hak akses pengguna.
4. User memilih menu Master Data
Akun.
5. Sistem menampilkan daftar Akun yang sudah
ada.
6. User memilih tombol Add Document
Simpan.
dilakukan.
data oleh user.
II yang hendak disunting datanya,
klik tombol Simpan.
dilakukan.
data oleh user.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Post-Conditions :  Sistem berhasil menyimpan Data Akun.
Exceptions

3.1.1.30 UC.02.2 – Use Case Master Data Anggaran POK
Tabel 3.4 – Kartu Use Case Master Data Anggaran POK

Kode : UC.02.1
Nama Use Case : Master Data Anggarn POK
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
Sipatuh.

hak akses pengguna.
Anggaran POK.
5. Sistem menampilkan daftar Anggaran POK yang
sudah ada.
Simpan.
dilakukan.
data oleh user.
Anggaran POK yang hendak
klik tombol Simpan.
dilakukan.
data oleh user.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Exceptions

1.1.1.1 UC.02.3 – Use Case Master Data User
1.1.1.2 UC.02.4 – Use Case Master Data Role
1.1.1.3 UC.02.5 – Use Case Master Data Auditor
1.1.1.4 UC.02.6 – Use Case Master Data Auditee
Tabel 3.4 – Kartu Use Case Master Data Auditee

Kode : UC.02.6
Nama Use Case : Master Data Auditee
Deskripsi

Pre-Conditions :
berlaku.
Skenario
User Sistem
Sipatuh.

hak akses pengguna.
Auditee.
5. Sistem menampilkan Daftar Data Auditee yang
sudah ada.
Tambah Baru.
dilakukan.
data oleh user.
Anggaran POK yang hendak
klik tombol Simpan.
dilakukan.
data oleh user.
untuk memastikan.
dilakukan.
data oleh user.

data oleh user.
Exceptions

1.1.1.5 UC.02.7 – Use Case Master Data Golongan
1.1.1.6

Template Spesifikasi Disain: (Nama Aplikasi)

Diunggah oleh

Informasi Dokumen

Judul Asli

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

Template Spesifikasi Disain: (Nama Aplikasi)

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

1.3. Konvensi Dokumen

1.4. Ruang Lingkup

Berikut konfigurasi aplikasi E-RKA

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

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 – Perencanaan Audit

Gambar 3. 1 Diagram Use Case Perencanaan Audit

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 Pra Audit

Gambar 3. 2 Diagram Use Case Pra Audit

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

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

Gambar 3. 3 Diagram Use Case Pelaksanaan

3.1.1.9 UC.03.1 – Use Case Mengisi TOR

Tabel 3.10 – Kartu Use Case Mengisi TOR

2. Sistem mencatat informasi pengguna ybs.

8. Sistem tidak melanjutkan proses

Post-Conditions :  Sistem berhasil menyimpan data TOR.