8.

1 REQUIREMENTS E NGINEERING

Merancang dan membangun perangkat lunak komputer itu menantang, kreatif, dan adil
menyenangkan. Bahkan, membangun perangkat lunak begitu menarik sehingga banyak
pengembang perangkat lunak ingin melompat tepat sebelum mereka memiliki pemahaman
yang jelas tentang apa yang dibutuhkan.
Mereka berpendapat bahwa hal-hal akan menjadi jelas ketika mereka membangun, bahwa
para pemangku kepentingan proyek akan dapat memahami kebutuhan hanya setelah
memeriksa iterasi awal perangkat lunak, bahwa hal-hal berubah begitu cepat sehingga setiap
upaya untuk memahami persyaratan secara rinci adalah buang-buang waktu, bahwa intinya
adalah memproduksi program kerja, dan bahwa semua yang lainnya adalah sekunder. Yang
membuat argumen ini menggoda adalah mereka mengandung unsur kebenaran. 1
 Tetapi setiap argumen gagal dan dapat menyebabkan kegagalan proyek perangkat lunak.

Spektrum yang luas dari tugas dan teknik yang mengarah pada pemahaman persyaratan
disebut persyaratan rekayasa. Dari perspektif proses perangkat lunak, rekayasa kebutuhan
adalah tindakan rekayasa perangkat lunak utama itu dimulai selama aktivitas komunikasi dan
berlanjut ke aktivitas pemodelan. Itu harus disesuaikan dengan kebutuhan proses, proyek,
produk, dan orang-orang yang melakukan pekerjaan.

Rekayasa persyaratan membangun jembatan untuk desain dan konstruksi. Tapi darimana
jembatan itu berasal? Orang bisa berpendapat bahwa itu dimulai di kaki pemangku
kepentingan proyek (mis., manajer, pelanggan, dan pengguna akhir), di mana kebutuhan
bisnis ditentukan, skenario pengguna dijelaskan, fungsi dan fitur digambarkan, dan kendala
proyek diidentifikasi. Orang lain mungkin menyarankan bahwa itu dimulai dengan definisi
sistem yang lebih luas, di mana perangkat lunak hanyalah satu komponen dari domain sistem
yang lebih besar. Namun terlepas dari titik awalnya, perjalanan melintasi jembatan membawa
Anda jauh di atas proyek, memungkinkan Anda untuk memeriksa konteks pekerjaan
perangkat lunak yang akan dilakukan; kebutuhan spesifik yang mendesain dan konstruksi
harus mengatasi; prioritas yang memandu urutan pekerjaan untuk diselesaikan; dan
informasi, fungsi, dan perilaku yang akan a dampak mendalam pada desain yang dihasilkan.

Selama dekade terakhir, ada banyak perubahan teknologi yang berdampak proses rekayasa
persyaratan [Wev11]. Komputasi di mana-mana memungkinkan teknologi komputer
diintegrasikan ke dalam banyak objek sehari-hari. Kapan ini objek terhubung dalam jaringan
mereka dapat memungkinkan pembuatan profil pengguna yang lebih lengkap, dengan
perhatian yang menyertainya untuk privasi dan keamanan. Ketersediaan aplikasi yang luas di
pasar elektronik akan mengarah untuk persyaratan pemangku kepentingan yang lebih
beragam. Stakeholder dapat menyesuaikan produk untuk memenuhi spesifikasi, persyaratan
yang ditargetkan yang hanya berlaku untuk yang kecil himpunan bagian dari semua pengguna
akhir. Seiring siklus pengembangan produk yang lebih pendek, ada tekanan untuk
merampingkan rekayasa persyaratan sehingga produk datang ke pasar lebih cepat. Tapi
masalah mendasar tetap sama, semakin tepat waktu, input pemangku kepentingan yang
akurat dan stabil. Rekayasa persyaratan mencakup tujuh tugas berbeda: permulaan, elisitasi,
elaborasi, negosiasi, spesifikasi, validasi, dan manajemen. ini
Penting untuk dicatat bahwa beberapa tugas ini terjadi secara paralel dan semuanya
disesuaikan untuk kebutuhan proyek.

Awal (Inception )
Bagaimana proyek perangkat lunak dimulai? Apakah ada satu kejadian saja
menjadi katalis untuk sistem atau produk berbasis komputer baru, atau melakukan
perlu berevolusi dari waktu ke waktu? Tidak ada jawaban pasti untuk pertanyaan-pertanyaan
ini. Di dalam beberapa kasus, hanya percakapan biasa yang diperlukan untuk mengendapkan
jurusan upaya rekayasa perangkat lunak. Tetapi secara umum, sebagian besar proyek dimulai
ketika sebuah bisnis kebutuhan diidentifikasi atau pasar atau layanan baru yang potensial
ditemukan. Stakeholder dari komunitas bisnis (mis., Manajer bisnis, orang pemasaran,
manajer produk) mendefinisikan kasus bisnis untuk ide tersebut, cobalah untuk
mengidentifikasi luasnya dan kedalaman pasar, melakukan analisis kelayakan kasar, dan
mengidentifikasi suatu pekerjaan deskripsi ruang lingkup proyek. Semua informasi ini dapat
berubah, tetapi cukup untuk mempercepat diskusi dengan organisasi rekayasa perangkat
lunak. 2
 Pada awal proyek, 3
 Anda membangun pemahaman dasar tentang masalah, orang-orang yang menginginkan
