Halo semuanya, jumpa lagi bersama saya Supardianto pada mata kuliah analisis dan spesifikasi kebutuhan angkat punah. Kita akan masuk ke pertemuan kita yang pertama, yaitu membahas mengenai introduction of the requirement engineering. Kita mulai dulu dari deskripsi mata kuliahnya.
Bahwa mata kuliah ini adalah mata kuliah yang mengenalkan konsep dasar dalam melakukan analisis dan menentukan spesifikasi kebutuhan pada sebuah perangkat lunak. Mulai dari tahapan analisis, menyusun menjadi sebuah dokumen, suatu kebutuhan perangkat lunak. Kemudian pada pertemuan kita yang pertama ini, kita akan membahas mengenai dasar-dasar analisis dan negaya saya kebutuhan. Sehingga diharapkan nanti teman-teman bisa menjelaskan mengenai dasar analisis dan negaya saya kebutuhan.
Itu adalah capai pembelajaran kita di pertemuan yang pertama ini. Ada pun outline yang akan kita bahas pada pertemuan kali ini adalah mengenai what is requirement engineering, why is important, lalu kemudian ada common problem in the project, Product and Project Requirement, Terminologi, serta sampai dengan Cartoon Stick of the Good Requirement. Kita akan masuk ke bagian yang pertama mengenai why is requirement engineering dan kenapa ia penting. Why is it important? Kita lihat dengan melalui penggambaran dari analogi gambar yang ada di slide ini.
Dikatakan bahwa ada seseorang yang ingin dibuatkan suatu aplikasi. Lalu ditanya oleh si analisnya, kita anggap si perempuan ini sebagai analis. Aplikasi seperti apa yang ingin kamu bangun?
Si customer-nya hanya menjawab bahwa saya mau aplikasi desain. Aplikasi yang seperti apa? Kemudian analis yang bertanya lagi. Ya, saya tidak tahu. Saya saja belum lihat aplikasinya.
Bisa nggak kamu gambarkan mengenai konsep keseterusnya? Nah, dia nggak bisa. Makanya kemudian ada kalimat yang di bawahnya berkata bahwa software has to be created with the consideration of the user goals and needs. Jadi garis bawahnya adalah bahwa suatu aplikasi itu dia dibuat berdasarkan atas kebutuhan dari customer-nya dan juga dari tujuan apa yang ingin customer-nya dapatkan.
maka kita tidak bisa membuat suatu aplikasi dengan hanya berdasarkan satu asumsi saja. Nah, itu yang perlu teman-teman ingat pada bagian kenapa kemudian requirement engineering itu sangat dibutuhkan. Lalu kita lihat awalnya, what is requirement?
Apa itu requirement? Definisinya seperti apa? Definisi dari suatu requirement pada software development is different with the requirement in the common definition. Artinya agak sedikit berbeda pengertian pada requirement di pengembangan software dengan yang ada teman-teman biasa ketahui. Kalau pada software development diketahui bahwa requirement ini adalah spesifikasi yang memang harusnya ada dan terdapat pada aplikasi yang akan kita...
Kembangkan nantinya bahwa requirement ini adalah deskripsi yang menjelaskan mengenai aplikasi ini itu nanti bentuknya adalah seperti ini. Kebutuhannya akan seperti ini. Fiturnya dia akan bisa seperti ini.
Nah itulah yang requirement coba tangkap dari si customer seperti itu. Requirement include user perspective of the system behavior. Nah itu artinya bahwa Si requirement ini dia harus bisa menangkap dari kebutuhan pengguna dan menjadikannya sebagai perilaku atau fitur pada sistem. Seperti itu ya.
Also including developer perspective into the internal system. Ya tentu. Bisa dilihat juga dari sisi pandang si developernya. Bagaimana kira-kira requirement ini bisa menjawab goal dan needs-nya dari si customer.
Kemudian kalau ditanya, why is important? Nah, ini ada dua poin yang bisa kita tangkap dari pentingnya requirement. Yang pertama adalah semakin awal kita bisa menemukan bahwa terdapatnya, bahwa semakin awal kita bisa menentukan requirement apa yang kemudian bisa kita temukan, maka ketika nantinya terjadi kesalahan, ketika nanti terjadinya bug, seterusnya terjadinya fitur yang tidak relevan, itu semakin murah, semakin gampang. kita untuk selesaikan, to fix it. Jadi kalau requirement itu sudah didefinisikan di awal, sudah terdefinisi, baik.
Nah itu kemudian, dia akan semakin mudah dan murah dari segi biaya untuk kemudian dilanjutkan ke tahapan berikutnya. Lalu, jika nantinya ada kendala yang terjadi di bagian-bagian awal seperti ini, maka tadi juga yang bisa saya sebutkan bahwa ya ini akan semakin mudah untuk diperbaiki. Jangan sampai kita sudah masuk ke tahapan coding, implementasi, tapi ternyata environment-nya kemudian tidak sesuai. Fiturnya malah tidak relevan dengan kebutuhan dari pengguna. Nah itu muter lagi balik ke bagian tahapan awal, itu memakan waktu serta biaya yang kemudian harus dikeluarkan oleh si customer nantinya.
Lalu kita lihat beberapa common problem pada software project atau pengembangan aplikasi. Yang pertama poinnya adalah insufficient user involvement. Artinya ada beberapa permasalahan yang disebabkan oleh kurangnya komunikasi antara misalnya analis dengan si customer.
kayak gitu, kemudian si usernya atau si customernya juga kemudian tidak bisa menyampaikan mengenai kebutuhannya dengan baik. Nah itu juga kemudian akan menjadi salah satu permasalahan pada pengembangan aplikasi. Poin berikutnya adalah the creeping user requirement.
Artinya ketika customer sudah mengungkapkan bahwa fiturnya adalah ABC, namun seringkali ketika sudah masuk menjalankan tahapan desain, implementasi, Customer ingin kemudian menambahkan atau merubah fitur-fitur yang sudah disepakati pada saat tahapan requirement. Hal ini yang biasanya sering terjadi pada saat kita mengembangkan aplikasi. Customer merasa bahwa yang dulu saya sampaikan itu ternyata salah, saya ingin merubahnya.
Atau bahkan saya yang dulu saya sampaikan itu kurang, saya ingin menambahkannya lagi. Nah ini kemudian bisa menyebabkan atau merupakan salah satu permasalahan yang umum. pada pengembangan suatu aplikasi. Lalu berikutnya ada ambiguous requirement. Si customer dia tidak bisa atau dia menggunakan kata yang sebenarnya kita agak sulit mengartikannya.
Antara pemahaman kita sebagai developer dan kita sebagai developer atau analis dan si customer itu bisa berbeda. Sehingga ketika kita menginterpretasikan dari fitur dan seterusnya, si customer ternyata bilang bahwa Oh, tidak seperti ini, seperti itu. Yang saya maksudnya itu seperti ini.
Nah, hal ini terjadi karena memang terjadi ambiguous requirement ini. Jadi requirement-nya memang bisa menyebabkan interpretasi yang berbeda. Kemudian ada God-plating.
Kalau God-plating, ini biasanya masalahnya terjadi dari sisi-sisi developernya. Si customer-nya merasa bahwa Saya nggak butuh kok fitur ini. Lalu si developer-nya merasa bahwa, oh ini fitur bagus, saya masukin deh misalnya. Terus fitur ini bagus, saya masukin deh.
Padahal fitur itu ternyata tidak dibutuhkan oleh si customer. Nah itu adalah ketik poin yang kita sebut sebagai goal planning. Lalu poin berikutnya adalah minimal specification in accurate planning.
Nah ini biasanya terjadi dari sisi internal pengembangnya Dari sisi analisnya, kemudian dari sisi developernya Terutama bagian project manager Dia tidak bisa merencanakan dengan baik apa yang harus dilakukan pada project ini Kemudian overlook user class Kalau ini dari sisi customer, biasanya customer terlalu banyak Menuntut bahwa aplikasi ini akan punya role A, B, C, D. Dan A, B, C, D ini akan mewakili fitur-fitur fungsi dan seterusnya. Nah ini kemudian... bisa menyebabkan permasalahan-permasalahan yang terjadi pada saat pengembangan proyek ini.
Jadi terlalu melihat banyaknya pengguna yang nantinya akan menggunakan aplikasi ini. Makanya penting perlu dicari tahu dengan benar siapa saja nantinya yang akan menggunakan aplikasi ini. Kemudian kita lihat poin berikutnya adalah Project and product requirement.
Nah, seringkali kita menganggap bahwa, oh ini adalah hal yang sama. Padahal seharusnya ini dua hal yang berbeda. Kalau produk berkaitan kepada requirement atau kebutuhan yang sistem produk atau software itu butuhkan. Dan dia akan menjadi fitur.
Kalau project requirement adalah kebutuhan bagaimana project ini bisa berjalan. Dan itu di luar dari produk, misalnya infrastruktur, kemudian environment pengembangannya, ke skill dari developernya, masalah hukum, serta hal-hal yang lainnya, dan itu berada di bagian luar dari si produk atau si aplikasinya. Lalu, kita masuk ke typical requirement process.
Pada highlight yang teman-teman lihat di slide ini, itu ada dua, yaitu adalah well established kemudian agile requirement. Kita lihat yang well established. Kalau kita melihat jenisnya well established requirement process, ini adalah jenis tipe requirement yang memang didasarkan pada tahapan-tahapan ketentu yang harus dia lalui sebelum masuk ke tahapan selanjutnya.
Kalau pada metode pengembangan aplikasinya, contoh yang well established ini adalah waterfall. Seperti itu ya. Nah, kalau di sini juga dia disebut sebagai the following process.
Bahwa harus mulai dari tahapan A dulu. Setelah tahapan A selesai, pindah ke tahapan B. Setelah selesai, pindah ke tahapan C.
Jadi setiap tahapan requirement yang terdapat itu bisa dengan jelas dan harus diselesaikan lebih dahulu. Itu adalah well established Apa tantangannya ketika kita menggunakan well established? Yang pertama adalah delivery-nya bisa saja menjadi lama Kemudian untuk bekerja bersama-sama itu juga kemudian susah Kemudian berkaitan dengan untuk membuat prototyping juga akan menjadi lama Karena tahapan prototyping itu mungkin berada di fase ketiga Harus lewat dulu ke requirement, lewat dulu analisis, lewat dulu decide baru kabur kemudian dilakukan prototyping.
Jadi ini adalah saling berperan, seperti itu ya. Lalu bagaimana dengan tipe satu lagi, yaitu agile requirement. Agile requirement sebenarnya juga merupakan well established. Tahapan-tahapan juga dilakukan.
Hanya saja yang membedakan adalah tahapan-tahapan ini itu dilakukan pada per fitur dari si aplikasi yang akan dikembangkan nanti. Jadinya sehingga ketika kita sudah selesai satu fitur, satu fungsi, kita masukkannya ke well established. Mulai dari requirement, analisis, design, implementasi selesai, kita balikkan lagi ke customer. Sesuai apa enggak?
Kalau sesuai, masukkan. Berarti sudah selesai. Fitur berikutnya lagi. Jadi benar-benar fitur-fiturnya sudah terdefinisi.
Seperti itu. Karena sudah terdefinisi, maka fitur-fitur tadi tinggal selanjutnya kita buat. Sekala prioritasnya.
Apakah prioritasnya itu tinggi atau rendah? Prioritas yang tinggi itulah yang dikerjakan berulang. Nah, seperti itu. Jadi, tahapan ini itu bisa lebih sangat-sangat fleksibel.
Namanya saja agile. Salah satu metode perancangan yang menggunakan agile environment adalah dengan menggunakan Scrum. Apa tantangan yang terdapat pada metode agile? Yaitu adalah...
repetitive works, karena dia terus dilakukan berulang-ulang untuk setiap fitur, maka tentu aja pekerjaannya menjadi berulang-ulang itu juga adalah menjadi tantangan informal documentation karena tadi sifatnya selalu fleksibel, jadi terkait dengan dokumentasi juga bisa menyebabkan suatu hal yang harus dipikirkan, bagaimana dengan dokumentasinya nanti perancangannya seperti apa, nah itu kemudian menjadi hal yang harus dipikirkan Kemudian inactive customer. Ketika fitur sudah selesai, lalu kemudian ingin ditunjukkan ke customer, customer harus bisa memberikan feedback. Kalau customer nggak bisa kasih feedback, nah ini kemudian kita agak sulit membaikkan sisi untuk semua.
Kita masuk ke kesimpulan untuk pertemuan kita yang pertama. Jadi dapat dikatakan bahwa memang requirement itu penting. Karena harus membangun suatu software tidak hanya berdasarkan asumsi, tapi harus berdasarkan kebutuhan dan tujuan dari si customer-nya. Ingat bahwa requirement adalah hal yang menggambarkan spesifikasi dari apa yang sistem harus punya.
Semakin awal kita bisa menemukan masalah yang muncul diakibatkan requirement yang sudah selesai di awal, itu maka akan semakin mudah dan semakin murah untuk kita teruskan ke pengembangan aplikasi. Dan ingat, ada dua jenis tipikal requirement, yaitu well-established dan juga agile. Masing-masing memiliki tantangannya sendiri dan masing-masing memiliki keuntungan setelah perlugiannya sendiri. Oke? Sampai situ dulu untuk pertemuan kita yang pertama.
Kita ketemu lagi di pertemuan kita berikutnya. Terima kasih.