Dokumen tersebut membahas proses persyaratan perangkat lunak, mulai dari definisi persyaratan, jenis persyaratan (fungsional dan non fungsional), sumber persyaratan, teknik elisitasi, analisis, spesifikasi, hingga validasi persyaratan perangkat lunak.

1. Software Requirements
Muhammad Ainul Yaqin

2. Definisi
• Karakteristik yang harus dimiliki
perangkat untuk memecahkan masalah
dunia nyata.
• Hasil pemikiran dari berbagai orang
dalam organisasi dan harus dapat
diverifikasi sebagai fungsional atau
nonfungsional

3. Kebutuhan Produk dan Proses
• Kebutuhan produk adalah kendala yang harus
dipenuhi dalam pengembangan perangkat lunak
• Kebutuhan proses adalah kendala pada
pengembangan perangkat lunak
• Kebutuhan proses juga dapat dikenakan oleh
organisasi pengembangan, pelanggan, atau
pihak ketiga seperti regulator keselamatan.

4. Kebutuhan Fungsional dan Non
Fungsional
• Kebutuhan fungsional menjelaskan
fungsi-fungsi yang akan dijalankan oleh
perangkat lunak
• Kebutuhan non fungsional membatasi
solusi dan bisa diklasifikasikan sebagai
kendala atau kualitas perangkat lunak

5. Proses Kebutuhan
• Model Proses
• Aktor Proses
• Dukungan dan Manajemen Proses
• Kualitas dan Peningkatan Proses

6. Model Proses
• Bukan aktifitas front-end dari siklus hidup
perangkat lunak
• Mengidentifikasi kebutuhan perangkat
lunak sebagai item konfigurasi dan
mengelolanya

7. Aktor Proses
• Pengguna
• Pelanggan
• Analis Pasar
• Regulator
• Insinyur perangkat lunak

8. Requirement Elcitation
• Merupakan aktivitas manusia untuk
mengidentifikasi dan membangun hubungan
antara tim pengembangan dan pelanggan
• Penyediaan deskripsi ruang lingkup proyek yang
memprioritaskan hasil untuk memenuhi
kebutuhan bisnis pelanggan paling penting
dan meminimalkan risiko pembuatan
persyaratan yang kurang penting

9. Sumber Kebutuhan
• Tujuan
• Pengetahuan domain
• Stakeholder
• Aturan bisnis
• Lingkungan operasional
• Lingkungan organisasi

10. Teknik Elisitasi
• Wawancara
• Skenario
• Prototipe
• Pertemuan
terfasilitasi
• Observasi
• Survey
• Cerita pengguna
• Analisis dokumen

11. Analisis Kebutuhan
• Klasifikasi kebutuhan
• Pemodelan konseptual
• Desain arsitektur dan alokasi kebutuhan
• Negosiasi kebutuhan
• Analisis formal

12. Klasifikasi Kebutuhan
• Fungsional / non-fungsional
• Turunan / bukan turunan
• Produk / proses
• Prioritas kebutuhan
• Lingkup kebutuhan
• Volatilitas / stabilitas

13. Pemodelan Konseptual
• Tujuannya untuk membantu memahami
situasi masalah dan menggambarkan
solusi.
• Notasi model konseptual  diagram use
case, DFD, model objek, model data, …
• Pemilihan notasi pemodelan berdasarkan:
– Sifat masalah
– Keahlian insinyur
– Kebutuhan proses pelanggan

14. Desain arsitektur dan alokasi
kebutuhan
• Desain arsitektur adalah proses dimana
kebutuhan diterjemahkan menjadi solusi
perangkat lunak atau desain sistem
• Alokasi kebutuhan ke komponen
arsitektur penting untuk analisis yang
terperinci dan dapat menyebabkan analisis
tambahan untuk setiap subsistem

