MEMPRIORITASKAN KEBUTUHAN PERANGKAT LUNAK MENGGUNAKAN MODEL KANO DENGAN MENAMPILKAN RANCANGAN ANTARMUKA PERANGKAT LUNAK

Seminar Nasional Matematika dan Aplikasinya 2013

MEMPRIORITASKAN KEBUTUHAN PERANGKAT LUNAK MENGGUNAKAN MODEL KANO DENGAN MENAMPILKAN RANCANGAN ANTARMUKA PERANGKAT LUNAK Indra Kharisma Raharjana Program Studi Sistem Informasi, Universitas Airlangga Kampus C Mulyorejo, Surabaya – 60115, Indonesia [email protected] Abstract— Paper ini mencoba untuk memprioritaskan hasil analisa kebutuhan perangkat lunak yang dibuat oleh analis perangkat lunak mengunakan metode kano dengan menampilkan rancangan antarmuka perangkat lunak. Kebutuhan perangkat lunak penting untuk diprioritaskan terutama pada pengembangan perangkat lunak dengan pendekatan agile, yang menerapkan beberapa iterasi dalam pembangunannya. Kebutuhan perangkat lunak dengan prioritas tinggi biasanya dibuat terlebih dahulu pada iterasi awal dan menjadi model awal dari perangkat lunak yang sedang dibanggun. Langkah-langkah yang dilakukan untuk menganalisa kebutuhan perangkat lunak adalah mengumpulkan informasi tentang perangkat lunak yang dibuat, baik dengan metode observasi maupun wawancara, kemudian disusun kebutuhan perangkat lunak oleh analis. Setiap kebutuhan perangkat lunak tersebut dirancang rancangan antarmuka perangkat lunak. Untuk memprioritaskan kebutuhan perangkat lunak digunakan model Kano dengan menanyakan kepada stakeholder setiap fitur yang didapatkan pada analisa kebutuhan, bagaimana tanggapan mereka jika fitur tersebut ada dan bagaimana jika fitur tersebut tidak ada. Sebelumnya stakeholder diberitahu tentang skenario sistem yang hendak dibuat beserta rancangan antarmuka sistem untuk setiap fiturnya. Dengan menampilkan rancangan antarmuka, stakeholder bisa mendapatkan gambaran lebih jelas tentang sistem yang hendak dibangun, sehingga pendapat dari stakeholder menjadi lebih objektif ketika diminta untuk memprioritaskan kebutuhan perangkat lunak yang hendak dibangun. Keywords— Analisa Kebutuhan Perangkat Lunak, Model Kano, Antarmuka Perangkat Lunak

I. PENDAHULUAN Kebutuhan perangkat lunak mendefinisikan fitur-fitur apa saja yang harusnya dimiliki oleh perangkat lunak agar memenuhi kebutuhan stakeholder. Kebutuhan perangkat lunak disusun berdasarkan analisa observasi dan wawancara yang dilakukan oleh pengembang perangkat lunak bersama stakeholder. Stakeholder berpartisipasi dan membantu untuk mengidentifikasikan

kebutuhan perangkat lunak karena mengetahui secara detail domain sistem yang hendak dibuat. Pembangunan Perangkat lunak mengunakan metode Agile membagi pengerjaanya menjadi beberapa bagian, biasanya disebut iterasi, setiap iterasi menghasilkan working code, yaitu kumpulan fitur-fitur yang sudah bisa digunakan oleh pengguna. Setiap iterasi terdiri atas sekumpulan fitur-fitur yang direncanakan berdasarkan analisa kebutuhan perangkat lunak, dan direncakan untuk selesai pada akhir iterasi. Fitur yang paling penting biasanya dikerjakan pada iterasi awal sehingga working code perangkat lunak tersebut sudah bisa mengambarkan produk yang akan jadi, dan pengguan bisa memberikan pengalamannya terhadap fitur-fitur utama untuk dijadikan masukan bagi pengembang perangkat lunak. Biasanya keterlibatan calon pengguna dalam proses membantu pengerjaan pengerjaan perangkat lunak, terutama untuk menjaga fungsionalitas fitur agar sesuai dengan domain sistem yang diharapkan. salah satu metode untuk memodelkan kebutuhan pengguna adalah dengan model Kano (Mamunur, 2010), dengan model ini kebutuhan perangkat lunak bisa dipetakan berdasarkan prioritasnya, namun karena deskripsi yang digunakan sering kali menimbulkan bias karena persepsi masing-masing responden bisa berbeda dalam memahami fitur-fitur yang ditanyakan. Untuk itu pada paper ini mencoba untuk memodelkan kebutuhan penguna untuk mendapat prioritas dengan menunjukan tampilan visual dari fitur perangkat lunak. Penampilan visual mengunakan low-fidelity prototype, yaitu berupa sketsa rancangan antarmuka, karena lebih mudah dibuat, terbuka pada perubahan, serta masih pada domain abstraksi visual, selain itu persepsi penguna terhadap low-fidelity dan high fidelity terbukti sama dalam pemahaman kegunaan perangakat lunak (Kieffer, 2010). Tujuan dari paper ini adalah ingin mengetahui dampak dari pengunaan rancangan antarmuka pada pemahaman pengguna untuk memprioritaskan kebutuhan produk perangkat lunak yang diinginkannya.


