Merancang serta membangun perangkat lunak komputer merupakan suatu tugas yang penuh tantangan, membutuhkan kreativitas, dan memberikan kepuasan tersendiri. Sebenarnya, proses membangun perangkat lunak sangat menarik sehingga banyak pengembang perangkat lunak ingin langsung terjun tanpa memiliki pemahaman yang jelas tentang kebutuhan yang sebenarnya. Mereka beranggapan bahwa segalanya akan menjadi jelas saat mereka sedang dalam tahap pembangunan, bahwa para pemangku kepentingan proyek akan mampu memahami kebutuhan hanya setelah melihat versi awal perangkat lunak, dan bahwa segala sesuatu berubah begitu cepat sehingga upaya untuk memahami persyaratan secara detail hanya akan membuang-buang waktu. Pokoknya, yang terpenting adalah menghasilkan program yang berfungsi, sedangkan hal lain dianggap kurang penting. Argumen-argumen ini memang menarik karena mengandung sebagian kebenaran, namun setiap argumen tersebut memiliki kekurangan dan bisa menyebabkan kegagalan proyek perangkat lunak.
Proses pengertian persyaratan yang melibatkan beragam tugas dan teknik dikenal sebagai requirements engineering. Dalam konteks pengembangan perangkat lunak, rekayasa kebutuhan merupakan salah satu langkah utama yang dimulai dengan aktivitas komunikasi dan berlanjut ke aktivitas pemodelan. Proses ini harus disesuaikan dengan kebutuhan dari segi proses, proyek, produk, serta orang yang terlibat dalam pekerjaan tersebut.
Requirements engineering berfungsi sebagai penghubung antara desain dan konstruksi, namun dari mana sebenarnya jembatan ini berasal? Sebagian orang mungkin berpendapat bahwa jembatan ini bermula dari pemangku kepentingan proyek (seperti manajer, pelanggan, pengguna akhir), di mana kebutuhan bisnis ditetapkan, skenario pengguna dijelaskan, fungsi dan fitur diuraikan, serta batasan proyek diidentifikasi. Ada juga yang berpendapat bahwa jembatan ini dimulai dengan definisi sistem yang lebih luas, di mana perangkat lunak hanya menjadi salah satu komponen dalam domain sistem yang lebih besar. Bagaimanapun, terlepas dari titik awalnya, perjalanan melintasi jembatan ini membawa Anda ke level yang lebih tinggi dalam proyek, memungkinkan Anda untuk mengeksplorasi konteks pekerjaan perangkat lunak yang akan dilakukan, kebutuhan khusus yang harus dipenuhi oleh desain dan konstruksi, prioritas yang menentukan urutan penyelesaian tugas, serta informasi, fungsi, dan perilaku yang akan memiliki dampak signifikan terhadap desain yang dihasilkan.
Rekayasa persyaratan memiliki peran penting dalam menyediakan mekanisme yang efektif untuk memahami keinginan pelanggan, menganalisis kebutuhan, mengevaluasi kelayakan, berdiskusi mengenai solusi yang masuk akal, menetapkan solusi dengan jelas, memvalidasi spesifikasi, dan mengelola persyaratan ketika diimplementasikan menjadi sistem yang beroperasi. Proses ini terdiri dari tujuh tugas yang berbeda, yaitu permulaan, pengumpulan informasi, pengembangan rinci, negosiasi, penyusunan spesifikasi, validasi, dan manajemen. Perlu diperhatikan bahwa beberapa tugas ini dapat berjalan secara bersamaan dan semuanya disesuaikan dengan kebutuhan proyek yang sedang dilakukan.
Inception. Bagaimana sebuah proyek perangkat lunak dimulai? Apakah ada peristiwa tunggal yang menjadi pendorong untuk menciptakan sistem atau produk baru berbasis komputer, ataukah kebutuhan tersebut berkembang seiring waktu? Pertanyaan-pertanyaan ini tidak memiliki jawaban pasti. Dalam beberapa kasus, sebuah proyek besar dalam rekayasa perangkat lunak dapat dimulai hanya melalui percakapan santai. Namun, secara umum, kebanyakan proyek dimulai ketika kebutuhan bisnis diidentifikasi atau ketika ditemukan peluang pasar atau layanan baru yang berpotensi. Stakeholder dari komunitas bisnis, seperti manajer bisnis, tim pemasaran, atau manajer produk, akan menentukan kasus bisnis untuk ide tersebut, berupaya mengidentifikasi pasar secara luas dan mendalam, melakukan analisis kelayakan awal, serta menentukan cakupan pekerjaan proyek. Meskipun semua informasi ini bisa berubah, tetapi sudah cukup untuk memicu diskusi dengan tim rekayasa perangkat lunak.
Di awal proyek, langkah pertama adalah membangun pemahaman dasar mengenai permasalahan yang ada, pihak-pihak yang membutuhkan solusi, karakteristik solusi yang diinginkan, serta menjalin komunikasi awal dan kolaborasi yang efektif antara pemangku kepentingan dan tim pengembang perangkat lunak.
Elicitation. Pada dasarnya terlihat sederhana - bertanyalah kepada pelanggan, pengguna, dan pihak lain mengenai tujuan sistem atau produk, apa yang perlu dicapai, bagaimana sistem atau produk dapat memenuhi kebutuhan bisnis, dan bagaimana penggunaan sistem atau produk akan terjadi secara rutin. Namun, sebenarnya hal tersebut tidaklah sederhana - melainkan sangat rumit.
Christel and Kang menemukan beberapa tantangan yang timbul selama proses pengumpulan informasi berlangsung.
- Problems of scope. Ketidakjelasan dalam batasan sistem atau pelanggan/pengguna yang menentukan detail teknis yang tidak relevan dapat menyebabkan kebingungan daripada memberikan pemahaman yang jelas mengenai tujuan sistem secara keseluruhan.
- Problems of understanding. Pelanggan atau pengguna sering kali tidak memiliki kejelasan mengenai apa yang sebenarnya mereka butuhkan, memiliki pemahaman yang terbatas tentang kemampuan dan batasan lingkungan komputasi yang mereka miliki, serta kurang pemahaman dalam domain masalah yang sedang dihadapi. Selain itu, mereka juga mengalami kesulitan dalam mengkomunikasikan kebutuhan mereka kepada tim insinyur sistem, sering kali menghilangkan informasi yang sebenarnya penting, dan sering kali menentukan persyaratan yang bertentangan dengan kebutuhan pengguna lainnya atau bersifat ambigu dan tidak dapat diuji.
- Problems of volatility. Seiring berjalannya waktu, persyaratan mengalami perubahan.
Agar dapat mengatasi masalah tersebut, diperlukan pendekatan sistematis dalam pengumpulan persyaratan.
Elaboration. Data yang diperoleh dari pelanggan selama tahap awal dan elisitasi kemudian diperluas dan diperinci selama tahap elaborasi. Pada tahap ini, fokusnya adalah mengembangkan model persyaratan yang lebih lengkap yang mengidentifikasi berbagai aspek dalam hal fungsi perangkat lunak, perilaku, dan informasi.
Proses elaborasi didorong oleh langkah-langkah pembuatan dan penyempurnaan skenario pengguna yang menggambarkan interaksi pengguna akhir (dan aktor lainnya) dengan sistem. Setiap skenario pengguna dianalisis secara mendetail untuk mengidentifikasi entitas-entitas kelas analisis yang relevan dalam domain bisnis yang terlihat oleh pengguna akhir. Atribut-atribut dari setiap kelas analisis ditentukan, dan layanan-layanan yang diperlukan oleh setiap kelas juga diidentifikasi. Selain itu, hubungan dan kolaborasi antara kelas-kelas tersebut diidentifikasi, serta dibuatkan berbagai diagram tambahan.
Negotiation. Seringkali tidak jarang bagi pelanggan dan pengguna untuk mengharapkan hasil yang melebihi kemampuan yang ada, mengingat keterbatasan sumber daya dalam bisnis. Juga umum bagi pelanggan atau pengguna yang berbeda untuk mengajukan persyaratan yang saling bertentangan, dengan argumen bahwa versi mereka adalah "penting untuk memenuhi kebutuhan khusus yang kami miliki".
Untuk menyelesaikan konflik tersebut, diperlukan proses negosiasi. Pelanggan, pengguna, dan pihak-pihak terkait lainnya diminta untuk mengurutkan persyaratan dan kemudian membahas konflik tersebut berdasarkan prioritas. Dengan menggunakan pendekatan iteratif yang memprioritaskan persyaratan, mengevaluasi biaya dan risikonya, serta mengatasi konflik internal, persyaratan dapat dieliminasi, digabungkan, atau dimodifikasi agar setiap pihak mencapai tingkat kepuasan yang diinginkan.
Specification. Dalam lingkup sistem berbasis komputer (dan perangkat lunak), istilah "spesifikasi" memiliki makna yang bervariasi bagi individu yang berbeda. Spesifikasi dapat berwujud dalam bentuk dokumen tertulis, serangkaian model grafis, model matematika formal, kumpulan skenario penggunaan, prototipe, atau kombinasi dari elemen-elemen tersebut.
Beberapa saran telah diajukan mengenai penggunaan "template standar" dalam menyusun spesifikasi, dengan argumen bahwa ini akan menghasilkan persyaratan yang disajikan secara konsisten dan dengan demikian lebih mudah dipahami. Namun, ada juga situasi di mana fleksibilitas tetap dibutuhkan dalam pengembangan suatu spesifikasi. Untuk sistem yang kompleks, pendekatan yang terbaik mungkin adalah menggabungkan dokumen tertulis yang menggunakan deskripsi bahasa alami dan model grafis. Namun, dalam kasus produk atau sistem yang lebih kecil dan berada dalam lingkungan teknis yang sudah dipahami dengan baik, mungkin hanya skenario penggunaan yang perlu disertakan dalam spesifikasi.
Validation. Kualitas dari produk kerja yang dihasilkan sebagai hasil dari rekayasa persyaratan dinilai selama tahap validasi. Proses validasi persyaratan bertujuan untuk memeriksa spesifikasi dengan tujuan memastikan bahwa semua persyaratan perangkat lunak telah diungkapkan dengan jelas, bahwa inkonsistensi, kelalaian, dan kesalahan telah teridentifikasi dan diperbaiki, serta memastikan bahwa produk kerja sesuai dengan standar yang ditetapkan untuk proses, proyek, dan produk yang bersangkutan.
Proses validasi persyaratan dilakukan melalui tinjauan teknis sebagai mekanisme utama. Tim peninjau yang terdiri dari insinyur perangkat lunak, pelanggan, pengguna, dan pemangku kepentingan lainnya bertugas untuk memeriksa spesifikasi dengan tujuan menemukan kesalahan dalam konten atau interpretasi, mengidentifikasi area yang memerlukan klarifikasi, menemukan informasi yang hilang, menangani ketidakkonsistenan (terutama dalam pembuatan produk atau sistem yang kompleks), mendeteksi persyaratan yang bertentangan, serta menilai kecukupan dan realitas persyaratan yang diajukan (memastikan bahwa persyaratan tersebut dapat dicapai secara praktis).
Requirements management. Persyaratan dalam sistem berbasis komputer tidak stabil, dan kebutuhan untuk mengubah persyaratan tetap ada sepanjang masa sistem tersebut. Manajemen persyaratan melibatkan serangkaian tindakan yang membantu tim proyek dalam mengenali, mengendalikan, dan melacak persyaratan serta mengadaptasi persyaratan tersebut selama proyek sedang berlangsung. Banyak dari kegiatan ini memiliki kesamaan dengan teknik manajemen konfigurasi perangkat lunak (SCM).
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment