0% found this document useful (0 votes)
1K views28 pages

User Requirement Assessment

Sistem informasi merupakan serangkaian kegiatan yang terdiri dari pengumpulan data, yang kemudian memprosesnya menjadi informasi, menyimpan, menganalisis, dan diseminasi informasi untuk sebuah aplikasi dengan tujuan khusus. Aplikasi sistem informasi terdiri dari hardware, software, data, people, policy, procedure, network, dan environment. Manajemen sistem informasi berarti sebuah sistem informasi manajerial yang hasilnya dijadikan sebagai dasar dari pengambilan keputusan.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1K views28 pages

User Requirement Assessment

Sistem informasi merupakan serangkaian kegiatan yang terdiri dari pengumpulan data, yang kemudian memprosesnya menjadi informasi, menyimpan, menganalisis, dan diseminasi informasi untuk sebuah aplikasi dengan tujuan khusus. Aplikasi sistem informasi terdiri dari hardware, software, data, people, policy, procedure, network, dan environment. Manajemen sistem informasi berarti sebuah sistem informasi manajerial yang hasilnya dijadikan sebagai dasar dari pengambilan keputusan.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 28

TUGAS SISTEM INFORMASI KESEHATAN DAN RUMAH SAKIT

USER REQUIREMENT ASSESSMENT

DISUSUN OLEH:
KELOMPOK 2
AJ IKM PEMINATAN AKK

ARFELLA DARA TRISTANTIA (101511123021)


ARINDA ZAHRA PUSPITASARI (101511123032)
ELLY NUMA ZAHROTI (101411123085)

FAKULTAS KESEHATAN MASYARAKAT


UNIVERSITAS AIRLANGGA
SURABAYA
2017
DAFTAR ISI

DAFTAR ISI

BAB I USER REQUIREMENT ASSESSMENT...................................... 2


1.1. Definisi User Requirement Assessment................................ 2
1.2. Tujuan User Requirement Assessment.................................. 6
1.3. Proses User Requirement Assessment.................................. 7
1.4. Prinsip User Requirement Assessment................................. 7
1.5. Jenis User Requirement Assessment..................................... 9
BAB II UNSUR USER REQUIREMENT ASSESSMENT....................... 12
2.1. Knowledge Management...................................................... 12
2.2. Collaboration....................................................................... 13

2.3. Decision Making................................................................... 13


BAB III METODE USER REQUIREMENT ASSESSMENT................... 14
3.1. Interview............................................................................... 14
3.2. Focus Group......................................................................... 21
3.3. Online Survey....................................................................... 25
3.4. Observation.......................................................................... 26
BAB V CONCLUSION................................................................................ 27

DAFTAR PUSTAKA
BAB I
USER REQUIREMENT ASSESSMENT

Sistem informasi merupakan serangkaian kegiatan yang terdiri dari


pengumpulan data, yang kemudian memprosesnya menjadi informasi,
menyimpan, menganalisis, dan diseminasi informasi untuk sebuah aplikasi dengan
tujuan khusus. Aplikasi sistem informasi terdiri dari hardware, software, data,
people, policy, procedure, network, dan environment. Manajemen sistem
informasi berarti sebuah sistem informasi manajerial yang hasilnya dijadikan
sebagai dasar dari pengambilan keputusan.
Di sistem informasi manajemen, people (manusia) berlaku sebagai pengguna
sistem informasi dan menjadi aktor utama dalam mengoperasikan sistem
infomasi. Keahlian dan kepentingan pengguna dalam mengoperasikan sistem
informasi sangat penting agar sistem informasi tersebut menjadi efektif dan
efisien bagi organisasi. Maka, sebelum menentukan teknologi apa yang akan
digunakan untuk sistem informasi di dalam perusahaan, perlu dilakukan analisis
dan penilaian kebutuhan pengguna terlebih dahulu.

1.1 Definisi User Requirement Assessment


User Requirement Assessment memiliki beberapa komponen yang terjabar
sebagai berikut:
1. User/Pengguna Informasi
User/pengguna merepresentasikan pengguna akhir sistem tetapi dapat
diperluas untuk mencakup semua orang yang terlibat dalam sistem, seperti
jaringan dan sistem, administrator dan manajemen.
User/Pengguna Sistem Informasi Manajemen adalah orang yang
melakukan suatu pekerjaan yang berhubungan dengan sistem informasi
manajemen. Pengguna Sistem Informasi Manajemen adalah orang yang
menggunakan atau memanfaatkan sistem informasi manajemen (Zakiyudin,
2014).

2
User/Pengguna dan pelaku sistem informasi manajemen dibagi menjadi 3
kelompok yang terdiri dari (Zakiyudin, 2014):
a. Manajer
1) Manajer Puncak (Top Manager) yang bertugas sebagai perencana
strategis, bertanggung jawab atas keseluruhan manajemen dalam sebuah
organisasi.
2) Manajer Garis Menengah (Middle Manager) yang bertugas sebagai
pengendali manajemen, dapat mencakup lebih dari satu tingkatan dalam
sebuah organisasi.
3) Manajer Garis Pertama (First Line) yang bertugas sebagai pengendali
operasional, dan merupakan tingkatan manajer paling rendah dalam
sebuah organisasi, bertanggung jawab atas pekerjaan orang lain.
b. Non Manajer
Pengguna Non Manajer adalah Karyawan. Karyawan adalah sumber daya
manusia yang merupakan penggerak utama sebuah perusahaan. Tanpa
karyawan maka sebuah perusahaan tidak akan berjalan dengan baik,
karena tidak semua pekerjaan manusia dapat digantikan dengan mesin.
c. Orang-orang yang ada di lingkungan organisasi
1) Supervisor adalah seseorang yang menangani orang-orang yang
memproduksi atau melakukan kinerja pelayanan.
2) Pimpinan prorgram adalah seseorang yang menerima tanggung jawab
untuk mengelola sebuah program
Menurut Sabarguna (2003), pengguna dalam SIMRS dibagi dalam
beberapa kategori, yaitu:
a. "End User" yaitu individu yang pekerjaannya mencakup kreasi,
pemrosesan dan distribusi dari informasi, mencakup operator komputer,
supervisor, seluruh pihak manajemen.
b. Pelanggan, yaitu individu yang menjadi objek dari SIM, mencakup para
pasien yang datang berkunjung ke Rumah Sakit.

