Kebutuhan Perangkat Lunak

By M. Ainul Yaqin, S.Si, M.Kom

Area Pengetahuan Kebutuhan Perangkat Lunak

• Area pengetahuan kebutuhan perangkat lunak berhubungan dengan elisitasi, analisis, spesifikasi, dan validasi kebutuhan perangkat lunak.

• Kebutuhan perangkat lunak menggambarkan kebutuhan dan batasan-batasan yang ada pada produk perangkat lunak yang berkontribusi terhadap solusi dari beberapa masalah dunia nyata.

Area Pengetahuan Kebutuhan Perangkat Lunak

Definisi Kebutuhan Perangkat Lunak

• Properti yang harus ditunjukkan untuk memecahkan beberapa masalah di dunia nyata.

• Properti penting dari semua kebutuhan harus dapat diverifikasi

Kebutuhan Proses dan Produk

• Parameter produk adalah kebutuhan pada perangkat lunak yang dikembangkan

• Parameter proses adalah batasan-batasan mendasar pengembangan perangkat lunak

Kebutuhan Fungsional dan Non Fungsional

• Kebutuhan fungsional menggambarkan fungsi yang dijalankan oleh perangkat lunak. Misal format teks, modulasi sinyal.

• Kebutuhan non fungisonal adalah sesuatu yang bertindak membatasi solusi. Kebutuhan non fungsional terkadang disenut sebagai batasan atau kebutuhan kualitas.

• Kebutuhan non fungsional lebih lanjut dapat diklasifikasikan ke dalam kebutuhan kinerja, kebutuhan pemeliharaan, kebutuhan keselamatan, kebutuhan keandalan, atau salah satu dari banyak jenis kebutuhan perangkat lunak.

Emergent Properties

• Emergent properties dapat muncul ketika sejumlah entitas sederhana beroperasi di sebuah lingkungan, membentuk perilaku yang lebih kompleks sebagai sebuah kolektifitas.

• Emergent properties mungkin adalah sesuatu yang sangat dapat diprediksi, atau tidak dapat diprediksi, bahkan belum pernah terjadi sebelumnya.

• Beberapa kebutuhan merupakan emergent properties bagi perangkat lunak, yaitu kebutuhan yang tidak dapat diatas oleh komponen tunggal.

• Contoh Emergent Properties : kebutuhan throughput untuk call center akan bergantung pada bagaimana sistem telepon, sistem informasi, dan operator dimana semua berinteraksi dalam kondisi operasi aktual

Kebutuhan Terukur

• Kebutuhan perangkat lunak harus dinyatakan sejelas mungkin, dan bila perlu secara kuantitatif.

• Contoh kebutuhan terukur : software call center harus meningkatkan throughput pusat sebesar 20%

Kebutuhan Sistem dan Kebutuhan Perangkat Lunak

• Kebutuhan sistem adalah kebutuhan untuk sistem secara keseluruhan. Dalam sistem yang mengandung komponen perangkat lunak, kebutuhan perangkat lunak yang berasal dari kebutuhan sistem.

• Literatur tentang kebutuhan kadang menyebut kebutuhan sistem sebagai kebutuhan pengguna. Petunjuk mendefinisikan kebutuhan pengguna dengan cara sebagai kebutuhan pelanggan atau pengguna akhir.

• Kebutuhan sistem meliputi kebutuhan pengguna, kebutuhan dari pihak lain, dan kebutuhan tanpa sumber manusia yang teridentifikasi.

Model Proses

• Suatu proses yang dimulai dari awal proyek dan terus disempurnakan di seluruh siklus hidup.

• Mengidentifikasi kebutuhan perangkat lunak sebagai item konfigurasi, dan mengelolanya dengan menggunakan praktek manajemen konfigurasi perangkat lunak yang sama dengan produk lain dari proses siklus hidup perangkat lunak.

• Perlu disesuaikan dengan konteks organisasi dan proyek

• Secara khusus berkaitan dengan bagaimana aktifitas elisitasi, analisis, spesifikasi, dan validasi yang dikonfigurasi untuk berbagai jenis proyek dan batasan.

Aktor Proses

• Pada bagian ini membahas orang-orang yang berpartisipasi dalam proses kebutuhan.

• Biasanya stakeholder perangkat lunak terdiri dari :– Pengguna. Kelompok ini terdiri dari orang-orang yang

akan mengoperasikan perangkat lunak– Pelanggan. Kelompok ini meliputi mereka yang telah

menugaskan atau yang mewakili target pasar– Analis pasar. Dibutuhkan untuk menetapkan kebutuhan

pasar dan untuk bertindak sebagai penghubung dengan pelanggan

– Regulator. Orang yang menetapkan aturan-aturan yang harus dipenuhi oleh perangkat lunak

– Perekayasa perangkat lunak. Orang yang mengembangkan perangkat lunak

Manajemen dan Dukungan Proses

• Memungkinkan hubungan antara kegiatan proses yang teridentifikasi dalam model proses dengan masalah biaya, sumber daya manusia, pelatihan, dan peralatan.