solusi, sifat dari solusi yang diinginkan, dan
efektivitas komunikasi awal dan kolaborasi antara
pemangku kepentingan lain dan tim perangkat lunak.

Pendatangan.( Elicitation) Tampaknya cukup sederhana — tanyakan pelanggan, pengguna,

dan lain apa tujuan untuk sistem atau produk, apa yang harus dicapai, bagaimana sistem atau
produk cocok dengan kebutuhan bisnis, dan akhirnya, bagaimana sistem atau produk
digunakan sehari-hari. Tapi itu tidak sederhana ini sangat sulit.
Bagian penting dari elisitasi adalah untuk menetapkan tujuan bisnis [Cle10]. Pekerjaan Anda
adalah untuk melibatkan pemangku kepentingan dan mendorong mereka untuk berbagi tujuan
dengan jujur. Setelah tujuan telah ditangkap, mekanisme prioritas harus ditetapkan, dan dasar
pemikiran desain untuk arsitektur potensial (yang memenuhi tujuan pemangku kepentingan)
dapat dibuat.

Christel dan Kang [Cri92] mengidentifikasi sejumlah masalah yang dihadapi

sebagai elisitasi terjadi. Masalah ruang lingkup terjadi ketika batas sistem
cacat atau pelanggan dan pengguna menentukan rincian teknis yang tidak perlu itu
dapat membingungkan, daripada memperjelas, tujuan sistem secara keseluruhan. Masalah
pemahaman ditemui ketika pelanggan dan pengguna tidak sepenuhnya yakin apa yang
dibutuhkan, memiliki pemahaman yang buruk tentang kemampuan dan keterbatasan
lingkungan komputasi mereka, tidak memiliki pemahaman penuh tentang masalah tersebut
domain, mengalami kesulitan dalam berkomunikasi kebutuhan, menghilangkan informasi
yang diyakini menjadi "jelas," tentukan persyaratan yang bertentangan dengan kebutuhan
pelanggan dan pengguna lain, atau tentukan persyaratan yang ambigu atau tidak dapat diuji.
Masalah volatilitas terjadi ketika persyaratan berubah seiring waktu. Untuk membantu
mengatasi masalah ini, Anda harus mendekati kegiatan pengumpulan-persyaratan secara
terorganisir.
 Elaborasi.( Elaboration.) Informasi yang diperoleh dari pelanggan selama awal dan
elisitasi diperluas dan diperbaiki selama elaborasi. Tugas ini berfokus pada pengembangan
model persyaratan yang disempurnakan (Bab 9 hingga 11) yang mengidentifikasi
berbagai aspek fungsi perangkat lunak, perilaku, dan informasi.
Elaborasi didorong oleh pembuatan dan penyempurnaan skenario pengguna itu
menggambarkan bagaimana pengguna akhir (dan aktor lain) akan berinteraksi dengan sistem.
Setiap Skenario pengguna diuraikan untuk mengekstraksi kelas analisis — entitas domain
bisnis yang terlihat oleh pengguna akhir. Atribut masing-masing kelas analisis didefinisikan,
dan layanan 4  yang diperlukan oleh setiap kelas diidentifikasi. Hubungan dan kolaborasi
antara kelas diidentifikasi, dan berbagai tambahan diagram diproduksi.

Perundingan.( Negotiation)Bukan hal yang aneh bagi pelanggan dan pengguna untuk
meminta lebih dari yang bisa dicapai, mengingat sumber daya bisnis yang terbatas. Itu juga
relatif umum untuk pelanggan atau pengguna yang berbeda untuk mengusulkan persyaratan
yang bertentangan, dengan alasan itu versi mereka "penting untuk kebutuhan khusus kita."
Anda harus merekonsiliasi konflik ini melalui proses negosiasi. Pelanggan, pengguna,
dan pemangku kepentingan lainnya diminta untuk menentukan peringkat persyaratan dan
kemudian mendiskusikan konflik dalam prioritas. Menggunakan pendekatan berulang yang
memprioritaskan persyaratan, menilai biaya dan risikonya, dan menangani konflik internal,
persyaratan dihilangkan, digabungkan, dan / atau dimodifikasi sehingga masing-masing pihak
mencapai beberapa ukuran kepuasan.