Secara umum, langkah yang dilakukan dalam paper ini adalah mengumpulkan kebutuhan perangkat lunak untuk dianalisa, hasil analisa berupa use case dengan beberapa skenario. Selanjutnya adalah melakukan perancangan antarmuka berdasarkan fitur-fitur yang berasal dari analisa tersebut. Kemudian menyusun kuisioner dengan model kano, kuisioner tersebut mengunakan 2 versi, versi pertama mengunakan kuisioner model kano konvensional, versi kedua mengganti pertanyaan dengan sketsa rancangan antarmuka.selanjutnya adalah melakukan evaluasi terhadap hasil kuisioner model kano. II. TINJAUAN PUSTAKA A. Model Kano Model Kano adalah teori tentang pembuatan produk dan kepuasan pelanggan yang dikembangkan pada tahun 1980an untuk mengklasifikasikan kecenderungan pengguna menjadi 5 kategori, yaitu (Kano, 1984): 1) One-dimensional : atribut ini mengakibatkan kepuasan jika dipenuhi dan ketidakpuasan jika tidak dipenuhi. 2) Attractive : atribut ini jika dibuat akan memuaskan pengguna, namun tidak mengakibatkan ketidakpuasan jika tidak dibuat, biasanya atribut ini merupakan fitur yang tidak disangka sebelumnya oleh pengguna. 3) Must-be : atribut ini tidak memiliki efek yang dominan jika dipenuhi, namun mengakibatkan ketidakpuasan jika tidak dipenuhi. Biasanya merupakan fitur-fitur dasar dalam suatu produk. 4) Indifferent : atribut ini merupakan atribut netral yang tidak berdampak kepuasan pelanggan. Sebaiknya menghindari fitur yang mempunyai atribut indifferent. 5) Reverse : jika atribut ini ada justru menimbulkan ketidakpuasan, jika tidak ada malah berdampak pada kepuasan. TABEL 1. KUISIONER MODEL KANO Pertanyaan model KANO Pertanyaan fungsional / jika fitur tersebut ada (misal:jika terdapat fitur notifikasi via SMS, bagaimana perasaan anda?) Pertanyaan disfungsional / jika fitur tersebut tidak ada (misal:jika tidak terdapat fitur notifikasi via SMS, bagaimana perasaan anda?)

Jawaban Saya suka seperti itu Harus Seperti itu Saya netral Saya tidak keberatan Saya tidak suka Saya suka seperti itu Harus Seperti itu Saya netral Saya tidak keberatan Saya tidak suka

Cara kerja dari model kano ini adalah untuk setiap fitur ditanyakan kepada pengguna dengan metode survey, bagaimana pendapatnya jika fitur

ini ada dan juga ketika fitur tersebut tidak ada (Tabel 1). Kombinasi dari jawaban dari pengguan untuk setiap fitur kemudian dikategorikan untuk mengetahui karakteristik fitur dengan mengunakan Tabel 2. Pada tabel tersebut terdapat atribut baru yaitu Questionable, atribut ini muncul jika preferensi pengguna sangat bertolak belakang (suka dan tidak suka) sehingga attribute menjadi tidak masuk akal. TABEL 2. EVALUASI MODEL KANO Fungsional

Disfungsional Suka Harus

Netral

Tidak keberatan A I I I

Tidak suka O M M M

Suka Q A A Harus R I I Netral R I I Tidak R I I keberatan Tidak suka R R R R Q A=Attractive, I=Indifferent, M=Must-be, O=One-dimensional, Q=Questionable, and R=Reverse

