ITS-paper-27782-5108100072-paper-pratiwi

1

KAKAS BANTU ANALISIS KERANCUAN KEBUTUHAN PERANGKAT

LUNAK BERBASIS ATURAN Yunata Dede Pratiwi

1, Daniel Oranova S

2, Sarwosri

3

1,2,3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh

Nopember

Kampus ITS Sukolilo Surabaya, 60111, Indonesia [email protected],

[email protected],

[email protected]

Abstrak

Analisis kebutuhan adalah fase yang penting dalam pengembangan sebuah perangkat lunak.

Otomatisasi evaluasi terhadap bahasa alamiah yang digunakan dalam dokumen kebutuhan telah

ditetapkan untuk meningkatkan kualitas dari sebuah sistem sebelum memulai fase pembangunan sistem.

Kakas Bantu Analisis Kerancuan Kebutuhan Perangkat Lunak Berbasis Aturan ini adalah suatu kakas

bantu yang dapat membantu otomatisasi dalam evaluasi dokumen kebutuhan perangkat lunak. Kakas

bantu ini mengekstraksi dokumen kebutuhan perangkat lunak menjadi kebutuhan spesifik. Kakas bantu

melakukan analisis kerancuan pada kebutuhan spesifik dan memberikan rekomendasi atas kerancuan

yang terjadi didalamnya.

1. Pendahuluan Tahap awal dari suatu pembangunan sistem

perangkat lunak adalah proses analisis

kebutuhan sistem. Di tahap awal ini terjadi

interaksi antara calon pengguna sistem dan

pihak pengembang perangkat lunak, dimana

mereka harus memiliki persepsi yang sama atas

spesifikasi perangkat lunak yang dibangun.

Kumpulan dari spesifikasi kebutuhan

dikumpulkan dalam bentuk Dokumen

Spesifikasi Kebutuhan Perangkat Lunak

(SKPL). Dokumen SKPL disusun menggunakan

bahasa alamiah, yaitu bahasa yang kita gunakan

dalam percakapan sehari-hari. Penggunaan

bahasa alamiah memiliki kelemahan yaitu pada

saat makna dari kalimat tersebut memiliki arti

atau penafsiran yang berbeda-beda pada masing-

masing orang. Dalam konteks ini, dokumen

SKPL dapat ditafsirkan berbeda-beda oleh tim

pengembang perangkat lunak. Dengan kata lain,

dokumen SKPL tersebut bersifat rancu karena

dapat memilki arti yang berbeda-beda. Dokumen

SKPL yang bersifat rancu dapat menyebabkan

kegagalan dalam pengembangan proyek

perangkat lunak karena tujuan proyek tidak

tercapai.

Kerancuan dalam sebuah dokumen SKPL

disebabkan penggunaan kata yang rancu dalam

menyusun kalimat-kalimat kebutuhan.

Untuk itu pada tugas akhir ini dibangun

sebuah kakas bantu analisis kerancuan

kebutuhan perangkat lunak berbasis aturan.

Kakas bantu ini dapat membantu tim

pengembang perangkat lunak untuk mendeteksi

kalimat rancu dalam kebutuhan spesifik sebuah

dokumen SKPL beserta pemberian rekomendasi

kepada pengguna terhadap kerancuan yang

terjadi dalam kalimat tersebut. Kakas bantu ini

hanya melayani analisis kerancuan pada

dokumen SKPL berbahasa inggris, sesuai

dengan format IEEE dan memiliki ekstensi

berkas .docx .

2. Tinjauan Pustaka 2.1 Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak (software

requirements) adalah atribut-atribut yang

bersifat spesifik yang merupakan spesifikasi

kebutuhan fungsional dan kebutuhan non

fungsional dari sebuah sistem perangkat

lunak. Kebutuhan perangkat lunak dijabarkan

dalam sebuah dokumen formal yang disebut

dokumen Spesifikasi Kebutuhan Perangkat

Lunak (SKPL). Spesifikasi yang harus

terkandung dalam sebuah dokumen kebutuhan

perangkat lunak antara lain: fungsionalitas,

antarmuka eksternal, performa, atribut dan

batasan perancangan. Gambar 1 menunjukkan

pokok-pokok bahasan dalam sebuah dokumen

SKPL.

2

