Dokumen tersebut membahas tentang kesalahan dalam mendefinisikan kebutuhan perangkat lunak yang dapat menyebabkan kegagalan proyek. Salah satu studi kasusnya adalah ketika sebuah supermarket ingin mengembangkan sistem penjualan dengan fitur-fitur tertentu yang tidak tercakup dalam sistem yang ditawarkan, sehingga perlu dilakukan revisi kebutuhan. Studi kasus ini menunjukkan pentingnya mendefinisikan kebutu

1. Faulty Requirement Definition Oleh: Ainnur Rofiq (5209100104) Endones Putra Yusa (5209100130)

2. Outline Latar Belakang Definisi Analisa Kebutuhan Perangkat Lunak Kesalahan Analisa Kebutuhan Perangkat Lunak Studi Kasus

3. Latar belakang Rekayasa perangkat lunak telah berkembang sejak pertama kali pada tahun 1940-an. 1945 – 1965 (fase awal) Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat debat tajam mengenai aspek engineering dari pengembangan perangkat lunak.

4. Latar Belakang 1965 – 1985 (krisis perangkat lunak) Pada tahun 1960-an hingga 1980-an, banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek yang melebihi anggaran, salah mendefinisikan kebutuhan, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.

5. Latar Belakang 1985 - kini Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi object, perangkat pembantu pengembangan perangkat lunak ( CASE tools ), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar , sesuai anggaran dan tepat waktu. Salah satu fokusnya adalah pada rekrutmen kebutuhan perangkat lunak.

6. Analisa Kebutuhan Perangkat Lunak Definisi : Analisa kebutuhan perangkat lunak adalah kegiatan dalam menentukan kebutuhan-kebutuhan atau kondisi yang harus dipenuhi untuk suatu produk baru (perangkat lunak) dengan mempertimbangkan kemungkinan terjadinya konflik kebutuhan dari berbagai macam stakeholder.

7. Analisa Kebutuhan Perangkat Lunak Analisis kebutuhan mempunyai peran penting dalam kesuksesan suatu proyek perangkat lunak. Kebutuhan harus terdokumentasi, dapat ditindaklanjuti (actionable), dapat diukur (measureable), dapat diuji, memiliki kaitan dengan kebutuhan dan peluang bisnis, serta memiliki tingkat kerincian yang cukup untuk perancangan sistem. Kebutuhan perangkat lunak dapat berupa kebutuhan fungsional dan non-fungsional.

8. Kesalahan Analisa Kebutuhan Perangkat Lunak Kesalahan pada analisa kebutuhan perangkat lunak menyebabkan kesalahan fatal pada perangkat lunak. Kesalahan pada analisa kebutuhan perangkat lunak menyebabkan kebutuhan yang seharusnya diperlukan tidak dapat dipenuhi

9. Beberapa Cara untuk Mengurangi Kesalahan Analisa Kebutuhan Perangkat Lunak Teknik kebutuhan perangkat lunak meliputi 3 buah tahap, yakni, elicitation (pengumpulan informasi), specification (spesifikasi), dan validation (validasi). Akan dijelaskan di slide berikutnya

10. Tahap Keterangan Metode Elicitation (pengumpulan informasi) Bertujuan untuk mengumpulkan sebanyak mungkin informasi mengenai problem domain, kesulitan-kesulitan klien dan user, serta apa yang sistem ingin lakukan untuk mereka. Wawancara Kuesioner Skenario Prototyping Specification (spesifikasi) Informasi dari proses elicitation dianalisa dan direkam menggunakan teknik modeling dramatis dan tekstual untuk menunjukkan masalah dan solusi yang diajukan. Spesifikasi formal Protoyping Validation (validasi) Mengecek kebutuhan yang telah direkam apakah telah berkaitan dengan tujuan stakeholder terhadap sistem. Wawancara Teknik kombinasi dari elicitation Inspeksi Fagan Prototyping

11. Studi Kasus Suatu perusahaan software developer bernama PT Matahari bergerak dibidang software untuk POS (Point of Sale) yang digunakan di Toko-toko dan supermarket untuk transaksi dengan para pembeli dan juga untuk manajemen keluar masuk barang, dan pelaporannya. Sebuah supermarket PANAMA menginginkan komputerisasi di bisnis retail yang dijalankannya dengan memesan software tersebut ke PT Matahari.

12. Studi Kasus (cont’d) PT Matahari menawarkan software yang sudah dibuatnya dan banyak dipakai di beberapa supermarket dan mendemokan software tersebut pada pihak customer supermarket PANAMA. Ternyata ada beberapa sistem atau fitur yang tidak ada seperti yang diharapkan oleh customer dan fitur tersebut sangat diperlukan dalam operasi bisnis di supermarket PANAMA. Salah satunya adalah fitur diskon pembelian. PT Matahari menggunakan persentase dalam system diskon pembelian. Dari pihak supermarket PANAMA menggunakan system rupiah dalam sistem diskon pembelian karena pemberian diskon hanya diberikan pada pembeli-pembeli tertentu yang memenuhi syarat dan pertimbangan manajemen. Supermarket panama juga menginginkan ada sistem pelaporan berupa grafik sehingga mudah dalam mengambil keputusan bisnis selanjutnya. Pihak customer menginginkan pelaporan harus sistematis, menarik, dan mudah untuk diambil kesimpulan.

13. Studi Kasus (cont’d) Dari permasalahan tersebut diatas, perlunya requirement elicitation untuk mengindentifikasi kebutuhan costumer. Untuk mengubah fitur diskon pembelian dari sistem persen ke rupiah mungkin sudah jelas, dan terdefinisi dengan baik, dan relative mudah untuk dimengerti oleh pihak software developer. Namun untuk fitur pelaporan yang menarik, sistematis dan mudah untuk diambil kesimpulan merupakan permasalahan cenderung abstrak. Dan ini mungkin pekerjaan ini memerlukan beberapa kali revisi karena tidak sesuai dengan kebutuhan customer. Solusi untuk masalah ini sebaiknya pihak developer mencari aspek-aspek apa saja yang diinginkan dalam sistem pelaporan dan manajemen bisnis retail dan mendefinisikannya dalam requirement specification untuk ditetapkan sebagai acuan pembuatan software yang bisa dipahami oleh kedua belah pihak. Requirement specification ini digunakan sebagai batasan pekerjaan yang harus dikerjakan oleh software developer, sehingga ketika tahap testing, customer tidak lagi menuntut jika customer ternyata masih merasa ada requirement yang terlupakan pada software tersebut.

14. Studi Kasus (cont’d) Permintaan agar software tersebut menarik dan mudah dipahami sebaiknya developer mendesain GUInya terlebih dahulu sebelum memulai coding. Jika GUI sudah disetujui maka akan digunakan sebagai acuan untuk proyek pembuatan software. Namun sebaiknya pihak developer masih tetap fleksibel untuk melayani jika customer meminta perubahan pada desain atau requirement specification yang sudah ditetapkan bersama dengan pertimbangan tertentu misalnya, pihak customer harus mengganti biaya revisi. Sumber : http://s2informatics.wordpress.com/2007/06/19/studi-kasus-software-development/

15. Terima Kasih