9. Pengertian
Requirements Engineering adalah fase terdepan
dari proses rekayasa perangkat lunak, dimana
software requirements (kebutuhan) dari user
(pengguna) dan customer (pelanggan) dikumpulkan,
dipahami dan ditetapkan.
10. Pengertian
Teknik kebutuhan perangkat lunak (Requirements Engineering)
atau sering juga disebut analisis kebutuhan perangkat lunak (Bahasa
Inggris: Requirements Analysis) mencakup kegiatan dalam
menentukan kebutuhan-kebutuhan atau kondisi yang harus
dipenuhi untuk suatu produk baru atau pengembangan, dengan
mempertimbangkan kemungkinan terjadinya konflik kebutuhan dari
berbagai macam stakeholder.
11. Peran Penting Analisis Kebutuhan
Analisis kebutuhan mempunyai peran penting dalam kesuksesan
suatu proyek perangkat lunak. Kebutuhan harus terdokumentasi,
dapat ditindaklanjuti (actionable), dapat diukur (measureable),
dapat diuji, memiliki kaitan dengan kebutuhan dan peluang bisnis,
serta memiliki tingkat kerincian yang cukup untuk perancangan
sistem.
12. Konsep Kebutuhan Perangkat Lunak
Kebutuhan perangkat lunak adalah kondisi,
kriteria, syarat atau kemampuan yang harus
dimiliki oleh perangkat lunak untuk memenuhi
apa yang disyaratkan atau diinginkan pemakai.
13. Mengapa Perlu Rekayasa Kebutuhan?
Alasan pokok dasar mengapa diperlukan rekayasa kebutuhan adalah:
1. Semua perangkat lunak memiliki spesifikasi
2. Permasalahan berawal dari spesifikasi kebutuhan.
Mengapa kualitas proses penspesifikasian kebutuhan sistem tersebut menjadi rendah yaitu
sebab:
1. Kepedulian yang rendah.
2. Adanya jurang pemisah.
3. Permintaan kebutuhan yang tak henti.
14. Apa Saja Teknik Kebutuhan Perangkat Lunak?
Teknik kebutuhan tersebut mencakup empat kunci proses,
yaitu: Elisitasi, Analisis, Spesifikasi dan Validasi. Keberhasilan
pada siklus pengembangan perangkat lunak yang menghasilkan
produk didasarkan pada proses kebutuhan perangkat lunak yang
baik.
15. Apa Saja Teknik Kebutuhan Perangkat Lunak?
Tahap Keterangan Metode
Elicitation (pengumpulan informasi)
Bertujuan untuk mengumpulkan sebanyak
mungkin informasi mengenai problem domain,
kesulitan-kesulitan klien dan user, serta apa
yang sistem ingin lakukan untuk mereka.
Wawancara
Kuesioner
Skenario
Prototyping
Specification (spesifikasi)
Informasi dari proses elicitation dianalisis dan
direkam menggunakan teknik modeling
dramatis dan tekstual untuk menunjukkan
masalah dan solusi yang diajukan.
Spesifikasi formal
Protoyping
Validation (validasi)
Mengecek kebutuhan yang telah direkam
apakah telah berkaitan dengan tujuan
stakeholder terhadap sistem.
Wawancara
Teknik kombinasi dari elicitation
Inspeksi Fagan
Prototyping
16. Mengapa di Perlukan Kebutuhan Perangkat Lunak?
Banyak permasalahan dalam pengembangan perangkat lunak berakar pada keterbatasan
pemahaman pengembang akan kebutuhan pengguna terhadap perangkat lunak yang
dibangun.
Hal ini disebabkan oleh keterbatasan data dan informasi yang didapatkan pada waktu proses
pengumpulan, penganalisaan, penspesifikasian, verifikasi dan validasi kebutuhan dari
perangkat lunak yang hendak dibangun.
17. Jenis Kebutuhan Perangkat Lunak
1. Kebutuhan pengguna adalah pernyataan, dalam bahasa alami ditambah
diagram, dari layanan apa yang diharapkan sistem untuk diberikan kepada
pengguna sistem dan kendala di mana sistem harus selesaikan.
2. Kebutuhan sistem adalah deskripsi yang lebih rinci tentang fungsi, layanan,
dan kendala operasional sistem perangkat lunak. Dokumen Kebutuhan
sistem (kadang-kadang disebut spesifikasi fungsional) harus mendefinisikan
secara tepat apa yang akan diimplementasikan. Ini mungkin menjadi bagian
dari kontrak antara pembeli sistem dan pengembang perangkat
18. Siapa yang Berkepentingan terhadap Sistem?
1. Pelanggan (customer), yang memesan pembangunan dari suatu perangkat lunak untuk mencapai
tujuan bisnis dari organisasi
2. Pemilik sistem (System Owner) merupakan sub-kelas dari pelanggan yang memiliki sistem dan
berkepentingan atas tercapainya tujuan bisnis melalui sistem yang dibangun. Biasanya pemilik sistem
juga sekaligus penyandang dana dari proyek terkait.
3. Pengguna (User) merupakan sub-kelas pelanggan yang berinteraksi langsung maupun tidak langsung
dengan produk mereka.
4. Analisis kebutuhan (Requirements Analyst) yang menuliskan spesifikasi kebutuhan dari suatu
perangkat lunka dan mengkomunikasikannya kepada komunitas pengembang.
5. Pengembang (Developer) yang merancang, mengimplementasikan dan memelihara proyek.
19. Siapa yang Berkepentingan terhadap Sistem?
1. Penguji (Tester) merupakan sub-kelas dari pengembang yang menentukan apakah sistem memang
sudah berperilaku seperti yang diterapkan.
2. Penulis Dokumentasi (Documentary’s Writer) merupakan sub-kelas dari pengembang yang
menghasilkan user manual, mining material, dan sistem bantuan.
3. Manajer proyek (Project Manager) merupakan sub-kelas dari pengembang yang merencanakan proyek
dan mengarahkan tim pengembang untuk menghasilkan produk yang sukses.
4. Staf hukum (legal) dan non-hukum (non-legal) yang memastikan bahwa produk yang dihasilkan patuh /
sesuai dengan hukum dan peraturan yang berlaku.
5. Staf manufaktur (Manufacturing personel) merupakan sub-kelas dari pengembang yang harus
membangun produk-produk yang membentuk sistem perangkat lunak.
6. Penjualan (Sales), pemasaran (Marketing) dan bagian pendukung, serta pihak-pihak lain yang nantinya
bekerja menggunakan sistem yang hendak dibangun.
7. Penyelia (Vendor) yang menyediakan teknologi bagi pembangunan sistem.
8. Regulator yang menetapkan batasan berupa baku mutu, peraturan, panduan atau rambu-rambu lain
terkait dengan produk, proses maupun personel dalam proses pengembangan sistem.