15. Negosiasi Kebutuhan
• Insinyur perangkat lunak harus bekerjasama
dengan pemangku kepentingan untuk mencapai
konsensus dan bertindak secara transparan.
• Prioritas kebutuhan sangat penting untuk
mengatasi konflik dan merencanakan
pengiriman bertahap.

16. Negosiasi Kebutuhan
• Pendekatan prioritas kebutuhan melibatkan
analisis nilai biaya, dengan mempertimbangkan
manfaat dan hukuman dari menerapkan setiap
kebutuhan.
• Ada juga pendekatan lain yang melibatkan
proses hierarki analitik untuk membandingkan
pasangan kebutuhan unik.

17. Analisis Kebutuhan
• Analisis formal memiliki pengaruh pada
beberapa aplikasi, khususnya yang
memiliki tingkat integritas sistem yang
tinggi.
• Ekspresi formal kebutuhan membutuhkan
bahasa dengan semantik yang
didefinisikan secara formal.

18. Spesifikasi Kebutuhan
• Dokumen definisi sistem
• Spesifikasi kebutuhan sistem
• Spesifikasi kebutuhan perangkat lunak

19. Dokumen Definisi Sistem
• Dokumen ini berisi kebutuhan sistem
tingkat tinggi dari sudut pandang domain.
• Pembacanya terdiri dari perwakilan
pengguna/pelanggan sistem dan ditulis
dalam istilah domain.

20. Dokumen Definisi Sistem
• Dokumen mencantumkan kebutuhan
sistem berserta informasi latar belakang
tentang tujuan, lingkungan target, dan
pernyataan kendala, asumsi, dan
persyaratan non-fungsional.
• Mungkin juga menyertakan model
konseptual yang menggambarkan konteks
sistem, skenario penggunaan, entitas
utama, dan alur kerja.

21. Spesifikasi Kebutuhan Sistem
• Spesifikasi kebutuhan sistem adalah
aktivitas rekayasa sistem yang berada di
luar cakupan panduan

22. Spesifikasi Kebutuhan
Perangkat Lunak
• Spesifikasi kebutuhan perangkat lunak
adalah dokumen yang menetapkan dasar
kesepakatan antara pelanggan dan
pemasok/kontraktor mengenai
fungsionalitas dan tugas produk perangkat
lunak

23. Spesifikasi Kebutuhan
Perangkat Lunak
• Kebutuhan perangkat lunak dapat ditulis
dalam bahasa alami atau dalam deskripsi
formal/semi formal.
• Indikator kualitas yang dapat digunakan
untuk mengukur kualitas spesifikasi
kebutuhan perangkat lunak meliputi
ukuran, keterbacaan, spesifikasi,
kedalaman, dan struktur teks.

24. Validasi Kebutuhan
• Tinjauan kebutuhan
• Prototyping
• Validasi model
• Tes penerimaan

25. Tinjauan Kebutuhan
• Validasi dokumen kebutuhan biasanya dilakukan
melalui tinjauan oleh sekelompok pemeriksa.
• Komposisi tim yang sesuai, seperti perwakilan
pelanggan, penting dan mungkin memerlukan
daftar periksa.
• Tinjauan dapat dilakukan pada berbagai tahap
dalam proses pembuatan perangkat lunak, seperti
pada dokumen definisi sistem, spesifikasi sistem,
atau spesifikasi kebutuhan perangkat lunak.

26. Prototyping
• Prototyping adalah cara untuk memvalidasi
interpretasi insinyur perangkat lunak dari
persyaratan perangkat lunak dan menemukan
persyaratan baru.
• Ada berbagai teknik pembuatan prototipe
dan validasi prototipe mungkin dilakukan
pada berbagai titik dalam proses.

27. Prototyping
• Prototipe memudahkan interpretasi asumsi
insinyur perangkat lunak dan memberikan
umpan balik berguna.
• Namun, ada kekurangan, seperti risiko
perhatian teralihkan dari fungsionalitas
utama dan biaya pengembangan.
• Prototipe awal mungkin berisi bagian solusi
akhir dan dapat berkembang seiring waktu.