3
2. Requirement
Requirement adalah spesifikasi dari apa yang harus diimplementasikan,
deskripsi bagaimana sistem harusnya bekerja atau bagian-bagian yang ada di
dalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem
(Sommerville, 2001).
Requirement (kebutuhan) adalah pernyataan yang mengidentifikasikan
kebutuhan penting dalam sistem dan didalamnya mencakup aspek kebenaran,
realistis, dibutuhkan tidak membingungkan dan terukur.
Dari pengertian diatas dapat disimpulkan bahwa requirement
merupakan proses menggambarkan kebutuhan, spesifikasi, bagian-bagian dan
batasan yang dibutuhkan dalam melaksanakan sebuah sistem.
3. Assessment
Assessment adalah proses pengumpulan bukti untuk dapat dilakukan
suatu penilaian. Dalam menilai kinerja, penilaian dilakukan untuk
mengetahui apakah kompetensi telah dicapai dan mengonfirmasi bahwa
seorang individu dapat melakukan pekerjaan dengan standar yang dibutuhkan
di tempat kerja (Standards for Registered Training Organisations, 2015).
Sedangkan assessment dalam sistem informasi merupakan proses
pengumpulan bukti, data, requirements, yang dilakukan terhadap user untuk
mengetahui kebutuhan user akan sebuah teknologi sistem informasi.
4. User Requirement
User Requirements adalah hal yang penting untuk membangun dan
mendokumentasikan kebutuhan pengguna sehingga mereka mengarah ke
proses perancangan sistem itu sendiri. kebutuhan pengguna akan mencakup
deskripsi ringkasan dari tugas-tugas yang sistem akan mendukung dan fungsi
yang akan diberikan untuk mendukung mereka (Maguire, 1998).
User Requirement (kebutuhan pengguna) yaitu pernyataan tentang
layanan yang disediakan sistem dan tentang batasan-batsan operasionalnya,
dapat dilengkapi dengan gambar atau diagram yang dapat dimengerti dengan
mudah (Sommerville, 2001).

4
Understanding user requirements is an integral part of information
systems design and is critical to the success of interactive systems. It is now
widely understood that successful systems and products begin with an
understanding of the needs and requirements of the users (Maguire, 2002).
User requirement diartikan sebagai sekumpulan requirement yang
dikumpulkan atau diturunkan dari user input dan merepresentasikan apa yang
dibutuhkan oleh user untuk suksesnya pekerjaan mereka dalam sistem.
5. User Requirement Assessment
Di dalam proses pengembangan sistem informasi, terdapat salah satu
tahap yaitu requirement analysis, yang dilakukan untuk mengetahui
spesifikasi kebutuhan user terkait sistem informasi seperti apa yang
diinginkan. Tahap tersebut merupakan tahapan yang secara paralel dilakukan
dalam user requirement assessment. Hal itu berarti, penilaian data, bukti,
requirements milik pengguna memerlukan analisis sehingga dapat
diinterpretasi dan disimpulkan.
User Requirement Analysis dilakukan untuk mengoptimalkan
persyaratan kinerja untuk fungsi identifikasi, dan untuk memverifikasi bahwa
solusi dapat memenuhi kebutuhan pelanggan (Gregor v. Bochmann, 2009).
User Requirement Analysis perlu dilakukan karena sulit untuk
mendapatkan kesepakatan (skeptical) pemakai tentang kebutuhan mereka dari
sebuah sistem informasi, karena mungkin pemakai mengalami kegagalan
sistem informasi sebelumnya.
User Requirement Analysis dilakukan untuk menjelaskan sistem saat
ini secara lengkap, menggambarkan sistem informasi yang ideal, membawa
sistem informasi yang ideal ke kondisi saat ini dengan memperhatikan
kendala sumber daya, memberi dorongan terhadap keyakinan pemakai ke
dalam team pengembangan sistem.
User requirements analysis adalah proses memberikan deskripsi yang
tepat dari konten, fungsi dan kualitas yang diminta oleh calon pengguna.
User requirements adalah dasar dari pendekatan pengguna untuk
menciptakan produk yang menarik.

5
Kesimpulannya, user requirement assessment dapat diartikan sebagai
proses pengumpulan bukti dan membuat penilaian terhadap sekumpulan
requirement yang mencakup deskripsi ringkasan dari tugas-tugas yang yang
dibutuhkan oleh user untuk suksesnya pekerjaan mereka dalam suatu sistem.

1.2 Tujuan User Requirement Assessment


Analisis kebutuhan pengguna memberikan deskripsi yang tepat dari
konten, fungsi dan kualitas yang diminta oleh calon pengguna.
Mengembangkan produk dan layanan yang memenuhi harapan pengguna dan
pelanggan adalah penting untuk keberhasilan, terutama saat ini bahwa
perusahaan yang berorientasi teknologi menghadapi persaingan yang kuat atas
dasar kualitas. analisis kebutuhan adalah dasar dari pendekatan berpusat
pengguna, menciptakan produk yang menarik dan perlu bertemu pengguna di
tingkat paling dekat. (Brown, Richard et al, 2006)
Analisis memberikan kita pemahaman konseptual dari sebuah sistem
dilihat dari sudut pandang logis dengan merinci nya secara fungsional.
Memberi kita banyak informasi tentang sifat fungsional dari sistem, karenanya
sangat penting untuk menganalisis kebutuhan dengan tepat sehingga tidak ada
kesenjangan analisis. (Bagchi, 2010) Adapun tujuan lain dari Requirement
Analysis (Bochmann, 2010) adalah:
1. Menentukan batasan dari sistem baru (atau software) dan bagaimana
sistem tersebut harus dapat berinteraksi dengan lingkungannya.
2. Mendeteksi dan menyelesaikan konflik antar kebutuhan pengguna
3. Negosiasi prioritas dari stakeholders
4. Memprioritaskan dan mengelompokkan kebutuhan
5. Mendefinisikan dokumen kebutuhan yang spesifik, sehingga manajer
dapat memberikan estimasi proyek yang realistis dan developer dapat
merancang, menguji dan mengimplementasikan sistem.
6. Mengklasifikasikan informasi terkait kebutuhan ke dalam berbagai
kategori dan mengalokasikan kebutuhan untuk sub-sistem.
7. Mengevaluasi kebutuhan untuk kualitas yang diinginkan.

1.3 Proses User Requirement Assessment

6
Kebutuhan user akan sebuah sistem informasi yang sesuai dengan
pekerjaannya, berangkat dari masalah user terhadap penggunaan software,
hardware, network, data, kebijakan, prosedur dan atau lingkungannya.
Sehingga, hal yang pertama kali dilakukan adalah identifikasi masalah user,
dilanjutkan dengan evaluasi jenis dan kebutuhan user, yang dirangkum ke
dalam dokumen kebutuhan untuk selanjutnya dijadikan bahan sebagai
pengambilan keputusan.

(Sommerville, 2004)
Gambar 1.1 Proses Rekayasa Kebutuhan

1.4 Prinsip User Requirement Assessment


Prinsip-prinsip kunci yang mendasar pada analisis adalah:
1. Informasi domain dari masalah harus menjadi perhatian. Ini berarti bahwa
domain informasi dimana masalah beroperasi harus dihargai (The
information domain of the problem is to be given due regard. This means
that the domain of the information in which the problem operates has to be
appreciated)
2. Fungsi utama dari sistem telah didefinisikan dan kunci fungsional dari
sistem harus jelas. (the key function of the system have to be defined and
the key functionally of the system has to be defined clearly)

7
3. Sistem harus modular. Hal ini diperlukan untuk membantu menciptakan
sistem dengan cara yang lebih cepat. (System must be modular. This is
required to help create the system in a faster way)
4. Sistem harus didefinisikan secara abstrak karena ini adalah akan
membantu mengurangi kompleksitas. (System has to be defined in abstract
terms as this is will help reduce complexcity)
5. Mengurangi ambiguitas. Ambiguitas dalam sistem harus dikurangi untuk
memungkinkan desainer untuk fokus pada hasil yang jelas. (Reduce
ambiguity. The ambiguity in the system must be reduced to enable designer
to focus on the outcome clearly)
Menurut Bagchi (2010), Pada saat memulai proses elisitasi kebutuhan
dan analisis, beberapa isu utama harus dipahami agar proses analisis lebih
mudah. Hal yang harus diketahui dari pihak developer adalah:
1. Orang-orang utama yang mendorong permintaan. Ini akan membantu
untuk memfokuskan informasi dari kumpulan orang-orang ini sehingga
sifat sebenarnya dari kebutuhan menjadi jelas.
2. Orang-orang penting yang akan menggunakan sistem. Hal ini memberikan
pemahaman kepada tim developer tentang profil pengguna.
3. Pemahaman tim elisitasi tentang keuntungan finansial yang sedang
diharapkan dari solusi ini.
4. Apa yang menurut pengguna adalah solusi terbaik? Hal ini memberikan
tim gambaran tentang harapan pengguna dari sistem.
5. Apa masalah yang akan sistem tangani? Ini memberikan alasan bagi tim
untuk pengembangan sistem.

1.4 Jenis Analisis Kebutuhan


1. Functional Requirement
Tujuan yang ingin pengguna capai dan tugas-tugas mereka yang
akan dilakukan dengan software baru harus ditentukan. Dengan mengenali
persyaratan fungsional, kita memahami tugas-tugas yang melibatkan
abstraksi mengapa pengguna melakukan kegiatan tertentu, apa kendala dan
preferensi, dan bagaimana pengguna akan membuat keseimbangan antara

8
aplikasi software dengan perbedaan produk. Bagaimana input/outout-nya,
prosesnya dan error handling nya.
2. Non-Functional Requirement
Kebutuhan non-fungsional adalah atribut yang baik sistem atau
lingkungan harus memiliki. Beberapa adalah persyaratan yang stakeholder
inginkan, dan beberapa persyaratan yang pengguna akhir diperlukan.
Berikut ini daftar persyaratan non-fungsional dan deskripsinya (diadaptasi
dari McEwen, Scott, Metasys Technologies, IBM DeveloperWorks,
Requirements: An Introduction, 2004):
a. Usability, menggambarkan kemudahan yang sistem dapat dipelajari
atau gunakan. Sebagai contoh:
Sistem harus cukup intuitif untuk memungkinkan pengguna baru
untuk mempelajari operasi dasar dalam satu hari penggunaan.
Pengguna akhir akan dapat mengakses halaman apapun dengan
waktu respon sub-kedua dan tidak akan diminta untuk pindah ke
lebih dari dua layar untuk menyelesaikan tugas.
b. Reliability, menggambarkan sejauh mana sistem harus bekerja untuk
pengguna. Spesifikasi untuk keandalan biasanya mengacu pada
ketersediaan, downtime, waktu untuk memperbaiki, akurasi, dll.
Sebagai contoh:
Dengan pengecualian dari bencana besar yang menonaktifkan
seluruh wilayah sistem, kita akan memiliki redundansi lokal dan
remote cukup untuk mematikan semua sistem non-kritis. Semua
sistem kritis akan berjalan pada generator cadangan atau daya
baterai lokal untuk setidaknya empat jam.
c. Performance Specification, biasanya mengacu pada waktu respon,
jalannya transaksi, dan kapasitas. Sebagai contoh:
Pada saat pencarian daftar obat, sistem harus mampu menampilkan
20 hasil per halaman.
d. Supportability, mengacu pada kemampuan aplikasi untuk dengan
mudah dimodifikasi atau dipertahankan untuk mengakomodasi
penggunaan khas atau mengubah skenario. Sebagai contoh:
Sistem ini akan memungkinkan pengguna untuk membuat alur
kerja baru tanpa perlu pemrograman tambahan.