Gambar 1. Bahasan Dalam Dokumen SKPL

Pada Tugas Akhir ini, bagian yang akan

diekstraksi untuk melakukan analisis kerancuan

adalah bagian Spesific Requirements atau Kebutuhan Spesifik dengan format tabel.

Gambar 2 menunjukkan contoh format tabel

kebutuhan spesifik yang akan diekstraksi.

Gambar Error! No text of specified style in document..

Format Tabel Kebutuhan Spesifik

Bagian yang diambil untuk diekstraksi

adalah pada bagian kolom 2 tabel spesific

requirements dimana dalam kolom tersebut

terdapat daftar pernyataan kebutuhan.

2.2 Kerancuan Kebutuhan Perangkat Lunak

Kerancuan dalam sebuah dokumen SKPL

dapat terjadi dalam berbagai bentuk bahasa

alamiah. Misalnya saja kita jumpai sebuah

pernyataan:

Design a program that allows a network operator to plan changes in every parameter of

every cell in the network. These planned

changes should be verified for consistency and

correctness and then applied to the network in

the least disturbing way [3].

Dalam pernyataan diatas, tidak dijelaskan

bagaimana sebuah sistem memverifikasi sebuah

konsistensi dan kebenaran lalu

mengimplementasikannya dalam jaringan

tersebut. Sehingga pernyataan ini tidak dapat

diimpementasikan dalam rancangan sistem

apalagi dibangun menjadi sebuah fungsi dari

sistem.

Sehingga dapat kita lihat pentingnya

sebuah pernyataan spesifikasi sistem dalam

sebuah dokumen SKPL merupakan sebuah dasar

yang kuat dalam membangun sebuah sistem.

Kesalahan kecil dalam membuat spesifikasi

perangkat lunak dapat berakibat terjadinya

kegagalan pengembangan sebuah sistem

perangkat lunak.

2.3 Analisis Kerancuan Kebutuhan Perangkat Lunak Berbasis Aturan [2]

Aturan ini dibuat berdasarkan pola-pola

kalimat yang dirumuskan berdasarkan aturan

SMART Requirement yang dikerjakan pada

penelitian sebelumnya [2]. Aturan ini dibangun

untuk mendeteksi kerancuan dalam sebuah

pernyataan spesifikasi kebutuhan perangkat

lunak. Aturan ini mengacu pada sebuah aturan

SMART Requirements dengan menggunakan

pengolahan bahasa alamiah yang dibantu oleh

WordNet. SMART Requirements adalah sebuah

akronim yang merepresentasikan lima buah

acuan yang menentukan kualitas kebutuhan

perangkat lunak:

1. Specific Pernyataan kebutuhan dikatakan berkualitas

jika ia ditulis secara spesifik, yaitu tidak

bersifat rancu, konsisten, sederhana, dan

tepat.

2. Measurable Dalam konteks rekayasa kebutuhan,

measurable berarti bahwa ketika sistem

telah dibangun nantinya, pernyataan

kebutuhan harus bisa diverifikasi apakah

sudah memenuhi atau belum.

3. Attainable

3

Attainable bermakna berdasarkan teori yang ada apakah sebuah pernyataan

kebutuhan dapat dicapai atau tidak?. 4. Realisable

Dengan sumber daya yang dimiliki saat ini,

apakah sebuah pernyataan kebutuhan bisa direalisasikan atau tidak?.

5. Traceable Traceable bermakna bahwa sebuah

pernyataan kebutuhan harus bisa dilacak

mulai dari konsep hingga ke desain,

implementasi, dan pengujian. Hal ini

penting agar bisa diketahui apakah seluruh

kebutuhan yang tertulis sudah

diimplementasikan atau belum.

Bagian yang menjadi fokus utama dalam

Tugas Akhir ini adalah bagian pertama yaitu

spesific. Bagian spesific menjelaskan bahwa

sebuah sebuah kebutuhan perangkat lunak tidak

bersifat rancu.

3 Analisis dan Perancangan 3.1 Deskripsi Umum Perangkat Lunak

Pada Tugas Akhir ini akan dibuat suatu

perangkat lunak berbasis aplikasi desktop yang

akan membantu pengguna untuk menentukan

kerancuan sebuah teks spesifikasi perangkat

lunak. Aplikasi ini bekerja pada platform

