Analisa Kebutuhan Perangkat Lunak

Djoko Soerjanto, M.Kom

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

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.

Pendahuluan

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 Sistem
Seseorang 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 customer dari sistem ATM ( Automatic Teller Machine)

Kelas Pemilik Modal Pemilik Sistem Pengguna Instansiasi Pemilik Bank Bagian Customer Banking - 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
Kebutuhan Bisnis Tujuan

Aturan Bisnis Apa Kebutuhan Pengguna Atribut Kualitas

Kebutuhan Sistem Kebutuhan Fungsional

Antarmuka Eksternal

Bagaimana

Batasan

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 Bisnis

Sistem ATM Kebutuhan Bisnis Meningkatkan pertumbuhan nasabah menjadi 5% tiap tahun Penghematan biaya pengadaan kertas sampai 20% Meningkatkan market share menjadi 5% Menurunkan biaya perizinan sampai 40%.

SIM Akademik

Online Ticketing SIM Perijinan Terpadu

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 Pengguna

Sistem ATM SIM Akademik Kebutuhan Pengguna Nasabah akan cek saldo Nasabah akan ambil uang Mahasiswa hendak menyusun KRS baru. Orang tua hendak melihat prestasi akademik anaknya. Calon penumpang memesan tiket pesawat. Penumpang mencetak tiket elektroniknya.

Online Ticketing

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 Bisnis

Sistem Aturan Bisnis

ATM

SIM Akademik Online Ticketing

Teknologi kartu yang digunakan harus memenuhi baku IEC. Otoritas keuangan negara menetapkan penggunaan smart card untuk kartu kredit paling lambat tahun 2015 Mahasiswa hendak menyusun rencana kuliah semester ini. 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 Kualitas

Sistem ATM Atribut Kualitas Kartu dapat digunakan sampai 1.000.000 kali Ketersediaan layanan minimal 92%

SIM Akademik

Dapat melayani 100 transaksi per menit. Kapasitas penyimpanan minimal 10 tahun. Proses booking paling lama 1 menit. Update halaman jadwal penerbangan maksimal dalam 2 detik.

Online Ticketing

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 Fungsional

Sistem ATM Kebutuhan Fungsional Jika saldo akhir setelah dikurangi jumlah debet akan lebih kecil dari saldo minimal yang diperkenankan, maka sistem menampilkan peringatan dan transaksi digagalkan. Dosen dapat mengubah presentase dari komponen penilaian. Sistem mengirimkan SMS ke penumpang jika terjadi perubahan jadwal penerbangan.

SIM Akademik

Online Ticketing

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 Eksternal

Sistem ATM Antarmuka Eksternal Koneksi basis data menggunakan TCP/IP. Menu minimalis dalam bahasa Indonesia dan Inggris. Sistem menggunakan protokol https via browser. Harus dapat ditampilkan di browser IE 7.0 ke atas, Firefox Opera dan Chrome. 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.

SIM Akademik

Online Ticketing

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 Batasan
Sistem ATM Batasan Monitor harus 14 dan resolusi 800x600 Tinggi ATM antara 130 cm s/d 150 cm Ukuran transaksi tidak boleh melebihi 64KB. Sistem harus dibangun menggunakan open source. Jumlah karakte untuk nama depan tidak boleh lebih dari 20 karakter. Satu sesi koneksi dengan basis data tidak boleh lebih dari 10 menit.

SIM Akademik

Online Ticketing

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 #1 Deskripsi Manajer produksi tidak berusaha memberikan pengetahuan yang cukup kepada pengembang tentang ranah sistem. Manajer tidak berkenan menyediakan waktu yang cukup untuk proses rekayasa kebutuhan. Tidak spesifik mengungkapkan masukan spesifikasi sistem. Tidak menghargai proses yang digunakan analis dalam rekayasa kebutuhan.

#2

#3 #4

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 ?