Himmatul Azizah - 5107100048 Page 1
EKSTRAKSI METADATA DOKUMEN SOFTWARE REQUIREMENT SPECIFICATION (SRS).
Himmatul Azizah - Sarwosri, S.Kom., M.T., Daniel Oranova Siahaan, S.Kom., M.Sc., PD.Eng.
Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember.
Email: [email protected]
Abstraksi
Dokumen Software Requirements Specification (SRS) merupakan sebuah deskripsi lengkap dari behavior sebuah sistem yang akan dikembangkan. Dokumen ini berisi rincian kebutuhan fungsionalitas dan non- fungsionalitas. Dokumen ini dianalisa oleh pengembang perangkat lunak yang kemudian digunakan oleh para pengembang perangkat lunak untuk dapat menciptakan perangkat lunak yang sesuai dengan kebutuhan pengguna. Pada kenyataannya, pengembang perangkat lunak terkadang sulit untuk menganalisa sebuah dokumen SRS yang digunakan sebagai pedoman saat pembuatan perangkat lunak. Oleh karena itu, diperlukan adanya perangkat lunak yang dapat membantu developer menganalisa dokumen SRS.
Perangkat lunak ini dapat membantu pengembang menganalisa dokumen SRS dengan cara mengekstraksi metadata dari dokumen tersebut. Pada perangkat lunak yang akan dibangun kali ini inputnya berupa dokumen SRS. Proses yang dilakukan pertama dengan memisahkan dokumen per bab. Lalu dokumen tersebut diberi tag menggunakan algoritma part-of-speech tagging. Terakhir dokumen tersebut diberi bobot menggunakan algoritma TF-IDF untuk mengetahui kepentingan kalimat tersebut. Setelah semua proses selesai dan metadata telah didapatkan, sistem akan membentuk RDF dari RDF skema yang telah dibuat secara manual.
Kemudian sistem akan memasukkan metadata kedalamnya.
Keluaran dari perangkat lunak ini berupa file RDF yang menyimpan dokumen SRS sebagai subjeknya, dan kebutuhan fungsional, kebutuhan non-fungsional, use case, dan aktor sebagai objeknya. Objek tersebut didapatkan dari dokumen SRS yang ingin diproses oleh pengguna. Nantinya objek tersebut diharapkan dapat memudahkan pengembang perangkat lunak dalam menganalisa dokumen SRS
Kata kunci : Software Requirement Specification, Metadata, Part-of-Speech, TF-IDF, RDF.
1. PENDAHULUAN
Dokumen Software Requirements Specification (SRS) merupakan sebuah deskripsi lengkap dari behavior sebuah sistem yang akan dikembangkan. Dalam dokumen ini berisi rincian kebutuhan fungsionalitas dan non-fungsionalitas.
Dokumen SRS ini berfungsi untuk mencatat semua kebutuhan pengguna perangkat lunak, sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan pengerjaan pengembangan sesuai dengan yang diharapkan, sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan, sebagai pedoman jika terdapat perbedaan antara pengguna dengan pengembang sistem terhadap hasil pengembangan perangkat lunak, dan sebagai bukti bahwa pengembang dalam hal ini sistem analis telah melakukan tahap software requirement analysis.
Saat sebuah perangkat lunak mulai dikembangkan, pengembang perangkat lunak harusnya membuat dokumen SRS. Dokumen ini harus dimengerti secara menyeluruh oleh pengembang perangkat lunak agar perangkat lunak yang diciptakan sesuai dengan keinginan pengguna.
Pada kenyataannya, pengembang perangkat lunak
terkadang sulit untuk menganalisa sebuah dokumen SRS yang digunakan sebagai pedoman saat pembuatan perangkat lunak. Seringkali para pengembang perangkat lunak kurang hati-hati dan tidak teliti, sehingga mengakibatkan terjadinya kesalahan analisa yang menimbulkan banyak kerugian. Kesalahan analisa dokumen SRS yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir pada tahap penyelesaian, adalah malapetaka besar bagi sebuah kelompok pembuat perangkat lunak. Biaya dan waktu yang diperlukan menjadi banyak yang tersia- sia. Biaya yang diperlukan untuk memperbaiki sebuah kesalahan karena analisa kebutuhan yang tidak benar bisa menjadi dua puluh lima kali lipat, jika kesalahan tersebut ditemukan pada tahap pengujian fungsi perangkat lunak.
Seringkali para pengembang perangkat lunak harus berulangkali menemui pengguna perangkat lunak yang sedang dikembangkan karena kesalahan analisa. Terkadang pula pengguna memberi waktu pengerjaan yang sangat singkat sehingga perangkat lunak yang dihasilkan menjadi tidak sempurna.
Untuk meminimalisir masalah-masalah tersebut, Departement of Computer Science and
Himmatul Azizah - 5107100048 Page 2
Software Engineering, Concordia University,Montreal, Canada melakukan penelitian mengenai perangkat lunak yang dapat membantu pengembang perangkat lunak dalam menyelesaikan masalah tersebut berupa sebuah perangkat lunak yang dapat menghasilkan high level contextual view pada aktor dan layanan dari sebuah sistem perangkat lunak secara otomatis. Perangkat lunak ini disebut Requirement Engineering Assistance Diagnostic (READ) projek. Pada perangkat lunak ini, pengembang perangkat lunak dapat terbantu pada langkah awal pemodelan use case. Hasil evaluasi dari READ projek yang dilakukan oleh Shadi Moradi Seresht dan Olga Ormandjieva yang merupakan bagian dari Departement of Computer Science and Software Engineering, Concordia University, Montreal, Canada itu sendiri adalah perangkat lunak ini dapat mendeteksi ambiguitas pada level pemahaman awal. Sekarang ini masih diteliti visualisasi dari kebutuhan non-fungsional (NFR) yang secara otomatis diekstrak dan diklasifikasi dari teks input. Kedepannya NFR akan disoroti untuk meningkatkan visibilitasnya, dan secara tidak langsung terhubung dengan kebutuhan fungsional, dan keduanya akan ditingkatkan melalui domain model dan CUCM (Convert Use-Case Model).
Kendala dari perangkat lunak ini adalah ketidaktetapan pada dokumen teks yang besar sehingga menyebabkan dokumen tersebut sulit untuk diidentifikasi. [1]
Penelitian lain yang dilakukan oleh Giuseppe Lami dari Software Engineering Institute, Carnegie Mellon University pada tahun 2005 mengenai QuARS (Quality Analyzer for Requirements Specifications) yang merupakan perangkat lunak yang digunakan untuk menganalisa dokumen kebutuhan yang diambil dari projek industri yang nyata. Pada perangkat lunak ini, dokumen kebutuhan dalam file format apapun dapat diproses.
Kesempurnaan analisa tergantung dari kelengkapan dan keakurasian kamus yang terdapat pada perangkat lunak tersebut. Sekarang ini QuARS hanya dapat memproses teks dokumen dan kebutuhan yang tidak sempurna. [3]
Berangkat dari masalah–masalah yang ada, pada tugas akhir ini penulis mengusulkan untuk membangun sebuah perangkat lunak yang dapat membantu pengembang perangkat lunak dalam mengekstraksi metadata dari sebuah dokumen SRS.
Ekstraksi metadata dokumen SRS tersebut diharapkan dapat membantu pengembang dalam menganalisa dokumen SRS. Berbeda dengan penelitian sebelumnya yang inputnya berupa daftar kebutuhan, pada perangkat lunak yang akan dibangun kali ini inputnya berupa dokumen SRS.
Dokumen SRS merupakan dokumen yang memiliki detail penjelasan keseluruhan aspek perangkat lunak. Di dalamnya terdapat informasi perangkat lunak yang berupa teks. Metadata dari
dokumen SRS dapat membantu pengembang perangkat lunak dalam mempercepat pengerjaan perangkat lunak dan mengurangi biaya yang diperlukan selama proses pengembangan perangkat lunak. Dalam mengekstraksi metadata dari dokumen SRS, dibutuhkan algoritma part-of-speech untuk mengekstraksi metadata dokumen yang berupa teks.
2. DASAR TEORI
2.1 Software Requirements Specification (SRS) Software Requirements Specification (SRS), sebuah spesifikasi kebutuhan untuk sebuah sistem perangkat lunak, adalah dokumen yang dibuat ketika sebuah perangkat lunak akan dikembangkan. Di dalamnya terdapat detil penjelasan dari keseluruhan aspek dari sebuah perangkat lunak. Ketika sebuah perangkat lunak akan dikembangkan dan memiliki spesifikasi yang sedikit atau ketika sebuah sistem terlalu kompleks, dokumen SRS sangatlah dibutuhkan. Ketika dokumen SRS telah siap, maka dokumen tersebut diserahkan pada pengguna untuk direview. [5]
Isi standar dari sebuah dokumen SRS yang memiliki format IEEE adalah :
a. Introduction
Pada bagian ini, diberikan pengantar mengenai spesifikasi, baik itu mengenai definisi, tujuan, serta pembaca yang ditargetkan untuk membaca SRS ini, serta pengenalan secara umum mengenai spesifikasi.
b. General Description
Pada bagian ini dijelaskan mengenai perspektif produk, fungsi-fungsi produk, karakteristik user, dan batasan umum dari sistem.
c. Specific Description
Pada bagian ini dijelaskan mengenai : 1) Kebutuhan fungsional
Bagian ini membahas mengenai kebutuhan- kebutuhan fungsional dari sistem, digambarkan melalui use cases. Use cases ini menggambarkan seluruh kerja fungsional dari perangkat lunak secara keseluruhan, melalui semua pengguna yang menggunakan perangkat lunak tersebut (aktor). Use cases yang digambarkan menunjukkan seluruh kerja fungsional dari perangkat lunak.
2) Kebutuhan data
Bagian ini membahas mengenai data-data yang dibutuhkan dalam pengembangan perangkat lunak. Data-data ini mencakup semua data yang diperlukan oleh perangkat lunak dalam prosesnya. Data-data ini bisa berupa masukan, serta keluaran yang akan dihasilkan oleh sistem / perangkat lunak.
Himmatul Azizah - 5107100048 Page 3
3) Kebutuhan kualitas sistemBagian ini menjelaskan secara spesifik faktor- faktor dari kualitas sistem yang tidak berhubungan dengan kebutuhan fungsional yang didokumentasikan melalui use case.
4) Batasan sistem
Bagian ini menjelaskan mengenai batasan- batasan yang ada pada sistem / perangkat lunak secara keseluruhan. Batasan yang ada berupa batasan dalam arsitektur, desain dan implementasi dari sistem.
d. Appendixes dan Index
Pada bagian appendix dan index ini hanya ditambahkan lampiran-lampiran yang diperlukan dalamspesifikasi dari software ini.
Manfaat dari SRS yaitu untuk menunjukkan kepada pembaca mengenai spesifikasi dari suatu perangkat lunak / sistem dengan jelas serta kebutuhan-kebutuhan baik fungsional maupun non- fungsional serta batasan-batasan sehingga dapat memberikan gambaran yang jelas mengenai sistem.
2.2 Use Case dan Aktor
Use case adalah dialog antara aktor dan sistem. Use case mempresentasikan fungsionalitas yang disediakan oleh sistem yang tampak oleh aktor.
Sebuah use case adalah suatu fungsionalitas tingkat tinggi yang disediakan sistem. Dengan kata lain use case menggambarkan bagaimana aktor menggunakan sistem. Notasinya adalah elips. Bentuk notasi dari use case ditunjukkan pada Gambar 1.
Gambar 1. Notasi Use Case
Aktor adalah orang-orang yang menggunakan sebuah sistem yang sama, tapi memiliki kepentingan berbeda terhadap sistem tersebut. Aktor merepresentasikan orang, perangkat keras, sistem atau subsistem yang menjalankan atau mengoperasikan sebuah sistem. Masing-masing aktor berasosiasi dengan satu use case. Aktor disebut pula entitas luar. Bentuk notasi dari aktor ditunjukkan pada Gambar 2.
Gambar 2. Notasi Aktor
2.3 Metadata [2]
Ketika sebuah dokumen dibuat menggunakan Microsoft Word, program menciptakan binary file dengan ekstensi “doc”. Pembuat program ini,
memilih memasukkan kode biner ke dokumen untuk menyatakan bold text, kode biner yang menyatakan page break, dan kode biner lainnya untuk menyatakan semua informasi yang disediakan oleh
“doc” file. Kode yang dimasukkan ke dokumen adalah metadata atau data mengenai data. Misalnya pada Microsoft Word, data aslinya berupa “a” dan metadatanya berupa “a should be in bold”.
Definisi sederhana dari metadata adalah data mengenai data. Metadata ini mengandung informasi mengenai isi dari suatu data yang dipakai untuk keperluan manajemen file / data dalam suatu basis data. Jika data tersebut dalam bentuk teks, metadatanya biasanya berupa keterangan mengenai nama ruas (field), panjang field, dan tipe fieldnya:
integer, character, date, dll. Untuk jenis data gambar (image), metadata mengandung informasi mengenai siapa pemotretnya, kapan pemotretannya, dan setting kamera pada saat dilakukan pemotretan. Satu lagi untuk jenis data berupa kumpulan file, metadatanya adalah nama-nama file, tipe file, dan nama pengelola (administrator) dari file-file tersebut.
2.4 Algoritma Part-of-speech Tagging
Part-of-speech tagging (POS tagging atau POST) , juga disebut grammatical tagging atau word-category disambiguation, m erupakan proses menandai kata pada teks sebagai hubungan dari bagian tertentu pada dokumen, didasarkan pada kedua definisi, serta konteksnya yakni hubungan dengan kata-kata yang berdekatan dan terkait dalam kalimat, frase, atau paragraf. Bentuk sederhana dari pemakaian POS adalah pada anak kecil yang baru belajar mengidentifikasi kata benda, kata kerja, kata keterangan, kata sifat, dll.
Terkadang ada beberapa kata yang merepresentasikan lebih dari satu bagian dalam dokumen di tempat yang berbeda. Contohnya adalah
“The sailor dogs the hatch”. Kata “dogs” disini dapat merupakan kata benda jamak, dapat pula merupakan kata kerja. Penggunaan grammatical tagging dapat menunjukkan bahwa "dogs" adalah kata kerja, dan bukan kata benda jamak, karena salah satu dari kata- kata harus menjadi kata kerja utama, dan pembacaan kata benda kurang memungkinkan untuk berada setelah kata "sailor" (sailor !→ dogs). Analisis semantik kemudian dapat meramalkan bahwa
"sailor" dan "hatch" mengimplikasikan "dogs"
sebagai 1) dalam konteks bahari (sailor→<kata kerja>←hatch) dan 2) tindakan yang diterapkan pada objek "hatch" ([subjek] dogs → hatch). Dalam konteks ini, "dogs" adalah istilah bahari yang berarti
"mengikatkan (penetasan kedap air) dengan aman;
berlaku untuk mengikuti".
2.5 Resource Description Framework (RDF) RDF merupakan representasi dari suatu model metadata dokumen yang mengandung subjek, predikat, dan objek. Subjek merupakan bagian dari
Use case 1
Aktor
Himmatul Azizah - 5107100048 Page 4
kalimat yang menjelaskan tentang sesuatu yangmenjadi pusat kalimat. Predikat merupakan bagian dari kalimat yang menjelaskan property atau karakteristik dari subject yang dibicarakan yang berisikan hubungan antar resource. Dan objek merupakan bagian dari kalimat yang menjelaskan value dari property. Sehingga apabila digambarkan dalam bentuk graph akan terlihat seperti Gambar 3.
Gambar 1 Graph Data Model
Dokumen RDF direpresentasikan dalam bentuk objek :
a. Class, merupakan subClass dari Resource. Dapat merepresentasikan Subject, yang merupakan domain dari suatu properti, maupun Object, yang merupakan range dari suatu properti dari suatu kalimat.
b. Property, merupakan predikat dari suatu kalimat, yang menjelaskan value (range) dari suatu pokok permasalahan (domain).
c. Datatype, merupakan subClass dari Literal, yang memiliki atribut label XMLLiteral, Literal (string dan integer). subClass, subProperties, Domain, type, dan range menunjukkan relasi yang terjadi antar object, yaitu menurut pada rules RDF.
d. Literal, merupakan sesuatu yang bukan termasuk resource.
Objek class, property, datatype, memiliki beberapa atribut yaitu, label, about, comment, dan isDefinedBy. Label, berisikan fragmen dari suatu URI reference (URIref) yang biasanya dipisahkan oleh karakter “#”, misalnya : http://www.w3.org/1999/02/22-rdfsyntax-ns#nil, maka labelnya adalah : nil. About, berisikan URIref secara lengkap yaitu URI beserta fragmennya,yaitu http://www.w3.org/1999/02/22-rdf-syntax-ns#nil.
isDefinedBy, berisikan URIref tanpa label, dibatasi oleh karakter “#”,yaitu http://www.w3.org/1999/02/
22-rdf-syntax-ns#. [4]
3. PERANCANGAN SISTEM
3.1 Deskripsi Umum Sistem
Arsitektur dari sistem ini dapat dilihat pada Gambar 4. Pada Gambar 4 terlihat bahwa hanya ada satu pengguna yang dapat mengakses sistem ini pada satu komputer. Pengguna dalam sistem ini merupakan developer. Kemudian developer tersebut memasukkan dokumen SRS ke dalam sistem.
Dokumen SRS yang diproses harus berupa dokumen yang berbahasa Inggris dan memiliki file format Microsoft Word 2007 ke atas. Selain itu, dokumen SRS juga harus sesuai standar IEEE.
Gambar 4. Arsitektur Sistem
Sistem memiliki lima proses yaitu mengubah dokumen docx menjadi xml, memisahkan dokumen yang telah terbaca menjadi subdokumen, memisahkan kata kerja dan kata benda pada subdokumen use case, memberi bobot pada setiap kata pada dokumen, dan yang terakhir menyimpan file RDF.
3.2 Use Case Diagram
Secara garis besar, use case dari sistem perangkat lunak ini digambarkan oleh use case diagram pada Gambar 5.
Gambar 5. Use Case Diagram 3.3 Langkah Kerja
Langkah kerja sistem ini diperlihatkan pada Gambar 6.
Himmatul Azizah - 5107100048 Page 5
Mulai
Selesai
Docx ٰ→ XML Dokumen ٰ→ Subdokumen
Beri bobot pada kata kerja dan kata benda Tagging setiap kata
yang ada padadokumen
Simpan metadata file dalam bentuk file RDF
File RDF Masukkan Dokumen
Apakah dokumen sesuai dengan syarat data input?
Apakah metadata ditemukan?
tidak
ya Menu apa yang
ingin dipilih?
Tag kata
Pisahkan kata benda dan kata kerja pada bagian kebutuhan
fungsional Beri bobot pada setiap kata
yang ada pada dokumen Beri bobot
Ambil kalimat pada bagian kebutuhan fungsional dan non
fungsional Lihat Metadata
Masukkan kalimat pada bagian kebutuhan fungsional dan kebutuhan non fungsional, serta kata kerja sebagai use
case dan kata benda sebagai aktor pada skema RDF Buat skema RDF
ya
tidak
Gambar 6. Flowchart Alur Kerja Sistem
3.4 Antarmuka Sistem
Sistem ini hanya memiliki satu antarmuka, dimana antarmuka tersebut dapat mencakup keseluruhan proses pada menubar yang disediakan.
Gambar 7. Antarmuka Sistem
4. IMPLEMENTASI
Implementasi utama dari sistem ini adalah melihat metadata sebagaimana terlihat pada gambar 8. Untuk proses taggingnya seperti pada gambar 9.
Untuk proses pembentukan file RDF ada pada gambar 10.
Gambar 8. Implementasi Menu Utama
for (int j = 0; j < teks_tags.Length; j++) {
if (teks_tags[j].Equals("NN")) {
int tandaA = 0;
for (int a = 0; a < aKerja; a++) {
if
(kataBenda[a].Equals(teks_tokens[j])) {
tandaA = 1;
break;
} }
if (tandaA == 0) {
kataBenda[aBenda] = teks_tokens[j];
aBenda++;
} }
else if (teks_tags[j].Equals("VB")) {
int tandaB = 0;
for (int b = 0; b < aKerja; b++) {
if
(kataKerja[b].Equals(teks_tokens[j])) {
tandaB = 1;
break;
} }
if (tandaB == 0) {
kataKerja[aKerja] = teks_tokens[j];
aKerja++;
} } }
Gambar 9. Implementasi Tagging
Gambar 10. Implementasi RDF
Himmatul Azizah - 5107100048 Page 6
5. UJI COBAUji coba pada perangkat lunak ekstraksi metadata dokumen SRS dilakukan dengan menggunakan sebuah laptop. Pengujian perangkat lunak ini menggunakan metode pengujian black box yang berfokus pada kebutuhan fungsional dan nonfungsional perangkat lunak tersebut. Uji coba ini dilakukan untuk menguji apakah fungsionalitas yang diidentifikasi pada tahap kebutuhan benar-benar diimplementasi dan bekerja seperti yang semestinya.
5.1 Uji Coba Fungsional
Pada bagian ini terdapat tiga proses uji coba, yaitu pengubahan file format dokumen SRS, tagging kata menggunakan Part-Of-Speech Tagging, dan terakhir menampilkan hasil ekstraksi metadata dalam bentuk RDF. Untuk ketiga uji coba ini disediakan dua data input, yaitu dokumen SRS yang dimasukkan berbahasa Inggris dan sesuai dengan format IEEE dan dokumen SRS yang dimasukkan tidak berbahasa Inggris dan / atau tidak sesuai dengan format IEEE.
Tabel 4.1 Pengujian dengan data Input dokumen SRS yang berbahasa Inggris dan sesuai dengan format
IEEE
No Uji Coba Hasil
1 Pengubahan file format dokumen SRS Dokumen terbaca
2 Tagging kata
menggunakan Part-Of- Speech Tagging
Tag kata didapatkan 3 Penampilkan hasil
ekstraksi metadata dalam bentuk RDF
Metadata
didapatkan secara lengkap
Gambar 4.2 Dokumen SRS yang memenuhi syarat
Gambar 4.2 Uji coba pengubahan file format dengan data input dokumen SRS memenuhi syarat
Gambar 4.4 Uji coba tagging kata dengan data input dokumen SRS yang berbahasa Inggris dan sesuai
dengan format IEEE
Gambar 4.3 Uji coba melihat metadata dengan data input dokumen SRS yang berbahasa Inggris dan sesuai
dengan format IEEE
Tabel 4.2 Pengujian dengan data Input dokumen SRS yang tidak berbahasa Inggris dan / tidak sesuai dengan
format IEEE
No Uji Coba Hasil
1 Pengubahan file format dokumen SRS Dokumen terbaca
Himmatul Azizah - 5107100048 Page 7
2 Tagging kata
menggunakan Part-Of- Speech Tagging
Tag kata tidak didapatkan 3 Penampilkan hasil
ekstraksi metadata dalam bentuk RDF
Metadata tidak didapatkan
Gambar 4.4 Dokumen SRS yang tidak memenuhi syarat
Gambar 4.5 Uji coba pengubahan file format dengan menggunakan data input dokumen SRS tidak
memenuhi syarat
Gambar 4.6 Pesan error pada uji coba tag kata dengan data input dokumen SRS yang dimasukkan berbahasa Indonesia dan / atau tidak sesuai dengan format IEEE
Gambar 4.7 Uji coba melihat metadata dengan data input dokumen SRS yang dimasukkan berbahasa Indonesia dan / atau tidak sesuai dengan format IEEE
5.2 Uji Coba Non Fungsional
Pada bagian ini hanya terdapat satu pengujian, yaitu pengujian waktu yang dibutuhkan selama program berlangsung.
Tabel 4.3 Uji coba waktu yang dibutuhkan untuk menganalisa dokumen SRS hingga didapatkan
metadata dalam bentuk file RDF No Data Input Waktu Proses
1 Dokumen yang diproses berukuran 1,855 Kb.
16 menit 03 detik 947 milidetik 2 Dokumen yang
diproses berukuran 4,213 Kb.
19 menit 41 detik 80 milidetik
5.3 Analisa Uji Coba
Dari uji coba yang telah dilakukan, hasil dari evaluasi uji coba tersebut adalah sebagai berikut : 1. Proses pengubahan file format dokumen SRS
telah berhasil, dan berjalan seperti yang diharapkan. Hal ini terlihat pada uji coba [TC- FR-01], dimana detil uji coba dipaparkan secara rinci.
2. Proses tagging kata menggunakan part-of- speech tagging telah berhasil, dan berjalan seperti yang diharapkan. Hal ini terlihat pada uji coba [TC-FR-02], dimana detil uji coba dipaparkan secara rinci.
3. Proses menampilkan hasil ekstraksi metadata dalam bentuk file RDF telah berhasil, dan berjalan seperti yang diharapkan. Hal ini terlihat pada uji coba [TC-FR-03], dimana detil uji coba dipaparkan secara rinci.
4. Proses ekstraksi fitur kebutuhan fungsional telah berhasil dijalankan, dan berjalan sesuai harapan.
Hal ini terlihat pada uji coba [TC-FR-04] , dimana detil uji coba dipaparkan secara rinci.
Himmatul Azizah - 5107100048 Page 8
5. Proses ekstraksi fitur kebutuhan non fungsionaltidak berhasil dijalankan. Hal ini terlihat pada uji coba [TC-FR-05] , dimana detil uji coba dipaparkan secara rinci. Pada proses ini terjadi kesalahan pada sistem karena bagian kebutuhan non fungsional tidak dikenali oleh sistem. Perlu dilakukan proses debugging untuk mengetahui kesalahan apa yang terjadi.
6. Proses ekstraksi fitur use case telah berhasil dijalankan, akan tetapi berjalan tidak sesuai dengan harapan. Perlu dilakukan proses lebih lanjut agar fitur use case yang dihasilkan sesuai dengan harapan. Hal ini terlihat pada uji coba [TC-FR-06], dimana detil uji coba dipaparkan secara rinci.
7. Proses ekstraksi fitur aktor telah berhasil dijalankan, akan tetapi berjalan tidak sesuai dengan harapan. Perlu dilakukan proses lebih lanjut agar fitur aktor yang dihasilkan sesuai dengan harapan. Hal ini terlihat pada uji coba [TC-FR-07] ], dimana detil uji coba dipaparkan secara rinci.
8. Waktu yang dibutuhkan untuk melakukan keseluruhan proses tidak berhasil mencapai harapan yang diinginkan seperti yang terlihat pada [TC-NFR-01].
6. KESIMPULAN
Kesimpulan yang dapat diambil dari hasil pengamatan selama perancangan, implementasi, dan proses uji coba sistem yang dilakukan adalah sebagai berikut :
1. Membuat sebuah kakas bantu untuk mengekstraksi sebuah dokumen SRS telah dilakukan seperti yang terlihat pada uji coba [TC-FR-01] sampai dengan [TC-FR-03].
2. Hasil fitur yang dapat diekstraksi adalah kebutuhan fungsional, kebutuhan non fungsional, use case, dan aktor.
3. Keakurasian sistem dalam mengekstraksi kebutuhan fungsional adalah 100%, untuk kebutuhan non fungsional 0%, untuk use case 100%, dan untuk aktor 4,31%. Hal ini terlihat dari hasil uji coba pada [TC-FR-04] sampai dengan [TC-FR-07]
4. Waktu yang dibutuhkan untuk mengekstraksi sebuah dokumen SRS ditentukan dari besarnya ukuran file dokumen yang ingin diproses. Hal ini sesuai dengan hasil uji coba [TC-NFR-01]
5. Use case dan aktor dari sebuah perangkat lunak yang akan dibangun dapat ditemukan pada bagian kebutuhan fungsional pada dokumen SRS.
7. DAFTAR PUSTAKA
[1].
Ahia, Airin dan Tabibi. 2008. Extracting Summary – level Use – Cases Descriptions by Text-Partitioning. 11th Workshop on Requirements Engineering.[2]. Baca, Murtha. 2008. Introduction to Metadata: Revised Edition. Los Angeles : The Getty Research Institute.
[3].
Lami, Giuseppe. 2005. QuARS: A Tool for Analyzing Requirements. Pittsburgh, PA USA: Carnegie Mellon Software Engineering Institute.[4]. Muslimin, A., Wibisono, W., dan Siahaan, D.
O.. 2006. Semantic Web Constructin For Image Retrieval System From Internet Sport News. Surabaya : Informatics Department, Faculty of Information Technology, Sepuluh Nopember Institute of Technology.
[5]. Pressman, Roger. 2010. Software Engineering : A practitioner’s Approach 7th Edition. Newyork USA : Mc Graw Hill.