Model kano tidak hanya berguna pada bidang pengembangan produk dalam industri, namun juga sering kali digunakan di bidang teknologi informasi, pada awalnya untuk memodelkan kualitasnya web page, kemudian memodelkan kebutuhan pelanggan pada permasalahan komputasi, serta memodelkan kualitas dengan fuzzy nonlinier model (Mamunur, 2010). B. Antarmuka dengan Low-Fidelity & HighFidelity Fidelity dalam antarmuka mengambarkan semudah apakah prototype bisa dibedakan dengan produk akhir serta bisa dimanipulasi untuk menunjukkan aspek dari desain. Low-fidelity merupakan prototype yang berbeda dengan produk akhir dalam model interaksi, tampilan, serta kedalaman detail. Biasanya low-fidelity dibuat dengan sketsa pada kertas, sehingga cepat dan bisa fokus pada high-level interaksi dan arsitektur informasi dibandingkan detail dan tampilan. Sedangkan high-fidelity menawarkan interaksi yang lebih menarik dan realistis karena antara prototype dan produk akhir memiliki kemiripan yang tinggi karena prototype dibuat dengan komputer dan bisa dijalankan. Low-fidelity dan high-fidelity tidak mempengaruhi pemahaman pengguna tentang kegunaan dari produk tersebut karena unsur estetika tidak mempengaruhi persepsi terhadap kegunaan perangkat lunak (Walker, 2002). Selain itu medium dari prototype tidak memiliki pengaruh yang signifikan terhadap kemampuan penguna untuk mengidentifikasi kegunaan dan permasalahan dalam pengunaan perangkat lunak nantinya (Chase, 2013).


III. METODE PENELITIAN Langkah-langkah yang dilakukan penelitian ini adalah sebagai berikut

dalam

A. Mengumpulkan Kebutuhan Perangkat Lunak Tujuan tahap ini adalah mendapatkan keinginan stakeholder tentang perangkat lunak yang hendak dibuat, perangkat lunak tersebut harus menyelesaikan permasalahan yang terjadi saat ini sehingga bisa membantu proses kerja yang terjadi pada organisasi tersebut. Untuk mendapatkan kebutuhan perangkat lunak dilakukan dengan cara metode observasi maupun wawancara. B. Analisa Kebutuhan Perangkat Lunak Berdasarkan kebutuhan perangkat lunak yang telah dikumpulkan pada kegiatan sebelumnya, dilakukan analisa permodelan kebutuhan mengunakan Use Case Diagram, yaitu menentukan aktor-aktor yang terlibat serta mengidentifikasikan fitur-fitur yang dibutuhkan oleh aktor tersebut. Selanjutnya dijabarkan skenario yang mungkin muncul pada setiap fitur pada use case diagram dengan mengunakan format use case scenario.satu fitur bisa punya lebih dari satu skenario. C. Perancangan Antarmuka Perangkat Lunak Berdasarkan skenario yang dijabarkan pada use case skenario, dibuat rancangan antarmuka untuk setiap skenario, karena masih dalam proses analisa, antarmuka yang dibuat lebih mengunakan lowfidelity prototype atau antarmuka yang dirancang dengan cara mendasainnya di kertas. Selain itu pengunaan antarmuka prototype berbasis kertas mempunyai kualitas yang sama dibandingkan dengan antarmuka prototype berbasis komputer dalam hal user testing, selain itu juga lebih murah dan lebih cepat (Kieffer, 2010). D. Penyusunan Quisioner dengan model Kano Quisioner model Kano dibuat sesuai dengan fitur yang diidentifikasikan pada tahap analisa kebutuhan perangkat lunak. Untuk mendapatkan dampak yang didapatkan dengan mengunakan rancangan antarmuka pada quisioner model kano, perlu dilakukan perbandingan. Perbandingan dilakukan antara kuisioner model Kano konvensional dengan kuisioner model Kano dengan sketsa antarmuka untuk mengantikan deskripsi fitur. E. Evaluasi Hasil Quisioner Setiap kebutuhan perangkat lunak tersebut dirancang rancangan antarmuka perangkat lunak. Untuk memprioritaskan kebutuhan perangkat lunak digunakan model Kano dengan menanyakan kepada stakeholder setiap fitur yang didapatkan pada analisa kebutuhan, bagaimana tanggapan mereka jika fitur tersebut ada dan bagaimana jika

