Analisa Kebutuhan Perangkat Lunak

Prespektif Stakeholder

Djoko Soerjanto, M.Kom

https://www.facebook.com/groups/analisa.kpl

Pendahuluan Seorang manajer produksi suatu perusahaan,

mengajukan permintaan sistem pelacakan material kepada staf TI. Sistem ini diharapkan dapat melacak pemakaian material setiap bagian proses, sehingga nantinya bisa diketahui lebih cepat dan akurat asal permasalahan dan siapa yang bertanggung jawab.

Staf TI mengiyakan permintaan dan juga mengajukan jadwal pertemuan dengan manajer dan staf produksi. Akan tetapi direspon dengan menolak karena kesibukan masing-masing dan merasa itu menjadi tanggung jawab bagian IT.

Akhirnya staf TI membangun sistem berdasarkan asumsi-asumsi yang didasari dari pengalaman sebelumnya.

Situasi seperti di atas sering muncul dalam proses pengembangan PL.

Pelanggan tidak memahami bahwa pengembangan PL bukan hanya sekedar tanggung jawab pihak TI. Namun memerlukan semua pihak yang memiliki kepentingan dalam pengembangan proyek PL tersebut.

Pihak-pihak yang berkepentingan inilah yang disebut Pemangku Kepentingan ( stakeholder )

Kegagalan suatu proyek PL disebabkan salah satunya pada proses rekayasa kebutuhan.

Salah satu sumber permasalahan berasal dari pemangku kepentingan, karena ketidakpahaman dan ketidakmampuan pemangku kepentingan untuk menspesifikasi kebutuhan dengan baik.

Jadi, keterlibatan pemangku kepentingan antar pelanggan dengan pengembang adalah sangat krusial.

Siapakah Pemangku Kepentinghan

Itu ?

1. Pelanggan (Customer)

Seseorang atau organisasi yang meminta jasa pengembang untuk mengembangkan suatu perangkat lunak tertentu.

Contoh : pemilik modal (investor), pemilik sistem (System owner), dan pengguna (user)

2. Pemilik Modal

Seseorang atau sekelompok orang yang berperan dalam mendananai

atau membiayai suatu proyek pengembangan perangkat lunak.

3. Pemilik Sistem Seseorang atau sekelompok orang

yang berperan sebagai pemilik dari proses bisnis yang sedang direpresentasikan dalam sistem yang dibangun.

Pemilik sistem seringkali juga merupakan penyedia dana (pemodal) dari pengembangan proyek PL tersebut.

4. Pengguna Setiap orang yang secara langsung

menggunakan atau mengoperasikan perangkat lunak tersebut.

Pengguna sering juga disebut Operator.

5. Regulator

Seseorang atau suatu organisasi yang menetapkan aturan dan batasan baik

dalam pengembangan maupun pengoperasian perangkat lunak

tersebut.

6. Penyelia ( vendor )

Seseorang atau sekelompok orang atau organisasi yang menyediakan teknologi atau jasa yang digunakan

bagi pengembangan atau pengoperasian perangkat lunak

tersebut.

7. Pengembang (developer) Seseorang atau sekelompok orang

yang bertanggung jawab mengembangkan perangkat lunak tersebut.

Termasuk disini Manajer Proyek (project manager) / Pemimpin Tim (Team Leader), Analis Sistem (System Analys) / Requirements Engineers, Programmer / Implementator, Designer, dan Penguji (Tester)

8. Analis SistemSeseorang atau sekelompok orang yang bertugas menganalisa dan

merancang sistem dalam pengembangan perangkat lunak.

9. Programmer

Seseorang atau sekelompok orang yang bertugas membuat kode program

yang merupakan implementasi dari hasil rancangan yang sudah dibuat

oleh analis sistem.

Contoh instansiasi customerdari sistem ATM ( Automatic

Teller Machine)

Kelas InstansiasiPemilik Modal Pemilik BankPemilik Sistem Bagian Customer BankingPengguna - Pemilik kartu ATM

- Pemilik kartu ATM dari bank lain

- Teknisi ATM

Kelompok Kebutuhan Pelanggan dalam menyatakan kebutuhan

(keinginan) atas perangkat lunak, kadang bentuknya sering abstrak, tidak lengkap, kabur dan tidak teratur.

Oleh karena itu, Analis berperan untuk mengidentifikasi mana yang merupakan kebutuhan dalam bentuk yang spesifik, terukur, teruji, realistis dan dapat diwujudkan.

Maka, dirasa perlu adanya kategori kebutuhan.

Kelompok Kebutuhan Selain kebutuhan Fungsional dan Non

Fungsional, juga ada kebutuhan berdasar tingkat dari pemangku kepentingan.

Kelompok Kebutuhan

KebutuhanBisnis

KebutuhanPengguna

Aturan Bisnis

Atribut Kualitas

KebutuhanSistem

KebutuhanFungsional

AntarmukaEksternal

Batasan

Tujuan

Apa

Bagaimana

Fungsional Non Fungsional

Kelompok Kebutuhan Lapisan teratas merepresentasikan tujuan

