1

A Quality-Based Requirement Prioritization Framework Using Binary InputsCarlos E. Otero, Erica Dell, Abrar QureshiDepartment of Mathematics and Computer ScienceUniversity of Virginia - College at WiseWise, VA USAcotero@virginia.edu

Disampaikan kembali oleh:Eko Prasetyo

Teknik InformatikaUniv. Pembangunan Nasional Veteran Jawa Timur

2011

2

Abstrak Disamping kebutuhan untuk perangkingan requirement, pencarian

metode praktek untuk perangkingan requirement juga sesuatu yang sulit.

Metode yang ada memberikan hasil yang konsisten, tapi juga sangat kompleks Sulit diimplementasikan

Metode yang informal hemat waktu dan lebih mudah diterapkan, tapi tidak cocok untuk skenario praktek karena struktur dan konsistensi yang kurang, yang dibutuhkan dalam analisis requirement.

Paper ini mengusulkan pendekatan yang mencoba untuk mengkuantisasi kualitas requirement untuk memberikan pengukuran yang mewakili semua kriteria kualitas yang mengidentifikasi spesifikasi proyek software.

Pengukuran kualitas yang diturunkan dapat dengan mudah dihitung untuk menyediakan metrik utama bagi perangkingan requirement.

Kata Kunci: Requirements Engineering, Requirements Prioritization, Desirability Functions, Software Engineering, Software Quality,Software Process

3

Pendahuluan Kebutuhan perangkat lunak dalam kehidupan meningkat. Dilema manajer proyek untuk menyelesaikan software

dengan bekal sumber daya dan waktu yang terbatas. Beberapa requirement tidak dapat secara penuh selesai jika

proyek harus selesai tepat waktu. Untuk meyakinkan bahwa requirement yang

diimplementasikan adalah yang paling penting, maka penting untuk merangking requirement secara benar.

Dua faktor penting yang dikaitkan dalam perangkingan requirement: benefit dan cost.

Riset oleh Herrman (2008) menyimpulkan “We found no methods which estimate benefit for individual requirements”

Metode perangkingan yang ada terlalu kompleks untuk diimplementasikan.◦ Trade-off antara konsistensi dan kemudahan, seperti: AHP,

Cumulative Voting, dsb.

4

Pendahuluan Metode yang memberikan hasil paling konsisten

menjadi paling sulit diimplementasikan. Metode yang lebih informal lebih hemat waktu

dan mudah, tapi tidak cocok untuk proyek yang kompleks karena kekurangan struktur dan konsistensi yang dibutuhkan dalam menganalisis sejumlah requirement secara benar.

Mengusulkan “novel approach” untuk perangkingan requirement software.◦ Berusaha mengkuantisasi kualitas requirement untuk

memberikan pengukuran yang mewakili semua kriteria kualitas yang diidentifikasi bagi suatu proyek software.

◦ Ukuran kualitas yang diturunkan dapat digunakan sebagai metrik utama untuk perangkingan requirement.

5

Latar Belakang Wieger (1999), sumber daya yang terbatas berarti ada beberapa

requirement yang tidak diimplementasikan.◦ Keputusan yang manakah requirement yang paling penting lebih baik

ditentukan diawal fase pengembangan. Metode perangkingan yang disampaikan Herrmann (2008)

meliputi pengujian requirement melalui framework benefit dan cost.◦ Requirement dianalisis pada basis benefit (keuntungan) yang didapat

dari requirement, dan cost (biaya) pengimplementasian. Umumnya metode perangkingan dilakukan secara kuantitatif dan

sistematik. Metode yang lain, pembuatan generalisasi dan pengelompokan

sebelum dirangking.◦ Pengelompokan dapat mengurangi waktu yang dibutuhkan untuk

perangkingan. Metode yang konsisten: Analytic Hierarchy Process (AHP). Metode perbandingan dengan kumulatif poin: Cumulative Voting

(100 point) Metode berbasis machine learning: Case-based Rangking (CBR)

6

Solusi: Novel Approach Metode harus bisa memberikan penentuan kepentingan

relatif dari setiap atribut kualitas yang diidentifikasi.◦ Memberikan representasi seberapa baik requirement mencapai

kualitas atribut dan bagaimana kepentingan kualitas atribut pada proyek software.

Usulan metode:◦ Satu kali requirement sudah diidentifikasi, sejumlah kualitas

atribut diidentifikasi sebagai kriteria evaluasi.◦ Requirement yang mendapat nilai tertinggi akan mendapat level

kualitas yang lebih tinggi untuk atribut kualitas tertentu.◦ Menggunakan desirability function untuk menggabungkan

semua ukuran kedalam satu nilai tunggal yang mewakili semua kualitas requirement.

◦ Fungsi tersebut menggunakan pandangan prioritas setiap atribut kualitas.

◦ Hasilnya: seberapa baik requirement mencapai atribut kualitas dan seberapa penting atribut kualitas untuk proyek software yang diidentifikasi.

7

Desirability FunctionDesirability Function Pendekatan yang populer

untuk optimasi simultas dari beberapa jawaban.Setiap jawaban sistem dikonversi kedalam

fungsi individu di dalam range 0 di 1, di = 1 ketika tujuan tercapai, dan di=0 untuk sebaliknya.

Setiap jawaban yang yang ditransformasikan, level dari setiap faktor dipilih untuk memaksimalkan desirability, dengan geometric mean dari m jawaban yang ditransformasi.

Vektor requirement:

8

Desirability Function Setiap requirement dievaluasi dengan sejumlah atribut/faktor kualitas:

QA1, QA2,.., QAn. Setiap atribut kualitas didefinisikan dengan m fitur, m>1. Skala evaluasi biner: 0 dan 1. 1 jika ada/benar, dan 0 jika tidak ada/salah. Misal, faktor type, bisa didefinisikan dengan fitur/kriteria: Functional,

Imposed, dan Product.◦ Jika requirement mempunyai prioritas paling tinggi (bedasar atribut kualitas

type) maka Functional=1, Imposed=1, dan Product=1.◦ Jika prioritas paling rendah maka Functional=0, Imposed=0, dan Product=0.

Pengukuran kepentingan requirement ke-j berdasar atribut kualitas ke-i (misal, type), dihitung:

Dimana m adalah jumlah fitur/kriteria yang diidentifikasi untuk atribut/faktor kualitas ke-I

Komputasi dinormalisasikan pada range 0 – 100, ◦ 0 merepresentasikan score terendah◦ 100 merepresentasikan score tertinggi

9

Desirability Function Semua penilaian requirement didasarkan pada

atribut/faktor kualitas yang di-capture menggunakan penilaian matrik Q

Setiap nilai yij merepresentasikan skor requirement ke-j didasarkan setiap atribut kualitas i.

Untuk menilai kepentingan setiap atribut/faktor kualitas, vektor bobot W dibuat, dimana ri menyatakan kepentingan atribut kualitas QA, skala 0 – 10,◦ 0 menyatakan paling tidak penting◦ 100 menyatakan paling penting.

10

Desirability Function Informasi dari X, Q, dan W digunakan

untuk menghitung nilai desirability bagi setiap requirement dengan matrik d.

Setiap nilai dij dari matrik merepresentasikan desirability requirement ke-j berdasarkan setiap individu atribut kualitas ke-I

Nilai dij dihitung menurut tujuan analisis requirement.◦ Atribut kualitas yang direpresentasikan

secara positif dengan nilai yij yang lebih tinggi ditransformasi menggunakan fungsi maksimasi.

◦ Atribut kualitas yang direpresentasikan secara negatif dengan nilai yij yang lebih tinggi (misal, penalti seperti biaya dan resiko) ditransformasi menggunakan fungsi minimasi.

L dan U adalah batas nilai terendah dan tertinggi, T adalah target objective (mis, 100 untuk meksimisasi, 0 untuk minimisasi), ri adalah bobot desirability pada atribut kualitas.

Ketika dij kurang dari 0.0001, maka nilai dij diset 0.0001

11

Desirability FunctionSetiap nilai desirability

requirement dihitung sebagai geometric mean dari m nilai desirability individu untuk requirement 1, 2, …, n.

Nilai ini adalah ukuran prioritas yang diturunkan dari atribut kualitas yang sudah didefinisikan dan kepentingan relatif terhadap proyek.

12

Studi Kasus 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

Studi Kasus (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).

14

15

KesimpulanPendekatan yang sederhana dan terbaca,

bisa diimplementasikan dengan spreadsheet sederhana.

Pendekatan yang menggabungkan evaluasi kriteria dan fitur untuk memberikan pandangan holistik semua kualitas requirement.

Mudah dikembangkan untuk memasukkan tambahan atribut kualitas yang belum dipandang dalam penelitian ini.

Memberikan mekanisme untuk mengevaluasi kualitas requirement dalam domain yang berbeda.