Spesifikasi.( Specification.) Dalam konteks sistem berbasis komputer (dan perangkat

lunak), istilah spesifikasi berarti hal yang berbeda bagi orang yang berbeda. Sebuah kaleng
spesifikasi menjadi dokumen tertulis, satu set model grafis, model matematika formal,
kumpulan skenario penggunaan, prototipe, atau kombinasi dari semuanya.
Beberapa menyarankan bahwa "template standar" [Som97] harus dikembangkan dan
digunakan untuk spesifikasi, dengan alasan bahwa ini mengarah pada persyaratan yang
disajikan secara konsisten dan karenanya lebih dapat dipahami. Namun demikian kadang-
kadang diperlukan untuk tetap fleksibel ketika spesifikasi dikembangkan.
Untuk sistem besar, dokumen tertulis, menggabungkan deskripsi bahasa alami dan model
grafis mungkin merupakan pendekatan terbaik. Namun, skenario penggunaan mungkin
semua yang diperlukan untuk produk atau sistem yang lebih kecil yang berada di dalamnya
lingkungan teknis yang dipahami dengan baik.

Validasi.( Validation.) Produk kerja yang dihasilkan sebagai konsekuensi dari

persyaratan rekayasa dinilai untuk kualitas selama langkah validasi. Validasi persyaratan
memeriksa spesifikasi 5 untuk memastikan bahwa semua persyaratan perangkat lunak miliki
dinyatakan dengan jelas; yang dimiliki oleh ketidakkonsistenan, kelalaian, dan kesalahan
telah terdeteksi dan diperbaiki; dan bahwa produk kerja sesuai dengan standar yang
ditetapkan untuk proses, proyek, dan produk.
Mekanisme validasi persyaratan utama adalah tinjauan teknis
(Bab 20). Tim peninjau yang memvalidasi persyaratan termasuk perangkat lunak
insinyur, pelanggan, pengguna, dan pemangku kepentingan lain yang memeriksa spesifikasi -
kation mencari kesalahan dalam konten atau interpretasi, area tempat klarifikasi
mungkin diperlukan, informasi yang hilang, ketidakkonsistenan (masalah utama ketika
produk atau sistem besar direkayasa), persyaratan yang membingungkan, atau persyaratan
yang tidak realistis (tidak dapat dicapai).
Untuk menggambarkan beberapa masalah yang terjadi selama validasi persyaratan,
pertimbangkan dua persyaratan yang tampaknya tidak berbahaya:
 • Perangkat lunak harus ramah pengguna.
• Probabilitas intrusi database sukses yang tidak sah seharusnya
kurang dari 0,0001.

Persyaratan pertama terlalu samar bagi pengembang untuk menguji atau menilai. Apa
sebenarnya yang dimaksud dengan "ramah pengguna"? Untuk memvalidasinya, harus
dikuantifikasi atau dikualifikasikan dalam beberapa cara.
Persyaratan kedua memiliki elemen kuantitatif ("kurang dari 0,0001"), tetapi
pengujian intrusi akan sulit dan memakan waktu. Apakah tingkat keamanan ini bahkan
dijamin untuk aplikasi? Dapatkah persyaratan pelengkap lainnya yang terkait dengan
keamanan (mis., Perlindungan kata sandi, jabat tangan khusus) diganti persyaratan kuantitatif
dicatat?
Glinz [Gli09] menulis bahwa persyaratan kualitas perlu diwakili dalam a
cara yang memberikan nilai optimal. Ini berarti menilai risiko (Bab 35) dari memberikan
sistem yang gagal memenuhi persyaratan kualitas pemangku kepentingan dan berusaha
mengurangi risiko ini dengan biaya minimum. Semakin kritis kualitasnya persyaratannya
adalah, semakin besar kebutuhan untuk menyatakannya secara kuantitatif. Kurang kritis
persyaratan kualitas dapat dinyatakan secara umum. Dalam beberapa kasus, seorang jenderal
persyaratan kualitas dapat diverifikasi menggunakan teknik kualitatif (mis., survei pengguna
atau daftar periksa). Dalam situasi lain, persyaratan kualitas dapat diverifikasi menggunakan
kombinasi penilaian kualitatif dan kuantitatif.

Manajemen persyaratan.( Requirements management) Persyaratan untuk perubahan