windows. Aplikasi ini membantu pengembang

perangkat lunak untuk mengetahui kerancuan

dari sebuah dokumen SKPL, dimana tingkat

kerancuan dari sebuah teks dapat ditelaah secara

pasti, bukan hanya melalui naluri alamiah

penguji dokumen SKPL.

Adapun gambaran umum dari aplikasi ini,

adalah sebagai berikut:

Input : bagian tekstual dari dokumen Spesifikasi Kebutuhan Perangkat Lunak.

Proses : ekstraksi dokumen SKPL untuk mendapatkan pernyataan kebutuhan yang

terkandung di dalam bagian kebutuhan

spesifik. Setelah proses ekstraksi dokumen

dilakukan, pengecekan kalimat utuh akan

dilakukan pada kebutuhan spesifik yang telah

terekstrakasi. Setelah ditemukan kalimat

kebutuhan yang merupakan kalimat utuh

dalam bahasa ingrris, kalimat kebutuhan

akan mengalami proses penandaan POS oleh

pustaka stanford pos tagger. Keluaran dari

proses tagging atau penandaan tersebut

berupa teks yang telah ditandai berdasarkan

struktur kalimatnya atau POS nya. Lalu

proses selanjutnya teks yang telah ditandai

tersebut akan diproses oleh modul utama

yang berisi aturan-aturan dan logika sistem.

Modul utama mengacu pada dua repositori

kata, dua repositori kata itu terdiri repositori

kata rancu beserta pos nya untuk mengetahui

ada tidaknya penggunaan kata rancu dalam

kalimat kebutuhan tersebut, dan juga terdapat

repositori sinonim kata dari pustaka WordNet

yang akan mendeteksi sinonim dari kata-kata

rancu yang terdaftar dalam tabel repositori

aturan. Dari pengecekan kata rancu akan

dihasilkan apakah kalimat kebutuhan bersifat

rancu atau tidak. Apabila ditemukan rancu,

maka akan dilakukan proses pemberian

rekomendasi pada kalimat rancu.

Output: berupa informasi apakah pernyataan kebutuhan tersebut bersifat rancu atau tidak.

Dengan keterangan bagian dari kalimat

tersebut yang menyebabkan ke rancuan, serta

rekomendasi yang bisa digunakan untuk

memperbaiki kerancuan tersebut.

3.2 Arsitektur Aplikasi

Arsitektur dari perangkat lunak ini dapat

dilihat pada Gambar 3. Sistem ini hanya dapat

diakses oleh pengguna dimana sistem

terinstalasi. Pengguna dalam kasus ini adalah

seorang analis sistem kebutuhan perangkat

lunak. Pada Gambar 3 pengguna akan

memasukan dokumen SKPL sebagai masukan

sebagai sistem untuk mengetahui kerancuan dari

dokumen SKPL tersebut.

Analis Kebutuhan Dokumen SKPL Antarmuka Pengguna

Ekstraksi Dokumen SKPL

Analisis Ambiguitas

Pemberian Rekomendasi

Cetak Hasil

Ekstraksi Berdasarkan Struktur Kalimat

Deteksi Kalimat Utuh

Kebutuhan Spesifik Pernyataan Kebutuhan

Gambar Error! No text of specified style in document..

Arsitektur Sistem Analisis Kerancuan

4

Di dalam sistem, dokumen SKPL akan

diekstraksi menggunakan bantuan dari pustaka

Apache POI. Setelah dilakukan ekstraksi

dokumen SKPL, sistem akan mengambil isi dari

kebutuhan spesifik. Lalu akan dilanjutkan

dengan pengecekan kalimat oleh pustaka

openNLP. Setelah itu, kalimat yang berhasil

lolos sebagai kalimat utuh, akan mengalami

proses pemisahan kalimat berdasarkan

strukturnya menggunakan pustaka Stanford Pos

Tagger . Setelah kalimat terpecah berdasarkan

POS nya, maka akan dilakukan analisis

kerancuan dengan menggunakan aturan yang

terdaftar dalam sebuah tabel aturan dalam basis

data. Sehingga akan diperoleh hasil apakah

kalimat tersebut rancu atau tidak. Sehingga

dapat ditentukan rekomendasi yang akan

diberikan. Dan hasil output akan dicetak dan

