rekayasa kebutuhan perangkat lunak

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