Dalam kondisi ideal, pemangku kepentingan dan insinyur perangkat lunak bekerja bersama dalam sebuah tim. Dalam situasi seperti itu, requirements engineering hanya menjadi sebuah permasalahan dalam berkomunikasi yang efektif dengan rekan tim yang dikenal. Namun, pada kenyataannya seringkali situasinya jauh berbeda.
Para pelanggan atau pengguna akhir mungkin berada di lokasi yang berbeda, baik itu di kota maupun negara yang berbeda. Mereka mungkin hanya memiliki pemahaman yang kurang jelas tentang apa yang mereka butuhkan, atau bahkan memiliki pendapat yang bertentangan mengenai sistem yang akan dibangun. Selain itu, pengetahuan teknis mereka mungkin terbatas, dan mereka mungkin memiliki keterbatasan waktu dalam berinteraksi dengan insinyur persyaratan. Semua aspek ini tidak diinginkan, namun cukup umum terjadi, dan sering kali memaksa kita untuk bekerja dalam batasan yang ditetapkan oleh situasi tersebut.
Pada bagian selanjutnya, saya akan membahas langkah-langkah yang perlu dilakukan untuk membentuk pemahaman dasar tentang persyaratan perangkat lunak. Tujuan dari langkah-langkah ini adalah memulai proyek dengan pendekatan yang dapat mendorong kemajuan menuju solusi yang sukses.
1.1 Identifying Stakeholders (Mengidentifikasi Pemangku Kepentingan)
Menurut definisi yang diajukan oleh Sommerville dan Sawyer, pemangku kepentingan dapat didefinisikan sebagai individu atau kelompok yang secara langsung maupun tidak langsung mendapatkan manfaat dari sistem yang sedang dikembangkan. Dalam hal ini, saya telah mengidentifikasi beberapa pemangku kepentingan yang umum, seperti manajer operasional bisnis, manajer produk, tim pemasaran, pelanggan internal dan eksternal, pengguna akhir, konsultan, insinyur produk, insinyur perangkat lunak, insinyur dukungan dan pemeliharaan, serta lainnya. Setiap pemangku kepentingan memiliki sudut pandang yang berbeda terkait sistem, mengharapkan manfaat yang berbeda ketika pengembangan sistem berhasil, dan juga rentan terhadap risiko yang berbeda jika upaya pengembangan tersebut mengalami kegagalan.
Pada awalnya, penting untuk menyusun daftar individu yang akan memberikan masukan saat persyaratan diajukan. Daftar ini akan terus bertambah saat pemangku kepentingan terlibat, karena setiap pemangku kepentingan akan ditanya: "Menurut Anda, siapa lagi yang perlu saya ajak bicara?"
1.2 Recognizing Multiple Viewpoints (Mengenali Berbagai Sudut Pandang)
Dikarenakan terdapat berbagai pemangku kepentingan yang berbeda, persyaratan sistem akan dilihat dari berbagai sudut pandang. Sebagai contoh, kelompok pemasaran akan tertarik pada fungsi dan fitur yang menarik bagi pasar potensial, sehingga membuat sistem baru mudah dijual. Manajer bisnis akan memperhatikan rangkaian fitur yang dapat dikembangkan sesuai dengan anggaran dan mampu memenuhi jendela waktu pasar yang ditetapkan. Pengguna akhir mungkin menginginkan fitur yang familiar, mudah dipelajari, dan digunakan. Insinyur perangkat lunak mungkin memperhatikan fungsi yang tidak terlihat oleh pemangku kepentingan non-teknis, namun memungkinkan adanya infrastruktur yang mendukung berbagai fungsi dan fitur yang dapat dipasarkan. Sementara itu, insinyur pendukung dapat fokus pada pemeliharaan perangkat lunak.
Setiap kelompok pemangku kepentingan ini, beserta yang lainnya, akan memberikan sumbangan informasi untuk proses rekayasa persyaratan. Saat informasi dari berbagai sudut pandang dikumpulkan, persyaratan yang muncul mungkin tidak seragam atau bahkan saling bertentangan. Oleh karena itu, penting untuk mengkategorikan semua informasi yang diberikan oleh pemangku kepentingan (termasuk persyaratan yang tidak seragam dan saling bertentangan) dengan cara yang memungkinkan pembuat keputusan untuk memilih serangkaian persyaratan sistem yang memiliki konsistensi internal.
1.3 Working toward Collaboration (Bekerja menuju Kolaborasi)
Apabila terlibat lima pemangku kepentingan dalam proyek perangkat lunak, kemungkinan akan terdapat lima atau lebih pendapat yang berbeda mengenai persyaratan yang tepat. Sepanjang pembahasan sebelumnya, saya telah mencatat bahwa penting bagi pelanggan (dan pemangku kepentingan lainnya) untuk bekerja sama secara kolaboratif antara mereka (dengan menghindari konflik kepentingan yang sempit) serta dengan praktisi rekayasa perangkat lunak agar dapat menghasilkan sistem yang sukses. Namun, pertanyaannya adalah bagaimana kolaborasi tersebut dapat dicapai?
Tugas seorang insinyur persyaratan adalah mengenali area persyaratan yang serupa (yaitu, persyaratan yang disepakati oleh semua pemangku kepentingan) serta area persyaratan yang bertentangan atau tidak konsisten (yaitu, persyaratan yang diinginkan oleh satu pemangku kepentingan namun bertentangan dengan kebutuhan pemangku kepentingan lainnya). Tentunya, kategori terakhir ini menjadi tantangan tersendiri.
Kolaborasi tidak berarti bahwa persyaratan ditentukan oleh suatu komite. Dalam banyak situasi, pemangku kepentingan berkolaborasi dengan memberikan pandangan mereka mengenai persyaratan, namun keputusan akhir mengenai persyaratan mana yang akan diadopsi sering kali diambil oleh "pemimpin proyek" yang memiliki kewenangan yang kuat (seperti manajer bisnis atau teknologi senior).
1.4 Asking the First Questions (Mengajukan Pertanyaan Pertama)
Pertanyaan yang diajukan pada tahap awal proyek harus "bebas konteks". Serangkaian pertanyaan bebas konteks pertama kali difokuskan pada pelanggan dan pemangku kepentingan lainnya, serta tujuan dan manfaat keseluruhan proyek. Sebagai contoh, beberapa pertanyaan yang mungkin diajukan adalah sebagai berikut:
- Siapa yang menjadi inisiator atau pihak yang meminta pekerjaan ini?
- Siapa yang akan menjadi pengguna dari solusi ini?
- Apa dampak ekonomi yang akan dihasilkan dari keberhasilan solusi ini?
- Apakah ada sumber lain untuk solusi yang Anda butuhkan?
Pertanyaan-pertanyaan ini membantu dalam mengidentifikasi semua individu atau kelompok pemangku kepentingan yang akan tertarik dengan perangkat lunak yang akan dikembangkan. Selain itu, pertanyaan-pertanyaan tersebut membantu mengidentifikasi manfaat konkret yang dapat diukur dari implementasi yang sukses, serta alternatif-alternatif yang mungkin untuk pengembangan perangkat lunak khusus.
Serangkaian pertanyaan berikutnya akan membantu Anda untuk memperoleh pemahaman yang lebih mendalam tentang masalah yang dihadapi dan memberikan kesempatan kepada pelanggan untuk mengungkapkan persepsi mereka mengenai solusi yang diinginkan:
- Bagaimana Anda mendeskripsikan hasil yang dianggap "baik" yang akan dicapai melalui keberhasilan solusi ini?
- Apa permasalahan yang akan diatasi oleh solusi ini?
- Bisakah Anda memperlihatkan (atau menjelaskan) lingkungan bisnis di mana solusi ini akan digunakan?
- Apakah ada masalah atau kendala kinerja tertentu yang akan mempengaruhi pendekatan solusi?
Pertanyaan-pertanyaan terakhir ini berkaitan dengan evaluasi efektivitas aktivitas komunikasi yang dilakukan. Dalam istilah Gause dan Weinberg, ini disebut sebagai "meta-questions" dan mereka mengusulkan daftar singkatan berikut ini:
- Apakah Anda memiliki keahlian yang tepat untuk menjawab pertanyaan-pertanyaan ini? Apakah jawaban yang Anda berikan dianggap sebagai jawaban yang sah?
- Apakah pertanyaan yang saya ajukan relevan dengan permasalahan yang Anda hadapi?
- Apakah saya mengajukan terlalu banyak pertanyaan?
- Apakah ada pihak lain yang dapat memberikan informasi tambahan?
- Apakah ada pertanyaan lain yang sebaiknya saya ajukan?
Pertanyaan-pertanyaan ini, bersama dengan yang lainnya, akan membantu "mengatasi kebuntuan" dan memulai komunikasi yang penting untuk mencapai elisitasi persyaratan yang sukses. Namun, format pertemuan tanya jawab tidaklah menjadi pendekatan yang sangat efektif. Sesungguhnya, sesi tanya jawab sebaiknya hanya digunakan pada pertemuan awal dan kemudian digantikan dengan pendekatan elisitasi persyaratan yang menggabungkan elemen pemecahan masalah, negosiasi, dan spesifikasi. Pendekatan semacam ini dijelaskan lebih lanjut dalam pembahasan berikutnya.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment