modul vi
DESCRIPTION
SRSTRANSCRIPT
![Page 1: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/1.jpg)
POLITEKNIK NEGERI MALANG
2015
Rekayasa Perangkat LunakProgram Studi Manajemen dan Teknik Informatika
Retno Damayanti
![Page 2: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/2.jpg)
Rekayasa Perangkat Lunak 2015
MODUL VI
REKAYASA KEBUTUHAN
(REQUIREMENT ENGINEERING)
A. Kompetensi Dasar
1. Mampu melakukan proses Elisitasi Kebutuhan Perangkat Lunak
2. Mampu menyusun dokumen Spesifikasi Kebutuhan Perangkat Lunak
3. Mampu menyusun Fuctional Requierement dan Non Functional Requirement
B. Alokasi Waktu
4 JS (4 x 45 menit)
C. Petunjuk
D. Materi Bahasan
Modul ini membahas materi meliputi:
1. Elisitasi Kebutuhan Perangkat Lunak
2. Spesifikasi Kebutuhan Perangkat Lunak
3. Verifikasi dan Validasi Kebutuhan Perangkat Lunak
4. Pembuatan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL)
5. Fuctional Requirement dan Non Functional Requirement
E. Dasar Teori
Requirements Engineering adalah fase terdepan dari proses rekayasa perangkat
lunak, di mana software requirements (kebutuhan) dari user (pengguna) dan customer
(pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat
bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta
![Page 3: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/3.jpg)
Rekayasa Perangkat Lunak 2015
membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena
adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun
ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan).
Banyak definisi yang diungkapkan oleh para peneliti tentang requirements
engineering. Satu definisi yang cukup jelas dan diterima secara umum adalah yang diuraikan
oleh Pamela Zave [Zave-97]:
Requirements Engineering adalah cabang dari software engineering yang
mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi,
dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor
tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses
evolusinya baik berhubungan dengan masalah waktu maupun dengan
software lain (dalam satu famili).
Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan
sebuah proyek pengembangan software sebagian besar disebabkan oleh masalah
requirements dan spesifikasinya [Standish-94].
Untuk merangkum masalah yang ingin dipecahkan dalam cabang ilmu
requirements engineering, kebanyakan pakar mengamini ungkapan Ed Yourdon dalam
foreword yang ditulisnya untuk buku Managing Software Requirements – A Unified
Approach karya Dean Leffingwell [Leffingwell-00]. Ed Yourdon menggunakan istilah “the
rock problem” (masalah batu) sebagai diskusi dasar masalah yang selalu muncul dalam
proses pengerjaan proyek software.
Customer (pelanggan) yang datang kepada kita untuk mengerjakan sebuah proyek
pengembangan software, adalah ibarat seseorang yang mengatakan kepada kita,
“Tolong buatkan saya batu”. Ketika kita memberikan kepadanya sebuah batu, dia
akan melihatnya sebentar dan mengatakan kepada kita, “Ya terima kasih, tapi
sebenarnya yang saya inginkan adalah sebuah batu kecil berwarna biru”. Dan
ketika kita bawakan untuknya batu kecil berwarna biru, dia mengatakan bahwa
yang diinginkan adalah yang “bentuknya bulat”. Demikian seterusnya proses
iterasi (iteration) terjadi berulangkali sampai akhirnya kita dapatkan yang
sebenarnya diinginkan customer kita adalah “batu pualam kecil berwarna biru”.
Meskipun mungkin sebenarnya bukan “tepat yang diinginkan”, tapi paling tidak
“paling dekat” dengan yang diinginkan customer. Dan mungkin saja terjadi,
![Page 4: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/4.jpg)
Rekayasa Perangkat Lunak 2015
customer kita mengubah pikiran tentang requirements pada saat proses interaksi
dengan pengembang terjadi (dari iterasi pertama yang sekedar batu, sampai iterasi
terakhir yang menghasilkan batu pualam kecil berwarna biru).
Hasil dari fase requirements engineering terdokumentasi dalam SRS (software
requirements specification) atau SKPL (spesifikasi kebutuhan perangkat lunak). SKPL berisi
kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan
customer, dan merupakan titik start menuju proses berikutnya yaitu software design.
Sistemisasi proses negosiasi pengembang dan customer dalam requirements
engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and
verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of
Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi
dengan mengakomodasi adanya feedback dari customer (user). Selengkapnya adalah
sebagai berikut :
1. Requirements Elicitation
Adalah proses mengumpulkan dan memahami requirements dari user. Kadang
masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu
yang dimiliki). Customer adalah expert pada domain yang software-nya ingin
dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst)
adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu
memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap
knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus
menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi
![Page 5: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/5.jpg)
Rekayasa Perangkat Lunak 2015
tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya
adalah interviewing, brainstorming, prototyping, use case, dsb.
2. Requirements Specification
Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam
bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi
yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode
pengembangannya.
3. Requirements Validation and Verification
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar
sudah ditulis. Verification (verifikasi), yaitu proses untuk memastikan bahwa
requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini melibatkan
customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan
requirements.
Tipe Requirements
Kebutuhan (requirements) perangkat lunak seringkali diklasifikasikan ke dalam
dua kategori :
1. Functional Requirements
Merupakan pernyataan tentang sekumpulan layanan/fitur yang harus tersedia
dalam perangkat lunak.
2. Non Functional Requirements
Terkait dengan kendala (constraint) dan kualitas dari perangkat lunak. Kualitas
perangkat lunak adalah sifat atau karakteristik dari sistem yang stakeholders peduli dan
karenanya akan mempengaruhi tingkat kepuasan mereka dengan sistem.
![Page 6: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/6.jpg)
Rekayasa Perangkat Lunak 2015
Tugas Pendahuluan:
1. Temukan the real customer (pelanggan yang sesungguhnya) dari aplikasi yang
akan dibangun.
2. Tentukan target-target yang hendak dicapai dalam proses requirements
engineering yang akan dilakukan.
3. Kembangkan wawasan tentang aplikasi lain yang relevan dengan aplikasi yang
akan dibangun.
4. Lakukan pendefinisian kebutuhan awal dari aplikasi yang akan dibangun, yang
akan dikembangkan melalui proses elisitasi.
Percobaan:
1. Lakukan proses elisitasi terhadap customer (pelanggan) untuk mengumpulkan,
memahami dan menetapkan kebutuhan dari pelanggan.
2. Klasifikasikan daftar kebutuhan pelanggan ke dalam kategori functional
requirements dan non functional requirements.
3. Berikan deskripsi dari masing-masing kebutuhan tersebut.
4. Lakukan proses verifikasi dan validasi kepada pelanggan terhadap spesifikasi
kebutuhan yang telah disusun.
![Page 7: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/7.jpg)
Rekayasa Perangkat Lunak 2015
Laporan Resmi:
Dari hasil elisitasi dengan customer, susun laporan berbentuk tabulasi dengan
kolom-kolom sbb :
No
Nama
Kode
Deskripsi
Prioritas
![Page 8: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/8.jpg)
Rekayasa Perangkat Lunak 2015
![Page 9: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/9.jpg)
Rekayasa Perangkat Lunak 2015
![Page 10: MODUL VI](https://reader036.vdokumen.com/reader036/viewer/2022083018/577c804f1a28abe054a81e65/html5/thumbnails/10.jpg)
Rekayasa Perangkat Lunak 2015