REKAYASA KEBUTUHAN SOFTWARE

Presentasi berjudul: "REKAYASA KEBUTUHAN SOFTWARE"— Transcript presentasi:

1 REKAYASA KEBUTUHAN SOFTWARE

2 Dasar – Dasar

3 Definisi software requirement adalah sebuah properti yang harus diperlihatkan /ditunjukkan oleh software untuk menyelesaikan suatu permasalahan yang ada di dunia nyata / bersifat riil. merupakan kombinasi rumit dari kebutuhan berbagai orang di bermacam – macam tingkat organisasi dan lingkungan di mana perangkat lunak akan dioperasikan. properti yang esensial dari semua software requirement adalah harus mampu diperiksa/diverifikasi.

4

5 Product and Process requirement
Parameter produk adalah requirement pada software untuk dikembangkan (Contohnya “Software harus memeriksa prasyarat mata kuliah yang diambil mahasiswa”) Parameter proses adalah batasan – batasan dalam mengembangkan software. Contohnya pilihan teknik verifikasi. Process requirement juga bisa ditetapkan oleh organisasi pengembang, pelanggan atau pihak ketiga seperti badan regulator.

6 Requirement fungsional dan nonfungsional
Requirments fungsional menjabarkan fungsi – fungsi yang akan dilaksanakan software. Contohnya memformat teks. Kadang – kadang disebut juga sebagai kapabilitas. Requirements non-fungsional memberikan batasan terhadap solusi yang akan dihasilkan. Disebut juga sebagai quality requirement. Requirement jenis ini masih bisa dibagi lagi menjadi performance requirements, maintainability requirements, safety requirements, reliability requirements atau salah satu software requirements lainnya.

7

8 Emergent Properties Beberapa requirement merupakan perwakilan dari emergent properties yaitu requirement yang tidak bisa ditangani oleh satu komponen saja. Keberhasilan dalam menanganinya juga bergantung pada interoperasi dari berbagai komponen yang ada. Emergent properties amat bergantung pada arsitektur sistem.

9 Quantifiable Requirements
Software requirement harus bisa dinyatakan dengan jelas, tidak ambigu dan pada beberapa bagiannya yang sesuai, kuantitatif. Contoh requirement yang memenuhi syarat: Sebuah perangkat lunak dari suatu call central harus meningkatkan throughput sebanyak 20% dan sistemnya hanya menghasilkan kesalahan fatal dengan peluang kurang dari 1*10-8.

10 System Requirements dan Software Requirements
Dalam topik ini sistem berarti kombinasi dari elemen – elemen yang berinteraksi untuk mencapai suatu tujuan yang terdefinisikan. Ini termasuk hardware, software, firmware, manusia, informasi, tehnik, fasilitas, layanan dan berbagai elemen pendukung lainnya System requirement adalah requirement untuk sistem secara keseluruhan. Dalam sebuah sistem yang mengandung komponen software, software requirement diperoleh dari system requirement.

11 Requirement Process

12 Process Models Bukan kegiatan berawal – berakhir secara diskrit tetapi dimulai dari awal suatu proyek dan terus diperhalus selama siklus hidup software. Mengidentifikasi software requirement sebagai konfigurasi item – item dan mengaturnya dengan praktik – praktik manajemen konfigurasi software yang sama dengan produk – produk lain dari proses – proses siklus hidup software tersebut. Perlu diadaptasikan sesuai dengan konteks organisasi dan proyek.

13 Process Actors Pengguna : kelompok yang kelak akan mengoperasikan software. Pelanggan : Kelompok inilah yang akan memberlakukan suatu software ke dalam suatu organisasi. Analis Pasar : Analis pasar diperlukan untuk mengetahui kebutuhan pasar. Regulator : Banyak bidang di mana aplikasi terkena regulasi misalnya perbankan dan transportasi umum. Karenanya software yang dioperasikan pada bidang – bidang semacam ini harus sesuai dengan ketentuan dari badan regulator yang berwenang. Perekayasa software : Kelompok ini memiliki hak yang sah untuk mengambil keuntungan dari pengembangan suatu software, termasuk menggunakan ulang beberapa komponennya untuk produk lain.

14 Process Quality and Improvement
Membahas penilaian kualitas dan peningkatan dari suatu requirement process. Tujuannya adalah untuk menekankan peran kunci requirement process dari segi biaya dan masa berlaku suatu produk software dan kepuasan pelanggan.

15 Requirements Elicitation

16 Sumber – Sumber Requirements
Tujuan. Tujuan bisa memberi motivasi bagi pembuatan software tetapi sayangnya sering diformulasikan secara samar. Karenanya perlu dinilai biaya dan nilainya secara jelas. Pengetahuan akan domain. Seseorang perekayasa software harus mengetahui domain dari aplikasi yang dikerjakannya. Pihak yang berkepentingan. Banyak software yang tidak memuaskan karena terlalu condong pada kepentingan pihak tertentu saja dan mengorbankan pihak lain. Hendaknya dipahami dan dicapai keseimbangan dari sudut pandang tiap pihak.

17 Sumber – Sumber Requirements
Lingkungan operasional. Requirement akan disusun dari lingkungan di mana software akan bekerja. Misalnya batasan timing untuk real – time software atau kemampuan interoperasional Lingkungan organisasional. Seringakali suatu software dibuat untuk menunjang proses bisnis. Karenanya perlu diperhatikan struktur, budaya kerja dan situasi politik dari organisasi yang bersangkutan.

18 Elicitation Techniques
Wawancara. Merupakan tehnik yang paling tradisional. Perlu diketahui batasan dan tata caranya. Skenario. Tehnik ini mampu memberikan konteks untuk menyusun requirement bagi pengguna. Memberikan kerangka kerja bagi perekayasa software dengan membolehkan pertanyaan seperti “Bagaimana jika…” atau “Bagaimana ini dikerjakan”. Prototipe. Tehnik ini bisa memberi kejelasan pada requirement yang masih kabur. Tehnik ini bertindak mirip dengan skenario karena bisa memberikan konteks di mana pengguna bisa tahu informasi apa yang harus diberikan.

19 Elicitation Techniques
Pertemuan terfasilitasi. Tehnik ini baik untuk menghimpun pandangan berbagai pihak yang berkepentingan. Bisa pula timbul – saran atau ide yang membantu. Selain itu juga bisa mengenali konflik antar requirement. Tetapi pertemuan sebaiknya menggunakan jasa seorang fasilitator untuk mencegah / mengendalikan kemungkinan dominasi pihak tertentu. Observasi. Tehnik ini relatif mahal tapi wajib karena mungkin saja proses bisnis terlau kompleks dan canggih untuk dijelaskan secara lisan. Perekayasa software harus masuk ke dalam lingkungan kerja pengguna dan mengamati interaksi pengguna dengan software dan sesama pengguna lain.