Reza Al Fajri NIM. 121020220008 1 Nama : Reza Al Fajri
NIM : 121020220008
Tugas Rekayasa Perangkat Lunak A. Requirement document
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.
B. Requirement
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.
1. Requirement berfungsi ganda yaitu:
a) Menjadi dasar penawaran suatu kontrak --> harus terbuka untuk masukan
b) --> harus didefinisikan secara detil
Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan, layanan
dan batasan tersebut disebut Requirement Engineering.
2. Pengumpulan requirement
a) Interviews : Memberi informasi yang terbaik,mahal;
b) Questionnaires : Bagus jika banyak orang terlibat dan tersebar, respon cenderung
kurang baik;
c) Observation : Akurat jika dilakukan dengan baik, mahal;
d) Searching : Informasi terbatas, cenderung tidak menampilkan hal-hal yang
mungkin jadi masalah;
3. Beberapa macam requirement
a) User requirement (kebutuhan pengguna)
1. Pernyataan tentang layanan yang disediakan sistem dan tentang batasan batasan
operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat
dimengerti dengan mudah.
b) System requirement (kebutuhan sistem)
1. Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara
Reza Al Fajri NIM. 121020220008 2 (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku
sebagai kontrak antara klien dan pembangun.
c) A software design specification (spesifikasi rancangan PL)
1. Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan
implementasi yang lebih detil.
C. 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.
1. Masalah dalam menyiapkan user req adalah:
a) Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat dokumen jadi sulit
dibaca
b) -jenis req, kadang jadi sulit dibedakan
c)
2. 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 memenuhi 6 hal berikut :
1. menjelaskan perilaku eksternal system;
2. menjelaskan batasan pada implementasi;
3. mudah diubah;
4. sebagai alat referensi untuk pemelihara system;
5. mencatat peringatan awal tentang siklus dari system;
6. menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal;
IEEE (Institute of Electrical and Electronics Engineers) merupakan organisasi non-profit yang
mendedikasikan kerja kerasnya demi kemajuan teknologi. menyarankan standar struktur dari
Reza Al Fajri NIM. 121020220008 3 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
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. appendices
4. 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
Reza Al Fajri NIM. 121020220008 4 Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:
a. Sulit mengantisipasi efek dari sistem baru terhadap organisasi
b. Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya kerja
c. End-user sistem, dan organisasi yang membiayai sistem berbeda requirement
d. Prototype sering dibutuhkan untuk menjelaskan requirement
e. Masalah perbedaan bahasa alami
D. Functional requirement dan Non-functional Requirement
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 system
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:
a. Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari
informasi tentang buku
b.
c. Sistem mampu catat transaksi peminjaman, pengembalian dan denda secara lengkap
d. Hari libur bisa di-set sejak awal, dan bisa menerima perubahan dengan otoritas khusus
e. 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 system
Reza Al Fajri NIM. 121020220008 5 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. 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 masingmasing profil /account, bahasa pemrograman yang digunakan, system operasi
yang digunakan.
Sesuai dengan 2 penjelasan di atas, non functional requirement dibagi menjadi 3 tipe
yaitu :
a) Product req. berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas
memori yang dibutuhkan dan efisiensi system;
b) Organisational req. berkaitan dengan standar, bahasa pemrograman dan metode
rancangan yang digunakan;
c) 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
