Thursday, September 4, 2014

Proses Rekayasa Kebutuhan

Rekayasa Kebutuhan adalah bagian yang tidak terpisahkan dari kegiatan rekayasa perangkat lunak. Rekayasa kebutuhan mempunyai peran yang cukup penting, bahkan aku menentukan keberhasilan dari suatu proyek rekayasa perangkat lunak.

1.    Feasibity study ( studi kelayakan )

Adalah sebuah analisa dan evaluasi dari proyek yang diusulkan untuk menentukan apakah secara teksis layak, layak dalam perkiraan biaya dan menguntungkan.Semua proyek layak bila sumber dan waktunya tidak terbatas. Kenyataannya, pengembangan sistem berbasis komputer dibatasi oleh sumber dan waktu. 
Ada 4 bidang utama yang menjadi konsentrasi dari feasibility studi, yaitu :

·         Economic Feasibility :
Evaluasi biaya (cost) dan manfaat (benefit) dalam pengembangan sistem.

·         Tehcnical feasibility :
Studi tentang fungsi, performance, dan hambatan yang berpengaruh terhadap kemampuan mendapatkan sistem yang baik.

·         Legal Feasibility :
Penentuan berbagai pelanggaran, kewajiban yang dapat terjadi dari pengembangan sistem.

·         Alternative :
Evaluasi sebagai alternatif untuk mengembangkan system.
Feasibility Report yaitu analisis yang mengevaluasi satu atau lebih langkah-langkah tindakan potensial dan merekomendasikan bagaimana organisasi tersebut harus dilanjutkan. Diperkirakan biaya, mengidentifikasi manfaat yang diharapkan memperkirakan berapa lama proyek akan mengambil dan menguraikan kesulitan potensial.
2.    Requirements Elicitation and Analysis (Analisis Kebutuhan)
Requirements Elicitation and Analysis adalah proses mengumpulkan dan memahami masalah dan kegiatan yang berjalan. Pada proses ini biasanya dilakukan dengan observasi terhadap lingkungan proyek yang akan digarap – termasuk fact gathering, wawancara pada pengguna langsung atau para menajer, dan bisa juga dengan mempelajari alur kerja yang terjadi dari bisnis proses yang berjalan. Biasanya proses ini dilakukan dengan terus menerus dengan jangka waktu tertentu sehingga keselarasan akan pemahaman suatu permasalahan bisa tercapai.
System Models adalah sistem model konseptual yang menggambarkan dan mewakili suatu sistem. Sebuah sistem terdiri dari beberapa pandangan seperti perencanaan, persyaratan, desain, implementasi, penyebaran, struktur, perilaku, input data, dan data tampilan output.
Dalam system model terdapat 2 pendekatan, yaitu:
·         Pendekatan non-arsitektur
terstruktur Sistem Metode Analisis dan Desain (SSADM), memilih bagan struktur untuk deskripsi struktur dan data flow diagram (DFD) untuk deskripsi perilaku.
·         Pendekatan arsitektur
arsitektur sistem menggunakan Bahasa Arsitektur Deskripsi (ADL) baik struktur dan perilaku deskripsi.

3.    Requirements Specification
Adalah akibat langsung dari analisis kebutuhan dan dapat merujuk. Jika seluruh kegiatan dan permasalah yang terjadi pada bisnis proses yang berjalan dimengerti dengan baik, maka software developer akan menkonversikan ke dalam suatu bentuk laporan tertulis yang berisi tentang semua definisi dan spesifikasi dari seluruh kebutuhan yang ada pada bisnis proses yang ada.
User and Systems Requirements
·         User requirement (kebutuhan pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
·         System requirement (kebutuhan sistem)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

4.    Requirements Validation and Verification
Adalah kepastian bahwa suatu produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnyadidentifikasi. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal. 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.
Requirements Document (Dokumen Kebutuhan)
Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA system mengerjakannya.
Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :
·         Menjelaskan perilaku eksternal system
·         menjelaskan batasan pada implementasi
·         mudah diubah
·         sebagai alat referensi untuk pemelihara system
·         mencatat peringatan awal tentang siklus dari system
·         menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal.
IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut :
·      introduction
Ø  purpose of the requirement document
Ø   scope of the product
Ø  definitions, acronyms and abbreviations
Ø  references
Ø  overview of the remainder of the document
·      General description
Ø  product perspective
Ø  product functions
Ø  user characteristics
Ø  general constrains
Ø  assumptions and dependencies
·         appendices
·         index

Sekalipun standar IEEE belumlah ideal tetapi telah memberikan masukan format dokumen yang cukup lengkap. Informasi yang dimasukkan ke dalam dokumen tergantung pada tipe software yang dibangun dan pendekatan yang digunakan untuk membangun software tersebut.

Struktur lain yang bisa digunakan adalah sebagai berikut :
a)      Preface
b)      Introduction
c)       Glossary
d)      User requirements definition
e)      System architecture
f)       System requirements specification
g)      System models
h)      System evolution
i)        Appendices
j)        Index
Kedua struktur sama baiknya dan salah satu dapat digunakan untuk menyusun dokumen kebutuhan.
Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:
·         Sulit mengantisipasi efek dari sistem baru terhadap organisasi
·         Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya
·         Kerja End-user sistem, dan organisasi yang membiayai sistem berbeda requirement
·         Prototype sering dibutuhkan untuk menjelaskan requirement
·         Masalah perbedaan bahasa alami

5 comments: