Dokumen ini membahas tentang rekayasa kebutuhan perangkat lunak, meliputi pengertian, tujuan, jenis kebutuhan, stakeholder, permasalahan dan outline standar IEEE untuk spesifikasi kebutuhan perangkat lunak. Dibahas pula tingkatan kebutuhan mulai dari bisnis, pengguna, fungsional hingga sistem dan atribut kualitas. Studi kasus digunakan untuk memperjelas konsep.

1. Rekayasa Kebutuhan Perangkat Lunak
Sherly Christina, S.Kom., M.Kom

2. Materi
• Pengertian Rekayasa Kebutuhan PL
• Mengapa perlu Rekayasa Kebutuhan PL
• Stakeholder
• Tipe Kebutuhan Perangkat Lunak
• Outline SKPL-IEEE 830-1998
• Studi Kasus

3. Pengertian
• Requirements are a specification of what
should be implemented. (Sommerville and
Sawyer, 1997)

4. Pengertian
• Investigating and describing the problem
domain and requirements and designing and
documenting the characteristics for a solution
system that will meet those requirements (Ian
K. Bray, An Introduction to Requirements
Engineering, 2002)

5. Pengertian
• Investigasi dan identifikasi
• Komunikasi dan dokumentasi
– Atribut/Properti/Karakteristik, Kapabilitas,
Kualitas, dan Batasan‐batasan yang Penting.
– Agar memiliki nilai dan kegunaan bagi pengguna
(user)

6. Mengapa perlu Rekayasa Kebutuhan PL

7. Stakeholder
• Stakeholder adalah setiap pihak yang memiliki
kepentingan terhadap sesuatu.
• Sesuatu dalam konteks perangkat lunak
adalah proyek pengembangan perangkat
lunak itu sendiri
–Yang termasuk stakeholder : Pelanggan,
Regulator, Penyelia, Pengembang

8. Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak
• Stakeholder sering tidak mengetahui apa yang
diinginkan dan mengungkapkan keinginannya dalam
kalimat yang umum.
• Stakeholder mengungkapkan permintaan dalam istilah
bidang pekerjaannya, sehingga perekayasa kebutuhan
yang tidak memiliki pengalaman di bidang kerja
pemesan harus memahami permintaan tersebut.
• Beberapa stakeholder memiliki permintaan yang
berbeda‐beda yang dinyatakan dalam cara yang
berbeda pula.
• Faktor politik dapat mempengaruhi kebutuhan sistem.
• Lingkungan bisnis dan ekonomi bersifat dinamis.

9. Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak

10. Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak

11. Tipe Kebutuhan
Kebutuhan dapat dibedakan menjadi:
• Kebutuhan fungsional, yang mendeskripsikan
layanan‐layanan atau fungsi‐fungsi dari sistem
• Kebutuhan non‐fungsional, yang merupakan
batasan‐batasan pada sistem atau pada
proses pengembangan sistem

12. Tingkatan dalam Kebutuhan

13. Kebutuhan Bisnis
• Tujuan tingkat tinggi dari organisasi
• Biasanya berasal dari penyandang dana atau
pemilik sistem
• Mendeskripsikan Mengapa organisasi
menginginkan pengimplementasian sistem
bersangkutan.
– Contoh:Universitas: Meningkatkan efisiensi selama
proses registrasi kuliah.
– Perusahaan: Mengurangi biaya tak perlu, memonitor
kinerja setiap waktu.

14. Kebutuhan Pengguna
• Goal atau tugas pengguna yang harus dapat
dilaksanakan menggunakan produk
bersangkutan.
–Contoh:FRS‐Online: memilih mata kuliah,
mengajukan persetujuan, menampilkan latar
belakang mahasiswa.
– Online Ticketing: memesan tiket, mengecek
jadwal, memesan tempat duduk.

15. Kebutuhan Fungsional
• Fungsionalitas perangkat lunak
• Kebutuhan perilaku
• Gunakan kata “akan” (shall)
–Contoh:FRS‐Online: “The system shall view a
confirmation to the student.”
– Online Ticketing: “The system shall provide a link
to download an softcopy ticket.”

16. Kebutuhan Sistem
• Kebutuhan tingkat atas dari sebuah sistem
yang terdiri dari sub sistem ganda
• Sistem terdiri dari: : Hardware + Software +
Brainware

17. Aturan Bisnis/Constraint
• Termasuk:
– Corporate policies
– Government regulations
– Industry standards
– Accounting practices
– Computational algorithm
• Ada di luar sistem
• Fungsi:Membatasi siapa dan bagaimana melakukan suatu use cases
tertentu
• Mendikte fungsionalitas yang harus dimiliki suatu sistem agar comply
dengan aturan‐aturan yang sudah berlaku
• Gunakan sebagai atribut kualitas.
– Contohs:Sistem perbankan: Semua kartu kredit harus menggunakan smart
card.”
– SIAK: Suatu kartu ID harus sesuai dengan KepMen No. 80/2005.”

18. Atribut Kualitas
• Termasuk goal dan deskripsi dari kinerja
Contoh:
– Usability: “The system is equipped with user manual.”
– Portability: “The system shall work in Microsoft‐OSs
and Unix‐OS.”
– Integrity: “The system shall restrict access for
un‐authorized user.”
– Efficiency: “The system shall work with maximum
200VA/hour.”
– Robustness: “The system shall withstand 5.1
atmoshpere pressure.”

19. Tujuan Dokumen Spesifikasi
• Menyediakan umpan balik kepada konsumen.
• Memecah permasalahan ke dalam
komponen‐komponen yang lebih kecil.
• Merupakan masukan untuk tahap spesifikasi
rancangan.
• Bisa melakukan pengecekan validasi produk.

20. Outline SKPL-IEEE 830-1998

21. Studi Kasus
• Website Perpustakaan
• Game Belajar Berhitung
Buat komponen SKPL berikut:
1. Deskripsi Umum produk
2. Fungsi Produk
3. Karakteristik Pengguna