ditampilkan pada pengguna.

3.3 Spesifikasi Kebutuhan Perangkat Lunak

Aplikasi ini memiliki 3 proses utama, yaitu:

1. Proses Ekstraksi Dokumen Masukan dokumen SKPL yang diproses

adalah dokumen dengan ekstensi .docx. Gambar

4 menunjukkan diagram alir ekstraksi dokumen

SKPL menjadi kebutuhan spesifik. Mulai

Baca isi keseluruhan

Dokumen

String Paragraf

Cek Tabel dan Cek Id Kebutuhan Spesifik

Format Sesuai IEEE?

Cek Keutuhan Kalimat

Selesai

Tampilkan Hasil Ekstraksi

Kalimat Utuh

Kebutuhan Spesifik

YA

String Sentence

Lokasi Berkas

Kalimat Utuh?

IYA

Beri Tanda kalimat Tidak

UtuhTIDAK

Gambar 4. Diagram Alir Ekstraksi Dokumen

Dokumen SKPL dengan ekstensi berkas

.docx merupakan ekstensi berkas keluaran yang

dihasilkan oleh Microsoft Word versi 2007 ke

atas. Kebutuhan spesifik dokumen SKPL

diperoleh dengan menggunakan pustaka apache

POI. Pustaka apache POI akan membaca

keseluruhan isi dokumen SKPL. Pembacaan

dilakukan secara terurut berdasarkan baris

paragrafnya dari awal hingga akhir dokumen.

Sehingga kita dapat menampung isi keseluruhan

dari sebuah dokumen SKPL ke dalam sebuah

variabel paragraf. Variabel paragraf akan

diekstraksi kembali untuk mendapatkan bagian

kebutuhan spesifik perangkat lunaknya saja. Id

dari kebutuhan spesifik dan format tabel

digunakan sebagai penanda kebutuhan spesifik

yang akan diekstraksi. Setelah melalui proses

ekstraksi, akan dilakukan proses pengecekan

kalimat utuh dengan menggunakan pustaka

OpenNLP. Pengecekan kalimat utuh dilakukan

agar hanya kalimat bahasa Inggris yang utuh

yang dapat masuk dalam proses analisis

kerancuan.

2. Proses Analisis Kerancuan Pemisahan kalimat berdasaran struktur

kalimatnya atau POS nya dilakukan dengan

menggunakan pustaka stanford pos

taggers. Digunakan juga pustaka wordNet

untuk membantu proses analisis kerancuan

dengan menggunakan sinonim.

Pencocokkan aturan yang tepat dilakukan

pada tabel aturansmart pada basis data mySql.

Untuk melakukan proses ini string kalimat

disimpan dalam sebuah list yang menampung

hasil dari proses pemecahan kalimat oleh

stanford pos tagger. Proses analisis

dimulai dengan mencocokkan masing-masing

kata dalam kalimat dengan kata-kata rancu

dalam tabel aturan. Jika terjadi kecocokan salah

satu kata dengan kata yang tersimpan dalam

tabel aturan, maka kalimat tersebut dinilai rancu.

Saat tidak ditemukan kata rancu yang

persis sama dengan kata-kata rancu pada tabel

aturan, dilakukan penyimpanan pos kalimat

yang memiliki pos sama dengan pos kata rancu.

Disinilah pustaka wordNet bekerja untuk

mencari sinonim dari kata-kata rancu yang

terdapat dalam tabel aturan. Gambar 5

menunjukkan diagram alir dari proses

5

analisiskerancuan dari sistem ini. Pencarian

sinonim hanya dilakukan pada kata yang

memiliki pos sama dengan kata yang sedang

diperiksa. Apabila sinonim ditemukan, maka

kalimat tersebut akan dinyatakan rancu.

Mulai

Pemisahan kalimat berdasarkan POS

String sentence

String tagged

Cek Pola Kata Rancu Tanpa WordNet

(Tampung Aturan)

Pencocokan Aturan Yang Tepat

Menanyakan Sinonim Kata Pada wordNet

Rancu?

Pencocokan Aturan dengan bantuan wordNet

Cetak Hasil : Kalimat Rancu

Selesai

TIDAK

Ya

Rancu?

YA

Cetak Hasil Tidak Rancu

TIDAK

Tidak Rancu