fitur tersebut tidak ada. Sebelumnya stakeholder diberitahu tentang skenario sistem yang hendak dibuat beserta rancangan antarmuka sistem untuk setiap fiturnya. TABEL 3. STORY CARD SISTEM No 1

2

Sebagai Saya butuh Sehingga Sebagai Saya butuh Sehingga

3

Sebagai Saya butuh Sehingga

4


5


6


7

Sebagai Saya butuh Sehingga Sebagai Saya butuh Sehingga

8

9


10


11


Story Cards Pasien Bisa mengetahui jadwal praktek dokter Saya bisa merencanakan kunjungan ke dokter sesuai dengan preferensi saya Pasien Melakukan reservasi secara online terhadap rencana kunjungan saya ke dokter Saya mendapatkan kepastian jadwal tentang waktu pemeriksaan saya oleh dokter Pasien Melakukan pendaftaran sebagai pasien Saya bisa melakukan reservasi secara online Pasien Bisa melakukan cek-in ketika saya telah datang di klinik/rumah sakit Klinik/Rumah sakit tahu kedatangan saya Pasien Mengetahui daftar antrian pasien Saya bisa memperkirakan waktu antrian saya Pasien Bisa melakukan pembayaran secara mudah via jalur elektronik Saya tidak perlu antri di kasir/resepsionis untuk membayar jasa dokter Petugas Administrasi Dapat mendata pasien baru Semua pasien dapat terdata secara benar Petugas Administrasi Dapat menangani pembayaran yang dilakukan oleh pasien Pasien dapat ditangani oleh dokter setelah pembayaran selesai Petugas Administrasi Dapat memverifikasi dokumen asuransi yang dimiliki oleh pasien Pasien mendapat pelayanan sesuai hak nya berdasarkan polis asuransi Petugas Administrasi Mengetahui daftar antrian pasien Dapat mengatur antrian pasien ketika sistem tidak berjalan seperti seharusnya Dokter Memberi tanda bahwa saya telah siap menerima pasien untuk diterima Pasien bisa segera masuk ke ruang praktek untuk diperiksa

IV. STUDI KASUS Dalam paper ini, metode penelitian dilakukan secara beurut dalam sebuah studi kasus. Studi kasus yang digunakan adalah pembangunan Sistem Registrasi, Reservasi dan Antrian pada praktek dokter di rumah sakit, sistem ini berbasis


smartphone yang membantu pasien untuk melakukan reservasi pada praktek dokter, serta membantu mengelola antrian sehingga menjadi lebih efisien. Sistem ini mencoba untuk mengatasi permasalah waktu tunggu pasien ketika berobat ke dokter, selain itu juga mengefesiensikan waktu periksa pasien, sejak pasien berencana untuk berobat ke dokter sampai pasien diperiksa oleh dokter. A. Mengumpulkan Kebutuhan Perangkat Lunak Tahap ini dilakukan dengan menganalisa permasalahan yang terjadi ketika berkunjung ke rumah sakit untuk memeriksakan diri pada dokter. Analisa ini berorientasi pada pasien sebagai pengguna utama sistem ini. Analisa permasalahan sistem tersebut ditampilkan dalam bentuk story cards (Table 3), mulai dari melihat jadwal dokter, reservasi, pendaftaran, cek-in, melihat daftar antrian dan melakukan pembayaran. B. Analisa Kebutuhan Perangkat Lunak Berdasarkan kebutuhan yang telah didapatkan dibuatlah use case diagram dan use case skenario, setiap use case disusun menurut urutannya dalam sistem sehingga didapatkan gambar 1 yang menampilkan ketergantungan use case berdasarkan skenario dalam sistem.

memiliki satu atau lebih skenario. Beberapa Use case yang didefinisikan skenario yang mungkin, memiliki alternatif skenario. Dalam paper ini, skenario-skenario alternatif ini yang hendak dikonfirmasi fitur mana saja yang perlu dibuat dalam sistem mengunakan model kano. sedangkan use case yang telah terdefinisi sebelumnya tidak dibuat sebagai bahan pertanyaan dalam model kano karena semuanya merukan use case mandatory yang harus ada di sistem. Alternatif fitur yang digunakan sebagai bahan quisioner model kano ditampilkan pada Table 4. TABEL 4. KEBUTUHAN FUNGSIONAL YANG DI TANYAKAN DALAM MODEL KANO N Kebutuhan o Pengguna 1 Melihat Jadwal Praktek Dokter

