rekayasa kebutuhan perangkat lunak
DESCRIPTION
Rekayasa Kebutuhan Perangkat LunakTRANSCRIPT
Rekayasa Kebutuhan Perangkat Lunak
Sherly Christina, S.Kom., M.Kom
Materi
• Pengertian Rekayasa Kebutuhan PL• Mengapa perlu Rekayasa Kebutuhan PL• Stakeholder• Tipe Kebutuhan Perangkat Lunak• Outline SKPL-IEEE 830-1998• Studi Kasus
Pengertian
• Requirements are a specification of what should be implemented. (Sommerville and Sawyer, 1997)
Pengertian
• Investigating and describing the problem domain and requirements and designing anddocumenting the characteristics for a solution system that will meet those requirements (Ian K. Bray, An Introduction to Requirements Engineering, 2002)
Pengertian
• Investigasi dan identifikasi• Komunikasi dan dokumentasi
– Atribut/Properti/Karakteristik, Kapabilitas, Kualitas, dan Batasan-batasan yang Penting.
– Agar memiliki nilai dan kegunaan bagi pengguna (user)
Mengapa perlu Rekayasa Kebutuhan PL
Stakeholder
• Stakeholder adalah setiap pihak yang memiliki kepentingan terhadap sesuatu.
• Sesuatu dalam konteks perangkat lunak adalah proyek pengembangan perangkat lunak itu sendiri– Yang termasuk stakeholder : Pelanggan,
Regulator, Penyelia, Pengembang
Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak
• Stakeholder sering tidak mengetahui apa yang diinginkan dan mengungkapkan keinginannya dalam kalimat yang umum.
• Stakeholder mengungkapkan permintaan dalam istilah bidang pekerjaannya, sehingga perekayasa kebutuhan yang tidak memiliki pengalaman di bidang kerja pemesan harus memahami permintaan tersebut.
• Beberapa stakeholder memiliki permintaan yang berbeda-beda yang dinyatakan dalam cara yang berbeda pula.
• Faktor politik dapat mempengaruhi kebutuhan sistem.• Lingkungan bisnis dan ekonomi bersifat dinamis.
Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak
Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak
Tipe Kebutuhan
Kebutuhan dapat dibedakan menjadi:• Kebutuhan fungsional, yang mendeskripsikan
layanan-layanan atau fungsi-fungsi dari sistem• Kebutuhan non-fungsional, yang merupakan
batasan-batasan pada sistem atau pada proses pengembangan sistem
Tingkatan dalam Kebutuhan
Kebutuhan Bisnis
• Tujuan tingkat tinggi dari organisasi• Biasanya berasal dari penyandang dana atau
pemilik sistem• Mendeskripsikan Mengapa organisasi
menginginkan pengimplementasian sistem bersangkutan.– Contoh:Universitas: Meningkatkan efisiensi selama
proses registrasi kuliah.– Perusahaan: Mengurangi biaya tak perlu, memonitor
kinerja setiap waktu.
Kebutuhan Pengguna
• Goal atau tugas pengguna yang harus dapat dilaksanakan menggunakan produk bersangkutan.– Contoh:FRS-Online: memilih mata kuliah,
mengajukan persetujuan, menampilkan latar belakang mahasiswa.
– Online Ticketing: memesan tiket, mengecek jadwal, memesan tempat duduk.
Kebutuhan Fungsional• Fungsionalitas perangkat lunak• Kebutuhan perilaku• Gunakan kata “akan” (shall)
– Contoh:FRS-Online: “The system shall view a confirmation to the student.”
– Online Ticketing: “The system shall provide a link to download an softcopy ticket.”
Kebutuhan Sistem
• Kebutuhan tingkat atas dari sebuah sistem yang terdiri dari sub sistem ganda
• Sistem terdiri dari: : Hardware + Software + Brainware
Aturan Bisnis/Constraint• Termasuk:
– Corporate policies– Government regulations– Industry standards– Accounting practices– Computational algorithm
• Ada di luar sistem• Fungsi:Membatasi siapa dan bagaimana melakukan suatu use cases
tertentu• Mendikte fungsionalitas yang harus dimiliki suatu sistem agar comply
dengan aturan-aturan yang sudah berlaku• Gunakan sebagai atribut kualitas.
– Contohs:Sistem perbankan: Semua kartu kredit harus menggunakan smart card.”
– SIAK: Suatu kartu ID harus sesuai dengan KepMen No. 80/2005.”
Atribut Kualitas• Termasuk goal dan deskripsi dari kinerja
Contoh:– Usability: “The system is equipped with user manual.”– Portability: “The system shall work in Microsoft-OSs
and Unix-OS.”– Integrity: “The system shall restrict access for
un-authorized user.”– Efficiency: “The system shall work with maximum
200VA/hour.”– Robustness: “The system shall withstand 5.1
atmoshpere pressure.”
Tujuan Dokumen Spesifikasi
• Menyediakan umpan balik kepada konsumen. • Memecah permasalahan ke dalam
komponen-komponen yang lebih kecil. • Merupakan masukan untuk tahap spesifikasi
rancangan. • Bisa melakukan pengecekan validasi produk.
Outline SKPL-IEEE 830-1998
Studi Kasus
• Website Perpustakaan • Game Belajar Berhitung
Buat komponen SKPL berikut:1. Deskripsi Umum produk2. Fungsi Produk3. Karakteristik Pengguna