sistem berbasis komputer, dan keinginan untuk mengubah persyaratan tetap ada sepanjang
umur sistem. Manajemen persyaratan adalah serangkaian kegiatan yang membantu tim
proyek mengidentifikasi, mengontrol, dan melacak persyaratan dan perubahan persyaratan
setiap saat sebagai hasil proyek. 6 Banyak dari kegiatan ini identik dengan konfigurasi
perangkat lunak teknik manajemen (SCM) yang dibahas dalam Bab 29.
8.2 MENDIRIKAN GROUNDWORK
Dalam pengaturan yang ideal, para pemangku kepentingan dan insinyur perangkat
lunak bekerja bersama dalam tim yang sama. 8  Dalam kasus seperti itu, rekayasa persyaratan
hanyalah masalah melakukan percakapan yang bermakna dengan kolega yang merupakan
anggota terkenal tim. Tetapi kenyataannya seringkali sangat berbeda.
Pelanggan atau pengguna akhir mungkin berlokasi di kota atau negara yang berbeda,
mungkin hanya memiliki gagasan yang kabur tentang apa yang diperlukan, mungkin
memiliki pendapat yang saling bertentangan tentang sistem yang akan dibangun, mungkin
memiliki pengetahuan teknis yang terbatas, dan mungkin memiliki waktu yang terbatas untuk
berinteraksi dengan insinyur persyaratan. Tidak satu pun dari hal-hal ini diinginkan, tetapi
semua cukup umum, dan Anda sering dipaksa untuk bekerja di dalamnya kendala yang
dipaksakan oleh situasi ini.
Di bagian selanjutnya, kami membahas langkah-langkah yang diperlukan untuk
membangun landasan untuk pemahaman tentang persyaratan perangkat lunak untuk
mendapatkan proyek dimulai dengan cara yang akan terus bergerak maju menuju solusi yang
sukses.

8.2.1 Mengidentifikasi Stakeholder

Sommerville dan Sawyer [Som97] mendefinisikan pemangku kepentingan sebagai
“siapa saja yang diuntungkan secara langsung atau tidak langsung dari sistem yang sedang
dikembangkan. " Kita punya sudah mengidentifikasi tersangka yang biasa: manajer operasi
bisnis, produk manajer, orang pemasaran, pelanggan internal dan eksternal, pengguna akhir,
konsultan, insinyur produk, insinyur perangkat lunak, insinyur dukungan dan pemeliharaan,
dan lainnya. Setiap pemangku kepentingan memiliki pandangan yang berbeda tentang sistem,
mencapai manfaat yang berbeda ketika sistem berhasil dikembangkan, dan terbuka untuk
risiko yang berbeda jika upaya pengembangan gagal.
Pada awal, Anda harus membuat daftar orang yang akan berkontribusi sebagai input
persyaratan muncul (Bagian 8.3). Daftar awal akan tumbuh sebagai pemangku kepentingan
dihubungi karena setiap pemangku kepentingan akan ditanya: "Menurut Anda siapa lagi
Saya harus berbicara dengan? "

8.2.2 Mengenali Berbagai Sudut Pandang

Karena ada banyak pemangku kepentingan yang berbeda, persyaratan sistem akan
dieksplorasi dari berbagai sudut pandang. Misalnya pemasaran
grup tertarik pada fungsi dan fitur yang akan menggairahkan pasar potensial, membuat sistem
baru mudah dijual. Manajer bisnis tertarik pada aset fitur yang dapat dibangun sesuai
anggaran dan yang akan siap untuk ditentukan jendela pasar. Pengguna akhir mungkin
menginginkan fitur yang akrab bagi mereka dan itu mudah dipelajari dan digunakan. Insinyur
perangkat lunak mungkin memperhatikan fungsi yang tidak terlihat oleh pemangku
kepentingan non-teknis tetapi memungkinkan infrastruktur yang mendukung lebih banyak
fungsi dan fitur yang dapat dipasarkan. Insinyur dukungan mungkin fokus pada pemeliharaan
perangkat lunak.
Masing-masing daerah pemilihan ini (dan lainnya) akan menyumbangkan informasi
kepada persyaratan proses rekayasa. Seperti informasi dari berbagai sudut pandang
dikumpulkan, persyaratan yang muncul mungkin tidak konsisten atau dapat bertentangan
dengan satu lain. Anda harus mengategorikan semua informasi pemangku kepentingan
(termasuk persyaratan yang tidak konsisten dan bertentangan) dengan cara yang akan
memungkinkan para pembuat keputusan untuk pilih satu set persyaratan yang konsisten
secara internal untuk sistem.
 Ada beberapa hal yang dapat mempersulit untuk mendapatkan persyaratan untuk
perangkat lunak yang memuaskan penggunanya: tujuan proyek tidak jelas, prioritas
pemangku kepentingan berbeda, orang memiliki asumsi yang tak terucapkan, pemangku
kepentingan menafsirkan makna berbeda, dan persyaratan dinyatakan dengan cara yang
membuat mereka sulit untuk memverifikasi [Ale11]. Tujuan dari rekayasa persyaratan yang
efektif adalah untuk menghilangkan atau setidaknya kurangi masalah ini.

8.2.3 Bekerja menuju Kolaborasi

