ANALISIS KEBUTUHAN SISTEM PENGADUAN MASYARAKAT...

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

http://www.pengaduan.dpr.go.id/

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


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


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


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


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


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


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


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


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


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


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


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


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


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


(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


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


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


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


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


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


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


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


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


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


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


28


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


29


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


30


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


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”


Gambar 2.8 Hubungan concerns “Alarm Bell”


32


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


33


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


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


35


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


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


37


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


38


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


39


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


40


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


41


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


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


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


44


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


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


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


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


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


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


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


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).


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


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).


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


yaitu Regulations to Goal

Model (R2G)

- Metode pengecekan

konsistensi goal, yaitu Goal

Consistency Checking

(GCC).


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


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



metode yang ada

pada GORE


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



metode yang ada

pada GORE


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


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


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


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


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


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


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


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


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


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


Visi, Misi, Motto, Maklumat Pertanyaan dan Kontak dari Bagian

Pengaduan Masyarakat.

6. Menu Laporan


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


mengenai cara penyampaian pengaduan masyarakat melalui surat.

3. Menu Kirim Pengaduan Datang Langsung


mengenai cara penyampaian pengaduan masyarakat dengan cara

datang langsung atau delegasi masyarakat.

4. Menu SMS Aspirasi

67



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


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


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


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


kontak dari masing-masing Alat Kelengkapan Dewan (AKD)

yang ada di DPR RI. Kontak tersebut berupa alamat email, nomor

telepon, dan juga fax.

68


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


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


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


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


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


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


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


“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


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


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


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


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


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


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


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


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


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


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


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


Gambar 4.15 Goal Model System-as-is

88


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:


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


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


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


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


Badan Keahlian Dewan

DPR RI

Peraturan Sekretaris Jenderal Peraturan Sekretaris

Jenderal DPR RI No. 7

Tahun 2018 tentang

Perubahan Kedua atas

Peraturan Sekretaris


Tahun 2015 tentang

Organisasi dan Tata Kerja


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


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


Badan Keahlian Dewan

DPR RI


Jenderal



Tahun 2018 tentang

Perubahan Kedua atas



Tahun 2015 tentang

Organisasi dan Tata Kerja



R2G-UP3: Penulis menentukan strategic goal dari sistem tersebut yaitu

“Mendukung Kewajiban DPR RI dalam menampung dan

menindaklanjuti pengaduan masyarakat”

94


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


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



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


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


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


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


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


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


Gambar 4.21 Goal Model dari System-to-be

101


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



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


>

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:


>

ALGORITHM

write(aduan)

read (aduan)

aduan

104


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


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:


>



Gambar 4.26 Tampilan Form Input nama pengadu

106


Function DisplayStatus (parameter: String, kata_kunci: String,

aduan_masyarakat: aduan) integer

ALGORITHM:


DisplayStatus (parameter, kata_kunci, aduan_masyarakat)


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


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

email

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:


>


selected_email : String


108


Function get_email(aduan_masyarakat, kata_kunci: String,)

String

Function Kirim_Aduan (selected_email: String,

aduan_masyarakat: aduan ) integer

ALGORITHM:


selected_email get_email(kata_kunci)

Kirim_Aduan (selected_email, aduan_masyarakat)


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


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


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


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


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


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


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


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


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


(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


(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


(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


(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


(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


(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


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


(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


(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


(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.

ANALISIS KEBUTUHAN SISTEM PENGADUAN MASYARAKAT...

Documents

Transcript of ANALISIS KEBUTUHAN SISTEM PENGADUAN MASYARAKAT...