============ 8 ===============
Definisi Requirements Interdependencies
Mengelola Requirements interdependencies adalah
mengidentifikasi, menyimpan, dan memelihara informasi
tentang bagaimana kebutuhan saling berhubungan dan
mempengaruhi satu sama lain.
Hal ini juga melibatkan bagaimana memutuskan keterkaitan
informasi yang dibutuhkan dalam berbagai situasi selama
pengembangan perangkat lunak dan bagaimana informasi
tersebut harus disajikan.
Requirements Traceability
A Basic for Understanding Requirements Interdependencies
Requirements tracebility atau rekam jejak kebutuhan harus
kita pahami terlebih dahulu untuk memahami lebih jauh
tentang requirements interdependencies.
Requirements Traceability
Secara umum requirements traceability dapat dicapai dengan
mengasosiasikan beberapa informasi yang terkait antara lain:
Kebutuhan dan komponen sistem yang terkait dapat berguna untuk
kebutuhan tersebut.
Tujuan sistem dan kebutuhan yang berasal dari kebutuhan tersebut.
Perubahan proposal dan kebutuhan yang dapat mengubah sistem.
Requirements Traceability
Sebuah keputusan dan dasar pemikiran serta asumsi yang mendasar.
Kasus uji dan kebutuhan yang pemenuhannya untuk memastikan.
Komponen sistem dan sumber daya yang dibutuhkan untuk menerapkan
kebutuhan.
Kenapa Requirements Tracebility?
Requirements traceability saat ini dianggap sebagai
dukungan yang penting untuk mengembangkan sebuah sistem
perangkat lunak berkualitas tinggi.
Untuk menghindari kesalahan, rekam jejak informasi
diperlukan sebagai dasar bagi keputusan dan tugas-tugas di
sebagian besar tahapan proses pengembangan perangkat
lunak.
Kenapa Requirements Tracebility?
Tracebility juga menyediakan kemungkinan untuk
memastikan semua kebutuhan yang dipenuhi oleh komponen
sistem dan tidak ada fitur yang ditambahkan karena semua
komponen atau fitur dalam sistem harus berhubungan
dengan satu atau beberapa kebutuhan.
Kenapa Requirements Tracebility?
Rekam jejak kebutuhan yang komprehensif mendukung
untuk dihasilkannya kualitas produk yang lebih baik,
meningkatkan baik pengembangan dan pemeliharaan
perangkat lunak, dan berpotensi menurunkan biaya siklus
hidup sistem.
Kenapa Requirements Tracebility?
Ditekankan bahwa dalam praktek traceability (rekam jejak)
bisa ditemukan kasus traceability yang diabaikan, tidak
cukup dan tidak terstruktur.
Hal ini menyebabkan penurunan kualitas sistem,
menyebabkan revisi, meningkatkan biaya proyek dan waktu.
Tipe-tipe Requirements Tracebility
Tipe-tipe Requirements Tracebility
Keterangan:
S = Stakeholder/ pemangku kepentingan
BR = Business Rule/ aturan bisnis
Doc = Previous Documentation/ dokumentasi sebelumnya
C = Component/ komponen
R = Requirement/ kebutuhan
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Pre-traceability mengacu pada aspek-aspek kehidupan
kebutuhan sebelum termasuk dalam spesifikasi kebutuhan
dan berfokus pada memungkinkan pemahaman yang lebih
baik dari kebutuhan.
Pre-traceability termasuk menelusuri elisitasi kebutuhan,
definisi kebutuhan serta evolusi mereka.
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Tipe traceability ini merupakan pondasi untuk mengelola
evolusi dari sistem, karena pre-tracebility memungkinkan
elisitasi bagian dari spesifikasi yang disebabkan perubahan
oleh permintaan khusus, misalnya oleh kebijakan organisasi,
proses bisnis, atau penggunaan sistem.
Tipe-tipe Requirements Tracebility
2. Post-traceability
Post-traceability berkaitan dengan memastikan bahwa
semua kebutuhan dipenuhi oleh sistem melalui
perancangan dan implementasi sistem, dengan
mengaitkan kebutuhan untuk komponen (C), yang
membantu memastikan kebutuhan tertentu.
Tipe-tipe Requirements Tracebility
2. Post-traceability
Post-traceability juga penting untuk integrasi
perubahan dengan memungkinkan identifikasi dampak
dari perubahan terhadap perancangan dan
implementasi.
Tipe-tipe Requirements Tracebility
1. Pre-traceability
Berkaitan dengan produksi kebutuhan dan berfokus
pada domain yang berinteraksi ketika kebutuhan
dikembangkan dan di mana sistem akan dipasang.
2. Post-traceability
Berkaitan dengan penyebaran kebutuhan dan
difokuskan pada perangkat lunak yang dikembangkan
berdasarkan kebutuhan.
Tipe-tipe Requirements Tracebility
Tracebility juga dapat dibedakan menjadi horizontal traceability dan
vertical traceability yang mengacu pada objek informasi terkait
termasuk jenis yang sama atau tidak.
Horizontal traceability berhubungan dengan versi atau varian dari
jenis informasi yang sama, misalnya antara kebutuhan atau antara
komponen sistem.
Vertical traceability berkaitan dengan melacak informasi antara
fase sebelumnya dan selanjutnya dalam proses pembangunan
antara objek informasi dari berbagai jenis.
Meta-model requirements traceability
Meta-model menunjukkan perspektif utama dari
requirements traceability dan juga menunjukkan bahwa ada
beberapa dimensi rekam jejak informasi.
Meta-model requirements traceability
• The source is the physical artifact where the information
is maintained, e.g. requirements specification document,
design document, memorandum, and telephone call.
• This perspective emphasizes the document management
part of traceability, which is important because trace
objects available in persistent sources constitute long-term traceability.
Meta-model requirements traceability
• Source (Sumber) adalah artefak fisik dimana informasi
diperbaiki, contoh: dokumen spesifikasi kebutuhan,
dokumen perancangan, memorandum, dan panggilan
telepon.
• Perspektif ini menekankan rekam jejak bagian mengelola
dokumen, ini penting karena jejak objek tersedia dalam
sumber yang persistent dalam waktu yang lama.
Meta-model requirements traceability
• The stakeholder is the agent involved in the management
of traceability, e.g. the customer, system analyst, and
project manager.
• This perspective emphasizes the importance of different
usage roles when designing and implementing a
traceability system. It also provides the ability to define
who is responsible for various products and decisions
during the development process.
Meta-model requirements traceability
• Stakeholder (Pemangku kepentingan) adalah aktor yang
terlibat dalam managemen rekam jejak, contoh: pelanggan,
system analist, dan manager proyek.
• Perspektif ini menekankan pentingnya penggunaan peran
yang berbeda ketika merancang dan menerapkan rekam
jejak sistem. Hal ini juga menyediakan kemampuan untuk
menentukan siapa yang bertanggungjawab untuk berbagai
produk dan keputusan selama proses pembangunan.
Meta-model requirements traceability
Object refers to the type of information objects that
should be related to each other, e.g. requirement, rationale,
decision, and system component.
Meta-model requirements traceability
Object (Objek) merujuk kepada tipe informasi yang terkait
satu sama lain, contoh: kebutuhan, dasar pemikiran,
keputusan, dan komponen sistem.
Meta-model requirements traceability
Meta-model ini dapat digunakan untuk mewakili beberapa dimensi
traceability, termasuk:
Informasi yang disampaikan,
Dimana disampaikan dan bagaimana,
Siapa stakeholders dan peran mereka dan informasi yang digunakan,
Mengapa objek tertentu dibuat atau diubah.
Tipe Interdependency
Types of interdependency:
1. Structural Interdependencies
2. Constrain Interdependencies
3. Cost/ Value Interdependencies
Tipe Interdependency
1. Structural Interdependencies
Structural interdependencies berkaitan dengan fakta
bahwa apabila diberikan satu set kebutuhan, maka
structural interdependencies dapat diatur dalam struktur
yang hirarkis dan juga bersifat lintas-struktur.
Kebutuhan bisnis tingkat tinggi secara bertahap
didekomposisi menjadi kebutuhan perangkat lunak yang
lebih rinci, membentuk sebuah hirarki.
Tipe Interdependency
1. Structural Interdependencies
Tipe structural interdependencies mempunyai beberapa
kategori yaitu Refined_to, Changes_to, dan Similar_to.
Tipe Interdependency
1. Structural Interdependencies
Refined_to
Kebutuhan tingkat yang lebih tinggi dapat disempurnakan dengan
sejumlah kebutuhan yang lebih spesifik.
Tipe dependensi Refined_to digunakan untuk menggambarkan
struktur yang hirarkis, di mana kebutuhan yang lebih rinci terkait
dengan sumber kebutuhan mereka.
Dalam hal ini, kebutuhan memberikan penjelasan lebih lanjut, lebih
detail atau terdapat klarifikasi tentang sumber kebutuhan. Sumber
kebutuhan dapat dilihat sebagai abstraksi kebutuhan rinci.
Tipe Interdependency
1. Structural Interdependencies
Refined_to
Contoh:
Terdapat sebuah kebutuhan yang menyatakan “Sistem harus mendukung
tindaklanjut pesanan pelanggan setelah pesanan dikirim”.
Dapat disempurnakan dengan “Membandingkan biaya produksi produk
yang berhubungan dengan pesanan pelanggan dengan anggaran
manufaktur untuk produk-produk tersebut, dan sistem harus
memfasilitasi perubahan anggaran manufaktur saat tindaklanjut produk
dalam pesanan pelanggan.
Tipe Interdependency
1. Structural Interdependencies
Changes_to
Kebutuhan yang lama akan digantikan dengan kebutuhan
yang baru apabila ada perubahan versi baru dari
kebutuhan.
Tipe dependensi ini digunakan untuk menggambarkan
sejarah dari kebutuhan, misalnya bagaimana hal tersebut
berkembang dari waktu ke waktu karena ini memungkinkan
untuk menghubungkan berbagai versi menjadi satu
kebutuhan.
Tipe Interdependency
1. Structural Interdependencies
Changes_to
Contoh:
Terdapat kebutuhan “Itu harus mengambil waktu tidak lebih
dari 10 detik untuk mencari informasi kontak” dapat diubah
menjadi versi baru sebagai berikut “Itu harus mengambil
tidak lebih dari 5 detik untuk mencari informasi kontak”.
Tipe Interdependency
1. Structural Interdependencies
Similar_to
Salah satu kebutuhan dinyatakan mirip atau tumpang tindih
dengan satu atau lebih kebutuhan lainnya.
Tipe interdependency ini menggambarkan situasi dimana satu
kebutuhan mirip atau tumpang tindih dengan kebutuhan lainnya
dalam hal bagaimana dinyatakan atau dalam hal ide dasar yang
sama tentang apa yang harus dilakukan oleh sistem.
Tipe Interdependency
1. Structural Interdependencies
Similar_to
Contoh:
Terdapat kebutuhan:
“Sistem harus mendukung pengelolaan barang perpustakaan”
dan “Sistem harus menyediakan sarana untuk menangani buku
dan jurnal dalam perpustakaan”.
Kedua kebutuhan tersebut mirip karena buku dan jurnal
dapat dianggap sebagai item perpustakaan.
Tipe Interdependency
2. Constraining Interdependencies
Saling ketergantungan yang lebih rinci dapat diidentifikasi
untuk menggambarkan bagaimana kebutuhan dapat
menghambat satu sama lain atau tergantung satu sama lain.
Terdapat 2 kategori untuk tipe constraining
interdependencies yaitu Requires dan Conflicts_with.
Tipe Interdependency
2. Constraining Interdependencies
Requires
Pemenuhan satu kebutuhan tergantung pada pemenuhan
kebutuhan lain. Jenis dependensi ini digunakan untuk
menggambarkan bahwa jika salah satu kebutuhan
dimasukkan ke dalam sistem, memerlukan kebutuhan lain
untuk dimasukkan juga.
Contoh: Jika sistem harus dapat memasukkan email dan
WebAccess, harus ada koneksi jaringan (yang diperlukan).
Tipe Interdependency
2. Constraining Interdependencies
Conflicts_with
Sebuah kebutuhan bertentangan dengan kebutuhan lain jika
tidak bisa melakukan fungsinya pada waktu yang sama atau jika
salah satu meningkatkan/ mengurangi fungsi dari kebutuhan
yang lain.
Jenis dependensi ini termasuk yang tidak mungkin apabila
menerapkan kedua kebutuhan secara bersamaan, dan situasi di
mana kebutuhan memiliki pengaruh negatif kepada kebutuhan
lain dan resolusi kebutuhan harus dilakukan.
Tipe Interdependency
2. Constraining Interdependencies
Conflicts_with
Contoh: Jika terdapat kebutuhan menyatakan bahwa
”Semua personel harus dapat mencari informasi tentang
produk dan pelanggan” dan state lain menyatakan
”Hanya personel dengan status keamanan yang diizinkan
mencari informasi tersebut”,
kedua hal ini bertentangan satu sama lain dan tidak dapat
digunakan secara bersamaan.
Tipe Interdependency
3. Cost/ Value Interdependencies
Cost/ Value Interdependencies berkaitan dengan biaya
yang terlibat dalam pelaksanaan kebutuhan dalam
kaitannya dengan nilai pemenuhan kebutuhan yang akan
dirasakan oleh pelanggan atau pengguna.
Terdapat 2 kategori dari jenis interdependency ini yaitu
Increases/ Decreases_cost_of dan Increases/
Decreases_value_of.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_cost_of
Jika salah satu kebutuhan dipilih untuk proses implementasi,
maka biaya implementasi kebutuhan yang lain bisa bertambah
atau berkurang. Hal ini digunakan untuk menghubungkan
kebutuhan yang mempengaruhi implementasi.
Contoh: Jika kebutuhan menyatakan bahwa tidak ada waktu
respon lebih dari 0.5 detik, kemungkinan besar akan
meningkatkan biaya.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_value_of
Jika salah satu kebutuhan yang dipilih untuk implementasi,
maka nilai kebutuhan untuk pelanggan bisa bertambah atau
berkurang.
Tipe ini berfokus pada hubungan pengaruh antara
kebutuhan dan nilai yang dirasakan pelanggan. Beberapa
kebutuhan mungkin memiliki pengaruh positif terhadap
satu pelanggan, sementara bisa memiliki pengaruh negatif
terhadap pelanggan lain.
Tipe Interdependency
3. Cost/ Value Interdependencies
Increases/ Decreases_value_of
Contoh: Kepuasan pelanggan mungkin akan meningkat ketika
kalender perencanaan di masukkan ke dalam ponsel, jika ada
kemungkinan untuk menyingkronkan dengan kalender
perencanaan yang ada di PC.
Mengenal Turnitin – SRE 4803
Turnitin adalah Software untuk mengecek Plagiarism
Di mulai hari ini untuk semua tugas SRE akan menggunakan
Turnitin (Belajar menulis kreatif dan mencegah plagiarism)
Silahkan buka : https://turnitin.com/newuser_type.asp?lang=en_us
Buatlah akun sebagai student
Login untuk kelas SRE 4803 dengan
Class ID: 9968842
Password: sre4803
Mengenal Turnitin – SRE 4806
Turnitin adalah Software untuk mengecek Plagiarism
Di mulai hari ini untuk semua tugas SRE akan menggunakan
Turnitin (Belajar menulis kreatif dan mencegah plagiarism)
Silahkan buka : https://turnitin.com/newuser_type.asp?lang=en_us
Buatlah akun sebagai student
Login untuk kelas SRE 4806 dengan
Class ID: 9968849
Password: sre4806
Create Akun Turnitin
Akun Turnitin
Klik Class SRE-4803, Lalu Submit tugas dan lihat hasil
pekerjaan Kelompok Anda, Toleransi Kemiripan Laporan 30%
Lampirkan Hasil Turnitin di Laporan Tugas Anda
============= 11 Impact Analysis ============
Pengertian Impact Analysis
Analisis dampak adalah alat untuk mengendalikan perubahan
dan untuk menghindari kerusakan.
Bohner dan Arnold mendefinisikan analisis dampak sebagai
“aktifitas mengidentifikasi konsekuensi potensial, termasuk
efek samping dan efek perubahan, atau memperkirakan apa
yang perlu diubah untuk mencapai perubahan sebelum
dibuat.”
Impact Analysis
Output dari analisis dampak dapat digunakan sebagai dasar
untuk memperkirakan biaya yang terkait dengan perubahan.
Biaya perubahan dapat digunakan untuk memutuskan apakah
akan diterapkan tergantung pada rasio biaya/ manfaatnya.
Impact Analysis
Analisis dampak merupakan bagian penting dari rekayasa
kebutuhan karena perubahan perangkat lunak sering
diprakarsai oleh perubahan kebutuhan.
Dalam buku rekayasa kebutuhan, analisis dampak diakui
sebagai suatu kegiatan penting dalam manajemen perubahan,
namun rincian tentang bagaimana melakukan hal tersebut
sering ditinggalkan, atau terbatas pada penalaran tentang
dampak perubahan pada spesifikasi kebutuhan.
Impact Analysis
Hal ini dijelaskan pada gambar di bawah ini. Perhatikan
bahwa proses pembangunan kurang idealis, situasi masih
memungkinkan; perubahan kebutuhan mempengaruhi semua
representasi sistem yang ada.
Software life-cycle objects (SLOs) yang terkena dampak (kanan) akibat
perubahan kebutuhan dalam fase yang berbeda (kiri)
Impact Analysis
Software life-cycle objects (SLOs) atau disebut juga
produk perangkat lunak, atau produk hasil kerja) adalah
pusat untuk analisis dampak.
Sebuah SLO adalah sebuah artefak yang dihasilkan selama
proyek, seperti kebutuhan, komponen arsitektur, kelas dan
sebagainya.
SLO saling terhubung satu sama lain melalui hubungan
jaringan. Hubungan dapat terjadi antara SLO dari jenis yang
sama, dan antara SLO dari berbagai jenis.
Impact Analysis
Sebagai contoh, dua kebutuhan dapat saling berhubungan
untuk menandakan bahwa mereka berhubungan satu sama
lain.
Sebuah kebutuhan juga dapat dihubungkan ke komponen
arsitektur, misalnya, untuk menandakan bahwa komponen
menerapkan kebutuhan.
Impact Analysis
Analisis dampak sering dilakukan dengan menganalisis
hubungan antara berbagai entitas dalam sistem. Dibedakan
menjadi dua jenis analisis:
1. Analisis ketergantungan
Hubungan rinci antara entitas program, misalnya variable atau fungsi yang
diambil dari source code
2. Analisis rekam jejak.
Analisis hubungan yang telah diidentifikasi selama pengembangan antara semua
jenis SLO. Dengan demikian analisis rekam jejak cocok untuk menganalisis hubungan
antara kebutuhan, komponen arsitektur, dokumentasi dan sebagainya.
Impact Analysis
Arnold dan Bohner mendefinisikan set dalam analisis dampak
menjadi 4 bagian yaitu:
1. System set
2. Starting Impact Set
3. Estimated Impact Set
4. Actual Impact Set
Impact Analysis
1. System set merupakan himpunan semua SLO dalam sistem
– semua set lain adalah himpunan bagian dari himpunan ini.
2. Starting Impact Set (SIS) merupakan sekumpulan objek
yang awalnya harus diubah. SIS biasanya berfungsi sebagai
masukkan untuk mempengaruhi pendekatan analisis yang
digunakan untuk menemukan Estimated Impact Set.
Impact Analysis
3. Estimated Impact Set selalu meliputi SIS dan oleh karena itu
dapat dipandang sebagai perluasan dari SIS.
Hasil pengembangan dari penerapan aturan propagasi perubahan
model objek internal yang berulang-ulang sampai semua benda yang
mungkin akan terpengaruh ditemukan.
Idealnya SIS dan EIS harus sama, yang berarti dampak terbatas
pada apa yang awalnya dianggap berubah.
Impact Analysis
4. Actual Impact Set, memiliki SLO yang telah terpengaruh
setelah perubahan telah dilaksanakan.
Dalam scenario kasus terbaik, AIS dan EIS adalah sama, yang
berarti bahwa estimasi dampak yang sempurna.
Impact Analysis
Hal ini umum untuk membedakan antara perubahan primer dan
sekunder.
Perubahan primer, juga disebut sebagai dampak langsung,
sesuai dengan SLO yang diidentifikasi dengan menganalisis
bagaimana efek dari perubahan yang diusulkan mempengaruhi
sistem.
Analisis ini biasanya sulit untuk mengotomatisasi karena
didasarkan pada keahlian manusia.
Impact Analysis
Dampak tidak langsung terdiri dari dua bentuk:
1. Side effects (efek samping) adalah perilaku yang tidak
diinginkan yang dihasilkan dari modifikasi yang diperlukan untuk
melaksanakan perubahan. Efek samping mempengaruhi stabilitas
dan fungsi dari sistem dan harus dihindari.
2. Ripple effects (efek riak) adalah efek pada beberapa bagian
dari sistem yang disebabkan oleh perubahan ke bagian lain. Efek
riak tidak dapat dihindari, karena mereka adalah konsekuensi
dari struktur dan implementasi sistem. Efek riak bagaimanapun
harus diidentifikasi dan dihitung ketika perubahan dilaksanakan.
Perubahan Kebutuhan
Perubahan perangkat lunak terjadi karena beberapa alasan,
misalnya:
dalam rangka untuk memperbaiki kesalahan,
untuk menambahkan fitur baru atau
merestrukturisasi perangkat lunak untuk mengakomodasi
perubahan di masa depan.
Perubahan kebutuhan adalah salah satu motivasi yang paling
signifikan untuk perubahan perangkat lunak.
Perubahan Kebutuhan
Faktor-faktor yang dapat menimbulkan perubahan kebutuhan
selama pengembangan serta evolusi perangkat lunak menurut
Leffingwell dan Widrig adalah:
1. Masalah bahwa sistem seharusnya untuk memecahkan
perubahan, misalnya karena alasan ekonomi, politik atau
teknologi.
2. Para pengguna mengubah pikiran mereka tentang apa yang
mereka inginkan dari sistem, karena mereka memahami
kebutuhan mereka dengan lebih baik. Hal ini dapat terjadi
karena pengguna awalnya tidak yakin tentang apa yang
mereka inginkan.
Perubahan Kebutuhan
3. Lingkungan di mana sistem dilakukan perubahan. Misalnya,
peningkatan kecepatan dan kapasitas komputer dapat
mempengaruhi harapan dari sistem.
4. Sistem baru dikembangkan dan dirilis menuntut pengguna
untuk menemukan kebutuhan baru.
Perubahan Kebutuhan
Maciaszek menunjukkan: “Change is not a kick in the teeth,
unmanaged change is”.
Dengan kata lain, sebuah organisasi yang mengembangkan
perangkat lunak membutuhkan proses manajemen perubahan
yang tepat untuk mengurangi resiko kebutuhan yang terus
berubah dan dampaknya pada sistem.
Perubahan Kebutuhan
Leffingwell dan Widrig membahas lima (5) bagian penting dari
proses untuk mengelola perubahan.
Dalam gambar di bawah ini dijelaskan, pembentukkan kerangka
kerja untuk manajemen proses perubahan yang memungkinkan tim
proyek untuk mengelola perubahan dengan cara yang terkontrol.
Kerangka kerja manajemen proses perubahan
Perubahan Kebutuhan
• Plan for change membahas fakta bahwa telah terjadi
perubahan yang merupakan bagian penting dari pembangunan
sistem. Persiapan ini penting untuk perubahan yang akan
diterima dan ditangani secara efektif.
• Baseline requirements berarti untuk merekam set
kebutuhan. Hal yang ditekankan dari langkah ini
memungkinkan perubahan berikutnya dalam kebutuhan yang
stabil, yang dikenal dengan set kebutuhan.
Perubahan Kebutuhan
• Single channel diperlukan untuk memastikan bahwa tidak ada
perubahan yang diimplementasikan dalam sistem sebelum diteliti
oleh seseorang, atau beberapa orang yang mengawasi sistem,
proyek dan anggaran.
• Dalam organisasi yang lebih besar, single channel sering disebut
Change Control Board (CCB) atau papan pengendalian perubahan.
Perubahan Kebutuhan
• Change control system memungkinkan CCB untuk mengumpulkan,
melacak dan menilai dampak perubahan.
• Menurut Leffingwell dan Widrig, perubahan harus dinilai dampak
biaya dan fungsinya.
• Perubahan mungkin berdampak pada stakeholder eksternal
(misalnya pelanggan) dan berpotensi mengacaukan sistem. Jika hal
ini diabaikan, sistem yang ditunjukkan sebelumnya cenderung
memburuk.
Perubahan Kebutuhan
Manage hierarchically untuk mengelola hirarki mungkin
diperlukan tindakan:
Perubahan yang diperkenalkan dalam kode oleh programmer yang
ambisius,
Efek potensial perubahan yang telah di uji,
Perancangan arsitektur kebutuhan dan sebagainya.
Perubahan harus diperkenalkan secara top-down, dimulai
dengan kebutuhan. Jika kebutuhan yang kadaluarsa dan terkait
dengan SLO lainnya mungkin diperlukan perubahan dengan cara
yang terkontrol.
Perubahan Kebutuhan
Kerangka di atas untuk proses perubahan dan menentukan suatu
proses perubahan yang sebenarnya. Proses yang diusulkan oleh
Kotoya dan Sommerville merupakan proses yang rinci dan terdiri
dari langkah-langkah berikut:
1. Analisis masalah dan spesifikasi perubahan
2. Mengubah analisis dan biaya, yang pada gilirannya terdiri dari:
Periksa validitas permintaan perubahan
Cari kebutuhan yang terkena dampak secara langsung
Cari kebutuhan yang terkait
Mengusulkan perubahan kebutuhan
Menilai biaya perubahan
Menilai biaya penerimaan
3. Perubahan implementasi
Analisis dampak dilakukan dalam langkah-langkah
2b, 2c dan 2e, dengan mengidentifikasi kebutuhan
dan komponen sistem yang terpengaruh oleh
perubahan yang diusulkan. Analisis harus
dinyatakan dalam usaha yang dibutuhkan, waktu,
uang dan sumber daya yang tersedia.
Strategi untuk analisis dampak
Ada berbagai strategi untuk melakukan analisis dampak,
beberapa diantaranya lebih erat dengan proses rekayasa
kebutuhan daripada yang lain. Strategi umum analisis dampak
adalah:
1. Menganalisis rekam jejak atau ketergantungan informasi
2. Memanfaatkan teknik slicing
3. Konsultasi spesifikasi perancangan dan dokumentasi lainnya
4. Wawancara dengan developers yang berpengetahuan
Strategi untuk analisis dampak
Strategi analisis dampak ke dalam dua kategori:
1. Automatable dan
2. Manual.
Strategi untuk analisis dampak
1. Automatable
Strategi analisis dampak automatable sering menggunakan
metode algoritma untuk mengidentifikasi perubahan dan
dampak tidak langsung.
Sebagai contoh, hubungan grafik untuk kebutuhan dan SLO
lainnya dapat digunakan dengan algoritma untuk
mengidentifikasi dampak perubahan yang diusulkan pada
sistem.
Strategi untuk analisis dampak
1. Automatable
Prasyarat untuk strategi automatable adalah spesifikasi
terstruktur dari sistem, berarti bahwa spesifikasi konsisten
dan lengkap termasuk beberapa informasi semantik
(misalnya, jenis hubungan).
Setelah itu, spesifikasi dapat digunakan oleh alat untuk
melakukan analisis dampak secara otomatis.
Ketergantungan kebutuhan dalam web dan model objek
adalah contoh spesifikasi terstruktur.
Strategi untuk analisis dampak
1. Automatable
Strategi secara otomatis membahas rekam jejak dan analisis
ketergantungan, biasanya digunakan untuk menilai perkiraan
dampak dengan mengidentifikasi perubahan sekunder yang
diperlukan karena perubahan utama sistem. Strategi otomatis
tidak cocok untuk mengidentifikasi dampak langsung.
a. Traceability/ Dependency Analysis
b. Slicing Techniques
Strategi untuk analisis dampak
1. Automatable
Strategi secara otomatis membahas rekam jejak dan analisis
ketergantungan, biasanya digunakan untuk menilai perkiraan
dampak dengan mengidentifikasi perubahan sekunder yang
diperlukan karena perubahan utama sistem. Strategi otomatis
tidak cocok untuk mengidentifikasi dampak langsung.
a. Traceability/ Dependency Analysis
b. Slicing Techniques
Strategi untuk analisis dampak
a. Traceability/ Dependency Analysis
Analisis rekam jejak dan analisis ketergantungan melibatkan
pemeriksaan hubungan antara entitas dalam perangkat lunak,
keduanya berbeda dalam lingkup dan tingkat detail.
Analisis rekam jejak adalah analisis hubungan diantara semua
jenis SLO, sedangkan analisis ketergantungan adalah analisis
ketergantungan tingkat rendah yang diambil dari source code.
Strategi untuk analisis dampak
b. Slicing Techniques
Slicing (mengiris) mencoba untuk memahami ketergantungan
menggunakan irisan independen dari program.
Program ini diiris menjadi irisan dekomposisi, yang berisi tempat
perubahan, dan sisa dari program.
Slicing didasarkan pada data dan keterkaitan dalam program ini.
Perubahan yang dilakukan pada potongan dekomposisi sekitar
variabel yang diiris didasarkan pada slice pelengkap yang tidak
terpengaruh.
Strategi untuk analisis dampak
2. Manual
Strategi analisis dampak manual tidak tergantung pada
spesifikasi terstruktur seperti yang terdapat pada strategi
automatable. Akibatnya, ada resiko yang kurang tepat dalam
prediksi dampak secara manual.
Di sisi lain, strategi manual lebih mudah untuk
memperkenalkan proses manajemen perubahan, dan biasanya
digunakan dalam industri tanpa memperhatikan ketepatan
strategi manual tersebut.
Strategi untuk analisis dampak
2. Manual
Strategi manual dalam hal ini menggunakan design
documentation dan interviews, digunakan untuk menilai
dampak awal dengan mengidentifikasi dampak langsung.
Identifikasi dampak sekunder mungkin dilakukan, tetapi
lebih baik ditangani oleh strategi automatable. Strategi
manual dapat digunakan untuk menangkap link traceability
antara SLO untuk digunakan dalam analisis rekam jejak.
Strategi untuk analisis dampak
2. Manual
Keberhasilan dan ketepatan kegiatan ini tergantung pada sejumlah faktor:
1. Pengetahuan dan keterampilan orang-orang yang melakukan analisis
Orang dengan sedikit wawasan tentang sistem kemungkinan besar akan memiliki
masalah dalam menentukan dampak perubahan kebutuhan dalam sistem.
2. Ketersediaan dokumentasi
Dokumentasi yang “tersembunyi” di komputer pribadi atau disimpan dalam binder
anonim dapat diabaikan dalam analisis.
3. Jumlah informasi yang disampaikan dalam dokumentasi
Sketsa sederhana perancangan yang umum gagal untuk mengekspresikan hubungan
semantik antara kelas atau komponen arsitektur. Skema penamaan yang dipilih atau
notasi yang tidak konsisten membuat tugas analisis sulit.
4. Dokumentasi yang jelas dan konsisten
Dokumentasi yang ambigu terbuka untuk interpretasi, misalnya dampak dari
perubahan yang diusulkan ditambah dengan ketidakpastian yang besar, hanya
karena penafsiran lain akan menghasilkan dampak yang berbeda.
Strategi untuk analisis dampak
Strategi automatable memiliki kemampuan untuk
memberikan estimasi dampak yang sangat halus dalam mode
otomatis, tetapi membutuhkan keberadaan infrastruktur
rinci dan mengakibatkan pada waktu yang terlalu banyak
salah.
Dengan strategi manual, dilakukan oleh orang-orang yang
terbaik atau manusia (sebagai lawan alat). Ini membutuhkan
infrastruktur yang kurang, tetapi mungkin memiliki estimasi
dampak yang kasar daripada yang automatable.
Impact Analysis Metrics
Metrik berguna dalam analisis dampak karena berbagai
alasan.
Metrik dapat digunakan untuk mengukur dan menghitung
perubahan yang disebabkan oleh kebutuhan baru atau
kebutuhan yang diubah pada analisis dampak.
Metrik juga dapat digunakan untuk mengevaluasi proses
analisis dampak itu sendiri setelah perubahan telah
dilaksanakan.
Impact Analysis Metrics
Menentukan seberapa parah atau mahalnya sebuah
perubahan merupakan hal yang berguna untuk menentukan
faktor-faktor dampak.
Lindvall mendefinisikan faktor dampak pada tabel di bawah
untuk mengukur dampak dari perubahan yang disarankan.
Faktor dampak didasarkan pada temuan empiris di mana
ditetapkan bahwa perubahan jenis SLOs dapat digunakan
sebagai indikator tingkat perubahan. Semakin tinggi faktor
dampak, semakin parah perubahan.
Metrik untuk mengukur Dampak Perubahan
Faktor dampak Dampak Deskripsi
M1 Perubahan model
obyek
perancangan
Perubahan ini menganggap deskripsi nyata atau fisik
sistem dan dapat menghasilkan perubahan dalam
arsitektur perangkat lunak tentang ukuran perubahan
dalam model.
M2 Perubahan model
obyek analisis
Perubahan ini menganggap deskripsi ideal atau logis dari
sistem. Perubahan kecil dapat menghasilkan perubahan
dalam arsitektur perangkat lunak yang lebih besar
daripada perubahan dalam model ini.
M3 Perubahan model
obyek domain
Perubahan ini menganggap kosakata yang dibutuhkan
dalam sistem. Perubahan kecil di sini dapat menghasilkan
perubahan besar dalam arsitektur perangkat lunak.
M4 Perubahan model
use case
Perubahan ini memerlukan penambahan dan penghapusan
dengan model use case. Perubahan kecil di sini mungkin
memerlukan perubahan besar dalam arsitektur
perangkat lunak.
Alat Pendukung
Kompleksitas dari proses manajemen perubahan membuat
perlu untuk menggunakan beberapa jenis alat pendukung.
Sebuah alat manajemen perubahan dapat digunakan untuk
mengelola kebutuhan dan SLO lainnya, mengelola permintaan
perubahan, permintaan perubahan link kebutuhan dan SLO
lainnya, dan memantau kemajuan analisis dampak.
Alat Pendukung
Sebuah database atau spreadsheet sederhana dapat
digunakan sebagai dukungan manajemen perubahan
mendasar, tetapi masih membutuhkan cukup banyak
pekerjaan manual, yang pada akhirnya dapat menyebabkan
inkonsistensi dalam manajemen perubahan data.
Alat Pendukung
Dalam sebuah survei fitur dari 29 alat manajemen kebutuhan
pendukung traceability, hanya bisa menemukan sembilan alat yang
secara eksplisit dinyatakan di situs web mereka bahwa mereka
mendukung traceability antara kebutuhan dan SLO lainnya,
seperti elemen desain, uji kasus dan kode.
Hal ini menunjukkan bahwa dalam banyak kasus itu perlu untuk
menggunakan beberapa alat yang berbeda untuk mengelola
traceability dan melakukan analisis dampak, yang dapat menjadi
masalah tergantung pada tingkat integrasi antara alat.
Alat Pendukung
Contoh alat pendukung untuk melakukan analisis dampak adalah:
Egyed
Dalam tool ini diusulkan sebuah pendekatan untuk mengekstraksi
dependensi terutama untuk source code.
Masukan untuk pendekatan adalah seperangkat skenario
pengujian dan beberapa jejak hipotesis yang menghubungkan
skenario SLO.
Pendekatan kemudian menghitung footprint dari skenario, yaitu
baris source code yang menutupi, dan berdasarkan footprint dan
hipotesis jejak menghasilkan jejak yang tersisa.
============ 13 Negotiation ===============
Tujuan Requirements Negotiation
Tujuan utama dari negosiasi kebutuhan adalah untuk
mengidentifikasi dan menyelesaikan konflik antar para
stakeholder (pemangku kepentingan).
Ini memberikan kontribusi untuk tujuan mendefinisikan
kebutuhan yang layak dan mengakomodasi semua tujuan
dan harapan stakeholder.
Tujuan Requirements Negotiation
Selain itu, terdapat beberapa tujuan dari negosiasi
kebutuhan yaitu:
1. Memahami kendala proyek
2. Beradaptasi dengan perubahan
3. Membina pembelajaran tim
4. Memunculkan pengetahuan yang dipahami
5. Mengelola kompleksitas
6. Berurusan dengan ketidakpastian
7. Menemukan solusi yang lebih baik
Definisi Negosiasi
Negosiasi diadopsi secara luas dan telah diteliti oleh
berbagai disiplin ilmu. Akibatnya, ada perspektif yang
berbeda pada negosiasi dan aspek berbeda yang
ditekankan.
Negosiasi secara tradisional dipandang sebagai "interaksi
aktual antara peserta yang mengarah pada komitmen
bersama dimulai saat peserta mulai berkomunikasi
mengenai tujuan mereka, dan berakhir atau berhasil ketika
semua setuju untuk kontrak tertentu.”
Definisi Negosiasi
Easterbrook mendefinisikan negosiasi sebagai
"pendekatan kolaboratif untuk menyelesaikan konflik
dengan eksplorasi berbagai kemungkinan.” Hal ini ditandai
oleh peserta yang mencoba untuk menemukan penyelesaian
yang memuaskan semua pihak sebanyak mungkin.
Definisi Negosiasi
Curtis B, Krasner H, Iscoe N mengambil perspektif
rekayasa kebutuhan ketika menyatakan bahwa “negosiasi
kebutuhan dapat dilihat sebagai proses berulang dimana
para pemangku kepentingan membuat timbal balik antara
fungsi sistem yang diminta, kemampuan teknologi yang ada,
jadwal pengiriman dan biaya.”
Definisi Negosiasi
Robinson dan Volkov berpendapat bahwa di luar negosiasi
yang sebenarnya kita juga harus mempertimbangkan tahap
pra dan pasca-negosiasi sebagai bagian dari proses
kegiatan negosiasi meliputi seperti pengakuan awal
masalah, ajakan peserta dan komunikasi, atau pemeliharaan
solusi.
Proses Negosiasi
Proses negosiasi meliputi 3 pendekatan yaitu:
1. Pre-Negotiation,
2. Negotiation, dan
3. Post-Negotiation.
Proses Negosiasi
1. Pre-Negotiation
Kegiatan penting dari tahap ini adalah:
Definisi masalah negosiasi,
Identifikasi pemangku kepentingan,
Elisitasi tujuan dari para pemangku kepentingan, dan
Analisis tujuan untuk menemukan konflik.
Hasil dari tahap ini adalah isu-isu dan konflik yang terlibat.
Proses Negosiasi
2. Negotiation
Kegiatan negosiasi adalah tentang penataan masalah dan
mengembangkan alternatif untuk pemecahan masalah,
misalnya dengan bertukar penawaran atau mengusulkan
alternatif yang saling menguntungkan.
Setelah mengembangkan solusi yang mungkin pemangku
kepentingan akhirnya setuju pada yang “terbaik”.
Proses Negosiasi
2. Negotiation
Penjelasan dari solusi yang mungkin merupakan prasyarat
sebelum para pemangku kepentingan dapat menyetujui
keputusan dan membutuhkan pembentukan kriteria penilaian,
seperangkat aturan yang disepakati oleh semua pemangku
kepentingan.
Diperlukan juga sesi negosiasi untuk menyetujui kriteria
penilaian.
Proses Negosiasi
3. Post-Negotiation
Dalam fase ini pemangku kepentingan (atau alat otomatis)
menganalisis dan mengevaluasi hasil negosiasi dan
menyarankan kembali negosiasi jika diperlukan.
Sebagai contoh, dapat ditentukan perjanjian sesuai
permintaan stakeholder dan jika solusi yang lebih baik
mungkin bagi satu pihak yang melakukan negosiasi, tanpa
menyebabkan kerugian ke pihak yang lain.
Hal ini juga dapat melibatkan evaluasi jaminan kualitas dari
hasil negosiasi.
Dimensi Requirements Negotiation
Dimensi ini terbagi ke dalam tiga kerangka yaitu
1. Strategi resolusi konflik,
2. Kolaborasi situasi para pemangku kepentingan, dan
3. Alat pendukung negosiasi.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Konflik merupakan bagian tak terelakkan dari desain
sistem dan alasan untuk negosiasi. Di dalam setiap proyek
rekayasa perangkat lunak, konflik adalah hal penting dan
membutuhkan solusi sebagai keputusan penting.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Sebuah studi yang dilakukan oleh Curtis membagi 3
sumber konflik dalam rekayasa perangkat lunak, yaitu:
1. Pengetahuan yang sedikit tentang domain aplikasi,
2. Kebutuhan yang fluktuatif dan saling bertentangan, dan
3. Kurangnya komunikasi dan koordinasi.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Berdasarkan Easterbrook sumber konflik diantaranya adalah
Konflik karena perbedaan solusi yang disarankan,
Konflik yang disebabkan karena kendala pernyataan,
Konflik karena kebutuhan,
Konflik dalam penggunaan sumber daya, dan
Konflik karena perbedaan evaluasi prioritas.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Terdapat sebuah model yang diusulkan oleh Thomas.
Menurut model ini stakeholder mempunyai dua dimensi
orientasi yakni:
1). Fokus pada memuaskan kepentingannya sendiri (tidak
tegas, asertif) dan
2). Fokus pada memuaskan kepentingan orang lain (tidak
kooperatif, kooperatif).
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Dengan menggunakan 2 dimensi tersebut dapat ditentukan 5 orientasi
dominan untuk menangani konflik, yaitu:
Bersaing (memaksa) melibatkan penekanan pada memenangkan
kepentingan sendiri dengan mengorbankan yang lain, yang sering
menimbulkan situasi "menang-kalah".
Menampung (lebih halus) mencoba untuk memuaskan kekhawatiran
lain tanpa memperhatikan kepentingan sendiri. Hal ini berarti bahwa
satu pemangku kepentingan rela berkorban dan mengorbankan yang
lain.
Dimensi Requirements Negotiation
1. Strategi resolusi konflik
Berkolaborasi (pemecahan masalah) berfokus pada memnuhi
kepentingan semua pihak untuk mencari alternatif sehinggan memnuhi
kepentingan semua. Menekankan pada situasi “win-win solution”.
Menghindari (menarik diri dari forum) Negosiasi bisa menghasilkan
ketidakpedulian, penolakan, atau apatis.
Berkompromi (berbagi) Melibatkan konsesi untuk menemukan jalan
tengah yang memuaskan.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Waktu negosiasi dan lokasi stakeholder memiliki dampak yang kuat pada
interaksi yang sebenarnya selama negosiasi dan menimbulkan tantangan
tambahan. Computer-Supported Cooperative Work telah mengembangkan
matriks CSCW, skema klasifikasi sederhana yang membedakan empat
skenario yang berbeda.
Co-located Dislocated
Synchronous
communication
Same time/ Same place Same time/ Different place
Asynchronous
communication
Different time/ Same place Different time/ Different place
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Same time/ Same place
• Pertemuan dengan tatap muka masih merupakan cara yang umum
untuk memperoleh dan bernegosiasi mengenai kebutuhan. Dalam
rekayasa kebutuhan, banyak pendekatan masih bekerja dengan
baik atau bahkan mengharuskan terus menerus dan
mengharuskan kerja tim yang sinkron.
• Pendekatan seperti metode Agile mendukung pertemuan dengan
tatap muka. Contoh yang popular adalah “on-site customer”,
dalam sebuah praktik di eXtreme Programming.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Different time/ Same place
• Menyelenggarakan seluruh negosiasi dengan pertemuan
tatap muka biasanya tidak mungkin, bahkan jika
stakeholder terletak di lokasi yang sama.
• Durasi negosiasi sering melebihi waktu workshop dan
umumnya sulit untuk diatur karena kendala waktu.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Same time/ Different place
• Apabila tidak mungkin untuk mempertemukan para
stakeholder dengan pertemuan tatap muka, mungkin untuk
mengumpulkan stakeholder pada saat yang sama, dengan
beberapa dari stakeholder berpartisipasi jarak jauh.
• Penggunaan konferensi audio dan video harus menyediakan
bandwidth yang wajar dan bermanfaat dengan interaksi
pada waktu yang sama.
Dimensi Requirements Negotiation
2. Kolaborasi situasi para pemangku kepentingan
Different time/ Different place
• Rekayasa kebutuhan semakin banyak dilakukan dalam
waktu dan lokasi yang berbeda karena semakin banyak
proyek yang dilakukan sehingga mempengaruhi beberapa
organisasi.
• Dengan adanya teknologi canggih untuk berkolaborasi
seperti menjadi sebuah keharusan yang memungkinkan
semua stakeholder untuk berkontribusi di belahan dunia
manapun stakeholder berada.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Negosiasi sering didukung dengan cara tradisional seperti
buku pedoman dan buku pegangan untuk fasilitasi serta alat
rapat pada umumnya bagi semua stakeholder seperti papan
tulis, kertas rencana kerja, dll.
Berdasarkan skala dan kompleksitas proyek dunia nyata
menyarankan penggunaan yang lebih canggih untuk
mendukung negosiasi mulai dari perangkat lunak untuk
berkomunikasi dan agen perangkat lunak cerdas.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Kersten dalam makalahnya memberikan klasifikasi mendalam
tentang alat pendukung negosiasi yang terbagi menjadi 3
yaitu:
Passive support,
Active facilitative support, dan
Pro-active interventive support.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Passive support
Passive support menyediakan infrastruktur untuk negosiasi
dan mendukung semua kolaborasi situasi yang berbeda. Alat
ini mengizinkan semua pihak terlibat untuk mengekspresikan
preferensi, berkomunikasi tentang ide-ide, saling tawar dan
ber-argumen, serta berbagi hasil akhir.
Contohnya adalah email, chatting atau multimedia room.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Active facilitative support
Active facilitative support mampu membimbing para
pemangku kepentingan (stakeholder) terhadap kesepakatan.
Misalnya, dengan mengidentifikasi situasi yang saling
menguntungkan.
Sistem tersebut dapat membantu pengguna dalam
perumusan, evaluasi, dan solusi dari masalah yang sulit. Alat
ini juga mendukung pembuatan konsesi dan konstruksi
penawaran, serta penilaian proses.
Dimensi Requirements Negotiation
3. Alat pendukung negosiasi
Pro-active interventive support
Pada pro-active interventive support mampu mengkoordinasikan
kegiatan para stakeholder. Sebagai contoh, mereka mengkritik
tindakan mereka atau menyarankan kesepakatan apa untuk
diterima. Untuk memberikan kemampuan tersebut akses sistem
menggunakan basis pengetahuan dan menggunakan agen perangkat
lunak cerdas dalam memantau proses negosiasi serta kegiatan
individu negosiator.
Contoh perangkat lunaknya adalah Atin intelligent software agent
augmenting the Inspire system.
Contoh Sistem Negosiasi
Para peneliti dan praktisi telah mengembangkan jenis sistem
negosiasi yang mendukung stakeholder dalam melakukan
negosiasi.
Namun, beberapa dari mereka ditargetkan khusus pada
perangkat lunak negosiasi kebutuhan, sementara sebagian
besar alat yang lain lebih mendukung negosiasi yang lebih
umum.
Contoh alat negosiasi adalah DealMaker, Inspire,
MeetingOne, Negoisst, SimpleNS, SmartSettle, dan
WebNS
=============== 14 Kualitas ========================
Pentingnya Jaminan Kualitas
Meningkatnya kompleksitas, meningkatnya tekanan pasar,
dan tuntutan pelanggan untuk kualitas yang lebih tinggi
membutuhkan suatu kombinasi yang hati-hati untuk dipilih,
divalidasi, dan verifikasi untuk memberikan suatu produk
software yang tepat waktu, sesuai anggaran, dan sesuai
dengan kualitas yang diinginkan
Pentingnya Jaminan Kualitas
Rekayasa kebutuhan adalah bagian awal dari proses
pengembangan software, dan
Semua langkah pembangunan selanjutnya dipengaruhi oleh
kebutuhan, membuat suatu kebutuhan yang berkualitas
merupakan faktor penting untuk keseluruhan kualitas dari
sistem yang dikembangkan.
Pentingnya Jaminan Kualitas
Mengapa penting untuk mendeteksi cacat sedini mungkin?
Sebuah isu yang berasal dari kebutuhan menjalankan resiko
yang mempengaruhi tidak hanya kebutuhan lain, tapi juga
mempengaruhi fase-fase dalam arsitektur, perancangan,
coding dan pengujian.
Kebutuhan dan Jaminan Kualitas
Kualitas adalah hal yang sulit untuk ditentukan karena
merupakan konsep yang rumit, tergantung pada sudut
pandang organisasi dan karakteristik konteks.
Misalnya, apakah lebih sedikit cacat per baris kode yang
sama berkualitas tinggi? Kualitas memiliki arti yang sangat
berbeda dalam situasi yang berbeda.
Kualitas Kebutuhan
Kualitas kebutuhan tergantung pada stakeholder dan
perspektif mereka. Beberapa pandangan yang berbeda perlu
dipertimbangkan dalam rangka untuk menentukan apakah
kualitas berarti dalam konteks tertentu.
Kualitas Kebutuhan
Pandangan pertama pada kualitas adalah Transcendental
View.
Di dalamnya, kualitas dianggap sebagai sesuatu yang
berusaha untuk ideal, tapi tidak akan pernah bisa
menerapkan ideal ini.
Tujuan dari sudut pandang ini adalah untuk mengungkapkan
kompleksitas kualitas konsep pada umumnya.
Kualitas Kebutuhan
• Pandangan kedua, User View mengevaluasi kualitas produk
perangkat lunak sehubungan dengan tujuan untuk
memenuhi tugas-tugas pengguna tertentu.
• Pandangan ketiga, Manufacturing view, fokus pada
tampilan produk selama produksi dan setelah pengiriman.
Hal ini difokuskan pada kepatuhan standard an
mengevaluasi apakah produk tersebut dibangun dengan
benar pertama kali.
Kualitas Kebutuhan
• Pandangan keempat adalah Product View. Fokus pandangan
ini adalah pada aspek kualitas internal produk yang dapat
diukur. Hal ini diasumsikan bahwa memastikan aspek mutu
internal tertentu memiliki dampak kualitas eksternal dan
kualitas dalam penggunaan produk.
• Terakhir, pandangan Value-Based View berhubungan
dengan biaya. Hal ini mempertimbangkan bahwa pelanggan
bersedia membayar untuk kualitas.
Kualitas Kebutuhan
Pemetaan pandangan pada kualitas kebutuhan mengungkapkan
bahwa pihak terkait (stakeholder) diperlukan untuk jaminan
kualitas (QA) kebutuhan.
Kebutuhan harus menggambarkan apa yang mengharuskan
pengguna lakukan dari sistem (User-View).
Selain itu, mereka harus dijelaskan dengan cara yang
memungkinkan developers menghasilkan perangkat lunak secara
efektif dan efisien (Product-View).
Kualitas Kebutuhan
Para Requirements Engineers harus mengikuti standar tertentu
ketika menentukan kebutuhan untuk memastikan kualitas
kebutuhan sejak awal (Manufacturing-View).
Dan terakhir, pelanggan harus memutuskan pada nilai kebutuhan
masing-masing dan biaya pelaksanaan (Value-Based View).
Atribut kualitas untuk kebutuhan
1. Correctness (IEEE, User-View)
Kebutuhan yang diterapkan harus mencerminkan apa yang
diharapkan (dimaksudkan) pengguna dan pelanggan. Artinya,
segala sesuatu yang dinyatakan sebagai syarat adalah
sesuatu yang harus dipenuhi oleh sistem akhir untuk
memenuhi tujuan tertentu (sesuai).
Atribut kualitas untuk kebutuhan
2. Unambiguity (IEEE, Product-View)
Kebutuhan harus memiliki hanya satu interpretasi yang
mungkin. Perhatikan bahwa salah satu kebutuhan mungkin
jelas untuk kelompok stakeholder tertentu, tetapi memiliki
arti yang berbeda untuk kelompok lain.
Hal ini penting untuk melibatkan semua stakeholder dalam
proses rekayasa kebutuhan untuk mendapatkan pemahaman
secara umum.
Atribut kualitas untuk kebutuhan
3. Completeness (IEEE, Product-View)
Semua elemen penting yang relevan untuk memenuhi tugas-tugas pengguna yang berbeda harus dipertimbangkan.
Ini termasuk kebutuhan fungsional dan non-fungsional yang
relevan dan interface ke sistem lain, tanggapan terhadap
semua potensi masukkan ke sistem, semua referensi untuk
gambar dan tabel dalam spesifikasi, definisi dari semua
kebutuhan dan langkah-langkah yang relevan.
Atribut kualitas untuk kebutuhan
4. Consistency (IEEE, Product, Manufacturing-View)
Kebutuhan yang dinyatakan harus konsisten dengan semua
kebutuhan lainnya, dan kendala penting lainnya seperti
pembatasan hardware, pembatasan anggaran, dll.
Atribut kualitas untuk kebutuhan
5. Ranked for Importance/ Stability (IEEE, Product, Value-Based, User-View)
Setiap kebutuhan menentukan seberapa pentingnya sesuatu
atau sering disebut stabilitas. Stabilitas mengungkapkan
kemungkinan perubahan kebutuhan, sedangkan menentukan
betapa pentingnya kebutuhan adalah untuk keberhasilan
proyek (dari sudut pandang value-based dan user).
Atribut kualitas untuk kebutuhan
6. Verifiability (IEEE, Product-View)
Semua kebutuhan harus diverifikasi. Artinya, terdapat suatu
proses untuk mesin atau manusia untuk memeriksa (dengan
biaya yang efektif) apakah kebutuhan terpenuhi atau tidak.
Atribut kualitas untuk kebutuhan
7. Modifiable (IEEE, Product-View)
Semua kebutuhan harus bisa dimodifikasi, yaitu struktur
kebutuhan dan spesifikasi kebutuhan memungkinkan integrasi
perubahan dengan cara yang mudah, konsisten dan lengkap.
Atribut kualitas untuk kebutuhan
8. Traceable (IEEE, Manufacturing-View)
Semua kebutuhan harus bisa dilacak, hal ini harus
memungkinkan agar preferensi kebutuhan dilacak dengan
cara yang mudah. Selain itu harus memungkinkan untuk
identifikasi asal kebutuhan.
Atribut kualitas untuk kebutuhan
9. Comprehensibility (New, Manufacturing, User, Value-Based View)
Kebutuhan yang ditentukan dan diungkapkan dengan cara
yang mudah dipahami oleh semua stakeholder yang terlibat.
Atribut kualitas untuk kebutuhan
10. Feasibility (New, Value-Based, Product-View)
Semua kebutuhan dapat diimplementasikan dengan teknologi
yang tersedia, sumber daya manusia dan anggaran yang
sesuai. Selain itu, semua kebutuhan berkontribusi terhadap
keberhasilan moneter dari sistem, yaitu mereka layak untuk
dimasukkan ke dalam sistem.
Atribut kualitas untuk kebutuhan
11. Right Level of Detail (New, User, Manufacturing, Value-Based View)
Informasi yang diberikan dalam kebutuhan ini cocok untuk
mendapatkan pemahaman yang benar tentang sistem dan
dalam memulai pelaksanaan. Tidak ada yang tidak perlu dalam
implementasi dan detail desain yang ditetapkan dalam
kebutuhan.
Strategi Kualitas Kebutuhan
Mengembangkan perangkat lunak tanpa adanya cacat
adalah hal yang tidak mungkin.
Namun, hal ini memungkinkan untuk mencapai sesuatu yang
optimal antara kualitas dan sumber daya yang tersedia,
mengingat faktor konteks yang spesifik dan pemenuhan
akan kualitas dari perusahaan atau sebuah proyek.
Strategi Kualitas Kebutuhan
Selama fase rekayasa kebutuhan, akan menjadi sangat
penting untuk menentukan strategi kualitas yang
membahas isu-isu kualitas yang dapat dengan mudah
diverifikasi dan divalidasi dalam fase kebutuhan.
Aspek kualitas lain yang tidak dapat ditangani secara
efisien selama tahap kebutuhan harus dibiarkan untuk
tahap selanjutnya.
Strategi Kualitas Kebutuhan
Elemen penting untuk menentukan strategi jaminan kualitas
untuk kebutuhan
Strategi Kualitas Kebutuhan
High quality of requirements
Menentukan kriteria kualitas untuk kebutuhan yang baik.
Kriteria ini dapat bervariasi dari perusahaan ke perusahaan
dan dari proyek untuk proyek. Hal ini penting untuk
menentukan set optimal dan minimal karakteristik kualitas
kebutuhan.
Strategi Kualitas Kebutuhan
Available resources
Menggambarkan upaya yang tersedia, anggaran, perangkat
keras, dan personil untuk melakukan QA selama kegiatan
pengumpulan kebutuhan.
Selain itu, ketersediaan ahli tambahan harus
dipertimbangkan, seperti pendekatan jaminan kualitas
tertentu, stakeholder tertentu di luar rekayasa kebutuhan.
Sumber daya yang tersedia juga berdampak langsung pada
pendekatan QA yang berlaku.
Strategi Kualitas Kebutuhan
Risks
Resiko terkait dengan kebutuhan tertentu, terutama resiko
yang tidak mengharuskan atau menerapkan kebutuhan dengan
cara yang salah, resiko merupakan faktor tambahan yang
mempengaruhi strategi kualitas.
Strategi Kualitas Kebutuhan
Time schedule
Terkait dengan sumber daya yang tersedia dan menentukan
waktu yang tersedia untuk QA pada umumnya dan dalam
tahap kebutuhan khususnya.
Waktu sangat penting karena terkait dengan kegiatan
jaminan kualitas kebutuhan dengan kegiatan lainnya.
Strategi Kualitas Kebutuhan
Organization Aspects
Seperti proses pembangunan, contohnya agile development
atau product domain, (contoh: perangkat lunak desktop atau
airplane control system) mempengaruhi keputusan
pendekatan QA yang digunakan.
Pendekatan QA untuk kebutuhan
Pendekatan QA untuk kebutuhan
Pendekatan jaminan kualitas terbagi menjadi dua kelas yakni
1. Pendekatan Constructive dan
2. Pendekatan Analytical.
Pendekatan QA untuk kebutuhan
1. Pendekatan Constructive
Pendekatan Constructive memastikan bahwa kesalahan yang
diminimalkan selama pembuatan produk (misalnya spesifikasi
kebutuhan).
Contoh pendekatan Constructive dalam fase rekayasa
kebutuhan adalah bagaimana menentukan kebutuhan,
template untuk spesifikasi kebutuhan, pendekatan elisitasi
dan prototyping.
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Pendekatan Analytical dilakukan pada artefak yang komplit
atau sebagian dengan tujuan untuk mendeteksi masalah.
Pendekatan jaminan kualitas Analytical dapat dibagi lagi
menjadi pendekatan jaminan kualitas static dan
pendekatan jaminan kualitas dynamic (termasuk formal
methods).
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Perbedaan antara dua kelas adalah bahwa pendekatan dynamic
memerlukan versi executable dari sistem.
Pendekatan pengujian adalah contoh jaminan kualitas dynamic.
Pendekatan QA untuk kebutuhan
2. Pendekatan Analytical.
Pendekatan jaminan kualitas static dapat dilakukan tanpa
mengeksekusi kode. Inspeksi dan verifikasi formal merupakan
contoh pendekatan static.
Ada dalam banyak kasus tidak ada kode yang dieksekusi selama
fase rekayasa kebutuhan. Oleh karena itu, biasanya hanya
pendekatan static yang berlaku.
Selasa, 07 Juli 2015
Kamis, 30 April 2015
Materi UTS Software Requirement Engineering
Salah satu bagian tersulit dalam pembuatan sistem perangkat lunak adalah memutuskan dengan tepat apa yang akan dibuat - F. Brooks
Pengertian Requirement
- Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut (Robertson99)
- Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan (Anton96)
Requirement Engineering adalah Proses dimana persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh iklus hidup rekayasa perangkat lunak.
Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan
Kenapa Requirement Engineering dibutuhkan?
- Requirements yang tidak lengkap adalah sumber utama dari kegagalan (Standish95)
- Banyaknya masalah yang dirasakan terkait dengan spesifikasi kebutuhan (>50%) – (ESI96)
- Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut (Bell&Tayer76)
- Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81)
Requirement Classifications
1. Kebutuhan fungsional
Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam sistem baru. Kebutuhan fungsional mencakup:
* Fungsi deskripsi kebutuhan
* Laporan baik hardcopy maupun softcopy
* Updating dan query online
* Penyimpanan data, pencarian kembali dan transfer data
2. Kebutuhan Non fungsional mencakup:
* Waktu respon
* Rata-rata waktu untuk kegagalan
* Kebutuhan keamanan
* Akses untuk pengguna yang tidak punya hak
1. Primary requirements – elicited from stakeholders
Requirements yang didapatkan langsung dari client/ pihak yang berkepentingan.
2. Derived requirements – derived from primary requirements
Diperoleh dari kebutuhan primer sebelumnya, biasanya bersifat turunan/ tambahan secara detail dari kebutuhan primer yang ada
Ini melibatkan memahami kebutuhan para pemangku kepentingan, memunculkan kebutuhan, pemodelan dan mengumpulkan mereka dalam repositori.
2. Prioritization
Kegiatan ini membantu manajer proyek dengan menyelesaikan konflik (di mana pelanggan dan pengembang berkolaborasi pada prioritas kebutuhan), rencana pengiriman bertahap, dan membuat keputusan yang diperlukan
3. Requirements Dependencies and Impact Analysis
Hal ini penting untuk mengakui bahwa perubahan kebutuhan dan ini secara signifikan dapat mempengaruhi proyek software
4. Requirements Negotiation
Rekayasa kebutuhan dasarnya adalah komunikasi dan proses negosiasi kompleks yang melibatkan pelanggan, desainer, manajer proyek dan pengelola.
5. Quality Assurance
Tujuannya adalah untuk memastikan bahwa kebutuhan kualitas tinggi dicatat dalam dokumen spesifikasi.
Tujuan dari jaminan kualitas adalah untuk menetapkan tingkat yang wajar dan realistis saat menyusun dan mengelola persyaratan.
Bagian penting dari elisitasi didedikasikan untuk mengungkap, menggali, dan memunculkan keinginan dari para pemangku kepentingan potensial.
Proses elisitasi kebutuhan melibatkan serangkaian kegiatan yang harus memungkinkan untuk komunikasi, prioritas, negosiasi, dan kolaborasi dengan semua pemangku kepentingan terkait.
Hal ini penting ketika memulai proses elisitasi kebutuhan untuk menyelidiki dan memeriksa secara rinci situasi atau "dunia nyata" di mana sistem utama berada (kadang-kadang disebut domain aplikasi). | Lingkungan saat ini perlu benar-benar dieksplorasi, termasuk aspek-aspek politik, organisasi, dan sosial yang berkaitan dengan sistem, di samping setiap kendala yang ada pada sistem dan perkembangannya.
2. Identifying the sources of Requirements
- Kebutuhan dapat tersebar di berbagai sumber dan ada dalam berbagai format
- Dalam semua proyek pengembangan perangkat lunak sejumlah kemungkinan sumber dari kebutuhan dapat diidentifikasi
- Stakeholder merupakan sumber yang paling jelas dari persyaratan untuk sistem
- Sistem dan proses yang ada merupakan sumber lain untuk memunculkan kebutuhan, terutama ketika proyek melibatkan pergantian sistem saat ini atau warisan dari sistem sebelumnya.
3. Analyzing the Stakeholders
Salah satu langkah dalam elisitasi kebutuhan adalah untuk menganalisis dan melibatkan semua pemangku kepentingan yang relevan. Stakeholder adalah orang-orang yang memiliki kepentingan dalam sistem atau yang berpengaruh dalam beberapa pengembangan dan implementasi sistem.
4. Selecting the Techniques, Approaches, and Tool to Use
Pemilihan teknik yang akan digunakan tergantung pada konteks khusus dari proyek ini dan merupakan faktor penting dalam keberhasilan proses elisitasi. Hickey dan Davis telah menyelidiki pemilihan teknik elisitasi dan menyatakan bahwa teknik elisitasi tertentu dapat dipilih untuk berbagai alasan
A. Teknik yang dipilih adalah satu-satunya yang analis tahu
B. Teknik yang dipilih adalah favorit analis
C. Teknik yang dipilih adalah salah satu yang ditentukan oleh metodologi tertentu yang sedang diikuti untuk pengembangan sistem
D. Pilihan teknik diatur sendiri oleh intuisi analis sehingga efektif dalam konteks saat ini
5. Eliciting the Requirements from Stakeholders and Other Sources
Selama kegiatan ini penting untuk menetapkan tingkat lingkup sistem dan menyelidiki secara rinci kebutuhan dan keinginan para pemangku kepentingan, terutama pengguna. Juga penting untuk menentukan masa depan proses dalam sistem yang dilakukan sehubungan dengan operasi bisnis, dan Menelaah cara-cara di mana sistem dapat mendukung untuk memenuhi tujuan utama dan mengatasi masalah utama bisnis
- Tanggung jawab dan peran ini tergantung pada proyek, orang, konteks dan organisasi yang terlibat
1. Requirements engineers memainkan peran penting sebagai
facilitator
Ketika memunculkan kebutuhan pada sesi kerja kelompok, mereka tidak hanya dituntut untuk mengajukan pertanyaan dan mencatat jawaban, tetapi harus membimbing dan membantu peserta dalam menangani isu-isu yang relevan untuk mendapatkan informasi kebutuhan yang benar dan lengkap.
2. Requirements engineers sebagai mediator
Dalam banyak kasus prioritas kebutuhan dari kelompok pemangku kepentingan yang berbeda adalah sumber dari banyak perdebatan dan perselisihan. Requirements engineers memiliki tanggung jawab untuk untuk mencari resolusi yang sesuai melalui negosiasi dan kompromi.
3. Requirements engineers bertanggungjawab untuk mendokumentasikan kebutuhan yang dimunculkan selama proses elisitasi. Peran ini sangat penting karena merupakan produksi hasil dari
proses elisitasi, dan membentuk dasar untuk proyek fase
berikutnya
4. Semua kebutuhan yang muncul divalidasi terhadap pemangku
kepentingan lainnya, sistem lain, satu sama lain, dan kemudian dibandingkan dengan sasaran yang telah ditetapkan sebelumnya untuk sistem.
Terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) dengan detail dekomposisi fungsional yang menekankan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain.
2. Object Oriented (OO) Approaches
Khususnya Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi kebutuhan ang ditetapkan dengan notasi namun fleksibel dan format seperti Use Case diagrams, Use Case descriptions, and Class Diagrams.
Perbedaan antara modeling dan spesifikasi:
Modeling sesuai dengan aktivitas memilih meta-model untuk meresmikan pada tingkat konseptual/ tampilan sistem ertentu, sedangkan
Spesifikasi berkaitan dengan penerapan bahasa untuk membuat model sistem nyata.
2. Activity Oriented Meta-Models Meta-models berorientasi aktivitas memungkinkan pemodelan sistem sebagai erangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi yang berkaitan. contoh : Data Flow Diagram (DFD), Flowcharts
3. Structured Oriented Meta-Models Structured oriented meta-models memungkinkan deskripsi sistem modul fisik dan interkoneksi mereka. Meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya.
Contoh: Block Diagram/ Component-Connectivity Diagrams (CCDs), UML’s deployment dan component diagram didasarkan pada meta-model ini.
4. Data Oriented Meta-Models Data oriented meta-models memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. biasanya digunakan dalam metodologi berdasarkan analisis struktur tradisional dan teknik desain. Ex ERD, JSDs
5. Heterogeneous Meta-Models Heterogeneous meta-models memungkinkan penggunaan dalam representasi sistem yang sama, beberapa karakteristik dari meta-model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya
Contoh :
- Control/ Data Flow Graphs (CDFGs)
- Object Process Diagram (OPDs)
- Program State Machines (PSMs)
6. Multiple-View Approach
Dengan meningkatnya kompleksitas sistem, penggunaan meta-model yang berbeda untuk mewakili berbagai jenis karakteristik sistem menjadi hal yang umum.
Pada dasarnya tergantung pada bahasa spesifikasi, dan jika dikelola dengan benar memungkinkan diperoleh spesifikasi yang ringkas dan mudah dipahami.
- Pendekatan grafis biasanya lebih mudah dipahami daripada yang tekstual. Dengan demikian meningkatkan pembacaan dan understandability pandangan sistem.
- UML mengadopsi pendekatan grafis
2. Development complexity
Dimensi kedua kontrol kompleksitas (development complexity) mengacu pada kontrol dari evolusi spesifikasi sistem dari konseptualisasi awal kebutuhan.
Requirements Transformation 4SRS Technique
Step 1 – Object creation
Setiap use case harus ditransformasikan ke dalam 3 objek (One interfaces, one data, and one control)
Step 2 – Object elimination
Ini harus diputuskan mana dari tiga obyek harus dijaga untuk sepenuhnya mewakili dengan mempertimbangkan seluruh sistem
Step 3 – Object packaging and aggregation
Objek yang tersisa (dari step 2) yang ada keuntungan dalam diperlakukan dengan cara yang terpadu harus memberikan asal ke agregasi atau paket objek yang konsisten
Step 4 – Object association
Mendukung asosiasi di dalam model objek
Tujuan Requirements Prioritization-
- Para pemangku kepentingan dapat menentukan kebutuhan inti untuk sistem
- Untuk merencanakan dan memilih set optimal kebutuhan perangkat lunak untuk implementasi dalam rilis yang berturut-turut
- Untuk lingkup proyek yang diinginkan kadang-kadang bertentangan dengan kendala seperti jadwal, anggaran, sumber
daya, waktu rilis ke pasaran, dan kualitas.
- Untuk menyeimbangkan manfaat bisnis terhadap biaya
- Untuk menyeimbangkan akibat dari kebutuhan pada arsitektur perangkat lunak dan evolusi masa depan produk dan biaya yang terkait
- Untuk memilih hanya sebagian dari kebutuhan dan masih menghasilkan sebuah sistem yang akan memuaskan pelanggan
- Untuk memperkirakan kepuasan pelanggan yang diharapkan
- Untuk mendapatkan keunggulan teknis dan mengoptimalkan peluang pasar
- Untuk meminimalkan kerja ulang dan jadwal (stabilitas rencana)
- Untuk menangani kebutuhan yang bertentangan, fokus pada proses negosiasi, dan menyelesaikan perbedaan pendapat antara para pemangku kepentingan
- Untuk menentukan kepentingan relatif dari setiap kebutuhan untuk memberikan nilai terbesar pada biaya terendah
Kategori Requirements Prioritization
- Metode didasarkan pada jumlah menempatkan nilai ke aspek yang
berbeda dari kebutuhan, sementara pendekatan negosiasi fokus
pada memberikan prioritas untuk kebutuhan dengan mencapai
kesepakatan antara para pemangku kepentingan yang berbeda.
- Pendekatan negosiasi didasarkan pada ukuran subjektif dan
biasanya digunakan ketika analisis kontekstual dan ketika variabel
keputusan yang saling terkait.
Ketika memprioritaskan kepentingan, para pemangku kepentingan harus memprioritaskan mana persyaratan yang paling penting bagi sistem. Namun, penting bisa menjadi konsep yang sangat beragam karena sangat tergantung pada
perspektif yang dimiliki pemangku kepentingan.
2. Hukuman
Hal ini dimungkinkan untuk mengevaluasi hukuman yang diperkenalkan jika persyaratan tidak terpenuhi. Misalnya, gagal untuk menyesuaikan diri dengan standar akan dikenakan penalti tinggi bahkan jika itu sangat rendah bagi
pelanggan (yaitu pelanggan tidak merasa senang jika kebutuhannya tidak terpenuhi).
3. Biaya
Biaya pelaksanaan biasanya diperkirakan oleh organisasi pengembang. Tindakan yang mempengaruhi biaya meliputi:
kompleksitas kebutuhan, kemampuan untuk menggunakan kembali kode yang ada, jumlah pengujian dan dokumentasi
yang diperlukan, dll
4. Waktu
Biaya dalam pengembangan perangkat lunak sering berhubungan dengan jumlah jam staf. Namun, dipengaruhi oleh banyak faktor lain seperti tingkat paralelisme dalam pembangunan, kebutuhan pelatihan, perlu mengembangkan infrastruktur pendukung, standar industri yang lengkap, dll
5. Resiko
Setiap proyek membawa beberapa jumlah risiko. Dalam manajemen proyek, manajemen risiko digunakan untuk mengatasi baik internal (teknis dan risiko pasar) dan risiko eksternal (misalnya peraturan, pemasok). Manajemen risiko juga dapat digunakan ketika merencanakan persyaratan menjadi produk dan rilis dengan mengidentifikasi risiko yang cenderung menyebabkan kesulitan selama pengembangan. Risiko tersebut bisa mencakup misalnya risiko kinerja, risiko proses, risiko jadwal dll
6. Volatilitas (Hal yang berubah-ubah)
Volatilitas persyaratan dianggap sebagai faktor risiko dan kadang-kadang ditangani sebagai bagian dari aspek risiko. Orang lain berpikir bahwa volatilitas harus dianalisis secara terpisah dan volatilitas persyaratan harus diperhitungkan secara terpisah dalam proses prioritas. Misalnya: perubahan pasar, kebutuhan bisnis berubah, perubahan
legislatif yang terjadi, pengguna berubah.
7. Aspek Lain
Dari daftar di atas aspek telah dianggap penting dalam literatur tetapi tidak berarti lengkap. Contoh aspek lain adalah: keuntungan finansial, manfaat strategis, pesaing, kompetensi/ sumber daya, rilis tema, kemampuan untuk menjual, dll Bagi perusahaan, disarankan agar para pemangku kepentingan mengembangkan daftar aspek penting untuk digunakan dalam pengambilan keputusan. Adalah penting bahwa para pemangku kepentingan memiliki penafsiran yang sama dari aspek serta persyaratan.
8. Menggabungkan Aspek yang berbeda-beda
Dalam prakteknya, penting untuk mempertimbangkan beberapa aspek sebelum memutuskan apakah persyaratan harus dilaksanakan secara langsung, kemudian, atau tidak sama sekali. Sebagai contoh, dalam pendekatan Cost-Value, baik value
(penting) dan biaya diprioritaskan untuk melaksanakan persyaratan yang memberikan nilai untuk uang
Penelitian telah menunjukkan bahwa AHP tidak cocok untuksejumlah besar kebutuhan.Para peneliti telah mencoba untuk menemukan cara untukmengurangi jumlah perbandingan dan varian teknik telah ditemukan untuk mengurangi jumlah perbandingan sebanyak 75 persen.
2. Cumulative Voting, the 100-Dollar Test
Tes 100-dolar adalah teknik prioritas yang sangat mudah di mana para pemangku kepentingan diberikan 100 unit imajiner (uang, jam, dll) untuk mendistribusikan antara kebutuhan. Hasil prioritas disajikan pada skala rasio.
3. Numerical Assignment (Grouping)
Numerical assignment adalah teknik prioritas yang paling umum dan disarankan baik di RFC 2119 dan IEEE Std. 830-1998. Pendekatan ini didasarkan pada pengelompokan kebutuhan ke dalam kelompok prioritas yang berbeda. Jumlah kelompok dapat bervariasi, tetapi dalam prakteknya, tiga kelompok yang sangat umum.
3. Numerical Assignment (Grouping)
Bila menggunakan tugas numerik, adalah penting bahwa masing-masing kelompok mewakili sesuatu yang para pemangku kepentingan dapat berhubungan dengan (misalnya kritis, standar, opsional), untuk klasifikasi handa.
4. Ranking
Setiap kebutuhan memiliki peringkat yang unik (dibandingkan dengan tugas numerik) tetapi tidak mungkin untuk melihat perbedaan relatif antara item peringkat (seperti dalam AHP atau tes 100 dolar).
5. Top-Ten Requirements
Dalam pendekatan kebutuhan top-sepuluh, para pemangku kepentingan memilih kebutuhan mereka sepuluh paling atas (dari satu set yang lebih besar) tanpa menetapkan perintah internal antara kebutuhan.
Pengertian Requirement
- Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut (Robertson99)
- Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan (Anton96)
Requirement Engineering adalah Proses dimana persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh iklus hidup rekayasa perangkat lunak.
Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan
Kenapa Requirement Engineering dibutuhkan?
- Requirements yang tidak lengkap adalah sumber utama dari kegagalan (Standish95)
- Banyaknya masalah yang dirasakan terkait dengan spesifikasi kebutuhan (>50%) – (ESI96)
- Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut (Bell&Tayer76)
- Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81)
Requirement Classifications
1. Kebutuhan fungsional
Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam sistem baru. Kebutuhan fungsional mencakup:
* Fungsi deskripsi kebutuhan
* Laporan baik hardcopy maupun softcopy
* Updating dan query online
* Penyimpanan data, pencarian kembali dan transfer data
2. Kebutuhan Non fungsional mencakup:
* Waktu respon
* Rata-rata waktu untuk kegagalan
* Kebutuhan keamanan
* Akses untuk pengguna yang tidak punya hak
1. Primary requirements – elicited from stakeholders
Requirements yang didapatkan langsung dari client/ pihak yang berkepentingan.
2. Derived requirements – derived from primary requirements
Diperoleh dari kebutuhan primer sebelumnya, biasanya bersifat turunan/ tambahan secara detail dari kebutuhan primer yang ada
Requirements Management
1. Requirements Elicitation, Specification and ModelingIni melibatkan memahami kebutuhan para pemangku kepentingan, memunculkan kebutuhan, pemodelan dan mengumpulkan mereka dalam repositori.
2. Prioritization
Kegiatan ini membantu manajer proyek dengan menyelesaikan konflik (di mana pelanggan dan pengembang berkolaborasi pada prioritas kebutuhan), rencana pengiriman bertahap, dan membuat keputusan yang diperlukan
3. Requirements Dependencies and Impact Analysis
Hal ini penting untuk mengakui bahwa perubahan kebutuhan dan ini secara signifikan dapat mempengaruhi proyek software
4. Requirements Negotiation
Rekayasa kebutuhan dasarnya adalah komunikasi dan proses negosiasi kompleks yang melibatkan pelanggan, desainer, manajer proyek dan pengelola.
5. Quality Assurance
Tujuannya adalah untuk memastikan bahwa kebutuhan kualitas tinggi dicatat dalam dokumen spesifikasi.
Tujuan dari jaminan kualitas adalah untuk menetapkan tingkat yang wajar dan realistis saat menyusun dan mengelola persyaratan.
Requirement Elicitation
Requirements Elicitation adalah proses mempelajari dan memahami kebutuhan pengguna dan sponsor proyek dengan tujuan utama berkomunikasi mengenai kebutuhan dengan para pengembang sistemBagian penting dari elisitasi didedikasikan untuk mengungkap, menggali, dan memunculkan keinginan dari para pemangku kepentingan potensial.
Proses elisitasi kebutuhan melibatkan serangkaian kegiatan yang harus memungkinkan untuk komunikasi, prioritas, negosiasi, dan kolaborasi dengan semua pemangku kepentingan terkait.
Proses Requirement Elicitation
1. Understanding the application domain
Hal ini penting ketika memulai proses elisitasi kebutuhan untuk menyelidiki dan memeriksa secara rinci situasi atau "dunia nyata" di mana sistem utama berada (kadang-kadang disebut domain aplikasi). | Lingkungan saat ini perlu benar-benar dieksplorasi, termasuk aspek-aspek politik, organisasi, dan sosial yang berkaitan dengan sistem, di samping setiap kendala yang ada pada sistem dan perkembangannya.
2. Identifying the sources of Requirements
- Kebutuhan dapat tersebar di berbagai sumber dan ada dalam berbagai format
- Dalam semua proyek pengembangan perangkat lunak sejumlah kemungkinan sumber dari kebutuhan dapat diidentifikasi
- Stakeholder merupakan sumber yang paling jelas dari persyaratan untuk sistem
- Sistem dan proses yang ada merupakan sumber lain untuk memunculkan kebutuhan, terutama ketika proyek melibatkan pergantian sistem saat ini atau warisan dari sistem sebelumnya.
3. Analyzing the Stakeholders
Salah satu langkah dalam elisitasi kebutuhan adalah untuk menganalisis dan melibatkan semua pemangku kepentingan yang relevan. Stakeholder adalah orang-orang yang memiliki kepentingan dalam sistem atau yang berpengaruh dalam beberapa pengembangan dan implementasi sistem.
4. Selecting the Techniques, Approaches, and Tool to Use
Pemilihan teknik yang akan digunakan tergantung pada konteks khusus dari proyek ini dan merupakan faktor penting dalam keberhasilan proses elisitasi. Hickey dan Davis telah menyelidiki pemilihan teknik elisitasi dan menyatakan bahwa teknik elisitasi tertentu dapat dipilih untuk berbagai alasan
A. Teknik yang dipilih adalah satu-satunya yang analis tahu
B. Teknik yang dipilih adalah favorit analis
C. Teknik yang dipilih adalah salah satu yang ditentukan oleh metodologi tertentu yang sedang diikuti untuk pengembangan sistem
D. Pilihan teknik diatur sendiri oleh intuisi analis sehingga efektif dalam konteks saat ini
5. Eliciting the Requirements from Stakeholders and Other Sources
Selama kegiatan ini penting untuk menetapkan tingkat lingkup sistem dan menyelidiki secara rinci kebutuhan dan keinginan para pemangku kepentingan, terutama pengguna. Juga penting untuk menentukan masa depan proses dalam sistem yang dilakukan sehubungan dengan operasi bisnis, dan Menelaah cara-cara di mana sistem dapat mendukung untuk memenuhi tujuan utama dan mengatasi masalah utama bisnis
Peran Requirements Engineer selama elisitasi
- Selama elisitasi kebutuhan requirement engineer (analis sistem atau analis bisnis) dapat memainkan berbagai peran dan memikul tanggung jawab yang berbeda.- Tanggung jawab dan peran ini tergantung pada proyek, orang, konteks dan organisasi yang terlibat
1. Requirements engineers memainkan peran penting sebagai
facilitator
Ketika memunculkan kebutuhan pada sesi kerja kelompok, mereka tidak hanya dituntut untuk mengajukan pertanyaan dan mencatat jawaban, tetapi harus membimbing dan membantu peserta dalam menangani isu-isu yang relevan untuk mendapatkan informasi kebutuhan yang benar dan lengkap.
2. Requirements engineers sebagai mediator
Dalam banyak kasus prioritas kebutuhan dari kelompok pemangku kepentingan yang berbeda adalah sumber dari banyak perdebatan dan perselisihan. Requirements engineers memiliki tanggung jawab untuk untuk mencari resolusi yang sesuai melalui negosiasi dan kompromi.
3. Requirements engineers bertanggungjawab untuk mendokumentasikan kebutuhan yang dimunculkan selama proses elisitasi. Peran ini sangat penting karena merupakan produksi hasil dari
proses elisitasi, dan membentuk dasar untuk proyek fase
berikutnya
4. Semua kebutuhan yang muncul divalidasi terhadap pemangku
kepentingan lainnya, sistem lain, satu sama lain, dan kemudian dibandingkan dengan sasaran yang telah ditetapkan sebelumnya untuk sistem.
Methodology Based Requirements Elicitation
1. Structured Analysis and Design (SAD)Terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) dengan detail dekomposisi fungsional yang menekankan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain.
2. Object Oriented (OO) Approaches
Khususnya Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi kebutuhan ang ditetapkan dengan notasi namun fleksibel dan format seperti Use Case diagrams, Use Case descriptions, and Class Diagrams.
Perbedaan antara modeling dan spesifikasi:
Modeling sesuai dengan aktivitas memilih meta-model untuk meresmikan pada tingkat konseptual/ tampilan sistem ertentu, sedangkan
Spesifikasi berkaitan dengan penerapan bahasa untuk membuat model sistem nyata.
Meta-Models Categories
1. State Oriented Meta-Models adalah State oriented meta-models memungkinkan pemodelan sistem sebagai set of states dan satu set transisi. Contoh : Contoh: Finite State Machines (FSMs), Finite State Machines with Data paths (FSMDs), State Charts, Petri nets2. Activity Oriented Meta-Models Meta-models berorientasi aktivitas memungkinkan pemodelan sistem sebagai erangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi yang berkaitan. contoh : Data Flow Diagram (DFD), Flowcharts
3. Structured Oriented Meta-Models Structured oriented meta-models memungkinkan deskripsi sistem modul fisik dan interkoneksi mereka. Meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya.
Contoh: Block Diagram/ Component-Connectivity Diagrams (CCDs), UML’s deployment dan component diagram didasarkan pada meta-model ini.
4. Data Oriented Meta-Models Data oriented meta-models memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. biasanya digunakan dalam metodologi berdasarkan analisis struktur tradisional dan teknik desain. Ex ERD, JSDs
5. Heterogeneous Meta-Models Heterogeneous meta-models memungkinkan penggunaan dalam representasi sistem yang sama, beberapa karakteristik dari meta-model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya
Contoh :
- Control/ Data Flow Graphs (CDFGs)
- Object Process Diagram (OPDs)
- Program State Machines (PSMs)
6. Multiple-View Approach
Dengan meningkatnya kompleksitas sistem, penggunaan meta-model yang berbeda untuk mewakili berbagai jenis karakteristik sistem menjadi hal yang umum.
Complexity Control
1. Representational complexityPada dasarnya tergantung pada bahasa spesifikasi, dan jika dikelola dengan benar memungkinkan diperoleh spesifikasi yang ringkas dan mudah dipahami.
- Pendekatan grafis biasanya lebih mudah dipahami daripada yang tekstual. Dengan demikian meningkatkan pembacaan dan understandability pandangan sistem.
- UML mengadopsi pendekatan grafis
2. Development complexity
Dimensi kedua kontrol kompleksitas (development complexity) mengacu pada kontrol dari evolusi spesifikasi sistem dari konseptualisasi awal kebutuhan.
Requirements Transformation 4SRS Technique
Step 1 – Object creation
Setiap use case harus ditransformasikan ke dalam 3 objek (One interfaces, one data, and one control)
Step 2 – Object elimination
Ini harus diputuskan mana dari tiga obyek harus dijaga untuk sepenuhnya mewakili dengan mempertimbangkan seluruh sistem
Step 3 – Object packaging and aggregation
Objek yang tersisa (dari step 2) yang ada keuntungan dalam diperlakukan dengan cara yang terpadu harus memberikan asal ke agregasi atau paket objek yang konsisten
Step 4 – Object association
Mendukung asosiasi di dalam model objek
Requirements Prioritization
Penjelasan tentang teknik untuk menentukan prioritas kebutuhan untuk produk perangkat lunak untuk mengidentifikasi kebutuhan yang paling berharga dengan membedakan hal yang kritis daripada yang biasa.Tujuan Requirements Prioritization-
- Para pemangku kepentingan dapat menentukan kebutuhan inti untuk sistem
- Untuk merencanakan dan memilih set optimal kebutuhan perangkat lunak untuk implementasi dalam rilis yang berturut-turut
- Untuk lingkup proyek yang diinginkan kadang-kadang bertentangan dengan kendala seperti jadwal, anggaran, sumber
daya, waktu rilis ke pasaran, dan kualitas.
- Untuk menyeimbangkan manfaat bisnis terhadap biaya
- Untuk menyeimbangkan akibat dari kebutuhan pada arsitektur perangkat lunak dan evolusi masa depan produk dan biaya yang terkait
- Untuk memilih hanya sebagian dari kebutuhan dan masih menghasilkan sebuah sistem yang akan memuaskan pelanggan
- Untuk memperkirakan kepuasan pelanggan yang diharapkan
- Untuk mendapatkan keunggulan teknis dan mengoptimalkan peluang pasar
- Untuk meminimalkan kerja ulang dan jadwal (stabilitas rencana)
- Untuk menangani kebutuhan yang bertentangan, fokus pada proses negosiasi, dan menyelesaikan perbedaan pendapat antara para pemangku kepentingan
- Untuk menentukan kepentingan relatif dari setiap kebutuhan untuk memberikan nilai terbesar pada biaya terendah
Kategori Requirements Prioritization
- Metode didasarkan pada jumlah menempatkan nilai ke aspek yang
berbeda dari kebutuhan, sementara pendekatan negosiasi fokus
pada memberikan prioritas untuk kebutuhan dengan mencapai
kesepakatan antara para pemangku kepentingan yang berbeda.
- Pendekatan negosiasi didasarkan pada ukuran subjektif dan
biasanya digunakan ketika analisis kontekstual dan ketika variabel
keputusan yang saling terkait.
Aspek Prioritas
1. Tingkat KepentingannyaKetika memprioritaskan kepentingan, para pemangku kepentingan harus memprioritaskan mana persyaratan yang paling penting bagi sistem. Namun, penting bisa menjadi konsep yang sangat beragam karena sangat tergantung pada
perspektif yang dimiliki pemangku kepentingan.
2. Hukuman
Hal ini dimungkinkan untuk mengevaluasi hukuman yang diperkenalkan jika persyaratan tidak terpenuhi. Misalnya, gagal untuk menyesuaikan diri dengan standar akan dikenakan penalti tinggi bahkan jika itu sangat rendah bagi
pelanggan (yaitu pelanggan tidak merasa senang jika kebutuhannya tidak terpenuhi).
3. Biaya
Biaya pelaksanaan biasanya diperkirakan oleh organisasi pengembang. Tindakan yang mempengaruhi biaya meliputi:
kompleksitas kebutuhan, kemampuan untuk menggunakan kembali kode yang ada, jumlah pengujian dan dokumentasi
yang diperlukan, dll
4. Waktu
Biaya dalam pengembangan perangkat lunak sering berhubungan dengan jumlah jam staf. Namun, dipengaruhi oleh banyak faktor lain seperti tingkat paralelisme dalam pembangunan, kebutuhan pelatihan, perlu mengembangkan infrastruktur pendukung, standar industri yang lengkap, dll
5. Resiko
Setiap proyek membawa beberapa jumlah risiko. Dalam manajemen proyek, manajemen risiko digunakan untuk mengatasi baik internal (teknis dan risiko pasar) dan risiko eksternal (misalnya peraturan, pemasok). Manajemen risiko juga dapat digunakan ketika merencanakan persyaratan menjadi produk dan rilis dengan mengidentifikasi risiko yang cenderung menyebabkan kesulitan selama pengembangan. Risiko tersebut bisa mencakup misalnya risiko kinerja, risiko proses, risiko jadwal dll
6. Volatilitas (Hal yang berubah-ubah)
Volatilitas persyaratan dianggap sebagai faktor risiko dan kadang-kadang ditangani sebagai bagian dari aspek risiko. Orang lain berpikir bahwa volatilitas harus dianalisis secara terpisah dan volatilitas persyaratan harus diperhitungkan secara terpisah dalam proses prioritas. Misalnya: perubahan pasar, kebutuhan bisnis berubah, perubahan
legislatif yang terjadi, pengguna berubah.
7. Aspek Lain
Dari daftar di atas aspek telah dianggap penting dalam literatur tetapi tidak berarti lengkap. Contoh aspek lain adalah: keuntungan finansial, manfaat strategis, pesaing, kompetensi/ sumber daya, rilis tema, kemampuan untuk menjual, dll Bagi perusahaan, disarankan agar para pemangku kepentingan mengembangkan daftar aspek penting untuk digunakan dalam pengambilan keputusan. Adalah penting bahwa para pemangku kepentingan memiliki penafsiran yang sama dari aspek serta persyaratan.
8. Menggabungkan Aspek yang berbeda-beda
Dalam prakteknya, penting untuk mempertimbangkan beberapa aspek sebelum memutuskan apakah persyaratan harus dilaksanakan secara langsung, kemudian, atau tidak sama sekali. Sebagai contoh, dalam pendekatan Cost-Value, baik value
(penting) dan biaya diprioritaskan untuk melaksanakan persyaratan yang memberikan nilai untuk uang
Prioritization Techniques
1. Analytical Hierarchy Process (AHP)Penelitian telah menunjukkan bahwa AHP tidak cocok untuksejumlah besar kebutuhan.Para peneliti telah mencoba untuk menemukan cara untukmengurangi jumlah perbandingan dan varian teknik telah ditemukan untuk mengurangi jumlah perbandingan sebanyak 75 persen.
2. Cumulative Voting, the 100-Dollar Test
Tes 100-dolar adalah teknik prioritas yang sangat mudah di mana para pemangku kepentingan diberikan 100 unit imajiner (uang, jam, dll) untuk mendistribusikan antara kebutuhan. Hasil prioritas disajikan pada skala rasio.
3. Numerical Assignment (Grouping)
Numerical assignment adalah teknik prioritas yang paling umum dan disarankan baik di RFC 2119 dan IEEE Std. 830-1998. Pendekatan ini didasarkan pada pengelompokan kebutuhan ke dalam kelompok prioritas yang berbeda. Jumlah kelompok dapat bervariasi, tetapi dalam prakteknya, tiga kelompok yang sangat umum.
3. Numerical Assignment (Grouping)
Bila menggunakan tugas numerik, adalah penting bahwa masing-masing kelompok mewakili sesuatu yang para pemangku kepentingan dapat berhubungan dengan (misalnya kritis, standar, opsional), untuk klasifikasi handa.
4. Ranking
Setiap kebutuhan memiliki peringkat yang unik (dibandingkan dengan tugas numerik) tetapi tidak mungkin untuk melihat perbedaan relatif antara item peringkat (seperti dalam AHP atau tes 100 dolar).
5. Top-Ten Requirements
Dalam pendekatan kebutuhan top-sepuluh, para pemangku kepentingan memilih kebutuhan mereka sepuluh paling atas (dari satu set yang lebih besar) tanpa menetapkan perintah internal antara kebutuhan.
Langganan:
Postingan (Atom)