PERSYARATAN PERANGKAT LUNAK Kuliah 4 Rianto Rekayasa Perangkat

PERSYARATAN PERANGKAT LUNAK Kuliah - 4 Rianto Rekayasa Perangkat Lunak Teknik Informatika - Universitas Siliwangi

Software Requirement Ø 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, ini pun disebut requirement.

Ø Definisi Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Ø Requirement berfungsi ganda yaitu: § Menjadi dasar penawaran suatu kontrak : harus terbuka untuk masukan § Menjadi dasar kontrak : harus didefinisikan secara detil Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan dan batasan tersebut disebut Requirement Engineering.

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

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

Macam Requirement 3. A software design specification (spesifikasi rancangan PL) Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

Gambar Macam requirement dan pembacanya

Ø Masalah yang mungkin terjadi dalam pendefinisian requirement adalah: § 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

Software 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. Selain itu kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan:

§ Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari informasi tentang buku § Semua peminjam memiliki pengenal yang unik § Sistem mampu catat transaksi peminjaman, pengembalian 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)

Ø Masalah yang mungkin terjadi dalam menyusun functional requirement adalah: a. Diintepretasikan/diartikan berbeda oleh user atau developer b. Hasil intepretasi sering tidak menjawab kebutuhan klien c. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem d. Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan

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.

Non Fungsional Requirement § 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.

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. Ø Masalah dalam menyiapkan user requirement adalah : § Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat dokumen jadi sulit dibaca § Jenis-jenis req, kadang jadi sulit dibedakan § 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. Ø Untuk mengurangi kesalah pahaman ketika menulis user requirement berikut ini beberapa petunjuk yang bisa diikuti: a. Buatlah format yang standar untuk penulisan. Format ini untuk mengurangi hal-hal yang tidak perlu dan mudah untuk diperiksa kembali.

b. Menggunakan bahasa yang konsisten, istilah-istilah yang konsisten sehinga mudah dikuti. c. Gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting untuk beberapa istilah atau penjelasan. d. Hindari istilah-istilah 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 bisa terdiri dari macam model sistem seperti model object atau model data-flow. System requirement menyatakan apa yang harus dikerjakan sistem, dan bukan bagaimana sistem diimplementasikan.

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. Ø Pengguna dari dokumen kebutuhan adalah pihak yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut. Ø Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :

1. 2. 3. 4. 5. 6. 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 biasa/normal

Contoh Dokumen Kebutuhan IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut : 1. Pendahuluan 1. 1. Tujuan Dokumen Persyaratan 1. 2. Cakupan Produk 1. 3. Definisi, Akronim dan Singkatan 1. 4. Referensi 1. 5. Tinjauan Bagian Dokumen Berikutnya 2. Deskripsi Umum 2. 1. Perspektif Umum 2. 2. Fungsi Produk 2. 3. Karakteristik User 2. 4. Batasan-Batasan Umum 2. 5. Asumsi dan Ketergantungan 3. Persyaratan Khusus: mencakup persyaratan fungsional, non-fungsional, dan interface. 4. Lampiran 5. Indeks

Terima Kasih Rianto