BBAABB 88

RREEKKAAYYAASSAA KKEEBBUUTTUUHHAANN

((RREEQQUUIIRREEMMEENNTT EENNGGIINNEEEERRIINNGG))

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

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].

2

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 :

3

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

4

Tabel Ringkasan Kebutuhan Non Fungsional

SKPL-Id Keterangan

SKPL-NF001 Availability – Ketersediaan Aplikasi Untuk Dapat Diakses Oleh

Pengguna.

SKPL-NF002 Reliability – kehandalan aplikasi, termasuk aspek teknis seperti

koneksi, kebutuhan hardware.

SKPL-NF003 Ergonomy – Desain Aplikasi harus disesuaikan dengan kenyamanan

pengguna.

SKPL-NF004 Portability – Keberpindahan Aplikasi, sehingga dapat diakses oleh

berbagai device.

SKPL-NF005 Memory – Kebutuhan Aplikasi akan media penyimpanan.

SKPL-NF006 Response time – Waktu Aplikasi untuk merespon request dari user.

SKPL-NF007 Safety – Keamanan data dari aplikasi, serta penggunaan aplikasi.

SKPL-NF008 Security – Keamanan aplikasi untuk melindungi data di dalamnya.

SKPL-NF009 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

5

Kode

Deskripsi

Prioritas

Perhatikan contoh di bawah ini :

Fungsional Requirement (pada proyek M-Trans)

No. Nama Kode Deskripsi Prioritas

1 Input lokasi dan

tujuan

FR-01 Input asal berupa nama

jalan

Input tujuan berupa nama

jalan atau nama fasilitas

umum(rumah sakit, mall,

kampus,terminal dll)

High

2 Menampilkan

output berupa

rute jalan

FR-02 Output yang dihasilkan berupa

rute jalan

Contoh :

Angkot yang disarankan adalah

G1 Joyoboyo – Karang

Menjangan

Rute : Raya Gubeng – Kertajaya

– Menur – Karang Menjangan –

Dharmawangsa

High

3 Mencari lokasi

kita dengan

GPS

FR-03 Memanfaatkan teknologi GPS

untuk mencari lokasi jalan kita

berada saat ini

High

4 Menampilkan

Output berupa

map

FR-04 Output berupa map yang telah

tersimpan dalam database berupa

peta jalur yang dilewati angkot.

Medium

5 Menampilkan

Rute Alternatif

FR-05 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

Medium

6

6 Menampilkan

foto angkot

FR-06 Menampilkan foto angkot yang

diminta user

Medium

7 Menampilkan

ongkos

FR-07 Menampilkan biaya yang

dibutuhkan

Low

Non Fungsional Requirement

No. Nama Kode Deskripsi Prioritas

1 Desain Interface

yang menarik

NFR-01 Meyiapkan tampilan yang

menarik dan mudah digunakan

High

2 Petunjuk

penggunaan

NFR-02 Menampilkan petunjuk

penggunaan aplikasi

High

3 Menampilkan

data selluruh

angkot

NFR-03 Menampilkan rute seluruh angkot

yang tersimpan di database

High

4 Kompatibilitas

aplikasi

NFR-04 Aplikasi bias dijalankan di

kebanyakan versi android

Medium

Contoh lain untuk Non Functional Requirements:

SKPL-Id Parameter Kebutuhan

SKPL-NF1 Availability 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 berbeda-

beda.

SKPL-NF2 Reliability Aplikasi ini harus dibangun dengan

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.

SKPL-NF3 Portability Aplikasi ini bisa diakses di mana saja di

lingkungan ITS dengan menggunakan

intranet.

SKPL-NF4 Security Aplikasi membutuhkan security untuk

mengamankan account.

SKPL-NF5 Maintainability Aplikasi harus dapat di-maintain dengan

mudah oleh administrator.

7

SKPL-Id Parameter Kebutuhan

SKPL-NF6 Documentation Dokumentasi yang berhubungan dengan

aplikasi harus jelas dan dapat dilacak

sehingga pengembangan di masa mendatang

dapat dilakukan dengan mudah.

SKPL-NF7 Interface Aplikasi yang dibuat harus memiliki

antarmuka yang bersifat user friendly

SKPL-N03 Ergonomy 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.

SKPL-N04 Portability Aplikasi ini dapat diakses dari manapun

selama ada jaringan intenet.

Memory 100 megabyte space pada storage disk.

Besarnya memori yang dibutuhkan untuk

menjalankan aplikasi sebesar 256Mb.

SKPL-N05 Response time Kecepatan Central Processing dan jalur

komunikasi dapat untuk 30 on-line user

secara simultan. Waktu response 1 detik

untuk data entry dan query

SKPL-N06 Security Ada pengaturan hak akses agar aman.

informasi yang diproses harus terjamin

aman. data pribadi aman. tempat

penyimpanan data fisikal aman

SKPL-N07 Bahasa

komunikasi

Bahasa komunikasi pada user interface

menggunakan bahasa Indonesia.

SKPL-N08 Lain-lain