2 Reservasi Online

3 Mekanisme CekIn 4 Terlambat Cek-In

UC01 – Melakukan Pendataan Pasien Baru

UC02 – Melakukan Pendaftaran Sebagai Pasien Online

5 Mekanisme Pembayaran 6 Daftar Antrian

UC03 - Mengetahui Jadwal Praktek Dokter

UC04 – Reservasi Rencana Kunjungan Secara Online

UC05 – Melakukan Pembayaran Via Jalur Elektronik

UC07 – Menangani Pembayaran Tunai

UC08 – Memverifikasi Dokumen Asuransi

UC06 – Melakukan Cek-In Setelah Datang Di Rumah Sakit

7 Notifikasi Antrian

Kebutuhan Fungsional

Kode

Dikelompokkan berdasarkan Spesialisasi Dokter Dikelompokkan berdasarkan Hari Praktek Dikelompokkan berdasarkan Nama Dokter Memilih Waktu Pemeriksaan Berdasarkan Antrian Reservasi Berdasarkan Urutan Kedatangan di Rumah Sakit Cek-in Pada Komputer

F1-1

Cek-in dengan smartphone Mundur beberapa Nomor Antrian Reservasi Online Batal Bayar Tunai

F3-2 F4-1

Bayar secara Elektronik Display di ruang tunggu Display di smartphone Ketika Giliran < 5 nomor Ketika Giliran < 3 nomor Ketika tiba giliran diperiksa

F5-2 F6-1 F6-2 F7-1 F7-2 F7-3

F1-2 F1-3 F2-1 F2-2 F2-3 F3-1

F4-2 F5-1

C. Perancangan Antarmuka Perangkat Lunak Berdasarkan kebutuhan fungsional pada table 4, dibuatlah rancangan antarmuka untuk setiap kebutuhan fungsional. Antarmuka dibuat mengunakan konsep low-fidelity namun digambar mengunakan komputer. Contoh hasil rancangan antarmuka tersebut bisa dilihat pada gambar 2.

UC09 – Memberi Tanda Siap Memeriksa Pasien

UC10 – Mengetahui Daftar Antrian Pasien

UC11 – Melihat Daftar Antrian Pasien

Gambar 1. Grafik Ketergantungan Use Case dalam membentuk skenario sistem secara Utuh

Dari setiap use case, diidentifikasikan skenarioskenario yang mungkin muncul. Satu use case bisa

Gambar 2.Contoh Antarmuka untuk kebutuhan fungsional Reservasi Online Memilih Waktu Pemeriksaan


Berdasarkan analisa, tidak semua kebutuhan fungsional dapat dibuat rancangan antarmuka. Beberapa rancangan antarmuka yang tidak dibuatkan rancangan antarmukanya adalah F2-3, F2-4, F4-1, F4-2, F5-1, dan F5-2. D. Penyusunan Quisioner dengan model Kano Quisioner model Kano dibuat berdasarkan kebutuhan pengguna dan kebutuhan fungsional yang didefinisikan pada table 4, untuk setiap kebutuhan fungsionalnya ditanyakan kepada responden pertanyaan fungsional dan disfungsional sesuai dengan tabel 1. Terdapat dua versi pertanyaan untuk setiap kebutuhan fungsional, yaitu pertanyaan model kano tanpa dan dengan rancangan antarmuka. E. Evaluasi Hasil Quisioner Kuisioner dibuat menjadi dua versi, setiap versi terdapat pertanyaan yang menampilkan model kano dengan rancangan antarmuka dan tidak. Nantinya hasil quisioner tersebut dilakukan pengecekan silang untuk membandingkan dampak dari pengunaan rancangan antarmuka pada model kano. Selain itu dibandingkan juga hasil dari kuisioner model kano dengan persepsi tingkat pentingnya suatu fitur. Kemudian dilakukan evaluasi terhadap fitur adanya rancangan model antarmuka dengan mengunakan model kano itu sendiri. Dilakukan juga penilaian persepsi pemahaman responden terhadap pengunaan rancangan antarmuka dalam quisioner model kano. V. HASIL DAN PEMBAHASAN A. Perbandingan Hasil Model Kano Berdasarkan hasil pengolahan quisioner model kano, didapatkan hasil seperti pada tabel 5. Dari pengolahan ini kecocokan hasil model kano hanya 20%, model kano tanpa rancangan antarmuka 50% menemukan hasil Indifferent. Sedangkan model kano dengan rancangan antarmuka hasil Onedimensional dan Attractive lebih sering muncul. TABEL 5. PERBANDINGAN HASIL MODEL KANO BERDASARKAN KEMUNCULAN TERBANYAK

