Pertemuan 5 Rekayasa Perangkat Lunak Requirement Pertemuan 5 Rekayasa Perangkat Lunak
Definisi Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasanbatasan dari sistem dan bisa juga berupa definisi matematis fungsifungsi sistem.
Requirement Engineering Fungsi Menjadi dasar penawaran suatu kontrak harus terbuka untuk masukan Menjadi dasar kontrak harus didefinisikan secara detil Requirement Engineering Proses menemukan, menganalisis, men dokumentasikan dan pengujian layanan layanan dan batasan.
Catatan Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.
Pengumpulan Requirement Interviews: Memberi informasi yang terbaik, mahal Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon cenderung kurang baik Observation: Akurat jika dilakukan dengan baik, mahal Searching: Informasi terbatas, cenderung tidak menampilkan halhal yang mungkin jadi masalah
Macam Requirement (1) User Requirement (kebutuhan pengguna) : Pernyataan tentang layanan yang disediakan sistem dan tentang batasanbatasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah. System Requirement (kebutuhan sistem) : Sekumpulan layanan/kemampuan sistem dan batasanbatasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
Macam Requirement (2) A software design specification (spesifikasi rancangan PL) : Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masingmasing memberi pengertian ke pihak yang berbeda kepentingan.
Pembaca Requirement
Masalah dalam Pendefinisian Requirement Sulit mengantisipasi efek dari sistem baru terhadap organisasi. Beda user, beda pula requirement dan prioritasnya terpengaruh cara atau gaya kerja. Enduser sistem, dan organisasi yang membiayai sistem berbeda requirement. Prototype sering dibutuhkan untuk menjelaskan requirement Masalah perbedaan bahasa alami
Kategori Software System Requirement (1) Functional Requirement : Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasisituasi tertentu. Menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku.
Contoh Kasus Peminjaman Buku Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari informasi tentang buku. Semua peminjam memiliki pengenal yang unik Sistem mampu mencatat transaksi peminjaman, pengembalian dan denda secara lengkap Hari libur bisa diset sejak awal, dan bisa menerima perubahan dengan otoritas khusus Harus komplit (kebutuhan layanan jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan)
Masalah dalam Menyusun Functional Requirement Diintepretasikan/diartikan berbeda oleh user atau developer Hasil intepretasi sering tidak menjawab kebutuhan klien Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem Perlu analisis yang dalam dan menyeluruh untuk kesalahan
Kategori Software System Requirement (2) Nonfunctional Requirement Secara umum berisi batasanbatasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standarstandar tertentu.
Cakupan NonFunctional Requirement
Non-Functional Requirement dibagi 3 Tipe Product req. berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem Organisational req. berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan. External req. berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.
Kategori Software System Requirement (3) Domain requirement Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang tidak berhak.
User Requirement Menggambarkan functional dan nonfunctional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana.
Masalah dalam Menyiapkan User Requirement Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat dokumen jadi sulit dibaca. Catatan : Sering digabungkan menjadi satu kumpulan requirement saja Contoh penggunaan bahasa alami : pengguna perpustakaan dapat mencari informasi tentang pustaka melalui form pencarian dengan mengetikkan kata kunci yang merupakan kata kunci dari judul buku, nama pengarang atau nama penerbit.
Mengurangi Kesalahpahaman User Requirement Buatlah format yang standar untuk penulisan. Format ini untuk mengurangi halhal yang tidak perlu dan mudah untuk diperiksa kembali. Menggunakan bahasa yang konsisten, istilahistilah yang konsisten sehinga mudah dikuti. Gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting untuk beberapa istilah atau penjelasan. Hindari istilahistilah teknis komputer yang tidak dimengerti oleh user. Jika terpaksa menggunakan, buatlah daftar istilah dan artinya sehingga mudah diikuti oleh user.
System Requirement Merupakan deskripsi sistem yang lebih detil dari user requirement (jadi masih berisi functional dan non functional req). Req ini bisa berlaku sebagai kontrak pembangunan sistem dan isa terdiri dari macam model sistem seperti model object atau model dataflow. System req. menyatakan apa yang harus dikerjakan sistem, dan bukan bagaimana sistem diimplementasikan. Dapat digunakan bahasa yang lebih spesifik dan bersifat teknis, seperti misalnya PDL (Program Description Language)
Contoh PDL : Fungsi ATM Class ATM { //declaration here public state void main(string args[]) throws InvalidCard { try { thisCard.read(); //maythrowInvalidCardexception pin = KeyPad.readPin(); attempts =1; while ( IthisCard.pin.equals(pin)& attempts <4) { pin = Keypad.readPin (); attempts = attempts+1; } if (IthisCard.pin.equals(pin)) throw new InvalidCard (“Bad Pin”); thisBalance=thisCard.getBalance(); do { Screen.prompt(“Please select a service”); service = Screen.touchkey(); switch(service){ case Service.withdrawalWithReceipt: receiptRequired = true; case Service.withdrawalNoReceipt: amount = KeyPad.readAmount(); if (amount > thisBalance) { Screen.printmsg(“Balance insufficient”); break; } Dispenser.deliver(amount); newbalance= thisBalanceamount; if(receiptRequired) Receipt.print(amount, newBalance); break; // other service descriptions here default: break; } } while(service !=Service.quit); thisCard.returnToUser(“Please take your card”); } catch(InvalidCard e) { Screen.printmsg (“Invalid card or PIN”); } //other exception handling here }//main() }//ATM
Dokumen Kebutuhan (Requirement Document) Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya.
Dokumen Kebutuhan Sebaiknya Menjelaskan perilaku eksternal sistem Menjelaskan batasan pada implementasi Mudah diubah Sebagai alat referensi untuk pemelihara sistem Mencatat peringatan awal tentang siklus dari sistem Menjelaskan bagaimana sistem merespon halhal yang tidak
Contoh (Pertanyaan Fokus pada Pengertian Permasalahan) Menemukan yang membutuhkan software tersebut : Siapa yang membutuhkan sistem (serta personal di belakangnya) ? Siapa yang akan menggunakan solusi Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik Adakan sumber lain dari solusi yang dibutuhkan Bentuk solusi yang diinginkan : Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan dihasilkan oleh solusi yang benar Masalah-masalah apa yang akan dicarikan solusinya? Lingkungan solusi yang akan digunakan Adakah isu atau kendala khusus yang berdampak kepada solusi Efektifitas : Mendapatkan person yang benar/berhak atas jawaban pertanyaan, Apakah pertanyaan yang diajukan relevan dengan permasalahan Adakah personal lain yang dapat menambah informasi Adakah hal lain yang perlu ditambahkan?
Contoh (Pertanyaan Fokus pada Implementasi Studi Kelayakan ) Apa yang akan terjadi apabila sistem tidak diimplementasikan? Masalah proses apa yang ada ? Apa yang dapat dibantu oleh sistem ? Masalah apa yang akan muncul pada proses Integrasi ? Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ? Fasilitas apa yang harus didukung oleh sistem ?
The End