Pola Penyebab Kerancuan

Gambar 5. Diagram Alir Analisis Kerancuan

3. Proses Pemberian Rekomendasi Setelah pengecekan kerancuan, kalimat

kebutuhan akan diberi rekomendasi agar

pengguna dapat memperbaiki kerancuan yang

terjadi pada kalimat tersebut.

Rekomendasi hanya diberikan pada

kalimat yang memiliki hasil analisis berupa

kalimat rancu. Pemberian rekomendasi

dilakukan dengan mencocokkan pola penyebab

rancu dalam tabel basis data aturan dengan

rekomendasi yang terdapat di dalamnya. Pada

tabel basis data aturan pola penyebab rancu dan

rekomendasinya tersimpan dalam satu baris

yang sama. Ketika kerancuan disebabkan oleh

penggunaan sinonim kata rancu, maka akan

dilakukan pengecekan ulang terhadap pola kata

penyebab rancu. Hal tersebut dilakukan untuk

mendapatkan referensi pola penyebab kerancuan

sehingga didapatkanlah hasil rekomendasinya.

Gambar 6 menunjukkan diagram alir dari proses

pemberian rekomendasi.

Mulai

String sentence

Cek hasil Analisis

Ambigu?

Pencocokan rekomendasi

Tampilkan Pernyataan

Terklasifikas + Rekomendasinya

Selesai

Cetak HasilTidak Perlu

RekomendasiTIDAK

Pola Penyebab Ambigu

YA

Rekomendasi Yang Tepat

Cetak pernyataan terklasifikasi +

rekomendasi pada berkas teks.

Gambar 6. Diagram Alir Pemberian

Rekomendasi

3.4 Analisis Aktor Pada sistem ini hanya terdapat satu aktor

yaitu pengguna. Pengguna sistem ini merupakan

analis sistem kebutuhan perangkat lunak yang

sedang melakukan pengecekan kerancuan dari

sebuah dokumen SKPL.

4. Implementasi 4.1 Implementasi Aturan dalam Basis Data

Aturan penentuan kerancuan berasal dari

beberapa sumber tertulis dan riset-riset

sebelumnya mengenai penggunaan kalimat yang

menyebabkan kerancuan dalam kalimat

pernyataan kebutuhan perangkat lunak. Tabel

aturan ditulis oleh Wayan Muliawan. Salah satu

contoh pendekatan aturan kerancuan yang

ditulis dalam daftar aturannya adalah sebagai

berikut ini.

Acuan tersebut menyatakan apabila kita

menggunakan kata-kata seperti some, several

dan many dalam sebuah kalimat pernyataan

kebutuhan perangkat lunak, maka kalimat

tersebut dipastikan akan bersifat rancu. Contoh

Acuan [4] :

Avoid ambiguities such as some, several, many

6

penggunaan kata-kata rancu dalam kalimat

kebutuhan dapat kita amati pada contoh berikut

ini:

Jika dalam sebuah kalimat terdapat pola

some/DT + NNS, maka kalimat tersebut

dapat dikategorikan rancu. Contoh kalimat

beserta Part of Speech (POS) untuk tiap-tiap

katanya adalah: The/DT system/NN

provides/VBZ some/DT languages/NNS

./..


several/JJ + NNS, maka kalimat tersebut


beserta POS untuk tiap-tiap katanya adalah:

The/DT system/NN provides/VBZ

several/JJ languages/NNS ./..


many/JJ + NNS, maka kalimat tersebut


beserta POS untuk tiap-tiap katanya adalah:

The/DT system/NN provides/VBZ

many/JJ languages/NNS ./..

Pos kalimat yang digunakan adalah model

Penn TreeBank yang digunakan dalam Tugas

Akhir ini. Jumlah aturan yang digunakan dalam

tugas akhir ini berjumlah 56 buah aturan.

Tabel 1. Simbol dan Definisi English POS Tag Model

Penn TreeBank

No. Simbol Definisi Keterangan

1 DT Determiner Pada umumnya berupa article seperti: the, a, an, all, dan some.

2 NNS Noun (plural) Kata benda bentuk jamak, contoh: languages, books, hats, dan lain-lain.

3 NN Noun (singular) Kata benda bentuk tunggal, contoh: language, book, hat, dan lain-lain.