F1-1 F1-2 F1-3 F2-1 F2-2 F3-1 F3-2 F6-1 F6-2 F7-1 F7-2 F7-3

Tanpa Rancangan Antarmuka A I I O,A A,I I I M O I O M

Dengan Rancangan Antarmuka M R A O,A,M,I M I A,R O O O,A A O,A,M

B. Perbandingan Hasil Model Analytical-Kano Pada Analisa ini hasil quisioner diproyeksikan menjadi model kano pada gambar 3 dan gambar 4. Gambar 3 merupakan pemetaan setiap fitur dengan model kano tanpa rancangan antarmuka, Sedangkan gambar 4 merupakan representasi model kano dengan rancangan antarmuka.

Gambar 3.Hasil Model Kano tanpa Rancangan Antarmuka

Gambar 4.Hasil Model Kano dengan Rancangan Antarmuka

Mekanisme penilaian A-Kano (Qianli, 2008) adalah memberikan nilai untuk setiap pertanyaan fungsional dan disfungsional (Tabel 6). Nilai tersebut kemudian menjadi koordinat XY grafik, jika nilainya negatif maka hasilnya merupakan Questionable atau Reverse. X mengambarkan disfungsional dan Y mengambarkan fungsional. TABEL 6. EVALUASI MODEL A-KANO (ANALYTICAL KANO) Jawaban pertanyaan Kano Suka Harus Netral Tidak keberatan Tidak suka

Fungsional

Disfungsional

1 0.5 0 -0.25 -0.5

-0.5 -0.25 0 0.5 1

Untuk mempermudah pengkategorian model kano, digunakan klasifikasi pada gambar 5 yang diusulkan oleh (Berger, 1993). Jika nilai X dan Y kurang dari 0.5 maka masuk kategori Indifferent, Attractive, Must-Be, dan One-Dimensional juga didapatkan berdasarkan posisi X dan Y. jika posisinya negative maka artinya masuk kategori Reverse.


Fungsional

antarmuka tidak berdampak pada kepuasan responden. Namun dari sudut pespektif responden dalam memahami pertanyaan quisioner model kano, terungkap bahwa model kano dengan rancangan antarmuka lebih mudah dipahami sebanyak 86% dibandingkan dengan model kano tanpa rancangan antarmuka yang hanya 51%. TABEL 8. PERBANDINGAN HASIL MODEL A-KANO DENGAN PERSEPSI TINGKAT KEPENTINGAN FITUR

Gambar 5.Hasil Pemetaan Model Kano dari XY Fitur

Hasil perbandingan model A-Kano dapat dilihat pada tabel 7. Secara umum tidak ada perbedaan signifikan terhadap hasil yang didapatkan. 60% hasil yang muncul sama antara tanpa dan dengan rancangan antarmuka. TABEL 7. PERBANDINGAN HASIL MODEL KANO BERDASARKAN MODEL A-KANO

Fitur F1-1 F1-2 F1-3 F2-1 F2-2 F3-1 F3-2 F6-1 F6-2 F7-1 F7-2 F7-3

Tanpa Rancangan Antarmuka X Y Hasil 0.53 0.78 O 0.47 0.50 A 0.34 0.13 I 0.50 0.88 O 0.34 0.63 A 0.50 0.50 O 0.50 0.53 O 0.94 0.47 M 0.81 0.78 O 0.63 0.53 O 0.75 0.66 O 0.75 0.38 M

Dengan Rancangan Antarmuka X Y Hasil 0.94 0.75 O 0.38 0.16 I 0.38 0.50 A 0.63 0.56 O 0.53 0.63 O 0.56 0.25 M 0.44 0.44 I 0.69 0.75 O 0.63 0.63 O 0.81 0.88 O 0.63 0.75 O 0.59 0.56 O