Jika lima pemangku kepentingan terlibat dalam proyek perangkat lunak, Anda
mungkin memiliki lima (atau lebih) pendapat berbeda tentang seperangkat persyaratan yang
tepat. Sepanjang bab-bab sebelumnya, kami telah mencatat bahwa pelanggan (dan pemangku
kepentingan lainnya) harus berkolaborasi di antara mereka sendiri (menghindari pertempuran
rumput kecil) dan dengan praktisi rekayasa perangkat lunak jika sistem yang berhasil adalah
hasil. Tetapi bagaimana kolaborasi ini dapat dicapai?
Tugas seorang insinyur persyaratan adalah mengidentifikasi bidang-bidang kesamaan
(mis., persyaratan yang disetujui oleh semua pemangku kepentingan) dan bidang konflik atau
ketidakkonsistenan (yaitu, persyaratan yang diinginkan oleh satu pemangku kepentingan
tetapi berkonflik dengan kebutuhan pemangku kepentingan lain). Tentu saja, kategori
terakhirlah yang hadir sebuah tantangan.

Kolaborasi tidak selalu berarti bahwa persyaratan ditentukan oleh

komite. Dalam banyak kasus, para pemangku kepentingan berkolaborasi dengan memberikan
pandangan mereka tentang persyaratan, tetapi "juara proyek" yang kuat (mis., manajer bisnis
atau teknolog senior) dapat membuat keputusan akhir tentang persyaratan yang dibuat luka.

8.2.4 Mengajukan Pertanyaan Pertama Pertanyaan

yang diajukan pada awal proyek harus “bebas konteks” [Gau89]. Rangkaian
pertanyaan bebas konteks pertama berfokus pada pelanggan dan pemangku kepentingan
lainnya, keseluruhan sasaran proyek dan manfaatnya. Misalnya, Anda mungkin bertanya:
• Siapa di belakang permintaan untuk pekerjaan ini?
• Siapa yang akan menggunakan solusi?
• Apa manfaat ekonomi dari solusi yang berhasil?
• Apakah ada sumber lain untuk solusi yang Anda butuhkan?

Pertanyaan-pertanyaan ini membantu mengidentifikasi semua pemangku kepentingan yang

akan tertarik pada perangkat lunak yang akan dibangun. Selain itu, pertanyaan
mengidentifikasi manfaat yang terukur implementasi yang sukses dan kemungkinan alternatif
untuk perangkat lunak khusus pengembangan.
Set pertanyaan berikutnya memungkinkan Anda untuk mendapatkan pemahaman yang lebih
baik tentang masalah dan memungkinkan pelanggan untuk menyuarakan persepsi tentang
solusi:
• Bagaimana Anda mengkarakterisasi output "baik" yang akan dihasilkan oleh a
solusi yang berhasil?
• Masalah apa yang akan diatasi oleh solusi ini?
• Dapatkah Anda menunjukkan kepada saya (atau menggambarkan) lingkungan bisnis
di mana solusi yang akan digunakan?
• Apakah masalah atau kendala kinerja khusus akan memengaruhi cara solusi
didekati?
 Set pertanyaan terakhir berfokus pada keefektifan komunikasi aktivitas itu sendiri.
Gause dan Weinberg [Gau89] menyebut ini "pertanyaan meta" dan mengusulkan daftar
berikut (disingkat):
• Apakah Anda orang yang tepat untuk menjawab pertanyaan-pertanyaan ini? Apakah
jawaban Anda "Resmi"?
• Apakah pertanyaan saya relevan dengan masalah yang Anda miliki?
• Apakah saya terlalu banyak bertanya?
• Dapatkah orang lain memberikan informasi tambahan?
• Haruskah saya menanyakan hal lain kepada Anda?

Pertanyaan-pertanyaan ini (dan lainnya) akan membantu untuk “memecahkan

kebekuan” dan memulai komunikasi yang penting untuk keberhasilan pemunculan. Tapi
pertanyaan-dan-jawaban format rapat bukanlah pendekatan yang sangat berhasil. Di
Bahkan, sesi tanya jawab harus digunakan hanya untuk pertemuan pertama dan kemudian
diganti dengan format elisitasi persyaratan yang menggabungkan elemen masalah.
pemecahan, negosiasi, dan spesifikasi. Pendekatan jenis ini disajikan dalam
Bagian 8.3.

8.2.5 Persyaratan Nonfungsional

