03 Software Requirements
Download as PPTX, PDF0 likes11 views
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.
More Related Content
Similar to 03 Software Requirements (20)
More from Ainul Yaqin (20)
03 Software Requirements
- 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.