Peningkatan dan Kualitas Proses

• Topik ini berkaitan dengan penilaian kualitas dan peningkatan proses kebutuhan

• Tujuannya adalah menekankan peran penting kebutuhan proses yang berjalan dari segi biaya dan ketepatan waktu, dan kepuasan pelanggan terhadapnya.

• Topik ini meliputi :– Pengkaveran proses kebutuhan oleh model dan standar

peningkatan proses– Pengukuran dan benchmarking proses kebutuhan– Perencanaan dan implementasi peningkatan

Elisitasi Kebutuhan

• Berkaitan dengan dari mana kebutuhan perangkat lunak berasal dan bagaimana mengumpulkannya

• Salah satu prinsip dasar rekayasa perangkat lunak adalah komunikasi yang baik antara pengguna perangkat lunak dan pengembangnya.

Sumber Kebutuhan

• Hal utama yang akan dibahas adalah :– Tujuan

Tujuan tingkat tinggi secara keseluruhan. Tujuan menyediakan motivasi perangkat lunak, tetapi sering kali diformulasikan secara tersamar. Perekayasa perangkat lunak perlu memberikan perhatian lebih untuk menilai nilai dan biaya tujuan (melakukan studi kelayakan)

– Domain pengetahuan– Stakeholder– Lingkungan operasional. Kendala waktu dalam batasan

perngkat lunak real-time, interoperabilitas di lingkungan kantor

– Lingkungan organisasi. Struktur, budaya, dan politik internal organisasi

Teknik Elisitasi

• Teknik yang biasa digunakan :– Wawancara– Skenario– Prototip– Pertemuan terfasilitasi– Observasi

Analisis Kebutuhan

• Tujuan analisis kebutuhan adalah :– Mendeteksi dan menyelesaikan konflik diantara

kebutuhan-kebutuhan– Menemukan batasan perangkat lunak dan bagaimana

harus berinteraksi dengan lingkungan– Mengelaborasikan kebutuhan sistem untuk mendapatkan

kebutuhan perangkat lunak

Klasifikasi Kebutuhan

• Kebutuhan dapat diklasifikasikan menjadi :– Kebutuhan fungsional dan non-fungsional– Kebutuhan yang didapatkan dari satu atau lebih

kebutuhan tingkat tinggi atau emergent properties– Kebutuhan pada produk atau proses– Prioritas kebutuhan– Lingkup kebutuhan– Volatilitas / stabilitas

Pemodelan Konseptual

• Tujuan pemodelan konseptual adalah untuk membantu memahami masalah, bukan untuk memulai desain dari solusi

• Model konseptual terdiri dari model entitas dari domain masalah terkonfigurasi untuk mencerminkan hubungan dan dependensi dunia nyata mereka

• Jenis model yang dapat dikembangkan adalah aliran data dan kendali, state model, jejak peristiwa, interaksi pengguna, model objek, model data, dll.

• Faktor-faktor yang mempengaruhi pilihan model diantaranya :– Sifat dari masalah– Keahlian insinyur perangkat lunak– Kebutuhan proses dari pelanggan– Ketersediaan metode dan peralatan

Desain Arsitektur dan Alokasi Kebutuhan

• Desain arsitektur adalah titik di mana kebutuhan proses tumpang tindih dengan desain sistem atau perangkat lunak dan menggambarkan bagaimana mungkin memisahkan dua tugas secara rapi.

• Dalam banyak kasus insinyur perangkat lunak bertindak sebagai arsitek perangkat lunak karena proses menganalisis dan menguraikan kebutuhan akan teridentifikasi melalui komponen yang sesuai.

• Desain arsitektur teridentifikasi melalui pemodelan konseptual.

• Begitu satu set kebutuhan telah dialokasikan untuk komponen, kebutuhan individu dapat dianalisa lebih lanjut untuk mengetahui lebih lanjut tentang bagaimana kebutuhan komponen yang akan berinteraksi dengan komponen lain untuk memenuhi kebutuhan yang dialokasikan.

Negosiasi Kebutuhan

• Menyelesaikan masalah yang sehubungan dengan kebutuhan yang menjadi konflik antara dua pihak yang membutuhkan fitur yang saling bertentangan, antara kebutuhan dan sumber daya, atau antara kebutuhan fungsional dan non fungsional

Dokumen Definisi Sistem

• Dokumen berisi kebutuhan sistem dengan latar belakang informasi tentang tujuan keseluruhan sistem, lingkungan targetnya dan pernyataan constrain, asumsi, dan kebutuhan non fungsional

• Termasuk juga model konseptual yang dirancang untuk menggambarkan konteks sistem, skenario penggunaan dan entitas domain utama, data, informasi, dan workflow.

Spesifikasi Kebutuhan Sistem

• Kebutuhan sistem yang ditentukan adalah kebutuhan perangkat lunak yang berasal dari kebutuhan sistem, kemudian menentukan kebutuhan untuk komponen perangkat lunak

Spesifikasi Kebutuhan Perangkat Lunak

