A Quality-Based Requirement Prioritization Framework Using Binary Inputs

1. A Quality-Based Requirement Prioritization Framework Using Binary Inputs Carlos E. Otero, Erica Dell, AbrarQureshi Department of Mathematics and Computer Science University of Virginia - College at Wise Wise, VA USA cotero@virginia.edu Disampaikankembalioleh: Eko Prasetyo TeknikInformatika Univ. Pembangunan Nasional Veteran JawaTimur 2011

2. Abstrak • Disampingkebutuhanuntukperangkingan requirement, pencarianmetodepraktekuntukperangkingan requirement jugasesuatu yang sulit. • Metode yang adamemberikanhasil yang konsisten, tapijugasangatkompleks Sulitdiimplementasikan • Metode yang informal hematwaktudanlebihmudahditerapkan, tapitidakcocokuntukskenariopraktekkarenastrukturdankonsistensi yang kurang, yang dibutuhkandalamanalisis requirement. • Paper inimengusulkanpendekatan yang mencobauntukmengkuantisasikualitas requirement untukmemberikanpengukuran yang mewakilisemuakriteriakualitas yang mengidentifikasispesifikasiproyek software. • Pengukurankualitas yang diturunkandapatdenganmudahdihitunguntukmenyediakanmetrikutamabagiperangkingan requirement. • KataKunci: Requirements Engineering, Requirements Prioritization, Desirability Functions, Software Engineering, Software Quality,Software Process

3. Pendahuluan • Kebutuhanperangkatlunakdalamkehidupanmeningkat. • Dilemamanajerproyekuntukmenyelesaikan software denganbekalsumberdayadanwaktu yang terbatas. • Beberapa requirement tidakdapatsecarapenuhselesaijikaproyekharusselesaitepatwaktu. • Untukmeyakinkanbahwa requirement yang diimplementasikanadalah yang paling penting, makapentinguntukmerangking requirement secarabenar. • Duafaktorpenting yang dikaitkandalamperangkingan requirement: benefitdancost. • RisetolehHerrman (2008) menyimpulkan “We found no methods which estimate benefit for individual requirements” • Metodeperangkingan yang adaterlalukompleksuntukdiimplementasikan. • Trade-off antarakonsistensidankemudahan, seperti: AHP, Cumulative Voting, dsb.

4. Pendahuluan • Metode yang memberikanhasil paling konsistenmenjadi paling sulitdiimplementasikan. • Metode yang lebih informal lebihhematwaktudanmudah, tapitidakcocokuntukproyek yang komplekskarenakekuranganstrukturdankonsistensi yang dibutuhkandalammenganalisissejumlah requirement secarabenar. • Mengusulkan “novel approach” untukperangkingan requirement software. • Berusahamengkuantisasikualitas requirement untukmemberikanpengukuran yang mewakilisemuakriteriakualitas yang diidentifikasibagisuatuproyek software. • Ukurankualitas yang diturunkandapatdigunakansebagaimetrikutamauntukperangkingan requirement.

5. LatarBelakang • Wieger (1999), sumberdaya yang terbatasberartiadabeberapa requirement yang tidakdiimplementasikan. • Keputusan yang manakah requirement yang paling pentinglebihbaikditentukandiawalfasepengembangan. • Metodeperangkingan yang disampaikan Herrmann (2008) meliputipengujian requirement melalui framework benefit dan cost. • Requirement dianalisispada basis benefit (keuntungan) yang didapatdari requirement, dan cost (biaya) pengimplementasian. • Umumnyametodeperangkingandilakukansecarakuantitatifdansistematik. • Metode yang lain, pembuatangeneralisasidanpengelompokansebelumdirangking. • Pengelompokandapatmengurangiwaktu yang dibutuhkanuntukperangkingan. • Metode yang konsisten: Analytic Hierarchy Process (AHP). • Metodeperbandingandengankumulatifpoin: Cumulative Voting (100 point) • Metodeberbasis machine learning: Case-based Rangking (CBR)

6. Solusi: Novel Approach • Metodeharusbisamemberikanpenentuankepentinganrelatifdarisetiapatributkualitas yang diidentifikasi. • Memberikanrepresentasiseberapabaik requirement mencapaikualitasatributdanbagaimanakepentingankualitasatributpadaproyek software. • Usulanmetode: • Satu kali requirement sudahdiidentifikasi, sejumlahkualitasatributdiidentifikasisebagaikriteriaevaluasi. • Requirement yang mendapatnilaitertinggiakanmendapat level kualitas yang lebihtinggiuntukatributkualitastertentu. • Menggunakandesirability functionuntukmenggabungkansemuaukurankedalamsatunilaitunggal yang mewakilisemuakualitas requirement. • Fungsitersebutmenggunakanpandanganprioritassetiapatributkualitas. • Hasilnya: seberapabaik requirement mencapaiatributkualitasdanseberapapentingatributkualitasuntukproyek software yang diidentifikasi.

7. Desirability Function • Desirability Function  Pendekatan yang populeruntukoptimasisimultasdaribeberapajawaban. • Setiapjawabansistemdikonversikedalamfungsiindividudidalam range 0  di  1, di = 1 ketikatujuantercapai, dandi=0 untuksebaliknya. • Setiapjawaban yang yangditransformasikan, level darisetiapfaktordipilihuntukmemaksimalkan desirability, dengan geometric mean dari m jawaban yang ditransformasi. • Vektor requirement:

8. Desirability Function • Setiap requirement dievaluasidengansejumlahatribut/faktorkualitas: QA1, QA2,.., QAn. Setiapatributkualitasdidefinisikandengan m fitur, m>1. • Skalaevaluasibiner: 0 dan 1. 1 jikaada/benar, dan 0 jikatidakada/salah. • Misal, faktor type, bisadidefinisikandenganfitur/kriteria: Functional, Imposed, dan Product. • Jika requirement mempunyaiprioritaspaling tinggi (bedasaratributkualitas type) maka Functional=1, Imposed=1, dan Product=1. • Jikaprioritaspaling rendahmaka Functional=0, Imposed=0, dan Product=0. • Pengukurankepentingan requirement ke-j berdasaratributkualitaske-i (misal, type), dihitung: • Dimana m adalahjumlahfitur/kriteria yang diidentifikasiuntukatribut/faktorkualitaske-I • Komputasidinormalisasikanpada range 0 – 100, • 0 merepresentasikan score terendah • 100 merepresentasikan score tertinggi

9. Desirability Function • Semuapenilaian requirement didasarkanpadaatribut/faktorkualitas yang di-capture menggunakanpenilaianmatrik Q • Setiapnilaiyijmerepresentasikanskor requirement ke-j didasarkansetiapatributkualitasi. • Untukmenilaikepentingansetiapatribut/faktorkualitas, vektorbobot W dibuat, dimanarimenyatakankepentinganatributkualitas QA, skala 0 – 10, • 0 menyatakanpaling tidakpenting • 100 menyatakanpaling penting.

10. Desirability Function • Informasidari X, Q, dan W digunakanuntukmenghitungnilai desirability bagisetiap requirement denganmatrik d. • Setiapnilaidijdarimatrikmerepresentasikan desirability requirement ke-j berdasarkansetiapindividuatributkualitaske-I • Nilaidijdihitungmenuruttujuananalisis requirement. • Atributkualitas yang direpresentasikansecarapositifdengannilaiyij yang lebihtinggiditransformasimenggunakanfungsimaksimasi. • Atributkualitas yang direpresentasikansecaranegatifdengannilaiyij yang lebihtinggi (misal, penaltisepertibiayadanresiko) ditransformasimenggunakanfungsiminimasi. L dan U adalahbatasnilaiterendahdantertinggi, T adalah target objective (mis, 100 untukmeksimisasi, 0 untukminimisasi), riadalahbobot desirability padaatributkualitas. Ketikadijkurangdari 0.0001, makanilaidijdiset 0.0001

11. Desirability Function • Setiapnilai desirability requirement dihitungsebagai geometric mean dari m nilai desirability individuuntuk requirement 1, 2, …, n. • Nilaiiniadalahukuranprioritas yang diturunkandariatributkualitas yang sudahdidefinisikandankepentinganrelatifterhadapproyek.

12. StudiKasus • Evaluates 10 requirements based on the following identified quality attributes: Type, Scope, Customers Satisfaction, Perceived Impact (PMF), Application-Specific Attributes, and Penalties. • 1) Type: The type of the requirement. Requirement type is defined with the following features: Functional, Imposed, and Product. • 2) Scope: The scope of the requirement. This quality attribute asseses the impact of this requirmenent on the overall system. Requirements that affect many (or all) subsystems are determined to have higher priority than requirements that affect minimal number subsystems. Scope is defined with the following features: Subsystem 1 (S1), Subsystem 2 (S2), …, Subsystem n (Sn) • 3) Customer Satisfaction:The number of customers the requirement satisfies. The higher the number of customer the requirement satisfies, the higher the desirabilty of the requirement. Customer Satisfaction is defined with the following features: Customer 1 (C1), Customer 2 (C2), …, Customer n (Cn)

13. StudiKasus (2) • 4) Perceived Impact (PMF): The perceived impact the requirement has on the project based on expert opinion. This quality attribute asks each software lead the question “Is this requirement Perceived as a Major Functionality (PMF)?”. Perceived Impact is defined in terms of all leads (software, hardware, systems). Therefore the features are: Lead 1 (L1), Lead 2 (L2), …, Lead n (Ln) • 5) Application-Specific: The attributes that are important to the specific software application. Depending on the application domain (e.g., safety critical systems), requirements dictating a specific functionality will have higher importance. In this case study, application-specific is defined with the following features: Usability (U), Performance (P), Safety (S), Security (S), Reliability, and Interoperability (I). • 6) Penalties: The penalties associated with the requirement. Requriements are associated with varied types of penalties, for example cost, risk, complexities, etc. This quality attribute is designed to ask the question “Is the requirement perceived as costly/risky/complex?”. Penalties is defined with the following features: Costly (C), Risky (R), and Complex (Cx).

15. Kesimpulan • Pendekatan yang sederhanadanterbaca, bisadiimplementasikandengan spreadsheet sederhana. • Pendekatan yang menggabungkanevaluasikriteriadanfituruntukmemberikanpandanganholistiksemuakualitas requirement. • Mudahdikembangkanuntukmemasukkantambahanatributkualitas yang belumdipandangdalampenelitianini. • Memberikanmekanismeuntukmengevaluasikualitas requirement dalam domain yang berbeda.