Laman

Selasa, 07 Juli 2015

Materi Kuliah Software Requirement Engineering UAS

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

Tidak ada komentar:

Posting Komentar