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.
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.
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.
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
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.
SIM Akademik
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.
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.
ATM
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.
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.
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.
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
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.
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.
#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.
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 ?