Anda di halaman 1dari 7

REKAYASA KEBUTUHAN (REQUIREMENT ENGINEERING)

Pokok Bahasan: Elisitasi Kebutuhan Perangkat Lunak Spesifikasi Kebutuhan Perangkat Lunak Verifikasi dan Validasi Kebutuhan Perangkat Lunak Pembuatan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) Fuctional Requirement dan Non Functional Requirement Tujuan Pembelajaran: Mampu melakukan proses Elisitasi Kebutuhan Perangkat Lunak Mampu menyusun dokumen Spesifikasi Kebutuhan Perangkat Lunak Mampu menyusun Fuctional Requierement dan Non Functional Requirement

BAB 8

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 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, 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 specificatio) 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 :
2

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

Tabel Ringkasan Kebutuhan Non Fungsional SKPL-Id SKPL-NF001 SKPL-NF002 SKPL-NF003 SKPL-NF004 SKPL-NF005 SKPL-NF006 SKPL-NF007 SKPL-NF008 SKPL-NF009 Keterangan Availability Ketersediaan Aplikasi Untuk Dapat Diakses Oleh Pengguna. Reliability kehandalan aplikasi, termasuk aspek teknis seperti koneksi, kebutuhan hardware. Ergonomy Desain Aplikasi harus disesuaikan dengan kenyamanan pengguna. Portability Keberpindahan Aplikasi, sehingga dapat diakses oleh berbagai device. Memory Kebutuhan Aplikasi akan media penyimpanan. Response time Waktu Aplikasi untuk merespon request dari user. Safety Keamanan data dari aplikasi, serta penggunaan aplikasi. Security Keamanan aplikasi untuk melindungi data di dalamnya. Bahasa komunikasi Media Bahasa yang digunakan oleh aplikasi.

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 Laporan Resmi: Dari hasil elisitasi dengan customer, susun laporan berbentuk tabulasi dengan kolom-kolom sbb : No Nama
4

Kode Deskripsi Prioritas

Perhatikan contoh di bawah ini : Fungsional Requirement (pada proyek M-Trans) No. 1 Nama Input lokasi dan tujuan Kode FR-01 Deskripsi Input asal berupa nama jalan Input tujuan berupa nama jalan atau nama fasilitas umum(rumah sakit, mall, kampus,terminal dll) Output yang dihasilkan berupa rute jalan Contoh : Angkot yang disarankan adalah G1 Joyoboyo Karang Menjangan Rute : Raya Gubeng Kertajaya Menur Karang Menjangan Dharmawangsa Memanfaatkan teknologi GPS untuk mencari lokasi jalan kita berada saat ini Output berupa map yang telah tersimpan dalam database berupa peta jalur yang dilewati angkot. Contoh : Angkot yang disarankan adalah : Angkot 1 : V Joyoboyo Tambakrejo Angkot 2 : G1 Joyoboyo Karang Menjangan Rute 1 : Wijayakusuma Gubeng Pojok Pemuda Panglima Sudirman Urip Sumoharjo Rute 2 : Urip Sumoharjo Dr. Soetomo Adityawarman Brawijaya Prioritas High

Menampilkan output berupa rute jalan

FR-02

High

Mencari lokasi kita dengan GPS Menampilkan Output berupa map Menampilkan Rute Alternatif

FR-03

High

FR-04

Medium

FR-05

Medium

6 7

Menampilkan foto angkot Menampilkan ongkos

FR-06 FR-07

Menampilkan foto angkot yang diminta user Menampilkan biaya yang dibutuhkan

Medium Low

Non Fungsional Requirement No. 1 2 3 Nama Desain Interface yang menarik Petunjuk penggunaan Menampilkan data selluruh angkot Kompatibilitas aplikasi Kode NFR-01 NFR-02 NFR-03 Deskripsi Meyiapkan tampilan yang menarik dan mudah digunakan Menampilkan petunjuk penggunaan aplikasi Menampilkan rute seluruh angkot yang tersimpan di database Aplikasi bias dijalankan di kebanyakan versi android Prioritas High High High

NFR-04

Medium

Contoh lain untuk Non Functional Requirements: SKPL-Id SKPL-NF1 Parameter Availability Kebutuhan Aplikasi ini harus dapat beroperasi terus menerus selama 7 hari per minggu, 24 jam per hari tanpa berhenti, karena aplikasi ini akan bersifat web-based dan akan diakses oleh orang yang membutuhkan dari berbagai tempat pada waktu yang berbedabeda. Aplikasi ini harus dibangun dengan Reliability kehandalan yang setinggi mungkin meskipun tidak perlu setinggi kehandalan sebuah critical application. Kegagalan yang dapat ditoleransi kurang lebih 10%. Dengan kahandalan yang tinggi diharapkan aplikasi ini dapat digunakan dengan baik pada saat dibutuhkan. Aplikasi ini bisa diakses di mana saja di Portability lingkungan ITS dengan menggunakan intranet. Aplikasi membutuhkan security untuk Security mengamankan account. Maintainability Aplikasi harus dapat di-maintain dengan mudah oleh administrator.
6

SKPL-NF2

SKPL-NF3

SKPL-NF4 SKPL-NF5

SKPL-Id SKPL-NF6

Parameter Documentation

SKPL-NF7 SKPL-N03

Interface Ergonomy

SKPL-N04

Portability Memory

SKPL-N05

Response time

SKPL-N06

Security

SKPL-N07 SKPL-N08

Bahasa komunikasi Lain-lain

Kebutuhan Dokumentasi yang berhubungan dengan aplikasi harus jelas dan dapat dilacak sehingga pengembangan di masa mendatang dapat dilakukan dengan mudah. Aplikasi yang dibuat harus memiliki antarmuka yang bersifat user friendly Aplikasi ini harus memiliki nilai ergonomi/ kenyamanan dipakai yang tinggi bagi user. Aplikasi akan dibangun dengan antarmuka user yang mudah dimengerti, indah dilihat, konsisten, mudah dioperasikan dan tidak membingungkan. Aplikasi ini dapat diakses dari manapun selama ada jaringan intenet. 100 megabyte space pada storage disk. Besarnya memori yang dibutuhkan untuk menjalankan aplikasi sebesar 256Mb. Kecepatan Central Processing dan jalur komunikasi dapat untuk 30 on-line user secara simultan. Waktu response 1 detik untuk data entry dan query Ada pengaturan hak akses agar aman. informasi yang diproses harus terjamin aman. data pribadi aman. tempat penyimpanan data fisikal aman Bahasa komunikasi pada user interface menggunakan bahasa Indonesia.