Perspektif Pemangku Kepentingan

Proyek rekayasa perangkat lunak berhasil dihasilkan ketika para pemangku kepentingan
peduli dengan masalahnya dan tau bahwa ide, pendapat, dan kontribusinya dihargai.

Inti cerita Bu. Ida

Proses pengembangan perangkat lunak tidak hanya tanggung jawab tim TI namun semua
pihak yang memiliki kepentingan dalam proyek pengembangan perangkat lunak (stakeholders).

a. Pemangku Kepentingan (Stake Holders) adalah pihak yang memiliki kepentingan terhadap
perangkat lunak.
b. Kegagalan proyek pengembangan perangkat lunak salah satunya yaitu karena proses
rekayasa kebutuhan dan sejumlah sumber permasalahan yang berasal dari pemangku
kepentingan.
Contohnya yaitu rendahnya kepedulian terhadap proses rekayasa kebutuhan,
ketidakpahaman dan ketidakmampuan pemangku kepentingan untuk menspesifikasi
kebutuhannya dengan baik.

Pemangku kepentingan dapat diklasifikasikan sebagai berikut :

a. Pelanggan(customer)
Merupakan seseorang atau organisasi yang meminta jasa pengembang untuk
mengembangkan perangkat lunak tsb. Termasuk investor, system owner maupun
pengguna.
b. Pemilik Modal (Investor)
Pemilik modal yaitu seseorang atau sekelompok orang yang mendanai atau membiayai
suatu proyek pengembangan perangkat lunak.
c. Pemilik Sistem
Pemilik sistem adalah seseorang yang berperan sebagai pemilik proses bisnis yang
direpresentasikan dalam sistem yang dibangun. Pemilik sistem mendapatkan keuntungan
secara langsugn maupun tidak langsung dari pengoperasian sistem yang bersangkutan.
Pemilik sistem biasanya juga sebagai pemilik modal.
d. Pengguna (User)
Seseorang yang menggunakan perangkat lunak.
e. Regulator
Seseorang yang menetapkan aturan dan batasan baik dalam pengembangan maupun
pengoperasian software tsb.
f. Penyedia (Vendor)
Seseorang yang menyediakan teknologi atau jasa yang digunakan bagi pengembangan atau
pengoperasian software tsb.
g. Pengembang (Developer)
 Sekelompok orang yang bertanggung jawab untuk mengembangkan software. Termasuk
didalamnya adalah manajer proyek, pemimpin tim, analis sistem, programmer atau
implementator dan penguji (tester).
h. Analis sistem
System Analist mempunyai tugas melakukan analisis sistem, merancang sistem kemudian
diimplementasikan pada Perusahaan serta bertanggung jawab terhadap hasil yang ingin di
capai oleh Perusahaan.
i. Programmer
Seseorang yang memiliki skill menulis kode program (syntax) dan merancang sistem.

Kelompok Kebutuhan :

1. Kebutuhan Bisnis
Mempresentasikan tujuan akhir yang hendak dicapai ketika nanti sistem dioperasikan.
Contoh :
a. Sistem ATM => meningkatkan pertubuhan nasabah menjadi 5% pertahun.
b. SIM Akademik => penghematan biaya pengadaan kertas sampai 20%
c. Online ticketing => meningkatkan market share menjadi 15%
d. SIM Perizinan Terpadu => menurunkan biaya perizinan sampai 50%
2. Kebutuhan Pengguna
Merupakan kebutuhan fungsional yang mempresentasikan tujuan dari pengguna
(khususnya pengguna akhir) ketika menggunakan sisyem yang hendak dibangun.
Contoh :
a. Sistem ATM => nasabah hendak mengecek saldo dan nasabah hendak mengambil uang
b. SIM Akademik => Mahasiswa hendak menyusun rencana kuliah semester ini dan
Orangtua hendak melihat prestasi belajar anak didik.
c. Online ticketing => Calon penumpang memesan tiket pesawat dan Penumpang
mencetak tiket elekronik.
3. Aturan Bisnis
Merupakan kebutuhan non-fungsional yang meliputi aturan dan kebijakan dari suatu
perusahan atau pemerintah yang membatasi bagaimana sistem memenuhi kebutuhan
pengguna tsb.
Contoh :
a. Sistem ATM => Teknologi kartu yang digunakan harus memenuhi baku IEC, dan
Otoritas keuangan negara menetapkan penggunaan smart card untuk semua kartu kredit
paling lambat tahun 2015.
b. SIM Akademik => Mahasiswa diatas semester 4 yang IPK nya diatas 3.00 dapat
menempuh 24 SKS
c. Online ticketing => Setiap pemesanan tiket harus menyebutkan identitas dari calon
penumpang dan Sistem harus mematuhi aturan yang ditetapkan ole IATA.
4. Atribut Kualitas
 Merupakan kebutuhan non-fungsional yang memperjelas kebutuhan fungsional dengan
menambahkan karakteristik dari system dalam berbagai dimensi yang penting.
Contoh :
a. Sistem ATM => Kartu dapat digunakan minimal 1.000.000 kali dan Ketersediaan layanan
minimal 92%.
b. SIM Akademik => sistem dapat melayani minimal 100 transaksi per menit dan
kapasitas penyimpanan minimal untuk 10 tahun.
c. Online ticketing => Proses booking paling lama 1 menit dan Update halaman jadwal
penerbangan maksimal dalm 2 detik.
5. Kualitas Sistem
6. Kebutuhan Sistem
Kebutuhan system terkait suatu system terintegrasi yang terdiri dari sub-sub sistem, baik
perangkat lunak, perangkat keras, maupun personel.
Contoh :
a. Sistem ATM => Menggunakan Processor 2.0 Ghz, RAM 4 GB, Bandwith internet 5
Gb, dan UPS.
b. SIM Akademik => Storage sebesar 10 TB, Bandwith internet 10 Gb, dan RAM 32 GB.
7. Kebutuhan Fungsional
Merupakan fungsi atau fitur yang harus ada pada sistem untuk dapat membantu pengguna
mencapai tujuan ketika menggunakan sistem.
Contoh :
a. Sistem ATM => Jikalau saldo akhir nasabah seetelah dikurangi jumlah debit akan lebih
kecil dari saldo minimal yang diperkenankan, maka sistem menampilkan peringakatan
dan menggagalkan transaksi debit terkait.
b. SIM Akademik => Dosen harus dapat mengubah persentase dan komponen penilaian.
c. Online ticketing => Sistem mengirimkan SMS ke penumpang jika terjadi perubahan
jadwal penerbangan.
8. Antarmuka Eksternal
Merupakan kebutuhan non fungsional yang mendeskripsikan kondisi atau karakteristik
yang harus dipenuhi sebagai bentuk interaksi dengan entitas di luar dirinya.
Contoh :
a. Sistem ATM => Koneksi dengan basis data bank menggunakan protocol TCP/IP dan
Menu ditampilkan minimum dalam Bahasa Indonesia atau Inggris.
b. SIM Akademik => Sistem menggunakan protocol HTTPS untuk akses pengguna
menggunakan browser dan Elemen antarmuka pengguna harus dapat ditampilkan di IE
7.0 ke bawah, Firefox, dan Opera.
c. Online ticketing => Sistem harus dapat mencetak e-tiket setidaknya dalam format pdf,
doc, dan docx dan Data dalam e-tiket harus mematuhi metadata sesuai dengan
OpenDoc agar dapat diimport ke SIM Dept. Perhubungan Udara.
9. Batasan
 Merupakan kebutuhan non-fungsional dari sistem yang searah formal membatasi pilihan
yang dapat dilakukan oleh pengembang dalam mengambil keputusan yang berkaitan
dengan proses pengembangan software.
Contoh :
a. Sistem ATM => Monitor yang digunakan harus berukuran 14” dengan resolusi 800x600 dan
Tinggi ATM antara 130 cm s/d 150 cm.
b. SIM Akademik => Ukuran sebuah transaksi tidak boleh melebihi 64 kbyte dan Sistem harus
dibangun sepenuhnya menggunakan open source.
c. Online ticketing => Jumlah maksimum karakter utuk atribut nama depta tidak boleh lebih
dari 20 karakter dan Satu sesi koneksi dengan basis data tidak boleh lebih dari 10 menit.

Tanggung Jawab Pelanggan :

1. Memberitahukan pengembang tentang bisnisnya dan mendefinisikan jargon bisnis yang

digunakan.
2. Meluangkan waktu yang diperlukan untuk proses elisitasi kebutuhan, mengklarifikasi, dan
secara iterative menyempurnakan.
3. Menyediakan masukan yang diperlukan untuk spesifikasi kebutuhan spesifik dan presisi
4. Membuat keputusan tepat waktu berkaitan dengan kebutuhan ketika diminta.
5. Menghargai penilaian pengembang tentang biaya dan kelayakan dari suatu kebutuhan.
6. Bersama – sama dengan pengembangan menetapkan prioritasdari sekumpulan kebutuhan
yang telah dispesifikasikan.
7. Mengulas kembali setiap dokumen kebutuhan dan mengevaluasi semua prototype.
8. Mengkomunikasikan setiap perubahan kebutuhan sesegera mungkin.
9. Mematuhi proses perubahan kebutuhan yang ditetapkan organisasi pengembang perangkat
lunak.
10. Menghargai proses-proses yang digunakan pengembang dalam merekayasa kebutuhan.

Hak Pelanggan :

1. Mengharapkan analis menggunakan Bahasa pelanggan.

2. Mengharapkan analis belajar tentang bisnis dan tujuan pelanggan akan sistem yang hendak
dibangun.
3. Mengharap analis menspesifikasikan kebutuhan yang telah didapatkan dari proses elisitasi
yang telah dilakukan.
4. Meminta analis menjelaskan semua produk yang dihasilkan dari proses rekayasa
kebutuhan.
5. Mengharapkan pengembang memperlakukan pelanggan dengan rasa hormat dan mejaga
sikap professional dan mau bekerjasama sepanjang interaksinya.
6. Meminta pengembang menyediakan ide-ide dan alternative kebutuhan maupun
implementasi dari solusi.
7. Menjelaskan karakteristik dari produk sehingga memudahkan dan menyenangkan untuk
diguakan.
8. Diberi kesempatan untuk melakukan penyesuaian terhadap kebutuhan untuk
memungkinkan penggunaan kembali komponen perangkat lunak yang telah ada.
9. Menerima perkiraan, dampak, dan trade-off atas dasar kepercayaan ketika pelanggan
mempertimbangkan suatu perubahan kebutuhan.
10. Menerima sistem yang memenuhi kebutuhan fungsional dan non-fungsional sepanjang
yang telah dikomunikasikan kepada pengembang.