Pemangku Kepentingan (Stake Holders) adalah Pihak-pihak yang memiliki kepentingan terhadap perangkat lunak.
Kegagalan proyek pengembangan perangkat lunak salah satunya dimulai pada proses rekayasa kebutuhan, dan sejumlah sumber permasalahan tsb berasal dari pemangku kepentingan, contohnya kepedulian yang rendah terhadap proses rekayasa kebutuhan, pemahaman yang salah tentang spesifikasi kebutuhan dan ketidakfahaman serta ketidakmampuan pemangku kepentingan untuk menspesifikasikan kebutuhannya dengan baik.
Pemangku kepentingan dapat diklasifikasikan seperti berikut :
- Pelanggan, seseorang atau organisasi yang meminta jasa pengembang untuk mengembangkan perangkat lunak tsb. Termasuk pemilik modal (investor) atau pemilik sistem (system owner) dan pengguna (user).
- Pemilik Modal, seseorang atau sekelompok orang mendanai atau membiayai suatu proyek pengembangan perangkat lunak.
- Pemilik Sistem, seseorang atau kelompok orang yang berperan sebagai pemilik dari proses bisnis yang direpresentasikan dalam sistem yang dibangun. Pemilik sistem mendapat keuntungan baik secara langsung maupun tidak langsung dari pengoperasian sistem yang bersangkutan. Pemilik sistem biasanya sekaligus penyedia dana atau pemilik modal dari proyek pengembang perangkat lunak.
- Pengguna (user), setiap orang secara langsung menggunakan atau mengoperasikan perangkat lunak. Pengguna sering juga disebut operator.
- Regulator, seorang atau suatu organisasi yang menetapkan aturan dan barasan baik dalam pengembangan maupun pengoperasian perangkat lunak tsb.
- Penyelia (Vendor), seorang atau sekelompok orang yang menyediakan teknologi atau jasa yang digunakan bagi pengembangan atau pengoperasian perangkat lunak tsb.
- Pengembang (Developer), sekelompok orang yang bertanggung jawab mengembangan perangkat lunak. Termasuk didalamnya adalah manajer proyek, pemimpin tim, analis sistem, programmer atau implementator dan penguji (tester),
- Analis Sistem (System Analyst), seorang atau kelompok orang yang menyediakan teknologi atau jasa yag digunakan bagi pengembangan atau pengoperasian perangkat lunak tsb.
- Programmer, seorang atau sekelompok orang yang menyediakan teknologi atau jasa yang digunakan bagi pengembangan atau pengoperasian perangkat lunak tsb.
Contoh pada sistem Automatic Teller Machine (ATM) Instansiasi dari masing-masing kelas customer sesuai dengan definisi sebelumnya adalah sbb:
Kelompok Kebutuhan
Salah satu permasalahan dari spesifikasi kebutuhan adalah adanya jurang pemisah antara pelaggan dengan pengembang. Pelanggan sering mengungkapkan kebutuhannya (terkadang keinginannya) dalam bentuk yang abstrak, tersirat, tidak lengkap, kabur dan tidak teratur. Dan tugas seorang analis adalah mengidentifikasikan mana yang merupakan kebutuhan pelanggan dari sistem tsb dan mendeskripsikannya dalam bentuk yang spesifik, terukur dan teruji, realistis dan dapat diwujudkan, serta menyediakan mekanisme untuk pelacakan. Dan kebutuhan-kebutuhan tsb perlu dikategorikan berdasarkan jenisnya agar dapat digunakan dengan tepat.
Selain dapat dikelompokkan ke dalam kebutuhan fungsional dan non fungsional, kebutuhan juga dapat dikelompokkan lebih rinci lagi berdasarkan tingkat dari pemangku kepentingan (Wiegers, 2003). Pada gambar, dapat dijelaskan sbb :
- lapisan teratas merepresentasikan tujuan tingkat tinggi, yaitu tujuan yang hendak dicapai dari membangun sistem.
- Lapisan ditengah merepresentasikan kondisi serta kapabilitas apa saja yang harus disediakan sistem untuk mencapai tujuan tersebut.
- Lapisan terbawah merepresentasikan bagaimana kondisi dan kapabilitas tersebut dapat disediakan oleh sistem. Lapisan ini juga merepresentasikan antarmuka dengan sistem lain dan batasan-batasan yang harus dipatuhi baik dalam proses pengembangan sistem maupun dalam pengoperasiannya.
Kebutuhan Bisnis (Business Requirements).
Merepresentasikan tujuan akhir yang hendak dicapai ketika nantinya sistem dioperasikan. Tujuan akhir ini disebut juga tujuan (project goals) dari proyek pengembangan perangkat lunak. Tujuan ini biasanya berasal dari pemilik sistem atau penyandang dana sebagai pemilik organisasi. Tujuan ini didokumentasikan ke dalam dokumen penawaran proyek. Dari kebutuhan bisnis ini, analis sistem dapat mengidentifikasi pengguna dari sistem yang hendak dibangun. Contoh :
Kebutuhan Pengguna (user requirement)
Kebutuhan fungsional yang merepresentasikan tujuan dari pengguna (khususnya pengguna akhir) ketika menggunakan sistem yang hendak dibangun. Kebutuhan pengguna pada akhirnya menjadi sebuah fungsi atau fitur dari sistem. Tetapi tidak semua fungsi atau fitur tsb merupakan perwujudan dari aturan bisnis ataupun atribut kuallitas yang harus dipenuhi oleh sistem. Contoh :
Aturan Bisnis (Business Rules)
Kebutuhan non fungsional yang meliputi aturan dan kebijakan dari perusahaan maupun pemerintah, baku mutu industri, best practise dll yang membatasi bagaimana sistem memenuhi kebutuhan pengguna tsb. Contoh :
Atribut Kualitas (quality attributes)
Kebutuhan non fungsional yang memperjelas kebutuhan fungsional dengan menambahkan karakteristik dari sistem dalam berbagai dimensi yang penting, baik bagi pengguna maupun pengembang. Karakteristik tsb merepresentasikan antara lain unjuk kerja, ketersediaan, ketangguhan, efisiensi, efektivitas atau portabilitas yang harus dimiliki oleh sistem. Contoh :
Kebutuhan Sistem (system requirement)
Terkait suatu sistem terintegrasi yang terdiri dari sub-sub sistem, baik perangkat lunak, perangkat keras maupun personel. Kebutuhan ini merupakan kebutuhan fungsional yang mendeskripsikan sekumpulan fungsi atau fitur yang membentuk perilaku dari sistem ketika sub sistem tersebut berinteraksi satu dengan yang lain.
Kebutuhan Fungsional (functional requirement)
Kebutuhan sistem yang terkait dengan subsistem perangkat lunak. Kebutuhan ini menspesifikasikan fungsi atau fitur yang harus ada pada sistem untuk dapat membantu pengguna mencapai tujuan ketika menggunakan sistem, yang pada akhirnya memenuhi tujuan bisnis. Kebutuhan inilah yang menjadi acuan bagi perancang dalam membuat rancangan sistem, dan sebagai acuan bagi penguji dalam membangun kasus pengujian untuk pengujian integrasi sistem.
Antarmuka Eksternal (eksternal interface)
Kebutuhan non fungsional yang mendeskripsikan kondisi atau karakteristik yang harus dipenuhi sistem sebagai bentuk interaksi dengan entitas diluar dirinya. Entitas diluar dirinya bisa berupa sistem lain atau individu yang berinteraksi dengan sistem. Contoh :
Batasan (constraints)
Kebutuhan non fungsional dari sistem yang secara formal membatasi pilihan yang dapat dilakukan oleh pengembang dalam pengambilan keputusan terkait proses-proses pengembanganperangkat lunak. Batasan ini biasanya terkait dengan keterbatasan dari metode maupun teknologi yang digunakan dalam proses implementasi. Contoh :
TANGGUNG JAWAB DAN HAK PELANGGAN
Wiegers (2003) menyusun Bill of Rights dan Bill of Responsibilities bagi pelanggan. Daftar tersebut menekankan pentingnya keterlibatan pelanggan sebagai salah satu pemangku kepentingan dari proyek pengembangan perangkat lunak.
Pelanggan memiliki tanggung jawab untuk :
- Memberitahukan pengembang tentang bisnisnya.
- Meluangkan waktu yang diperlukan untuk proses elisitasi kebutuhan, mengklarifikasinya, dan secara iteratif menyempurnakannya
- Menyediakan masukan yang diperlakukan untuk spesifikasi kebutuhan secara spesifik
- Membuat keputusan tepat waktu berkaitan dengan kebutuhan ketika diminta
- Menghargai penilaian pengembang tentang biaya dan kelayakan dari suatu kebutuhan
- Bersama-sama dengan pengembang menetapkan prioritas dari sekumpulan kebutuhan yang telah dispesifikasikan
- Mengulas kembali setiap dokumen kebutuhan dan mengevaluasinya
- Mengkomunikasikan setiap perubahan kebutuhan sesegera mungkin
- Mematuhi proses perubahan kebutuhan yang ditetapkan organisasi pengembangan perangkat lunak
- Menghargai proses-proses yang digunakan pengembang dalam merekayasa kebutuhan
Pelanggan memiliki hak untuk :
- Mengharapkan analis menggunakan bahasa pelanggan
- Mengharapkan analis belajar tentang bisnis dan tujuan pelanggan akan sistem yang hendak dibangun
- Mengharap analis menspesifikasikan kebutuhan yang telah didapatkan dari proses elisitasi yang telah dilakukan
- Meminta analis menjelaskan semua produk yang dihasilkan dari proses rekayasa kebutuhan
- Mengharapkan pengembang memperlakukan pelanggan dengan rasa hormat dan menjaga sikap profesional dan mau bekerja sama sepanjang interaksinya
- Meminta pengembang menyediakan ide-ide dan alternatif kebutuhan maupun implementasi dari solusi
- Menjelaskan karakteristik dari produk sehingga memudahkan dan menyenangkan untuk digunakan
- Diberi kesempatan untuk melakukan penyesuaian terhadap kebutuhan untuk memungkinkan penggunaan kembali komponen perangkat lunak yang telah ada
- Menerima perkiraan, dampak dan trade-off atas dasar kepercayaan ketika pelanggan mempertimbangkan suatu perubahan kebutuhan
- Menerima sistem yang memenuhi kebutuhan fungsional dan non fungsional sepanjang yang telah dikomunikasikan kepada pelanggan
Kapan Selesai? :
Proses rekayasa kebutuhan merupakan proses iteratif. Spesifikasi kebutuhan dibangun sedikit demi sedikit berdasarkan informasi dan data yang berhasil dikumpulkan, dianalisa dan diverifikasi.
Biasanya dalam spesifikasi kebutuhan dikenal istilah “sign-off” yang merujuk kepada penandatanganan dokumen spesifikasi kebutuhan oleh perwakilan dari kedua belah pihak. Dengan keluarnya dokumen “sign-off” inilah sistem mulai dapat dikembangkan.
Menemukan Pemangku Kepentingan yang tepat
Setiap pemangku kepentingan yang teridentifiasi harus mewakili kepentingan tertentu yang nantinya teraktualisasi dalam bentuk kebutuhan-kebutuhan perangkat lunak. Masing-masing kelas pemangku kepentingan diperankan oleh satu atau lebih individu. Setiap individu pada satu saat hanya berperan sebagai salah satu kelas pemangku kepentingan.
Karena jumlah keseluruhan individu cenderung sangat banyak, untuk itu kita perlu memilah pemangku kepentingan mana yang perlu dilibatkan dan menentukan individu-individu mana yang harus mewakili tiap-tiap pemangku kepentingan tersebut.
Sejumlah langkah yang dapat dilakukan untuk melakukan pemilihan stakeholder, yaitu:
- Identifikasi struktur organisasi dimana perangkat lunak terkait hendak dikembangkan
- Petakan masing-masing jabatan/tanggung jawab di dalam organisasi ke dalam kelas-kelas pemangku kepentingan
- Identifikasi kelas-kelas pengguna yang ada
- Tentukan ranking prioritas dari kelas-kelas pemangku kepentingan
- Identifikasi keyperson untuk tiap-tiap kelas
- Tentukan keyperson minimum yang dapat dilibatkan untuk meliput keseluruhan pengetahuan tentang ranah sistem berdasarkan sumber daya yang ada
- Dokumentasikan setiap kelas pemangku kepentingan dan turunannya serta karakteristik, tanggung jawab dan lokasi fisik di dalam dokumen SKPL