9
Sistem ini akan memungkinkan analis operasi untuk memodifikasi
aturan dukungan keputusan klinis setelah mendapat persetujuan.
e. Interoperability, mengacu pada kemampuan satu aplikasi untuk
bertukar data dengan yang lain. Interoperabilitas membutuhkan adopsi
standar yang memungkinkan antarmuka yang akan ditulis.
Interoperabilitas juga dapat menggabungkan konsep konektivitas,
pesan, dan portal interaktif. Sebagai contoh:
Sistem harus dapat berinteraksi dengan sistem penagihan.
Portal penyedia tersedia untuk memberikan pengawasan layanan
antara rumah sakit dengan kantor dokter.
f. Scalability, umumnya mengacu pada kemampuan untuk meningkatkan
jumlah pengguna atau aplikasi yang berhubungan dengan produk.
g. System Requirement, umumnya termasuk sistem operasi, alat
pengembangan perangkat lunak, hardware atau persyaratan khusus
platform, dan persyaratan lingkungan.
h. Legal/Regulatory, mencakup kemampuan untuk menghasilkan
representasi penerimaan dari catatan hukum kesehatan, hak kekayaan
intelektual, kepatuhan dengan persyaratan telekomunikasi, dan fitur
lainnya. Persyaratan ini merupakan fokus penting untuk organisasi
kesehatan. Sistem ini harus mampu mendukung pembaruan ke proses
pengumpulan data yang dibutuhkan, aturan untuk peninjauan
peraturan, dan kode set baru.
i. Security, mengacu pada kemampuan untuk menyediakan kerahasiaan,
integritas data, dan ketersediaan data. Sebagai contoh:
Otentikasi pengguna ke beberapa aplikasi akan diaktifkan oleh
single sign on teknologi.
Dokter yang tidak memiliki hubungan pengobatan dengan klien
akan diizinkan untuk mengakses informasi kesehatan klien yang
dilindungi melalui fungsi break-the-glass hanya dalam keadaan
darurat yang harus didokumentasikan dan hanya dengan log audit
terpisah yang dihasilkan.

10
BAB II
UNSUR USER REQUIREMENT ASSESSMENT

Identifikasi dan penilaian kebutuhan user merupakan sebuah usaha untuk


dapat mengerti apa yang dibutuhkan dan diinginkan oleh user untuk dapat bekerja,
sehingga dapat ditentukan software dan arsitektur yang sesuai (Bilal, 2014).
User Requirement Assessment dalam merencanakan sebuah fasilitas,
seperti pengadaan atau pengembangan sistem informasi dan teknologi, didasari
oleh tiga unsur yang terintegrasi (Hassan, 2013), yaitu:
1.1 Knowledge Management
Pengumpulan data, informasi dan pengetahuan merupakan salah satu
proses perencanaan yang harus dilakukan agar dapat melakukan identifikasi
masalah, menentukan tujuan dan rencana alternatif, sehingga dapat diambil
suatu keputusan. User requirements, dalam hal ini, merupakan pengetahuan

11
yang perlu didokumentasikan oleh para perencana pengadaan fasilitas,
sehingga dapat dimengerti bagaimana nantinya suatu fasilitas atau sarana
akan digunakan oleh users, sebelum fasilitas tersebut akan di-design dan
dibangun. Sehingga, serangkaian knowledge management kompleks yang
tergambar dalam gambar 1 perlu dilakukan.

(Turban, 2001)
Gambar 2.1. Model Sistem Knowledge Management

1.2 Collaboration
Terdapat banyak pihak yang akan dilibatkan dalam proses
perencanaan fasilitas sistem informasi dan teknologi, seperti developer,
engineer, consultant, dan manajer. Para profesional tersebut memiliki fungsi
tersediri dan berbeda satu sama lain. Dibutuhkan suatu kolaborasi terutama
dalam komunikasi, karena komunikasi diantara anggota dengan latar
belakang, pengetahuan, talenta dan interest yang berbeda seringkali
menyebabkan miscommunication.
1.3 Decision Making
Komunikasi dan kolaborasi sangatlah penting, namun prosedur dan
strategi dalam pengambilan keputusan juga sama penting dalam pencapai
tujuan perencanaan. Diperlukan petunjuk prosedural dalam pengambilan
keputusan. Para perencana perlu mendiskusikan rencana terbaik dari seluruh
alternatif, dengan users dan stakeholders.
Ketiga unsur tersebut menjadi latar belakang dalam melakukan
penilaian terhadap kebutuhan user sehingga dapat dibuat perencanaan fasilitas

12
yang user-based evidence. Serangkaian usaha tersebut akan menghasilkan
suatu dokumen perencanaan disebut project brief yang tergambar dalam
gambar 2.

(Hassan, 2013)
Gambar 2.2 Conceptual Framework in Project Briefing Process
BAB III
METODE USER REQUIREMENT ASSESSMENT

Menilai user requirements atau kebutuhan userdapat dilakukan dengan


metode kuantitatif dan kualitatif. Metode kuantitatif bertujuan untuk
mengumpulkan data numerik, di saat metode kualitatif menargetkan ide,
komentar, opini dan saran dari user atas situasi dan kondisi tertentu. Salah satu
teknik yang digunakan dalam metode kuantitatif adalah observasi secara langsung
dan tidak langsung, sedangkan salah satu teknik metode kualitatif adalah
wawancara (Bilal, 2014). Berikut merupakan beberapa metode yang dapat
digunakan dalam mengumpulkan user requirements;

3.1 Interview
Metode ini merupakan metode yang dapat memberikan user-centered
requirements bagi assessor atau analis, namun membutuhkan lebih banyak
waktu karena diperlukan perencanaan material dan instrumen wawancara,
subjek atau target wawancara, pengumpulan data, dan analisis data sehingga
akhirnya hasilnya dapat dilaporkan.
1. Persiapan untuk Melakukan Wawancara

13
a. Identifikasi Tujuan
Pertanyaan untuk wawancara bisa dikembangkan dan mudah untuk
menambahkan lebih banyak pertanyaan sebagai pemangku kepentingan atau
stakeholders. (Tim produk, manajemen, mitra). Bagi setiap orang penting
untuk menyetujui maksud dan tujuan dari penelitian awal, termasuk dalam
penulisan proposal ke stakeholder dan ditandatangani oleh semua pihak.
Pewanwancara dan para pemangku kepentingan menentukan jenis wawancara
untuk melakukan dan pertanyaan brainstorming untuk wawancara,
menggunakan tujuan penelitian sebagai panduan. Jika jenis wawancara yang
disarankan atau pertanyaan yang ditawarkan tidak sesuai dengan tujuan yang
telah disepakati, permintaan harus ditolak. Hal ini jauh lebih mudah
dilakukan setelah proposal telah ditandatangani, bukan yang mencoba untuk
mendapatkan kesepakatan melalui proses.
b. Tentukan Jenis Wawancara
Ada tiga jenis utama dari satu-satu wawancara:
1. Tidak terstruktur (atau open-ended)
Pewawancara akan memulai dengan inti topik tapi akan memungkinkan para
peserta untuk masuk ke setiap titik dengan sebanyak atau sedikit detail seperti
yang diinginkan. Pertanyaan atau topik diskusi yang terbuka membuat peserta
bebas untuk menjawab dengan cara apapun, dan topik tidak harus dibahas
dalam setiap waktu tertentu. Jenis data yang diterima dengan jenis
unstructured adalah kualitatif.
Kelebihan dalam jenis ini yaitu kaya akan data, kemampuan untuk
menindaklanjuti dan mempelajari lebih pada pertanyaan, fleksibel, berguna
ketika tidak tahu jawaban yang diharapkan.
Sedangkan kekurangan dalan jenis ini yaitu sulit untuk menganalisis, tindak
lanjut pertanyaan yang mungkin tidak konsisten di seluruh peserta, peserta
dapat mencegah atau menutupi segala sesuatu yang mungkin pewawancara
tertarik akan hal tersebut, bagi peserta yang pasif mungkin tidak memberikan
informasi yang cukup.
2. Terstruktur
Jenis terstruktur adalah jenis yang paling terkontrol. Wawancara dapat terdiri
dari pertanyaan-pertanyaan tertutup dan peserta harus memilih dari pilihan
yang disediakan. Peserta dapat terbuka jika diminta, tetapi pewawancara tidak

14
akan menyelidiki tanggapan peserta untuk lebih detail atau mengajukan
pertanyaan yang tidak tercantum pada daftar pertanyaan. Jenis wawancara ini
mirip dengan melakukan survei secara lisan dan digunakan oleh organisasi
seperti Biro Sensus dan Biro Statistik Tenaga Kerja. Jenis data yang diterima
adalah kuantitatif.
Kelebihan jenis ini yaitu lebih cepat untuk menganalisis, pertanyaan yang
diajukan adalah konsisten di seluruh peserta, biasanya pewawancara dapat
meminta lebih banyak pertanyaan daripada dalam sebuah wawancara
terstruktur.
Kekurangan dalam jenis ini yaitu pewawancara mungkin tidak mengerti
alasan dari jawaban peserta karena peserta tidak diberi kesempatan untuk
menjelaskan pilihan mereka.
3. Semi Terstruktur
Semi terstruktur jelas sekali merupakan kombinasi jenis terstruktur dan tidak
terstruktur. Wawancara dimulai dengan serangkaian pertanyaan untuk
menjawab (tertutup dan terbuka) tapi menyimpang dari yang ditetapkan dari
waktu ke waktu pertanyaan. Jenis data yang dihasilkan adalah kombinasi.
Kelebihan pada jenis ini yaitu mampu menyediakan data kuantitatif dan
kualitatif, memberikan beberapa detil dan kesempatan untuk menindaklanjuti
jawaban.
Kekurangan pada jenis ini yaitu butuh beberapa waktu tambahan untuk
menganalisis komentar peserta, peserta tidak sekonsisten wawancara
terstruktur.
c. Putuskan Cara Analisis data
Sebelum melakukan wawancara, putuskan dahulu cara analisis data yang
akan dilakukan setelah wawancara selesai. Analisis hasil wawancara jarang
menggunakan elektronik karena perlu kemampuan untuk menggunakan alat
tersebut.
d. Susun Pertanyaan
Identifikasi semua pertanyaan untuk wawancara. Pada awalnya bisa
melakukan brainstorming dengan semua pemangku kepentingan (anggota tim
produk, kelompok kegunaan, pemasaran). Kemungkin akan berakhir dengan
pertanyaan-pertanyaan yang keluar dari ruang lingkup kegiatan yang
diusulkan, atau pertanyaan yang terbaik dijawab oleh kegiatan lain.
e. Uji Pertanyaan Anda

15
Baik di atas meja (uji coba bukan di lapangan) maupun di lapangan. Uji coba
bukan di lapangan dimaksudkan untuk mengecek validitas isi pedoman
sedangkan uji coba lapangan untuk mengecek pemahaman peserta terhadap
kata-kata yang sulit dimengerti, bahasa yang digunakan, maksud isi
pertanyaan, serta reaksi peserta terhadap wawancara tersebut.
Jumlah peserta dalam uji coba lapangan ini sekitar 10 sampai 20 orang dan
berasal dari.populasi yang sama dengan sampel studio Jika ada pertanyaan
yang enggan dijawab oleh kedua puluh peserta maka pertanyaan tersebut
harus ditinjau kembali. Perlu diidentifikasi apakah yang salah cara
mengkomunikasi-kannya, atau peserta kurang termotivasi, atau prosedur
wawancaranya tidak tepat, atau mungkin cara pengungkapannya keliru
sehingga perlu diubah. Untuk menjamin kelancaran wawancara,maka
beberapa cara memulai wawancara harus dicobakan dan digunakan.
f. Pemain dalam Wawancara
1. Pewawancara
2. Peserta
3. Notulen
4. Videografer
g. Mengundang Pengamat (observer)
Seperti dengan teknik kegunaan lainnya, direkomendasikan untuk memiliki
peninjau atau pengamat (rekan kerja, anggota tim produk) di ruangan yang
sama dengan peserta selama wawancara. Jika tidak memiliki fasilitas untuk
memungkinkan seseorang untuk mengamati wawancara dari ruangan lain,
tetapi bisa menginginkan pemangku kepentingan untuk hadir, yang terbaik
adalah untuk membatasi pengamat sekitar satu atau dua individu. Jumlah
pengamat yang berlebihan dapat mengintimidasi peserta.
h. Bahan aktivitas
Bahan yang digunakan dalam wawancara yaitu:
1) Protokol
2) Daftar pertanyaan untuk wawancara
3) Alat untuk pencatatan (laptop dan/ atau kertas dan pensil)
4) Tempat yang nyaman untuk peserta, pewawancara, notulen, alat-alat untuk
perekam.

