Requirements Engineering

  1. Pengertian

Requirement Engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana 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 adanya 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 ada;ah 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 tepat waktu dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain(dalam satu famil).

Requirements Engineering membantu para pakar software engineer untuk lebih memahami dalam menyelesaikan masalah yang akan mereka hadapi. Ini mencakup sekumpulan tugas-tugas mengenai sebuah pemahaman dari apa pengaruh bisnis dari software yang akan dipakai,apa yang diinginkan customer(pelanggan) ,dan bagaimana end-users akan berinteraksi dengan siftware.

  1. Latar Belakang
    1. Seringkali pencatatan kebutuhan tidak diorganisasikan dengan baik
    2. Jarang lakukan verifikasi
    3. Proyek dikendalikan oleh perubahan

Studi di Standish Gropu mencatat bahwa prosentase akumulatif kegagalan sebuah project 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- 00]. Ed Yourdon menggunakan istilah “ the rock problem(masalah batu) sebagai diskusi dasar masalah yang selalu muncul dalam proses pengerjaan proyek software.

  1. Langkah-langkah Rekayasa Kebutuhan

Requirements Engineering menyediakan mekanisme untuk memahami keinginan customer, menganalisa kebutuhan , menilai fisibilitas solusi,melakuikan negoisasi pemilihan solusi yang layak , menghilangkan ambiguitas , memvalidasi solusi, mengelola kebutuhan agar dapat diubah ke bentuk sistem operasional.

Langkah-langkah :

a) Inception

b) Elicitation

c) Elaboration

d) Negotiation

e) Specification

f) Validation

g) Management

a) Inception

Adalah sebuah proses yang menetapkan bidang dan sifat dasar dari masalah untuk diatasi.

Pertanyaan pertama ( mengidentifikasi stakeholder)

Ø Siapa yang menginginkan Sistem ?

Ø Siapa yang akan menggunakan solusi tersebut ?

Ø Apa keuntungan ekonomis dari suatu solusi yang sukses ?

Ø Apakah dibutuhkan sumber yang lain untuk ?

Pertanyaan untuk memahami masalah

v Bagaimana karakteristik solusi yang baik?

v Masalah apa yang dipecahkan oleh solusi tersebut ?

v Bagaimana kondisi business environment dimana solusi tersebut

diimplementasikan ?

v Apakah ada masalah performa dan batasan tertentu yang mempengaruhi pendekatan solusi?

Pertanyaan untuk mengukur efektifitas komunikasi

§ Apakah anda orang yang tepat untuk menjawab pertanyaan – pertanyaan ini ?

§ Apakah jawaban anda merupakan jawaban resmi ?

§ Apakah pertanyaan-pertanyaan yang diajukan relevan dengan masalah yang anda hadapi ?

§ Apakah saya mengajukan terlalu banyak pertanyaan ?

§ Apakah orang lain yang bisa melengkapi jawaban anda ?

§ Apakah masih ada hal-hal yang belum saya tanyakan ?

b) 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 sebyah software harus dikembangkan.

Christel dan Kang (CR192) mengidenfifikasi sejumlah masalah yang membantu kita memahami mengapa requirements elicitation itu sulit :

· Problems of scope .

(Masalah-masalah Bidang/jangkauan ).

Batas dari sistem yang tidak jelas atau customer(pelanggan) atau users(pengguna) menentukan teknikal detil yang tidak dibutuhkan yang mungkin membingungkan, daripada menjelaskan sistem objektif secara keseluruhan.

· Problems of Understanding

Pelanggan/pengguna tidak yakin sama sekali dari apa yang dibutuhkan,memiliki sebuah pemahaman yang lemah dari kemampuan dan keterbatasan dari lingkungan perhitungan mereka, tidak memiliki sebuah pemahaman penuh dari masalah utama,memiliki masalah penyampaian harus ke pakar software engineering, mengabaikan informasi yang dipercaya menjadi nyata, menjelaskan kebutuhan yang bertentangan dengan kebutuhan dari pelanggan/pengguna lain ,atau menjelaskan kebutuhan yang ambigu atau tidak teruji.

· Problems of Volatility

Kebutuhan-kebutuhan yang berubah kapanpun.

Untuk membantu mengatasi problem-problem di atas, para pakar requirements engineer harus melakukan pendekatan dengan requirements gathering(pertemuan) pada sebuah tata-cara yang telah diatur. Gap knowledge diharapkan bisa diatasi dengan adanya innteraksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case,dsb.

b) Elaboration

Adalah sebuah tugas yang memperbaiki dan memodifikasi kebutuhan dasar.

Ø Fokus pada model teknis fungsi,fitur dan batasan perangkat lunak.

Ø Skenario pengguna

Ø Proses berhenti jika telah diperoleh landasan yang cukup untuk memulai proses desain

c) Negotiation

Adalah sebuah proses yang mendamaikan konflik diantara customers(pelanggan),users(pengguna),dan stakeholders(manajer bisnis,pengusaha marketing,manajer produksi) lain.

Negoisasi bukanlah suatu kompetisi. Dalam suatu negoisasi diperlukan untuk membuat suatu strategi(Apa yang kita inginkan?Apa yang diinginkan client?). Selain itu harus mendengarkan secara aktif serta fokus pada apa yang menjadi keinginan client. Selain itu jangan anggap personal terhadap masalah-masalah yang timbul,jadilah kreatif dan komitmen terhadap keputusan yang diambil.

d) Specification

Hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan customer,dan merupakan titik start menuju proses berikutnya yaitu software design.

IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practise for Software Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.

e) Validation

Adalah memeriksa spesifikasi untuk memastikan bahwa semua software requirements sudah benar,tidak ambigu atau sudah dimengerti,dan yang tidak konsisten,kelalaian dan error sudah dapat dideteksi dan diperbaiki.

Proses validasi dan verifikasi ini melibatkan customer/user sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.

Sistemasi proses negoisasi pengembang dan customer dalam requirements engineering dibagi dalam 3 proses besar yaitu : elicitation ,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.

TEKNIK – TEKNIK ANALISA KEBUTUHAN

* Wawancara

Pada awal fase, anggota requirements team bertemu dengan anggota dari organisasi/perusahaan untuk menentukan apa saja yang menjadi target pembuatan perangkat lunak.

Jika pada pertemuan pertama dirasa masih kurang,maka dapat dibuat pertemuan-pertemuan berikutnya. Terdapat 2 bentuk wawancara yang dapat dilakukan,yaitu :

1. Structured Interview : menggunakan pertanyaan yang bersifat close-ended yang telah direncanakan

2. Unstructures Interview : menggunakan pertanyaan yang bersifat open – ended dan mendorong orang untuk aktif berbicara.

Setelah sesi wawancara selesai , maka dibuat ringkasan hasil pertemuan yang ditinjukkan pula kepada pihak organisasi/perusahaan agar diverifikasi jika ada kesimpulan yang salah.

* Kuesioner : dilakukan untuk memperoleh pendapat dari orang banyak.

* Form : menganalis berbagai bentuk formulir yang digunakan client.

* Dokumen : menganalisis dokumen-dokumen yang ada pada perusahaan, misalnya dokumen mengenai pembagian tugas ( job description , petunjuk pengoperasian alat,dll)

* Benchmarking : melihat sistem / organisasi lain yang memiliki permasalahan yang sama.

* Pengamatan Lapangan : dilakukan dengan mengamati langsung keadaan di lapangan (dapat juga memantau dengan menggunakan kamera video )

* Skenario : membuat skenario dari hal-hal yang mungkin terjadi dengan membuat serangkaian daftar kegiatan / aktifitas atau dengan menggambar suatu storyboard.

Skenario memiliki beberapa kelebihan :

1. mendemonstrasikan bagaimana sifat produk dengan cara yang dapat dipahami oleh pengguna

2. Klien dan pengguna turut terlibat aktif

3. Skenario sangat berperan dalam tahap analisa berorientasi objek

* Rapid Prototyping : membuat prototype produk untuk memberikan gambaran tentang produk yang akan dibuat. RP memungkinkan tercapainya kesepakatan antara pihak pengembang dan klien dengan segera.

Kunci :

1. RP dibuat secepat mungkin

2. RP dibuat untuk dirubah.

Referensi

§ Pressman, Roger S., Software Engineering : A Practitioner Approach,6th Edition, McGraw-Hill,2005(chapter 7)

§ http://RomiSatrioWahono.Net

§ http://lecturer.ukdw.ac.id/~dito

Oleh : Riskiana Wulan

Email : riskiana@gmail.com

Website : http://riskiana.blogsome.com

http://riskianawulan.tk