• Spesifikasi kebutuhan perangkat lunak menetapkan persetujuan antara pelanggan dan kontraktor atau pemasok tentang apa yang akan dilakukan dan tidak dilakukan oleh produk perangkat lunak

• Spesifikasi kebutuhan perangkat lunak memungkinkan penentuan kebutuhan secara ketat sebelum memulai desain dan kemudian mengurangi redesain. Hal ini juga harus memberikan dasar yang realistis untuk memperkirakan biaya produk, risiko, dan jadwal

Review Kebutuhan

• Kebutuhan mungkin akan divalidasi untuk memastikan bahwa insinyur perangkat lunak telah memahami kebutuhan, dan juga penting untuk memverifikasi bahwa dokumen kebutuhan sesuai dengan standar perusahaan, dapat dipahami, konsisten, dan lengkap.

• Cara yang paling umum adalah dengan pemeriksaan validasi atau review dari dokumen kebutuhan

• Sekelompok pe-review ditugaskan untuk mencari kesalahan dengan jelas, asumsi keliru, kurangnya kejelasan, dan penyimpangan dari praktek standar.

• Review harus dibentuk pada saat penyelesaian dokumen definisi sistem, dokumen spesifikasi sistem, dokumen spesifikasi kebutuhan perangkat lunak, spesifikasi dasar untuk rilis baru, atau pada setiap langkah lain dalam proses.

Prototyping

• Prototyping umumnya sarana untuk memvalidasi interpretasi insinyur perangkat lunak dari kebutuhan perangkat lunak serta untuk memunculkan kebutuhan baru

• Keuntungan prototipe adalah interpretasi terhadap asumsi insinyur perangkat lunak menjadi lebih mudah, dan bila diperlukan dapat diberikan umpan balik yang berguna

• Kelemahan prototipe adalah dapat mengganggu perhatian pelanggan terhadap fungsionalitas inti dan kualitas

Validasi Model

• Diperlukan untuk memvalidasi kualitas model yang dikembangkan selama analisis

Penerimaan Pengujian

• Properti penting dari suatu kebutuhan perangkat lunak adalah bahwa hal itu harus mungkin untuk produk yang diselesaikan telah memenuhi kebutuhan tersebut

• Mengidentifikasi dan merancang pengujian penerimaan untuk kebutuhan non-fungsional mungkin sulit dilakukan, oleh karena itu harus dianalisa ke titik dimana mereka dapat dinyatakan secara kuantitatif terlebih dahulu

Sifat Iteratif Proses Kebutuhan

• Ada tekanan umum dalam industri perangkat lunak untuk siklus pengembangan yang lebih pendek.

• Kebutuhan biasanya beriterasi menuju tingkat kualitas dan detail yang cukup untuk memungkinkan desaindan pengadaan keputusan yang harus dibuat

• Pada hampir semua kasus, pemahaman kebutuhan terus berkembang sebagai hasil desain dan pengembangan

Manajemen Perubahan

• Manajemen perubahan adalah pusat pada manajemen kebutuhan

• Topik ini menggambarkan peranan manajemen perubahan, prosedur yang perlu diletakkan, dan analisis yang harus diterapkan pada perubahan yang diajukan

Atribut Kebutuhan

• Kebutuhan harus terdiri dari spesifikasi dari apa yang dibutuhkan, informasi tambahan yang membantu mengelola dan menginterpretasikan kebutuhan.

• Ini harus mencakup dimensi klasifikasi berbagai kebutuhan dan metode verifikasi atau rencana penerimaan tes.

• Ini juga mungkin menyertakan informasi tambahan seperti alasan ringkasan untuk setiap kebutuhan, sumber kebutuhan masing-masing, dan sejarah perubahan.

• Kebutuhan yang paling penting atribut, bagaimanapun, adalah sebuah identifier yang memungkinkan kebutuhan untuk secara unik dan jelas diidentifikasi.

Pelacakan Kebutuhan

• Menelusuri kebutuhan berkaitan dengan memulihkan sumber kebutuhan dan memprediksi dampak dari kebutuhan

• Sebuah kebutuhan harus dapat dilacak ke belakang dan stakeholder yang memotivasinya

• Kebutuhan harus dapat dilacak ke depan ke dalam kebutuhan dan entitas desain yang memuaskannya

Mengukur Kebutuhan

• Sebagai masalah praktis, itu biasanya berguna untuk memiliki beberapa konsep "volume" dari persyaratan untuk produk perangkat lunak tertentu.

• Nomor ini berguna dalam mengevaluasi "ukuran“ (size) dari perubahan dalam kebutuhan, dalam mengestimasi biaya tugas pengembangan atau pemeliharaan, atau hanya untuk digunakan sebagai penyebut dalam pengukuran lainnya.

• Pengukuran Ukuran Fungsional (Functional Size Measurement) adalah teknik untuk mengevaluasi ukuran tubuh kebutuhan fungsional. IEEE Std 14.143,1 mendefinisikan konsep FSM. Standar dari ISO / IEC dan sumber lainnya menjelaskan metode FSM