2. Pelaksanaan Wawancara

16
Pelaksanaan wawancara membutuhkan keahlian dan latihan. Wawancara
membutuhkan alur waktu yang jelas agar wawancara bisa berjalan dengan
baik.
a) Lima Tahapan Wawancara
a. Introduction
Pendahuluan tidak dilakukan terlalu lama, dimulai dari perkenalan diri
pewanwancara dan pengamat di dalam ruangan. Jika ada orang lain yang ada
di dalam ruangan, perkenalkan agar peserta tidak terganggu saat dilakukan
wawancara. Jelaskan tujuan dari wawancara dan kenapa peserta mengikuti
wawancara, sebelumnya izin terlebih dahulu jika wawancara tersebut
direkam. Persetujuan dilakukan setelah menjelaskan tujuan serta rahan dari
wawancara. Ucapan terima kasih kepada peserta karena telah menyediakan
waktunya untuk berpartisipasi.
b. Warm Up
Pemanasan yaitu tahapan yang dilakukan dalam wawancara dengan
menanyakan pertanyaan-pertanyaan yang mudah sebelum memasuki inti
pertanyaan.
c. Body of the session
Inti dari sesi wawancara dimulai dari pertanyaan secara umum kemudian
menanyakan hal yang detail secara satu persatu dan jelas. Sesi ini harus
menjadi jawaban yang dominan (sekitar 80%) dari waktu wawancara dengan
peserta.
d. Cooling-off
Peserta mungkin telah intens dengan pertanyaan yang sangat rinci. Pada titik
ini, pewawancara mungkin ingin menarik kembali dan mengajukan
pertanyaan yang lebih umum atau meringkas wawancara. Waktu dalam
tahapan ini adalah sekitar 5 Hingga 10 menit.
e. Wrap Up
Pewawancara harus menunjukkan bahwa wawancara telah berakhir. Beberapa
orang suka melakukan hal ini dengan menutup notebook dan menempatkan
pena mereka, mengubah posisi tempat duduk mereka, atau mematikan tape
recorder. Ini adalah saat yang tepat untuk meminta peserta untuk menayakan
sesuatu terkait wawancara. Ucapan terima kasih diberikan kepada peserta atas
waktunya, dan kompensasi peserta untuk keahlian mereka, sebagaimana
disetujui sebelumnya.

17
Tabel 3.1 Perkiraan Durasi Waktu Wawancara
Perkiraan Durasi Waktu Prosedur
5-10 menit Pendahuluan (menyambut responden,
melengkapi formulir, memberikan
arahan)
5-10 menit Pemanasan dengan memberikan
pertanyaan ringan
85-100 menit Inti dari wawancara. Menanyakan
detail pertanyaan sesuai dengan
daftar pertanyaan
5-10 menit Pendinginan dengan merangkum dan
menanyakan pertanyaan ringan atau
penutu
5 menit Penutup dengan cara mengucapkan
terima kasih dan menuntun
responden untuk keluar dari lokasi

b) Peran sebagai Pewawancara


Wawancara merupakan aktifitas yang intens utuk pewawancara, walaupun
peserta menyediakan informasi yang dibutuhkan, pewawancara tidak boleh
pasif. Pewawancara membantu peserta dalam memberikan informasi dan
merupakan tugas pewawancara menggali informasi tersebut. Ketika peserta
sedang menjelaskan, pewawancara jangan memotong penjelasan tersebut
walaupun sangat antusias untuk mengetahui lebih akan informasi yang
disampaikan. Berikan waktu kepada peserta untuk menyelesaikan
penjelasannya hingga selesai, pewawancara mengikuti penjelasannya, ketika
informasi tidak ada dalam penjelasannya, pewawancara menanyakan kembali
atau memperjelas pertanyaan agar peserta mampu memebrikan informasi
yang dibutuhkan sesuai pertanyaan yang disampikan.
Pewawancara mampu memberikan contoh untuk memperjelas pertanyaan bila
peserta kesulitan dalam menjawab pertanyaan.
c) Pemantauan Hubungan dengan Peserta
Wawancara adalah tentang memberi dan menerima informasi, karena
berhadapan dengan sumber secara pribadi dan biasanya perindividu. Agar

18
mendapatkan hasil maksimal, penting untuk memantau hubungan dan
memperlakukan peserta secara etis. Pastikan bahwa peserta nyaman, terlibat,
dan percaya. Jika peserta merasakan pewawancara tidak jujur atau tidak
memotivasi peserta untuk menjawab dibalik pertanyaan, peserta tidak akan
memberikan secara jelas apa yang pewawancara inginkan dari pertanyaan.
Perhatikan gerakan tubuh peserta untuk mengetahui apakah peserta merasa
tertekan terhadap pertanyaan atau tidak, jika merasa tertekan atau tegang
maka peserta akan sulit menjelaskan detail jawaban dari pertanyaan yang
diberikan oleh pewawancara.
Saat Wawancara berlangsung, tahan emosi dan usahakan untuk mengontrol
rasa persaingan anatar peserta dan pewawancara. Seringkali terdapat peserta
yang sulit untuk memberikan jawaban yang detail.
d) Analisis Data dan Interpretasi
Data yang ada dianalisis setelah setiap wawancara. Jika keputusan untuk
menganilisis atau menunda analisis data wawancara, maka kemungkinan akan
lupa dengan jalannya sesi wawancara. Catatan yang ada tidak terlalu
membantu untuk menginterpretasikan informasi yang didapat, dan akan
membutuhkan waktu lagi jika melihat rekaman video wawancara. Analisis
data dilakukan dengan mengkategorikan jawaban hasil wawancara, kemudian
membuat diagram dari hasil tersebut untuk memudahkan dalam
menginterpretasikan hasil wawancara, kemudian gunakan alat untuk analisis
membantu menganilisis jawaban.
Sebelum hasil temuan dikomunikasikan atau disampaikan kepada
stakeholders, hasil temuan diprioritaskan terlebih dahulu. Selanjutnya
membuat presenatsi efektif, menuliskan laporan yang memiliki nilai untuk
pendengar yang berbeda, dan memastikan penggabungan hasil temuan sesuai
dengan tujuan awal.
(Courage and Baxter, 2015)