tingkat tinggi, yaitu tujuan yang hendak dicapai dari membangun sistem.

Lapisan tengah, merepresentasikan kondisi serta kapabilitas apa saja yang harus tersedia untuk mencapai tujuan tersebut.

Lapisan bawah, merepresentasikan bagaimana kondisi dan kapabilitas tersebut disediakan oleh sistem. Selain itu juga merepresentasikan antarmuka dengan sistem lain dan batasan yang harus dipatuhi.

Kebutuhan Bisnis Kebutuhan bisnis ( business requirements),

merepresentasikan tujuan akhir yang hendak dicapai ketika sistem dipakai.

Sering disebut Tujuan Project (Project Goal) Tujuan ini berasal dari pemilik sistem atau

penyandang dana sebagai pemilik organisasi.

Dari kebutuhan ini, analis sistem dapat mengidentifikasi pengguna dari sistem yang akan dibangun.

Contoh Kebutuhan BisnisSistem Kebutuhan BisnisATM Meningkatkan

pertumbuhan nasabah menjadi 5% tiap tahun

SIM Akademik Penghematan biaya pengadaan kertas sampai 20%

Online Ticketing Meningkatkan market share menjadi 5%

SIM Perijinan Terpadu Menurunkan biaya perizinan sampai 40%.

Kebutuhan Pengguna Merupakan kebutuhan fungsional yang

merepresentasikan tujuan dari pengguna (khususnya pengguna akhir) ketika hendak menggunakan sistem yang dibangun.

Kebutuhan ini diturunkan langsung dari kebutuhan bisnis dengan cara mengidentifikasi pengguna serta sistem lain yang terkait pencapaian kebutuhan bisnis ini. Kemudian mengidentifikasi tujuan pengguna.

Kebutuhan pengguna dapat dipakai sebagai acuan kasus pengujian penerimaan pengguna.

Contoh Kebutuhan PenggunaSistem Kebutuhan PenggunaATM Nasabah akan cek saldo

Nasabah akan ambil uangSIM Akademik Mahasiswa hendak

menyusun KRS baru.Orang tua hendak melihat prestasi akademik anaknya.

Online Ticketing Calon penumpang memesan tiket pesawat.Penumpang mencetak tiket elektroniknya.

Ingat ! Kebutuhan pengguna memang pada

akhirnya menjadi sebuah fungsi atau fitur sistem. Akan tetapi tidak semuanya itu merupakan kebutuhan pengguna, terkadang fungsi atau fitur itu merupakan perwujudan dari aturan bisnis atau atribut kualitas yang harus dipenuhi oleh sistem.

Aturan Bisnis Business Rule merupakan kebutuhan

non fungsional yang meliputi aturan dan kebijakan dari perusahaan maupun pemerintah, industri, dll.

Terkadang aturan bisnis ini mengandung atribut kualitas yang harus dipenuhi dari suatu layanan dari sistem ketika memenuhi kebutuhan pengguna.

Contoh Aturan BisnisSistem Aturan BisnisATM Teknologi kartu yang digunakan

harus memenuhi baku IEC.Otoritas keuangan negara menetapkan penggunaan smart card untuk kartu kredit paling lambat tahun 2015

SIM Akademik Mahasiswa hendak menyusun rencana kuliah semester ini.

Online Ticketing Setiap pemesanan tiket harus menyebutkan identitas calon penumpang.

Aturan Kualitas Quality Attributes merupakan kebutuhan

non fungsional yang memperjelas kebutuhan fungsional dengan menambahkan karakteristik dari sistem dalam pelbagai dimensi yang penting, baik bagi pengguna maupun pengembang.

Karakteristik tersebut menunjukkan unjuk kerja, ketersediaan, ketangguhan, efisiensi, efektivitas, dan portabilitas yang dimiliki sistem.

Contoh Atribut KualitasSistem Atribut KualitasATM Kartu dapat digunakan sampai

1.000.000 kaliKetersediaan layanan minimal 92%

SIM Akademik Dapat melayani 100 transaksi per menit.Kapasitas penyimpanan minimal 10 tahun.

Online Ticketing Proses booking paling lama 1 menit. Update halaman jadwal penerbangan maksimal dalam 2 detik.

Kebutuhan Fungsional Merupakan kebutuhan yang

menspesifikasi fungsi atau fitur yang harus ada pada sistem untuk membantu pengguna mencapai tujuan.

Kebutuhan fungsional inilah yang menjadi acuan bagi analis dan penguji dalam membuat rancangan sistem dan pengujian sistem.

Contoh Kebutuhan FungsionalSistem Kebutuhan FungsionalATM Jika saldo akhir setelah dikurangi

jumlah debet akan lebih kecil dari saldo minimal yang diperkenankan, maka sistem menampilkan peringatan dan transaksi digagalkan.

SIM Akademik Dosen dapat mengubah presentase dari komponen penilaian.

Online Ticketing Sistem mengirimkan SMS ke penumpang jika terjadi perubahan jadwal penerbangan.

Antarmuka Eksternal External interface merupakan

kebutuhan non fungsional yang mendeskripsikan kondisi atau karakteristik yang harus dipenuhi sistem sebagai bentuk interaksi dengan entitas di luar dirinya.

Entitas luar bisa berupa sistem lain, atau individu ynag berinteraksi dengan sistem.

Contoh Antarmuka EksternalSistem Antarmuka EksternalATM Koneksi basis data menggunakan

TCP/IP.Menu minimalis dalam bahasa Indonesia dan Inggris.

SIM Akademik Sistem menggunakan protokol https via browser.Harus dapat ditampilkan di browser IE 7.0 ke atas, Firefox Opera dan Chrome.

Online Ticketing Sistem dapat mencetak e-tiket setidaknya dalam format PDF, DOC dan DOCX.Data e-tiket harus mematuhi metadata dengan OpenDoc agar dapat diimpor Departemen Perhubungan Udara.

Batasan Constraints, merupakan kebutuhan

non fungsional dari sistem yang membatasi pilihan yang dapat dilakukan oleh pengembang dalam pengambilan keputusan terkait proses perkembangan perangkat lunak.

Batasan ini terkait dengan metode dan teknologi yang digunakan.

Contoh BatasanSistem BatasanATM Monitor harus 14” dan resolusi

800x600Tinggi ATM antara 130 cm s/d 150 cm

SIM Akademik Ukuran transaksi tidak boleh melebihi 64KB.Sistem harus dibangun menggunakan open source.

Online Ticketing Jumlah karakte untuk nama depan tidak boleh lebih dari 20 karakter.Satu sesi koneksi dengan basis data tidak boleh lebih dari 10 menit.

TANGGUNG JAWAB & HAK PELANGGAN

Tanggung jawab Pelanggan

1) Memberitahukan kepada pengembang tentang bisnisnya dan mendefinisikan istilah-istilah bisnis yang digunakan.

2) Meluangkan waktu yang diperlukan untuk proses pengumpulan kebutuhan, mengklarifikasi, dan secara iteratif menyempurnakannya.

3) Menyediakan masukan yang diperlukan untuk spesifikasi kebutuhan spesifik dan presisi mungkin.Spesifik -> unik, sederhana, tidak bias, jelas dan konsisten.

4) Membuat keputusan tepat waktu berkaitan dengan kebutuhan yang diminta.

5) Mengulas kembali setiap dokumen kebutuhan dan mengevaluasi semua prototipe.

6) Mengkomunikasikan setiap perubahan kebutuhan sesegera mungkin.

Hak Pelanggan Mengharapkan analis belajar tentang

bisnis dan tujuan pelanggan akan sistem yang dibangun.

Mengharap analis menspesifikasikan kebutuhan yang telah didapatkan dari proses penyusuan kebutuhan yang telah dilakukan.

Meminta analis menjelaskan semua produk yang dihasilkan dari rekayasa kebutuhan.

Mengharapkan pengembang memperlakukan pelanggan dengan rasa hormat dan menjaga sikap profesional dan mau bekerjasama sepanjang interaksinya.

Menjelaskan karakteristik dari produk sehingga memudahkan dan menyenangkan untuk digunakan.

Menerima sistem yang memenuhi kebutuhan fungsional dan non fungsional sepanjang yang telah dikomunikasikan dengan pengembang.

Contoh Tanggung Jawab Yang Tidak dilakukan Pelanggan

Tanggung Jawab Deskripsi#1 Manajer produksi tidak berusaha

memberikan pengetahuan yang cukup kepada pengembang tentang ranah sistem.

#2 Manajer tidak berkenan menyediakan waktu yang cukup untuk proses rekayasa kebutuhan.

#3 Tidak spesifik mengungkapkan masukan spesifikasi sistem.

#4 Tidak menghargai proses yang digunakan analis dalam rekayasa kebutuhan.

Sign-off Istilah merujuk penandatanganan

dokumen spesifikasi kebutuhan oleh kedua belah pihak.

Penandatanganan ini menandai persetujuan pihak pelanggan terhadap spesifikasi kebutuhan yang telah diformalisasi oleh pengembang. Selain itu sebagai janji dari pengembang kepada pelanggan untuk memenuhi semua kebutuhan dalam produk yang dikembangkan.

Sikap ekstrem pemangku kepentingan atas ‘sign-off’

Mereka tidak peduli, dan mengganggap sign-off sebagai prasayarat bahwa pengembang mulai bekerja dan tidak mengganggu mereka lagi.

Mereka takut dipersalahkan, seringkali bukanlah keyperson yang dapat mengambil keputusan.

Solusi ? Persetujuan kedua pihak, bahwa sign-off

adalah upaya untuk memiliki pemahaman yang sama terhadap ranah sistem, yang meliputi fungsionalitas, kualitas dan batasan yang hendak dibuat.

Pemahaman ini dibangun dari setiap informasi dan kebutuhan yang berhasil dikumpulkan (elisitasi) dan feedback dari pelanggan saat verifikasi.

Pemahaman ini akan berkembang sedikit demi sedikit mengikuti waktu.

Question ?