1. Requirements Engineering
D4 Manajemen Informatika 2023D
Kelompok 5
MK: Rekayasa Perangkat Lunak
NIM NAMA
23091397131 Ainul Yaqin Hidayatul Wachid
23091397135 Akbar Jarullah Fawwas
23091397136 Vicky Wijaya Nur waluddin
2. Objectives
• Memahami konsep kebutuhan pengguna dan sistem serta mengapa
kebutuhan ini harus ditulis dengan cara yang berbeda.
• Memahami perbedaan antara kebutuhan fungsional dan non-
fungsional perangkat lunak.
• Memahami aktivitas utama rekayasa kebutuhan seperti
pengumpulan, analisis, dan validasi, beserta hubungan antara
aktivitas-aktivitas tersebut.
• Memahami mengapa manajemen kebutuhan diperlukan dan
bagaimana hal ini mendukung aktivitas rekayasa kebutuhan lainnya.
4. Kebutuhan untuk sebuah sistem adalah deskripsi dari layanan yang
seharusnya disediakan oleh sistem dan batasan-batasan atas operasinya.
Kebutuhan-kebutuhan ini mencerminkan kebutuhan pelanggan terhadap
sebuah sistem yang melayani tujuan tertentu seperti mengendalikan
perangkat, melakukan pemesanan, atau mencari informasi. Jenis kebutuhan
ini dibagi menjadi dua yaitu:
• Kebutuhan pengguna (User Requirment) adalah pernyataan, dalam
bahasa alami ditambah diagram, tentang layanan apa yang diharapkan
sistem sediakan kepada pengguna sistem dan batasan-batasan di bawah
mana itu harus beroperasi.
• Kebutuhan sistem (system requirment) adalah pernyataan, dalam bahasa
alami ditambah diagram, tentang layanan apa yang diharapkan sistem
sediakan kepada pengguna sistem dan batasan-batasan di bawah mana
itu harus beroperasi.
5.
6. Functional And Non-Functional
Requirement
1.1 Functional Requirement
• Kebutuhan fungsional ini adalah pernyataan mengenai layanan
atau fungsi yang harus disediakan oleh sistem seperti,
bagaimana sistem harus bereaksi terhadap input tertentu, dan
bagaimana sistem harus berperilaku dalam situasi tertentu.
Dalam beberapa kasus, kebutuhan fungsional juga mungkin
secara eksplisit menyatakan apa yang tidak boleh dilakukan
oleh sistem.
• Kebutuhan fungsional suatu sistem mendeskripsikan apa yang
harus dilakukan sistem secara rinci. Hal Ini tergantung pada
jenis perangkat lunak yang dikembangkan.
7. Berikut adalah contoh kebutuhan fungsional untuk sistem Mentcare,
yang digunakan untuk menjaga informasi tentang pasien yang
menerima perawatan untuk masalah kesehatan mental:
1.Pengguna harus dapat mencari daftar janji temu untuk semua
klinik.
2.Sistem harus menghasilkan setiap hari, untuk setiap klinik, daftar
pasien yang diharapkan hadir untuk janji temu hari itu.
3.Setiap anggota staf yang menggunakan sistem harus diidentifikasi
secara unik oleh nomor pegawai delapan digitnya.
• Kebutuhan pengguna ini menentukan fungsionalitas spesifik yang
harus dimasukkan dalam sistem yang dapat ditulis dengan tingkat
kedetailan yang berbeda.
8. • Dalam kasus seperti itu, fokus harus pada developer kebutuhan
informasi yang menentukan berbagai informasi yang diperlukan,
bagaimana cara pengirimannya, dan diorganisasikan. Menyebabkan
ketidakpastian dalam spesifikasi kebutuhan.
• Ketidakpastian dalam spesifikasi kebutuhan dapat menyebabkan
perselisihan antara pelanggan dan developer perangkat lunak akibat
salah tafsirnya kebutuhan yang ambigu oleh developer.
• Idealnya, spesifikasi kebutuhan fungsional sistem harus lengkap dan
konsisten.
• Namun, konsistensi dan kelengkapan kebutuhan hanya dapat dicapai
untuk sistem perangkat lunak yang sangat kecil dalam praktiknya.
• Salah satu alasan adalah karena mudah terjadi kesalahan dan kelupaan
ketika menulis spesifikasi untuk sistem yang besar dan kompleks.
9. 1.2 Kebutuhan Non-functional
• Seperti namanya, adalah kebutuhan yang tidak secara
langsung terkait dengan layanan khusus yang disediakan oleh
sistem kepada penggunanya.
• Kebutuhan non-fungsional ini biasanya menentukan atau
membatasi karakteristiksistem secara keseluruhan.
• Kebutuhan ini juga dapat berhubungan dengan properti sistem
yang muncul seperti keandalan, waktu respons, dan
penggunaan memori
10. Penerapan persyaratan ini mungkin tersebar ke seluruh wilayah
sistem, karena dua alasan:
• Kebutuhan non-fungsional dapat mempengaruhi arsitektur
sistem secara keseluruhan daripada komponen individualnya.
Misalnya untuk memastikan kinerja itu persyaratan terpenuhi
dalam sistem tertanam, mungkin harus mengatur sistem untuk
meminimalkan komunikasi antar komponen.
• Persyaratan non-fungsional individu, seperti persyaratan
keamanan, mungkinmenghasilkan beberapa persyaratan
fungsional terkait yang menentukan layanan sistem baru yang
diperlukan jika persyaratan non-fungsional ingin
diimplementasikan.
11.
12.
13. • Sebuah masalah umum dengan kebutuhan non-fungsional adalah
ketika pemangku kepentingan mengusulkan kebutuhan sebagai
tujuan umum, seperti kemudahan penggunaan, kemampuan sistem
untuk pulih dari kegagalan, atau respons pengguna yang cepat. Hal
ini menyebabkan masalah bagi pengembang sistem karena
meninggalkan ruang untuk interpretasi dan perselisihan di masa
depan setelah sistem disampaikan.
• Kebutuhan non-fungsional harus ditulis secara kuantitatif jika
memungkinkan agar dapat diuji secara obyektif. Penggunaan metrik
tertentu seperti kecepatan proses, keandalan, dan kerentanan dapat
membantu menentukan kebutuhan ini.
• Konflik antara kebutuhan fungsional dan non-fungsional sering terjadi.
Misalnya, kebutuhan identifikasi memerlukan pembaca kartu untuk
diinstal di setiap komputer yang terhubung ke sistem, tetapi
kebutuhan lain mungkin menginginkan akses mobile dari tablet atau
smartphone dokter atau perawat.
14. Requirment Engineering
Process
Rekayasa kebutuhan melibatkan tiga kegiatan kunci:
• Menemukan kebutuhan melalui interaksi dengan pemangku
kepentingan (pengumpulan dan analisis).
• Mengubah kebutuhan menjadi bentuk standar (spesifikasi).
• Memvalidasi kebutuhan untuk memastikan sesuai dengan
kebutuhan pelanggan.
Awalnya digambarkan sebagai proses berurutan namun
sebenarnya bersifat iteratif dan berselang-seling.
15. • Gambar 4.6 menunjukkan penyelarasan ini.
Kegiatan-kegiatan tersebut disusun sebagai
proses iteratif dalam bentuk spiral.
• Pada awal proses, sebagian besar usaha
akan dihabiskan untuk memahami
kebutuhan bisnis tingkat tinggi dan non-
fungsional, dan kebutuhan pengguna untuk
sistem.
• Kemudian dalam proses, di cincin-cincin luar
spiral, lebih banyak usaha akan
dipersembahkan untuk menggali dan
memahami kebutuhan non-fungsional dan
kebutuhan sistem yang lebih rinci.
16. • Model spiral tersebut dapat menampung pendekatan
pengembangan di mana kebutuhan dikembangkan dengan
tingkat detail yang berbeda.
• Jumlah iterasi di sekitar spiral dapat bervariasi sehingga spiral
dapat diakhiri setelah beberapa atau semua kebutuhan pengguna
telah dipanggil.
• Pengembangan agile dapat digunakan sebagai gantinya
prototyping sehingga kebutuhan dan implementasi sistem
dikembangkan bersama-sama.
17. 4.3.3 Requirements Elicitation
• Requirements Elicitation adalah proses pertama dalam rekayasa
kebutuhan perangkat lunak yang bertujuan untuk mencari,
mengungkap, memperoleh, dan mengelaborasi kebutuhan untuk
sistem berbasis computer. Proses ini melibatkan komunikasi, prioritas,
negosiasi, dan kolaborasi dengan semua pemangku kepentingan
terkait, seperti pengguna dan sponsor proyek.
• Proses ini juga melibatkan serangkaian kegiatan seperti memahami
domain aplikasi, identifikasi sumber kebutuhan, analisis pemangku
kepentingan, dan memilih teknik, pendekatan, dan alat yang
digunakan. Requirements Elicitation juga dapat dilakukan dengan
menggunakan beberapa metode seperti brainstorming, interview,
observasi, dan analisa dokumen
18. Model proses dari proses elisitasi dan analisis ditunjukkan pada
Gambar 4.7. Setiap organisasi akan memiliki versi atau
penerapannya sendiri dari model umum ini, tergantung pada
faktor-faktor lokal seperti keahlian staf, jenis sistem yang
dikembangkan, dan standar yang digunakan.
Aktivitas prosesnya adalah:
Requirements discovery and understanding
Ini adalah proses berinteraksi dengan pemangku
kepentingan sistem untuk menemukan kebutuhan mereka.
Persyaratan domain dari para pemangku kepentingan dan
dokumentasi juga ditemukan selama kegiatan ini.
Requirements classification and organization
Aktivitas ini mengambil kumpulan persyaratan yang tidak
terstruktur, mengelompokkan persyaratan yang terkait, dan
mengaturnya ke dalam kelompok yang koheren
19. Requirements prioritization and negotiation
Ketika beberapa pemangku kepentingan terlibat, persyaratan akan
mengalami konflik. Aktivitas ini berkaitan dengan memprioritaskan
persyaratan dan menemukan serta menyelesaikan konflik persyaratan
melalui negosiasi. Biasanya, para pemangku kepentingan harus bertemu
untuk menyelesaikan perbedaan dan menyepakati persyaratan kompromi.
Requirements documentation
Persyaratan didokumentasikan dan dimasukkan ke dalam putaran
spiral berikutnya. Draf awal dari dokumen persyaratan perangkat lunak dapat
dihasilkan pada tahap ini, atau persyaratan dapat dikelola secara informal di
papan tulis, wiki, atau ruang bersama lainnya
20. Teknik elisitasi persyaratan
Wawancara
Wawancara formal atau informal dengan pemangku kepentingan
sistem adalah bagian dari sebagian besar proses rekayasa persyaratan.
Dalam wawancara ini, tim teknik persyaratan mengajukan pertanyaan
kepada pemangku kepentingan tentang sistem yang saat ini mereka gunakan
dan sistem yang akan dikembangkan. Persyaratan berasal dari jawaban atas
pertanyaan-pertanyaan ini. Wawancara dapat terdiri dari dua jenis:
• Wawancara tertutup, di mana pemangku kepentingan menjawab
serangkaian pertanyaan yang telah ditentukan.
• Wawancara terbuka, di mana tidak ada agenda yang telah ditentukan. Tim
teknik persyaratan mengeksplorasi berbagai masalah dengan pemangku
kepentingan sistem dan karenanya mengembangkan pemahaman yang
lebih baik tentang kebutuhan mereka.
21. Teknik elisitasi persyaratan
Ethnography
Etnografi sangat efektif untuk menemukan dua jenis persyaratan:
• Persyaratan berasal dari cara di mana orang benar-benar bekerja, daripada cara di
mana definisi proses bisnis mengatakan mereka harus bekerja. Dalam praktiknya,
orang tidak pernah mengikuti proses formal. Misalnya, pengendali lalu lintas udara
dapat mematikan sistem peringatan konflik yang mendeteksi pesawat dengan jalur
penerbangan yang berpotongan, meskipun prosedur kontrol normal menentukan
bahwa itu harus digunakan. Sistem peringatan konflik sensitif dan mengeluarkan
peringatan yang dapat didengar bahkan ketika pesawat berjauhan.
• Persyaratan berasal dari kerja sama dan kesadaran akan kegiatan orang lain.
Misalnya, pengendali lalu lintas udara (ATC) dapat menggunakan kesadaran akan
pekerjaan kontrol lain untuk memprediksi jumlah pesawat yang akan memasuki
sektor kontrol mereka. Mereka kemudian memodifikasi strategi kontrol mereka
tergantung pada beban kerja yang diprediksi.
22. Etnografi dapat dikombinasikan dengan
pengembangan prototipe sistem (Gambar 4.8).
Etnografi menginformasikan pengembangan
prototipe sehingga siklus penyempurnaan
prototipe lebih sedikit diperlukan. Selanjutnya,
prototyping memfokuskan etnografi dengan
mengidentifikasi masalah dan pertanyaan yang
kemudian dapat didiskusikan dengan etnografer.
Dia kemudian harus mencari jawaban atas
pertanyaan-pertanyaan ini selama fase berikutnya
dari studi sistem (Sommerville et al. 1993).
23. Cerita dan skenario
Skenario dimulai dengan garis besar interaksi. Selama proses elisitasi, detail
ditambahkan untuk membuat deskripsi lengkap tentang interaksi tersebut.
Pada yang paling umum, skenario dapat mencakup:
Deskripsi tentang apa yang diharapkan sistem dan pengguna saat skenario
dimulai.
Deskripsi aliran normal peristiwa dalam skenario.
Deskripsi tentang apa yang bisa salah dan bagaimana masalah yang
dihasilkan dapat ditangani.
Informasi tentang kegiatan lain yang mungkin terjadi pada saat yang sama.
Deskripsi status sistem saat skenario berakhir.
24. 4.4 Spesifikasi persyaratan
Spesifikasi persyaratan adalah proses menuliskan persyaratan pengguna dan sistem
dalam dokumen persyaratan. Idealnya, persyaratan pengguna dan sistem harus jelas, tidak
ambigu, mudah dimengerti, lengkap, dan konsisten. Namun, pada tingkat detail yang
diperlukan untuk sepenuhnya menentukan sistem perangkat lunak yang kompleks, tidak
mungkin atau tidak diinginkan untuk mengecualikan semua informasi desain. Ada
beberapa alasan untuk ini:
Anda mungkin harus merancang arsitektur awal sistem untuk membantu menyusun
spesifikasi persyaratan. Persyaratan sistem diatur sesuai dengan subsistem yang berbeda
yang membentuk sistem.
Dalam kebanyakan kasus, sistem harus beroperasi dengan sistem yang ada, yang
membatasi desain dan memaksakan persyaratan pada sistem baru.
Penggunaan arsitektur khusus untuk memenuhi persyaratan non-fungsional, seperti
pemrograman versi-N untuk mencapai keandalan, yang dibahas dalam Bab 11, mungkin
diperlukan. Regulator eksternal yang perlu menyatakan bahwa sistem tersebut aman
dapat menentukan bahwa desain arsitektur yang telah disertifikasi harus digunakan.
25. 4.4.1 Spesifikasi bahasa alami
Bahasa alami telah digunakan untuk menulis persyaratan untuk
perangkat lunak sejak tahun 1950-an. Ini ekspresif, intuitif, dan universal. Ini
juga berpotensi kabur dan ambigu, dan interpretasinya tergantung pada latar
belakang pembaca. Akibatnya, telah banyak proposal untuk cara-cara
alternatif untuk menulis persyaratan. Namun, tidak satu pun dari proposal ini
telah diadopsi secara luas, dan bahasa alami akan terus menjadi cara yang
paling banyak digunakan untuk menentukan persyaratan sistem dan
perangkat lunak.
Untuk meminimalkan kesalahpahaman saat menulis persyaratan bahasa
alami, saya sarankan Anda mengikuti panduan sederhana ini:
26. Ciptakan format standar dan pastikan bahwa semua definisi
persyaratan mematuhi format itu.
Gunakan bahasa secara konsisten untuk membedakan antara
persyaratan wajib dan yang diinginkan.
Gunakan penyorotan teks (tebal, miring, atau warna) untuk memilih
bagian penting dari persyaratan.
Jangan berasumsi bahwa pembaca memahami teknis, bahasa
rekayasa perangkat lunak. Sangat mudah untuk kata-kata seperti
"arsitektur" dan "modul" untuk disalahpahami. Jika memungkinkan,
Anda harus menghindari penggunaan jargon, singkatan, dan akronim.
Bila memungkinkan, Anda harus mencoba mengaitkan alasan dengan
setiap kebutuhan pengguna..
27. 4.4.2 Spesifikasi terstruktur
Bahasa alami terstruktur adalah cara penulisan persyaratan sistem di mana
persyaratan ditulis dengan cara standar daripada sebagai teks bentuk bebas.
Pendekatan ini mempertahankan sebagian besar ekspresi dan pemahaman
bahasa alami tetapiBahasa alami terstruktur adalah cara penulisan persyaratan
sistem di mana persyaratan ditulis dengan cara standar daripada sebagai teks
bentuk bebas. Pendekatan ini mempertahankan sebagian besar ekspresi dan
pemahaman bahasa alami tetapi
Untuk menggunakan pendekatan terstruktur untuk menentukan persyaratan
sistem, Anda menentukan satu atau beberapa template standar untuk
persyaratan dan mewakili template ini sebagai formulir terstruktur. Spesifikasi
dapat disusun di sekitar objek yang dimanipulasi oleh sistem, fungsi yang
dilakukan oleh sistem, atau peristiwa yang diproses oleh sistem. Contoh
spesifikasi berbasis formulir, dalam hal ini, yang mendefinisikan cara menghitung
dosis insulin yang akan diberikan ketika gula darah berada dalam pita yang aman,
ditunjukkan pada Gambar 4.13.
28.
29. Ketika format standar digunakan untuk menentukan persyaratan fungsional,
informasi berikut harus disertakan:
Deskripsi fungsi atau entitas yang ditentukan.
Deskripsi input dan asal input ini.
Deskripsi output dan tujuan output ini.
Informasi tentang informasi yang diperlukan untuk perhitungan atau
entitas lain dalam sistem yang diperlukan (bagian "membutuhkan").
Deskripsi tindakan yang akan diambil.
Jika pendekatan fungsional digunakan, prasyarat menetapkan apa yang
harus benar sebelum fungsi dipanggil, dan postcondition menentukan apa
yang benar setelah fungsi dipanggil.
Deskripsi efek samping (jika ada) dari operasi.
30. Tabel sangat berguna ketika ada sejumlah
kemungkinan situasi alternatif dan Anda perlu
menjelaskan tindakan yang harus diambil untuk
masing-masing. Pompa insulin mendasarkan
perhitungannya dari kebutuhan insulin pada tingkat
perubahan kadar gula darah. Tingkat perubahan
dihitung menggunakan pembacaan saat ini dan
sebelumnya. Gambar 4.14 adalah deskripsi tabular
tentang bagaimana laju perubahan gula darah
digunakan untuk menghitung jumlah insulin yang akan
dikirimkan.
31. 4.4.3 Kasus penggunaan
Kasus penggunaan adalah cara untuk menggambarkan interaksi antara pengguna
dan sistem menggunakan model grafis dan teks terstruktur. Mereka pertama kali
diperkenalkan dalam metode Objectory (Jacobsen et al. 1993) dan sekarang telah
menjadi fitur mendasar dari Unified Modeling Language (UML). Dalam bentuknya
yang paling sederhana, kasus penggunaan mengidentifikasi aktor yang terlibat
dalam interaksi dan menyebutkan jenis interaksi. Anda kemudian menambahkan
informasi tambahan yang menjelaskan interaksi dengan sistem. Informasi
tambahan dapat berupa deskripsi tekstual atau satu atau lebih model grafis
seperti urutan UML atau bagan negara (lihat Bab 5).
Kasus penggunaan mengidentifikasi interaksi individu antara sistem dan
penggunanya atau sistem lain. Setiap kasus penggunaan harus didokumentasikan
dengan deskripsi tekstual. Ini kemudian dapat dihubungkan ke model lain di UML
yang akan mengembangkan skenario secara lebih rinci. Misalnya, deskripsi
singkat tentang kasus penggunaan Konsultasi Penyiapan dari Gambar 4.15
mungkin:
32. Konsultasi pengaturan memungkinkan dua atau lebih
dokter, yang bekerja di kantor yang berbeda, untuk
melihat catatan pasien yang sama pada saat yang
bersamaan. Seorang dokter memulai konsul dengan
memilih orang-orang yang terlibat dari menu dropdown
dokter yang sedang online. Catatan pasien kemudian
ditampilkan di layar mereka, tetapi hanya dokter yang
memulai yang dapat mengedit catatan. Selain itu,
jendela obrolan teks dibuat untuk membantu
mengoordinasikan tindakan. Diasumsikan bahwa
panggilan telepon untuk kation komunikasi suara dapat
diatur secara terpisah.
33. 4.4.4 Dokumen persyaratan
perangkat lunak
Dokumen persyaratan perangkat lunak (kadang-kadang disebut spesifikasi
persyaratan perangkat lunak atau SRS) adalah pernyataan resmi tentang
apa yang harus diterapkan oleh pengembang sistem. Ini dapat mencakup
persyaratan pengguna untuk suatu sistem dan spesifikasi terperinci dari
persyaratan sistem. Terkadang persyaratan pengguna dan sistem
diintegrasikan ke dalam satu deskripsi. Dalam kasus lain, persyaratan
pengguna dijelaskan dalam bab pengantar dalam spesifikasi persyaratan
sistem.
Dokumen persyaratan memiliki beragam pengguna, mulai dari manajemen
senior organisasi yang membayar sistem hingga insinyur yang bertanggung
jawab untuk mengembangkan perangkat lunak. Gambar 4.16 menunjukkan
kemungkinan pengguna dokumen dan bagaimana mereka
menggunakannya.
34.
35. Requirements validation
• Validasi kebutuhan adalah proses memastikan bahwa kebutuhan-
kebutuhan tersebut secara tepat mendefinisikan sistem yang
diinginkan oleh pelanggan. Proses ini sering kali berhubungan erat
dengan tahapan pengumpulan informasi dan analisis, karena
tujuannya adalah untuk menemukan masalah-masalah yang mungkin
ada dalam kebutuhan tersebut. Validasi kebutuhan sangat penting
karena kesalahan dalam dokumen kebutuhan dapat menyebabkan
biaya pengulangan yang besar saat masalah-masalah ini ditemukan
selama pengembangan atau setelah sistem beroperasi.
36. • Selama proses validasi kebutuhan, berbagai jenis pemeriksaan
harus dilakukan pada dokumen kebutuhan. Pemeriksaan ini
meliputi:
1. Validity checks: Memastikan bahwa kebutuhan mencerminkan kebutuhan
nyata pengguna sistem.
2. Consistency checks: Memastikan bahwa tidak ada konflik antara kebutuhan
yang terdapat dalam dokumen.
3. Completeness checks: Memastikan bahwa dokumen kebutuhan mencakup
semua fungsi dan batasan yang dimaksudkan oleh pengguna sistem.
4. Realism checks: Memastikan bahwa kebutuhan dapat diimplementasikan
dalam anggaran yang diajukan untuk sistem.
5. Verifiability: Memastikan bahwa kebutuhan sistem dapat diverifikasi dengan
menguji apakah sistem yang disampaikan memenuhi setiap kebutuhan yang
ditentukan.
37. • Beberapa teknik validasi kebutuhan yang dapat digunakan secara
individu atau bersama-sama antara lain:
1. Requirements reviews: Kebutuhan dianalisis secara sistematis oleh tim pemeriksa
untuk menemukan kesalahan dan inkonsistensi.
2. Prototyping: Pengembangan model eksekutif sistem yang digunakan bersama
pengguna akhir dan pelanggan untuk memastikan apakah memenuhi kebutuhan
dan harapan mereka. Para pemangku kepentingan mencoba sistem tersebut dan
memberikan umpan balik perubahan kebutuhan kepada tim pengembangan.
3. Test-case generation: Kebutuhan harus dapat diuji. Jika tes untuk kebutuhan
tersebut dirancang sebagai bagian dari proses validasi, ini sering mengungkap
masalah kebutuhan. Jika suatu tes sulit atau tidak mungkin dirancang, ini biasanya
berarti kebutuhan akan sulit diimplementasikan dan harus dipertimbangkan
kembali. Mengembangkan tes dari kebutuhan pengguna sebelum menulis kode
merupakan bagian integral dari pengembangan berbasis tes.
38. Requirements change
• Kebutuhan untuk sistem perangkat lunak besar selalu berubah. Salah
satu alasan perubahan yang sering terjadi adalah bahwa sistem-sistem
ini sering dikembangkan untuk menangani “masalah jahat” – masalah
yang tidak dapat sepenuhnya didefinisikan (Rittel dan Webber 1973).
Karena masalahnya tidak dapat sepenuhnya didefinisikan, kebutuhan
perangkat lunak kemungkinan besar akan berubah.
39. • Saat proses pengembangan
perangkat lunak
berlangsung, pemahaman
para pemangku kepentingan
tentang masalah terus
berubah. Oleh karena itu,
kebutuhan sistem harus
berkembang untuk
mencerminkan pemahaman
yang berubah tentang
masalah tersebut.
40. • Setelah sistem terpasang dan digunakan, kebutuhan baru tak
terhindarkan. Sebagian karena kesalahan dalam kebutuhan awal yang
harus diperbaiki. Namun, kebanyakan perubahan kebutuhan muncul
karena perubahan lingkungan bisnis:
1. Lingkungan bisnis dan teknis selalu berubah setelah instalasi. Perangkat
keras baru mungkin diperkenalkan, prioritas bisnis dapat berubah, dan
regulasi baru mungkin diberlakukan.
2. Pembayar sistem dan pengguna jarang sama. Pembayar sistem
menetapkan kebutuhan berdasarkan kendala organisasi dan anggaran,
mungkin bertentangan dengan kebutuhan pengguna.
3. Sistem besar memiliki beragam pemangku kepentingan dengan kebutuhan
yang berbeda. Kebutuhan akhir merupakan kompromi, dan kadang perlu
disesuaikan ulang sesuai pengalaman.
41. • Saat kebutuhan terus berkembang, Anda perlu melacak kebutuhan
individual dan menjaga hubungan antara kebutuhan yang saling
bergantung sehingga Anda dapat menilai dampak perubahan kebutuhan.
Oleh karena itu, Anda memerlukan proses formal untuk membuat
proposal perubahan dan menghubungkannya dengan kebutuhan sistem.
Proses ini dikenal sebagai “manajemen kebutuhan” dan sebaiknya
dimulai segera setelah versi draf dokumen kebutuhan tersedia.
• Proses pengembangan Agile telah dirancang untuk mengatasi kebutuhan
yang berubah selama proses pengembangan. Dalam proses ini, ketika
pengguna mengusulkan perubahan kebutuhan, perubahan tersebut tidak
melalui manajemen perubahan formal.
42. 4.6.1 Requirements management planning
Requirements management planning berkaitan dengan menetapkan bagaimana satu set
kebutuhan yang berkembang akan dikelola. Selama tahap perencanaan, Anda harus
memutuskan beberapa isu:
1. Requirements identification setiap kebutuhan harus diidentifikasi secara unik sehingga
dapat dirujuk dengan kebutuhan lainnya dan digunakan dalam penilaian jejak.
2. A change management process ini adalah serangkaian aktivitas yang menilai dampak dan
biaya perubahan. Saya akan membahas proses ini lebih detail dalam bagian berikutnya.
3. Traceability policies Kebijakan ini menetapkan hubungan antara setiap kebutuhan dan
antara kebutuhan dan desain sistem yang harus dicatat. Kebijakan jejak juga harus
menetapkan bagaimana catatan-catatan ini harus dipelihara.
4. Tool support Manajemen kebutuhan melibatkan pemrosesan informasi besar tentang
kebutuhan. Alat yang dapat digunakan bervariasi mulai dari sistem manajemen kebutuhan
khusus hingga spreadsheet bersama dan sistem basis data sederhana.
43. • Requirements management memerlukan dukungan otomatis, dan
alat perangkat lunak untuk ini harus dipilih selama fase perencanaan.
Anda memerlukan dukungan alat untuk:
1. Requirements storage : Kebutuhan harus dipelihara dalam penyimpanan data
yang aman dan dikelola yang dapat diakses oleh semua pihak yang terlibat
dalam proses rekayasa kebutuhan.
44. 2. Change management: Proses ini lebih mudah dengan dukungan alat yang dapat
melacak dan merespons perubahan yang disarankan.
3. Traceability: Alat ini memungkinkan penemuan kebutuhan terkait dan dapat
menggunakan teknik pemrosesan bahasa alami.
Untuk sistem kecil, dokumen web bersama, spreadsheet, dan basis data cukup untuk
mendukung manajemen kebutuhan. Namun, untuk sistem yang lebih besar, alat
khusus seperti DOORS (IBM 2013) sangat membantu dalam melacak banyaknya
kebutuhan yang berubah.
45. 4.6.2 Requirements change management
Requirements change management harus diterapkan pada semua
perubahan yang diusulkan terhadap kebutuhan sistem setelah
dokumen kebutuhan disetujui. Manajemen perubahan penting karena
Anda perlu memutuskan apakah manfaat dari menerapkan kebutuhan
baru dibenarkan oleh biaya implementasi. Keuntungan menggunakan
proses formal untuk manajemen perubahan adalah bahwa semua
proposal perubahan diperlakukan secara konsisten dan perubahan
pada dokumen kebutuhan dibuat dengan terkendali.
46. 1. Problem analysis and change specification: Proses dimulai dengan mengidentifikasi masalah
kebutuhan atau proposal perubahan. Masalah atau proposal tersebut dianalisis untuk
memastikan validitasnya, dan hasilnya disampaikan kembali kepada pengusul perubahan.
2. Change analysis and costing: Dampak perubahan dievaluasi menggunakan informasi jejak dan
pengetahuan sistem. Biaya perubahan diperkirakan termasuk modifikasi dokumen kebutuhan dan
desain sistem. Setelah analisis, keputusan diambil untuk melanjutkan atau tidak perubahan
kebutuhan.
3. Change implementation: Dokumen kebutuhan, dan jika perlu, desain dan implementasi sistem
dimodifikasi. Dokumen kebutuhan sebaiknya diatur agar perubahan dapat dilakukan tanpa
penulisan ulang atau reorganisasi yang luas. Seperti halnya dengan program, kemampuan untuk
diubah dalam dokumen dapat dicapai dengan meminimalkan referensi eksternal dan membuat
bagian-bagian dokumen semodular mungkin. Dengan demikian, bagian-bagian individu dapat
diubah dan diganti tanpa memengaruhi bagian lain dari dokumen.
47. References
• Ian Sommerville, 2016, Software Engineering, Tenth Edition, Pearson
Education Limited, Edinburgh Gate, Harlow, Essex CM20 2JE, England
