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
This comment has been removed by the author.
ReplyDeleteTerima kasih gan
ReplyDeleteMy blog
TERIMA KASIH ATAS TULISANNYA SANGAT MEMBANTU
ReplyDeleteTerimakasih, sangat bermanfaat
ReplyDeletethank you
ReplyDeleteMy blog