1. DEFINISI REKAYASA KEBUTUHAN
2. KEGIATAN REKAYASA KEBUTUHAN
Merupakan proses menetapkan layanan yang dibutuhkan konsumen terhadap sistem dan batasan operasi dan pengembangan, kebutuhan sendiri adalah diskripsi layanan sistem dan batasan yang dibangkitkan selama proses rekayasa kebutuhan.
Kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan)
Beberapa hukum requirement enginnering diantaranya
Beberapa hukum requirement enginnering diantaranya
- Hukum Glass (Robert Glass)
Menentukan kebutuhan yang tepat merupakan masalah berat. Kekurangan kebutuhan (requirement deficiences) adalah sumber utama dari kegagalan proyek. Kekurangan kebutuhan menimbulkan masalah di banyak proyek.
- Hukum Boehm Pertama
Kesalahan yang paling sering selama menentukan kebutuhan (requirements) adalah kegiatan desain yang lebih mahal. Studi ini berkaitan dengan analisis kesalahan yang dibuat oleh pengembang.
- Hukum Boehm kedua
Prototyping (secara signifikan) mengurangi kebutuhan dan kesalahan desain, terutama untuk user interface. Hukum ini menempatkan penekanan pada pengurangan kesalahan. Pengurangan kesalahan membawa penurunan biaya juga.
- Hukum Davis
Nilai dari sebuah model tergantung pada pandangan diambil, tetapi tidak ada yang terbaik untuk semua tujuan. Sebuah model dari realitas membantu untuk menjelaskan pemahaman.
2. KEGIATAN REKAYASA KEBUTUHAN
- Studi Kelayakan atau analisis risiko
Studi kelayakan perlu dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, mendapatkan jawaban atas memenuhi kebutuhan sesuai pengetahuan dan teknologi, mempertanyakan biaya yang memadai dari pengembangan kebutuhan.
- Pengungkapan Kebutuhan dan Prioritas (Requirements elicitation and prioritization)
Kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi. Kontribusi terutama dari calon pelanggan dan pengguna. Selain itu, pihak ketiga ahli hukum yang berwenang, dan badan standar mungkin memiliki masukan. Namun, Kebutuhan yang diharapkan pengguna harus mendapatkan prioritas utama. Oleh karena itu, harus dipahami siapa pengguna, dan apa keterampilan mereka, motivasi dan lingkungan kerja.
Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.
- Spesifikasi kebutuhan
a. Kebutuhan fungsional : Menyatakan prilaku yang harus ada pada sistem.
Ex. pembelian mobil utuk pengiriman barang ke gudang, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang ke gudang.
Ex. pembelian mobil utuk pengiriman barang ke gudang, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang ke gudang.
b. Kebutuhan non fungsional : Batasan yang harus ada pada sistem dan bagaimana dalam membentuk sistem tersebut.
Batasan dapat dibagi menjadi dua sub katagori yakni:
- Performance constraint, batasan ini menunjukan spesifikasi bagaimana sistem bekerja ketika kebutuhan funsional telah bekerja. Ex. pada mobil yang mengangkut barang diatas adalah batasan bahwa minimal daya angkut pada mobil harus lebih dari satu ton.
- Development constraint, batasan ini menunjukan sebagai pelengkap dari performance constraint. Batasan ini lebih cenderung pada batasan pada level manajemen proyek . Contoh rincian dari waktu , resource, quality.
- Penerimaan, Validasi dan Persetujuan Kebutuhan
Cara terbaik untuk mencapai ini adalah melalui partisipasi pengguna, selalu dimulai dengan definisi kebutuhan. User harus menerima kebutuhan, yakni mempertimbangkan kebutuhan sebagai milik mereka.
Setelah didapat suatu kebutuhan yang teranalisa maka memvalidasi kembali dan meperbaiki apa yang menjadi kekurangan. Meliputi proses identifikasi, menyakin kan kembali, menanggapi dan memperbaiki masalah dari requirements, dan menyatakan bahwa requirement telah dapat diterima.
.jpg)
