BAB 1
PENDAHULUAN
1.1
Latar BelakangAnalisis kualitas kebutuhan perangkat lunak merupakan fase penting dalam sebuah proyek pengembangan perangkat lunak (Bucchiarone et al., 2008).
Kebutuhan perangkat lunak dapat dikatakan berkualitas jika kebutuhan tersebut bersifat Specific, Measurable, Attainable, Realisable, dan Traceable (SMART) (Mike & Berry, 1995). Menciptakan kebutuhan perangkat lunak yang berkualitas adalah langkah awal untuk menciptakan perangkat lunak yang berkualitas pula (Giuseppe, 2005).
Penelitian yang dilakukan oleh The Standish Group di tahun 1995 (Standish, 1995) menunjukkan bahwa kegagalan dalam suatu proyek pengembangan perangkat lunak berakar dari kesalahan yang terjadi pada proses penspesifikasian kebutuhan. Pada prakteknya, spesifikasi kebutuhan dinyatakan dalam bahasa alamiah. Hal ini membuat spesifikasi tersebut menjadi tercemar oleh berbagai bentuk ambiguitas, yang pada akhirnya berkontribusi pada kegagalan kritis dalam tahapan proses pengembangan berikutnya. Untuk itu, perlu suatu metode untuk mendeteksi sedini mungkin ambiguitas yang mungkin muncul atau terkandung di dalam suatu spesifikasi kebutuhan.
Bagi seorang pengembang perangkat lunak, memeriksa secara manual satu demi satu pernyataan kebutuhan yang sedang disusun merupakan pekerjaan yang memakan banyak waktu dan tenaga. Oleh karena itu para peneliti giat melakukan penelitian untuk menciptakan kakas bantu yang mampu mendeteksi ambiguitas kebutuhan secara otomatis dengan tingkat akurasi yang sebaik mungkin.
Beberapa penelitian yang terkait dengan analisis ambiguitas kebutuhan perangkat lunak adalah sebagai berikut: pertama, penelitian yang dilakukan oleh (Wilson, 1997) dan (Wilson et al., 1996) yang menghasilkan sebuah kakas bantu bernama Automated Requirements Measurement (ARM). ARM merupakan sebuah kakas bantu yang mampu menganalisis kualitas kebutuhan perangkat lunak secara otomatis yang dikembangkan oleh Software Assurance Technology Center (SATC)
– NASA. Para peneliti membuat 9 kategori indikator kualitas kebutuhan perangkat lunak, yaitu:
1 Keharusan (imperatives), 2 Kelanjutan (continuances), 3 Arahan (directives),
4 Pilihan (options),
5 Frasa lemah (weak phrases), 6 Ukuran (size),
7 Kedalaman spesifikasi (specification depth), 8 Keterbacaan (readability), dan
9 Struktur teks (text structure)
Lima pertama dari kategori tersebut berdasarkan frekwensi munculnya kata-kata tertentu dalam konteks ambiguitas. Sedangkan empat sisanya berhubungan dengan pengorganisasian dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Kelemahan kakas bantu ini yaitu mengabaikan penggunaan metode- metode NLP terkini (misal: analisis morfologi dan analisis sintaktik) yang tentunya bisa meningkatkan performa kakas bantu tersebut dalam menganalisis ambiguitas kebutuhan perangkat lunak.
Kedua, sekelompok peneliti dari Formal Method and Tool (FMT) Group memperkenalkan kakas bantu yang bernama Quality Analyzer of Requirements Specifications (QuARS)(Fabbrini et al., 2001)(Giuseppe, 2005). QuARS didasarkan pada model kualitas yang mengukur kemampuan untuk dapat diuji (testability), kelengkapan (completeness), kemampuan untuk dapat dimengerti (understandability), dan konsistensi (consistency) dari spesifikasi kebutuhan perangkat lunak yang ditulis dalam bahasa alamiah. Kakas bantu ini menganalisis struktur dokumen Spesifikasi Kebutuhan Perangkat Lunak serta sintaktik dan semantik dari tiap-tiap pernyataan kebutuhan. Struktur dokumen dibandingkan terhadap dokumen standar SKPL dari Rational Unified Process (RUP), sedangkan kepatuhan sintaktik dan semantik diperiksa terhadap satu set kata kunci yang telah ditetapkan yang merupakan kata-kata yang tidak diinginkan. Tiap-tiap domain permasalahan membutuhkan repositori khusus yang memuat kata-kata yang tidak diinginkan pada ruang lingkup permasalahan tersebut. Hal ini sekaligus sebagai
kelemahan kakas bantu ini karena ruang lingkup repositori kata-kata yang tidak diinginkan bersifat terbatas.
Ketiga, penelitian berupa tesis yang dilakukan oleh (Hussain, 2007) dari Universitas Concordia, Canada. Penelitian ini menghasilkan sebuah kakas bantu yang bernama Requirements Specification Ambiguity Checker (ReqSAC). Di dalam buku tesisnya ia menuliskan bahwa tujuan dari penelitiannya adalah untuk menghasilkan sebuah metode beserta kakas bantu yang mampu mendeteksi secara otomatis ambiguitas kebutuhan pada fase elisitasi. Untuk mendeteksi ambiguitas digunakan metode klasifikasi teks dengan menggunakan algoritma C4.5 di dalamnya. Kualitas, kuantitas, dan ruang lingkup data latih akan sangat menentukan performa ReqSAC dalam menganalisis ambiguitas kebutuhan perangkat lunak. Jumlah ahli yang terlibat akan menentukan kualitas data latih.
Sedangkan di dalam penelitian ini hanya melibatkan tiga orang ahli untuk membentuk data latih pada analisis tingkat kalimat (sentence-level analysis).
Ditinjau dari sisi kuantitas dan ruang lingkup data latih yang digunakan masih bersifat terbatas pada 25 buah topik proyek perangkat lunak. Kemudian yang tak kalah menariknya adalah repositori kata-kata yang bersifat ambigu diciptakan berdasarkan data latih yang digunakan. Hal ini sekaligus sebagai kelemahan ReqSAC karena repositori yang dihasilkan ruang lingkupnya masih bersifat terbatas.
Dalam penelitian ini diajukan sebuah metode untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements dengan menggunakan teknik pengolahan bahasa alamiah dan dibantu oleh WordNet sebagai repositori kata-kata yang tidak diinginkan. Dengan ini diharapkan ruang lingkup dari daftar kata-kata yang tidak diinginkan menjadi lebih luas. Penelitian ini juga diharapkan menghasilkan sebuah metode yang dapat mengidentifikasi kebutuhan yang bersifat ambigu maupun tidak ambigu dengan indeks Kappa yang lebih baik dari penelitian sebelumnya (Hussain, 2007), yaitu lebih besar dari 0.8475.
1.2 Perumusan Masalah
Perumusan masalah dalam penelitian ini yaitu:
1. Aturan apa saja yang perlu dibangun untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements?
2. Bagaimana memanfaatkan WordNet sebagai repositori kata-kata yang tidak diinginkan?
Batasan masalah dalam penelitian ini yaitu:
1. Bahasa alamiah yang digunakan adalah bahasa Inggris
2. Analisis difokuskan pada kriteria kebutuhan yang spesifik saja berdasarkan acuan SMART Requirements
1.3 Tujuan Penelitian
Tujuan dari penelitian ini adalah untuk menghasilkan metode yang dapat digunakan untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements dengan ruang lingkup dari daftar kata-kata yang tidak diinginkan lebih luas daripada penelitian sebelumnya (Hussain, 2007) serta dengan indeks Kappa yang lebih baik yaitu lebih besar dari 0.8475. Manfaat dari penelitian ini adalah untuk membantu pengembang perangkat lunak dalam menyusun kebutuhan perangkat lunak yang berkualitas, dalam hal ini yaitu kebutuhan perangkat lunak yang tidak bersifat ambigu. Kontribusi dari penelitian ini adalah tersedianya metode yang dapat digunakan untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements dengan ruang lingkup dari daftar kata-kata yang tidak diinginkan lebih luas daripada penelitian sebelumnya serta dengan indeks Kappa yang lebih baik yaitu lebih besar dari 0.8475 (Hussain, 2007).
BAB 2
KAJIAN PUSTAKA
2.1 Ambiguitas
Definisi ambiguitas menurut Kamus Besar Bahasa Indonesia adalah sebagai berikut: “Sifat atau hal yang bermakna dua atau kemungkinan yang mempunyai dua pengertian”. Berikut dipaparkan dua buah contoh kalimat ambigu di dalam spesifikasi kebutuhan perangkat lunak (Hussain, 2007):
1. “Most commonly, the orders are matched in price/time priority: The order with the better price has a higher priority than an order with a worse price.” 2. “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.”
Pada contoh yang pertama, sangat sulit untuk menentukan secara pasti apa yang dimaksud dengan better dan worse price. Sedangkan pada contoh yang kedua, tidak dijelaskan secara spesifik bagaimana memverifikasi perubahan pada cells untuk konsistensi dan correctness.
2.2 Kebutuhan Perangkat Lunak
Kebutuhan sebuah sistem adalah deskripsi layanan yang disediakan oleh sistem serta batasan-batasan operasionalnya. Kebutuhan tersebut merefleksikan kebutuhan klien terhadap sistem yang dapat memberikan jalan keluar untuk beberapa permasalahan. Proses menemukan, menganalisis, mendokumentasikan, dan mengecek layanan dan batasan-batasan operasional dari sebuah sistem dikenal dengan istilah rekayasa kebutuhan.
Kebutuhan fungsional adalah sebuah pernyataan tentang layanan apa saja yang harus disediakan oleh sistem, bagaimana reaksi sistem terhadap sebuah masukan, serta bagaimana perilaku sistem pada situasi tertentu. Sedangkan
kebutuhan non-fungsional adalah pernyataan tentang batasan-batasan layanan yang disediakan oleh sistem.
Tujuan yang ingin dicapai oleh proses rekayasa kebutuhan adalah untuk membuat dan memelihara dokumen kebutuhan sistem. Proses rekayasa kebutuhan terdiri dari empat subproses. Feasibility study fokus pada penilaian apakah sebuah sistem layak untuk dibangun atau dikembangkan. Menemukan kebutuhan adalah tugas dari requirements elicitation and analysis. Kemudian setelah semua kebutuhan berhasil diidentifikasi, maka subproses selanjutnya adalah requirements specifications, yaitu menuliskan semua kebutuhan tersebut kedalam sebuah bentuk standar. Terakhir adalah subproses requirements validation yang bertugas untuk memvalidasi semua kebutuhan yang telah ditulis sehingga dapat menghasilkan sebuah dokumen kebutuhan sistem.
2.3 Penelitian-Penelitian Sebelumnya
Penelitian yang dilakukan di sini erat kaitannya dengan beberapa penelitian sebelumnya yang berhubungan dengan analisis ambiguitas kebutuhan perangkat lunak.
2.3.1 Automated Requirements Measurement (ARM)
ARM merupakan sebuah kakas bantu yang mampu menganalisis kualitas kebutuhan perangkat lunak secara otomatis yang dikembangkan oleh Software Assurance Technology Center (SATC) – NASA (Wilson, 1997)(Wilson et al., 1996). Para peneliti membuat 9 kategori indikator kualitas kebutuhan perangkat lunak, yaitu:
1. Keharusan (imperatives), 2. Kelanjutan (continuances), 3. Arahan (directives),
4. Pilihan (options),
5. Frasa lemah (weak phrases), 6. Ukuran (size),
7. Kedalaman spesifikasi (specification depth), 8. Keterbacaan (readability), dan
9. Struktur teks (text structure)
Lima pertama dari kategori tersebut berdasarkan frekwensi munculnya kata-kata tertentu dalam konteks ambiguitas. Sedangkan empat sisanya berhubungan dengan pengorganisasian dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Kelemahan kakas bantu ini yaitu mengabaikan penggunaan metode- metode NLP terkini (misal: analisis morfologi dan analisis sintaktik) yang tentunya bisa meningkatkan performa kakas bantu tersebut dalam menganalisis ambiguitas kebutuhan perangkat lunak.
2.3.2 Quality Analyzer of Requirements Specifications (QuARS)
Sekelompok peneliti dari Formal Method and Tool (FMT) Group memperkenalkan kakas bantu yang bernama Quality Analyzer of Requirements Specifications (QuARS)(Fabbrini et al., 2001)(Giuseppe, 2005). QuARS didasarkan pada model kualitas yang mengukur kemampuan untuk dapat diuji (testability), kelengkapan (completeness), kemampuan untuk dapat dimengerti (understandability), dan konsistensi (consistency) dari spesifikasi kebutuhan perangkat lunak yang ditulis dalam bahasa alamiah. Kakas bantu ini menganalisis struktur dokumen SKPL serta sintaktik dan semantik dari tiap-tiap pernyataan kebutuhan. Struktur dokumen dibandingkan terhadap dokumen standar SKPL dari Rational Unified Process (RUP), sedangkan kepatuhan sintaktik dan semantik diperiksa terhadap satu set kata kunci yang telah ditetapkan yang merupakan kata- kata yang tidak diinginkan. Tiap-tiap domain permasalahan membutuhkan repositori khusus yang memuat kata-kata yang tidak diinginkan pada ruang lingkup permasalahan tersebut. Hal ini sekaligus sebagai kelemahan kakas bantu ini karena ruang lingkup repositori kata-kata yang tidak diinginkan bersifat terbatas.
Arsitektur sistem QuARS ditunjukkan oleh Gambar 2.1 di bawah ini (Giuseppe, 2005).
Gambar 2.1 Arsitektur Sistem QuARS
Penjelasan tiap-tiap komponennya adalah sebagai berikut:
Syntax Parser
Menggunakan aplikasi Minipar. Syntax Parser menguraikan setiap kalimat dengan cara sebagai berikut:
”The system shall provide the manual of the user.”
1 (the ~ Det 2 det) 2 (system ~N 4 s) 3 (shall ~ Aux 4 aux)
4 (provide ~V E0 i (gov fin)) 5 (the ~ Det 6 det)
6 (manual ~N 4 obj) 7 (of ~ Prep 6 mod) 8 (the ~ Det 9 det) 9 (user ~ N 7 pcomp-n)
Baris 1: ”The” adalah determiner dari ”system” pada baris 2.
Baris 2: ”system” adalah noun dan subjek bagi verb pada baris 4.
Baris 3: ”shall” adalah auxiliary dari verb pada baris 4.
Baris 4: ”provide” adalah verb utama
Baris 5: ”the” adalah determiner dari noun yang ada di baris 6.
Baris 6: ”manual” adalah noun dan bertindak sebagai objek dari verb pada baris 4.
Baris 7: ”of” adalah preposition dari terminologi pada baris 6 sekaligus sebagai modifier-nya.
Baris 8: ”the” adalah determiner dari terminologi pada baris 9
Baris 9: ”user” adalah noun dan bertindak sebagai complement yang disebabkan oleh terminologi ”of” pada baris 7.
Lexical Parser
Lexical Parser mengidentifikasi kata dan frasa tertentu yang muncul dalam setiap kalimat. Hal ini digunakan untuk melakukan analisis morfologis dari kalimat dan untuk mendukung analisis berdasarkan deteksi istilah khusus atau kata-kata yang tidak diinginkan.
Indicators Detector
Indicators Detector merupakan komponen asli yang mendeteksi indikator- indikator yang telah ditetapkan (memanfaatkan hasil dari Syntax dan Lexical Parser) dan menuliskannya ke dalam file log.
Views Derivation
Cara kerjanya berdasarkan pertanyaan: ”Kalimat ini tergolong View apa?”
Dictionaries
Dictionaries adalah komponen pasif dari kakas ini. Berisi istilah-istilah yang dibutuhkan oleh komponen lainnya: Syntax Parser, Lexical Parser, dan Views Derivation. Dictionaries juga berfungsi sebagai repositori kata-kata yang tidak diinginkan.
2.3.3 Requirements Specification Ambiguity Checker (ReqSAC)
ReqSAC adalah sebuah kakas bantu untuk menganalisis ambiguitas yang terkandung di dalam kalimat pernyataan kebutuhan (Hussain, 2007). Di dalam buku tesisnya ia menuliskan bahwa tujuan dari penelitiannya adalah untuk menghasilkan sebuah metode beserta kakas bantu yang mampu mendeteksi secara otomatis ambiguitas kebutuhan pada fase elisitasi. Bagian yang berwarna abu-abu pada gambar 2.2 di bawah ini adalah ruang lingkup penelitiannya.
Gambar 2.2 Ruang Lingkup Penelitian (Hussain, 2007)
Untuk mendeteksi ambiguitas digunakan metode klasifikasi teks dengan menggunakan algoritma C4.5 di dalamnya. Langkah-langkah yang dilakukan yaitu:
1. Mengelompokkan secara manual pernyataan kebutuhan kedalam dua kelompok yaitu kelompok ambigu dan tidak ambigu. Pengelompokan ini dilakukan oleh tiga orang ahli rekayasa kebutuhan.
2. Membangun sentence classifier dan melakukan training menggunakan data yang dihasilkan pada langkah 1 di atas. Algoritma C4.5 diterapkan pada langkah ini sehingga menghasilkan decision tree yang mampu mengklasifikasikan pernyataan kebutuhan menjadi ambigu atau tidak ambigu.
Gambar 2.3 Decision Tree
Kualitas, kuantitas, dan ruang lingkup data latih akan sangat menentukan performa ReqSAC dalam menganalisis ambiguitas kebutuhan perangkat lunak.
Jumlah ahli yang terlibat akan menentukan kualitas data latih. Sedangkan di dalam penelitian ini hanya melibatkan tiga orang ahli untuk membentuk data latih pada analisis tingkat kalimat (sentence-level analysis). Ditinjau dari sisi kuantitas dan ruang lingkup data latih yang digunakan masih bersifat terbatas pada 25 buah topik proyek perangkat lunak. Kemudian yang tak kalah menariknya adalah repositori kata-kata yang bersifat ambigu diciptakan berdasarkan data latih yang digunakan. Hal ini sekaligus sebagai kelemahan ReqSAC karena repositori yang dihasilkan ruang lingkupnya masih bersifat terbatas.
Dalam penelitian ini diajukan sebuah metode untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements dengan menggunakan teknik pengolahan bahasa alamiah dan dibantu oleh WordNet sebagai repositori kata-kata yang tidak diinginkan. Dengan ini diharapkan ruang lingkup dari daftar kata-kata yang tidak diinginkan menjadi lebih luas. Penelitian ini juga diharapkan menghasilkan sebuah metode yang dapat mengidentifikasi kebutuhan yang bersifat ambigu maupun tidak ambigu dengan indeks Kappa yang lebih baik dari penelitian sebelumnya yaitu lebih besar dari 0.8475 (Hussain, 2007).
2.4 SMART Requirements
Kata ”SMART” dalam ”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 ambigu, konsisten, sederhana, dan tepat. Secara umum ada beberapa acuan yang direkomendasikan:
(a) Avoid phrases such as: "obviously", “clearly", "certainly"
(b) Avoid ambiguities such as "some", “several", "many"
(c) Avoid list terminators such as: "etc", "and so on", "such as"
(d) Ensure pronouns are clearly referenced, e.g. "When module A calls B its message history file is updated"
(e) When numbers are specified identify the units (f) Ensure all possible elements in a list are described (g) Use pictures to clarify understanding
(h) Ensure all system or project terms are defined in a glossary
(i) Consider placing individual requirements in a separate paragraph and individually numberered
(j) Ensure verbs such as "transmitted", "sent", "downloaded", "processed"
are qualified by precise explanations
(k) Only use the word "details" , "information", "data" in a requirement when you can describe or refer to precisely what they will be
(l) If the requirement is described by a prototype program ensure that specific program is documented
(m)When a term is defined in a glossary, substitute the definition in the text and then review the requirement
(n) No "To Be Defineds"
2. Measurable
Dalam konteks rekayasa kebutuhan, measurable berarti bahwa ketika sistem telah dibangun nantinya, pernyataan kebutuhan harus bisa
diverifikasi apakah sudah memenuhi atau belum. Secara umum ada beberapa acuan yang direkomendasikan:
(a) What other requirements need to be verified before this requirement?
(b) Can this requirement be verified as part of the verification for another requirement? If so, which one?
(c) How much data or what test cases are required?
(d) How much processing power is required?
(e) Can the test be conducted on one site?
(f) Can this requirement be tested in isolation?
3. Attainable
Attainable bermakna ”berdasarkan teori yang ada apakah sebuah pernyataan kebutuhan dapat dicapai atau tidak?”. Beberapa acuan yang direkomendasikan:
(a) Is there a theoretical solution to the problem?
(b) Has it been done before? If not, why not?
(c) Has a feasibility study been done?
(d) Is there an overiding constraint which prohibits this requirement?
(e) Are there physical constraints on the size of the memory, processor or peripherals?
(f) Are there environmental constraints such as temperature, compressed air?
4. Realisable
Dengan sumber daya yang dimiliki saat ini, ”apakah sebuah pernyataan kebutuhan bisa direalisasikan atau tidak?”. Beberapa acuan yang direkomendasikan:
(a) Determine who has responsibility for satisfying the requirement. Can they deliver? Can we afford to manage them?
(b) Are there sufficient resources?
(c) Is there sufficient time?
(d) Is there sufficient budget?
(e) Will we have to develop it ourselves?
(f) Can we reuse from other projects?
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. Beberapa hal yang sebaiknya dicantumkan di dalam spesifikasi:
(a) Originators of requirements (institutions or people) (b) Underlying assumptions
(c) Business justifications (d) Their criticality
BAB 3
METODE PENELITIAN
Di dalam bab ini dijelaskan langkah-langkah sistematis yang akan dilakukan untuk mencapai tujuan penelitian.
Gambar 3.1 Langkah-Langkah Penelitian
3.1 Studi Literatur
Pada tahap ini dipelajari beberapa paper, buku, dan sumber lain yang berkaitan dengan teori rekayasa kebutuhan perangkat lunak, pengolahan bahasa alamiah, WordNet, dan SMART Requirements. Disamping itu dipelajari pula beberapa penelitian sebelumnya yang terkait dengan analisis ambiguitas kebutuhan perangkat lunak sebagai related work penelitian ini. Hasil studi literatur dipaparkan secara rinci di dalam bab 2.
3.2 Pengidentifikasian Acuan SMART Requirements
Tahap ini adalah tahap pengidentifikasian acuan SMART Requirements yang bertujuan untuk menghasilkan aturan SMART. Aturan SMART ini nantinya akan disimpan di dalam repositori aturan SMART menggunakan DBMS MySQL.
Contoh aturan SMART yang dibangun adalah sebagai berikut:
Acuan: “Avoid ambiguities such as some, several, many” (Mike & Berry, 1995).
Berdasarkan acuan tersebut maka aturan SMART yang perlu dibangun adalah:
• Jika dalam sebuah kalimat terdapat pola some/DT + NNS, maka kalimat tersebut dapat dikategorikan ambigu. Contoh kalimat beserta Part of Speech (POS) untuk tiap-tiap katanya adalah: “The/DT system/NN provides/VBZ some/DT languages/NNS ./.”.
• Jika dalam sebuah kalimat terdapat pola several/JJ + NNS, maka kalimat tersebut dapat dikategorikan ambigu. Contoh kalimat beserta POS untuk tiap-tiap katanya adalah: “The/DT system/NN provides/VBZ several/JJ languages/NNS ./.”.
• Jika dalam sebuah kalimat terdapat pola many/JJ + NNS, maka kalimat tersebut dapat dikategorikan ambigu. Contoh kalimat beserta POS untuk tiap-tiap katanya adalah: “The/DT system/NN provides/VBZ many/JJ languages/NNS ./.”.
Tabel 3.1 menjelaskan simbol dan definisi english POS tag model Penn TreeBank yang digunakan di dalam penelitian ini.
Tabel 3.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 Didalam penelitian ini telah dihasilkan 52 buah aturan SMART yang disimpan di dalam Tabel AturanSmart.
Tabel 3.2 AturanSmart
id kata pos pos2
1 obviously RB JJ
2 obviously RB 0
3 clearly RB VBN
4 clearly RB VB
5 clearly RB 0
6 certainly RB JJ
7 certainly RB 0
8 some DT NNS
9 some JJ NNS
10 some DT 0
11 some JJ 0
12 several JJ NNS
13 several JJ 0
14 many JJ NNS
15 many JJ 0
16 clear JJ 0
17 easy JJ 0
18 strong JJ 0
19 good JJ 0
20 bad JJ 0
21 useful JJ 0
22 significant JJ 0
23 adequate JJ 0
24 recent JJ 0
25 similar JJ 0
26 similarly RB 0
27 possibly RB 0
28 tremendous JJ 0
29 frequently RB 0
30 specific JJ NNS
31 complex JJ NNS
32 quickly RB 0
33 finally RB 0
34 particular JJ NN
35 multiple JJ NNS
36 geographic JJ NNS
37 small JJ 0
38 quick JJ 0
39 next JJ NNS
40 next JJ NN
41 obvious JJ NNS
42 obvious JJ NN
43 short JJ 0
44 slow JJ 0
45 fat JJ NN
46 modest JJS NN
47 all DT VBG
48 meanwhile RB 0
49 ancillary JJ 0
50 common JJ 0
51 it PRP 0
52 routine JJ 0
Aturan nomor 1 sampai dengan 7 serta aturan nomor 41 dan 42 dibuat berdasarkan acuan: “Avoid phrases such as: obviously, clearly, certainly” (Mike &
Berry, 1995). Aturan nomor 8 sampai dengan 15 dibuat berdasarkan acuan:
”Avoid ambiguities such as some, several, many” (Mike & Berry, 1995). Aturan
nomor 16 sampai dengan 24, aturan nomor 28, 30, 31, aturan nomor 34 sampai dengan 36, aturan nomor 37 sampai dengan 40, dan aturan nomor 43 sampai dengan 46 dibuat berdasarkan acuan: ”Vagueness-revealing wordings (e.g. clear, easy, strong, good, bad, useful, significant, adequate, recent, ...)” (Gnesi et al., 2005). Aturan nomor 25, 26, 32, dan 33 dibuat berdasarkan acuan: ”Subjectivity- revealing wordings (e.g. similar, similarly,...)” (Gnesi et al., 2005). Aturan nomor 27 dan 29 dibuat berdasarkan acuan: ”Optionality-revealing words (e.g. possibly, in case, ...)” (Gnesi et al., 2005). Aturan nomor 47 dibuat berdasarkan acuan:
”Avoid writing S containing all, any, or both” (Tjong et al., 2008). Aturan nomor 48 dibuat berdasarkan acuan: ”Avoid writing S containing meanwhile, whereas, on the other hand, velc.” (Tjong et al., 2008). Aturan nomor 49 dan 52 dibuat berdasarkan acuan: ”Avoid writing S containing any vague adjective such as ancillary, relevant, routine, etc.” (Tjong et al., 2008). Aturan nomor 50 dibuat berdasarkan acuan: ”Avoid writing S containing the ambiguous identifier common, generic, customary, velc.” (Tjong et al., 2008). Aturan nomor 51 dibuat berdasarkan acuan: ”Avoid writing S that contains anaphora or pronoun such as they or them to refer to collective sets of people or objects, and it to a singular object.” (Tjong et al., 2008).
3.3 Perancangan Metode
Perancangan Metode adalah tahap inti dalam penelitian ini yang bertujuan untuk menghasilkan sebuah metode yang dapat digunakan untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements
Arsitektur sistem yang diajukan dalam penelitian ini ditunjukkan oleh gambar 3.2.
Gambar 3.2 Arsitektur Sistem
Daerah di dalam kotak adalah ruang lingkup dari tesis ini. Berikut dijelaskan tiap- tiap komponen dalam arsitektur sistem di atas.
3.3.1 Preprocessing
Stanford POS Tagger digunakan untuk menandai Part of Speech (POS) setiap kata pada pernyataan kebutuhan agar bisa diproses lebih lanjut oleh Modul SMART. Contoh masukan: “The system provides several languages.”. Keluaran yang dihasilkan yaitu: “The/DT system/NN provides/VBZ several/JJ languages/NNS ./.”, dimana DT adalah Determiner, NN adalah Noun (singular), VBZ adalah Verb, JJ adalah Adjective, dan NNS adalah Noun (plural). Keluaran tahap preprocessing akan sangat bermanfaat bagi Modul SMART karena didalam melakukan tugasnya, Modul SMART membutuhkan pola-pola yang dihasilkan oleh tahap preprocessing. Contoh: several/JJ languages/NNS. Caranya yaitu dengan mendeteksi apakah ada pola tersebut atau tidak. Jika ada,
maka pernyataan kebutuhan tersebut dinilai sebagai pernyataan kebutuhan yang bersifat ambigu.
3.3.2 Repositori Aturan SMART
Repositori aturan SMART dibuat menggunakan DBMS MySQL. Kata- kata yang bersifat ambigu beserta POS-nya disimpan di dalam tabel 3.2. Field pos2 menunjukkan pasangan POS yang membuat sebuah pola, yang terdapat di dalam sebuah kalimat, dikategorikan ambigu. Contoh pola: several/JJ + languages/NNS. Pola tersebut cocok dengan aturan nomor 12 pada tabel 3.2. Oleh karena itu, pola tersebut dikategorikan sebagai pola yang bersifat ambigu.
Nantinya, pada saat melakukan analisis, tidak semua aturan dieksekusi oleh Modul SMART. Hanya aturan-aturan yang memiliki POS yang sama dengan POS pada pola yang akan dieksekusi. Field pos nantinya digunakan oleh Modul SMART sebagai field kunci dalam proses pemilihan aturan yang tepat dalam rangka menganalisis ambiguitas sebuah pernyataan kebutuhan.
3.3.3 WordNet
Kata-kata yang bersifat ambigu yang muncul di dalam sebuah kalimat pernyataan kebutuhan ada kalanya tidak persis sama seperti kata-kata yang bersifat ambigu yang terdapat di dalam tabel 3.2. Suatu saat bisa saja sinonim dari kata-kata tersebut yang muncul di dalam kalimat pernyataan kebutuhan yang sedang dianalisis. Untuk mengantisipasi hal tersebut, maka digunakanlah WordNet untuk memperluas makna kata-kata yang bersifat ambigu yang terdapat di dalam tabel 3.2.
Jenis WordNet yang digunakan di dalam penelitian ini adalah RiTa WordNet yang telah dilengkapi dengan WordNet dictionary. RiTa WordNet bertugas untuk memberikan rekomendasi berupa sinonim dari kata-kata yang bersifat ambigu yang ada di dalam tabel 3.2. Dalam implementasinya menggunakan Java sebagai bahasa pemrograman. Kemudian untuk mencari sinonim digunakan metode getAllSynonyms.
Gambar 3.3 Metode getAllSynonyms
Tabel 3.3 menunjukkan sinonim dari kata-kata yang bersifat ambigu yang terdapat di dalam tabel 3.2.
Tabel 3.3 Sinonim Kata-kata Ambigu
Kata Sinonim
obviously Manifestly, plain, plainly, evidently, patently, apparently
clearly Distinctly, understandably, intelligibly, clear certainly Surely, sure
some Both, view, whatever, any, extraordinary, whatsoever, much, many, several
several Some, different, respective, individual, various, single
many More, legion, some, umteen, numerous
useful Reclaimable, reusable, eficacious, utile, profitable, functional, utilitarian, recyclable, serviceable, effectual, effective, expedient, multipurpose, useable, usable, helpful, utilizable
adequate Sufficient, decent, tolerable, equal, enough, capable, competent, passable, satisfactory
recent Past, new, late similarly Likewise
possibly Mayhap, perchance, perhaps, maybe, peradventure tremendous Marvellous, marvelous, terrible, big, fantastic,
grand, awful, extraordinary, howling, enormous, terrific, rattling, wondrous, frightful, wonderful, large
frequently Ofttimes, oftentimes, often, oft
specific Special, particularized, proper, unique, circumstantial, specified, limited, precise, peculiar,
particular, specialized, specialised, particularized quickly Apace, speedily, rapidly, promptly, quick, cursorily
finally Last, lastly, ultimately, eventually
particular Careful, primary, fussy, finicky, special, peculiar, specific, uncommon, especial, finical, fastidious, picky, exceptional
geographic True, geographical
routine Unremarkable, workaday, everyday, quotidian, ordinary, mundane
3.3.4 Modul SMART
Modul SMART adalah modul utama yang bertugas untuk menganalisis ambiguitas setiap pernyataan kebutuhan yang telah diproses sebelumnya. Proses analisis dibantu oleh repositori aturan SMART dan WordNet. Modul SMART memiliki 6 tugas utama, yaitu mendeteksi frase ambigu (et cetera, and so on, dan to be defineds sebagaimana yang direkomendasikan di dalam acuan SMART Requirements), mendeteksi ambiguitas tanpa bantuan sinonim dari WordNet (mendeteksi pola-pola ambigu berdasarkan tabel 3.2 tanpa bantuan sinonim dari WordNet), memilih aturan yang tepat, menanyakan sinonim kata ambigu kepada WordNet, mendeteksi ambiguitas dengan bantuan sinonim dari WordNet, dan mencetak hasil analisis.
Hasil analisis berupa kesimpulan apakah pernyataan kebutuhan yang telah dianalisis bersifat ambigu atau tidak ambigu. Jika ambigu, maka akan disertai catatan mengapa sebuah pernyataan kebutuhan dinilai ambigu dengan menunjukkan bagian mana yang bersifat ambigu.
Modul SMART dibangun menggunakan 3 buah class di dalam bahasa pemrograman Java, yaitu:
1. Class AturanSmartModel
Adalah sebuah class yang bertugas untuk mengambil isi tabel AturanSmart sesuai dengan kebutuhan class MainView.
Gambar 3.4 Potongan Kode di Dalam Class AturanSmartModel
2. Class RitaModels
Adalah sebuah class yang bertugas untuk menanyakan sinonim kata kepada RiTa WordNet.
Gambar 3.5 Potongan Kode di Dalam Class RitaModels
3. Class MainView
Adalah class utama yang bertugas untuk memilih aturan yang tepat, mendeteksi frase ambigu, mendeteksi ambiguitas tanpa bantuan sinonim dari WordNet, mendeteksi ambiguitas dengan bantuan sinonim dari WordNet, dan mencetak hasil analisis yang disertai dengan catatan mengapa sebuah pernyataan kebutuhan dinilai ambigu dengan menunjukkan bagian mana yang bersifat ambigu.
Gambar 3.6 Potongan Kode di Dalam Class MainView
3.4 Implementasi
Tahap implementasi merupakan tahap penerjemahan rancangan menjadi sebuah kakas bantu yang ditujukan untuk penyelesaian masalah. Selain itu dilakukan juga proses penerapan metode yang diajukan. Untuk membuat kakas bantu digunakan bahasa pemrograman Java. Dari tahapan ini dihasilkan sebuah kakas bantu untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan kriteria kebutuhan yang spesifik dalam acuan SMART Requirements.
Gambar 3.7 adalah snapshot kakas bantu yang telah dihasilkan pada tahap implementasi.
Gambar 3.7 Kakas Bantu
3.5 Uji Coba dan Evaluasi
Uji coba dan evaluasi dibahas lebih rinci di dalam Bab 4.
BAB IV
UJI COBA DAN EVALUASI
Untuk mengetahui performa metode yang diajukan di dalam penelitian ini, maka pengujian dilakukan dengan cara membandingkan pengetahuan yang dimiliki oleh seorang ahli dengan keluaran yang dihasilkan oleh kakas bantu. Ahli bertindak sebagai penguji pertama, kakas bantu bertindak sebagai penguji kedua.
Sedangkan analisis terhadap hasil pengujian dilakukan dengan menggunakan indeks Kappa (Cohen, 1960). Indeks Kappa menunjukkan proporsi kesepakatan antara dua penguji, dalam hal ini yaitu ahli sebagai penguji pertama dan kakas bantu sebagai penguji kedua. Indeks Kappa digunakan untuk menganalisis hasil pengujian karena tidak adanya data set dalam penelitian ini. Disamping itu, subyektivitas dari seorang ahli rekayasa kebutuhan sebagai penguji pertama adalah pertimbangan lain mengapa indeks Kappa digunakan untuk menganalisis hasil pengujian.
κ = P(A) – P(E) / 1 - P(E) …...(4.1)
κ = indeks Kappa
P(A) = proporsi berapa kali para penguji diamati setuju P(E) = proporsi berapa kali para penguji diharapkan setuju
Tabel 4.1 Interpretasi Nilai Indeks Kappa (Landis & Koch, 1977) Nilai Indeks Kappa Proporsi Kesepakatan
< 0 Rendah
0.01 – 0.20 Sedikit
0.21 – 0.40 Cukup
0.41 – 0.60 Sedang
0.61 – 0.80 Banyak
0.81 - 1 Hampir Sempurna
Dalam penelitian ini telah dilakukan 65 pengujian dengan menggunakan 65 buah kalimat pernyataan kebutuhan (Hussain, 2007). Untuk lebih detailnya
dapat dilihat di Lampiran A. Ruang lingkup untuk pengujian ini terbatas pada 25 domain permasalahan. Terjadi 1 kali misclassification dalam mendeteksi ambiguitas, dimana kalimat yang tidak ambigu menurut ahli dideteksi sebagai kalimat yang ambigu oleh kakas bantu yang telah dihasilkan pada tahap implementasi (Kalimat nomor 13 pada Lampiran A).
Berikut ditampilkan 4 pengujian beserta analisis terhadap hasilnya.
Snapshot 65 pengujian dapat dilihat di Lampiran B.
1. Kalimat: ”As the main incoming channel for cases is frequently the telephone, the system must have sub-second response times and be intuitive to use.”.
Gambar 4.1 Pengujian 1
Kalimat ”As the main incoming channel for cases is frequently the telephone, the system must have sub-second response times and be intuitive to use.” dideteksi
sebagai kalimat yang bersifat ambigu oleh kakas bantu karena kalimat tersebut mengandung pola frequently/RB yang bersifat ambigu.
2. Kalimat: ”A case may involve a single or multiple requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.”.
Gambar 4.2 Pengujian 2
Kalimat ”A case may involve a single or multiple requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.” dideteksi sebagai kalimat yang bersifat ambigu oleh kakas bantu karena kalimat tersebut mengandung pola multiple/JJ + NNS yang bersifat ambigu.
3. Kalimat: ”A Flexible Manufacturing System (FMS) is a computerized factory production entity, composed of numerically controlled machines, an automatic inventory system for storing raw, temporary in-process, and finished pieces, and an automatic guided vehicle system (AGV) for moving pieces, which can operate on different types of pieces.”.
Gambar 4.3 Pengujian 3
Kalimat tersebut dideteksi sebagai kalimat yang ambigu oleh kakas bantu, namun ahli menilainya sebagai kalimat yang tidak ambigu. Terjadi misclassification.
4. Kalimat: ”If an idle machine is found, the piece is transported there; otherwise, the piece is moved to the temporary store Store_tmp.”.
Gambar 4.4 Pengujian 4
Kalimat tersebut dideteksi sebagai kalimat yang tidak ambigu oleh kakas bantu karena semua aturan berhasil dilewati.
Tabel 4.2 Jawaban Ahli dan Kakas Bantu
Kakas Bantu
Ambigu Tidak Ambigu
Ahli Ambigu 42 0
Tidak Ambigu 1 22
Setiap pernyataan kebutuhan diuji oleh ahli dan sebuah kakas bantu. Ahli maupun kakas bantu memiliki dua kemungkinan jawaban: ambigu atau tidak ambigu. Berdasarkan tabel 4.2 di atas terlihat bahwa 42 buah pernyataan kebutuhan dinyatakan ambigu oleh ahli maupun kakas bantu dan 22 buah
pernyataan kebutuhan dinyatakan tidak ambigu. Berdasarkan data tersebut maka P(A) = (42 + 22) / 65 = 0.9846. Kemudian untuk menghitung P(E) dilakukan dengan cara sebagai berikut:
1. Ahli menjawab ambigu sebanyak 42 kali dan tidak ambigu sebanyak 23 kali, maka prosentase ahli menjawab ambigu = 64.61 %
2. Kakas bantu menjawab ambigu sebanyak 43 kali dan tidak ambigu sebanyak 22 kali, maka prosentase kakas bantu menjawab ambigu = 66.15
%
3. Probabilitas para penguji menjawab ambigu adalah 0.6461 * 0.6615 = 0.4273
4. Probabilitas para penguji menjawab tidak ambigu adalah 0.3539 * 0.3385
= 0.1197
5. P(E) = 0.4273 + 0.1197 = 0.547
Setelah itu nilai κ (indeks Kappa) dapat ditentukan dengan mudah:
κ = ( 0.9846 – 0.547) / (1-0.547) = 0.9660. Hal ini menandakan bahwa pada ruang lingkup 25 domain permasalahan tersebut, metode yang diajukan didalam penelitian ini memiliki performa yang lebih baik.
Jika tanpa menggunakan WordNet, performa metode tidak sebaik performa metode dengan menggunakan WordNet. Berikut ditampilkan analisis secara lengkap:
Tabel 4.3 Jawaban Ahli dan Kakas Bantu Tanpa WordNet Kakas Bantu
Ambigu Tidak Ambigu
Ahli Ambigu 31 12
Tidak Ambigu 0 22
Berdasarkan tabel 4.3 di atas terlihat bahwa Terjadi 12 kali misclassification dalam mendeteksi ambiguitas, dimana kalimat yang ambigu menurut ahli, dideteksi sebagai kalimat yang tidak ambigu oleh kakas bantu (Kalimat nomor 8, 13, 15, 17, 22, 24, 27, 28, 35, 38, 41, dan 44 pada Lampiran A). Indeks Kappa dihitung dengan cara mencari nilai P(A) terlebih dahulu. P(A) =
(31 + 22) / 65 = 0.8153. Kemudian untuk menghitung P(E) dilakukan dengan cara sebagai berikut:
(a) Ahli menjawab ambigu sebanyak 43 kali dan tidak ambigu sebanyak 22 kali, maka prosentase ahli menjawab ambigu = 66.15 %
(b) Kakas bantu menjawab ambigu sebanyak 31 kali dan tidak ambigu sebanyak 34 kali, maka prosentase kakas bantu menjawab ambigu = 47.69%
(c) Probabilitas para penguji menjawab ambigu adalah 0.6615 * 0.4769 = 0.3154
(d) Probabilitas para penguji menjawab tidak ambigu adalah 0.3385 * 0.5231
= 0.1770
(e) P(E) = 0.3154 + 0.1770 = 0.4924
Setelah itu nilai κ (indeks Kappa) dapat ditentukan dengan mudah:
κ = ( 0.8153 – 0.4924) / (1-0.4924) = 0.3229 / 0.5076 = 0.6361
Untuk mengetahui apakah metode yang diajukan didalam penelitian ini mampu menganalisis ambiguitas diluar ruang lingkup 25 domain permasalahan (Hussain, 2007), maka dilakukan pengujian dengan menggunakan 26 buah kalimat yang berada diluar ruang lingkup 25 domain permasalahan tersebut (Lampiran C). Berikut ditampilkan analisis secara lengkap:
Tabel 4.4 Jawaban Ahli dan Kakas Bantu
Kakas Bantu
Ambigu Tidak Ambigu
Ahli Ambigu 15 0
Tidak Ambigu 1 10
Berdasarkan tabel 4.4 di atas terlihat bahwa terjadi 1 kali misclassification dalam mendeteksi ambiguitas, dimana kalimat yang tidak ambigu menurut ahli, dideteksi sebagai kalimat yang ambigu oleh kakas bantu. Indeks Kappa dihitung dengan cara mencari nilai P(A) terlebih dahulu. P(A) = (15 + 10) / 26 = 0.9615.
Kemudian untuk menghitung P(E) dilakukan dengan cara sebagai berikut:
1. Ahli menjawab ambigu sebanyak 15 kali dan tidak ambigu sebanyak 11 kali, maka prosentase ahli menjawab ambigu = 57.69 %
2. Kakas bantu menjawab ambigu sebanyak 16 kali dan tidak ambigu sebanyak 10 kali, maka prosentase kakas bantu menjawab ambigu = 61.53
%
3. Probabilitas para penguji menjawab ambigu adalah 0.5769 * 0.6153 = 0.3549
4. Probabilitas para penguji menjawab tidak ambigu adalah 0.4231 * 0.3847
= 0.1627
5. P(E) = 0.3549 + 0.1627 = 0.5176
Setelah itu nilai κ (indeks Kappa) dapat ditentukan dengan mudah:
κ = ( 0.9615 – 0.5176) / (1-0.5176) = 0.4439 / 0.4824 = 0.9202. Hal ini menandakan bahwa diluar ruang lingkup 25 domain permasalahan yang digunakan pada penelitian sebelumnya, metode yang diajukan didalam penelitian ini memiliki performa yang lebih baik. Disamping itu, fakta tersebut juga membuktikan bahwa daftar kata-kata yang tidak diinginkan memiliki ruang lingkup yang lebih luas daripada penelitian sebelumnya.
BAB V KESIMPULAN
Adapun kesimpulan dari penelitian ini yaitu:
1. Pengujian yang dilakukan pada ruang lingkup 25 domain permasalahan menghasilkan indeks Kappa sebesar 0.9660. Hal ini menandakan bahwa pada ruang lingkup 25 domain permasalahan tersebut, metode yang diajukan didalam penelitian ini memiliki performa yang lebih baik.
2. Pengujian yang dilakukan diluar ruang lingkup 25 domain permasalahan menghasilkan indeks Kappa sebesar 0.9202. Hal ini menandakan bahwa diluar ruang lingkup 25 domain permasalahan tersebut, metode yang diajukan didalam penelitian ini memiliki performa yang lebih baik.
Disamping itu, fakta tersebut juga membuktikan bahwa daftar kata-kata yang tidak diinginkan memiliki ruang lingkup yang lebih luas daripada penelitian sebelumnya.
3. Telah dihasilkan sebuah kakas bantu untuk menganalisis ambiguitas kebutuhan perangkat lunak berdasarkan acuan SMART Requirements.
Daftar Pustaka
Cohen, J. (1960). “A coefficient of agreement for nominal scales”. Educational and Psychological Measurement.
Mannion, M., Keepence, B. (1995). “SMART Requirements”. ACM Sigsoft.
The Standish Group International, Inc. (1995). “The CHAOS Report”.
Wilson, W., Rosenberg, L., & Hyatt, L. (1996) “Automated Quality Analysis of Natural Language Requirement Specifications”. Proceedings 14th Annual Pacific Northwest Software Quality Conference, Portland.
Wilson, W. (1997). “Writing Effective Requirements Specifications”. USAF Software Technology Conference, Utah.
Fabbrini, F., Fusani, M., Gnesi, S., dan Lami, G. (2001). “An Automatic Quality Evaluation for Natural Language Requirements”. Seventh International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'01) Interlaken, Switzerland.
Lami, G. (2005). “QuARS: A Tool for Analyzing Requirements”. Technical Report CMU/SEI-2005-TR-014 ESC-TR-2005-014.
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.
Bucchiarone, A., Fantechi, A., Gnesi, S., Lami, G., dan Trentanni, G. (2008).
“QuARS Express - An Automatic Analyzer of Natural Language Requirements”. Proceeding ACM International Conference on Automated Software Engineering, 473-474, L'Aquila, Italy.
Lampiran A Data Pengujian
1. As the main incoming channel for cases is frequently the telephone, the system must have sub-second response times and be intuitive to use.
2. Prioritise the cases based on specific rules (including Artificial Intelligence engines that deal with complex rules).
3. The design problem for DesignFest® is to create an Object Oriented framework for use in developing Case Management applications quickly, and customisable to the particular work practices of the company purchasing the framework.
4. A case may involve a multiple requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.
5. The manager then determines the next appropriate step (close, assign to another case worker for the next processing step, put aside until a bring-forward is
activated, etc.).
6. A case worker selects cases from a pool to perform a specific function, and then moves that case to the next appropriate step (close, put in another pool, put aside until a bring-forward is activated, etc.).
7. Finally, workflow support also means providing the ability to Approve or Reject a particular request regarding a case.
8. A case may involve a single requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.
9. Changing to a particular status may cause an event to be created automatically, such as creating a bring-forward entry due at some future date.
10. Changing to a particular status may also automatically close a bring-forward (whether it is due or not).
11. Bring-Forward entries are reminders to a case worker that it is time to perform a certain
12. If case worker are geographically dispersed, then you may assume that the cases are managed by geographic regions.
13. A Flexible Manufacturing System (FMS) is a computerized factory production entity, composed of numerically controlled machines, an automatic inventory system for storing raw, temporary in-process, and finished pieces, and an
automatic guided vehicle system (AGV) for moving pieces, which can operate on different types of pieces.
14. The production is planned at factory level and is represented by lots assigned to the FMS (a lot is an administrative entity indicating a group of identical pieces to be manufactured together.) Several lots of different types of pieces can be in production at the same time in a given FMS.
15. Machines are assigned to a waiting piece (if any) as soon as they become idle.
16. For our purposes (as is the case in a small FMS), the time needed to serve a transport request is small relative to the time needed for a machine operation.
17. Two turning machines, M1 and M2, and a drilling machine, M3, each of which can work on a single piece at a time.
18. When the Drilling Machine M3 has finished the operation DO1 on a piece, it notifies the Dispatcher. The Dispatcher makes a request for a cart from the Transportation System for evacuating the piece from the Drilling Machine.
19. When the cart has evacuated the piece, the machine enters the IDLE state. The Dispatcher then checks if the piece is finished.
20. If the piece is finished, it is transported to Store_out; otherwise, the Dispatcher checks if there is an idle machine performing the next operation on the piece.
21. If an idle machine is found, the piece is transported there; otherwise, the piece is moved to the temporary store Store_tmp.
22. When a piece is evacuated from the drilling machine M3, the machine becomes idle and it is ready to perform an operation on another piece.
23. When the machine enters the IDLE state, the dispatcher is informed and checks whether a piece (in the store for raw pieces Store_in or in the temporary in-process pieces Store_tmp) is waiting for the next operation on the drilling machine M3.
24. The specification can be adjusted for different levels of complexity applying one or more of the following constraints:
25. It used to be possible to configure these networks by hand, but the tremendous growth has made this infeasible.
26. There are just too many cells to be handled by man.
27. When a network is initially built, the area that is covered by each cell is very large.
28. This is almost a black art and is usually handled by special planning programs.
29. The mobile phone must be slaved to a cell when it is first turned on.
30. It will select the most suitable cell by scanning all beacon frequencies.
31. It will then send an identifying signal to the cell to make contact.
32. When the mobile is moving, the cell will detect that the signal quality will become worse, and will hand over the mobile to a more suitable neighboring cell.
33. The sites are the most visible part of a cellular network because of the very obvious antenna masts that are visible all over the country.
34. Planning, subscriptions, procurement, installation, handling of alarms, measurements, configuration changes and many more.
35. The networks have become so large that they are normally split sections.
36. This is complicated because each cell has literally hundreds of parameters. A short summary:
37. Several of these parameters are dependent on, and constrained by, the settings of other parameters in other cells.
38. For example, neighboring cells should always use different frequencies.
39. Changing parameters in the network must be done in a short time on all related cells to keep the disturbance to the network as low as possible.
40. Therefore, the changes must be planned and executed in a short time, usually during the middle of the night.
41. A very complicating factor in the management of the cells is that in one network, one can find cells from different manufacturers and different versions and variants from the same manufacturer.
42. We would like you to pay most of your attention to the fact that there are so many different cells in the network that need to managed in a common way, but are still of very different types.
43. Adding new cells and new cell types should be relatively easy.
44. All parameters with the same name should be converted to the new type without loss of information.
45. It must be possible to develop "small" software modules that can work upon the information without getting intricately tied to all the possible cell types.
46. The reason is that certain cells have a very slow connection (seconds per command).
47. Each cell is on a site (and a site can have many cells on it).
48. Some cells are managed by the same OMC, others are managed by other OMCs or other network operators.
49. A cell in sector 301.402 is split in three.
50. The original cell was a Sienokola and used an antenna that created a cell where the site was in the middle.
51. Three directional antennas have been added plus the necessary base stations.
52. The operator starts the application and first selects the cell that must be removed.
53. She indicates that the cell should be removed.
54. All the other parameters were left at default values.
55.The network operator decides to buy 10 base stations and installs them on the sites.
56. Reports have come in that the cell in sector 231.912 is not functioning well.
57. Commands look very similar to the AT command set for modems, for example:
58. In one version of a "fat client" 128-megabyte workstations cache nearly all business objects in local memory.
59. Modest client computers could "browse" these servers using software and protocol suggested by the world-wide web.
60.When filter = standard, neighbour relations algorithm can only be 0 or 2 61. Each neighbour mentioned in a neighbour relation "rels" should have its frequencies listed in the neigbour frequencies "nfreq"
62. Paging channels + broadcast channels <= 12 63. Paging channels + broadcast channels <= 8 64. When bspower > 32, hopping cannot be used
65. One possible interpretation of a "thin" alternative architecture would be to move these caches and coherency logic to a small number of large middle-level servers.
Lampiran B Snapshot Pengujian
Kalimat “As the main incoming channel for cases is frequently the telephone, the system must have sub-second response times and be intuitive to use.” dinyatakan ambigu karena memiliki pola frequently/RB.
Kalimat “Prioritise the cases based on specific rules (including Artificial Intelligence engines that deal with complex rules).” dinyatakan ambigu karena memiliki pola specific/JJ rules/NNS.
Kalimat “The design problem for DesignFest® is to create an Object Oriented framework for use in developing Case Management applications quickly, and customisable to the particular work practices of the company purchasing the framework.” dinyatakan ambigu karena memiliki pola quickly/RB.
Kalimat “A case may involve a multiple requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.” dinyatakan ambigu karena memiliki pola multiple/JJ requests/NNS.
Kalimat “The manager then determines the next appropriate step (close, assign to another case worker for the next processing step, put aside until a bring-forward is activated, etc.).” dinyatakan ambigu karena mengandung frase etc (et cetera).
Kalimat “A case worker selects cases from a pool to perform a specific function, and then moves that case to the next appropriate step (close, put in another pool, put aside until a bring-forward is activated, etc.).” dinyatakan ambigu karena mengandung frase etc (et cetera).
Kalimat “Finally, workflow support also means providing the ability to Approve or Reject a particular request regarding a case.” dinyatakan ambigu karena memiliki pola finally/RB.
Kalimat “A case may involve a single requests requiring approval, and security may be needed to restrict who can make these decisions, depending on the organisation building the application using this framework.” dinyatakan ambigu karena memiliki pola single/JJ requests/NNS.
Kalimat “Changing to a particular status may cause an event to be created automatically, such as creating a bring-forward entry due at some future date.”
dinyatakan ambigu karena memiliki pola particular/JJ status/NN.
Kalimat “Changing to a particular status may also automatically close a bring- forward (whether it is due or not).” dinyatakan ambigu karena memiliki pola particular/JJ status/NN.
Kalimat “Bring-Forward entries are reminders to a case worker that it is time to perform a certain” dinyatakan tidak ambigu karena tidak ditemukan pola yang sama dengan salah satu pola yang ada di dalam repositori aturan SMART.
Kalimat “If case worker are geographically dispersed, then you may assume that the cases are managed by geographic regions.” dinyatakan ambigu karena memiliki pola geographic/JJ regions/NNS.
Kalimat “A Flexible Manufacturing System (FMS) is a computerized factory production entity, composed of numerically controlled machines, an automatic inventory system for storing raw, temporary in-process, and finished pieces, and an automatic guided vehicle system (AGV) for moving pieces, which can operate on different types of pieces.” dinyatakan ambigu karena memiliki pola different/JJ types/NNS. Pengujian ini bersifat misclassification, dimana ahli mengatakan bahwa kalimat tersebut bersifat tidak ambigu, sedangkan kakas bantu menilai bahwa kalimat tersebut bersifat ambigu.
Kalimat “The production is planned at factory level and is represented by lots assigned to the FMS (a lot is an administrative entity indicating a group of identical pieces to be manufactured together.) Several lots of different types of pieces can be in production at the same time in a given FMS.” dinyatakan ambigu karena memiliki pola several/JJ lots/NNS.
Kalimat “Machines are assigned to a waiting piece (if any) as soon as they become idle.” dinyatakan ambigu karena memiliki pola any/DT.
Kalimat “For our purposes (as is the case in a small FMS), the time needed to serve a transport request is small relative to the time needed for a machine operation.” dinyatakan ambigu karena memiliki pola small/JJ.
Kalimat “Two turning machines, M1 and M2, and a drilling machine, M3, each of which can work on a single piece at a time.” dinyatakan ambigu karena memiliki pola single/JJ.
Kalimat “When the Drilling Machine M3 has finished the operation DO1 on a piece, it notifies the Dispatcher. The Dispatcher makes a request for a cart from the Transportation System for evacuating the piece from the Drilling Machine.”
dinyatakan tidak ambigu.
Kalimat “When the cart has evacuated the piece, the machine enters the IDLE state. The Dispatcher then checks if the piece is finished.” dinyatakan tidak ambigu.
Kalimat “If the piece is finished, it is transported to Store_out; otherwise, the Dispatcher checks if there is an idle machine performing the next operation on the piece.” dinyatakan tidak ambigu.
Kalimat “If an idle machine is found, the piece is transported there; otherwise, the piece is moved to the temporary store Store_tmp.” dinyatakan tidak ambigu.
Kalimat “When a piece is evacuated from the drilling machine M3, the machine becomes idle and it is ready to perform an operation on another piece.” dinyatakan ambigu karena terdapat pola ready/JJ.
Kalimat “When the machine enters the IDLE state, the dispatcher is informed and checks whether a piece (in the store for raw pieces Store_in or in the temporary in-process pieces Store_tmp) is waiting for the next operation on the drilling machine M3.” dinyatakan ambigu karena ditemukan pola next/JJ operation/NN.
Kalimat “The specification can be adjusted for different levels of complexity applying one or more of the following constraints:” dinyatakan ambigu karena terdapat pola different/JJ levels/NNS.
Kalimat “It used to be possible to configure these networks by hand, but the tremendous growth has made this infeasible.” dinyatakan ambigu karena ditemukan pola tremendous/JJ.
Kalimat “There are just too many cells to be handled by man.” dinyatakan ambigu karena ditemukan pola many/JJ cells/NNS.
Kalimat “When a network is initially built, the area that is covered by each cell is very large.” dinyatakan ambigu karena ditemukan pola large/JJ.
