Study Kasus Faulty Requirement Definition

Pengertian Faulty Requirement Definition

Salah satu penyebab error pada software adalah Faulty Requirement Definition (Kesalahan Definisi Kebutuhan). Faulty Requirement Definition ini biasanya dibuat oleh klien. Error paling umum dari jenis ini adalah :

• Erroneous definition of requirements. 
• Tidak adanya persyaratan penting.
• Ketidaklengkapannya ketentuan dari persyaratan. Misalnya, salah satu persyaratan dari sistem software pajak lokal kotamadya mengacu diskon diberikan kepada berbagai segmen penduduk: warga senior, orang tua dari keluarga besar, dan sebagainya. Namun, diskon yang diberikan kepada siswa tidak termasuk dalam dokumen persyaratan.
• Pencantuman persyaratan yang tidak perlu, fungsi yang tidak diharapkan atau diperlukan dalam waktu dekat

Studi Kasus Faulty Requirement Definition

"Kegagalan Sistem Field Data Collection Automation"

Pada sensus penduduk tahun 2000 ke bawah, Biro Sensus Amerika Serikat telah mengimplementasikan system perangkat lunak TIGER (Topologically Integrated Geographic Encoding and Referencing). System ini menyediakan data lengkap mengenai alamat penduduk beserta wilayah geografisnya seperti peta jalan, badan air, kerata api, dll. Sehingga, Biro Sensus hanya perlu mengirimkan surat ke seluruh penduduk amerika serikat via Pos dengan data alamat yang didapat pada TIGER. Penduduk Amerika Serikat mengembalikan surat sensus yang telah diisi ke Biro Sensus melalui Pos juga. Petugas Sensus hanya mendatangi rumah penduduk untuk melakukan pengambilan data hanya pada penduduk yang tidak mengirim feedback. Proses ini berjalan dengan sukses, namun dirasa kurang efektif, karena justru melibatkan banyak pihak di luar biro sensus, seperti Pos dan Industri system Informasi Geografis.

Pada tahun 2000, Biro Sensus Amerika Serikat berinisiatif untuk melakukan gebrakan metode sensus penduduk dengan menggunakan system FDCA (Field Data Collection Automation) dengan proyek yang dipesan ke perusahaan Harris Corporation.

FDCA merupakan sistem mobile yang akan memungkinkan enumerator bekerja di lapangan untuk mengumpulkan dan mengirimkan data kembali ke kantor, sehingga dapat mengotomatisasi pengumpulan data lapangan. Proses kerjanya adalah, dengan software FDCA ini, para petugas sensus mendatangi penduduk untuk melakukan wawancara, dan data langsung diinputkan ke Sistem FDCA ini secara mobile menggunakan hardware yang disediakan. Sehingga data akan langsung masuk ke server pada saat itu juga. Biro merencanakan untuk menggunakan sistem ini tidak hanya untuk mengumpulkan dan mengirimkan data selama menyisir dan wawancara, tetapi juga untuk mengelola operasi lapangan dan terintegrasi juga dengan TIGER. Sehingga, dengan adanya Software FDCA ini, data hasil wawancara langsung dapat diterima pusat dan diolah secara otomatis untuk menghasilkan informasi yang diperlukan dengan waktu yang singkat dan efisien.

Pada 1 Mei 2008, Sistem ini diuji coba untuk melakukan sensus penduduk, namun hasil penelitian menunjukkan bahwa komputer genggam bergerak lambat, kadang-kadang membeku, dan tidak mengirimkan data secara konsisten. Selain itu, tes menunjukkan masalah dengan program yang dirancang untuk mengelola operasi di lapangan. Biro tersebut mengumumkan bahwa mereka akan perlu untuk memperpanjang jadwal pengembangan software ini dan mengalokasikan dana lebih jauh untuk menyelesaikan proyek. Pada bulan Agustus 2009, diumumkan bahwa enumerator akan menurunkan penggunaan perangkat mobile dengan system FDCA ini selama proses wawancara dan bergantung secara eksklusif pada operasi berbasis kertas. Kontrak baru hanya akan mengimplementasikan untuk update alamat berbasis genggam, dan bahkan dengan ruang lingkup sangat berkurang, biayanya adalah $ 200 juta lebih tinggi dari anggaran asli untuk seluruh system.

Kantor Government Accountability Officer (GAO) USA menganalisa kegagalan Software ini,

Proyek ini gagal karena:

• Kegagalan untuk mengidentifikasi penyampaian (deliverable) dan tonggak(milestone) kunci proyek.
• Kegagalan untuk mendapatkan pemangku kepentingan membeli pada rencana proyek, termasuk parameter proyek utama seperti estimasi biaya dan jadwal.
• Kegagalan untuk memvalidasi kebutuhan utama proyek.
• Kegagalaann untuk menetapkan tanggung jawab atas risiko dan untuk mempersiapkan rencana mitigasi.
• Kegagalan untuk mendefinisikan metrik kunci untuk pelacakan kontrak dan kekeliruan eksekutif

Selain itu,

•       Inspektur Jenderal Departemen Perdagangan menyatakan penyebab masalah ini adalah :

–      "kegagalan manajer senior Biro Sensus di tempat pada saat untuk mengantisipasi persyaratan TI yang kompleks, yang terlibat dalam mengotomatisasi sensus."

•      Biro sensus sering mengubah persyaratan kebutuhan proyek software ini, sehingga reqirement dari biro sensus terhadap FDCA ini sering berubah-ubah ditengah jalan ketika proyek sudah berjalan dan setiap ada perubahan, biaya kontrak dengan Harris Corporation selalu meningkat

Sehingga, menjadi pelajaran, bahwa terdapat Faulty Requirement Definition terhadap Software ini yang menyebabkan Software error. Seharusnya, kedua belah pihak harus menyepakati requirement yang telah didefinisikan bersama. Berubah-ubahnya kebutuhan ditengah jalan proyek menunjukkan bahwa pendefinisian kebutuhan di awal proyek belum jelas dan belum fix, sehingga menerjemahkannya ke dalam proyek pembuatan software pun tidak benar dan sesuai dengan yang dibutuhkan.

Hal ini menjadi bahan evaluasi kita, jika memiliki proyek untuk membuat software, bahwa perlu secara jelas mendefinisikan kebutuhan perangkat lunak agar terjadi kesepakatan yang jelas antara pihak customer dengan developer software.

Sumber : Ethics in Information Technology 3^rd Edition (George W. Reynolds)
Nama Kelompok :
Achmad Kamal 5208100137
Innike Desy Kristianti DK 5209100034