Persyaratan nonfungsional (NFR) dapat digambarkan sebagai atribut kualitas, aatribut
kinerja, atribut keamanan, atau kendala umum pada suatu sistem.
Ini seringkali tidak mudah untuk diartikulasikan oleh para pemangku kepentingan. Chung
[Chu09] menyarankan bahwa ada penekanan miring pada fungsi perangkat lunak, namun
perangkat lunak mungkin tidak berguna atau tidak dapat digunakan tanpa karakteristik non-
fungsional yang diperlukan.
Dalam Bagian 8.3.2, kita membahas teknik yang disebut penyebaran fungsi kualitas
(QFD). Penerapan fungsi kualitas berupaya menerjemahkan kebutuhan atau sasaran
pelanggan yang tak terucapkan ke dalam persyaratan sistem. Persyaratan nonfungsional
seringkali terdaftar secara terpisah dalam spesifikasi persyaratan perangkat lunak.
Sebagai tambahan untuk QFD, dimungkinkan untuk mendefinisikan pendekatan dua fase
[Hne11] yang dapat membantu tim perangkat lunak dan pemangku kepentingan lainnya
dalam mengidentifikasi persyaratan yang tidak berfungsi. Selama fase pertama, seperangkat
pedoman rekayasa perangkat lunak dibuat untuk sistem yang akan dibangun. Ini termasuk
pedoman terbaik berlatih, tetapi juga membahas gaya arsitektur (Bab 13) dan penggunaan
desain pola (Bab 16). Daftar NFR (mis., Persyaratan yang membahas kegunaan,
testability, keamanan atau rawatan) kemudian dikembangkan. Tabel sederhana berisi daftar
NFR sebagai label kolom dan pedoman rekayasa perangkat lunak sebagai label baris. Matriks
hubungan membandingkan setiap pedoman dengan pedoman lainnya, membantu tim untuk
menilai apakah masing-masing pasangan pedoman saling melengkapi, tumpang tindih, saling
bertentangan, atau
independen.
Pada fase kedua, tim memprioritaskan setiap persyaratan nonfungsional oleh
membuat seperangkat persyaratan nonfungsional yang homogen menggunakan serangkaian
keputusan aturan [Hne11] yang menetapkan pedoman mana yang harus diterapkan dan mana
yang harus ditolak.
8.2.6 Keterlacakan
Ketertelusuran adalah istilah rekayasa perangkat lunak yang merujuk pada tautan
yang terdokumentasi antara produk kerja rekayasa perangkat lunak (mis., Persyaratan dan
kasus uji). SEBUAH matriks keterlacakan memungkinkan insinyur persyaratan untuk
mewakili hubungan antara persyaratan dan produk kerja rekayasa perangkat lunak lainnya.
Deretan matriks keterlacakan diberi label menggunakan nama dan kolom persyaratan
dilabeli dengan nama produk pekerjaan rekayasa perangkat lunak (mis., desain elemen atau
kasus uji). Sel matriks ditandai untuk menunjukkan keberadaan tautan antara keduanya.
Matriks ketertelusuran dapat mendukung berbagai pengembangan teknik
kegiatan. Mereka dapat memberikan kontinuitas bagi pengembang saat proyek bergerak
satu fase proyek ke fase lainnya, terlepas dari model proses yang digunakan. Matriks
keterlacakan sering dapat digunakan untuk memastikan produk pekerjaan teknik miliki
memperhitungkan semua persyaratan.
Dengan bertambahnya jumlah persyaratan dan jumlah produk kerja, semakin sulit untuk
menjaga matriks keterlacakan. Meskipun demikian, penting untuk menciptakan beberapa cara
untuk melacak dampak dan evolusi
dari persyaratan produk [Got11].

8.3 PERSYARATAN MEMILIH

Elisitasi persyaratan (juga disebut pengumpulan persyaratan) menggabungkan elemen
penyelesaian masalah, elaborasi, negosiasi, dan spesifikasi. Untuk mendorong pendekatan
kolaboratif, berorientasi pada tim untuk pengumpulan persyaratan, para pemangku
kepentingan bekerja bersama untuk mengidentifikasi masalah, mengusulkan elemen-elemen
dari solusi, negosiasikan pendekatan yang berbeda, dan tentukan satu set awal persyaratan
solusi [Zah90].
8.3.1 Pengumpulan Persyaratan Kolaboratif
Banyak pendekatan berbeda untuk pengumpulan persyaratan kolaboratif telah
dilakukan diusulkan. Masing-masing memanfaatkan skenario yang sedikit berbeda, tetapi
semuanya menerapkan beberapa variasi pada pedoman dasar berikut:
• Rapat (baik nyata atau virtual) dilakukan dan dihadiri oleh para insinyur perangkat
lunak dan pemangku kepentingan lainnya.
• Aturan untuk persiapan dan partisipasi ditetapkan.
• Agenda disarankan yang cukup formal untuk mencakup semua yang penting
poin tetapi cukup informal untuk mendorong arus bebas ide.
• “Fasilitator” (dapat berupa pelanggan, pengembang, atau orang luar) mengendalikan
pertemuan.
• “mekanisme definisi” (bisa berupa lembar kerja, bagan fl ip, atau stiker dinding atau
papan buletin elektronik, ruang obrolan, atau forum virtual) digunakan.

Tujuannya adalah untuk mengidentifikasi masalah, mengusulkan elemen-elemen

