analisis kebutuhan sistem pengaduan masyarakat...
Post on 31-Jul-2020
3 Views
Preview:
TRANSCRIPT
ANALISIS KEBUTUHAN
SISTEM PENGADUAN MASYARAKAT (SPM)
ONLINE DPR RI
BERORIENTASI SASARAN
DENGAN METODE SAR, R2G, DAN KAOS
SKRIPSI
Oleh:
Shofan Amirudin
NIM: 11150910000006
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI
SYARIF HIDAYATULLAH
JAKARTA
2019 M / 1441 H
ANALISIS KEBUTUHAN
SISTEM PENGADUAN MASYARAKAT (SPM)
ONLINE DPR RI
BERORIENTASI SASARAN
DENGAN METODE SAR, R2G, DAN KAOS
Skripsi
Diajukan sebagai salah satu syarat untuk memperoleh gelar
Sarjana Komputer (S.Kom)
Oleh:
Shofan Amirudin
NIM: 11150910000006
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI
SYARIF HIDAYATULLAH
JAKARTA
2019 M / 1441 H
ii
PERNYATAAN ORISINALITAS
iii
LEMBAR PERSETUJUAN
iv
PENGESAHAN UJIAN
v
KATA PENGANTAR
Bismillaahirrahmaanirrahiim.
Assalamu’alaikum Wr. Wb.
Puji syukur senantiasa dipanjatkan kehadirat Allah SWT yang telah
melimpahkan rahmat, hidayah serta nikmat-Nya sehingga penyusunan skripsi ini
dapat diselesaikan. Sholawat dan salam senantiasa dihaturkan kepada junjungan
kita baginda Nabi Muhammad Shalallahu Alaihi Wassalam beserta keluarganya,
para sahabatnya serta umatnya hingga akhir zaman. Penulisan skripsi ini
mengambil judul:
ANALISIS KEBUTUHAN SISTEM PENGADUAN (SPM) ONLINE DPR RI
BERORIENTASI SASARAN DENGAN METODE SAR, R2G, DAN KAOS
Penyusunan skripsi ini adalah salah satu syarat untuk memperoleh gelar
Sarjana Komputer (S.Kom) pada program studi Teknik Informatika, Fakultas Sains
dan Teknologi, Universitas Islam Negeri Syarif Hidayatullah Jakarta.
Dalam penyusunan skripsi ini, telah banyak bimbingan, bantuan yang penulis
dapatkan dari berbagai pihak sehingga skripsi ini dapat selesai dengan lancer. Oleh
karena itu, penulis ingin mengucapkan terimakasih kepada:
1. Prof. Dr. Lily Suraya Eka Putri, M.Env.Stud selaku dekan Fakultas Sains
dan Teknologi.
2. Dr. Imam Marzuki Shofi selaku Ketua Program Studi Teknik Informatika
sekaligus Dosen Pempimbing I penulis, yang telah meluangkan waktu dan
memberikan bimbingan, dan semangat dalam menyelesaikan skripsi ini.
3. Nurul Faizah Rozy, MTI, selaku Dosen Pembimbing II penulis, yang
senantiasa membimbing penulis, meluangkan waktu, memberikan
bantuan, semangat, dan motivasi untuk penulis agar dapat menyelesaikan
skripsi ini.
4. Pihak Bagian Pengaduan Masyarakat Sekretariat Jenderal DPR RI,
khususnya Bapak Yadin selaku Kasubbag Analisis Pengaduan
vi
Masyarakat II yang telah bersedia membantu penulis dalam
mengumpulkan data yang penulis butuhkan.
5. Keluarga tercinta, Bapak, Ibu, Mba Alfia, Mas Arif, dan Ka Desi yang
senantiasa mendukung dan medoakan penulis agar dapat menyelesaikan
skripsi ini.
6. Keluarga besar HIMTI UIN Jakarta, terkhusus sahabat seperjuangan di
HIMTI, yaitu Kunhadji, Ririn, Ayu, Irfan, Dhimas, Fahmi, Isma, Putnav,
dan yang lainnya yang tidak dapat disebutkan satu persatu, namun tidak
mengurasi rasa terimakasih yang penulis ingin sampaikan.
7. Sahabat-sahabat penulis, yaitu Faisal, Mahfudz, Rifky, Ilham, Bagus, dan
Dafa yang telah membantu penulis dan menjadi teman diskusi penulis
selama ini.
8. Keluarga besar Istana Belajar Anak Banten (ISBANBAN), khususnya
ISBANBAN Chapter Kota Tangerang Selatan yang tidak dapat penulis
sebutkan namanya satu persatu, terimakasih atas motivasi, dan doa yang
telah diberikan selama ini.
9. Seluruh pihak yang tidak dapat disebutkan satu persatu yang telah
membantu, dan memberikan saran dalam penyusunan skripsi ini.
Penulisan skripsi ini masih jauh dari kata sempurna. Untuk itu, sangat
diperlukan kritik dan saran yang membangun bagi penulis. Akhir kata, semoga
skripsi ini dapat bermanfaat bagi penulis dan orang lain.
Jakarta, 28 Oktober 2019
Shofan Amirudin
vii
PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI
Sebagai civitas akademik UIN Syarif Hidayatullah Jakarta, saya yang bertanda
tangan dibawah ini:
Nama : Shofan Amirudin
NIM : 11150910000006
Program Studi : Teknik Informatika
Fakultas : Sains dan Teknologi
Jenis Karya : Skripsi
demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada
Universitas Islam Negeri Syarif Hidayatullah Jakarta Hak Bebas Royalti
Noneksklusif (Non-exclusive Royalty Free Right) atas karya ilmiah saya yang
berjudul:
ANALISIS KEBUTUHAN
SISTEM PENGADUAN MASYARAKAT (SPM) ONLINE DPR RI
BERORIENTASI SASARAN DENGAN METODE SAR, R2G, DAN KAOS
Dengan Hak Bebas Royalti Non-eksklusif ini Universitas Islam Negeri Syarif
Hidayatullah Jakarta berhak menyimpan, mengalih media/formatkan, mengelola
dalam bentuk pangkalan data (database), merawat dan mempublikasikan tugas
akhir saya selama tetap mencantumkan nama saya sebagai penulis/pencipta dan
sebagai pemilik Hak.
Jakarta, 28 Oktober 2019
Yang menyatakan,
(Shofan Amirudin)
viii
Penulis : Shofan Amirudin
NIM : 11150910000006
Program Studi : Teknik Informatika
Judul : ANALISIS KEBUTUHAN SISTEM PENGADUAN MASYARAKAT
(SPM) ONLINE DPR RI BERORIENTASI SASARAN DENGAN
METODE SAR, R2G, DAN KAOS
ABSTRAK
DPR adalah lembaga negara yang salah satu kewajibannya adalah
menampung dan menindaklanjuti aspirasi dan pengaduan masyarakat. Sistem
Pengaduan Masyarakat (SPM) Online DPR RI adalah salah satu media yang dapat
digunakan masyarakat untuk memberikan pengaduannya kepada DPR. Melalui
wawancara dengan ahli sistem, saat ini SPM Online DPR RI (system-as-is) masih
perlu dikembangkan, sehingga perlu dilakukan analisis lebih mendalam terhadap
sistem tersebut. Analisis dilakukan menggunakan metode GORE (Goal Oriented
Requirements Engineering), yaitu SAR (Select Appropriate Regulations), R2G
(Regulations to Goal Model), dan KAOS (Keep All Objectives Satisfied). Hasil
analisis yang telah dilakukan menunjukkan bahwa metode SAR, R2G, dan KAOS
terbukti sesuai jika digunakan untuk menganalisis kebutuhan SPM Online DPR RI.
Selain itu, hasil analisis menunjukkan bahwa system-as-is hanya dapat
merealisasikan 13 kebutuhan sistem atau setara 81,25% dari total 16 kebutuhan
sistem yang sesungguhnya diinginkan (system-to-be), artinya system-as-is belum
optimal, karena terdapat kesenjangan yang terjadi antara system-as-is dengan
system-to-be sebesar 3 kebutuhan sistem atau 18,75%.
Kata Kunci : Analisis, Requirements Engineering, GORE, DPR, Pengaduan,
SAR, R2G, KAOS.
Daftar Pustaka : 9 buku, 11 jurnal, dan 1 website
Jumlah Halaman : 129 halaman + xv halaman
ix
Name : Shofan Amirudin
NIM : 11150910000006
Study Program: Teknik Informatika
Title : ANALISIS KEBUTUHAN SISTEM PENGADUAN MASYARAKAT
(SPM) ONLINE DPR RI BERORIENTASI SASARAN DENGAN
METODE SAR, R2G, DAN KAOS
ABSTRACT
The DPR is a state institution whose obligations are to accommodate and act
on people's aspirations and complaints. Sistem Pengaduan Masyarakat (SPM)
Online DPR RI is one of the media that can be used by the public to provide
complaints to the DPR. Through interviews with system experts, the current SPM
Online DPR RI (system-as-i) still needs to be developed, so it needs to be done a
more in-depth analysis of the system. The analysis was performed using the GORE
(Goal Oriented Requirements Engineering), namely SAR (Select Appropriate
Regulations), R2G (Regulations to Goal Model), and KAOS (Keep All Objectives
Satisfied). The results of the analysis that have been carried out show that the SAR,
R2G, and KAOS methods are proven to be suitable if used to analyze the needs of
the Republic of Indonesia DPR's Online SPM Online. Furthermore, the analysis
shows that system-as-is can only realize 13 system requirements or equal to 81.25%
of the total 16 actual system needs (system-to-be), meaning that system-as-is not
optimal, because there is a gap between system-as-is and system-to-be of 3 system
requirements or 18.75%.
Keyword : Analysis, Requirements Engineering, GORE, DPR, Complaint, SAR, R2G,
KAOS.
x
DAFTAR ISI
PERNYATAAN ORISINALITAS ...................................................................... ii
LEMBAR PERSETUJUAN ................................................................................ iii
PENGESAHAN UJIAN ....................................................................................... iv
KATA PENGANTAR ............................................................................................ v
PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI ............................ vii
ABSTRAK .......................................................................................................... viii
ABSTRACT .......................................................................................................... ix
DAFTAR ISI ........................................................................................................... x
DAFTAR GAMBAR .......................................................................................... xiii
DAFTAR TABEL ................................................................................................ xv
BAB 1 PENDAHULUAN ..................................................................................... 1
Latar Belakang ............................................................................................. 1
Tujuan Penelitian .......................................................................................... 4
Manfaat Penelitian ........................................................................................ 5
1.3.1. Bagi Mahasiswa ..................................................................................... 5
1.3.2. Bagi Universitas..................................................................................... 5
Rumusan Masalah ........................................................................................ 5
Batasan Masalah ........................................................................................... 5
1.5.1. Metode ................................................................................................... 5
1.5.2. Tools ...................................................................................................... 5
1.5.3. Proses ..................................................................................................... 5
Metodologi Penelitian .................................................................................. 6
1.6.1. Metode Pengumpulan Data.................................................................... 6
Sistematika Penulisan ................................................................................... 6
BAB 2 TINJAUAN PUSTAKA DAN LANDASAN TEORI ............................. 8
Requirements Engineering (RE) .................................................................. 8
2.1.1. Artefact-Driven Elicitation Techniques ............................................... 10
2.1.2. Stakeholder-Driven Elicitation Techniques ......................................... 13
Goal Oriented Requirements engineering (GORE) ................................... 15
2.2.1. Goal, Requirements, Expectations, dan Agent..................................... 16
xi
2.2.2. Metode-metode dalam GORE ............................................................. 18
Metode KAOS ............................................................................................ 22
2.3.1. Goal Model .......................................................................................... 24
2.3.2. Responsibility Model ........................................................................... 27
2.3.3. Object Model ....................................................................................... 30
2.3.4. Operation Model .................................................................................. 32
Metode SAR dan R2G ................................................................................ 35
2.4.1. Metode SAR (Select Appropriate Regulations) .................................. 37
2.4.2. Metode R2G (Regulations to Goal Model) ......................................... 39
Sistem Pengaduan Masyarakat ................................................................... 43
2.5.1. Definisi Sistem .................................................................................... 43
2.5.2. Karakterteristik Sistem ........................................................................ 44
2.5.3. Klasifikasi Sistem ................................................................................ 46
2.5.4. Pengaduan Masyarakat ........................................................................ 47
Metode Pengumpulan data ......................................................................... 48
2.6.1. Studi Pustaka ....................................................................................... 48
2.6.2. Observasi ............................................................................................. 48
2.6.3. Wawancara .......................................................................................... 49
Analisis Kesenjangan ................................................................................. 50
Tinjauan Pustaka (Literature Review) ........................................................ 51
BAB 3 METODOLOGI PENELITIAN ............................................................ 57
Metode Pengumpulan Data ........................................................................ 57
3.1.1. Studi Pustaka ....................................................................................... 57
3.1.2. Observasi ............................................................................................. 57
3.1.3. Wawancara .......................................................................................... 57
Metode KAOS ............................................................................................ 58
3.2.1. Membangun Goal Model ..................................................................... 58
3.2.2. Membangun Responsibility Model ...................................................... 58
3.2.3. Validasi Goal Model ............................................................................ 58
3.2.4. Validasi Responsibility Model ............................................................. 59
Metode SAR dan R2G ................................................................................ 59
3.3.1. Metode SAR (Select Appropriate Regulations) .................................. 59
3.3.2. Metode R2G (Regulations to Goal Model) ......................................... 59
xii
Analisis Kesenjangan (Gap Analysis) ........................................................ 60
Kerangka Berpikir ...................................................................................... 61
BAB 4 ANALISIS SISTEM ............................................................................... 62
Analisis System-as-is (SPM Online DPR RI yang sedang berjalan) .......... 62
4.1.1. Analisis Dokumen (Studi Latar Belakang) .......................................... 62
4.1.2. Analisis Hasil Observasi ...................................................................... 63
4.1.3. Analisis Hasil Wawancara ................................................................... 74
4.1.4. Pemodelan Goal Model System-as-is .................................................. 76
4.1.5. Pemodelan Responsibility Model System-as-is .................................... 88
Penentuan Dokumen Regulasi (Metode SAR) ........................................... 90
Mengektraksi Dokumen Regulasi (Metode R2G) ...................................... 92
4.3.1. Prosedur Umum ................................................................................... 92
4.3.2. Prosedur Ekstraksi ............................................................................... 94
Analisis System-to-be ................................................................................. 96
4.4.1. Pemodelan Goal Model System-to-be .................................................. 96
4.4.2. Pemodelan Responsibility Model System-to-be ................................. 101
4.4.3. Analisis Kebutuhan System-to-be ...................................................... 102
Analisis System-to-be Akhir (Setelah validasi) ........................................ 109
4.5.1. Pemodelan Goal Model System-to-be Akhir ..................................... 109
4.5.2. Pemodelan Responsibility Model System-to-be Akhir ....................... 109
BAB 5 HASIL DAN PEMBAHASAN ............................................................. 110
Pemodelan Kesenjangan........................................................................... 110
Analisis Kesenjangan ............................................................................... 112
BAB 6 PENUTUP ............................................................................................. 114
Kesimpulan ............................................................................................... 114
Saran ......................................................................................................... 114
DAFTAR PUSTAKA ......................................................................................... 115
LAMPIRAN ........................................................................................................ 118
xiii
DAFTAR GAMBAR
Gambar 2.1 Tiga Dimensi Requirements Engineering ........................................... 9
Gambar 2.2 Aktivitas Menemukan Goal .............................................................. 15
Gambar 2.3 Empat Model yang Ada Pada KAOS ................................................ 24
Gambar 2.4 A Goal Model .................................................................................... 27
Gambar 2.5 Contoh Responsibility Model dari Sistem Elevator .......................... 28
Gambar 2.6 Contoh Responsibility Model dari Agen Elevator Company ........... 29
Gambar 2.7 Contoh Object Model “Alarm Bell” ................................................. 31
Gambar 2.8 Hubungan concerns “Alarm Bell” .................................................... 31
Gambar 2.9 Contoh Object Model dari Sistem Elevator ...................................... 32
Gambar 2.10 Contoh Operation Model ................................................................ 34
Gambar 2.11 Aplikasi Bisnis vs Aplikasi Kepemerintahan .................................. 36
Gambar 2.12 Pyramid Model ................................................................................ 36
Gambar 2.13 Input dan Output Metode SAR ....................................................... 37
Gambar 2.14 Langkah-langkah Metode SAR ....................................................... 38
Gambar 2.15 Input dan Output Metode R2G ........................................................ 39
Gambar 2.16 Pembagian Prosedur Metode R2G .................................................. 40
Gambar 2.17 Langkah-langkah Metode R2G ....................................................... 43
Gambar 2.18 Karakteristik Dari Suatu Sistem ...................................................... 46
Gambar 3.1 Kerangka Berpikir ............................................................................. 61
Gambar 4.1 Contoh tampilan system-as-is ........................................................... 64
Gambar 4.2 Alert Sistem Ketika Nama Pengguna dan Password Tidak Terdaftar
............................................................................................................................... 68
Gambar 4.3 Back End SPM Online DPR RI saat ini (system-as-is) .................... 69
Gambar 4.4 Strategic Goal dan Goal Turunannya ................................................ 77
Gambar 4.5 Mengelola Data Pengaduan Masyarakat yang Masuk dan
Tindaklanjutnya .................................................................................................... 78
Gambar 4.6 Mengelola Data Pengaduan yang Masuk .......................................... 79
Gambar 4.7 Data Pengaduan Masyarakat Dapat Dihapus .................................... 80
Gambar 4.8 Menampilkan Informasi Cara Pengiriman Pengaduan Masyarakat .. 81
Gambar 4.9 Menampung Pengaduan Masyarakat ................................................ 82
Gambar 4.10 Kerahasiaan Data Pengaduan Masyarakat Terjaga ......................... 83
Gambar 4.11 Data Pengaduan Masyarakat Ditampilkan ...................................... 84
Gambar 4.12 Mengelola Data dan Informasi Tindaklanjut Pengaduan Masyarakat
............................................................................................................................... 84
Gambar 4.13 Hasil Analisis Pengaduan Masyarakat Dapat Dituliskan ................ 85
Gambar 4.14 Menampilkan Informasi Tindaklanjut Pengaduan Masyarakat ...... 86
Gambar 4.15 Goal Model System-as-is ................................................................ 87
Gambar 4.16 Responsibility Model untuk Masyarakat ........................................ 88
Gambar 4.17 Responsibility Model untuk Sekretariat AKD ................................ 88
Gambar 4.18 Responsibility Model untuk Pengadministrasi Umum ................... 88
Gambar 4.19 Responsibility Model untuk Sistem ................................................ 89
Gambar 4.20 Goal Diagram Berdasarkan Dokumen Regulasi ............................. 96
xiv
Gambar 4.21 Goal Model dari System-to-be ...................................................... 100
Gambar 4.22 Responsibility Model dari System-to-be untuk Sistem ................. 101
Gambar 4.23 Responsibility Model dari System-to-be untuk Masyarakat ......... 101
Gambar 4.24 Responsibility Model dari System-to-be untuk Sekretariat AKD. 101
Gambar 4.25 Responsibility Model dari System-to-be untuk Pengadministrasi
Umum ................................................................................................................. 102
Gambar 4.26 Tampilan Form Input nama pengadu ............................................ 105
Gambar 5.1 Pemodelan Kesenjangan Antara System-as-is dengan System-to-be
............................................................................................................................. 111
xv
DAFTAR TABEL
Tabel 2.1 Perbandingan Metode yang ada dalam GORE ..................................... 19
Tabel 2.2 Penelitian Sejenis .................................................................................. 51
Tabel 2.3 Perbedaan Penelitian ............................................................................. 54
Tabel 4.1 Hierarki Peraturan Perundang-undangan Terkait SPM Online DPR RI 91
Tabel 4.2 Kandidat Goal pada UU No. 2 Tahun 2018 tentang Perubahan Kedua
atas UU No. 17 Tahun 2014 tentang MPR, DPR, DPD, dan DPRD .................... 94
Tabel 4.3 Peraturan Presiden No. 27 Tahun 2015 tentang Sekretariat Jenderal dan
Badan Keahlian DPR RI ....................................................................................... 95
Tabel 4.4 Peraturan Sekretaris Jenderal DPR RI No. 7 Tahun 2018 tentang Peru-
bahan Kedua atas Peraturan Sekretaris Jenderal DPR RI No. 6 Tahun 2015 tenta-
ng Organisasi dan Tata Kerja Sekretariat Jenderal dan Badan Keahlian DPR RI 95
Tabel 5.1 Hasil Realisasi Kebutuhan System-as-is ............................................. 112
1
BAB 1
PENDAHULUAN
Latar Belakang
Dewan Perwakilan Rakyat (DPR) adalah lembaga negara dalam sistem
ketatanegaraan Republik Indonesia yang merupakan lembaga perwakilan rakyat
dan memegang kekuasaan membentuk Undang-Undang (Ubaedillah, 2015). Salah
satu kewajiban dari anggota DPR RI adalah menampung dan menindaklanjuti
aspirasi dan pengaduan masyarakat (Simbolon, 2019). Saat ini, untuk
melaksanakan kewajiban dalam menampung pengaduan masyarakat, DPR telah
menyediakan 3 media yang dapat digunakan masyarakat untuk memberikan
pengaduannya kepada DPR RI, yaitu melalui Sistem Pengaduan Masyarakat (SPM)
Online, melalui surat tertulis, dan dengan datang langsung ke kantor DPR. (DPR
RI, 2019).
SPM Online yang dibuat oleh DPR RI dapat diakses di
www.pengaduan.dpr.go.id. Pada sistem tersebut tertera mengenai keterangan dan
informasi yang dibutuhkan oleh masyarakat ketika ingin mengisi form pengaduan
online yang disediakan di dalam sistem. Informasi tersebut meliputi daftar alat
kelengkapan dewan dan ruang lingkupnya, syarat pengaduan, alur proses
pengaduan, serta Standar Operasional Prosedur (SOP) pengaduan.
Saat ini, tidak semua aduan masyarakat yang masuk ditindaklanjuti oleh
anggota DPR RI. Dari 584 pengaduan yang masuk melalui SPM Online DPR RI
pada tahun sidang 2017-2018, yang ditindaklanjuti atau diteruskan ke Alat
Kelengkapan Dewan (AKD) terkait hanya 379 pengaduan (DPR RI, 2018).
Menurut Bapak Yadin, ada beberapa faktor yang menyebabkan anggota DPR RI
tidak menindaklanjuti pengaduan masyarakat yang masuk. Pertama, AKD menilai
aduan masyarakat tersebut skala masalahnya tidak menasional atau tidak
menyangkut hajat hidup orang banyak. Kedua, sekretariat dari masing-masing
AKD tidak meneruskan semua aduan yang masuk kepada pimpinan atau anggota
AKD tersebut. Hal ini dapat mengakibatkan adanya anggota DPR RI yang tidak
2
UIN Syarif Hidayatullah Jakarta
mengetahui terkait adanya aduan masyarakat yang berasal dari daerah pemilihan
anggota DPR RI tersebut.
Berdasarkan permasalahan tersebut, SPM Online DPR RI seharusnya
memiliki fitur yang dapat mendistribusikan secara otomatis aduan masyarakat yang
masuk ke semua anggota DPR RI yang daerah pemilihannya sama dengan daerah
aduan masyarakat tersebut berasal. Solusi tersebut dipilih karena menurut Bapak
Yadin, setiap anggota DPR RI memiliki kepentingan untuk meningkatkan
kemungkinan keterpilihan mereka pada periode berikutnya, caranya dengan
menindaklanjuti aduan masyarakat yang berasal dari daerah pemilihannya. Untuk
itu, SPM Online DPR RI perlu dikembangkan dengan melakukan analisis
kebutuhan Sistem Pengaduan Masyarakat Online DPR RI yang lebih mendalam
untuk mengidentifikasi pengembangan apa saja yang perlu dilakukan terhadap
sistem tersebut. Hal ini sesuai dengan yang disampaikan Lamsweerde mengenai
tiga dimensi requirements engineering, bahwa analisis kebutuhan sistem dapat
dilakukan dengan melihat adanya keterbatasan sistem yang sedang berjalan saat ini
(system-as-is), dan adanya peluang untuk dieksploitasi atau dikembangkan
(Lamsweerde, 2009).
Analisis sistem dapat dilakukan dengan menggunakan beberapa pendekatan,
seperti pendekatan berorientasi data, proses, objek, dan organisasi, serta pendekatan
berorientasi sasaran (I. Shofi, 2015). Menurut Borgida dkk diantara pendekatan
yang ada tersebut, pendekatan berorientasi sasaran (goal) dan agen (agent) adalah
pendekatan yang cocok untuk melakukan analisis kebutuhan sistem (I. Shofi,
2015). Pendekatan berorientasi sasaran juga memiliki beberapa manfaat, yaitu
tahap desain awal yang lebih efektif, kemungkinan menggunakan berbagai bahasa
pemodelan, keterlacakan yang lebih baik, serta memungkinkan kontrol dan
pemeliharaan sistem yang lebih baik (Souza, Sanfilippo, Silva, & Cordero, 2016).
Pendekatan analisis kebutuhan berorientasi sasaran dan agen ini lebih dikenal
sebagai goal oriented requirements engineering (GORE).
Menurut Shofi dan Budiarjo terdapat 17 metode yang ada pada GORE. Antara
lain metode KAOS, GBRAM, i* framework, NFR framework dan lain sebagainya
(I. M. Shofi & Budiardjo, 2011). Metode yang ada tersebut dapat digunakan untuk
3
UIN Syarif Hidayatullah Jakarta
melakukan analisis kebutuhan sistem. Seperti penelitian (Aini, 2018) yang
melakukan analisis terhadap tiga website perpustakaan UIN dengan menggunakan
i* framework. Penggunaan i* framework memang terbukti dapat digunakan untuk
analisis kebutuhan sistem, akan tetapi, model yang dihasilkan i* framework
berpotensi sangat kompleks dan besar (Werneck, Oliveira, & do Prado Leite, 2009).
Penelitian lain (Souza et al., 2016) melakukan analisis kebutuhan untuk
memperkaya fase awal dari pembuatan desain standar exoskeleton. Metode yang
digunakan adalah metode KAOS (Keep All Objectives Satisfied). Model yang
dihasilkan berupa goal model, responsibility model, object model, dan operation
model. Pada penelitian (Souza et al., 2016) goal model yang dihasilkan mampu
menyajikan jalur pengambilan keputusan seorang analis, sehingga dapat mudah
dipahami oleh stakeholders. Akan tetapi, (Souza et al., 2016) pada penelitiannya
tidak menggunakan dokumen regulasi sebagai salah satu acuan dalam menyusun
goal model dan kebutuhan sistem.
Penggunaan GORE dengan metode KAOS juga telah dilakukan oleh
(Fuadiyati, 2018). Penelitian ini menggunakan pemodelan GORE dan salah satu
metodenya yaitu metode KAOS untuk melakukan analisis kebutuhan dari sistem
Evaluasi Dosen Oleh Mahasiswa (EDOM) online yang sedang digunakan oleh UIN
Syarif Hidayatullah Jakarta dan menganalisa kesenjangannya dengan kebutuhan
sistem yang sesungguhnya diinginkan oleh Lembaga Penjaminan Mutu (LPM) UIN
Syarif Hidayatullah. Pada penelitian tersebut, Fuadiyati tidak menggunakan
dokumen regulasi sebagai salah satu sumber informasi atau acuan dalam menyusun
goal model dan kebutuhan sistem. SPM Online DPR RI tergolong ke dalam sistem
yang ada pada instansi pemerintah, dan sebagaimana menurut (I. M. Shofi &
Budiardjo, 2011) sebagian besar instansi pemerintah (di Indonesia) telah
mempunyai dokumen resmi atau peraturan baku (dalam bentuk peraturan
pemerintah) yang berisi visi, misi, tugas pokok dan fungsi (TUPOKSI), maupun
peraturan-peraturan lainnya yang lebih detail jika dibandingkan dengan sebagian
besar perusahaan swasta, sehingga dapat dijadikan acuan untuk menyusun goal
model sistem. Berdasarkan hal tersebut, penulis menilai perlu menggunakan
4
UIN Syarif Hidayatullah Jakarta
dokumen regulasi sebagai salah satu acuan untuk membuat goal model SPM Online
DPR RI.
Metode untuk menyusun goal model sistem berdasarkan dokumen regulasi
adalah metode SAR (Select Appropriate Regulations) dan metode R2G
(Regulations to Goal Model). Metode SAR dan R2G merupakan metode yang
diusulkan (I. Shofi, 2015). Pemilihan metode SAR dan R2G didasari atas umpan
balik yang diberikan responden pada metode usulan (I. Shofi, 2015) tersebut, bahwa
100% responden menyataka
n perlunya penggunaan dokumen regulasi untuk menganalisis aplikasi
kepemerintahan, lebih dari 95% responden menyatakan perlunya metode/prosedur
khusus yang dapat membantu menyusun goal model berdasarkan dokumen
regulasi, 100% responden menyatakan metode usulan secara umum baik, dan lebih
dari 95% responden menyatakan perlunya mengimplementasikan metode usulan
untuk menganalisis kebutuhan aplikasi kepemerintahan (I. Shofi, 2015).
Setelah melakukan analisis terhadap permasalahan di atas, dan melakukan
studi pustaka terhadap penelitian-penelitian sebelumnya, penulis memutuskan
untuk menganalisis kebutuhan Sistem Pengaduan Masyarakat (SPM) Online DPR
RI berorientasi sasaran dengan menggunakan metode SAR, R2G dan KAOS.
Metode SAR dan R2G digunakan sebagai metode untuk mendapatkan goal dari
SPM Online DPR RI berdasarkan dokumen regulasi yang berlaku. Adapun3 dalam
menyusun goal model dan responsibility model penulis menggunakan metode
KAOS untuk mengetahui hasil analisis kebutuhan Sistem Pengaduan Masyarakat
Online DPR RI.
Tujuan Penelitian
Tujuan dari penelitian ini adalah menganalisis kebutuhan Sistem Pengaduan
Masyarakat (SPM) Online DPR RI berorientasi sasaran dengan metode SAR (Select
Appropriate Regulations), R2G (Regulations to Goal Model), dan KAOS (Keep All
Objectives Satisfied).
5
UIN Syarif Hidayatullah Jakarta
Manfaat Penelitian
1.3.1. Bagi Mahasiswa
Dapat menambah ilmu dan wawasan mahasiswa tentang pemanfaatan
teori-teori yang didapatkan di perkuliahan.
1.3.2. Bagi Universitas
Dapat menambah koleksi karya ilmiah Universitas mengenai Analisis
Kebutuhan Sistem Pengaduan Masyarakat (SPM) Online DPR RI
berorientasi sasaran dengan metode SAR (Select Appropriate Regulations),
R2G (Regulations to Goal Model), dan KAOS (Keep All Objectives
Satisfied).
Rumusan Masalah
Berdasarkan latar belakang permasalahan yang telah diuraikan di atas, maka
penulis menetapkan rumusan masalah pada penelitian ini adalah bagaimana
Analisis Kebutuhan Sistem Pengaduan Masyarakat (SPM) Online DPR RI
berorientasi sasaran dengan metode SAR (Select Appropriate Regulations), R2G
(Regulations to Goal Model), dan metode KAOS (Keep All Objectives Satisfied)?
Batasan Masalah
Berdasarkan uraian latar belakang masalah di atas, perlu adanya batasan
masalah agar penelitian yang dilakukan tetap fokus dan dapat menyelesaikan
permasalahan yang ada. Maka ruang lingkup batasan masalah penelitian yakni:
1.5.1. Metode
Pada penelitian ini penulis menggunakan 3 (tiga) metode yang ada
pada pendekatan GORE untuk melakukan analisis kebutuhan sistem, yaitu:
1. Metode SAR (Select Appropriate Regulations).
2. Metode R2G (Regulations to Goal Model).
3. Metode KAOS (Keep All Objectives Satisfied).
1.5.2. Tools
Pada penelitian ini, penulis menggunakan Microsoft Visio
Professional 2016 untuk membuat goal model dan responsibility model.
1.5.3. Proses
Berikut ini adalah proses yang terdapat pada penelitian, yaitu:
6
UIN Syarif Hidayatullah Jakarta
1. Analisis kebutuhan dilakukan pada Sistem Pengaduan Masyarakat
Online DPR RI, yaitu www.pengaduan.dpr.go.id.
2. Pemodelan sistem dilakukan sebanyak 3 (tiga) kali, yaitu
pemodelan untuk sistem yang sedang berjalan saat ini (system-as-
is), pemodelan untuk sistem yang sebenarnya diinginkan (system-
to-be awal), dan pemodelan sistem setelah melalui validasi
(system-to-be) akhir.
3. Model yang dibuat adalah goal model dan responsibility model.
4. Wawancara untuk mendapatkan informasi dalam menyusun hasil
analisis kebutuhan sistem hanya dilakukan kepada Kepala
Subbagian Analisis Pengaduan Masyarakat II Sekretariat Jenderal
DPR RI selaku ahli dari SPM Online DPR RI.
Metodologi Penelitian
Penulis menggunakan metodologi penelitian agar dapat dijadikan sebagai
pedoman penulis dalam melaksanakan penelitian dari perumusan masalah sampai
kesimpulan.
1.6.1. Metode Pengumpulan Data
Dalam melakukan pengumpulan data peneltian dan penulisan skripsi
ini, penulis menggunakan 3 metode pengumpulan data, yaitu:
1. Studi Pustaka
2. Observasi
3. Wawancara
Sistematika Penulisan
Sistematika yang dibuat pada skripsi ini akan dibagi dalam enam bagian,
yaitu:
BAB 1 PENDAHULUAN
Dalam bab ini membahas mengenai latar belakang penulisan,
perumusan masalah, batasan masalah, tujuan dan manfaat
penulisan, metode dan sistematika penulisan yang merupakan
gambaran menyeluruh dari penulisan skripsi ini.
7
UIN Syarif Hidayatullah Jakarta
BAB 2 LANDASAN TEORI
Dalam bab ini membahas mengenai berbagai teori yang mendasari
analisis permasalahan yang berhubungan dengan pembahasan dan
melakukan tinjauan pustaka terhadap penelitian-penelitian
sebelumnya.
BAB 3 METODOLOGI PENELITIAN
Bab ini berisi pembahasan atau pemaparan metode yang penulis
pakai dalam pencarian data maupun metode yang digunakan untuk
membuat pemodelan sistem.
BAB 4 ANALISIS SISTEM
Bab ini membahas mengenai proses dan hasil dari analisis
kebutuhan sistem menggunakan metode SAR, R2G dan KAOS
terhadap sistem yang sedang berjalan saat ini (system-as-isi),
sistem yang sebenarnya diinginkan (system-to-be), dan setelah
melakukan validasi (system-to-be akhir).
BAB 5 HASIL DAN PEMBAHASAN
Membahas mengenai analisis kesenjangan yang terjadi antara
hasil analisis kebutuhan sistem yang ada saat ini dengan sistem
yang sebenarnya diinginkan, serta kesenjangan setelah dilakukan
validasi. Selanjutnya, dikaitkan dengan landasan teori serta
metodologi yang digunakan.
BAB VI PENUTUP
Pada bab ini berisi kesimpulan dari hasil pembahasan seluruh bab
serta saran-saran yang kiranya dapat diperhatikan serta
dipertimbangkan untuk pengembangan penelitian dimasa
mendatang.
8
BAB 2
TINJAUAN PUSTAKA DAN LANDASAN TEORI
Requirements Engineering (RE)
Requirements adalah kondisi atau kemampuan yang harus dipenuhi oleh
sistem sesuai spesifikasi yang diinginkan oleh pengguna (Maniah & Hamidin,
2017). Requirements juga dapat didefinisikan sebagai kondisi dari tipe data, proses,
dan tampilan yang harus dipenuhi oleh sistem (Whitten & Bentley, 2018).
Berdasarkan dua pengertian tersebut, penulis menyimpulkan bahwa requirements
(kebutuhan) adalah kondisi berupa tipe data, proses, dan tampilan yang harus
dipenuhi oleh sistem sesuai dengan spesifikasi yang diinginkan oleh stakeholders.
Menurut Nuse requirements engineering (RE) adalah proses untuk
menemukan requirements (kebutuhan) yang tepat, sehingga suatu perangkat lunak
dapat memenuhi kegunaannya. Proses ini dilakukan dengan cara mengenali para
stakeholder serta kebutuhan mereka dan mendokumentasikannya ke dalam sebuah
bentuk, yang dapat digunakan untuk analisis, komunikasi, dan implementasi (Aini,
2018). Pengertian lain dari requirements engineering adalah proses analisis dan
proses memformulasikan masalah (what) yang perlu diselesaikan, mengapa (why)
masalah tersebut harus diselesaikan, dan siapa (who) yang harus dilibatkan dalam
tanggung jawab menyelesaikan masalah tersebut (Lamsweerde, 2009).
Berdasarkan dua pengertian di atas, penulis menyimpulkan bahawa
requirements engineering adalah sebuah aktivitas atau proses untuk menemukan
sebuah masalah, bagaimana cara menyelesaikan masalah tersebut dengan
menggunakan perangkat lunak, dan siapa saja yang bertanggung jawab untuk
menyelesaikan masalah tersebut.
9
UIN Syarif Hidayatullah Jakarta
Why, what, who merupakan 3 (tiga) dimensi dari requirements engineering.
Dimensi why fokus pada alasan kontekstual terhadap adanya usulan sistem dengan
versi terbaru yang harus dibuat secara eksplisit dalam hal sasaran yang harus
dipenuhi. Sasaran tersebut harus diidentifikasi sehubungan dengan keterbatasan
sistem yang sedang berjalan saat ini (system-as-is) dan peluang untuk dieksploitasi.
Proses ini membutuhkan analisis yang cermat. Apa tujuan tepatnya? Apa
konsekuensinya? Bagaimana mereka berinteraksi? dan Bagaimana cara
menyelaraskan dengan tujuan bisnis?. (Lamsweerde, 2009)
Dimensi what fokus pada layanan fungsional bahwa sistem yang
sesungguhnya diinginkan (system-to-be) harus disediakan untuk memenuhi sasaran
yang telah diidentifikasi pada dimensi why. Diantara layanan-layanan tersebut
diimplementasikan oleh system-to-be, dan sebagian yang lain direalisasikan melalui
prosedur manual maupun devices. Layanan-layanan sistem, kendala dan asumsi
dapat diidentifikasi dari sasaran sistem yang telah disetujui dan diformulasikan
dengan istilah/bahasa yang tepat/cermat, agar semua pihak yang berkepentingan
dapat memahami ketika ingin memvalidasi dan merealisasikannya (Lamsweerde,
2009).
Gambar 2.1 Tiga Dimensi Requirements Engineering
Sumber: Lamsweerde (2009)
10
UIN Syarif Hidayatullah Jakarta
Sedangkan dimensi who mengarah kepada penugasan tanggung jawab untuk
dapat mencapai sasaran, layanan, dan konstrain diantara komponen-komponen
pada system-to-be, manusia, alat, atau perangkat lunak (Lamsweerde, 2009).
RE terdiri dari berbagai aktivitas yang menghasilkan berbagai produk dan
melibatkan berbagai jenis aktor. Aktivitas-aktivitas tersebut adalah: (Lamsweerde,
2009)
1. Domain Understanding yaitu aktivitas yang terdiri dari mempelajari system-as-
is dalam konteks organisasi dan tekniknya, dengan tujuan untuk memperoleh
pemahaman yang baik mengenai domain dimana permasalahan tersebut
bersumber dan akar dari sumber permasalahan tersebut.
2. Requirement Elicitation yaitu aktivitas yang terdiri dari penemuan kandidat
kebutuhan, dan asumsi yang akan membentuk system-to-be, berdasarkan pada
kelemahan dari system-as-is yang muncul dari domain understanding.
3. Evaluation and Agreement yaitu aktivitas yang bertujuan untuk membuat
keputusan informasi mengenai isu-isu yang muncul pada aktivitas requirement
elicitation. Keputusan semacam itu seringkali didasarkan pada penjualan
(trade-off) terbaik yang harus disepakati oleh stakeholders.
4. Specification and Documentation yaitu aktivitas yang terdiri dari perincian,
penataan, dan pendokumentasian karakteristik yang telah disetujui selama
aktivitas evaluation and agreement. Hasil dari aktivitas ini adalah requirement
documentation (RD).
5. Requirements Consolidation yaitu aktivitas yang bertujuan untuk menjamin
kualitas (quality assurance).
Proses yang efektif untuk domain understanding dan requirement elicitiation
adalah dengan menggabungkan teknik yang berbeda, tergantung pada tingkat
interaksi mereka dengan para pemangku kepentingan, yaitu: (Lamsweerde, 2009)
2.1.1. Artefact-Driven Elicitation Techniques
Dalam mendukung proses akuisisi, ada teknik-teknik yang
mengandalkan kepada artefak yang lebih spesifik. Berikut ini beberapa
contoh teknik elisitasi yang mengandalkan artefak: (Lamsweerde, 2009)
11
UIN Syarif Hidayatullah Jakarta
2.1.1.1 Studi Latar Belakang (Background Study)
Apabila requirements engineer kurang familiar terhadap
system-as-is, requirements engineer dapat memperoleh pengetahuan
tentang sistem, organisasi di sekitarnya dan domain yang
mendasarinya, dengan mengumpulkan dan mempelajari dokumen
yang relevan:
1. Untuk mempelajari tentang organisasi, requirements engineer
dapat mempelajari dokumen seperti bagan organisasi, rencana
bisnis, panduan kebijakan, laporan keuangan, notulen rapat
penting, deskripsi pekerjaan, formulir bisnis, dan sejenisnya.
2. Untuk mempelajari tentang domain, requirements engineer
dapat mempelajari buku, survei, dan artikel yang diterbitkan.
Requirements engineer harus mempelajari peraturan yang
diberlakukan di dalam domain, jika ada. Requirements engineer
juga dapat melihat laporan tentang sistem serupa di domain itu.
3. Untuk mempelajari tentang sistem secara spesifik, Requirements
engineer dapat mempelajari laporan yang mendokumentasikan
arus informasi, prosedur kerja, aturan bisnis, formulir yang
dipertukarkan antara unit organisasi, dan sebagainya. Jika
tersedia, laporan tentang cacat, keluhan, dan permintaan
perubahan sangat membantu dalam menemukan masalah
dengan system-as-is.
Studi latar belakang terkadang disebut juga analisis konten.
Kekuatan dari teknik ini adalah menyediakan informasi dasar yang
akan dibutuhkan sesudahnya, khususnya terminologi yang
digunakan, tujuan dan kebijakan yang harus diperhitungkan,
pembagian tanggungjawab di antara para pemangku kepentingan dan
lain sebagainya. Teknik ini memungkinkan requirements engineer
untuk mempersiapkan diri sebelum bertemu dengan stakeholders.
Sehingga, muncul sebagai pra-syarat dari teknik elisitasi lainnya.
12
UIN Syarif Hidayatullah Jakarta
2.1.1.2 Kuesioner
Teknik ini terdiri dari mengajukan daftar pertanyaan spesifik
kepada stakeholders terpilih. Setiap pertanyaan yang diberikan dapat
diberikan konteks yang singkat dan membutuhkan sebuah jawaban
yang singkat dan itu terstrandarisasi dari daftar jawaban yang telah
ditentukan sebelumnya. Stakeholders dapat mengembalikan
kuesioner tersebut dengan hanya menandai jawaban yang menurut
mereka paling tepat. Dalam sisi positifnya, kuesioner memungkinkan
Requirements engineer untuk memperoleh informasi subjektif
dengan segera, dengan biaya rendah (dalam hal waktu memperoleh),
dari jarak jauh, dan dari sejumlah besar orang.
2.1.1.3 Mock-ups dan prototipe sistem
Stakeholders sering menemukan kesulitan dalam
memproyeksikan deskripsi tekstual dari sistem ke kondisi kerja masa
depan. Untuk mengurangi kesulitan ini, requirements engineer
mungkin bisa menampilkan kepada mereka sebuah sketsa dari
sebuah produk untuk membantu memvisualisasikan akan seperti apa
nantinya. Prinsip ini sudah berhasil digunakan dalam teknik sipil
dalam beberapa tahun.
1. A functional prototype menampilkan aspek yang terkait dengan
fungsional perangkat lunak.
2. A user interface prototype menampilkan aspek statis dan
dinamis dari interaksi antara pengguna dengan perangkat lunak,
seperti tampilan format dari input-output data.
2.1.1.4 Penggunaan kembali pengetahuan (knowledge reuse)
Sistem jarang dipahami dari awal. Requirements engineer
dan stakeholders cenderung menggunakan kembali pengetahuan
sebelumnya dari sistem terkait. Pengetahuan tersebut dapat merujuk
pada organisasi, domain tempat masalah berakar, sampai dengan
jenis masalah yang dialami dalam sistem serupa dan jenis kebutuhan
yang perlu dipertimbangkan untuk mengatasi masalah tersebut.
13
UIN Syarif Hidayatullah Jakarta
Penggunaan kembali pengetahuan secara sistematis dapat
meningkatkan proses elicitation secara signifikan.
2.1.2. Stakeholder-Driven Elicitation Techniques
Pada teknik ini berfokus pada berbagai tipe interaksi dengan
stakeholders untuk mendapatkan informasi yang relevan dan memadai
mengenai sebuah organisasi, domain dan problem dari system-as-is. Berikut
ini beberapa contoh teknik elisitasi yang fokus pada tipe interaksi dengan
stakeholders: (Lamsweerde, 2009)
2.1.2.1 Wawancara
Wawancara pada umumnya dianggap sebagai teknik utama
untuk requirements elicitation. Wawancara secara tradisional
dibedakan menjadi:
1. Wawancara terstruktur, requirements engineer telah
mempersiapkan serangkaian pertanyaan. Serangkaian
pertanyaan ini memiliki tujuan spesifik yang berkaitan dengan
wawancara. Beberapa pertanyaan mungkin terbuka, dan yang
lainnya mungkin meminta pilihan di antara beberapa jawaban
yang disediakan.
2. Dalam wawancara tidak terstruktur, tidak ada serangkaian
pertanyaan yang telah dipersiapkan sebelumnya. Wawancara
terdiri dari diskusi informal bebas dengan para stakeholders
tentang bagaimana keadaan sistem saat ini, bagaimana sistem
tersebut bekerja, apa permasalahan yang dirasakan olehnya, dan
bagaimana Dia ingin masalah seperti itu diatasi dalam sistem
yang baru.
Wawancara terstruktur maupun tidak terstruktur memiliki
nilai atau jasanya masing-masing. Wawancara terstruktur
mendukung diskusi yang lebih fokus dan menghindari masalah yang
tidak relevan. Sedangkan wawancara tidak terstruktur menyetujui
eksplorasi masalah yang mungkin diabaikan. Wawancara yang
14
UIN Syarif Hidayatullah Jakarta
efektif karenanya harus menggabungkan dua mode, dimulai dengan
bagian terstruktur, diikuti oleh yang tidak terstruktur.
Efektifitas dari wawancara dapat diukur dengan rasio antara:
1. Alat dan cakupan pengetahuan dari pengetahuan yang diperoleh.
2. Waktu yang dibutuhkan untuk memperoleh pengetahuan
tersebut.
2.1.2.2 Observasi
Teknik ini didasarkan pada premis yang memahami suatu
tugas dengan melakukan pengamatan sementara. Poin ini terutama
berlaku untuk proses bisnis atau prosedur kerja yang melibatkan
banyak orang yang mungkin tidak menyadari apa yang dilakukan
orang lain, atau kesulitan menjelaskannya. Observasi tugas bisa pasif
maupun aktif:
1. Dalam observasi pasif, requirement engineer tidak dapat
mengganggu orang-orang yang terlibat dalam tugas tersebut.
Requirement engineer hanya melihat dari luar dan merekam apa
yang terjadi melalui catatan, video kamera, dsb. Seperti dalam
pengumpulan data, catatan-catatan itu selanjutnya harus dipilah
dan ditafsirkan dengan benar.
2. Dalam observasi aktif, requirement engineer terlibat dalam
tugas, kadang-kadang ke titik di mana ia menjadi anggota tim
kerja.
2.1.2.3 Sesi Kelompok (group sessions)
Teknik ini didasarkan pada premis bahwa ada banyak
persepsi yang akan timbul dari banyaknya orang. Group sessions
digunakan untuk mendapatkan kesepakatan dari berbagai persepsi
yang timbul tersebut. Group sessions dapat terstruktur maupun tidak
terstruktur, berikut penjelasannya:
1. Pada group session terstruktur, peran dari peserta sudah jelas
didefinisikan, seperti pemimpin, moderator, reporter,
pengguuna, manajer atau pengembang. Setiap peserta harus
15
UIN Syarif Hidayatullah Jakarta
berkontribusi pada penjabaran bersama requirements sesuai
dengan peran dan sudut pandang spesifiknya.
2. Pada group session tidak tersetruktur atau juga disebut sesi
bertukar pikiran (brainstorming session), peran dari masing-
masing peserta kurang jelas.
Goal Oriented Requirements engineering (GORE)
Menurut Lapouchnian GORE merupakan pendekatan di dalam requirements
engineering yang berorientasi sasaran (goal) dan aktor yang akhir-akhir ini
berkembang cukup pesat. Salah satu alasan kemunculan GORE ini adalah
dirasakannya kekurangcukupan dalam pendekatan analisis tradisional ketika
berkenaan dengan sistem perangkat lunak yang lebih kompleks. (I. Shofi, 2015).
GORE mempertimbangkan sasaran organisasi dan aktor dalam mengembangkan
sistem sebagai sumber kebutuhan (requirements), Sehingga requirements engineer
perlu mengetahui goals terlebih dahulu untuk mendapatkan kebutuhan sistem. Hal
ini yang merupakan pembeda dari pendekatan RE yang biasa, yang hanya
memodelkan kebutuhan, sedangkan GORE melakukan pemodelan sasaran, yang
merupakan alasan mengapa kebutuhan diperlukan (Werneck et al., 2009).
Goal adalah pernyataan yang harus dipenuhi oleh sistem melalui kerjasama
seluruh agennya. Agen adalah komponen sistem aktif yang dapat membatasi
perilakunya dengan kontrol yang memadai atas item sistem untuk memenuhi
sasaran yang menjadi tanggung jawabnya. Goals memberikan abstraksi dasar untuk
mengatasi dimensi why dari requirement engineering. (Lamsweerde, 2009)
Menurut Lapouchnian untuk menemukan goal menjadi requirements,
aktivitas yang dapat dilakukan adalah goal analysis (Elcitation), dan goal
refinement. (I. Shofi, 2015)
Gambar 2.2 Aktivitas Menemukan Goal
Sumber: Imam M. Shofi (2015)
16
UIN Syarif Hidayatullah Jakarta
Lapouchnian menjelaskan bahwa goal analysis atau goal elicitation adalah
proses eksplorasi dari sumber informasi untuk mengidentifikasi goal suatu
organisasi dan mengklasifikasikan goal tersebut. Menurut Regev & Wegmann ada
beberapa teknik yang digunakan untuk mengidentifikasi goal, yaitu: (I. Shofi,
2015)
1. Memahami permasalahan stakeholder
2. Mengekstrak pernyataan resmi dari:
a. Transkip interview
b. Kebijakan perusahaan
c. Visi & misi perusahaan/organisasi
d. Goal perusahaan/organisasi
e. Workflow Diagrams.
f. Skenario yang ditulis stakeholder.
3. Menanyakan “Bagaimana” (How) dan “Mengapa” (Why) tentang awalnya goal
yang diidentifikasi ini untuk menentukan hierarki goal.
4. Menanyakan “Bagaimana yang lain” (How else) untuk mengidentifikasi
alternatif goal.
Sedangkan goal refinement merupakan proses evolusi goal dari saat awal
diidentifikasi sampai saat ditranslasikan menjadi kebutuhan operasional
(operational requirement) (I. Shofi, 2015). Goal refinement meliputi:
1. Dekomposisi goal menjadi sub goal, dimana masing-masing sub goal akan
mempunyai relasi ke agent yang lebih sedikit.
2. Proses refinement berhenti ketika goal mencapai suatu kondisi dimana yang
merupakan tanggung jawab dari agen tunggal.
3. Terminal goal yang diassign ke agen dalam software-to-be menjadi kebutuhan.
4. Terminal goal yang diassign ke agen dalam lingkungan (environment) menjadi
asumsi.
2.2.1. Goal, Requirements, Expectations, dan Agent
Goal adalah pernyataan atau kondisi yang harus dipenuhi oleh sistem
melalui kerjasama para agennya. Goals dikatakan semakin halus (low level)
ketika semakin sedikit agen yang diperlukan untuk memenuhinya
17
UIN Syarif Hidayatullah Jakarta
(Lamsweerde, 2009). Berdasarkan tingkatan abstraksinya, goal dapat
dibedakan menjadi 2, yaitu: (Lamsweerde, 2009)
1. Higher level goal merupakan goal yang masih kasar, untuk
menyatakan sasaran (goal) strategis terkait dengan bisnis atau
organisasi. Contoh:
a. Kapasitas sistem transportasi akan meningkat 50%
b. Sistem perpustakaan harus menyediakan akses yang efektif
c. Pertemuan harus dijadwalkan untuk memaksimalkan
kehadiran peserta yang diundang
2. Lower level goal merupakan goal yang menyatakan sasaran teknis
terkait dengan opsi desain sistem. Contoh:
a. Perintah akselerasi harus dikirim ke setiap kereta setiap 3 detik
b. Pengingat untuk salinan buku yang tidak dikembalikan akan
diterbitkan setiap minggu setelah berakhirnya jangka waktu
pinjaman
Requirements adalah goal di bawah tanggung jawab agen tunggal
calon perangkat lunak (system-to-be). Contoh: (Lamsweerde, 2009)
1. Kupon pinjaman akan dikeluarkan jika ada salinan buku yang
diminta dalam database perpustakaan
2. Tanggal dan lokasi pertemuan yang dijadwalkan akan dikirim ke
alamat email setiap peserta yang terdapat pada daftar undangan
setelah mereka divalidasi oleh inisiator rapat.
Menurut (Lamsweerde, 2009) requirements dapat dikategorikan
menjadi dua, yaitu:
1. Functional requirements mendefinisikan pengaruh fungsional yang
harus dimiliki oleh calon perangkat lunak pada lingkungannya atau
mendefinisikan layanan yang harus disediakan oleh calon perangkat
lunak. Contoh: ‘Mesin pencari daftar pustaka harus menyediakan
daftar semua buku perpustakaan tentang topik yang diberikan’.
2. Non Functional Requirements mendefinisikan batasan bagaimana
layanan tersebut harus disediakan oleh calon perangkat lunak.
18
UIN Syarif Hidayatullah Jakarta
Contoh: ‘Format untuk mengirimkan pencarian daftar pustaka dan
menampilkan jawabannya harus dapat diakses oleh siswa yang tidak
memiliki keahlian komputer’.
Expectations adalah goal di bawah tanggung jawab agen tunggal
dalam lingkungan calon perangkat lunak (system-to-be). Secara definisi,
expectation tidak dapat dilakukan oleh calon perangkat lunak (system-to-be),
tidak seperti requirements. Contoh: (Lamsweerde, 2009)
1. Penumpang keluar dari kereta ketika pintu kereta terbuka di
platform tujuan mereka.
2. Perintah akselerasi yang dikirim ke pengontrol kereta harus diterima
paling lama dalam waktu X detik.
3. Peserta yang diundang akan menghadiri pertemuan jika tanggal dan
lokasi yang diberitahukan sesuai dengan batasan yang dia
kembalikan.
Agen adalah komponen sistem aktif yang memainkan peran spesifik
dalam kepuasan goal. Untuk memenuhi peran tersebut, agen perlu membatasi
perilakunya dengan kontrol yang cukup terhadap item sistem. Dalam goal
satisfaction, dapat melibatkan beberapa agen sistem, seperti: (Lamsweerde,
2009)
1. Manusia yang memainkan peran spesifik, seperti unit organisasi,
operator atau pengguna akhir.
2. Alat seperti sensor, aktuator, instrumen pengukuran atau media
komunikasi.
3. Komponen perangkat lunak yang ada, seperti peninggalan
(legacy), komponen asing dalam sistem terbuka.
4. Komponen perangkat lunak baru, yang membentuk perangkat
lunak seperti pengendali perangkat lunak, manajer informasi atau
web service.
2.2.2. Metode-metode dalam GORE
Sedikitnya telah terdapat 17 metode dalam GORE, dimana masing-
masing mempunyai kelebihan dan kekurangan, ada juga metode yang
19
UIN Syarif Hidayatullah Jakarta
merupakan gabungan dari metode-metode yang lain (I. M. Shofi & Budiardjo,
2011). Berikut ini perbandingan dari beberapa metode-metode yang ada
dalam GORE:
Tabel 2.1 Perbandingan Metode yang ada dalam GORE
Metode Kelebihan Kekurangan
Non-Functional
Requirements
(NFR)
Framework
Menyediakan pendekatan
berorientasi proses untuk
menangani kebutuhan non-
fungsional dengan menekan-
kan pada upaya merasiona-
lisasi proses pengembangan-
nya. (Lapouchnian, 2005)
Hanya fokus pada pemodelan
dan analisis kebutuhan non
fungsional. (Lapouchnian,
2005)
Goal Skills
Preferences
(GSP)
Framework
1. Dapat menjelaskan
variability. (I. Shofi, 2015)
2. Dapat menjelaskan skill
yang harus terpenuhi
untuk melaksanakan suatu
task/goal tertentu. (I.
Shofi, 2015)
1. Secara spesifik tidak
menjelaskan bagaimana
menangani konflik antar
/dalam goal. (I. Shofi, 2015)
2. Secara spesifik tidak
menjelaskan bagaimana cara
mengidentifikasi suatu goal.
(I. Shofi, 2015)
Goal-Based
Requirements
Analysis
Method
(GBRAM)
Membantu dalam mengum-
pulkan goals dan penyem-
purnaannya dengan cara me-
mpersenjatai requirements
engineers dengan pertanya-
an standar. Misalnya, “Apa-
kah pencapaian berkelan-
jutan dari goals ini
diperlukan?”. (Lapouchnian,
2005)
Tidak dapat memberikan
notasi grafis untuk mewakili
goals, penyempurnaan goals,
agen, dsb. (Lapouchnian,
2005)
20
UIN Syarif Hidayatullah Jakarta
Metode Kelebihan Kekurangan
i*/Tropos Memiliki mekanisme
requirements yang lebih
lengkap dari pada
pendekatan yang lainnya,
selain itu pendekatan ini
memiliki rancangan
pemetaan model goal secara
otomatis terhadap arsitektur
sistem. (Dipaloka, Suwardi,
& Surendro, 2016)
1. Seorang aktor bergantung
pada aktor lain untuk
mencapai sebuah goals.
Sehingga, aktor menjadi
rentan jika aktor yang
berhubu-ngan dengannya
tidak dapat mengantarkan
sumber daya atau tidak dapat
melaksanakan tugasnya.
(Lapouchnian, 2005)
2. Tidak dapat menyebutkan
hambatan (obstacles)
(Werneck et al., 2009).
3. Model yang dihasilkan
berpotensi kompleks dan
besar. (Werneck et al., 2009)
4. Tidak dapat mengksplorasi
peran dan posisi agen.
(Werneck et al., 2009)
SAR (Select
Appropriate
Regulations)
dan R2G
(Regulations to
Goal Model)
Metode dapat digunakan
untuk menentukan dokumen
regulasi yang memiliki
keterkaitan dengan
sistem/aplikasi dan
membuat goal model
berdasarkan dokumen
regulasi tersebut.
(I. Shofi, 2015)
1. Hanya fokus pada artefact-
driven berupa dokumen
regulasi. (I. Shofi, 2015)
2. Masih bersifat early phase
requirements engineering
sehingga perlu dilengkapi
dengan requirements
elicitation yang dipicu dari
stakholders. (I. Shofi, 2015)
21
UIN Syarif Hidayatullah Jakarta
KAOS (Keep
All Objectives
Satisfied)
1. Dapat memberikan
gambaran secara hierarki
dari kebutuhan-
kebutuhan yang ada dan
lebih mudah untuk
dilakukan penelusuran
(high traceability).
(Adikara, Sitohang, &
Hendradjaya, 2013)
2. Alasan dari pengerjaan
sebuah sistem menjadi
dapat dimengerti.
(Adikara et al., 2013)
3. Kebutuhan dapat
dijabarkan sesuai dengan
sasaran utama (goal) dan
soft-goal, hal ini
didapatkan karena untuk
setiap goal dilakukan
penuruan kebutuhan
dengan menanyakan
pertanyaan “bagaimana”
atau “mengapa”.
(Adikara et al., 2013)
4. Lebih mudah untuk
menjaga hal-hal sederha-
na dan jelas dan untuk
mengkomunikasikan
kebutuhan proyek secara
efisien. (RESPECT-IT,
2007)
Tidak dapat memberikan
prioritas pada kebutuhan yang
didapatkan. (Adikara et al.,
2013)
22
UIN Syarif Hidayatullah Jakarta
Berdasarkan tabel di atas, penulis memilih untuk menggunakan metode
KAOS pada penelitian ini, karena metode KAOS telah terbukti dapat memberikan
gambaran dari goals sampai ke kebutuhan sistem secara hierarki (memudahkan
dalam melakukan penelusuran), dan setiap kebutuhan sistem dapat dijabarkan
sesuai dengan sasaran utama dari pengembangan sistem tersebut. Selanjutnya, jika
dibandingkan dengan metode GORE yang lain, metode KAOS mampu memberikan
notasi grafis untuk mewakili goals, penyempurnaannya goals, dan agen. Selain itu,
metode KAOS lebih berorientasi kepada sasaran dan metode KAOS juga dapat
memodelkan kebutuhan fungsional sistem.
Metode KAOS
Menurut Lamsweerde pendekatan KAOS adalah implementasi GORE yang
berorientasi pada sasaran yang melibatkan serangkaian teknik analisis formal
berbasis Linear Tree Logic (LTL). KAOS adalah singkatan dari Keep All Objectives
Satisfied, menggambarkan kerangka kerja multi-paradigma yang menggabungkan
berbagai tingkat penalaran, yaitu semi formal untuk pemodelan dan penataan
sasaran, serta formal berdasarkan formalisme logika waktu linear. Oleh karena itu,
KAOS menggabungkan jaring semantik konsep dasar seperti asumsi, operasi, objek
dan agen, dengan LTL (Silva, 2016). Pada dasarnya, KAOS adalah metode
elaborasi yang menyediakan bahasa spesifik untuk menangkap aspek WHY, WHAT,
dan WHO untuk mendapatkan requirements. (Silva, 2016).
M. Teruel, E. Navarro, dan V. Lopez-Jaquero dalam bukunya yang berjudul
“Comparing Goal-Oriented Approaches to Model Requirements for CSCW” (2012)
mengungkapkan bahwa KAOS dapat dideskripsikan sebagai sebuah kerangka kerja
dari beberapa paradigma yang memungkinkan untuk mengkombinasikan beberapa
tingkatan pemikiran berbeda dan disertai alasannya. Bahasa pemodelan KAOS
merupakan bagian dari kerangka kerja KAOS untuk menggali (elicitation),
menspesifikasi, dan menganalisis sasaran (goals), kebutuhan (requirements),
skenario, dan tanggung jawab tugas. Elemen pada KAOS meliputi istilah berikut
ini: (Adikara et al., 2013)
1. Sasaran (goal) didefinisikan sebagai kumpulan perilaku / keadaan yang harus
dipenuhi atau dapat diterima oleh sistem dalam sebuah kondisi yang ditetapkan.
23
UIN Syarif Hidayatullah Jakarta
Definisi sasaran harus jelas sehingga dapat diverifikasi apakah sistem mampu
memenuhi / memuaskan goal tersebut.
2. Softgoal digunakan untuk mendokumentasikan perilaku alternatif dari sistem,
sehingga tidak secara tegas dapat diverifikasi tingkat kepuasannya. Tingkat
kepuasan dari softgoal akan dibatasi menggunakan limitasi yang ditetapkan.
3. Agen adalah sebuah jenis dari obyek yang bertindak sebagai pemroses kegiatan
operasional. Agen merupakan komponen aktif bisa berupa manusia, perangkat
keras, perangkat lunak, dan lainnya yang mempunyai peran spesifik dalam
memuaskan sebuah sasaran.
Menurut M. Teruel, E. Navarro, dan V. Lopez-Jaquero (2012) ada 3 jenis
ketergantungan diantara goal pada KAOS, yaitu: (Adikara et al., 2013)
1. AND/OR-decomposition yaitu sebuah hubungan yang menggambarkan hierarki
dari goal dengan sub-goal-nya, menggambarkan bahwa goal dapat
dipenuhi/dipuaskan jika seluruh sub-goal-nya terpuaskan (menggunakan AND
decomposistion), atau minimal salah satu dari softgoal tersebut terpuaskan
(menggunakan OR decomposistion).
2. Potential conflict yaitu hubungan yang menggambarkan pada kondisi tertentu,
jika sebuah goal terpenuhi ternyata dapat menyebabkan goal yang lainnya tidak
terpenuhi.
3. Responsibility assignment yaitu hubungan antara agen dengan sebuah goal.
Agen yang terhubung tersebut mempunyai tanggung jawab agar goal dapat
dipenuhi/terpuaskan.
Saat ini semakin banyak development teams yang menghargai teknik
pemodelan untuk menentukan solusi. Gagasan kunci pertama di balik KAOS adalah
membangun model untuk requirement, yaitu untuk menggambarkan masalah yang
harus dipecahkan dan kendala yang harus dipenuhi oleh penyedia solusi. KAOS
dirancang untuk: (RESPECT-IT, 2007)
1. Agar sesuai dengan deskripsi masalah dengan memungkinkan anda untuk
mendefinisikan dan memanipulasi konsep yang relevan dengan deskripsi
masalah.
24
UIN Syarif Hidayatullah Jakarta
2. Untuk meningkatkan proses analisis masalah dengan menyediakan pendekatan
sistematis untuk menemukan dan menyusun requirements.
3. Untuk memperjelas tanggung jawab semua stakeholders proyek.
4. Untuk memungkinkan stakeholders berkomunikasi dengan mudah dan efisien
tentang requirements.
Kerangka kerja KAOS didasarkan pada empat model terkait yang
memberikan perancang dan pemangku kepentingan gambaran sistem yang lebih
luas tentang sasaran dan operasionalisasinya (Souza et al., 2016).
Keempat model yang terdapat pada Gambar 2.3 dijelaskan lebih lanjut di
bawah ini:
2.3.1. Goal Model
Goal menyajikan abstraksi dasar yang menangani dimensi WHY dari
requirements engineering. Goal adalah pernyataan niat preskriptif bahwa
sistem harus memuaskan melalui kerja sama para agennya (Lamsweerde,
2009). Selain itu, Goal dapat didefinisikan sebagai sifat sistem yang
Gambar 2.3 Empat Model yang Ada Pada KAOS
Sumber: A Kaos Tutorial (2007)
25
UIN Syarif Hidayatullah Jakarta
diinginkan oleh stakeholders dan telah diungkapkan oleh stakeholders itu
sendiri. Berikut ini contohnya, sebuah goal yang dikutip dari studi kasus
elevator: (RESPECT-IT, 2007)
“Setiap kali seorang penumpang memanggil elevator dari lantai f1
untuk pergi ke lantai f2, sistem elevator akhirnya membawanya ke f2”.
Dengan KAOS, analis menemukan goal sistem baru dengan
mewawancarai pengguna saat ini dan di masa depan dan dengan menganalisis
sistem yang ada, membaca dokumen teknis yang tersedia, dsb. KAOS
memungkinkan analis untuk menyusun goal yang dikumpulkan menjadi
grafik asiklik yang diarahkan sehingga: (RESPECT-IT, 2007)
1. Setiap goal (kecuali yang paling atas) biasanya dibenarkan oleh
setidaknya satu goal lain yang menjelaskan mengapa sasaran tersebut
diperkenalkan dalam model.
2. Setiap goal (kecuali yang terbawah) disempurnakan sebagai kumpulan
sub-goal yang menjelaskan bagaimana goal yang telah disempurnakan
dapat dicapai.
Di dekat bagian atas grafik, berdiri tujuan bisnis atau strategis. Di
bagian bawah (daun) berdiri requirements sistem. Contoh yang diberikan di
atas adalah goal business. Goal business memberikan properti yang berkaitan
dengan bisnis inti sistem elevator. Itu tidak dapat dianggap sebagai
requirements: kualifikasi kata "akhirnya" tidak cukup tepat. Inilah kandidat
yang lebih baik untuk menjadi kebutuhan: (RESPECT-IT, 2007)
"Ketika ada panggilan untuk elevator di lantai f, elevator pertama
yang melewati lantai f dan menuju ke arah yang diminta, akan dihentikan di
lantai f, kecuali saat penuh”
Konsep “elevator penuh” harus didefinisikan di tempat lain dalam
document requirements. (RESPECT-IT, 2007)
Business dan strategical goals dinyatakan dalam kosa kata para
stakeholder. Lower-level goals biasanya diungkapkan menggunakan kata-
kata dari kosa kata para pemangku kepentingan, serta istilah teknis khusus
yang diperkenalkan dalam model jika perlu. Identifikasi goals tidak berjalan
26
UIN Syarif Hidayatullah Jakarta
secara eksklusif dari top-down (beralih dari business goals yang lebih tinggi
ke technical requirements yang lebih rendah) atau pendekatan bottom-up.
Dalam kebanyakan kasus, dua pendekatan harus digunakan pada saat yang
sama. Seringkali analis memulai dengan mengungkap sasaran menengah
(intermediate goals) terlebih dahulu. Selanjutnya, mereka melanjutkan
dengan mencari yang lebih tinggi, dan menemukan alasan setiap sasaran baru
(new goal) (dengan bertanya "mengapa kita menginginkan itu?"). Untuk juga
menemukan sub-goal yang lebih spesifik, analis harus bertanya pada diri
sendiri pertanyaan-pertanyaan seperti "bagaimana kita mencapai sasaran
itu?" (RESPECT-IT, 2007).
KAOS Goal Model adalah serangkaian diagram sasaran yang saling
terkait yang telah disatukan untuk mengatasi masalah tertentu (RESPECT-IT,
2007). Sedangkan menurut Werneck dkk goal model adalah seperangkat
diagram sasaran (goal) yang saling terkait, berisi sasaran (goals), sub-goals,
ekspektasi, konflik, kepemilikan domain (domain proprieties), resolusi,
hambatan, dan perbaikan/penyempurnaan hambatan (refinements of
obstacles) (Werneck et al., 2009).
Goal model pada dasarnya menunjukkan bagaimana sasaran
fungsional dan non fungsional sistem berkontribusi satu sama lain melalui
refinement links ke software requirements dan asumsi lingkungan. Goal
model dapat menangkap cara-cara alternatif untuk menyempurnakan goal dan
potensi konflik di antara mereka. Pada antarmuka dengan pandangan lain dari
sistem, goal model menangkap hubungan antar-model seperti responsibility
links antara goal dan agen sistem, obstruction links antara goal dan obstacle,
reference links dari goal ke conceptual objects, atau operationalization links
antara goal dan sistem operasi. Model ini juga menentukan fitur individual
dari setiap sasaran seperti nama dan spesifikasi yang tepat, jenisnya, kategori,
prioritas, sumber identifikasi dari mana sasarannya dan sebagainya.
27
UIN Syarif Hidayatullah Jakarta
Spesifikasi formal beberapa sasaran (goals) dapat secara opsional disediakan
untuk analisis lebih lanjut. (Lamsweerde, 2009)
Dalam sistem nyata, beberapa goal dapat saling bertentangan. Goals
saling bertentangan jika sistem dapat mencapai keadaan di mana tidak
mungkin untuk memenuhi kedua sasaran secara bersamaan. Misalnya,
sasaran kinerja dapat bertentangan dengan sasaran keselamatan; sasaran
informasi dapat bertentangan dengan sasaran keamanan dan privasi.
Keinginan dari peran pengguna yang berbeda juga dapat bertentangan. Sangat
penting untuk mengidentifikasi setiap sasaran yang bertentangan sesegera
mungkin dalam siklus hidup perangkat lunak (yang terbaik selama analisis
requirements). Menangani konflik atau lebih umum dengan hambatan yang
mencegah pencapaian sasaran memungkinkan requirements engineer untuk
membangun dokumen requirements yang lebih lengkap dan sistem yang lebih
kuat pada kesempatan pertama. (RESPECT-IT, 2007)
2.3.2. Responsibility Model
Selain goals, agen mewakili jenis konsep KAOS yang penting. Agen
adalah manusia atau komponen otomatis yang bertanggung jawab untuk
mencapai requirements dan ekspektasi (RESPECT-IT, 2007). Dalam metode
Gambar 2.4 A Goal Model
Sumber: A Kaos Tutorial (2007)
28
UIN Syarif Hidayatullah Jakarta
KAOS, saat melakukan analisis diharuskan mengaitkan setiap kebutuhan
(requirements) atau ekspektasi (expectations) dengan agen yang bertanggung
jawab untuknya. Sehingga pada metode KAOS: (RESPECT-IT, 2007)
1. Requirement adalah jenis sasaran tingkat rendah (low-level goals)
yang ingin dicapai oleh agen perangkat lunak.
2. Expectation adalah jenis sasaran yang ingin dicapai oleh agen
yang merupakan bagian dari lingkungan sistem.
Menurut Bashar Nuseibeh dan Steve Easterbrook responsibility
berarti bahwa agen berkomitmen untuk membatasi perilakunya dengan
melakukan operasi yang ditugaskan hanya dalam kondisi terbatas, yaitu yang
ditentukan oleh sebelum, sesudah, dan kondisi pemicu (Bano, Reddy, &
Khammari, 2018). Responsibility model mewakili tanggung jawab agen dan
antarmuka yang menggambarkan untuk masing-masing agen requirements di
bawah tanggung jawab dan ekspektasinya yang ditugaskan kepada agen.
Model ini berisi semua diagram tanggung jawab di mana setiap diagram
menunjukkan semua kebutuhan dan ekspektasi di bawah tanggung jawab
sebuah agen. (Werneck et al., 2009)
Gambar 2.5 Contoh Responsibility Model dari Sistem Elevator
Sumber: A Kaos Tutorial (2007)
29
UIN Syarif Hidayatullah Jakarta
Dalam banyak kasus, sasaran dapat diberikan kepada beberapa agen
daripada satu agen. Dengan KAOS, perbedaan dibuat antara dua
kemungkinan ini. Penugasan (assignment) digunakan ketika beberapa agen
mungkin bertanggung jawab atas beberapa kebutuhan atau harapan,
sedangkan tanggung jawab (responsibility) digunakan ketika hanya ada satu
agen yang bertanggung jawab untuk itu. Pada dasarnya, perbedaan ini
memberikan analis kriteria untuk berhenti memperbaiki goals menjadi sub-
goals, karena perbaikan tidak lagi diperlukan segera setelah sasaran
ditempatkan di bawah tanggung jawab agen tunggal. KAOS memungkinkan
diagram tanggung jawab (responsibility diagrams) diturunkan dari goal
model, setiap diagram menunjukkan semua kebutuhan atau ekspektasi yang
menjadi tanggung jawab agen. Diagram tanggung jawab KAOS adalah
serangkaian diagram tanggung jawab (responsibility diagrams) yang
diturunkan. (RESPECT-IT, 2007)
Gambar 2.6 Contoh Responsibility Model dari Agen Elevator Company
Sumber: A Kaos Tutorial (2007)
30
UIN Syarif Hidayatullah Jakarta
2.3.3. Object Model
Object model merupakan model UML yang dapat diturunkan dari
spesifikasi formal dari goals karena merujuk ke objek atau propertinya
(Parveen & Imam, 2017). Object model berisi objek, agen, entitas, dan
hubungan di antara mereka. Notasi yang digunakan dalam object model
sesuai dengan yang digunakan dalam UML untuk class diagram. Object
model digunakan untuk mendefinisikan dan mendokumentasikan konsep-
konsep domain sistem yang memiliki relevansi dengan kebutuhan sistem
yang telah diketahui dan untuk memberikan kendala statis pada sistem
operasional yang akan memenuhi kebutuhan. (RESPECT-IT, 2007)
Setiap objek dapat berkaitan dengan domain pemangku kepentingan
dan objek lain yang diperkenalkan dengan sasaran untuk mengungkapkan
kebutuhan atau kendala pada sistem operasional. Apa pun jenis objeknya,
para pemangku kepentingan harus memahami apa artinya dan mengapa itu
dibuat dalam model.
Adapun tiga tipe objek yang saling berdampingan dalam sebuah
object model: (RESPECT-IT, 2007)
1. Entities (entitas): mempresentasikan objek pasif yang tidak-
ketergantungan. Tidak ketergantungan disini berarti bahwa
deskripsi mereka tidak perlu mengacu pada objek lain dalam
model. Pasif disini berarti objek tersebut tidak bisa melakukan
operasi apapun. Entitas bisa saja memiliki atribut-atribut yang
nilainya mendefinisikan himpunan state yang valid untuk
bertransisi.
2. Agent (agen): mempresentasikan objek aktif yang tidak
ketergantungan. Aktif berarti mereka dapat melakukan operasi.
Sebuah operasi biasanya menyiratkan keadaan transisi pada
entitas.
3. Association (asosiasi): adalah objek pasif yang ketergantungan.
Ketergantungan berarti dekripsi mereka mengacu pada objek yang
lain. Objek-objek ini bisa memiliki atribut-atribut yang nilainya
31
UIN Syarif Hidayatullah Jakarta
mendefinisikan himpunan state valid yang dimana entitas bisa
bertransisi.
Identifikasi objek didorong oleh proses definisi goal. Ketika objek
baru diidentifikasi saat menjelajah melalui goal model, analis harus
mendefinisikannya dengan konsep yang ada (RESPECT-IT, 2007).
Sebagaimana yang terlihat pada Gambar 2.7 telah teridentifikasi
bahwa “alarm bell” merupakan komponen dari sistem elevator. Cara lain
untuk mengidentifikasi objek baru terdiri dari memilah kebutuhan sistem dan
menemukan komponen sistem yang diperlukan untuk memenuhi kebutuhan.
Objek dapat direpresentasikan dalam goal diagram, hubungan concerns
digunakan untuk menghubungkan kebutuhan dengan objek yang dibutuhkan
agar dipenuhi (lihat Gambar 2.8). Identifikasi objek-objek tersebut
Gambar 2.7 Contoh Object Model “Alarm Bell”
Sumber: A Kaos Tutorial (2007)
Gambar 2.8 Hubungan concerns “Alarm Bell”
Sumber: A Kaos Tutorial (2007)
32
UIN Syarif Hidayatullah Jakarta
selanjutnya akan membatasi ruang solusi yang dapat diusulkan oleh penyedia
sistem di masa depan. (RESPECT-IT, 2007)
Selanjutnya, Gambar 2.9 di bawah ini menampilkan komponen dari
elevator system. Gambar tersebut dapat dibaca:
Elevator System terbuat dari komponen-komponen berikut ini:
1. Satu atau beberapa cage.
2. Setidaknya terdiri dari 2 lantai.
3. Satu bel alarm, yang merupakan (spesialisasi) dari perangkat
alarm.
4. Satu elevator controller, berlokasi atau ditempatkan di ruangan
kontrol.
5. Satu system elevator terdiri dari satu power supply.
2.3.4. Operation Model
Operation model menjelaskan perilaku semua agen yang diperlukan
untuk mencapai kebutuhan (requirements) mereka. Perilaku dinyatakan
dalam hal operasi dan tugas yang dilakukan oleh agen. Operasi tersebut
bekerja dengan objek yang ditentukan dalam object model yang dapat
Gambar 2.9 Contoh Object Model dari Sistem Elevator
Sumber: A Kaos Tutorial (2007)
33
UIN Syarif Hidayatullah Jakarta
membuat, mengubah statusnya, dan mengaktifkan operasi lain. Model ini
mewakili visi fungsional layanan yang ditugaskan untuk masalah yang diteliti
di mana konsep-konsep berikut dapat muncul: operasi, agen, entitas dan
asosiasi, peristiwa dan pembatasan. (Werneck et al., 2009)
Agen perangkat lunak (software agents) bertanggung jawab atas
requirements. Operation model menggunakan KAOS merangkum semua
perilaku yang harus dimiliki agen untuk memenuhi kebutuhan (requirements)
mereka. Operasi-operasi itu bekerja pada objek yang dijelaskan dalam object
model. Mereka dapat membuat objek, memprovokasi transisi keadaan objek
atau memicu operasi lain melalui peristiwa yang dikirim dan diterima. Contoh
operasi yang dapat dilakukan oleh penumpang dalam sebuah sistem elevator
adalah menekan tombol masuk, dan menekan tombol keluar. (RESPECT-IT,
2007)
Operation diagram pada KAOS biasanya menyusun operasi yang
dilakukan oleh satu atau beberapa agen untuk mencapai requirements.
Komposisi dibuat melalui aliran data (output dari output operasi menjadi
input dari operasi lain) atau aliran kontrol (peristiwa yang dikirim oleh suatu
operasi memicu atau menghentikan operasi lain). Diagram operasi dengan
demikian menjelaskan bagaimana agen perlu bekerja sama untuk membuat
sistem bekerja. Dengan KAOS, operation model terhubung ke goal model.
para analis membenarkan operasi oleh sasaran (goal) yang mereka
"operasionalkan". Operasi tanpa pembenaran berarti bahwa masih ada
sasaran yang hilang dalam model atau bahwa operasi tidak diperlukan.
Sebaliknya jika beberapa kebutuhan dibiarkan tanpa "operasionalisasi",
mereka mungkin hanya angan-angan. (RESPECT-IT, 2007)
Operation direpresentasikan sebagai oval. Objek yang bersangkutan
(concerned objects) terhubung ke operasi melalui tautan Input dan Output.
Peristiwa direpresentasikan sebagai rambu lalu lintas yang digunakan untuk
menunjukkan arah. Peristiwa dapat bersifat eksternal atau diproduksi oleh
operasi (mereka merupakan hasil operasi). Peristiwa juga dapat menyebabkan
mulai atau berhentinya sebuah operasi. (RESPECT-IT, 2007)
34
UIN Syarif Hidayatullah Jakarta
Selanjutnya, Gambar 2.10 di atas merupakan contoh operation model
dari system elevator. Operation model tersebut dapat dibaca:
“Ketika seorang penumpang menekan tombol system elevator, sistem
memperbarui daftar operasi (reschedule) yang harus dijalankan oleh elevator
controller. Jadwal baru akan segera digunakan oleh elevator controller.
Untuk menjalankan jadwal, elevator controller harus mengetahui jadwal dan
status system elevator terbaru. Status system elevator diperbarui berkat
peristiwa khusus lainnya (elevator state change)”
Gambar 2.10 Contoh Operation Model
Sumber: A Kaos Tutorial (2007)
35
UIN Syarif Hidayatullah Jakarta
Dari penjelasan mengenai metode KAOS di atas, dapat diketahui
bahwa dalam proses menemukan goal dari sebuah sistem tidak ada teknik
spesifik yang menggunakan dokumen regulasi/peraturan perundang-
undangan sebagai sumber informasi untuk menemukan goal dari sistem.
Sedangkan dalam studi kasus penelitian ini, penulis memilih sistem yang ada
di kepemerintahan, yang mana biasanya pada setiap aplikasi atau sistem yang
ada di kepemerintahan menurut (I. Shofi, 2015) ada dokumen
regulasi/peraturan perundang-undangan yang relevan dengan aplikasi
tersebut. Untuk itu, penulis dalam penelitian ini akan mencoba untuk
mengkombinasikan metode KAOS dengan salah satu metode GORE yang
telah dikembangkan oleh Imam M. Shofi (2015) dalam membuat sebuah goal
model dengan berdasarkan dokumen regulasi yang memiliki relevansi dengan
sistem, yaitu metode SAR (Select Appropriate Regulations), dan R2G
(Regulations to Goal Model).
Metode SAR dan R2G
Metode SAR dan R2G adalah metode yang diusulkan oleh Imam M. Shofi
untuk membuat goal model dengan peraturan perundang-undangan sebagai sumber
informasinya (I. Shofi, 2015). Metode-metode ini pada umumnya digunakan untuk
pembuatan goal model pada aplikasi kepemerintahan, karena setiap aplikasi
kepemerintahan memiliki dasar/landasan peraturan perundang-undangan yang
bersesuaian dengannya (I. Shofi, 2015). Aplikasi kepemerintahan berorientasi pada
sasaran pelayanan kepada publik, sehingga porsi aspek keuntungan (profit) relatif
‘diabaikan’ (sebagai pendukung saja). Sedangkan aplikasi bisnis berorientasi pada
sasaran mencari profit dan pelayanan kepada publik hanya sebagai pendukung (I.
M. Shofi & Budiardjo, 2011).
36
UIN Syarif Hidayatullah Jakarta
Gabungan dari metode SAR dan metode R2G juga dapat dinamakan “pyramid
model” karena membentuk suatu model mirip piramida:
1. Metode SAR (Select Appropriate Regulations) merupakan metode untuk
memilih/menentukan dokumen regulasi/peraturan perundang-undangan
yang sesuai dengan aplikasi kepemerintahan yang ingin dikembangkan.
Gambar 2.11 Aplikasi Bisnis vs
Aplikasi Kepemerintahan
Sumber: I. M. Shofi & Budiardjo (2011)
Gambar 2.12 Pyramid Model
Sumber: Imam M. Shofi (2015)
37
UIN Syarif Hidayatullah Jakarta
2. Metode R2G (Regulations to Goal Model) merupakan metode untuk
mengekstrasi peraturan perundang-undangan menjadi goal model.
2.4.1. Metode SAR (Select Appropriate Regulations)
Penentuan dokumen regulasi (Metode SAR) bertujuan untuk mencari
dan menentukan dokumen regulasi apa saja yang akan digunakan sebagai
dasar atau landasan untuk menganalisis aplikasi kepemerintahan tertentu.
Masukkan (input) dari metode SAR adalah sekumpulan/daftar/database
dokumen regulasi/peraturan perundang- undangan, sedangkan keluarannya
(output-nya) adalah sekumpulan/set dokumen regulasi yang menjadi
dasar/landasan bagi aplikasi kepemerintahan tertentu. Berikut gambar
masukkan dan keluaran dari metode SAR:
Berdasarkan Gambar 2.13 dapat diketahui bahwa yang dimaksud
metode SAR adalah: (I. Shofi, 2015)
1. Asumsi : Telah tersedia basis data peraturan perundang-
undangan yang berlaku di Indonesia.
2. Kondisi Awal : Sembarang.
3. Kondisi Akhir : Terpilihnya peraturan perundang-undangan yang
menjadi dasar/landasan bagi aplikasi
kepemerintahan tertentu.
Gambar 2.13 Input dan Output Metode SAR
Sumber: Imam M. Shofi (2015)
38
UIN Syarif Hidayatullah Jakarta
Penjelasan lebih lanjut mengenai prosedur atau langkah-langkah dari
metode SAR dapat dilihat dari Gambar 2.14 di bawah ini beserta
penjelasannya:
Di bawah ini merupakan langkah/prosedur dari metode SAR dan
penjelasannya:
SAR-P1: Tentukan aplikasi (kepemerintahan) yang ingin
dianalisis/disusun "Goal Model"nya.
SAR-P2: Dari basis data peraturan perundang-undangan yang ada
(misal: JDIH), cari/tentukan peraturan perundang-undangan
yang (dapat) menjadi dasar/landasan aplikasi kepemerintahan
yang telah ditentukan pada prosedur P1 pada level yang
(ditentukan) paling rendah terlebih dahulu. Jika tidak
ditemukan pada level terendah, maka cari/tentukan peraturan
perundang-undangan satu level diatasnya, demikian seterusnya
sampai ditemukan peraturan perundangan-undangan yang
sesuai pada level tertentu.
Gambar 2.14 Langkah-langkah Metode SAR
Sumber: Imam M. Shofi (2015)
39
UIN Syarif Hidayatullah Jakarta
SAR-P3: Cari/tentukan peraturan perundang-undangan di level atasnya
dengan cara melihat isi peraturan perundang-undangan yang
telah ditentukan dengan merujuk pada bagian “mengingat".
Ambil peraturan perundang-undangan level atasnya yang
dirujuk pada bagian "mengingat" tersebut.
SAR-P4: Analisis lebih mendalam terhadap semua kandidat melalui
bagian "Menimbang", "Mengingat", dan
"Memustuskan/Menetapkan". Pilih kandidat yang mempunyai
hubungan erat dengan proses/aktifitas pada sistem/aplikasi
yang dipilih sebagai studi kasus.
SAR-P5: Ulangi prosedur P3 sampai diperoleh peraturan perundang-
undangan pada level undang-undang.
2.4.2. Metode R2G (Regulations to Goal Model)
Metode R2G (regulations to goal model) bertujuan untuk
mengekstraksi peraturan perundang-undangan menjadi goal model. Peraturan
perundang-undangan yang dimaksud pada metode ini, merupakan peraturan
perundang-undangan yang telah terpilih pada metode SAR. Masukkan (input)
dari metode R2G adalah sekumpulan/set dokumen regulasi yang menjadi
dasar/landasan bagi aplikasi kepemerintahan tertentu, sedangkan keluarannya
(output-nya) adalah daftar kebutuhan berupa goal model yang
sesuai/mengacu pada dokumen regulasi. Berikut gambar masukkan dan
keluaran dari metode R2G:
Pada metode R2G untuk menyusun goal model dengan sumber
informasi peraturan perundang-undangan, terbagi menjadi 2 bagian utama,
Gambar 2.15 Input dan Output Metode R2G
Sumber: Imam M. Shofi (2015)
40
UIN Syarif Hidayatullah Jakarta
yaitu: bagian metode/prosedur umum dan bagian metode/prosedur ekstraksi,
seperti terlihat pada Gambar 2.16
1. Prosedur Umum
Berikut ini merupakan tahapan dan penjelasan dari prosedur umum:
R2G-UP1: Tentukan aplikasi (kepemerintahan) yang ingin
dianalisis/disusun "Goal Model"nya.
R2G-UP2: Tentukan peraturan perundang-undangan sesuai hierarkinya
(yang tertinggi cukup sampai Undang-undang), yang menjadi
dasar/landasan bagi aplikasi tersebut sesuai metode SAR.
R2G-UP3: Tentukan "goal" pokok/utama dari Aplikasi yang dipilih
pada P1.
R2G-UP4: Dengan terfokus pada "goal" pokok/utama hasil dari P3,
"Ekstrak" peraturan perundang-undangan yang menjadi
landasan, berdasarkan hierarkinya (mulai dari yang tertinggi
hingga terendah)
Prosedur R2G-UP1 dan R2G-UP2 merupakan metode SAR yang
telah dijelaskan sebelumnya.
2. Prosedur Ekstraksi:
Di bawah ini merupakan tahapan dan penjelasan dari prosedur
ekstraksi:
Gambar 2.16 Pembagian Prosedur Metode R2G
Sumber: Imam M. Shofi (2015)
41
UIN Syarif Hidayatullah Jakarta
R2G-EP1: Berdasarkan “goal” pokok/utama yang telah ditentukan pada
prosedur umum, tentukan “kata kunci” yang mempunyai
kaitan erat dengannya.
R2G-EP2: Abaikan bagian “menimbang”, “mengingat”, dan
“memutuskan”, dan lain-lain. Langsung menuju ke Bab I
dan/atau Pasal 1
R2G-EP3: Jika pasal 1 merupakan definisi/singkatan/istilah, cari
singkatan/istilah yang terdapat pada pasal 1 dimana
kepanjangan/keterangannya mengandung “kata kunci”,
dengan cara:
EP3.1: Telusuri pasal 1 tersebut ayat demi ayat sampai akhir
ayat dari pasal 1 berdasarkan “kata kunci”.
EP3.2: Jika ditemukan “kata kunci”, cek kalimat utuh dari
ayat tsb. Jika ditemukan suatu singkatan/istilah,
ambil/gunakan singkatan/istilah tsb. Untuk ditambah-
kan/dijadikan sebagai “kata kunci” juga sebagaimana
pada prosedur P1.
R2G-EP4: Tentukan kandidat-kandidat kalimat yang mengandung
“goal”, dengan cara:
EP4.1: Telusuri bab demi bab, pasal demi pasal, ayat demi
ayat sampai akhir dokumen (satu peraturan
perundang-undangan) yang mengandung “kata
kunci”.
EP4.2: Jika ditemukan “kata kunci” dalam suatu ayat/kali-
mat, ambil kalimat tersebut dengan struktur
Subyek+Predikat+Obyek+[Keterangan]. Masukkan
kalimat tersebut dalam suatu daftar/list kandidat goal.
R2G-EP5 Telusuri kandidat goal satu per satu, dengan fokus pada
"bagaimana untuk" (how to) mencapai "goal" yang telah
ditentukan. Jika ditemukan kalimat yang merupakan "how to"
dari "goal" yang telah ditentukan, maka ambil kalimat
42
UIN Syarif Hidayatullah Jakarta
tersebut, dan jadikan sebagai "sub goal" dari "goal" yang
telah ditentukan. Kalimat yang bukan merupakan "how to"
dari "goal", diabaikan saja.
R2G-EP6 Kalimat "sub goal" yang baru/telah ditemukan,
merupakan/menjadi "goal" baru yang dapat dijadikan fokus
pada penelusuran berikutnya untuk mencari "sub goal"
darinya. Tentu saja, "goal" utama yang telah
ditentukan/ditemukan sebelumnya, tetap menjadi fokus pada
penelusuran berikutnya juga. Sehingga fokusnya sekarang
menjadi pada "goal" dan "sub goal"nya.
R2G-EP7 Jika "sub goal" yang baru ditemukan, merupakan "sub goal"
kedua/ketiga/dst dari satu "goal" yang sama, maka jika
memungkinkan (dapat diperoleh dari informasi kalimat),
tentukan relasi antar "sub goal" tersebut, apakah merupakan
relasi "AND" atau "OR" dalam mencapai satu "goal" yang
diharapkan. Jika tidak/belum dapat ditentukan relasinya,
maka lewati dulu penentuan relasi tsb., ada kemungkinan
informasi relasi tersebut ada pada kalimat-kalimat
berikutnya.
R2G-EP8 Ulangi langkah EP5, EP6, dan EP7 sampai penelusurannya
selesai di kalimat terakhir dari daftar kandidat goal.
R2G-EP9 Cek ulang "Goal Model" yang terbentuk sedemikian
sehingga "Goal model" tersebut merupakan "Goal Model"
yang tepat. Ubah/sesuaikan susunan kalimat sedemikian
sehingga merupakan pernyataan “goal”.
Berdasarkan penjelasan mengenai prosedur/langkah-langkah yang
ada dalam metode R2G di atas, dapat diketahui alur atau rincian metode R2G:
43
UIN Syarif Hidayatullah Jakarta
Sistem Pengaduan Masyarakat
2.5.1. Definisi Sistem
Berikut pengertian sistem yang dikemukakan oleh para ahli, yaitu:
(Hutahaean, 2014)
1. Menurut Indrajit sistem mengantung arti kumpulan-kumpulan dari
komponen-komponen yang memiliki unsur keterkaitan antara satu
dengan yang lainnya.
2. Pengertian sistem menurut Jogianto yaitu kumpulan dari elemen-
elemen yang berinteraksi untuk mencapai tujuan tertentu. Sistem
ini menggambarkan kejadian-kejadian dan kesatuan yang nyata
Gambar 2.17 Langkah-langkah Metode R2G
Sumber: Imam M. Shofi (2015)
44
UIN Syarif Hidayatullah Jakarta
adalah suatu objek nyata, seperti tempat, benda, dan orang-orang
yang betul-betul ada dan terjadi.
3. Menurut Fat pengertian sistem adalah sebagai berikut: “sistem
adalah suatu himpunan, suatu benda, suatu yang nyata atau abstrak
(a set of thing) yang terdiri dari bagian-bagian atau komponen-
komponen yang saling berkaitan, berhubungan,
berketergantungan, saling mendukung yang secara keseluruhan
bersatu dalam satu kesatuan (unity) untuk mencapai tujuan tertentu
secara efisien dan efektif”.
4. Definisi sistem menurut Dr. Ir. Harijono Djojodihardjo yaitu
sekumpulan objek yang mencakup hubungan fungsional antara
tiap-tiap objek dan hubungan antara ciri tiap objek, dan secara
keseluruhan merupakan satu kesatuan secara fungsional.
Berdasarkan pengertian diatas penulis menyimpulkan bahwa sistem
adalah kumpulan dari bagian-bagian atau komponen-komponen yang saling
berhubungan, tidak dapat terpisahkan dan menjadi satu-kesatuan yang utuh.
2.5.2. Karakterteristik Sistem
Berikut karakteristik dari sistem yang menjadi ukuran bahwa sistem
itu baik atau tidak, yaitu: (Hutahaean, 2014)
1. Komponen
Suatu sistem terdiri dari sejumlah komponen-komponen yang saling
berinteraksi, yang artinya saling bekerja sama membentuk satu kesatuan.
Komponen sistem terdiri dari komponen yang berupa subsistem atau bagian-
bagian dari sistem.
2. Batasan sistem (boundary)
Batasan sistem merupakan daerah yang membatasi suatu sistem
dengan sistem yang lain atau dengan lingkungan luarnya. Batasan sistem ini
memungkinkan suatu sistem dipandang sebagai suatu kesatuan. Batasan suatu
sistem menunjukkan ruang lingkup dari sistem tersebut.
3. Lingkungan luar sistem (environtment)
45
UIN Syarif Hidayatullah Jakarta
Lingkungan luar sistem adalah diluar batas dari sistem yang
mempengaruhi operasi sistem. Lingkungan dapat bersifat menguntungkan
yang harus tetap dijaga dan yang merugikan yang harus dijaga dan
dikendalikan, kalau tidak akan mengganggu kelangsungan hidup dari sistem.
4. Penghubung sistem (interface)
Penghubung sistem merupakan media penghubung antara satu
subsistem dengan subsistem lainnya. Melalui penghubung ini memungkinkan
sumber-sumber daya mengalir dari subsistem ke subsistem lain. Keluaran
dari subsistem akan menjadi masukkan untuk subsistem lain melalui
penghubung.
5. Masukkan sistem (input)
Masukkan adalah energy yang dimasukkan ke dalam sistem, yang
dapat berupa perawatan (maintenance input) dan masukkan sinyal (signal
input). Maintenance input adalah energi yang dimasukkan agar sistem dapat
beroperasi. Signal input adalah energi yang diproses untuk didapatkan
keluaran. Contoh dalam sistem komputer, program adalah maintenance input
sedangkan data adalah signal input untuk diolah menjadi informasi.
6. Keluaran sistem (output)
Keluaran sistem adalah hasil dari energi yang diolah dan
diklasifikasikan menjadi keluaran yang berguna dan sisa pembuangan.
Contohnya komputer menghasilkan panas yang merupakan sisa pembuangan,
sedangkan informasi adalah keluaran yang dibutuhkan.
7. Pengolah Sistem
Suatu sistem menjadi bagian pengolah yang akan merubah masukkan
menjadi keluaran. Sistem produksi akan mengolah bahan baku menjadi bahan
jadi, sistem akuntansi akan mengolah data menjadi laporan-laporan
keuangan.
8. Sasaran Sistem
46
UIN Syarif Hidayatullah Jakarta
Suatu sistem pasti mempunyai sasaran (goal). Sasaran dari sistem
sangat menentukan input yang dibutuhkan sistem dan keluaran yang akan
dihasilkan sistem.
2.5.3. Klasifikasi Sistem
Sebuah sistem dapat diklasifikasikan menurut berbagai sudut
pandang, yaitu: (Hutahaean, 2014)
1. Sistem abstrak dan fisik
Sistem abstrak adalah sistem yang berupa pemikiran-pemikiran
atau ide-ide yang tidak tampak secara fisik.
Sistem fisik adalah sistem yang ada secara fisik.
2. Sistem alamiyah dan buatan manusia
Sistem alamiyah adalah sistem yang terjadi melalui proses alam,
tidak dibuat oleh manusia, misalnya sistem perputaran bumi.
Sistem buatan manusia adalah sistem yang dibuat oleh manusia
yang melibatkan interaksi antara manusia dengan mesin (human
machine system)
Gambar 2.18 Karakteristik Dari Suatu Sistem
Sumber: Konsep Sistem Informasi (2014)
47
UIN Syarif Hidayatullah Jakarta
3. Sistem tertentu dan tak tentu
Sistem tertentu adalah sistem yang beroperasi dengan tingkah
laku yang sudah dapat diprediksi, sebagai keluaran sistem yang
dapat diramalkan.
Sistem tak tentu adalah sistem yang kondisi masa depannya tidak
dapat diprediksi karena mengandung unsur probabilistik.
4. Sistem tertutup dan terbuka
Sistem tertutup adalah sistem yang tidak terpengaruh dan tidak
berhubungan dengan lingkungan luar, sistem bekerja secara
otomatis tanpa ada turut campur lingkungan liar. Secara teoritis
sistem tertutup ini ada, kenyataannya tidak ada sistem yang
benar-benar tertutup, yang ada hanya relatively system.
Sistem terbuka adalah sistem yang berhubungan dan terpengaruh
dengan lingkungan luarnya. Sistem ini menerima input dan
output dari lingkungan luar atau subsistem lainnya. Karena sistem
terbuka terpengaruh lingkungan luar maka harus mempunyai
pengendali yang baik.
2.5.4. Pengaduan Masyarakat
Pengaduan masyarakat merupakan suatu sumber informasi bagi
berbagai upaya pemerintah sebagai penyelenggara pelayanan untuk secara
konsisten menjaga pelayanan yang diberikan (Chazienul Ulum, 2018).
Masyarakat sebagai pengguna dan penerima layanan dari pemerintah
mempunyai hak untuk memberikan aspirasi berupa keluhan/pengaduan,
masukkan, dan saran tentang permasalahan pelayanan publik yang diterima.
(Chazienul Ulum, 2018)
Berdasarkan KepmenPAN ada 2 jenis pengaduan masyarakat, yaitu:
(Chazienul Ulum, 2018)
1. Pengaduan berkadar pengawasan, adalah pengaduan masyarakat
yang isinya mengandung informasi atau adanya indikasi
terjadinya penyimpangan atau penyalahgunaan wewenang oleh
48
UIN Syarif Hidayatullah Jakarta
aparatur negara yang dapat mengakibatkan kerugian masyarakat
atau negara dalam rangka pengelenggaraan pemerintahan.
2. Pengaduan yang tidak berkadar pengawasan adalah pengaduan
masyarakat yang isinya mengandung informasi berupa sumbangan
saran, kritik yang konstruktif dan lain sebagainya yang bermanfaat
bagi perbaikan penyelenggaraan pemerintahan dan pelayayanan
masyarakat.
Tujuan utama penanganan pengaduan adalah untuk meminimalkan
dampak negatif akibat kegagalan layanan dan pada akhirnya
mempertahankan loyalitas pelanggan (Chazienul Ulum, 2018).
Metode Pengumpulan data
Menurut Sudaryono metode pengumpulan data adalah teknik atau cara-cara
yang dapat digunakan oleh peneliti untuk mengumpulkan data. (Rahman, 2017)
2.6.1. Studi Pustaka
Menurut Sudaryono studi pustaka adalah menganalisis secara kritis
pustaka penelitian yang ada saat ini. Studi pustaka tersebut perlu dilakukan
secara ketat dan harus mengandung keseimbangan antara uraian deskriptif
dan analisis. Identifikasi kekuatan dan kelemahan pustaka tersebut dengan
menelaah hasil atau temuan penelitian tersebut, metodologi yang digunakan,
serta bagaimana hasil temuan tersebut dibandingkan penelitian atau publikasi
lainnya. (Rahman, 2017)
2.6.2. Observasi
Observasi sebagai teknik pengumpulan data mempunyai ciri yang
spesifik dibandingkan dengan teknik yang lain, yaitu wawancara dan
kuesioner. Apabila wawancara dan kuesioner selalu berkomunikasi dengan
manusia, maka observasi tidak terbatas pada manusia, tetapi juga pada objek-
objek alam yang lain. Observasi digunakan apabila penelitian berkenaan
dengan perilaku manusia, proses kerja, gejala-gejala alam dan apabila
responden yang diamati tidak terlalu besar. (Sugiyono, 2016)
Dari segi proses pelaksanaan pengumpulan data, observasi dibedakan
menjadi: (Sugiyono, 2016)
49
UIN Syarif Hidayatullah Jakarta
1. Observasi Berperan Serta
Dalam observasi ini, peneliti terlibat dalam kegiatan sehari-hari
orang atau objek yang sedang diamati atau yang digunakan
sebagai sumber data penelitian.
2. Observasi Nonpartisipan
Observasi nonpartisipan artinya peneliti tidak terlibat dalam
kegiatan objek, melainkan hanya sebagai pemangat independen.
Berdasarkan segi intrumentasi yang digunakan, observasi dibedakan
menjadi: (Sugiyono, 2016)
3. Observasi terstruktur adalah observasi yang telah dirancang secara
sistematis, tentang apa yang akan diamati, kapan, dan dimana
tempatnya.
4. Observasi tidak terstruktur adalah observasi yang tidak
dipersiapkan secara sistematis tentang apa yang akan diobservasi.
2.6.3. Wawancara
Wawancara digunakan sebagai teknik pengumpulan data apabila
peneliti ingin melakukan studi pendahuluan untuk menemukan permasalahan
yang harus diteliti, dan juga apabila peneliti ingin mengetahui hal-hal dari
responden yang lebih mendalam dan jumlah respondennya sedikit/kecil.
Teknik ini mendasarkan diri pada laporan tentang diri sendiri atau self-report,
atau setidak-tidaknya pada pengetahuan dana tau keyakinan pribadi.
(Sugiyono, 2016)
Wawancara dapat dilakukan secara terstruktur maupun tidak
terstruktur. Wawancara terstruktur digunakan sebagai teknik pengumpulan
data, bila peneliti atau pengumpul data telah mengetahui dengan pasti
mengenai informasi apa yang akan diperoleh. Wawancara tidak terstruktur
atau terbuka sering digunakan dalam penelitian pendahuluan atau untuk
penelitian yang lebih mendalam tentang responden. (Sugiyono, 2016)
50
UIN Syarif Hidayatullah Jakarta
Analisis Kesenjangan
Analisis kesenjangan (Gap Analysis) salah satu alat yang dapat digunakan
untuk mengevaluasi kinerja perusahaan. Analis kesenjangan juga merupakan salah
satu langkah yang sangat penting dalam tahapan perencanaan maupun tahap
evaluasi kerja. Metode ini merupakan salah satu metode yang paling umum
digunakan dalam pengelolaan intemal suatu lembaga. Secara harfiah "gap”
mengidentifikasikan adanya suatu perbedaan (disparity) antara satu hal dengan hal
lainnya. (Nasir, 2014)
Berdasarkan definisi tersebut, dapat disimpulkan bahwa secara umum analisis
kesenjangan dapat dikatakan sebagai suatu metode yang dapat digunakan untuk
mengetahui tingkat kesenjangan dari sebuah perusahaan, dengan cara
membandingkan kinerja perusahaan saat ini dengan sistem yang sebenarnya
diinginkan atau diharapkan.
Tingkat kesenjangan diperoleh dengan perhitungan sebagai berikut:
(Luthfi Azis & Lestariningsih, 2018)
X= Tingkat kematangan yang diharapkan (to be)
Y= Tingkat kematangan saat ini (as is)
Setelah mendapatkan tingkat kesenjangan antara kinerja perusahan saat ini
dengan kinerja yang sebenarnya diharapkan oleh perusahaan, maka perusahaan
dapat mencari solusi atau melakukan pendekatan agar dapat mengingkatkan kinerja
perusahaannya.
Tingkat Kesenjangan = (X-Y)
51
UIN Syarif Hidayatullah Jakarta
Tinjauan Pustaka (Literature Review)
Pada Tabel 2.2 di bawah ini, dijelaskan mengenai berbagai penelitian yang telah dilakukan sebelumnya, yang memiliki
keterkaitan dengan penelitian yang dilakukan penulis.
Tabel 2.2 Penelitian Sejenis
No Judul Penelitian Penulis Metode Deskripsi
1 Analisis Website
Perpustakaan UIN
Menggunakan Metode
Benchmarking dan GORE
Model (Studi Kasus: UIN
Jakarta, UIN Yogjakarta,
UIN Malang)
(Aini,
2018)
- Metode GORE yang
digunakan adalah i*.
- Metode untuk
membandingkan tiga sistem
menggunakan metode
benchmarking.
- Metode pengumpulan data
yang digunakan adalah studi
pustaka, observasi, kuesioner.
- Menggunakan teknik stakeholders driven
(observasi), dan artefacts driven (studi latar
belakang, dan kuesioner) dalam mencari
goal dan kebutuhan sistem.
- Observasi sistem dilakukan dari luar, tanpa
masuk ke dalam sistem (login as admin).
- Melakukan analisis terhadap 3 website
perpustakaan.
2 Analisis Requirement Sistem
Evaluasi Dosen Oleh
Mahasiswa (EDOM) Online
UIN Syarif Hidayatullah
dengan Goal Oriented
Requirement Engineering
(GORE) Model
(Fuadiyati,
2018)
- Metode GORE yang
digunakan adalah metode
Keep All Objectives Satisfied
(KAOS).
- Metode pengumpulan data
yang digunakan adalah
kuesioner, observasi,
wawancara, studi latar
belakang, dan studi literatur.
- Menggunakan stakeholders driven
(wawancara) dan artefacts driven (observasi
dan dokumen) dalam mencari goal dan
kebutuhan sistem.
- Melakukan validasi terhadap pemodelan
yang telah dibuat.
- Melakukan analisis kesenjangan terhadap
kebutuhan sistem saat ini dibandingkan
kebutuhan sistem yang sesungguhnya
diinginkan.
52
UIN Syarif Hidayatullah Jakarta
No Judul Penelitian Penulis Metode Deskripsi
3 PENERAPAN GOAL
ORIENTED
REQUIREMENTS
ENGINEERING (Gore)
MODEL (STUDI KASUS:
PENGEMBANGAN
SISTEM INFORMASI
PENJAMINAN MUTU
DOSEN (SIPMD) PADA
INSTITUSI PENDIDIKAN
TINGGI)
(Adikara et
al., 2013)
- Menggunakan pendekatan
berdasarkan sasaran (Metode
KAOS), dan pendekatan
berdasarkan proses bisnis.
- Metode pegumpulan data
yang digunakana adalah
wawancara, dan studi
pustaka.
Menggunakan teknik stakeholders driven
(wawancara dan brainstorming session) serta
artefact driven (studi latar belakang) dalam
mencari kebutuhan sistem.
4 MODULAR
EXOSKELETON DESIGN:
REQUIREMENT
ENGINEERING WITH
KAOS
(Souza et
al., 2016)
- Metode GORE yang
digunakan adalah metode
KAOS (Keep All Objectives
Satisfied).
- Metode pengumpulan data
yang digunakan adalah studi
pustaka.
Menggunakan teknik artefacts driven, yaitu
knowledge reuse dalam mencari goal dan
kebutuhan sistem.
5 METODE ANALISIS PRA-
SYARAT PERANGKAT
LUNAK BERORIENTASI
SASARAN
BERDASARKAN
DOKUMEN REGULASI
(I. Shofi,
2015)
- Metode pemilihan dokumen
regulasi yang memiliki
relevansi dengan sistem,
yaitu Select Appropriate
Regulations (SAR)
- Metode ekstraksi dokumen
regulasi menjadi goal model,
- Menggunakan teknik artefacts driven, yaitu
dokumen regulasi untuk membuat goal
model.
- Membuat 3 metode baru dalam pendekatan
GORE, yaitu SAR, R2G, dan GCC.
53
UIN Syarif Hidayatullah Jakarta
yaitu Regulations to Goal
Model (R2G)
- Metode pengecekan
konsistensi goal, yaitu Goal
Consistency Checking
(GCC).
- Metode pengumpulan data
yang digunakan adalah
wawancara, studi literatur,
dan kuesioner.
Sebagaimana yang terlihat pada tabel Tabel 2.2 di atas, terdapat beberapa penelitian terkait goals oriented requirements
engineering (GORE), baik itu penelitian mengenai analisis kebutuhan dengan mengimplementasikan salah satu metode yang ada pada
GORE, maupun penelitian dengan membandingkan metode-metode yang ada pada GORE. Berdasarkan hal tersebut, dapat diketahui
perbedaan dan keunggulan dari penelitian yang dilakukan oleh penulis dibandingkan dengan penelitian-penelitian yang telah dilakukan
sebelumnya, sebagaimana terlihat pada Tabel 2.3 di bawah ini:
54
UIN Syarif Hidayatullah Jakarta
Tabel 2.3 Perbedaan Penelitian
Penelitian Menggabungkan
metode yang ada
pada GORE
Teknik Pengumpulan Data
dalam Requirements
Engineering
Menggunakan
Dokumen Regulasi
Sebagai Salah Satu
Acuan dalam
Membuat goal
Validasi
Model
Analisis
Kesenjangan
(gap
analysis) Artefacts
Driven
Stakeholders
Driven
Analisis Website Perpustakaan
UIN Menggunakan Metode
Benchmarking dan GORE
Model (Studi Kasus: UIN
Jakarta, UIN Yogjakarta, UIN
Malang)
√ √
Analisis Requirement Sistem
Evaluasi Dosen Oleh Mahasiswa
(EDOM) Online UIN Syarif
Hidayatullah dengan Goal
Oriented Requirement
Engineering (GORE) Model
√ √ √ √
55
UIN Syarif Hidayatullah Jakarta
Penelitian Menggabungkan
metode yang ada
pada GORE
Teknik Pengumpulan Data
dalam Requirements
Engineering
Menggunakan
Dokumen Regulasi
Sebagai Salah Satu
Acuan dalam
Membuat goal
Validasi
Model
Analisis
Kesenjangan
(gap
analysis) Artefacts
Driven
Stakeholders
Driven
Penerapan Goal Oriented
Requirements Engineering
(GORE) Model (Studi Kasus:
Pengembangan Sistem Informasi
Penjaminan Mutu Dosen
(SIPMD) Pada Institusi
Pendidikan Tinggi)
√ √
Modular Exoskeleton Design:
Requirement Engineering With
KAOS
√
Metode Analisis Pra-syarat
Perangkat Lunak Berorientasi
Sasaran Berdasarkan Dokumen
Regulasi
√ √
56
UIN Syarif Hidayatullah Jakarta
Penelitian Menggabungkan
metode yang ada
pada GORE
Teknik Pengumpulan Data
dalam Requirements
Engineering
Menggunakan
Dokumen Regulasi
Sebagai Salah Satu
Acuan dalam
Membuat goal
Validasi
Model
Analisis
Kesenjangan
(gap
analysis) Artefacts
Driven
Stakeholders
Driven
Analisis Kebutuhan Sistem
Pengaduan Masyarakat (SPM)
Online DPR RI Berorientasi
Sasaran Menggunakan Metode
SAR (Select Appropriate
Regulations), R2G (Regulations
to Goal Model), dan KAOS
(Keep All Objectives Satisfied)
√ √ √ √ √ √
Berdasarkan tinjauan pustaka di atas, penulis melakukan penelitian untuk menganalisis kebutuhan Sistem Pengaduan Masyarakat
Online DPR RI berorientasi sasaran dengan menggunakan metode SAR (Select Appropriate Regulaions), R2G (Regulations to Goal
Model), dan KAOS (Keep All Objectives Satisfied).
57
BAB 3
METODOLOGI PENELITIAN
Metode Pengumpulan Data
Penulis melakukan pengumpulan data sebagai cara untuk mendapatkan data
yang berkaitan dengan penelitian seperti latar belakang penelitian, landasan teori,
metodologi penelitian, dan pembahasan. Pada penelitian ini penulis menggunakan
studi pustaka, wawancara, dan observasi sebagai metode pengumpulan data.
3.1.1. Studi Pustaka
Studi pustaka dilakukan untuk mencari data atau informasi yang valid
agar dapat dijadikan sebagai referensi dan bahan untuk penelitian. Pencarian
dilakukan dengan cara mengumpulkan dan mempelajari referensi yang
memiliki relevansi dengan penelitian penulis. Dari referensi yang didapatkan,
penulis menggunakannya sebagai bahan penulisan dalam latar belakang,
landasan teori, metode penelitian, dan metode pengumpulan data. Semua
referensi yang digunakan penulis sebagai bahan dalam penelitian ini ditulis
sumber atau rujukannya pada daftar pustaka skripsi.
3.1.2. Observasi
Dalam penelitian ini, observasi dilakukan secara menyeluruh dan
lebih mendalam terhadap SPM Online DRR RI yang sedang berjalan saat ini,
yaitu melalui situs www.pengaduan.dpr.go.id. Proses yang dilakukan oleh
penulis dalam observasi sistem ini dibagi menjadi dua, yaitu observasi yang
dilakukan dengan menggunakan akses sebagai masyarakat, dan sebagai
administrator website. Penulis memulai observasi dengan mengecek fungsi
dari setiap fitur yang tersedia di dalam system-as-is, baik itu sebagai
administrator maupun sebagai masyarakat.
3.1.3. Wawancara
Wawancara dilakukan secara langsung dengan Kasubbag Analisis
Pengaduan Masyarakat II Sekretariat Jendral DPR RI. Wawancara dilakukan
untuk mengetahui kondisi sistem saat ini (system-as-is), dan untuk
mengetahui sasaran dan kebutuhan SPM Online DPR RI yang sesungguhnya
58
UIN Syarif Hidayatullah Jakarta
diinginkan (system-to-be).
Metode KAOS
Dalam membuat pemodelan (goal model, dan responsibility model) dari SPM
Online DPR RI, penulis menggunakan Goal Oriented Requirements Engineering
(GORE) dengan metode Keep All Objectives Satisfied (KAOS). Pada penelitian ini,
penulis berfokus pada 4 tahap dalam penggunaan metode KAOS, yaitu:
3.2.1. Membangun Goal Model
Pada penelitian ini, goal model dibuat sebanyak tiga kali. Pertama,
digunakan untuk menggambarkan system-as-is dengan menggunakan
dokumen Standar Operasional Prosedur, observasi system-as-is
(www.pengaduan.dpr.go.id) dengan akses sebagai masyarakat dan
administrator website, serta wawancara dengan Kasubbag Analisis
Pengaduan Masyarakat II sebagai sumber informasi untuk membuat goal
model. Goal model yang kedua untuk menggambarkan system-to-be dengan
didasari pada perbaikan atau perkembangan apa saja yang dapat dilakukan
dari system-as-is serta didasari pada goal diagram yang didapatkan dari
penggunaan metode SAR dan R2G. Goal model yang terakhir merupakan
goal model dari system-to-be akhir, yaitu goal model setelah dilakukan
validasi kepada Kasubbag Analisis Pengaduan Masyarakat II.
3.2.2. Membangun Responsibility Model
Pada penelitian ini, Responsibility model digunakan untuk
menggambarkan tanggungjawab untuk setiap agen yang ada pada sistem
maupun agen yang ada pada lingkungan sistem. Pembuatan responsibility
model mengacu pada goal model yang telah dibuat sebelumnya. Semua
kebutuhan sistem dan expectation ditetapkan pada setiap agen yang
berwenang. Agen diletakkan ditengah diagram dan semua kebutuhan sistem
untuk agen tersebut digambarkan di sekitar agen.
3.2.3. Validasi Goal Model
Validasi goal model dilakukan dengan melakukan presentasi dan
klarifikasi terhadap hasil goal model yang telah dibuat sebelumnya kepada
Kasubbag Analisis Pengaduan Masyarakat II. Tujuan dari validasi goal model
59
UIN Syarif Hidayatullah Jakarta
untuk mengetahui bagian dari goal model yang masih terdapat kesalahan. Jika
terdapat kesalahan, penulis akan memperbaiki goal model tersebut.
3.2.4. Validasi Responsibility Model
Validasi responsibility model dilakukan dengan melakukan presentasi
dan klarifikasi terhadap hasil responsibility model yang telah dibuat
sebelumnya kepada Kasubbag Analisis Pengaduan Masyarakat II. Tujuan
dari validasi responsibility model untuk mengetahui bagian dari responsibility
model yang masih terdapat kesalahan. Jika terdapat kesalahan, penulis akan
memperbaiki responsibility model tersebut.
Metode SAR dan R2G
Dalam proses mendapatkan goal dari SPM Online DPR RI yang bersumber
dari dokumen regulasi/peraturan perundang-undangan, penulis menggunakan
pendekatan Goal Oriented Requirement Engineering (GORE) dengan metode SAR
dan R2G.
3.3.1. Metode SAR (Select Appropriate Regulations)
Dalam penelitian ini, penulis menggunakan metode SAR (Select
Appropriate Regulations) untuk menentukan dokumen regulasi/peraturan
perundang-undangan yang terkait/relevan dengan SPM Online DPR RI. Input
dari metode SAR adalah daftar dokumen regulasi/peraturan perundang-
undangan. Output dari metode SAR berupa peraturan perundang-undangan
pada level undang-undang, yang memiliki keterkaitan dengan SPM Online
DPR RI. Hasil atau output dari metode SAR akan digunakan sebagai input
pada metode selanjutnya (metode R2G).
3.3.2. Metode R2G (Regulations to Goal Model)
Metode R2G (Regulations to Goal Model) digunakan untuk
mendapatkan daftar goal dari SPM Online DPR RI berdasarkan dokumen
regulasi. Input dari metode R2G adalah daftar atau database dokumen
regulasi yang memiliki keterkaitan dengan SPM Online DPR RI. Output
metode R2G berupa preliminary goals (sasaran awal) atau daftar goal dari
SPM Online DPR RI yang didasarkan pada dokumen regulasi. Hasil atau
60
UIN Syarif Hidayatullah Jakarta
output dari metode R2G akan digunakan sebagai salah satu input pada metode
selanjutnya (metode KAOS).
Analisis Kesenjangan (Gap Analysis)
Analisis kesenjangan sistem dilakukan untuk mengidentifikasi perbaikan
yang perlu dilakukan oleh Bagian Pengaduan Masyarakat terhadap Sistem
Pengaduan Masyarakat Online yang ada saat ini (www.pengaduan.dpr.go.id).
Kesenjangan didapatkan ketika penulis menemukan kelemahan yang ada pada SPM
Online DPR RI saat ini (system-as-is), dan membandingkannya dengan sistem yang
sebenarnya diinginkan oleh Bagian Pengaduan Masyarakat DPR RI sebelum dan
sesudah dilakukan validasi.
61
UIN Syarif Hidayatullah Jakarta
Kerangka Berpikir
Gambar 3.1 Kerangka Berpikir
62
BAB 4
ANALISIS SISTEM
Analisis System-as-is (SPM Online DPR RI yang sedang berjalan)
Analisis Sistem Pengaduan Masyarakat (SPM) Online DPR RI yang sedang
berjalan saat ini (system-as-is) dilakukan untuk mendapatkan goal dan kebutuhan
system-as-is. Analisis tersebut dilakukan terhadap modul atau fungsi-fungsi yang
terdapat pada SPM Online DPR RI saat ini (www.pengaduan.dpr.go.id) dengan
menggunakan teknik pengumpulan data yang ada pada tahap requirements
elicitation, yaitu studi latar belakang, observasi, serta wawancara. Wawancara
dilakukan kepada Kasubbag Analisis Pengaduan Masyarakat II (Bapak Yadin).
4.1.1. Analisis Dokumen (Studi Latar Belakang)
Dokumen yang penulis analisis adalah SOP (Standar Operasional
Prosedur) yang ada pada Bagian Pengaduan Masyarakat Sekretariat Jenderal
DPR RI dalam menangani atau mengelola pengaduan masyarakat yang
masuk melalui SPM Online DPR RI. Bagian Pengaduan Masyarakat Setjen
DPR RI memiliki beberapa SOP yang dapat dijadikan sebagai pedoman
dalam mengelola atau mengelola pengaduan masyarakat yang masuk. Akan
tetapi, penulis hanya melakukan analisis terhadap SOP yang memiliki
keterkaitan dengan SPM Online DPR RI, yaitu:
1. SOP Penerimaan Surat Masuk Pengaduan Masyarakat
2. SOP Penanganan Surat Pengaduan Msyarakat Melalui Website.
3. SOP Penanganan Surat Tembusan Pengaduan Masyarakat Kepada Alat
Kelengkapan Dewan (AKD).
4. SOP Penanganan Surat Pengaduan Masyarakat yang Ditujukan Kepada
Komisi dan Badan.
5. SOP Penanganan Surat Pengaduan Masyarakat yang Ditujukan Kepada
Pimpinan DPR RI.
63
UIN Syarif Hidayatullah Jakarta
Berdasarkan beberapa SOP di atas, dapat diketahui peran dari masing-
masing pengguna dalam SPM Online DPR RI saat ini yaitu:
1. Kepala Bagian Pengaduan Masyarakat
Melakukan koreksi materi dan penyempurnaan redaksi hasil
analisis permasalahan pengaduan masyarakat dan
menyampaikannya kepada Kepala Biro Hukum dan Pengaduan
Masyarakat.
2. Kepala Subbagian Analisis Pengaduan Masyarakat II dan II
Mengoreksi materi dan penyempurnaan redaksi hasil analisis
permasalahan Pengaduan Masyarakat melalui website.
3. Analis
Menganalisis permasalahan pengaduan, memberikan saran untuk
diteruskan kepada Komisi/Badan sesuai bidang permasalahan, dan
memasukkan hasil analisis tersebut ke dalam database SPM
Online DPR RI.
4. Pengadministrasi Umum
Melakukan pengisian form pengaduan dalam database SPM
Online DPR RI.
5. Kepala Bagian Sekretariat AKD
Menerima pengaduan masyarakat melalui SPM Online DPR RI
beserta hasil analisis dari Bagian Pengaduan Masyarakat dan
meneruskannya kepada Pimpinan AKD.
6. Masyarakat
Melakukan atau mengisi pengaduan masyarakat.
4.1.2. Analisis Hasil Observasi
Pada subbab ini, dijabarkan mengenai hasil observasi yang telah
penulis lakukan pada tanggal 9 Juni 2019. Observasi yang dilakukan meliputi
analisis mengenai fungsi-fungsi apa saja yang terdapat pada Sistem
Pengaduan Masyarakat (SPM) Online DPR RI saat ini
(www.pengaduan.dpr.go.id). Observasi ini dilakukan setelah penulis
melakukan analisis dokumen yang memiliki keterkaitan dengan sistem
64
UIN Syarif Hidayatullah Jakarta
tersebut. Berdasarkan observasi langsung pada system-as-is, dapat diketahui
beberapa modul yang terdapat di dalam sistem, yaitu:
1. Modul Sistem Informasi Aspirasi dan Pengaduan Masyarakat
Modul yang diperuntukan bagi seluruh masyarakat yang ingin
mengirimkan pengaduannya secara online dan mendapatkan informasi
terkait penyaluran aspirasi dan pengaduan masyarakat. Masyarakat dapat
mengakses ke SPM Online DPR RI yaitu dengan mengunjungi website
www.pengaduan.dpr.go.id. Modul ini dapat diakses tanpa melalui proses
login terlebih dahulu, sehingga setiap pengguna atau masyarakat dapat
Gambar 4.1 Contoh tampilan system-as-is
65
UIN Syarif Hidayatullah Jakarta
mengaksesnya dengan mudah. Berdasarkan observasi yang telah
dilakukan penulis, dalam Modul Sistem Informasi Aspirasi dan
Pengaduan Masyarakat terdapat menu yang ada pada sidebar website dan
menu yang terdapat pada header website.
a. Menu yang terdapat pada header website
1. Menu Home
Menu yang secara otomatis muncul ketika pertama kali
mengunjungi website SPM Online DPR RI. Dalam menu ini,
terdapat informasi mengenai definisi dari aspirasi dan pengaduan,
serta berisi informasi mengenai rujukan atau dasar aturan yang
digunakan DPR RI dalam menampung aspirasi dan pengaduan
masyarakat. Selain itu juga terdapat video petunjuk cara
pengiriman pengaduan dan aspirasi yang dapat dilakukan oleh
masyarakat.
2. Menu Bantuan
Menu yang berfungsi untuk menampilkan informasi
bagaimana cara menyampaikan pengaduan ke DPR. Dalam menu
ini dijelaskan mengenai adanya 3 cara yang dapat dilakukan
masyarakat untuk menyampaikan aduannya, yaitu secara online,
melalui surat, dan dengan datang langsung ke Bagian Hubungan
Masyarakat Sekretariat Jenderal DPR RI.
3. Menu Kontak
Menu yang berfungsi untuk menampilkan informasi
mengenai 2 kontak yang dapat digunakan oleh masyarakat yang
ingin menyampaikan pengaduan. Kontak yang pertama adalah
Bagian Pengaduan Masyarakat apabila masyarakat ingin
menyampaikan aduannya melalui surat, dan yang kedua adalah
Bagian Hubungan Masyarakat apabila masyarakat ingin
menyampaikan aduannya dengan datang langsung.
4. Menu FAQ
66
UIN Syarif Hidayatullah Jakarta
Menu yang berfungsi untuk menampilkan informasi terkait
jawaban dari Frequently Asked Question (FAQ) atau pertanyaan
yang paling sering ditanyakan oleh pengunjung Sistem Pengaduan
Masyarakat Online DPR RI.
5. Menu Bagian Pengaduan Masyarakat
Menu yang berfungsi untuk menampilkan informasi terkait
Visi, Misi, Motto, Maklumat Pertanyaan dan Kontak dari Bagian
Pengaduan Masyarakat.
6. Menu Laporan
Menu yang berfungsi untuk menampilkan informasi terkait
Laporan Jumlah Pengaduan dan Aspirasi Masyarakat pada masa
persidangan I s/d V (16 Agustus 2017 – 15 Agustus 2018).
Masyarakat dapat mengunduh laporan tersebut secara gratis
dengan cara menekan pilihan download yang ada pada tampilan
website tersebut.
b. Menu yang terdapat pada sidebar website
1. Menu Kirim Pengaduan Secara Online
Merupakan menu yang berfungsi sebagai media bagi
masyarakat yang ingin menyampaikan pengaduannya secara
online. Menu ini berisi formulir pengaduan online, yang di
dalamnya terdapat beberapa field yang harus diisi oleh masyarakat
ketika ingin menyampaikan aduannya, seperti biodata diri, isi
aduan, bidang aduan, dsb.
2. Menu Kirim Pengaduan Melalui Surat
Menu yang berfungsi untuk menampilkan informasi
mengenai cara penyampaian pengaduan masyarakat melalui surat.
3. Menu Kirim Pengaduan Datang Langsung
Menu yang berfungsi untuk menampilkan informasi
mengenai cara penyampaian pengaduan masyarakat dengan cara
datang langsung atau delegasi masyarakat.
4. Menu SMS Aspirasi
67
UIN Syarif Hidayatullah Jakarta
Menu yang berfungsi untuk menampilkan informasi
mengenai nomor telepon yang dapat digunakan oleh masyarakat
untuk menyampaikan aspirasinya melalui SMS. Selain itu, di
dalam menu ini juga menampilkan pengertian dari aspirasi dan
pengaduan.
5. Menu Lihat Pengaduan
Menu yang berfungsi untuk menampilkan informasi terkait
status tindak lanjut dari pengaduan yang telah dikirim masyarakat.
Cara melihat status dari pengaduan tersebut dengan memasukkan
nomor pengaduan yang didapatkan ketika mengisi formulir
pengaduan online pada Menu Kirim Pengaduan Secara Online.
6. Menu Alur Proses Pengaduan
Merupakan menu yang berfungsi untuk menampilkan
gambar dari alur pengelolaan aspirasi dan pengaduan masyarakat
yang masuk melalui laman (website).
7. Menu Syarat Pengaduan
Menu yang berfungsi untuk menampilkan informasi
mengenai beberapa hal yang harus diperhatikan oleh masyarakat
yang ingin mengirimkan pengaduannya melalui Sistem
Pengaduan Masyarakat Online DPR RI.
8. Menu Alat Kelengkapan Dewan Sekretariat
Menu yang berfungsi untuk menampilkan informasi terkait
kontak dari masing-masing Alat Kelengkapan Dewan (AKD)
yang ada di DPR RI. Kontak tersebut berupa alamat email, nomor
telepon, dan juga fax.
9. Menu Alat Kelengkapan Dewan Ruang Lingkup
Menu yang berfungsi untuk menampilkan informasi terkait
kontak dari masing-masing Alat Kelengkapan Dewan (AKD)
yang ada di DPR RI. Kontak tersebut berupa alamat email, nomor
telepon, dan juga fax.
68
UIN Syarif Hidayatullah Jakarta
2. Modul Login
Modul ini adalah modul yang berfungsi untuk melakukan
authentication (otentikasi) terhadap administrator yang ingin masuk ke
dalam Back end System. Otentikasi dilakukan dengan cara memverikasi
nama pengguna dan password yang dimasukkan dengan daftar
administrator yang ada dalam database sistem.
Jika nama pengguna dan/atau password yang dimasukkan tidak sesuai
dengan daftar pengguna dan/atau password yang ada dalam database
sistem, maka otomatis akan diberikan alert (“Tidak ada hak akses ke
aplikasi; PENGADUAN, atau Login dan Password salah!”). Berikut ini
tampilan dari Back end SPM Online DPR RI:
Gambar 4.2 Alert Sistem Ketika Nama Pengguna dan Password
Tidak Terdaftar
69
UIN Syarif Hidayatullah Jakarta
3. Modul Pengelolaan Data Pengaduan
Modul ini hanya dapat diakses setelah berhasil melewati tahap
otentikasi yang ada pada Modul Login. Modul Pengelolaan Data
Pengaduan memiliki beberapa menu di dalamnya, diantaranya yaitu:
Menu Form Pengaduan via Surat, Menu Data Pengaduan, Menu Mesin
Cari Pengaduan, Menu Rekap Data, dan Menu Statistik Pengaduan.
a. Menu Form Pengaduan via Surat
Menu ini berfungsi untuk memasukkan pengaduan
masyarakat yang dikirim dalam bentuk surat tertulis kepada
Sekretariat Jenderal DPR RI ke dalam database SPM Online
Gambar 4.3 Back End SPM Online DPR RI saat ini (system-as-is)
70
UIN Syarif Hidayatullah Jakarta
DPR RI. Menu ini dapat diakses setelah admin menekan memu
form pengaduan via surat.
b. Menu Data Pengaduan
Menu Data Pengaduan memiliki fungsi untuk menampilkan
seluruh data pengaduan masyarakat yang masuk, dan dapat
melakukan filterisasi berdasarkan tahun, bulan, media
pengiriman pengaduan, dan peran. Data yang ditampilkan
berisikan nama pelapor, kode, tanggal surat, media pengiriman,
perihal pengaduan, bidang pengaduan, dan status pengaduan.
Menu ini dapat diakses ketika admin telah menakan menu data
pengaduan.
c. Menu Detail Data Pengaduan
Menu yang dapat diakses ketika pengguna
menekan/memilih salah satu dari daftar data pengaduan yang
ditampilkan pada menu data pengaduan. Pada menu detail data
pengaduan terdapat beberapa sub menu yang memiliki
fungsinya masing-masing, yaitu:
1. Lihat
Submenu yang berfungsi untuk menampilkan informasi
lebih detail mengenai pengaduan yang kita pilih, seperti data
pelapor, data surat, data analisis surat, tanggapan dari bagian
pengaduan masyarakat, alur dan status tindak lanjut dari
pengaduan tersebut.
2. Edit
Submenu yang berfungsi untuk mengedit informasi detail
mengenai pengaduan yang kita pilih, seperti data pelapor,
data surat, data analisis surat, tanggapan dari bagian
pengaduan masyarakat, alur dan status tindak lanjut dari
pengaduan tersebut.
3. Hapus
71
UIN Syarif Hidayatullah Jakarta
Submenu yang berfungsi untuk menghapus data pengaduan
masyarakat yang dipilih dari database SPM Online DPR RI.
4. Form
Submenu yang berfungsi untuk mengunduh form pengaduan
masyarakat yang dipilih dalam bentuk file .docx. Form
tersebut berisikan data pelapor, data surat, alur analisis, alur
tindak lanjut, surat untuk AKD, surat untuk pelapor, dan
surat untuk institusi. Semua data tersebut disajikan dalam
bentuk tabel yang terpisah.
5. Disposisi Tembusan
Submenu yang berfungsi untuk mengunduh lembar disposisi
tembusan pengaduan masyarakat yang dipilih dalam bentuk
file .docx. Lembar disposisi tersebut digunakan Kepala Biro
Hukum dan Pengaduan Masyarakat untuk dikirimkan
kepada Deputi Administrasi. Isi dari lembar disposisi
tersebut adalah data pelapor beserta uraian mengenai
permasalahan pengaduan masyarakat yang dikirimkan.
6. Disposisi AKD
Submenu yang berfungsi untuk mengunduh lembar analisis
surat AKD bagian pengaduan masyarakat yang dipilih dalam
bentuk file .docx. Lembar analisis tersebut digunakan oleh
Deputi Administrasi untuk dikirimkan kepada Komisi/AKD
terkait. Isi dari lembar analisis tersebut adalah data pelapor
beserta uraian mengenai permasalahan pengaduan
masyarakat yang dikirimkan.
7. Lembar Analisis
Submenu yang berfungsi untuk mengunduh lembar analisis
bagian pengaduan masyarakat yang dipilih dalam bentuk file
.docx. Lembar analisis tersebut digunakan oleh Deputi
Administrasi untuk dikirimkan kepada Ketua DPR RI. Isi
dari lembar disposisi tersebut adalah data pelapor beserta
72
UIN Syarif Hidayatullah Jakarta
uraian mengenai permasalahan pengaduan masyarakat yang
dikirimkan dan uraian pembahasan yang telah dilakukan
oleh bagian pengaduan masyarakat.
8. Surat Pelapor 1
Submenu yang berfungsi untuk mengunduh surat pelapor
yang dipilih dalam bentuk file .docx. Surat pelapor ini
diberikan oleh Kepala Biro Hukum dan Pengaduan
Masyrakat atas nama Deputi Administrasi dan Sekretaris
Jenderal kepada pelapor/pengadu. Isi dari surat pelapor ini
adalah tanggapan kepada pelapor terkait surat aduan yang
telah dikirimkan, dan juga berisi mengenai laporan sudah
sejauh mana proses tindak lanjut yang telah dilakukan
terhadap aduan tersebut.
d. Menu Mesin Cari Pengaduan
Menu ini berfungsi untuk melakukan pencarian terkait data
pengaduan masyarakat yang ada dalam database SPM Online
DPR RI. Pencarian dapat dilakukan dengan melakukan
filterisasi berdasarkan tahun pengaduan, nama pengadu, nomor
indeks pengaduan, dan nomor kode pengaduan.
e. Menu Rekap Data
Menu ini memiliki fungsi untuk menampilkan rekapitulasi
dan daftar surat, dan membagi surat tersebut ke dalam beberapa
kelompok surat, diantaranya adalah:
1. Daftar Aspirasi dan Pengaduan Masyarakat
2. Rekap Surat Masuk Per Bidang Pimpinan
3. Rekap Surat Masuk Per Tujuan Surat
4. Rekap Surat Masuk Per Bidang Masalah dan Provinsi
5. Rekap Surat yang Diteruskan Per AKD
6. Rekap Surat yang Diteruskan Per Bulan
7. Rekap Surat yang Telah Ditanggapi Per Tahun
8. Daftar Surat Masuk Per Bidang Pimpinan
73
UIN Syarif Hidayatullah Jakarta
9. Daftar Surat Masuk Per Tujuan Surat
10. Daftar Surat Masuk yang di-File
11. Rekap Surat Masuk yang di-File Per Bidang Pimpinan
12. Daftar Surat Gabungan Per AKD
13. Daftar Surat Gabungan Per Bidang Permasalahan
14. Rekap Tindak Lanjut Per Alat Kelengkapan Dewan
15. Daftar Tindak Lanjut Per Alat Kelengkapan Dewan
f. Menu Statistik Pengaduan
Menu Statistik Pengaduan memiliki fungsi untuk
menampilkan statistik dari pengaduan masyarakat. Statistik
yang ditampilkan dibagi menjadi beberapa tampilan, yaitu:
1. Statistik Surat Masuk Per Bidang Pimpinan
2. Statistik Surat Masuk Per Bidang Permasalahan
3. Statistik Surat Masuk Per Provinsi
4. Statistik Surat Masuk Per Media Pengaduan
5. Statistik Analisis Per Bidang Pimpinan
6. Statistik Tindak Lanjut Per Bidang Permasalahan
7. Statistik Tindak Lanjut Perbidang Permasalahan
8. Statistik Tindak Lanjut Per Provinsi
9. Statistik Tindak Lanjut Per Tujuan
Selain dapat membagi statistik pengaduan yang ingin
ditampilkan ke dalam beberapa bagian, di setiap bagian tersebut
juga dapat dilakukan filterisasi terkait data grafik yang ingin
ditampilkan. Sebagai contoh dalam statistik surat masuk per
media pengaduan, dapat dilakukan filterisasi berdasarkan
medianya, waktu mulai, dan waktu akhir dari data pengaduan
masyarakat yang ingin ditampilkan ke dalam bentuk grafik.
4. Modul Pengelolaan Menu Statis
Modul ini berisikan beberapa menu yang berfungsi untuk mengubah
halaman-halaman website yang bersifat statis. Seluruh menu yang bersifat
74
UIN Syarif Hidayatullah Jakarta
statis yang dimaksud tersebut berada pada frontend SPM Online DPR RI.
Menu-menu yang ada dalam Modul Pengelolaan Menu Statis yaitu:
a. Halaman Depan
b. Halaman Bantuan
c. Halaman Kontak
d. Halaman FAQ
e. Halaman Pengaduan Melalui Surat
f. Halaman Delegasi Masyarakat (Datang Langsung
g. Halaman Alur Proses Pengaduan
h. Halaman Syarat Pengaduan
i. Halaman Kontak Sekretariat AKD
j. Halaman Ruang Lingkup AKD
k. Ganti Password
5. Modul Data Daerah Pemilihan
Merupakan Modul untuk menampilkan daftar daerah pemilihan dari
DPR RI beserta area dari masing-masing daerah pemilihan tersebut.
4.1.3. Analisis Hasil Wawancara
Pada Subbab ini, penulis melakukan analisis terhadap hasil
wawancara yang telah dilakukan penulis dengan Bapak Yadin (Kepala
Subbagian Analisis Pengaduan Masyarakat II) pada Hari Selasa, 21 Mei
2019, sebagaimana terlampir dalam Lampiran I. Analisis hasil wawancara
digunakan untuk mengidentifikasi goal (sasaran) dan requirements
(kebutuhan) dari Sistem Pengaduan Masyarakat Online DPR RI yang berjalan
saat ini.
1. Masyarakat dapat mengirimkan pengaduan masyarakat
Kebutuhan ini teridentifikasi berdasarkan jawaban dari pertanyaan
yang penulis ajukan yaitu “Apa saja platform atau tools yang bisa diakses
oleh masyarakat kalau mau melakukan pengaduan? Ada apa aja media
yang bisa digunakan pak?” Dan berikut adalah jawaban atau pernyataan
responden:
75
UIN Syarif Hidayatullah Jakarta
“Jadi sesuai dengan perkembangan yang ada sekarang
ini, itu ada 3 jenis media yang disediakan oleh DPR RI
khususnya Setjen DPR RI untuk melayani pengaduan
masyarakat, ….. Kemudian yang kedua, melalui
website atau yang sering kita sebut email yaitu
www.pengaduan.dpr.go.id”
Berdasarkan pernyataan responden di atas, terlihat bahwa
masyarakat dapat mengirimkan pengaduannya melalui SPM Online DPR
RI (www.pengaduan.dpr.go.id).
2. Analis dapat menuliskan analisis dari surat pengaduan yang masuk.
Sistem Pengaduan Masyarakat Online DPR RI juga diharuskan
memenuhi kebutuhan terkait Analis yang dapat menuliskan hasil
analisisnya terhadap surat pengaduan yang masuk dari masyarakat.
Kebutuhan ini penulis dapatkan dari pernyataan Bapak Yadin (responden)
yaitu:
“Untuk bagian analisis berarti melakukan analisis
terkait pengaduan yang masuk”
Pernyataan Bapak Yadin tersebut merupakan jawaban dari pertanyaan
yang penulis ajukan, yaitu “Apakah ada pembagian hak akses sistem? Lalu,
siapa saja yang bisa terlibat dalam sistem?”.
3. Pengadministrasi Umum dapat mendata surat yang masuk beserta surat
yang telah diteruskan ke Komisi.
Melalui pertanyaan “Apakah ada pembagian hak akses sistem? Lalu,
siapa saja yang bisa terlibat dalam sistem”. Maka penulis mendapatkan
kebutuhan sistem ‘Administrasi Umum dapat mendata surat yang masuk
beserta surat yang telah diteruskan ke Komisi’. Kebutuhan tersebut
diidentifikasi dari pernyataan responden bahwa:
“Administrasi Umum itu yang melakukan input data
kemudian mencatat apakah surat ini sudah disampaikan
dengan Komisi sesuai bidangnya atau belum”
76
UIN Syarif Hidayatullah Jakarta
Berdasarkan pernyataan di atas, dapat diketahui bahwa SPM Online
DPR RI digunakan oleh Pengadministrasi Umum untuk melakuan
pendataan terkait surat yang masuk dan mendata surat-surat yang telah
atau belum diteruskan ke Komisi.
4. Sekretariat AKD dapat mengelola pengaduan masyarakat yang masuk.
Kebutuhan sistem yang berhasil diindentifikasi selanjutnya yaitu
‘Sekretariat AKD diberikan akses untuk dapat mengelola pengaduan
masyarakat yang masuk’. Kebutuhan sistem tersebut penulis dapatkan
dari pernyataan responden, yaitu:
“Kalau masyarakat itu semua orang bisa masuk, tetapi
untuk pengolahannya dari bagian pengaduan
masyarakat, dan satu lagi adalah bagian sekretariat
AKD.”
Pernyataan di atas merupakan jawaban dari pertanyaan yang penulis
berikan pada saat wawancara, yaitu “Jadi yang bisa akses kepada
sistemnya itu dari pengaduan masyarakat pak?”.
4.1.4. Pemodelan Goal Model System-as-is
Berdasarkan analisis-analisis yang ada pada subbab sebelum-
sebelumnya, penulis akan memodelkan kumpulan goal dan kebutuhan yang
telah teridentifikasi menjadi sebuah goal model yang utuh dengan
menggunakan metode KAOS. Goal model yang dibangun adalah goal model
yang digunakan untuk menggambarkan kondisi Sistem Pengaduan
Masyarakat (SPM) Online DPR RI saat ini (system-as-is). Setelah selesai
dibangun, goal model akan divalidasi oleh responden yaitu Bapak Yadin
(Kasubbag Analisis Pengaduan Masyarakat II) selaku ahli dalam SPM Online
DPR RI ini. Selain itu, goal model yang akan dibangun ini juga digunakan
pada Bab selanjutnya untuk dijadikan acuan untuk menganalisis kesenjangan
yang terjadi antara goal yang sebenarnya ingin dicapai dengan realisasi yang
ada saat ini.
1. Mendukung kewajiban dan tugas DPR dalam menerima,
menampung, dan menindaklanjuti pengaduan masyarakat
77
UIN Syarif Hidayatullah Jakarta
Pada analisis goal model ini, hal pertama yang dilakukan adalah
menentukan sasaran utama atau strategic goal dari adanya SPM Online DPR
RI. Melalui proses wawancara yang telah dilakukan, penulis
menginterpretasikan bahwa sasaran utama dari SPM Online DPR RI adalah
Mendukung kewajiban dan tugas DPR dalam menerima, menampung, dan
menindaklanjuti pengaduan masyarakat. Sasaran ini diinterpretasikan dari
pernyataan responden sebagai berikut:
“Pada intinya yang paling utama adalah tugas, wewenang, dan
kewajiban dewan, sebagaimana yang di maksud di UU MD3 Pasal
74 bahwa anggota DPR mempunyai kewajiban dan tugas menerima,
menampung dan menindaklanjuti aspirasi dan pengaduan
masyarakat”
Setelah mendapatkan sasaran utama sistem (strategic goal), penulis
menyempurnakannya dengan mengidentifikasi goal yang berada di bawah
strategic goal tersebut. Identifikasi dilakukan dengan menggunakan Metode
KAOS, yaitu melalui pertanyaan ‘HOW’ atau “Bagaimana strategic goal dari
SPM Online DPR RI tersebut dapat tercapai?”. Maka, berdasarkan
pertanyaan tersebut penulis mendapatkan goal yang berada di bawahnya yaitu
“Mengelola data pengaduan masyarakat yang masuk dan tindak lanjutnya”.
Sebagaimana terlihat pada Gambar 4.4, jajaran genjang berfungsi
untuk merepresentasikan sebuah goal dan lingkaran kuning berfungsi untuk
merepresentasikan bahwa sasaran utama sistem (strategic goal) hanya bisa
Gambar 4.4 Strategic Goal dan Goal
Turunannya
78
UIN Syarif Hidayatullah Jakarta
terpenuhi apabila goal yang berada di bawah lingkaran kuning tersebut
terpenuhi.
2. SPM Online DPR RI dapat mengelola data pengaduan masyarakat
yang masuk dan tindak lanjutnya
Goal turunan dari strategic goal telah ditemukan. Selanjutnya
memulai dengan analisis terhadap goal tersebut. Apa yang dimaksud dengan
“Dapat mengelola data pengaduan masyarakat yang masuk dan tindak
lanjutnya” dalam konteks masalah SPM Online DPR RI? ini berarti SPM
Online harus mampu mengelola seluruh data pengaduan dan mengelola
seluruh informasi mengenai bagaimana tindak lanjut dari pengaduan tersebut.
Sehingga, dapat diketahui 2 goal di bawahnya, yaitu: “Mengelola data
pengaduan masyarakat yang masuk” serta “mengelola data dan informasi
tindak lanjut pengaduan masyarakat”.
3. Mengelola data pengaduan masyarakat yang masuk
Pertanyaan selanjutnya, bagaimana caranya untuk memenuhi goal
“Mengelola data pengaduan masyarakat yang masuk” ? yaitu dengan
memastikan bahwa “data pengaduan masyarakat dapat dihapus”, sistem
dapat “menampilkan informasi cara pengiriman pengaduan masyarakat”,
sistem dapat “menampung pengaduan masyarakat”, dan “kerahasiaan data
pengaduan masyarakat terjaga”, serta sistem dapat memastikan bahwa
“Data pengaduan masyarakat dapat ditampilkan”. Berdasarkan penjelasan
di atas, sehingga dapat dibuat diagram yang menggambarkan hubungan
Gambar 4.5 Mengelola Data Pengaduan Masyarakat yang Masuk dan
Tindaklanjutnya
79
UIN Syarif Hidayatullah Jakarta
antara goal “Mengelola data pengaduan masyarakat yang masuk” dengan
goal yang memiliki tingkatan lebih rendah, Seperti terlihat di bawah ini:
Berdasarkan Gambar 4.6, dapat diketahui bahwa untuk memenuhi
goal dari “Mengelola data pengaduan masyarakat yang masuk”, maka 5
(lima) goal yang berada di bawahnya juga harus terpenuhi terlebih dahulu.
Pertanyaan berikutnya, apa saja kriteria atau apa saja yang harus
dilakukan oleh sistem dan lingkungan sistem untuk dapat memenuhi 5
goal tersebut?. Pertanyaan ini digunakan untuk masuk ke dalam aktivitas
goal refinement atau aktivitas untuk mendapatkan requirements
(kebutuhan) sistem berdasarkan setiap goal yang ada.
Goal pertama yang dianalisis adalah goal “Data pengaduan
masyarakat dapat dihapus”. Sehingga, pertanyaan yang digunakan untuk
mendapatkan kebutuhan sistem dari goal tersebut adalah “apa saja yang
harus dilakukan sistem dan lingkungan sistem untuk dapat memastikan
bahwa data pengaduan masyarakat dapat dihapus?”. Maka, didapatkan
kebutuhan “Tersedia fitur hapus data pengaduan masyarakat”. Kebutuhan
tersebut teridentifikasi dari hasil observasi yang telah dilakukan penulis,
yaitu terdapat fitur hapus pada Menu Detail Data Pengaduan SPM Online
DPR RI saat ini. Berikut diagram dari kebutuhan sistem berdasarkan goal
“Data pengaduan masyarakat dapat dihapus”:
Gambar 4.6 Mengelola Data Pengaduan yang Masuk
80
UIN Syarif Hidayatullah Jakarta
Dapat dilihat pada Gambar 4.7, terdapat lingkaran kuning yang
berfungsi untuk menjelaskan adanya hubungan antara goal “Data
pengaduan masyarakat dapat dihapus” dengan kebutuhan sistem
“Tersedia fitur hapus data pengaduan masyarakat”. Hubungan tersebut
mengartikan bahwa sebuah goal hanya bisa terpenuhi apabila kebutuhan
sistem yang terhubung dengan lingkaran kuning tersebut telah terpenuhi.
Selain itu, pada Gambar 4.7 juga terdapat lingkaran merah, yang berguna
untuk menjelaskan responsibility dari kebutuhan sistem “Tersedia fitur
hapus data pengaduan masyarakat” kepada agen “Sistem”. Kebutuhan
sistem direpresentasikan dalam bentuk jajaran genjang dengan garis dan
tulisan tebal (bold). Sedangkan agen direpresentasikan ke dalam bentuk
persegi dengan 6 (enam) sudut.
Selanjutnya, sesuai dengan penggunaan metode KAOS yaitu
mengajukan pertanyaan WHAT, “ Apa yang harus dilakukan atau
disediakan oleh sistem agar dapat ‘menampilkan informasi cara
pengiriman pengaduan masyarakat’?” itu berarti sistem harus
menyediakan “tampilan informasi cara pengiriman pengaduan” dan
sistem harus menyediakan “menu sunting informasi cara pengiriman
pengaduan”. Dua kebutuhan sistem tersebut teridentifikasi berdasarkan
Gambar 4.7 Data Pengaduan Masyarakat Dapat Dihapus
81
UIN Syarif Hidayatullah Jakarta
hasil observasi yang telah dilakukan pada SPM Online saat ini, yaitu
terdapatnya Modul Pengelolaan Menu Statis.
Proses goal refinement berikutnya yaitu mencari, menganalisis, dan
mengidentifikasi kebutuhan sistem dari goal “Menampung pengaduan
Masyarakat”. Identifikasi kebutuhan sistem dilakukan dengan cara
mencari jawaban dari pertanyaan “Bagaimana cara sistem agar dapat
menampung pengaduan masyarakat?”, maka jawaban yang paling tepat
adalah sistem harus menyediakan form input pengaduan melalui surat, dan
form pengaduan online. Jawaban tersebut didasari hasil observasi
terhadap system-as-is, yaitu ditemukannya menu kirim pengaduan secara
online, dan menu form pengaduan via surat. Selain itu, jawaban tersebut
juga didukung dari hasil analisis dokumen yang menjelaskan mengenai
adanya salah satu tugas dari Pengadministrasi Umum Bagian Pengaduan
Masyarakat, yaitu melakukan pengisian form pengaduan dalam database
SPM Online DPR RI.
Gambar 4.8 Menampilkan Informasi Cara Pengiriman Pengaduan Masyarakat
82
UIN Syarif Hidayatullah Jakarta
Selanjutnya, sesuai dengan penggunaan metode KAOS, maka
pertanyaan “HOW” kembali diajukan untuk mendapatkan kebutuhan
sistem dari goal “Kerahasiaan data pengaduan masyarakat terjaga”.
Sehingga, pertanyaan yang diajukan adalah “Bagaimana cara sistem dapat
memastikan bahwa kerahasiaan data pengaduan masyarakat dapat
terjaga?” yaitu dengan adanya proses autentikasi setiap seseorang ingin
mengakses sistem. Proses otentikasi ini benar merupakan kebutuhan
sistem, karena sesuai dengan apa yang didapatkan pada saat observasi
system-as-is yaitu tersedianya modul login. Hal ini juga sesuai dengan
pernyataan Bapak Yadin saat diwawancarai, yaitu:
“Jadi kita melibatkan beberapa pegawai di beberapa bagian. Pertama
di bagian ini, yaitu tingkat eselon 3. Pejabat dan staff di bagian pengaduan
masyarakat ada dua jenis, satu sebagai analis pengaduan masyarakat, dan
yang kedua sebagai administrasi umum. Administrasi umum itu yang
melakukan input data kemudian mencatat apakah surat ini sudah
disampaikan dengan Komisi sesuai bidangnya atau belum. Untuk yang
bagian analisis berarti melakukan analisis terkait pengaduan yang masuk.“
Gambar 4.9 Menampung Pengaduan Masyarakat
83
UIN Syarif Hidayatullah Jakarta
Pernyataan tersebut merupakan jawaban dari pertanyaan yang
penulis ajukan “Siapa saja yang bisa terlibat dalam sistem?”. Berdasarkan
pernyataan di atas, dapat diketahui bahwa memang benar dalam system-
as-is terdapat pembagian hak akses sistem atau proses otentikasi.
Tahap yang terakhir, yaitu analisis terhadap goal “data pengaduan
masyarakat ditampilkan” dengan mengidentifikasi apa saja yang harus
dilakukan oleh sistem untuk dapat memenuhi goal tersebut. Berdasarkan
hasil observasi terhadap system-as-is yang telah dijelaskan pada subbab
sebelumnya, bahwa system-as-is memiliki menu mesin cari pengaduan,
menu statistik pengaduan, menu data pengaduan, menu rekap data, dan
menu detail data pengaduan. Sehingga, dapat diketahui beberapa
kebutuhan sistem yang harus dipenuhi agar goal tersebut dapat dicapai.
Seperti terlihat pada gambar goal diagram di bawah ini:
Gambar 4.10 Kerahasiaan Data Pengaduan Masyarakat Terjaga
84
UIN Syarif Hidayatullah Jakarta
Sebagaimana yang terlihat pada Gambar 4.11, untuk mencapai goal
“data pengaduan masyarakat ditampilkan”, sistem diharuskan untuk
memenuhi 3 (tiga) kebutuhan tersebut.
4. Mengelola informasi tindak lanjut pengaduan masyarakat
Agar dapat memenuhi goal “mengelola data dan informasi tindak
lanjut pengaduan masyarakat”, maka Hasil penulisan pengaduan masyarakat
dapat dituliskan, dan sistem dapat menampilkan informasi tindak lanjut
pengaduan masyarakat. Sebagaimana yang terlihat pada goal diagram di
bawah ini:
Goal diagram di atas menjelaskan hubungan antara goal “mengelola
data dan informasi tindak lanjut pengaduan masyarakat” dengan goal di
bawahnya. Goal “Hasil analisis pengaduan masyarakat dapat dituliskan”
didapatkan dari hasil analisis dokumen, yakni ditemukannya tugas dari Analis
Bagian Pengaduan Masyarakat untuk menganalisis permasalahan pengaduan
dan tugas dari Kasubbag Analisis Pengaduan Masyarakat II untuk
Gambar 4.11 Data Pengaduan Masyarakat Ditampilkan
Gambar 4.12 Mengelola Data dan Informasi Tindaklanjut
Pengaduan Masyarakat
85
UIN Syarif Hidayatullah Jakarta
mengoreksi materi dan penyempurnaan redaksi hasil analisis permasalahan
pengaduan masyarakat melalu website. Selanjutnya, bagaimana cara sistem
dapat memenuhi goal tersebut? yaitu dengan menyediakan menu edit data
pengaduan. Hal ini didasari dengan ditemukannya submenu edit data
pengaduan yang terdapat pada system-as-is. Karena pengadaan menu tersebut
telah menjadi tanggungjawab agen tunggal yaitu sistem, maka tidak disebut
sebagai goal, melainkan disebut sebagai kebutuhan sistem. Sehingga goal
diagram yang dihasilkan adalah:
Selanjutnya, untuk dapat memenuhi goal “Menampilkan informasi
tindak lanjut pengaduan masyarakat” sistem harus menyediakan tampilan
informasi tindak lanjut pengaduan masyarakat, sebagaimana yang terdapat
pada system-as-is, yaitu adanya menu lihat pengaduan. Untuk menampilkan
informasi tindak lanjut tersebut juga dibutuhkan nomor tiket yang
dimasukkan sendiri oleh masyarakat ke dalam sistem, hal itu sesuai dengan
cara penggunaan menu lihat pengaduan pada system-as-is.
Selain itu, untuk dapat menampilkan informasi tindak lanjut pengaduan
masyarakat, maka tindak lanjut tersebut harus dapat dituliskan. Selanjutnya,
bagaimana cara agar tindak lanjut tersebut dapat dituliskan? Pertama, sistem
harus menyediakan form input hasil tindak lanjut sebagaimana ditemukannya
submenu edit data pengaduan pada system-as-is. Kedua, Sekretariat AKD
Gambar 4.13 Hasil Analisis Pengaduan
Masyarakat Dapat Dituliskan
86
UIN Syarif Hidayatullah Jakarta
atau Pengadministrasi Umum Bagian Pengaduan Masyarakat harus
menuliskan hasil tindak lanjut dari pengaduan masyarakat yang masuk.
Goal diagram yang terdapat pada Gambar 4.14 menjelaskan bahwa
untuk mencapai goal “menampilkan informasi tindak lanjut pengaduan
masyarakat”, maka goal “informasi tindak lanjut pengaduan dapat
dituliskan” harus dipenuhi terlebih dahulu. Lalu bagaimana cara agar dapat
memenuhi goal tersebut? yaitu ketika sistem mampu meneyediakan form
input hasil tindak lanjut, dan Sekretariat AKD atau Pengadministrasi Umum
telah menuliskan hasil tindak lanjut dari pengaduan masyarakat. Selanjutnya,
untuk mencapai goal “menampilkan informasi tindak lanjut pengaduan
masyarakat”, masyarakat diharuskan memasukkan nomor tiket
pengaduannya, dan sistem harus menyediakan tampilan informasi tindak
lanjut pengaduan masyarakat, serta menyediakan form input nomor tiket
pengaduan.
Tahap pembuatan goal model system-as-is yang terakhir adalah
dengan membuat sebuah goal model utuh dari system-as-is. Pembuatan goal
model ini merupakan penggabungan dari seluruh goal diagram yang telah
dijelaskan sebelumnya. Di bawah ini merupakan goal model keseluruhan dari
SPM Online DPR RI saat ini:
Gambar 4.14 Menampilkan Informasi Tindaklanjut Pengaduan Masyarakat
87
UIN Syarif Hidayatullah Jakarta
Gambar 4.15 Goal Model System-as-is
88
UIN Syarif Hidayatullah Jakarta
4.1.5. Pemodelan Responsibility Model System-as-is
Pemodelan selanjutnya, yaitu pemodelan tanggungjawab atau
responsibility model dari setiap agen tunggal, yaitu sistem itu sendiri, ataupun
agen yang berada di lingkungan sistem.
1. Masyarakat
Masyarakat merupakan salah satu agen yang berada di
lingkungan sistem. Sesuai dengan penggunaan Metode KAOS,
untuk pembuatan responsibility model didasarkan pada goal
model yang telah dibuat sebelumnya. Sehingga responsibility
model untuk masyarakat adalah:
2. Sekretariat AKD
Berdasarkan hasil analisis terhadap goal model sebelumnya,
responsibility model untuk agen Sekretariat AKD adalah:
3. Pengadministrasi Umum
Sesuai dengan goal model yang telah dibuat sebelumnya,
Pengadministrasi Umum hanya memiliki satu tanggungjawab
dalam memenuhi goal dari SPM Online DPR RI saat ini, yaitu:
Gambar 4.16 Responsibility Model untuk Masyarakat
Gambar 4.17 Responsibility Model untuk Sekretariat AKD
Gambar 4.18 Responsibility Model untuk Pengadministrasi Umum
89
UIN Syarif Hidayatullah Jakarta
4. Sistem
Responsibility model yang terakhir adalah untuk sistem.
Sebagaimana yang telah dijelaskan pada subbab sebelumnya,
Sistem memiliki beberapa tanggungjawab yang harus dipenuhi
untuk mewujudkan goal dari SPM Online DPR RI saat ini.
Gambar 4.19 Responsibility Model untuk Sistem
90
UIN Syarif Hidayatullah Jakarta
Penentuan Dokumen Regulasi (Metode SAR)
Seperti yang telah penulis jelaskan pada Bab-bab sebelumnya, setiap aplikasi
kepemerintahan itu memiliki dokumen acuan sebagai dasar atau alasan mengapa
aplikasi tersebut perlu dibuat dan dikembangkan. Landasan tersebut berupa
dokumen regulasi/peraturan perundang-undangan. Sehingga, setiap pengembangan
sebuah sistem atau aplikasi perlu ditinjau lebih dalam mengenai dokumen regulasi
yang terkait atau relevan dengan sistem tersebut. Dalam hal ini metode yang
digunakan adalah metode SAR (Select Appropriate Regulations). Berikut langkah-
langkah dan penjelasan terkait penggunaan metode SAR dalam SPM Online DPR
RI:
Langkah/
Prosedur
Hasil
SAR-P1: Penulis menentukan “Sistem Pengaduan Masyarakat (SPM)
Online DPR RI” sebagai sistem yang akan dianalisis dan
disusun goal model-nya.
SAR-P2: Mencari peraturan perundang-undangan yang memiliki
keterkaitan dengan SPM Online DPR RI dengan level paling
terendah terlebih dahulu (berdasarkan hierarki perundang-
undangan). Terpilih “Peraturan Sekretaris Jenderal DPR RI
No. 7 Tahun 2018 tentang Perubahan Kedua atas Peraturan
Sekretaris Jenderal DPR RI No. 6 Tahun 2015 tentang
Organisasi dan Tata Kerja Sekretariat Jenderal dan Badan
Keahlian DPR RI”. Peraturan tersebut dipilih karena
merupakan peraturan yang mengatur mengenai struktur
organisasi, beserta tugas dan fungsi dari Setjen dan BK DPR
RI (Sekretariat Jenderal dan Badan Keahlian DPR RI, 2019).
Dalam peraturan tersebut terdapat struktur, tugas dan fungsi
Bagian Pengaduan Masyarakat, yang merupakan owner dari
SPM Online DPR RI.
SAR-P3: Menentukan peraturan perundang-undangan yang berada di
level atasnya, dengan cara melihat isi peraturan perundang-
91
UIN Syarif Hidayatullah Jakarta
undangan yang telah ditentukan, dengan melihat/merujuk
pada bagian “mengingat”.
SAR-P4: Analisis lebih mendalam terhadap semua kandidat Peraturan
Perundang-undangan yang ada pada bagian “mengingat”,
dan tentukan hierarki dari peraturan Perundang-undangan
tersebut yang menjadi landasan bagi sistem tersebut.
Tabel 4.1 Hierarki Peraturan Perundang-undangan Terkait
SPM Online DPR RI
Hierarki Peraturan Perundang-
undangan
UU/Peraturan Pemerintah
Pengganti Undang-Undang
UU No. 2 Tahun 2018
Tentang Perubahan Kedua
atas UU No. 17 Tahun
2014 Tentang MPR, DPR,
DPD, dan DPRD
Peraturan Presiden Peraturan Presiden No. 27
Tahun 2015 tentang
Sekretariat Jenderal dan
92
UIN Syarif Hidayatullah Jakarta
Badan Keahlian Dewan
DPR RI
Peraturan Sekretaris Jenderal Peraturan Sekretaris
Jenderal DPR RI No. 7
Tahun 2018 tentang
Perubahan Kedua atas
Peraturan Sekretaris
Jenderal DPR RI No. 6
Tahun 2015 tentang
Organisasi dan Tata Kerja
Sekretariat Jenderal dan
Badan Keahlian DPR RI
Mengektraksi Dokumen Regulasi (Metode R2G)
Setelah menentukan dokumen regulasi yang memiliki keterkaitan dengan
SPM Online DPR RI menggunakan metode SAR, maka sekarang masuk ke dalam
penggunaan metode R2G (Regulations to Goal Model) untuk mendapatkan
kandidat goal SPM Online DPR RI. Sesuai dengan metode R2G, maka terdapat
prosedur umum dan prosedur ekstraksi, berikut merupakan langkah-langkahnya:
4.3.1. Prosedur Umum
Dalam prosedur umum ini, penulis menentukan goal/pokok utama
dari SPM Online DPR RI dengan berdasarkan dokumen regulasi yang telah
diperoleh menggunakan metode SAR pada Subbab sebelumnya.
93
UIN Syarif Hidayatullah Jakarta
R2G-UP1: Penulis menentukan aplikasi kepemerintahan yang akan dianalisis
dan dibangun goal model-nya. Dalam Hal ini, penulis memilih
“Sistem Pengaduan Masyarakat (SPM) Online DPR RI”
R2G-UP2: Penulis menentukan peraturan perundang-undangan sesuai
hierarkinya yang menjadi landasan bagi aplikasi tersebut:
Hierarki Peraturan Perundang-
undangan
UU/Peraturan Pemerintah
Pengganti Undang-Undang
UU No. 2 Tahun 2018
Tentang Perubahan Kedua
atas UU No. 17 Tahun 2014
Tentang MPR, DPR, DPD,
dan DPRD
Peraturan Presiden Peraturan Presiden No. 27
Tahun 2015 tentang
Sekretariat Jenderal dan
Badan Keahlian Dewan
DPR RI
Peraturan Sekretaris
Jenderal
Peraturan Sekretaris
Jenderal DPR RI No. 7
Tahun 2018 tentang
Perubahan Kedua atas
Peraturan Sekretaris
Jenderal DPR RI No. 6
Tahun 2015 tentang
Organisasi dan Tata Kerja
Sekretariat Jenderal dan
Badan Keahlian DPR RI
R2G-UP3: Penulis menentukan strategic goal dari sistem tersebut yaitu
“Mendukung Kewajiban DPR RI dalam menampung dan
menindaklanjuti pengaduan masyarakat”
94
UIN Syarif Hidayatullah Jakarta
4.3.2. Prosedur Ekstraksi
Melakukan ekstraksi peraturan perundang-undangan mulai level
tertinggi terlebih dahulu, yaitu UU No. 2 Tahun 2018 Tentang Perubahan
Kedua atas UU No. 17 Tahun 2014 Tentang MPR, DPR, DPD, dan DPRD.
R2G-EP1: Berdasarkan “goal” utama yang telah ditentukan pada
prosedur umum, penulis menentukan “kata kunci” yang
mempunyai kaitan erat dengannya, yaitu aduan, aspirasi,
tugas, kewajiban, dan tindak lanjut.
R2G-EP2: Tentukan kandidat-kandidat kalimat yang mengandung
“goal”, dengan cara:
EP4.1: Telusuri bab demi bab, pasal demi pasal, ayat demi
ayat sampai akhir dokumen (satu peraturan
perundang-undangan) yang mengandung “kata
kunci”.
EP4.2: Jika ditemukan “kata kunci” dalam suatu ayat/kali-
mat, ambil kalimat tersebut dengan struktur
Subyek+Predikat+Obyek+[Keterangan]. Masukkan
kalimat tersebut dalam suatu daftar/list kandidat goal.
Setelah melalui tahap-tahap tersebut, penulis membuat tabel kandidat
goal yang didasarkan pada 3 (tiga) dokumen regulasi yang berkaitan dengan
Sistem Pengaduan Masyarakat (SPM) Online DPR RI
(www.pengaduan.dpr.go.id).
Tabel 4.2 Kandidat Goal pada UU No. 2 Tahun 2018 tentang Perubahan Kedua
atas UU No. 17 Tahun 2014 tentang MPR, DPR, DPD, dan DPRD
No Kandidat “goal” Acuan Keterangan
1 Anggota DPR berkewajiban menam-
pung dan menindaklanjuti aspirasi dan
pengaduan masyarakat.
Pasal 81 Poin j Kewajiban
Anggota DPR
Dari UU No. 2 Tahun 2018 penulis mendapatkan 1 kandidat goal
yang dapat dijadikan goal dari SPM Online DPR RI. Kandidat tersebut
95
UIN Syarif Hidayatullah Jakarta
tercantum pada Pasal 81 Poin j, yang merupakan salah satu kewajiban dari
Anggota DPR RI.
Tabel 4.3 Peraturan Presiden No. 27 Tahun 2015 tentang Sekretariat Jenderal dan
Badan Keahlian DPR RI
No Kandidat “goal” Acuan Keterangan
1 Sekretariat Jenderal mempunyai tugas
mendukung kelancaran pelaksanaan
wewenang dan tugas DPR RI di bidang
administrasi dan persidangan.
Pasal 4 Tugas
Sekretariat
Jenderal
Berdasarkan Peraturan Presiden No. 27 Tahun 2015, penulis
menentukan 1 (satu) kandidat goal dari SPM Online DPR RI, yaitu tercantum
dalam Pasal 4.
Tabel 4.4 Peraturan Sekretaris Jenderal DPR RI No. 7 Tahun 2018 tentang Peru-
bahan Kedua atas Peraturan Sekretaris Jenderal DPR RI No. 6 Tahun 2015 tenta-
ng Organisasi dan Tata Kerja Sekretariat Jenderal dan Badan Keahlian DPR RI
No Kandidat “goal” Acuan Keterangan
1 Sekretariat Jenderal mempunyai tugas
mendukung kelancaran pelaksanaan
wewenang dan tugas DPR RI di bidang
administrasi dan persidangan.
Pasal 3 Tugas
Sekretariat
Jenderal
2 Bagian Pengaduan masyarakat mempunyai
tugas melaksanakan kegiatan analisis dan
pengadministrasian surat pengaduan
masyarakat dan permasalahan yang
disampaikan kepada DPR RI dan Sekretariat
Jenderal.
Pasal 28 Tugas Bagian
Pengaduan
Masyarakat
3 Bagian Pengaduan Masyarakat
menyelenggarakan fungsi pelaksanaan
dukungan analisis dan pengadministrasian
surat pengaduan dan permasalahan yang
ditujukan kepada DPR RI dan Sekretariat
Jenderal
Pasal 29
d dan e
Fungsi Bagian
Pengaduan
Masyarakat
Berdasarkan Peraturan Sekretaris Jenderal DPR RI No. 7 Tahun 2018
didapatkan 3 (tiga) kandidat goal dari SPM Online DPR RI, yang masing-
masing kandidat goal berisi mengenai tugas dari bagian-bagian yang ada pada
Sekrteriat Jenderal DPR RI.
96
UIN Syarif Hidayatullah Jakarta
Setelah selesai menentukan kandidat goal dari SPM Online DPR RI
menggunakan metode SAR dan R2G, maka goal model yang terbentuk dari
berdasarkan dokumen regulasi adalah sebagai berikut:
Analisis System-to-be
Analisis system-to-be dilakukan untuk membuat pemodelan awal dari SPM
Online DPR RI yang menggambarkan keinginan sesungguhnya dari Bagian
Pengaduan Masyarakat. Pemodelan yang dihasilkan merupakan hasil modifikasi
terhadap system-as-is berdasarkan dokumen regulasi dan berdasarkan kelemahan
system-as-is yang dijelaskan oleh Kasubbag Analisis Pengaduan Masyarakat II
(Bapak Yadin) saat wawancara.
4.4.1. Pemodelan Goal Model System-to-be
Pada subbab sebelumnya, goal diagram telah dibuat berdasarkan
dokumen regulasi menggunakan metode SAR dan R2G (lihat Gambar 4.20).
Selanjutnya, setiap goal yang ada pada goal diagram tersebut dianalisis untuk
mengetahui apakah setiap goal tersebut benar merupakan goal dari SPM
Online DPR RI yang sesungguhnya diinginkan (system-to-be). Berikut ini
adalah analisis yang dilakukan:
1. Mendukung kewajiban Anggota DPR dalam menampung, dan
menindaklanjuti pengaduan masyarakat
Pada goal model SPM Online DPR RI saat ini, sasaran utama
dikembangkannya sistem adalah “Mendukung kewajiban dan tugas
DPR dalam menerima, menampung, dan menindaklanjuti pengaduan
masyarakat”. Sasaran utama tersebut berbeda dengan sasaran utama
yang didapatkan dari dokumen regulasi (Gambar 4.20). Perbedaan
Gambar 4.20 Goal Diagram Berdasarkan Dokumen Regulasi
97
UIN Syarif Hidayatullah Jakarta
yang ditemukan terletak pada kata “dan”, “tugas”, serta kata
“menerima” yang ada pada sasaran utama system-as-is, sedangkan
apabila dilihat dari sasaran utama yang bersumber dari dokumen
regulasi, ketiga kata tersebut tidak ada. Berdasarkan hal tersebut,
maka sasaran utama dari system-to-be adalah “Mendukung kewajiban
anggota DPR dalam menampung, dan menindaklanjuti pengaduan
masyarakat”. Pemilihan sasaran utama tersebut karena setiap aplikasi
kepemerintahan harus merujuk pada dokumen regulasi yang berlaku.
2. Mendukung pengadministrasian pengaduan masyarakat
Goal “Mendukung pengadministrasian pengaduan
masyarakat” secara substansi memiliki arti yang sama dengan goal
“Mengelola data pengaduan masyarakat yang masuk dan tindak
lanjutnya”. Sehingga, goal tersebut tidak perlu dilakukan perubahan.
3. Hasil analisis surat pengaduan masyarakat dapat dituliskan dan
Menampilkan informasi tindak lanjut pengaduan masyarakat
Karena goal “Hasil analisis surat pengaduan masyarakat dapat
dituliskan” dan goal “Menampilkan informasi tindak lanjut
pengaduan masyarakat” telah digambarkan dalam goal model, maka
tidak ada yang perlu untuk diubah.
Pada tahap berikutnya, dilakukan identifikasi terkait goals atau
kebutuhan sistem yang belum dapat dipenuhi oleh system-as-is. Identifikasi
dilakukan terhadap pernyataan-pernyataan yang disampaikan oleh Bapak
Yadin pada saat wawancara, yaitu:
1. Tersedia rekapitulasi data pengaduan masyarakat
Kebutuhan sistem ini diidentifikasi berdasarkan pernyataan
dari Bapak Yadin terkait adanya kebutuhan yang belum dapat
dipenuhi system-as-is, yaitu:
“Ohiya ada banyak, misalnya terkait dengan quick count,
jadi salah satu tugas dari bagian pengaduan masyarakat ini kan
secara berkala memberikan laporan terkait jumlah surat pengaduan
yang masuk, berdasarkan tiga media itu tadi, kemudian berdasarkan
98
UIN Syarif Hidayatullah Jakarta
bidang-bidang permasalahan mulai dari sosial, politik, budaya, dsb,
total sekitar 33 bidang. Nah itu ternyata masih dengan cara hitung
manual….”.
Berdasarkan apa yang disampaikan di atas, sistem diharuskan
menyediakan fitur rekapitulasi data pengaduan masyarakat, yang
berfungsi untuk menampilkan laporan jumlah surat pengaduan yang
masuk berdasarkan media dan bidang permasalahan.
2. Tersedia form input nama pengadu
Menurut Bapak Yadin, ketika masyarakat ingin mengecek
informasi tindak lanjut dari pengaduan yang telah disampaikan,
masyarakat seharusnya dapat melakukannya hanya dengan
memasukkan “nama pengadu” yang sebelumnya digunakan untuk
menyampaikan pengaduan. Berikut pernyataan lengkap dari Bapak
Yadin:
“ … dan dari masyarakat juga diberikan akses yang
gampang, maksudnya misalkan pihak luar mau mengecek surat
pengaduannya misalnya kan masukin nomer tiket (sekarang), nah
mungkin nanti kita kembangkan tidak hanya nomer tiket aja
misalkan dengan menggunakan nama si pengadu sudah bisa diakses
….”.
Berdasarkan hal tersebut, sistem perlu menyediakan form
input nama pengadu agar masyarakat dapat mengecek informasi
tindak lanjut pengaduan yang telah disampaikan menggunakan nama
pengadu. Selanjutnya, asumsi atau expectation dari agen masyarakat
perlu diperbaiki agar sesuai dengan perubahan kebutuhan sistem yang
telah dijelaskan di atas, sehingga expectation yang awalnya
“memasukkan nomor tiket pengaduan” dirubah menjadi
“memasukkan nomor tiket pengaduan atau nama pengadu”.
3. Mengirimkan aduan masyarakat kepada Anggota DPR melalui email.
Menurut Bapak Yadin sistem seharusnya dapat secara
otomatis mendistribusikan aduan masyarakat yang masuk ke semua
99
UIN Syarif Hidayatullah Jakarta
anggota dewan yang berada pada daerah pemilihan tempat adanya
permasalahan tersebut. Hal ini dibuktikan ketika penulis menanyakan
“apabila dibuatkan sistem alternatif pak, yaitu sebuah sistem yang
mendistribusikan secara otomatis aduan yang masuk ke semua
anggota dewan yang berada pada daerah pemilihan (dapil) tempat
adanya permasalahan tersebut, bagaimana pak?”, dan jawaban Bapak
Yadin “Ya bener mas, bisa saja mas, bisa saja itu menjadi salah satu
alternatif, jadi biasanya ada pengaduan 100 sampai 200 yang sudah
kita serahkan ke komisinya, dan ketua komisinya sudah tau nih, dan
sudah diumumkan di rapat, tetapi tidak semua, karena ternyata yang
diumumkan cuma 5, jadi perlu juga.”
Selain itu, kekurangan tersebut juga diperkuat dengan
ditemukannya fakta bahwa sebagian Anggota DPR tidak mengetahui
adanya permasalahan atau aduan masyarakat yang terjadi di Daerah
Pemilihannya. Seperti yang disampaikan Bapak Yadin “Ya, jadi
kemungkinan itu ada, bahwa anggota dewan tidak tahu atas adanya
aduan masyarakat yang kalau tidak disampaikan sekretariat AKD, dia
(anggota Dewan) tidak tahu”. Sehingga, sistem seharusnya mampu
mendistribusikan setiap aduan masyarakat yang masuk kepada
Anggota DPR yang dipilih oleh masyarakat di daerah aduan tersebut
berasal.
Setelah melakukan analisis terhadap goal diagram (Gambar 4.20) dan
identifikasi terkait goals dan kebutuhan sistem yang belum dapat dipenuhi
oleh system-as-is, dapat diketahui goal model dari sistem yang sesungguhnya
diinginkan (system-to-be), yaitu:
100
UIN Syarif Hidayatullah Jakarta
Gambar 4.21 Goal Model dari System-to-be
101
UIN Syarif Hidayatullah Jakarta
4.4.2. Pemodelan Responsibility Model System-to-be
Seperti yang telah dijelaskan sebelumnya, Responsibility model
dibuat berdasarkan goal model. Sehingga, responsibility model dari setiap
agen adalah:
1. Sistem
Perbedaan dengan responsibility model dari system-as-is
adalah adanya tanggungjawab baru, yaitu Mengirimkan aduan
masyarakat kepada Anggota DPR melalui email, tersedia form
input nama pengadu, dan tersedia rekapitulasi data pengaduan
masyarakat. Berikut ini merupakan responsibility model dari agen
Sistem:
2. Masyarakat
3. Sekretariat AKD
Gambar 4.22 Responsibility Model dari System-to-be untuk Sistem
Gambar 4.23 Responsibility Model dari System-to-be untuk Masyarakat
Gambar 4.24 Responsibility Model dari System-to-be untuk Sekretariat AKD
102
UIN Syarif Hidayatullah Jakarta
4. Pengadministrasi Umum
4.4.3. Analisis Kebutuhan System-to-be
Setelah melakukan pemodelan system-to-be, pada subbab ini akan
dilakukan analisis kebutuhan system-to-be yang belum terealisasi pada
system-as-is. Analisis dilakukan untuk membuat algoritma yang dapat
digunakan untuk memenuhi kebutuhan sistem tersebut. Berikut analisis yang
dilakukan:
1. Tersedia rekapitulasi data pengaduan masyarakat
Berdasarkan hasil pemodelan yang telah dijelaskan pada subbab
sebelumnya, dapat diketahui kebutuhan system-to-be yang belum
terealisasi pada system-as-is, salah satunya ‘tersedia rekapitulasi data
pengaduan masyarakat’. Kebutuhan ini dapat dibuat dengan
menggunakan algoritma berikut:
Program Rekapitulasi_Data_Pengaduan
{Melakukan perhitungan otomatis jumlah aduan masyarakat
berdasarkan waktu masuknya aduan, media yang digunakan, dan
bidang permasalahan}
Data Dictionary:
Type aduan: record < id: String, nama: String, tujuan_aduan: String, isi_aduan: String, analisis_aduan: String, bidang: String, waktu_input: Date, media: String, status: String, alamat: String
Gambar 4.25 Responsibility Model dari System-to-be untuk
Pengadministrasi Umum
103
UIN Syarif Hidayatullah Jakarta
>
aduan_masyarakat : aduan
Function get_aduan() String
Function DisplayJumlahAduan (Media_Aduan: String,
Waktu_Awal: Date, Waktu_Akhir: Date, Bidang_Permasalahan:
String, aduan_masyarakat: aduan) integer
ALGORITHM:
aduan_masyarakat get_aduan()
DisplayJumlahAduan (Media_Aduan, Waktu_Awal,
Waktu_Akhir, Bidang_Permasalahan, aduan_masyarakat)
Berdasarkan algoritma di atas, terdapat dua fungsi, yaitu fungsi
get_aduan() dan fungsi DisplayJumlahAduan(). Algoritma dari fungsi
get_aduan() sebagai berikut:
FUNCTION get_aduan()
{Mendapatkan data aduan yang dimasukkan masyarakat}
DATA DICTIONARY:
Type aduan: record < id: String, nama: String, tujuan_aduan: String, isi_aduan: String, analisis_aduan: String, bidang: String, waktu_input: Date, media: String, status: String, alamat: String
>
ALGORITHM
write(aduan)
read (aduan)
aduan
104
UIN Syarif Hidayatullah Jakarta
Setelah penjelasan algoritma pada fungsi get_aduan(), Berikut ini
algoritma fungsi DisplayJumlahAduan() yang digunakan untuk
melakukan perhitungan otomatis jumlah aduan masyarakat
berdasarkan aduan masyarakat berdasarkan waktu, media, dan bidang
permasalahan:
FUNCTION DisplayJumlahAduan()
{Melakukan perhitungan otomatis jumlah aduan masyarakat
berdasarkan waktu masuknya aduan, media yang digunakan, dan
bidang permasalahannya}
DATA DICTIONARY:
Type jumlah_aduan : Integer
ALGORITHM
write (Media_Aduan, Waktu_Awal, Waktu_Akhir,
Bidang_Permasalahan)
read (Media_Aduan, Waktu_Awal, Waktu_Akhir,
Bidang_Permasalahan)
Display (aduan_masyarakat)
read (bidang, waktu_input, media)
repeat
if ( bidang == Bidang_Permasalahan && media ==
Media_Aduan && waktu_input >= Waktu_Awal &&
waktu_input <= Waktu_Akhir)
jumlah_aduan+=1
endif
until (tidak ada aduan_masyarakat yang belum dicek)
return (jumlah_aduan)
105
UIN Syarif Hidayatullah Jakarta
2. Tersedia form input nama pengadu.
Kebutuhan sistem untuk menyediakan form input nama pengadu
ini, dapat diwujudkan dengan tampilan seperti ini:
Pada system-as-is telah tersedia form input nomor tiket pengaduan,
sehingga untuk system-to-be hanya perlu menambahkan sebuah
combobox yang akan digunakan sebagai parameter
untuk mengecek status pengaduan. Combobox tersebut terdiri dalam
dua pilihan, yaitu nomor tiket pengaduan dan nama pengadu. Setelah
ditambahkannya form input nama pengadu pada system-to-be, maka
algoritma dari pengecekan status pengaduan berubah menjadi sebagai
berikut:
Program Cek_Status
{Melakukan pengecekan status tindak lanjut dari aduan
masyarakat yang masuk}
Data Dictionary:
Type aduan: record < id: String, nama: String, tujuan_aduan: String, isi_aduan: String, analisis_aduan: String, bidang: String, waktu_input: Date, media: String, status: String, alamat: String
>
aduan_masyarakat : aduan
Function get_aduan() String
Gambar 4.26 Tampilan Form Input nama pengadu
106
UIN Syarif Hidayatullah Jakarta
Function DisplayStatus (parameter: String, kata_kunci: String,
aduan_masyarakat: aduan) integer
ALGORITHM:
aduan_masyarakat get_aduan()
DisplayStatus (parameter, kata_kunci, aduan_masyarakat)
Berdasarkan algoritma di atas, terdapat dua fungsi, yaitu fungsi
get_aduan() dan fungsi DisplayJumlahAduan(). Algoritma dari fungsi
get_aduan() sama dengan algoritma fungsi get_aduan() yang terdapat
pada program Rekapitulasi_Data_Pengaduan, sedangkan untuk
algoritma dari DisplayStatus() adalah sebagai berikut:
FUNCTION DisplayStatus()
{Melakukan pengecekan status tindak lanjut dari aduan
masyarakat yang masuk}
DATA DICTIONARY:
Type parameter: String
Type kata_kunci: String
Type status: String
ALGORITHM
write (parameter)
read (parameter)
write (kata_kunci)
read (kata_kunci)
display (aduan_masyarakat)
read (aduan_masyarakat)
repeat
if (parameter==”Nomor Tiket Pengaduan”)
if(id==kata_kunci)
return (status)
107
UIN Syarif Hidayatullah Jakarta
endif
endif
if (parameter==”Nama Pengadu”)
if(nama==kata_kunci)
return (status)
endif
endif
until (tidak ada aduan_masyarakat yang belum dicek)
3. Mengirimkan aduan masyarakat kepada anggota DPR melalui
Kebutuhan sistem yang terakhir adalah kebutuhan untuk
mengirimkan aduan masyarakat kepada anggota DPR melalui email.
Berikut ini merupakan algoritma yang dapat digunakan:
Program Pengiriman_Aduan
{Melakukan pengiriman aduan masyarakat kepada Anggota DPR
melalui email}
Data Dictionary:
Type aduan: record < id: String, nama: String, tujuan_aduan: String, isi_aduan: String, analisis_aduan: String, bidang: String, waktu_input: Date, media: String, status: String, alamat: String
>
aduan_masyarakat : aduan
selected_email : String
Function get_aduan() String
108
UIN Syarif Hidayatullah Jakarta
Function get_email(aduan_masyarakat, kata_kunci: String,)
String
Function Kirim_Aduan (selected_email: String,
aduan_masyarakat: aduan ) integer
ALGORITHM:
aduan_masyarakat get_aduan()
selected_email get_email(kata_kunci)
Kirim_Aduan (selected_email, aduan_masyarakat)
Berdasarkan algoritma di atas, terdapat dua fungsi, yaitu fungsi
get_aduan() dan fungsi Kirim_Aduan(). Algoritma dari fungsi
get_aduan() sama dengan algoritma fungsi get_aduan() yang terdapat
pada program Rekapitulasi_Data_Pengaduan, sedangkan untuk
algoritma dari Kirim_Aduan() adalah sebagai berikut:
FUNCTION get_email()
{Melakukan pengiriman aduan masyarakat kepada Anggota DPR
melalui email}
DATA DICTIONARY:
Type selected_email: String Type alamat_anggota: String
ALGORITHM
display (aduan_masyarakat)
read (aduan_masyarakat)
read from database (alamat_anggota)
repeat
if (alamat==alamat_anggota)
send_email_base_on_alamat()
endif
until (tidak ada data pada tabel Anggota DPR yang belum
dicek)
109
UIN Syarif Hidayatullah Jakarta
Analisis System-to-be Akhir (Setelah validasi)
Pada Subbab ini, penulis melakukan analisis system-to-be akhir berdasarkan
hasil wawancara atau validasi yang telah dilakukan penulis dengan Bapak Yadin
(Kepala Subbagian Analisis Pengaduan Masyarakat II). Analisis system-to-be akhir
merupakan usaha yang dilakukan untuk membuat kesimpulan apakah pemodelan
system-to-be yang telah dibangun penulis sebelumnya adalah benar dan mewakili
keinginan dari Bagian Pengaduan Masyarakat DPR RI.
4.5.1. Pemodelan Goal Model System-to-be Akhir
Pada subbab ini, penulis akan membuat goal model dari SPM Online
DPR RI yang sesungguhnya ingin dicapai oleh Bagian Pengaduan
Masyarakat (system-to-be akhir). Goal model system-to-be akhir dibangun
berdasarkan hasil validasi yang telah penulis lakukan kepada Kasubbag
Analisis Pengaduan Masyarakat II melalui proses wawancara. Validasi
dilakukan untuk memastikan objektivitas goal model system-to-be awal yang
telah dibangun oleh penulis pada tahap sebelumnya. Sehingga, penulis dapat
memperbaiki goal model system-to-be tersebut apabila di dalamnya terdapat
kesalahan.
Berdasarkan validasi yang telah dilakukan penulis kepada Bapak
Yadin selaku Kasubbag Analisis Pengaduan Masyarakat II, goal model
system-to-be tidak perlu diperbaiki. Karena goal model tersebut telah dinilai
aman dan mewakili kebutuhan sistem yang sesungguhnya diinginkan
(system-to-be). Sehingga, goal model dari system-to-be akhir dapat dilihat
pada Gambar 4.21 (tidak mengalami perubahan).
4.5.2. Pemodelan Responsibility Model System-to-be Akhir
Setelah melakukan validasi, dapat diketahui bahwa goal model tidak
ada yang perlu diperbaiki. Sehingga, responsibility model dari system-to-be
setelah dilakukan validasi sama dengan responsibility model dari system-to-
be sebelum dilakukan validasi. Responsibility untuk agen Sistem dapat dilihat
pada Gambar 4.22, untuk agen Masyarakat ada pada Gambar 4.23, agen
Sekretariat AKD terlihat pada Gambar 4.24, dan untuk agen
Pengadministrasi Umum dapat dilihat pada Gambar 4.25.
110
BAB 5
HASIL DAN PEMBAHASAN
Pemodelan Kesenjangan
Pada bab sebelumnya, telah dijelaskan bagaimana analisis dan pemodelan
dari system-as-is dan system-to-be. Pembuatan model dari system-as-is mengacu
pada hasil analisis dokumen Standar Operasional Prosedur (SOP), analisis hasil
observasi system-as-is, dan analisis hasil wawancara. Sedangkan untuk system-to-
be mengacu pada hasil analisis dokumen regulasi yang berlaku dan analisis hasil
wawancara.
Metode SAR dan R2G digunakan sebagai metode untuk mendapatkan
kandidat goal berdasarkan dokumen regulasi yang berlaku. Metode KAOS
digunakan sebagai metode untuk membuat goal model dan responsibility model.
Berdasarkan hasil analisis dan pemodelan tersebut, dapat diketahui tiga kebutuhan
SPM Online DPR RI yang sesungguhnya diinginkan dan belum dapat terealisasi
pada system-as-is:
1. Tersedia rekapitulasi data pengaduan masyarakat.
2. Mengirimkan aduan masyarakat kepada Anggota DPR melalui email.
3. Tersedia form input nama pengadu.
Selain itu, strategic goal mengalami perubahan, dari yang sebelumnya
(system-as-is) adalah “Mendukung kewajiban dan tugas DPR dalam menerima,
menampung, dan menindaklanjuti pengaduan masyarakat” menjadi (system-to-be)
“ Mendukung kewajiban Anggota DPR dalam menampung, dan menindaklanjuti
pengaduan masyarakat”. Selanjutnya, tanggungjawab dari agen masyarakat juga
mengalami perubahan, dari “Memasukkan nomor tiket pengaduan” menjadi
“Memasukkan nomor tiket pengaduan atau nama pengadu”.
Berdasarkan penjelasan di atas, berikut ini merupakan pemodelan yang
menggambarkan kesenjangan goal dan kebutuhan SPM Online DPR RI:
111
UIN Syarif Hidayatullah Jakarta
Gambar 5.1 di atas menggambarkan kesenjangan yang terjadi antara goal model system-as-is dengan goal model system-to-be. Persegi panjang berwarna merah dengan tulisan system-to-be yang ada
pada Gambar 5.1 berfungsi untuk menjelaskan bahwa goal, expectations, dan kebutuhan yang ada di dalamnya merupakan milik system-to-be, sedangkan persegi panjang yang bertuliskan system-as-is dan
terhubung dengan garis merah putus-putus menjelaskan apakah goal, expectations, dan kebutuhan tersebut ada pada system-as-is atau tidak.
Gambar 5.1 Pemodelan Kesenjangan Antara System-as-is dengan System-to-be
112
UIN Syarif Hidayatullah Jakarta
Analisis Kesenjangan
Analisis kesenjangan dilakukan berdasarkan kebutuhan SPM Online DPR RI
yang telah terealisasi saat ini (system-as-is), dengan kebutuhan SPM Online DPR
RI yang sesungguhnya diinginkan (system-to-be). Berikut ini merupakan tabel
keberhasilan system-as-is dalam merealisasikan kebutuhan system-to-be:
Tabel 5.1 Hasil Realisasi Kebutuhan System-as-is
Berdasarkan tabel di atas, diketahui jumlah kebutuhan sistem yang terealisasi
pada system-as-is sebanyak 13 kebutuhan sistem dari total 16 kebutuhan sistem
yang sesungguhnya diinginkan (system-to-be), sehingga tingkat kesenjangan yang
terjadi antara system-as-is dengan system-to-be adalah:
No Kebutuhan Sistem Terealisasi
1 Tersedia tampilan informasi cara pengiriman pengaduan √
2 Tersedia menu sunting informasi cara pengiriman
pengaduan √
3 Tersedia fitur hapus data pengaduan masyarakat √
4 Tersedia form input pengaduan melalui surat √
5 Tersedia form pengaduan online √
6 Terdapat autentikasi dalam mengakses sistem √
7 Tersedia fitur pencarian data pengaduan masyarakat √
8 Tersedia statistik data pengaduan masyarakat √
9 Tersedia daftar data pengaduan masyarakat √
10 Tersedia rekapitulasi data pengaduan masyarakat ×
11 Tersedia menu edit data pengaduan √
12 Tersedia tampilan informasi tindak lanjut pengaduan
masyarakat √
13 Tersedia form input hasil tindak lanjut √
14 Mengirimkan aduan masyarakat kepada Anggota DPR
melalui email ×
15 Tersedia form input nomor tiket pengaduan √
16 Tersedia form input nama pengadu ×
Z = ( X - Y )
Z = ( 16 - 13 )
Z = 3 kebutuhan sistem
113
UIN Syarif Hidayatullah Jakarta
Keterangan:
X= Total kebutuhan sistem yang sesungguhnya diinginkan (system-to-be).
Y= Total kebutuhan sistem yang terealisasi saat ini (system-as-is).
Z= Tingkat Kesenjangan.
Selanjutnya, nilai tingkat kesenjangan tersebut Sebagaimana perhitungan
tingkat kesenjangan yang telah dilakukan di atas, maka presentase tingkat
kesenjangan yang terjadi adalah:
Presentase Tingkat Kesenjangan = Z
X X 100%
Presentase Tingkat Kesenjangan = 3
16 X 100%
Presentase Tingkat Kesenjangan = 18,75%
Hasil perhitungan di atas menunjukkan adanya kesenjangan yang terjadi
antara kebutuhan sistem yang telah direalisasikan oleh system-as-is dengan
kebutuhan sistem yang sesungguhnya diinginkan (system-to-be), yaitu sebesar
18,75% atau 3 kebutuhan sistem. Kesenjangan tersebut terjadi karena Bagian
Pengaduan Masyarakat Setjen DPR RI belum melakukan pengembangan terhadap
system-as-is untuk mencapai kebutuhan-kebutuhan sistem yang sesungguhnya
diinginkan.
Selanjutnya, presentase keberhasilan system-as-is dalam merealisasikan
kebutuhan SPM Online DPR RI yang sesungguhnya diinginkan adalah:
Presentase Keberhasilan system-as-is = Y
X x 100%
Presentase Keberhasilan system-as-is = 13
16 x 100%
Presentase Keberhasilan system-as-is = 81,25%
Hasil perhitungan tersebut menjelaskan bahwa SPM Online DPR RI saat ini
(system-as-is) belum optimal, karena system-as-is hanya dapat memenuhi 81,25%
dari total kebutuhan sistem yang sesungguhnya diinginkan, yaitu 16 kebutuhan
sistem.
114
BAB 6
PENUTUP
Kesimpulan
Penelitian ini bertujuan untuk menganalisis kebutuhan SPM Online DPR RI
dengan pendekatan berorientasi sasaran. Berikut ini kesimpulan yang diperoleh
melalui penelitian yang dilakukan:
1. Hasil analisis kebutuhan SPM Online DPR RI dengan metode SAR, R2G, dan
KAOS sesuai dengan justifikasi dari ahli SPM Online DPR RI, artinya metode
tersebut terbukti dapat digunakan untuk menganilisis kebutuhan SPM Online
DPR RI dengan hasil yang baik.
2. Kondisi SPM Online DPR RI saat ini (system-as-is) hanya dapat
merealisasikan 13 kebutuhan sistem atau setara 81,25% dari total 16 kebutuhan
sistem yang sesungguhnya diinginkan (system-to-be), artinya system-as-is
belum optimal, karena terdapat kesenjangan yang terjadi antara system-as-is
dengan system-to-be, yaitu sebesar 3 kebutuhan sistem atau 18,75%.
Saran
Berikut ini merupakan saran yang perlu dipertimbangkan sebagai bentuk
pengembangan penelitian yang telah penulis lakukan:
1. Pada penelitian berikutnya, diharapkan untuk menambahkan elicitation
techniques yang lain seperti kuesioner dan group sessions.
2. Wawancara perlu dilakukan kepada setiap peran yang terlibat dalam sistem
untuk memperkaya informasi dalam menyusun hasil analisis kebutuhan sistem.
3. Diharapkan dapat dilakukan penelitian mengenai kemungkinan penggabungan
antara pendekatan berorientasi sasaran dengan pendekatan lain seperti objek,
proses, dan data.
4. Untuk mendapatkan hasil analisis kebutuhan sistem secara menyeluruh
diperlukan interaksi atau wawancara dengan seluruh stakeholders Sistem
Pengaduan Masyarakat (SPM) Online DPR RI seperti masyarakat, anggota
DPR RI, dan Sekretariat AKD.
115
UIN Syarif Hidayatullah Jakarta
DAFTAR PUSTAKA
Adikara, F., Sitohang, B., & Hendradjaya, B. (2013). Penerapan Goal Oriented
Requirements Engineering ( GORE ) Model ( Studi Kasus : Pengembangan
Sistem Informasi Penjaminan Mutu Dosen ( SIPMD ) pada Institusi
Pendidikan Tinggi ). Seminar Nasional Sistem Informasi Indonesia, 229–
234.
Aini, Q. (2018). Analisis Website Perpustakaan Universitas Islam Negeri
Menggunakan Metode Benchmarking dan Goal Oriented Requirements
Engineering (GORE) Model (Studi Kasus: UIN Jakarta, UIN Yogyakarta,
dan UIN Malang).
Bano, J., Reddy, L. S. S., & Khammari, H. (2018). A Significant Research
Framework on Goal Oriented Requirement Engineering, 13(11).
Chazienul Ulum, M. (2018). Public Service (Tinjauan Teoritis dan Isu-isu
Strategis Pelayanan Publik). Malang: UB Press. Retrieved from
https://books.google.co.id/books?id=u_-FDwAAQBAJ
Dipaloka, A., Suwardi, I. S., & Surendro, K. (2016). Pemodelan Requirements
Dalam Mengkonstruksi Perangkat Lunak Self-Adaptive. Jurnal Ilmiah
Teknologi Informasi Terapan, II(August).
DPR RI. (2018). Ringkasan Laporan Kinerja DPR RI Tahun Keempat. Retrieved
from www.dpr.go.id
DPR RI. (2019). Sistem Informasi Aspirasi dan Pengaduan Masyarakat DPR RI.
Retrieved March 12, 2019, from www.pengaduan.dpr.go.id
Fuadiyati, R. (2018). Analisis Requirement Sistem Evaluasi Dosen oleh
Mahasiswa (EDOM) Online UIN Syarif Hidayatullah Dengan Goal Oriented
Requirement Engineering (GORE) Model.
Hutahaean, J. (2014). Konsep Sistem Informasi (1st ed.). DEEPUBLISH.
Retrieved from https://books.google.co.id/books?id=o8LjCAAAQBAJ
Lamsweerde, A. (2009). Requirement Engineering From System Goals to UML
Models to Software Spesifications. A John Wiley and Sons.
Lapouchnian, A. (2005). Goal-Oriented Requirements Engineering : An Overview
116
UIN Syarif Hidayatullah Jakarta
of the Current Research Goal-Oriented Requirements Engineering,
(September).
Luthfi Azis, M. N., & Lestariningsih, T. (2018). Analisis Tatakelola Sistem
Informasi pada PT. Duta Kartika Agro Lestari Menggunakan COBIT 4.1.
Jurnal AKSI (Akuntansi Dan Sistem Informasi), 2(1), 33–42.
https://doi.org/10.32486/aksi.v2i1.215
Maniah, & Hamidin, D. (2017). Analisis dan Perancangan Sistem Informasi.
Yogyakarta: DEEPUBLISH. Retrieved from
https://books.google.co.id/books?id=MjxyDwAAQBAJ
Nasir, M. (2014). Kesiapan Perusahaan Terhadap Pengadopsian ISO 50001
dengan Menggunakan Tools Gap Analysis Studi Kasus PT. Indo Acidatama.
Tbk. Jurnal Teknik Industri, 35(1), 1–10.
Parveen, S., & Imam, A. (2017). Analysis of different techniques of GORE (Goal
oriented requirement engineering). Global Sci-Tech, 9(1), 22.
https://doi.org/10.5958/2455-7110.2017.00004.0
Rahman, D. (2017). Sistem Monitoring Pakan Kucing Otomatis Berbasis Mobile.
UIN Syarif Hidayatullah Jakarta.
RESPECT-IT. (2007). A Kaos Tutorial. Retrieved December 1, 2018, from
http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf
Sekretariat Jenderal dan Badan Keahlian DPR RI. (2019). Laporan Kinerja 2018.
Shofi, I. (2015). Metode Analisis Pra-Syarat Perangkat Lunak Berorientasi
Sasaran Berdasarkan Dokumen Regulasi. Universitas Indonesia.
Shofi, I. M., & Budiardjo, E. K. (2011). Klasifikasi Metode Goal Oriented
Requirement Engineering ( Gore ) Dan Kemungkinannya Untuk
Mengembangkan Aplikasi Kepemerintahan. Seminar Nasional Teknologi
Informasi Dan Komunikasi Terapan (SEMANTIK), 2011(Semantik).
Silva, J. M. (2016). Using GORE method for Requirement Engineering of
Planning & Scheduling. International Conference on Automatic Planning
and Scheduling, 2016, (Gonzalez 2009), 137–140. Retrieved from
http://icaps16.icaps-conference.org/proceedings/dc/dc16.pdf
Simbolon, L. (2019). Lembaga-Lembaga Negara. Yogyakarta: DEEPUBLISH.
117
UIN Syarif Hidayatullah Jakarta
Retrieved from https://books.google.co.id/books?id=6oifDwAAQBAJ
Souza, R. S., Sanfilippo, F., Silva, J. R., & Cordero, A. F. (2016). Modular
exoskeleton design: Requirement engineering with KAOS. Proceedings of
the IEEE RAS and EMBS International Conference on Biomedical Robotics
and Biomechatronics, 2016-July, 978–983.
https://doi.org/10.1109/BIOROB.2016.7523756
Sugiyono. (2016). Metode Penelitian Kuantitatif, Kualitatif, dan R&D. Bandung:
ALFABETA.
Ubaedillah, A. (2015). Pendidikan Kewarnegaraan (Civic Education) Pancasila,
Demokrasi, dan Pencegahan Korupsi (1st ed.). Jakarta: PT. Fajar
Interpratama Mandiri. Retrieved from
https://books.google.co.id/books?id=gFc_DwAAQBAJ
Werneck, V. M. B., Oliveira, A. de P. A., & do Prado Leite, J. C. S. (2009).
Comparing GORE Frameworks: i-star and KAOS. Wer, (January), 1–12.
Retrieved from http://wer-papers.googlecode.com/svn-
history/r71/trunk/dataset/wer09/WER09_4.pdf
Whitten, J. L., & Bentley, L. D. (2018). Systems Analysis and Design Methods.
McGraw-Hill/Irwin (7th ed.). new york.
https://doi.org/10.1201/9781315587363-10
118
UIN Syarif Hidayatullah Jakarta
LAMPIRAN
Lampiran I. Wawancara Ahli
Tujuan : Mendapatkan informasi mengenai kondisi Sistem
Pengaduan Masyarakat Online DPR RI saat ini
(system-as-is), dan untuk mengetahui kelemahan dari
system-as-is.
Tempat : Gedung Sekretariat Jenderal dan Badan Keahlian DPR RI
Waktu : Jam 13.20 WIB, Selasa, 21 Mei 2019
Durasi : 100 Menit
Narasumber : Bapak Safarudin Surya Lesmana, M.H. (Yadin)
(Kepala Subbagian Analisis Pengaduan Masyarakat II)
Pertanyaan:
1. Apa saja platform atau tools yang bisa diakses oleh masyarakat kalau
mau melakukan pengaduan? Ada apa aja media yang bisa digunakan
pak?
Jawaban: Ada 3 jenis media yang disediakan oleh DPR RI atau
khususnya Setjen DPR RI untuk melayani pengaduan masyarakat, yang
pertama bisa mengajukan melalui surat tertulis itu bisa saja di dalam surat
itu langsung ditujukan kepada ketua DPR RI dan alamatnya. Kemudian
yang kedua, melalui website atau yang sering kita sebut email yaitu
www.pengaduan.dpr.go.id. Terus yang ketiga melalui sms aspirasi, di
laman DPR itu ada nanti bisa dilihat nomernya.
2. Apa alasan atau tujuan utama dalam pembangunan Sistem Pengaduan
Masyarakat Online (www.pengaduan.dpr.go.id )?
Jawaban: Sebenernya sama saja dengan yang dua lainnya, pada intinya
yang paling utama adalah tugas, wewenang, dan kewajiban dewan,
sebagaimana yang di maksud di UU MD3 Pasal 74 bahwa anggota DPR
mempunyai kewajiban dan tugas menerima, menampung dan
menindaklanjuti aspirasi dan pengaduan masyarakat. Nah disinilah yang
dimaksud, Jadi alasan utama atau urgensitas yang pertama adalah itu.
119
UIN Syarif Hidayatullah Jakarta
(lanjutan)
3. Apakah ada pembagian hak akses sistem? Lalu, siapa saja yang bisa
terlibat dalam sistem?
Jawaban: Jadi kita melibatkan beberapa pegawai di beberapa bagian.
Pertama di bagian ini, yaitu tingkat eselon 3, pejabat dan staff di bagian
pengaduan masyarakat ada dua jenis, satu sebagai analis pengaduan
masyarakat, dan yang kedua sebagai administrasi umum. Administrasi
Umum itu yang melakukan input data kemudian mencatat apakah surat
ini sudah disampaikan ke komisi sesuai bidangnya atau belum, untuk
yang bagian analisis berarti melakukan analisis terkait pengaduan yang
masuk.
4. Jadi yang bisa akses kepada sistemnya itu dari pengaduan masyarakat
pak?
Jawaban: Kalau masyarakat itu semua orang bisa masuk, tetapi untuk
pengolaannya dari bagian pengaduan masyarakat, dan satu lagi adalah
bagian sekretariat Alat Kelengkapan Dewan (AKD), yaitu komisi I-XI
nah itu sekretariatnya.
5. Dari apa yang Bapak jabarkan tadi, terkait sistemnya pak, kira-kira ada
tidak sih pak kelemahan-kelamahannya?
Jawaban: Ohiya ada banyak, misalnya terkait dengan quick count atau
perhitungan secara cepat, jadi salah satu tugas dari bagian pengaduan
masyarakat ini kan secara berkala memberikan laporan terkait jumlah
surat pengaduan yang masuk, berdasarkan tiga media itu tadi, kemudian
berdasarkan bidang-bidang permasalahan mulai dari sosial, politik,
budaya, hukum dsb, total sekitar 33 bidang. Nah itu ternyata masih
dengan cara hitung manual, jadi sekarang ini kita sedang melakukan
pengembangan atau pembangunan aplikasi lagi dan sedang proses dan
kita bekerjasama dengan BDTI (Bidang Data dan Teknologi Informasi)
untuk mengembangkan ini supaya bisa ada fitur hitung cepat, dan dari
masyarakat juga diberikan akses yang gampang,
120
UIN Syarif Hidayatullah Jakarta
(lanjutan)
maksudnya misalkan pihak luar mau mengecek surat pengaduannya
misalnya kan masukin nomer tiket (sekarang), nah mungkin nanti kita
kembangkan tidak hanya nomer tiket aja, misalkan dengan menggunakan
nama si pengadu sudah bisa diakses, jadi tidak perlu udah nama nomer
tiket pula, atau misalkan nama doang tanpa nomer tiket merasa kesulitan.
Jadi untuk mempermudah, sudah kita bangun tadi.
7. Berdasarkan asumsi saya pak, jadi kalau berdasarkan regulasi itu tugas
dan kewajiban anggota DPR RI itu adalah menerima, menampung dan
menindaklanjuti pengaduan masyarakat, yang jadi permasalahan itu yang
tidak berhasil terlaksana dengan baik adalah di bagian menindaklanjuti,
benar tidak sih pak?
Jawaban: Iyaaa gitu, jadi ini artinya kan ketika ada pengaduan
masyarakat, kita sampaikan ke AKD. Nah nanti mekanismenya
dirapatkan bagaimana caranya pengaduan masyarakat ini ditindaklanjuti.
Namun dalam prakteknya minim, disaat kerja kita sudah maksimal kita
mengelola pengaduan masyarakat ini yang website, surat tertulis, dan
sms, kemudian ada juga yang secara langsung tetapi bukan ke kita, ke
PPID (ke bagian protokol).
Jadi, menurut saya ada beberapa faktor mas penyebab kurangnya
tindaklanjut tersebut, pertama dari anggota dewannya sendiri, terkadang
kita sudah menyampaikan ‘ini ada surat keluhan pak, surat pengaduan
masyarakat sebanyak 5 surat’, tetapi beliau ada yang merespond tetapi
tidak ada tindak lanjutnya, padahal tindak lanjut ada di dia sendiri,
mekanisme juga ada di dia sendiri, seperti menjawab atau merespond
’ohh iyaaa’ yaudah gitu doang tidak ditindaklanjuti, nah itu harusnya
direspondnya seperti apa jadi kita tinggal melaksanakan.
121
UIN Syarif Hidayatullah Jakarta
(lanjutan)
Kedua, keaktifan dari sekretariat dari AKD itu sendiri, jadi misalkan
kalau dari sekretariat tidak mengajukan atau memberikan surat-surat
pengaduan kepada pimpinan dan anggota AKD-nya itu sendiri ya susah,
surat itu akan terus menggelembung dan tidak ada tindak lanjutnya.
8. Untuk surat-surat yang tertulis juga seperti itu pak?
Jawaban: Iya, terus mengenai bentuk tindak lanjutnya seperti apa sih, itu
lebih banyak surat-surat pengaduan baik yang melalui tertulis, website,
atau sms, itu memang apabila ada 100 yang masuk, itu tidak bisa
semuanya, jadi secara bertahap gitu kan, kita pilih yang sifatnya satu
lebih urgent, kedua sifatnya menasional atau menyangkut hajat hidup
orang banyak.
9. Berdasarkan laporan pengaduan dan aspirasi masyarakat tahun sidang
2017-2018 itu ada 595 pengaduan yang masuk melalui website, dan yang
diteruskan ke komisi terkait ada 417 surat, berarti positif sebenarnya pak
ya?
Jawaban: itu data yang diteruskan mas, kalau perihal ditindaklanjuti beda
lagi mas.
10. Ada tapi pak datanya?
Jawaban: kewenangannya kami tidak sampai situ mas, makanya kami
hanya merekap atau membuat laporan hanya ‘yang diteruskan atau
disampaikan’, kalau yang soal tindak lanjut lain lagi mas. Jadi, kalau soal
tindak lanjutnya masih minim sekali mas.
11. Lalu kalau data dalam bentuk tabel atau grafik terkait pengaduan yang
sudah atau belum ditindaklanjut itu gimana pak?
Jawaban: kita tidak bikin rekapnya mas, makanya ketika mas bacakan
laporan nya tadi itu yang terlihat jumlah pengaduan yang diteruskan ke
komisi aja, ya karena kewenangan kita sampai situ,
122
UIN Syarif Hidayatullah Jakarta
(lanjutan)
sedangkan kalau data tindak lanjutnya ya harus ditelusuri ke tiap AKD,
‘pak surat dengan nomor sekian, tindak lanjutnya seperti apa’, nah itu
kan banyak sekali, nah ini yang masih jadi masalah kita.
12. Jadi kan secara faktanya itu ada setengah dari pegawai dari sekretariat
AKD itu yang sudah aktif lagi dalam menggunakan website karena
mutasi dan sebagainya, itu benar pak?
Jawaban: Ya benar, ada setengah atau 50% yang sudah tidak aktif lagi
menggunakan website tersebut.
13. Berarti benar pak, ada fakta juga bahwa banyak anggota dewan yang
sebenarnya tidak mengetahui adanya aduan dari masyarakat? Atau ada
kemungkinan seperti itu pak?
Jawaban: Yaa kemungkinan itu ada, seperti yang saya bilang tadi,
keaktifan dari sekretariat AKD itu sendiri, dengan alasan anggotanya
sibuk, dsb, sehingga tidak bisa tersampaikan secara penuh. Ya, jadi
kemungkinan itu ada bahwa anggota dewan tidak tahu atas adanya aduan
masyarakat yang kalau tidak disampaikan oleh sekretariat AKD, dia
tidak tau.
14. Berarti apabila dilihat dari kepentingan komisi terkait, kan kepentingan
yang diambil adalah kepentingan komisi pak?
Jawaban: Siap, benar mas seperti itu, itu salah satu penyebab kurangnya
atau minimnya tindak lanjut daripada pengaduan masyarakat di DPR ini
ya itu tadi, jadi khususnya itu, secara krusial dari sisi politisnya itu, kalau
tidak sexy yaudah engga.
15. Ada fakta juga sebenarnya bahwa anggota dewan yang tidak tau nih ada
aduan masyarakat, dan terutama juga aduan-aduan di daerah
pemilihannya sendiri, faktanya juga seperti itu pak ya?
123
UIN Syarif Hidayatullah Jakarta
(lanjutan)
Jawaban: Iya benar, tetapi sebenarnya selain kita ke komisi pengiriman
aduannya, kita juga rekomendasikan ke anggota dewan yang berada atau
termasuk dalam daerah pemilihan dari tempat adanya aduan masyarakat
tersebut.
16. Berarti sudah didistribusikan/dikirim ke anggota dewan terkait yang
berada di dalam Daerah Pemilihan tersebut juga pak?
Jawaban: Engga engga, jadi di dalam lembar analisis dan rekomendasi
yang biasanya kita buat, itu ada kita tulis Daerah Pemilihan mana yang
menjadi tempat kejadian dari aduan tersebut.
17. Tetapi itu didisposisinya kemana pak?
Jawaban: Tetap ke komisi, berarti si anggota yang merasa dia berada di
dapil tersebut, harusnya dia lebih aktif, dan lebih ditekankan dia.
18. Tetapi tetap ada juga kemungkinan bahwa di suatu komisi itu tidak ada
anggota dari dapil aduan tersebut pak?
Jawaban: Memang ada, makanya kita juga tidak hanya untuk komisi saja,
tetapi ke fraksi juga, karena kan surat banyak yaa, makanya biar
ditindaklanjuti ya kita kirim juga. Karena mereka itu hitungannya adalah
konstituennya yang mengadu, berarti nanti tindak lanjutnya juga bagi si
anggota dewan dalam bentuk kunjungan kerja pada masa reses, tetapi
tetap tidak begitu banyak juga tindak lanjutnya.
19. Jadi apabila dibuatkan sistem alternatif pak, yaitu sebuah sistem yang
mendistribusikan secara otomatis aduan yang masuk ke semua anggota
dewan yang berada pada daerah pemilihan (dapil) tempat adanya
masalah tersebut, bagaimana pak?
Jadi dari pengaduan masyarakat melakukan analisis kemudian
didisposisikan, nah jadi kalau menggunakan sistem ini tidak lagi
memikirkan terkait urgensinya atau skala masalahnya nasional atau
bukan yang penting pertanyaannya di bagian pengaduan masyarakat itu
terjadi di dapil mana,
124
UIN Syarif Hidayatullah Jakarta
(lanjutan)
nah dari situ sistem otomatis mendistribusikan aduan tersebut ke semua
anggota dewan yang berada di dapil tersebut. Jadi memangkas terkait
adanya komisi, fraksi, yang sebenarnya padahal setiap anggota dewan itu
punya kepentingan untuk menarik konstituen di dapil nya untuk
keterpilihannya 5 tahun mendatang.
Jawaban: Ya bener mas, Bisa saja mas bisa saja itu menjadi salah satu
alternatif, jadi biasanya ada pengaduan 100 sampai 200 yang sudah kita
serahkan ke komisinya, dan ketua komisinya sudah tau nih, dan sudah
diumumkan dirapat, tetapi tidak semua, karena ternyata yang
diumumkan cuma 5, jadi perlu juga, kalaupun ini sudah diumumkan,
karena ini ada berdasarkan dapil, ya bisa saja.
20. Jadi sistem ini bisa pak dijadikan salah satu solusi?
Jawaban: Iya bisa dan layak, karena khususnya itu, seperti yang tadi saya
bilang aduan dipilah oleh sekretariat komisi II ada 200 nih, di bawa ke
rapat 50 misalkan, sehingga kemungkinan atau probabilitas dari yang
150 aduan ini ada yang terjadi di dapil nya anggota-anggota di komisi II
ini itu kan ada peluangnya, jadi lewat sistem yang bersangkutan bisa, dan
diposisi fraksi juga iya gitu, kalau dia tidak sesuai dengan kepentingan
fraksi atau partainya itu udah lewat, walaupun disitu umpanya ‘ada dapil
saya nih’, dan walaupun kasus itu kejadiannya di dapil ketua fraksinya,
nah kalau memang fraksinya tidak menilai itu urgent atau tidak perlu
ditindaklanjuti yaudah down dia langsung, padahal seharusnya itu
penting buat keterpilihan dia di periode selanjutnya.
21. Jadi benar ya pak, permasalahan secara umum nya berada di tindak
lanjut?
Jawaban: Iya di tindak lanjut mas, secara umum atau global di tindak
lanjut.
125
UIN Syarif Hidayatullah Jakarta
Lampiran II. Wawancara Ahli
Tujuan : Melakukan validasi terhadap goal model, dan responsibility
yang telah dibuat.
Tempat : Gedung Sekretariat Jenderal dan Badan Keahlian DPR RI
Waktu : Jam 13.35 WIB, Jum’at, 27 September 2019
Durasi : 48 Menit
Narasumber : Bapak Safarudin Surya Lesmana, M.H. (Yadin)
(Kepala Subbagian Analisis Pengaduan Masyarakat II)
Pertanyaan:
1. Pada kesempatan kali ini, saya ingin memvalidasi pemodelan yang telah
saya buat pak, akan tetapi sebelumnya saya ingin mengkonfirmasi
beberapa hal terlebih dahulu. Untuk sistem yang sedang berjalan saat ini
itu adalah www.pengaduan.dpr.go.id ya pak?
Jawaban: Iya, benar
2. Terkait pengguna utama sistem itu Bagian Pengaduan Masyarakat ya Pak?
Jawaban: iya, pengguna utama sistem adalah Bagian Pengaduan
Masyarakat, karena kita ini yang melakukan pengelolaan pengaduan
masyarakat.
3. Jadi seperti ini pak, pada intinya kemarin kan penelitannya adalah
menganalisa terkait sistem yang ada saat ini, dan dianalisa
kesenjangannya dengan sistem yang sesungguhnya diinginkan sama
bagian pengaduan masyarakat, nah kurang lebih hasilnya dibuat ke dalam
model seperti ini pak. Untuk itu, saya ingin validasi kepada Bapak terkait
model yang telah saya buat. Apakah ada yang perlu diperbaiki pak?.
Jawaban: Jadi gini mas, kalaupun ada perkembangan aplikasi, pada
prinsipnya tidak keluar dari tujuan utama yang ini nih di diagram, dan
caranya ada di bawahnya kan, pada asasnya benar seperti ini, cuman
memang aplikasinya saja yang disederhanakan, kalau sekarang kan
berantai, kalau kedepannya pengennya sederhana aja mas aplikasinya,
tetapi tidak keluar dari ini.
126
UIN Syarif Hidayatullah Jakarta
(lanjutan)
4. Baik pak, lalu ini kan pada dasarnya ada perbedaan antara goal dan
kebutuhan sistem saat ini, dengan yang sebenarnya diinginkan. Kalau
yang pada sistem sekarang kan goal utamanya kan itu “Mendukung
kewajiban dan tugas DPR dalam menerima, menampung, dan
menindaklanjuti pengaduan masyarakat” nah kalau untuk sistem yang
seharusnya, saya cek berdasarkan dokumen regulasi itu redaksinya hanya
menampung dan menindaklanjuti, tanpa ada kata “tugas dan menerima”,
karena kalau yang tujuan utama sistem yang sekarang itu saya dapatkan
berdasarkan hasil wawancara, dan yang sesungguhnya itu saya cek
berdasarkan dokumen regulasi yang berlaku, sehingga timbul perbedaan
pak. Kemudian yang kedua, kita juga menambahkan kebutuhan sistem
sesuai dengan apa yang bapak sampaikan sebelumnya, yaitu masyarakat
untuk melihat status pengaduan dapat hanya menginput nama pengadu,
tidak harus dengan nomor tiket. Begitu ya pak?
Jawaban: Ya, jadi misalkan mau pilih salah satu, yang penting asalkan
yang bersangkutan yang tandatangan di dalam surat itu tercatat, jadi saat
dia sebut namanya Budi misalkan, nah itu bisa langsung keluar, tanpa
harus mengetik nomor tiketnya. Kalau untuk yang bagian goal utama ini
kan sebenernya pengertiannya sama ya mas, jadi kan cuma perbedaan
istilah aja, tetapi untuk lebih jelasnya silahkan lihat lagi di UU MD3
terutama yang pasal 81
5. Kemudian pak, terkait fitur memberikan notifikasi kepada sekretariat
masing-masing Anggota DPR, karena pada hasil diskusi kita sebelumnya
antara saya dengan Bapak, ada beberapa Anggota Dewan yang tidak
mengetahui adanya pengaduan masyarakat di daerah pemilihannya
sendiri. Seperti itu benar Pak?
127
UIN Syarif Hidayatullah Jakarta
(lanjutan)
Jawaban: iya benar benar mas, terutama soal ini mas, penulisan
tindaklanjut dari Sekretariat AKD. Jadi kan baik itu sistem yang ada
sekarang atau pengembangannya, setelah pengaduan kita teruskan ke
AKD terkait, kemudian pengaduan tersebut telah mereka tindaklanjuti,
seharusnya Sekretariat AKD menuliskan itu ke dalam aplikasi, supaya
bisa ketauan sebenarnya sudah ditindaklanjuti atau belum.
Ohiya pak perihal itu sudah ada pak di goal model ini, yaitu “Sekretariat
AKD menuliskan hasil tindaklanjut”
Jawaban: nah iya itu benar, karena kalau ini sudah ditulis ke aplikasi, pasti
bukan hanya kita aja yang tau, komisi-komisi atau AKD yang
berhubungan pun tau. Kemudian, yang paling utamanya kita jadi gampang
memberikan informasi kepada pengadu yang bertanya “Mana, gimana,
surat pengaduan saya sudah ditindaklanjuti belum?” nah ini gunanya,
kalau ini sudah ada kan enak, kalau belum ada, kan kita bingung juga
ngasih taunya, disana diapain itu pengaduannya, apakah didiamkan saja,
atau dibawa saja tetapi tidak ditindaklanjuti.
6. Baik pak, berarti ini seluruh pemodelannya sudah aman ya pak?
Jawaban: Iya iya mas, sudah aman.
7. Kemudian pak sebagai informasi tambahan, terkait apabila ada pengaduan
masuk, total berapa lama pak kira-kira prosesnya, waktu yang dibutuhkan
dari sejak surat masuk sampai diteruskan ke AKD pak?
Jawaban: Kalau berdasarkan standard pelayanan minimal, pengaduan
melalui surat tertulis itu 3 x 24 Jam, melalui website itu pada hari yang
sama (karena langsung forward aja), pengaduan secara langsung
ditindaklanjuti pada hari yang sama, pengaduan melalui sms aspirasi
ditindaklanjuti pada hari yang sama (1x24 jam).
128
UIN Syarif Hidayatullah Jakarta
(lanjutan)
8. Selanjutnya pak, untuk jumlah pengaduan yang masuk, setiap hari atau
bulannya berapa ya pak?
Jawaban: Paling dari per masa sidang aja ya mas antara 2-3 bulan, untuk
tertulis itu kira-kira 300, kalau sms bisa 2 kali lipatnya mas yaitu 600,
untuk website itu 250an rata-ratanya. Ohiya itu kan tadi sebelumnya saya
sudah jelaskan terkait aturan standar pelayan minimal, nah ini ada yang
penting perlu saya sampaikan juga nih, terkait UU KIP (keterbukaan
informasi publik) tentang jaminan keamanan dan keselamatan pelayanan,
bahwa identitas pengadu dilindungi kerahasiaannya sama informasi yang
dikecualikan sesuai dengan Undang-undang KIP. Jadi, kalau berdasarkan
hal tersebut, ada yang bisa dibuka oleh instansi pemerintah, ada yang
dikecualikan, ini di Bagian Pengaduan Masyarakat ada hal-hal yang
dikecualikan tidak boleh diberikan ke publik.
9. Kalau untuk kebutuhan penelitian, berarti juga tidak bisa diketahui pak
ya?
Jawaban: Kalau kemarin sih kita ada peneliti dari UI, kita cuma bisa kasih
ini aja jumlah, jadi kaya yang tadi mas Tanya “berapa sih pak pada satu
masa persidangan, berapa yang masuk, terus berdasarkan media apa aja?”
itu bisa, tetapi kalau secara perinci namanya ini si A, terus tinggalnya
disini, materi pengaduannya ini, kita tidak bisa kasih semuanya, karena
berdasarkan aturan itu.
top related