4 VBZ Verb Kata kerja, contoh: provides

5 JJ Adjective Kata sifat, contoh: many

6 RB Adverb Kata keterangan, contoh: clearly

7 PRP Personal Pronoun Kata ganti orang, contoh: it

4.2 Implementasi Ekstraksi Dokumen

Pembacaan dokumen SKPL menggunakan

pustaka Apache POI yang diinstansiasi dan

diimplementasikan dalam kelas

NewSkpl.Pembacaan dokumen dilakukan

secara terurut. Agar lebih mudah dalam

melakukan pengolahan string, isi dokumen

dipotong dengan mendeteksi akhir dari satu

baris bagian dokumen.

Cara yang digunakan untuk melakukan

pengecekan terhadap kebutuhan spesifik

dokumen SKPL adalah dengan mengidentifikasi

id dari pernyataan kebutuhan yang terkandung

dalam kebutuhan spesifik. Selanjutnya dilakukan

pemecahan tabel dari kebutuhan spesifik.

Setelah kebutuhan spesifik didapatkan,

dilakukan pengecekan terhadap kalimat utuh.

Dalam melakukan proses pengecekan kalimat

utuh, pustaka openNLP digunakan sebagai

pustaka pembantu. Fungsi openNLP yang

digunakan pada proses ini adalah fungsi

sentence detector. Gambar 7 menunjukkan

implementasi dari ekstraksi dokumen pada kelas

NewSKPL.

Gambar 7. Implementasi Ekstraksi Dokumen

pada kelas NewSKPL

4.3 Implementasi Analisis Kerancuan

Proses analisis kerancuan merupakan

proses utama dari aplikasi ini. Dalam proses ini,

kalimat kebutuhan yang telah didapatkan dari

proses ekstraksi, dianalisis kerancuannya dengan

menggunakan bantuan dari basis data mySQL

dan pustaka wordNet.

Kalimat kebutuhan dipecah dan ditandai

posnya oleh proses tagging menggunakan

stanford post tagger. Setelah melalui

proses penandaan pos dan pemisahan kata, maka

dilakukan proses analisis kerancuan. Pemisahan

kata dan posnya menghasilkan dua buah

keluaran yaitu k1 dan tag1. Gambar 8

7

menunjukkan implementasi analisis kerancuan

pada kelas AturanSmartModel dimana kelas

tersebut berfungsi sebagai jembatan antara

sistem dengan tabel basis data aturan.

Gambar 8. Implementasi Analisis Kerancuan

pada kelas AturanSmartModel

Mendeteksi kerancuan tanpa bantuan

sinonim dari WordNet dilakukan terlebih

dahulu. Proses ini mendeteksi pola-pola rancu

berdasarkan tabel aturan dalam basis data

mySql. Proses ke-2 dilakukan dengan memilih

aturan yang tepat dalam tabel berdasarkan kata

dan pos. Jika tidak ditemukan kata yang persis

dalam basis data maka akan dilakukan Proses

ke-3 yaitu pencarian sinonim kata rancu yang

dibantu oleh WordNet berdasarkan kesamaan

pos yang ditemukan. Dilanjutkan Proses ke-4

dengan mendeteksi kerancuan berdasarkan

sinonim yang diperoleh dari WordNet. Maka

akan diketahui adakah sionim kata rancu yang

terdapat dalam kata yang sedang dianalisis.

Setelah hasil didapatkan dilakukan proses

terakhirr yaitu mencetak hasil analisis. Pencarian

sinonim dalam wordnet didasarkan pada

kesamaan pos yang dimiliki oleh kata.

4.4 Implementasi Pemberian Rekomendasi Masing-masing aturan kalimat rancu

memiliki rekomendasinya sendiri. Sehingga

terdapat 56 butir rekomendasi untuk 56 aturan

kalimat rancu. Pengimplementasian

rekomendasi kalimat rancu ke dalam basis data

mySQL menggunakan satu tabel bersamaan

dengan basis data aturan untuk mempermudah

pengambilan rekomendasi apabila ditemukan

kecocokan pola kalimat rancu dengan aturan

dalam tabel. Pengambilan isi dari rekomendasi

dilakukan dengan mencocokkan kata penyebab

rancu dengan kata dan pos dengan tabel aturan

mySQL. Implementasi dari pemberian