solusi, bernegosiasi pendekatan yang berbeda, dan tentukan satu set persyaratan solusi
pendahuluan.
"Permintaan produk" satu atau dua halaman dihasilkan selama awal (Bagian 8.2).
Tempat, waktu, dan tanggal pertemuan dipilih; seorang fasilitator dipilih; dan peserta
dari tim perangkat lunak dan organisasi pemangku kepentingan lainnya diundang untuk
berpartisipasi.
Permintaan produk didistribusikan kepada semua peserta sebelum tanggal pertemuan.
Sebagai contoh, 10 pertimbangkan kutipan dari permintaan produk yang ditulis oleh a orang
pemasaran yang terlibat dalam proyek SafeHome. Orang ini menulis narasi berikut tentang
fungsi keamanan rumah yang menjadi bagian dari SafeHome: Penelitian kami menunjukkan
bahwa pasar untuk sistem manajemen rumah sedang berkembang tingkat 40 persen per tahun.
Fungsi SafeHome pertama yang kami bawa ke pasar harus menjadi fungsi keamanan rumah.
Kebanyakan orang terbiasa dengan "sistem alarm" jadi ini akan mudah dijual.
Fungsi keamanan rumah akan melindungi dan / atau mengenali beragam
"situasi" yang tidak diinginkan seperti masuknya ilegal, kebakaran, floding, kadar karbon
monoksida, dan lain-lain. Ini akan menggunakan sensor nirkabel kami untuk mendeteksi
setiap situasi, dapat diprogram
oleh pemilik rumah, dan secara otomatis akan menelepon agen pemantau ketika a
situasi terdeteksi.

Pada kenyataannya, orang lain akan berkontribusi pada narasi ini selama pertemuan
pengumpulan-persyaratan dan informasi yang jauh lebih banyak tersedia. Tetapi bahkan
dengan informasi tambahan, ambiguitas hadir, kelalaian kemungkinan ada, dan kesalahan
mungkin terjadi. Untuk saat ini, "fungsional" sebelumnya deskripsi ”akan mencukupi.
Saat meninjau permintaan produk pada hari-hari sebelum pertemuan, setiap peserta
diminta untuk membuat daftar objek yang merupakan bagian dari lingkungan yang
mengelilingi sistem, objek lain yang akan diproduksi oleh sistem, dan objek yang digunakan
oleh sistem untuk melakukan fungsinya. Selain itu, masing-masing peserta diminta untuk
membuat daftar layanan lain (proses atau fungsi) itu memanipulasi atau berinteraksi dengan
objek. Akhirnya, daftar kendala (mis., Biaya, ukuran, aturan bisnis) dan kriteria kinerja (mis.,
kecepatan, akurasi) juga dikembangkan. Para peserta diberitahu bahwa daftar ini tidak
diharapkan lengkap tetapi diharapkan untuk mencerminkan persepsi setiap orang tentang
sistem.
Objek yang dijelaskan untuk SafeHome mungkin termasuk panel kontrol, detektor
asap, sensor jendela dan pintu, detektor gerakan, alarm, peristiwa (sensor telah diaktifkan),
layar, PC, nomor telepon, panggilan telepon, dan seterusnya. Daftar layanan mungkin
termasuk mengkonfigurasi sistem, mengatur alarm, pemantauan sensor, panggilan telepon,
pemrograman kontrol panel, dan membaca tampilan (perhatikan bahwa layanan bekerja pada
objek). Dalam yang serupa fashion, setiap peserta akan mengembangkan daftar kendala (mis.,
sistem harus mengenali ketika sensor tidak beroperasi, harus ramah pengguna, harus
antarmuka langsung ke saluran telepon standar) dan kriteria kinerja (mis., acara sensor
harus diakui dalam satu detik, dan skema prioritas acara harus diimplementasikan).

Daftar benda dapat disematkan ke dinding ruangan menggunakan lembaran besar

kertas, menempel di dinding menggunakan lembaran yang didukung perekat, atau ditulis di
dinding naik. Atau, daftar tersebut mungkin telah diposting di forum grup, di situs web
internal, atau ditempatkan di lingkungan jejaring sosial untuk ditinjau sebelum pertemuan.
Idealnya, setiap entri yang terdaftar harus mampu dimanipulasi secara terpisah sehingga
daftar dapat digabungkan, entri dapat dihapus, dan tambahan dapat di buat. Pada tahap ini,
kritik dan debat dilarang keras.
Setelah masing-masing daftar disajikan dalam satu bidang topik, grup membuat daftar
gabungan dengan menghilangkan entri yang berlebihan, menambahkan ide-ide baru yang
muncul selama diskusi, tetapi tidak menghapus apa pun. Setelah Anda membuat daftar
gabungan untuk semua bidang topik, diskusi — dikoordinasikan oleh fasilitator — pun
terjadi. Daftar gabungan dipersingkat, diperpanjang, atau disusun ulang untuk mencerminkan
produk dengan benar atau sistem yang akan dikembangkan. Tujuannya adalah untuk
mengembangkan daftar objek konsensus, layanan, kendala, dan kinerja untuk sistem yang
akan dibangun.
Dalam banyak kasus, objek atau layanan yang dijelaskan dalam daftar akan
memerlukan lebih lanjut penjelasan. Untuk mencapai hal ini, para pemangku kepentingan
mengembangkan spesifikasi-mini untuk entri pada daftar atau dengan membuat use case
(Bagian 8.4) yang melibatkan objek atau layanan. Misalnya, spesifikasi mini untuk Panel
Kontrol objek SafeHome mungkin:
Panel kontrol adalah unit yang dipasang di dinding yang berukuran sekitar 230 x 130 mm.
Panel kontrol memiliki konektivitas nirkabel ke sensor dan PC. Interaksi pengguna terjadi
melalui keypad yang berisi 12 tombol. Layar warna OLED 75 x 75 mm menyediakan
umpan balik pengguna. Perangkat lunak menyediakan prompt interaktif, gema, dan fungsi
serupa.
Mini-spec disajikan untuk semua pemangku kepentingan untuk diskusi. Tambahan,
penghapusan, dan penjelasan lebih lanjut dibuat. Dalam beberapa kasus, perkembangan
spesifikasi mini akan mengungkap objek baru, layanan, kendala, atau persyaratan kinerja
yang akan ditambahkan ke daftar asli. Selama semua diskusi,
tim dapat mengajukan masalah yang tidak dapat diselesaikan selama pertemuan. Sebuah
masalah daftar dipertahankan sehingga ide-ide ini akan ditindaklanjuti nanti.

