Pertemuan 5 Rekayasa Perangkat Lunak

Presentasi berjudul: "Pertemuan 5 Rekayasa Perangkat Lunak"— Transcript presentasi:

1 Pertemuan 5 Rekayasa Perangkat Lunak
Requirement Pertemuan 5 Rekayasa Perangkat Lunak

2 Definisi Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan­batasan dari sistem dan bisa juga berupa definisi matematis fungsi­fungsi sistem.

3 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.

4 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.

5 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 hal­hal yang mungkin jadi masalah

6 Macam Requirement (1) User Requirement (kebutuhan pengguna) : Pernyataan tentang layanan yang disediakan sistem dan tentang batasan­batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah. System Requirement (kebutuhan sistem) : Sekumpulan layanan/kemampuan sistem dan batasan­batasannya 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.

7 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 masing­masing memberi pengertian ke pihak yang berbeda kepentingan.

8 Pembaca Requirement

9 Masalah dalam Pendefinisian Requirement
Sulit mengantisipasi efek dari sistem baru terhadap organisasi. Beda user, beda pula requirement dan prioritasnya terpengaruh cara atau gaya kerja. End­user sistem, dan organisasi yang membiayai sistem berbeda requirement. Prototype sering dibutuhkan untuk menjelaskan requirement Masalah perbedaan bahasa alami

10 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 situasi­situasi tertentu. Menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku.

11 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 di­set sejak awal, dan bisa menerima perubahan dengan otoritas khusus Harus komplit (kebutuhan layanan jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan)

12 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

13 Kategori Software System Requirement (2)
Non­functional Requirement Secara umum berisi batasan­batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar­standar tertentu.

14 Cakupan Non­Functional Requirement

15 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.

16 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.

17 User Requirement Menggambarkan functional dan non­functional 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.

18 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.

19 Mengurangi Kesalahpahaman User Requirement
Buatlah format yang standar untuk penulisan. Format ini untuk mengurangi hal­hal yang tidak perlu dan mudah untuk diperiksa kembali. Menggunakan bahasa yang konsisten, istilah­istilah yang konsisten sehinga mudah dikuti. Gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting untuk beberapa istilah atau penjelasan. Hindari istilah­istilah teknis komputer yang tidak dimengerti oleh user. Jika terpaksa menggunakan, buatlah daftar istilah dan artinya sehingga mudah diikuti oleh user.

20 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 data­flow. 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)

21 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= thisBalance­amount; 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

22 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.

23

24 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 hal­hal yang tidak

25 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?

26 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 ?

27 The End