rekomendasi terdapat pada kelas

readAmbiguDoc seperti yang ditunjukkan pada

Gambar 9.

Gambar 9. Implementasi Pemberian Rekomendasi pada kelas readAmbiguDoc pada

kelas AturanSmartModel

5. Uji Coba Uji coba dibagi menjadi 2 bagian yaitu uji

coba fungsionalitas dan uji coba non

fungsionalitas. Uji coba fungsionalitas meliputi

semua kebutuhan fungsional pada kakas bantu.

Sedangkan uji coba non fungsionalitas dilakukan

untuk melihat performa dari kakas bantu beserta

kepuasan pengguna terhadap performa yang

dimiliki oleh kakas bantu.

5.1 Uji Coba Kebutuhan Fungsional 1. Uji Coba Ekstraksi Dokumen SKPL

Uji coba ini bertujuan untuk mengetahui

apakah ektraksi terhadap dokumen SKPL

berhasil dilakukan dengan sempurna pada

dokumen uji. Uji coba dilakukan dengan

memasukkan dokumen SKPL dengan format

berkas .docx ke dalam kakas bantu dan

pengguna memilih pilihan lakukan Baca Berkas.

Parameter pengujian adalah tingkat kesamaan

yang didapatkan dari pembandingan terhadap

jumlah kebutuhan spesifik yang berhasil

diekstraksi oleh kakas bantu dengan hasil

perhitungan jumlah kebutuhan spesifik secara

manual.

Gambar 10 menunjukkan salah satu

keberhasilan dari uji coba ini. Pada dokumen

argos_urd.docx terdapat 61 butir pernyataan

kebutuhan dalam kebutuhan spesifik dan kakas

bantu berhasil mengekstraksi ke 61 pernyataan

tersebut. Sehingga uji coba fungsionalitas

ekstraksi dokumen SKPL pada kakas bantu

dapat dinyatakan berhasil.

8

Gambar 10. Hasil ekstraksi Dokumen

argos_urd.docx

2. Uji coba Analisis Kerancuan dan Pemberian Rekomendasi


apakah semua kebutuhan spesifik yang telah

terekstraksi berhasil dianalisis dan diberikan

rekomendasi. Cara pengujian adalah dengan

mencocokkan jumlah pernyataan yang bersifat

rancu dan hasil rekomendasi yang didapat dari

sistem dan perhitungan manual.

Dalam uji coba yang dilakukan pada

dokumen argos_urd.docx ini berhasil didapat 10

butir pernyataan kebutuhan bersifat rancu dan 10

butir pernyataan tersebut berhasil diberi

rekomendasi. Gambar 11 menunjukkan

keberhasilan uji coba ini.

Gambar 11. Hasil Analisis dan Pemberian

Rekomendasi Dokumen argos_urd.docx

3. Uji coba Akurasi Performa Hasil Analisis Kerancuan


tingkat akurasi/ kebenaran dari analisis

kerancuan yang dihasilkan sistem dengan

mencari indeks Kappa(indeks kesepakatan

anatara penguji 1 dan penguji 2). Dimana

penguji 1 adalah seorang ahli kebutuhan

perangkat lunak dan penguji 2 adalah kakas

bantu analisis kerancuan berbasis aturan.

Dokumen yang digunakan dalam uji coba ini

adalah dokumen uji dari penelitian ReqSac [1].

Dimana pernyataan kebutuhan dalam dokumen

tersebut telah diklasifikasikan sebelumnya oleh

ahli kebutuhan perangkat lunak. Hasil

perhitungan manual hasil yang didapat dari uji

coba ini terdapat pada tabel 2.

Tabel 2. Hasil Perhitungan Hasil Analisis Kerancuan

Kakas Bantu

Rancu Tidak Rancu

Ahli Rancu 42 0

Tidak Rancu 8 15

Berdasarkan data tersebut maka P(A) = (42 +

16) / 65 = 0.8923. Kemudian untuk menghitung

P(E) dilakukan dengan cara sebagai berikut:

1. Ahli menjawab rancu sebanyak 42 kali dan tidak rancu sebanyak 23 kali, maka

prosentase ahli menjawab rancu = 64.61 %

2. Kakas bantu menjawab rancu sebanyak 49 kali dan tidak rancu sebanyak 16 kali, maka