1.2 Focus Group Discussion


Focus Group Discussion adalah sebuah diskusi interaktif yang terdiri dari
enam hingga delapan, dipimpin oleh moderator terlatih dan fokus terhadap isu
spesifik. Tujuan dari Focus Group Discussion adalah untuk mendapatkan berbagai

19
pandangan tentang topik dimana durasinya 60-90 menit, dan untuk menciptakan
sebuah lingkungan yang nyaman agar peserta mampu mengeskpresikan
pandangan mereka. (Hennink, 2014)
1. Karakteristik Focus Group Discussion
a. Terdiri dari 6-8 peserta, tetapi bisa antara 5-10 peserta tergantung pada
tujuan dari kajian.
b. Peserta yang terpilih memiliki latar belakang yang sama atau berbagi
pengalaman terkait dengan isu-isu spesifik. Jika, tujuannya adalah untuk
mencari kebutuhan pengguna dalam sistem informasi manajemen di
pelayanan kesehatan maka, peserta memiliki latar belakang yang sama atau
dari unit yang terkait.
c. Diskusi terfokus pada satu topik atau isu-isu yang sudah dibatasi jumlahnya,
tetapi mampu mengungkapkan perspektif-perspektif dan pengalaman yang
dimiliki peserta.
d. Diskusi antara peserta adalah hal yang esensial untuk mengumpulkan
keunikan tipe data dalam metode pengumpulan data.
e. Diskusi dipimpin oleh moderator yang telah dilatih yang mampu
memfasilitasi diskusi untuk mengumpulkan reponse dari peserta secara luas
dan mendalam.
f. Pertanyaan ditanyakan oleh moderator dan telah didesain untuk
menstimulasi diskusi, dan moderator telah dilatih untuk mengidentifikasi
dan menelaah secara efektif tentang padangan-pandangan peserta terkait isu.
g. Lingkungan kelompok yang nyaman dan membolehkan peserta untuk
mengeskpresikan pandangan mereka terkait isu sangat penting agar peserta
mampu memberikan respon yang baik terkait isu.
(Hennink, 2014)
2. Anggota Tim Focus Group Discussion
a. Moderator
b. Notulen
c. Observer/ Videografer
d. Penghubung peserta
3. Langkah-Langkah dalam Focus Group Discussion
a. Persiapan untuk Focus Group Discussion
1) Identifikasi masalah
2) Putuskan jika Focus Group Discussion sesuai untuk menyelesaikan
masalah.

20
3) Tulis sebuah tujuan umum yang merefleksikan kepentingan dari
kegiatan.
4) Perbaiki tujuan dengan mengembangkan daftar informasi apa saja yang
boleh dilakukan dan tidak boleh dilakukan terkait Focus Group
Discussion.
5) Buat tujuan yang terkait bagaimana informasi dikumpulkan dari Focus
Group Discussion
6) Buat tujuan untuk mengidentifikasi kebutuhan outcomes dari Focus
Group Discussion yang berhasil.
7) Putuskan jumlah dari Focus Group Discussion
8) Tentukan durasi waktu untuk Focus Group Discussion
9) Tentukan alur dari Focus Group Discussion
10) Buat prosedur dan panduan untuk pelaksanaan Focus Group Discussion
b. Pemilihan Peserta
1) Buat sebuah perencanaan sampling
2) Buat kriteria untuk peserta
3) Buat dan implementasikan prosedur pemilihan
4) Susun rencana rekrutmen peserta
5) Undang dan orientasika peserta
c. Pelaksanaan Focus Group Discussion
1) Persiapkan ruangan dengan memeriksa susunan tempat duduk, suhu, dan
ventilasi
2) Persiapkan peralatan seperti alat perekam
3) Sambut peserta dengan ramah
4) Kumpulkan informasi demografi dan serahkan tanda pengenal
5) Orientasikan peserta dengan pembukaan
6) Mulai Focus Group Discussion
7) Catat dan dokumentasikan jawaban-jawaban dari para peserta.
d. Analisis dan Pelaporan Data dari Focus Group Discussion
1) Tentukan analisis data dan rencana pelaporan
2) Deskripsikan prosedur seleksi subjek dan peserta
3) Tuliskan data yang telah direkam atau dicatat
4) Rangkum inti dari ide-ide yang ada dalam data
5) Satukan data, kemudia kategorikan data.
6) Identifikasi tema dan teori yang terkait
7) Laporan Focus Group Discussion dalam bentuk draft.
Focus Group Discussion menggunakan format semi-terstruktur untuk
menelaah, mencari informasi, mengumpulkan dan memahami alur kerja.
menimbulkan kebutuhan pengguna dalam sebuah sistem informasi manajemen di
pelayanan kesehatan.

