10 Perangkap dalam Rekayasa Kebutuhan Perangkat Lunak

Table of Contents
Wiegers (2000) telah mengidentifikasi setidaknya terdapat sepuluh perangkap yang seringkali dihadapi ketika seorang perekayasa menspesifikasikan kebutuhan suatu perangkat lunak. Sepuluh perangkap tersebut antara lain:



Ilustrasi Perangkap dalam Rekayasa Kebutuhan
Perangkap 1 : Bingung tentang yang dimaksud "kebutuhan"
Tiap orang memiliki pandangan berbeda terkait dengan "kebutuhan" sesuai dengan posisinya dalam organisasi. Pemilik sistem atau manajemen memandang kebutuhan sebagai goal yang harus dicapai ketika sistem diimplementasikan. Sementara pengguna akhir memandang kebutuhan sebagai fitur-fitur yang harus tersedia dari suatu sistem yang akan diimplementasikan. Lain lagi dengan pengembang yang memandang kebutuhan sebagai solusi teknis yang harus dibangun. Sehingga ketika kebutuhan dikomunikasikan seringkali terjadi bias atau deviasi. 


Perangkap 2 : Kurangnya keterlibatan pelanggan
Terkadang proses pembuatan kebutuhan berakhir dengan situasi dimana pengembang harus berkutat sendiri menduga dan memahami apa yang diinginkan oleh pelanggan. Pelanggan berasalan enggan terlibat karena keterbatasan waktu, bahkan menganggap pengembang pasti dapat memahami kebutuhan pelanggan terlepas dari minimnya informasi yang diberikan. 

Perangkap 3 : Kebutuhan yang kabur atau ambigu
Kerancuan adalah hal yang susah dihindari ketika menspesifikasikan kebutuhan dalam bahasa alamiah. Kerancuan berakibat pada kaburnya makna suatu kebutuhan. Kerancuan rawan menyebabkan konflik antara pelangga dan pengembang, terutama dalam memahami dan menverifikasi pencapaian pengembang terhadap kebutuhan yang telah ditetapkan di awal. 

Perangkap 4 : Tidak ada prioritas
Seringkali pelanggan menganggap semua kebutuhannya sebagai prioritas utama dan mengabaikan keterbatasan sumber daya, baik waktu maupun dana. Perangkap ini dapat menyebabkan proyek melewati batas waktu maupun anggaran membengkak. 

Perangkap 5 : Membangun fungsionalitas yang tidak digunakan digunakan siapapun
Keluhan yang muncul adalah banyak fitur dari sistem yang sudah dibangun ternyata tidak digunakan oleh pengguna, Penyebabnya adalah (1) pengguna seringkali mengungkapka keinginannya bukan kebutuhannya (2) pengembang seringkali membuat asumsi sendiri akan kebutuhan pelanggan. 

Perangkap 6 : Paralisis Analisis
Pengembang terperangkap pemikiran bahwa proses spesifikasi harus selesai terlebih dahulu sebelum proses berikutnya dapat dilaksanakan. Konflik kebutuhan juga sering menghambat tercapainya kesepakatan akan spesifikasi kebutuhan sistem. Pada akhirnya waktu yang dibutuhkan bagi penghasilan produk menjadi lama, Selalu terlambat.

Perangkap 7 : Scope Creep 
Ketakutan dikalangan pengembang adalah ruang lingkup yang terus-menerus meluas tak terkendali. Sebabnya (1) konsumen tidak tahu apa yang dia inginkan, sehinga tidak ada acuan dasar menetapkan ruang lingkup proyek. (2) kebutuhan yang terus-menerus berubaah. 

Perangkap 8 : Proses perubahan kebutuhan yang tidak memadai 
Banyak proyek perangkat lunak yang mekanisme untuk mengelola perubahan kebutuhan lemah atau bahkan tidak ada sama sekali. Akibatnya, kebutuhan yang sebelumnya tidak disetujui dapat diminta kembali oleh pelanggan dipertemuan berikutnya, 

Perangkap 9 : Analisis dampak perubahan yang tidak memadai
Sadar atau tidak, seringkali pelanggan mengajukan suatu perubahan kebutuhan ditengah jalan yang mempengaruhi arsitektur sistem yang secara luas tidak dapat dicapai atau direalisasikan dengan sumber daya yang ada., hal ini tentu menjerumuskan tim pengembang pada permasalahan serius. 

Perangkap 10 : Kontrol versi yang tidak memadai 
Mengelola perubahan pada dokumen merupakan momok bagi pengembang, pekerjaan administratif ini seringkali dipandang sebagai pekerjaan yang membosankan sehingga dihindari. Akbibat terburuknya, masing-masing pihak (analis sistem, perancang, programmer, penguji, pengguna, dsb) berpegang pada dokumen spesifikasi kebutuhan yang benar tetapi versi yang berbeda-beda. Jika kondisi ini terjadi, berarti chaos

Sumber materi : buku Analisa Kebutuhan dalam Rekayasa Perangkat Lunak oleh Daniel Siahaan. 

Post a Comment