prosentase kakas bantu menjawab rancu

adalah sebesar = 75.38 %

3. Probabilitas para penguji menjawab rancu adalah 0.6461 * 0.7538 = 0.4870

4. Probabilitas para penguji menjawab tidak rancu adalah (0.3539 * 0.2461) = 0.0870

5. P(E) = 0.4870 + 0.0870 = 0.5740 Setelah itu nilai (indeks Kappa) dapat ditentukan dengan:

= ( 0.8923 0.5740) / (1-0.5740) = 0.3183/0.426

= 0.7471

5.2 Uji Coba Kebutuhan NonFungsional 1. Uji Coba Penggunaan

Uji coba penggunaan dibagi menjadi 2 sesi,

setiap sesi diikuti oleh 5 partisipan. Partisipan

9

merupakan mahasiswa teknik informatika yang

sering terlibat dengan kebutuhan perangkat

lunak. Sesi pertama dilakukan untuk menguji

kemudahan penggunaan aplikasi. Pada sesi

pertama, setiap partisipan tidak akan diberikan

arahan untuk menggunakan aplikasi. Setiap

partisipan akan diberikan waktu maksimal

selama 30 menit. Sesi kedua dilakukan

pengujian menggunakan skenario pengujian

ekstraksi dan analisis kerancuan serta

penggunaan fitur-fitur pendukung pada kakas

bantu. Waktu yang diberikan maksimal 30

menit. Setelah melakukan 2 sesi uji coba

penggunaan, partisipan diberikan kuisioner. Hal

ini dilakukan untuk mengetahui tingkat

kesepakatan terhadap kepuasan partisipan

sebagai pengguna terhadap kakas bantu ini.

Tabel 3 menyajikan hasil kuisioner yang didapat

dari partisipan.

Tabel 3. Hasil Kuisioner Partisipan

Pernyataan Tingkat

Persetujuan

Kakas bantu mudah digunakan. 70%

Tampilan kakas bantu menarik. 75%

Partisipan memahami kinerja kakas bantu. 70%

Partisipan memahami hasil keluaran yang

dihasilkan oleh kakas bantu.

85%

Tingkat kepuasan yang didapat dari hasil

keluaran kakas bantu.

80%

Partisipan merasa terbantu apabila kakas

bantu digunakan dalam melakukan analisis

kerancuan kebutuhan perangkat lunak

85%

6. Kesimpulan Dari hasil pengamatan selama

perancangan, implementasi, dan proses uji coba

perangkat lunak yang dilakukan, penulis

mengambil kesimpulan sebagai berikut:

1. Telah berhasil diimplementasikan sebuah kakas bantu yang dapat mengekstraksi

sebuah dokumen SKPL menjadi kebutuhan

spesifik yang dapat melakukan analisis

kerancuan serta memberikan rekomendasi

pada kerancuan yang terjadi.

2. Berdasarkan indeks kappa yang didapatkan dari hasil dokumen uji penelitian ReqSac

didapatkan hasil kappa sebesar 0,7079 yang

artinya kakas bantu memiliki nilai proporsi

kesepakatan Banyak (Substantial).

3. Kakas bantu berhasil memenuhi tujuan utamanya yaitu, dapat mempermudah

pengoreksian kerancuan sebuah dokumen

SKPL dengan memperoleh nilai kesepakatan

dari responden sebesar 85%.

7. Daftar Pustaka [1] Hussain, H. M. I. 2007. Using Text Classification to Automate Ambiguity Detection in SRS

Documents. Tesis di Departemen Computer Science & Software Engineering, Universitas Concordia , Canada

[2]Muliawan, I Wayan (2011). Analisis Ambiguitas Kebutuhan Perangkat Lunak berdasarkan Acuan Smart

Requirement. Tesis di Jurusan Teknik Informatika, Institut Teknologi Sepuluh Nppember, Surabaya.

[3]Wilson, W., Rosenberg, L., & Hyatt, L. (1996)

Automated Quality Analysis of Natural Language Requirement Specifications. Proceedings 14th Annual Pacific Northwest Software Quality Conference,

ortland.

[4]Mannion, M., Keepence, B. 1995. SMART Requirements. ACM Sigsoft. The Standish Group International, Inc. (1995). The CHAOS Report.