EKSTRAKSI METADATA DOKUMEN SOFTWARE REQUIREMENT SPECIFICATION (SRS)

PAPER TUGAS AKHIR PERIODE JULI 2011

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

Himmatul Azizah - 5107100048

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

Page 1

PAPER TUGAS AKHIR PERIODE JULI 2011 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 memiliki detail perangkat lunak. perangkat lunak

SRS merupakan dokumen yang penjelasan keseluruhan aspek Di dalamnya terdapat informasi 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 kebutuhankebutuhan 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.

Page 2

PAPER TUGAS AKHIR PERIODE JULI 2011 3) Kebutuhan kualitas sistem Bagian ini menjelaskan secara spesifik faktorfaktor dari kualitas sistem yang tidak berhubungan dengan kebutuhan fungsional yang didokumentasikan melalui use case. 4) Batasan sistem Bagian ini menjelaskan mengenai batasanbatasan 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 nonfungsional 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. Use case 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.

Aktor

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 katakata 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→←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

Page 3

PAPER TUGAS AKHIR PERIODE JULI 2011 kalimat yang menjelaskan tentang sesuatu yang menjadi 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 bentuk objek :

RDF

direpresentasikan

dalam

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.

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.

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

Gambar 5. Use Case Diagram

3.3

Langkah Kerja

Langkah kerja sistem ini diperlihatkan pada Gambar 6.

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.


Page 4

PAPER TUGAS AKHIR PERIODE JULI 2011 Mulai Masukkan Dokumen

tidak

Docx ٰ→ XML Dokumen ٰ→ Subdokumen

Apakah dokumen sesuai dengan syarat data input? ya Tag kata Tagging setiap kata yang ada padadokumen

Menu apa yang ingin dipilih?

Lihat Metadata Ambil kalimat pada bagian kebutuhan fungsional dan non fungsional

Beri bobot Beri bobot pada setiap kata yang ada pada dokumen

Apakah metadata ditemukan?

Pisahkan kata benda dan kata kerja pada bagian kebutuhan fungsional Beri bobot pada kata kerja dan kata benda ya

Buat skema RDF

Masukkan kalimat pada bagian kebutuhan fungsional dan kebutuhan non fungsional, serta kata kerja sebagai use case dan kata benda sebagai aktor pada skema RDF tidak

Selesai

Simpan metadata file dalam bentuk file RDF

File RDF

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 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 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 10. Implementasi RDF

Page 5

PAPER TUGAS AKHIR PERIODE JULI 2011 5.

UJI COBA

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

Gambar 4.2 Uji coba pengubahan file format dengan data input dokumen SRS memenuhi syarat

Tabel 4.1 Pengujian dengan data Input dokumen SRS yang berbahasa Inggris dan sesuai dengan format IEEE

No 1 2 3

Uji Coba Pengubahan file format dokumen SRS Tagging kata menggunakan Part-OfSpeech Tagging Penampilkan hasil ekstraksi metadata dalam bentuk RDF

Hasil Dokumen terbaca Tag kata didapatkan Metadata didapatkan secara lengkap

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

Gambar 4.2 Dokumen SRS yang memenuhi syarat

Tabel 4.2 Pengujian dengan data Input dokumen SRS yang tidak berbahasa Inggris dan / tidak sesuai dengan format IEEE

No 1


Uji Coba Pengubahan file format dokumen SRS

Hasil Dokumen terbaca

Page 6

PAPER TUGAS AKHIR PERIODE JULI 2011 2 3

Tagging kata menggunakan Part-OfSpeech Tagging Penampilkan hasil ekstraksi metadata dalam bentuk RDF

Tag kata tidak didapatkan Metadata tidak didapatkan

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.

Gambar 4.4 Dokumen SRS yang tidak memenuhi syarat

Tabel 4.3 Uji coba waktu yang dibutuhkan untuk menganalisa dokumen SRS hingga didapatkan metadata dalam bentuk file RDF

No 1 2

5.3

Data Input Dokumen yang diproses berukuran 1,855 Kb. Dokumen yang diproses berukuran 4,213 Kb.

Waktu Proses 16 menit 03 detik 947 milidetik

19 menit 41 detik 80 milidetik

Analisa Uji Coba

Dari uji coba yang telah dilakukan, hasil dari evaluasi uji coba tersebut adalah sebagai berikut : 1.

Gambar 4.5 Uji coba pengubahan file format dengan menggunakan data input dokumen SRS tidak memenuhi syarat

2.

3.

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


4.

Proses pengubahan file format dokumen SRS telah berhasil, dan berjalan seperti yang diharapkan. Hal ini terlihat pada uji coba [TCFR-01], dimana detil uji coba dipaparkan secara rinci. Proses tagging kata menggunakan part-ofspeech tagging telah berhasil, dan berjalan seperti yang diharapkan. Hal ini terlihat pada uji coba [TC-FR-02], dimana detil uji coba dipaparkan secara rinci. 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. 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.

Page 7

PAPER TUGAS AKHIR PERIODE JULI 2011 5.

6.

7.

8.

6.

Proses ekstraksi fitur kebutuhan non fungsional tidak 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. 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. 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. Waktu yang dibutuhkan untuk melakukan keseluruhan proses tidak berhasil mencapai harapan yang diinginkan seperti yang terlihat pada [TC-NFR-01].

[2]. [3].

[4].

[5].

Baca, Murtha. 2008. Introduction to Metadata: Revised Edition. Los Angeles : The Getty Research Institute.

Lami, Giuseppe. 2005. QuARS: A Tool for Analyzing Requirements. Pittsburgh, PA USA: Carnegie Mellon Software Engineering Institute. 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. Pressman, Roger. 2010. Software Engineering : A practitioner’s Approach 7th Edition. Newyork USA : Mc Graw Hill.

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 Workshop on Text-Partitioning. 11th Requirements Engineering.


Page 8

EKSTRAKSI METADATA DOKUMEN SOFTWARE REQUIREMENT SPECIFICATION (SRS)

Recommend Documents