Banyak kekhawatiran pemangku kepentingan (mis., Akurasi, aksesibilitas data, keamanan)

adalah dasar untuk persyaratan sistem nonfungsional (Bagian 8.2). Ketika para pemangku
kepentingan menyatakan keprihatinan ini, para insinyur perangkat lunak harus
mempertimbangkan mereka dalam konteks sistem yang akan dibangun. Di antara pertanyaan
yang harus dijawab [Lag10] adalah sebagai berikut:
• Bisakah kita membangun sistem?
• Apakah proses pengembangan ini memungkinkan kita untuk mengalahkan pesaing
kita ke pasar?
• Apakah ada sumber daya yang memadai untuk membangun dan memelihara sistem
yang diusulkan?
 • Apakah kinerja sistem akan memenuhi kebutuhan pelanggan kami?
Jawaban untuk ini dan pertanyaan lain akan berkembang seiring waktu.

8.3.2 Penerapan Fungsi Kualitas

Penyebaran fungsi kualitas (QFD) adalah teknik manajemen kualitas itu
menerjemahkan kebutuhan pelanggan menjadi persyaratan teknis untuk perangkat lunak.
QFD "berkonsentrasi pada memaksimalkan kepuasan pelanggan dari proses rekayasa
perangkat lunak" [Zul92]. Untuk mencapai hal ini, QFD menekankan pada pemahaman
apa yang berharga bagi pelanggan dan kemudian menyebarkan nilai-nilai ini di seluruh
proses rekayasa.
Dalam konteks QFD, persyaratan normal mengidentifikasi tujuan dan tujuan yang
dinyatakan untuk suatu produk atau sistem selama pertemuan dengan pelanggan. Jika
persyaratan ini ada, pelanggan puas. Persyaratan yang diharapkan tersirat pada produk atau
sistem dan mungkin sangat mendasar pelanggan tidak secara eksplisit menyatakannya.
Ketidakhadiran mereka akan menjadi penyebab ketidakpuasan yang signifikan. Persyaratan
yang menarik melampaui harapan pelanggan dan terbukti sangat memuaskan saat ada.
Meskipun konsep QFD dapat diterapkan di seluruh proses perangkat lunak
[Par96a]; teknik QFD spesifik berlaku untuk persyaratan yang diminta aktivitas. QFD
menggunakan wawancara dan observasi pelanggan, survei, dan pemeriksaan data historis
(mis., laporan masalah) sebagai data mentah untuk aktivitas pengumpulan persyaratan. Data-
data ini kemudian diterjemahkan ke dalam tabel persyaratan — disebut tabel suara pelanggan
— yang ditinjau oleh pelanggan dan pemangku kepentingan lainnya.
Berbagai diagram, matriks, dan metode evaluasi kemudian digunakan untuk
mengekstraksi persyaratan yang diharapkan dan berupaya mendapatkan persyaratan yang
menarik [Aka04].

8.3.3 Skenario Penggunaan

Ketika persyaratan dikumpulkan, visi keseluruhan fungsi dan fitur sistem mulai
terwujud. Namun, sulit untuk pindah ke perangkat lunak yang lebih teknis kegiatan rekayasa
hingga Anda memahami bagaimana fungsi dan fitur ini akan digunakan oleh berbagai kelas
pengguna akhir. Untuk mencapai ini, pengembang dan pengguna dapat membuat seperangkat
skenario yang mengidentifikasi utas penggunaan untuk sistem yang akan dibangun. Skenario,
sering disebut use case [Jac92], memberikan a deskripsi tentang bagaimana sistem akan
digunakan. Kasus penggunaan dibahas secara lebih luas detail dalam Bagian 8.4.