21
Metode ini bisa juga dilakukan sebagai tahap lanjutan dari interview untuk
memastikan validitas ide atau hasil yang didapat dari wawancara (Sergeant,
2016). Focus Group Discussion dapat dilakukan beberapa kali sesuai dengan
kebutuhan untuk setiap pembahasan terfokus, sehingga didapat prioritas
kebutuhan terkait dengan pembahasan. Selanjutnya, prioritised requirements
yang terbentuk akan menjadi bahan pertanyaan di online survey.
Berikut adalah contoh pertanyaan yang digunakan dalam menggali user
requirements untuk EMR (Electronic Medical Records) di Rumah Sakit Cancer di
Uganda dengan Focus Group Discussion dan Interview.
Tabel 3.2. Topik untuk Focus Group Discussion dan Interview
Topik Pertanyaan
Tugas/kegiatan a. apa tugas-tugas rutin yang terlibat dalam
seperti penjadwalan, perawaan pasien? (Proses dan aliran, orang
peresepan, arahan, dll yang terlibat dan waktu yang dihabiskan)
b. apakah ada inefisiensi/masalah? Silahkan
rumit (seperti pengulangan yang tidak perlu,
kemungkinan membuat kesalahan/lupa/
gangguan atau informasi hilangnya
misalnya hilangnya grafik pasien?
c. Apakah peserta merasa bahwa hal tersebut
dapat meningkat dengan menggunakan
komputer?
d. apa fungsi yang akan mereka inginkan dari
dalam sistem seperti untuk dapat
melaksanakan tugas atau memperbaiki
merek
Informasi/Data a. informasi apa yang biasanya dikumpulkan?
b. Format yang merupakan informasi (teks,
Seperti riwayat pasien,
gambar, karikatur)? apakah terstandar dan
laporan hasil laboratorium,
terstruktur (formulir standar untuk pasien,
dll
laporan laboratorium/atau pertanyaan
standar untuk menanyakan kepada pasien)?
c. adakah kemungkinan kesalahan ketika

22
mengumpulkan informasi ini (termasuk
menjadi tidak terbaca, miskomunikasi atau
hilangnya informasi)?
d. Apakah pengguna merasa terstandarisasi itu
akan layak?
Komunikasi dan a. Komunikasi apa saja yang secara rutin
Pertukaran Informasi dilakukan dan yang dilakukan antar pihak?
b. Informasi apa saja yang dipertukarkan?
c. Apakah informasi itu dapat dilakukan secara
elektronik?
Tantangan, pekerjaan yang a. Tantangan apa yang peserta hadapai dalam
ada disekitar, dan pelaksanaan pekerjaan?
dukungan dalam b. Dukungan apa yang mereka butuhkan?
keputusan klinik Apakah mereka merasa penggunaan
komputer akan membantu misalnya dalam
kesalahan dan dukungan keputusan klinik?
Apakah ada ide, pendapat, atau masalah lain?
Sumber: (Kabukye, 2016)

1.3 Online Survey


Metode ini tetap menggunakan kuesioner yang dibuat untuk
mengetahui kebutuhan user. Hanya saja, kuesioner dibuat di formulir berbasis
web sehingga lebih efisien karena mudah diakses dan hasilnya dapat
dianalisis menggunakan statistik deskriptif (presentasi, mean value, median,
dan standard deviation). Metode ini biasanya lebih disukai karena dapat
meminimalisasi pengembalian kuesioner yang belum terisi atau tidak diisi.

1.4 Observasi
Mengamati pekerjaan yang dilakukan oleh user dapat memberikan data
dan kuesioner yang mungkin tidak benar atau tidak sesuai. Ketika kuesioner

23
dan wawancara merupakan metode yang subjektif, maka observasi dapat
memberikan hasil yang lebih akurat terkait bagaimana user bekerja. Namun,
observasi membutuhkan waktu yang cukup lama, biaya yang cukup besar,
sulit dilakukan coding, analisis dan interpretasi. Terdapat 3W rule of thumb
(Who, Where, What) untuk membantu menentukan tujuan observasi sehingga
dapat memudahkan.
Metode tersebut di atas memiliki tujuan dan ciri yang berbeda satu sama lain,
sehingga pemilihan metode bergantung pada kapasitas dan kebutuhan tim
pengembangan sistem informasi.

BAB IV
CONCLUSION

24
Understanding user requirements is an integral part of information systems
design and is critical to the success of interactive systems. It is now widely
understood that successful systems and products begin with an understanding of
the needs and requirements of the users. Since users might have different
perspective in defining needs and requirement, thus there are elements and
principles of doing a user requirement analysis, such as: knowledge management,
collaboration and decision making. Without those all, developer shall get
difficulties in designing developed information system.
User needs assessment give an exact description of the content,
functionality and quality demanded by potential users. Developing products and
services that meet the expectations of users and customers is essential for success,
especially now that the technology-oriented company face strong competition on
the basis of quality. User requirement assessment is the basis of user-centered
approach, creating an attractive product and to meet user needs at the level
closest.
Methods of assessing user requirements are divided into qualitative method
such observation and quantitive methods such survey and interview through the
structured questionnaire. In this case, the methods of user requirement assessment
consists of interview, focus group discussion, online survey, and observation.
Overall, the principles of each methods is similiar which gathering information
from the user efficiently and required for the information system development.

DAFTAR PUSTAKA

Bagchi, Nirmalya. 2010. Management Information System. New Delhi: Vikas


Publishing House PVT LTD.

25
Bilal, Dania. 2014. Library Automation; Core Concepts and Practical Systems
Analysis. 3rd Edition. California: Libraries Unlimited
Bochmann, Gregor V. 2010. Introduction to Requirement Analysis and
Specification. University of Ottawa
Brown, Richard et al. 2006. User and System Requirements Journal
Courage, C. and Baxter, K. 2015. Understanding Your Users: A Practical Guide
to User Requirements Methods. Waltham, USA: Elsevier.
Education Facility Planning: a Knowledge Engineering Approach. Procedia -
Social and Behavioral Sciences 107 (2013) 104 111
Hassan, Halimah Che. 2013. A Framework for User Requirement Assessment in
Technical
Hennink, M. M. 2014. Understanding Focus Group Discussions. New York:
Oxford University Press.
Kabukye, J. K. 2016. User Requirements for An Electronic Medical Records
System for A Cancer Hospital in Uganda. Master's Programme in Health
Informatics Karolinska Institutet and Stockholm University.
Kvale, Steinar. 2007. Doing Interviews. London: SAGE Publications Ltd.
Maguire, M.C. 1998. User-centred requirements handbook. EC Telematics
Applications Programme, Project TE 2010 RESPECT (Requirements
Engineering and Specification in Telematics), WP4 Deliverable D4.2,
version 3.3, May. http:www.lboro.ac.uk/research/husat/respect/rp2.html
Maguire, Martin. 2002. User requirement Analysis. Canada: Kluwer Academic
Publisher.
Sergeant, D. M. et. all. 2016. User Requirements Analysis Report. Embedding a
VRE in an Institutional Environment (EVIE). Workpackage 2: User
Requirements Analysis
Sommerville, Ian. 2001. Software Engineering 6th. Addison Wesley.
Sommerville, Ian. 2004. Software Engineering. 7th Edition. Addison Wesley
Stratis Health. 2009. Health Information Technology Services; Requirement
Analysis.

26
Turban, E. and Aronson, J.E., 2001. Decision support systems and intelligent
systems. Sixth Edition. New Jersey: Prentice Hall International.

27

You might also like