C. Perbandingan Hasil Model Analytical-Kano Dengan Persepsi Tingkat Kepentingan Fitur Selain itu dilakukan juga evaluasi perbandingan nilai masing-masing fitur berdasarkan evaluasi model A-Kano dengan tingkat kepentingan fitur yang juga telah diisi oleh responden dalam quisioner. Yaitu dengan menambahkan nilai fungsional dan disfungsional dan melakukan normalisasi sehingga bisa dibandingkan dengan nilai tingkat kepentingan fitur yang mempunyai nilai antara 1 sampai 10. Hasil Perbandingan tersebut tidak menemukan perbedaan selisih hasil yang signifikan antara model kano dengan dan tanpa rancangan antarmuka. D. Evaluasi Fitur Rancangan Antarmuka Dinilai Mengunakan Model Kano Dalam kuisioner yang diisi responden, terdapat pertanyaan fungsional dan disfungsional tentang bagaimana perasaan responden jika terdapat rancangan antarmuka pada kuisioner model kano. Hasil yang didapatkan jika terdapat rancangan antarmuka pada quisioner model kano adalah Indifferent, artinya ada maupun tidak, rancangan

F1-1 F1-2 F1-3 F2-1 F2-2 F3-1 F3-2 F6-1 F6-2 F7-1 F7-2 F7-3 Ratarata selisih

Ting kat penti ngny a Fitur 7.94 7.25 5.38 8.00 7.56 7.50 6.75 8.13 8.75 7.69 8.19 8.19

Kano tanpa rancang an Antarm uka 7.38 6.07 4.64 7.86 6.56 6.90 6.55 8.02 8.65 7.19 9.90 7.08

selisih

0.56 1.18 0.73 0.14 1.00 0.60 0.20 0.10 0.10 0.50 1.71 1.10 0.66

Kano dengan rancan g antar muka 8.96 5.10 6.25 7.29 7.02 6.04 6.25 7.86 7.14 8.81 7.86 6.79

selisih

1.02 2.15 0.88 0.71 0.54 1.46 0.50 0.27 1.61 1.12 0.33 1.40 0.998

VI. KESIMPULAN Penggunaan rancangan antarmuka pada quisioner model kano bisa meningkatkan pemahaman pengguna terhadap fitur yang ditawarkan, namun secara umum responden tidak mempermasalahkan apakan qusioner terdapat rancangan antarmuka atau tidak. Dalam paper ini ditemukan kecenderungan bahwa fitur yang disertai dengan rancangan antarmuka mendapat respon baik dari responden. Rekomendasi dari paper ini adalah rancangan antarmuka bisa dikombinasikan pada quisioner model kano sehingga responden tidak bosan dengan pertanyaan pada model kano. DAFTAR PUSTAKA Md Mamunur Rashid , 2010, “A Review Of State-Of-Art On Kano Model For Research Direction”, International Journal of Engineering Science and Technology Vol. 2(12): 7481-7490 Kieffer,

Suzanne, Adrien Coyette, dan Jean Vanderdonckt, 2010, "User interface design by sketching: a complexity analysis of widget representations." In Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems, pp. 57-66. ACM.

Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji ,1984,. "Attractive quality and must-be quality". Journal of the Japanese


Society for Quality Control 14 (2): 39–48 . Miriam Walker, Leila Takayama, and James A. Landay ,2002, "High-fidelity or low-fidelity, paper or computer? Choosing attributes when testing web prototypes" Proceedings of the Human Factors and Ergonomics Society Annual Meeting. Vol. 46. No. 5. Boothe, Chase, Lesley Strawderman, and Ethan Hosea, 2013, "The effects of protoype medium on usability testing." Applied ergonomics.

Qianli Xu, Roger J. Jiao, Xi Yang, Martin Helander, Halimahtun M. Khalid, dan Anders Opperud, 2008, “An analytical Kano model for customer need analysis”, Design Studies, Volume 30, Issue 1, January 2009, Pages 87– 110. Berger, C, Blauth, R, Boger, D, Bolster, C, Burchill, G, DuMouchel, W, Pouliot, F, Richter, R, Rubinoff, A, Shen, D, Timko, M and Walden, D, 1993, “Kano’s method for understanding customer-defined quality”, Center for Quality of Management JournalVol 2 No 4 page 3-35

MEMPRIORITASKAN KEBUTUHAN PERANGKAT LUNAK MENGGUNAKAN MODEL KANO DENGAN MENAMPILKAN RANCANGAN ANTARMUKA PERANGKAT LUNAK

Recommend Documents