Anda di halaman 1dari 8

Rekayasa Perangkat Lunak Teknik Informatika UKDW

Software Requirement Disiapkan oleh: Umi Proboyekti, S.Kom, MLIS

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

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

Beberapa macam requirement

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.

1

Rekayasa Perangkat Lunak Teknik Informatika UKDW

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. 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. Pembaca dari ketiga requirement tersebut bisa dijelaskan dengan gambar 1.

User requirement
User requirement

Manager klien end-user sistem

staff ahli klien manager developer arsitek sistemgambar 1. User requirement Manager klien end-user sistem System requirement Software specification End-user

System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli
System requirement Software specification
System requirement
Software specification
System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli klien
System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli klien
System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli klien
System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli klien
System requirement Software specification End-user sistem staff ahli klien arsitek sistem tim developer Staff ahli klien

End-user sistem staff ahli klien arsitek sistem tim developerSystem requirement Software specification Staff ahli klien arsitek sistem tim developer 2 Gambar 1: jenis requirement

Staff ahli klien arsitek sistem tim developersistem staff ahli klien arsitek sistem tim developer 2 Gambar 1: jenis requirement dan pembacanya Masalah

2

developer Staff ahli klien arsitek sistem tim developer 2 Gambar 1: jenis requirement dan pembacanya Masalah

Gambar 1: jenis requirement dan pembacanya

Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:

Sulit mengantisipasi efek dari sistem baru terhadap organisasi

Prototype sering dibutuhkan untuk menjelaskan requirement

Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya kerja

End-user sistem, dan organisasi yang membiayai sistem berbeda requirement

Rekayasa Perangkat Lunak Teknik Informatika UKDW

Masalah perbedaan bahasa alami

Software system requirement sering dibedakan dalam 2 katagori yaitu Functional requirement, Non Functional requirement dan domain requirement dengan masing-masing penjelasannya sebagai berikut:

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-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 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)

Masalah yang mungkin terjadi dalam menyusun functional requirement adalah:

1. Diintepretasikan/diartikan berbeda oleh user atau developer

2. Hasil intepretasi sering tidak menjawab kebutuhan klien

3. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem

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

3

Rekayasa Perangkat Lunak Teknik Informatika UKDW

Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 2: Cakupan dari Non-Functional requirement Karena berkaitan dengan

Gambar 2: Cakupan dari Non-Functional requirement

Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa pemrograman yang digunakan, sistem operasi yang digunakan.

Sesuai dengan gambar 2 di atas, non functional requirement dibagi menjadi 3 tipe yaitu:

1. Product req. berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem

2. Organisational req. berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan.

3. External req. berkaitan dengan masalah etika penggunaan, interoperabilitas

dengan sistem lain, legalitas, dan privasi.

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 non-functional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User

4

Rekayasa Perangkat Lunak Teknik Informatika UKDW

requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana. Masalah dalam menyiapkan user req 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 kesalahpahaman ketika menulis user req. berikut ini beberapa

petunjuk yang bisa diikuti:

1. buatlah format yang standar untuk penulisan. Format ini untuk mengurangi hal-hal yang tidak perlu dan mudah untuk diperiksa kembali.

2. menggunakan bahasa yang konsisten, istilah-istilah yang konsisten sehinga muda dikuti.

3. gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting untuk beberapa istilah atau penjelasan.

4. 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 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. Untuk itu bahasa yang lebih spesifik dan bersifat teknis dapat digunakan, seperti misalnya PDL (Program Description Language) seperti contoh pada gambar 2. PDL digunakan untuk menggambarkan kebutuhan secara operasional dan sifatnya sangat dekat dengan implementasi program.

5

Rekayasa Perangkat Lunak Teknik Informatika UKDW

Class ATM { //declaration here public state void main(string args[]) throws InvalidCard { try { thisCard.read(); //may throw InvalidCard exception 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

Gambar 3: Contoh PDL menjelaskan salah satu fungsi 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. Pengguna dari dokumen kebutuhan adalah pihak-pihak yang dijelaskan pada Gambar 4 yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut.

6

Rekayasa Perangkat Lunak Teknik Informatika UKDW

Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya
Rekayasa Perangkat Lunak Teknik Informatika UKDW Gambar 4: Pengguna dari dokumen requirement Dokumen kebutuhan sebaiknya

Gambar 4: Pengguna dari dokumen requirement

Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :

1. menjelaskan perilaku eksternal sistem

2. menjelaskan batasan pada implementasi

3. mudah diubah

4. sebagai alat referensi untuk pemelihara sistem

5. mencatat peringatan awal tentang siklus dari sistem

6. menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal

IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut :

1.

introduction

1.1

purpose of the requirement document

1.2

scope of the product

1.3

definitions, acronyms and abbreviations

1.4

references

1.5

overview of the remainder of the document

7

Rekayasa Perangkat Lunak Teknik Informatika UKDW

2.

General description

2.1

product perspective

2.2

product functions

2.3

user characteristics

2.4

general constrains

2.5

assumptions and depedencies

3.

Specific requirement covering functional, non-functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organisationa practice, it is not appropriate to define standard structure for this section. The requirements may document external interfaces, describe syste functionality and performancce, specify logical database requirements, dsign constraints, emergent system properties and quality characteristics.

4.

appendices

5.

index

Sekalipun standar IEEE belumlah ideal tetapi telah memberikan masukan format

dokumen yang cukup lengkap. Informasi yang dimasukkan ke dalam dokumen

tergantung pada tipe software yang dibangun dan pendekatan yang digunakan untuk membangun software tersebut. Struktur lain yang bisa digunakan adalah sebagai berikut :

1. Preface

2. Introduction

3. Glossary

4. User requirements definition

5. System architecture

6. System requirements specification

7. System models

8. System evolution

9. Appendices

10. Index

Kedua struktur sama baiknya dan salah satu dapat digunakan untuk menyusun dokumen kebutuhan.

Diadaptasi dari:

Sommerville, Ian. "Software Engineering" .6th . Addison Wesley. 2001

8