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.

Manager klien
end-user sistem
User requirement staff ahli klien
manager developer
arsitek sistem

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

Staff ahli klien

Software specification arsitek sistem
tim developer

Gambar 1: jenis 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

2
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

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

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