REKAYASA KEBUTUHAN SOFTWARE

Requirement Process

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.

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.

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.

Requirements Elicitation

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.

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.

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.

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.

Requirement Analysis

Klasifikasi Requirements Fungsional dan non fungsional Apakah suatu requirement didapat dari satu atau lebih requirement yang berlevel lebih tinggi atau merupakan emergent propety (sub bagian 1.4) atau ditetapkan oleh pihak yang berkepentingan atau sumber lain. Apakah requirement ada pada produk atau proses. Prioritas. Secara umum, semakin tinggi prioritas suatu requirement semakin mendesak pula untuk dipenuhi dalam produk akhir. Cakupan dari requirement. . Hal ini sangat berpengaruh pada arsitektur software dan desain komponen. Stabilitas. Requirement kadang berubah dalam suatu siklus hidup software bahkan mungkin dalam proses pengembangannya.

Conceptual Modelling Pemodelan dari permaslahan riil adalah kunci dari analisa software requirements. Tujuannya untuk membantu memahami permasalahan. Model konseptual terdiri dari model entitas – entitas dari domain permasalahan yang disusun untuk mewakili relasi riil dan ketergantungan riil. Ada beberapa model yang bisa dikembangkan. Antara lain aliran data dan kontrol, model keadaan, pelackan even, interaksi pengguna, model obyek, model data dan lain – lain.

Conceptual Modelling Faktor yang mempengaruhi pemilihan pemodelan: Sifat dari permasalahan. Beberapa tipe software menuntut agar aspek tertentu dianalisa secara menyeluruh Keahlian perekayasa software. Lebih baik menggunakan notasi atau metode permodelan yang sudah familier. Process requierement dari pelanggan. Mungkin pelangan ingin menetapkan notasi atau metode pemodelan tertentu Ketersediaan metode dan alat. Meskipun cocok namun jika tidak ditunjang dengan keahlian dan alat yang baik, suatu notasi atau metode tidak bisa dipakai.

Desain Arsitektural dan Alokasi Requirement Desain arsitektural adalah suatu tahap di mana requirement process dilakukan bersamaan dengan desain sistem atau software. Karenanya sulit memisahkan dua aktivitas tersebut. Desain arsitektural sangat berhubungan dengan pemodelan konseptual. Pemetaan domain entitas dunia nyata menjadi komponen software tidak selalu jelas, sehingga desain arsitektural dianggap sebagai topik terpisah. Requirement untuk notasi dan metode secara umum sama pada pemodelan konseptual dan desain arsitektural.

Negosiasi Requirement Topik ini disebut juga sebagai “penyelesaian konflik”. Topik ini membahas penanganan masalah requirement di mana timbul konflik antara dua pihak yang sama – sama berkepentingan, antara requirement dengan sumber daya atau requirement fungsional dan non fungsional. Dalam kebanyakan kasus, keputusan yang diambil secara unilateral bukanlah sikap bijaksana. Karenanya penting untuk mencapai konsensus dengan pihak yang berkepentingan.

Spesifikasi Requirement

Spesifikasi Requirement Pada kebanyakan profesi perekayasaan, istilah spesifikasi merujuk pada kegiatan memberikan nilai numerik atau batas pada tujuan produk akhir. Tetapi definisi ini tidak bisa dipakai pada rekayasa perangkat lunak mengingat banyaknya requirement yang ada dan kompleksitas interaksinya. Karenanya pada rekayasa perangkat lunak istilah “spesifikasi requirement software” mengacu pada pembuatan dokumen baik fisik maupun elektronis.

Pada sistem yang kompleks, terutama yang melibatkan banyak kompone non software, ada 3 jenis dokumen yang dibuat yaitu definisi sistem, requirement sistem dan requirement perangkat lunak. Pada produk software yang sederhana hanya satu dari 3 jenis dokumen itu yang perlu dibuat. Semua tiga jenis dokumen itu akan dijelaskan di sini.

5.1: Dokumen Definisi Sistem Dokumen ini menyimpan requirement sebuah sistem. Dokumen ini mendaftar semua requirement beserta keterangan latar belakang tujuan keseluruhan sebuah sistem, lingkungan yang menjadi sasaran dan pernyataan batasan, asumsi dan requirement non-fungsional. Mungkin juga di dalamnya terdapat model konseptual yang didesain untuk memberikan gambaran tentang konteks sistem, skenario pemakaian dan entitas - entitas domain yang penting, termasuk juga data, informasi dan aliran kerja.

5.2: Spesifikasi Requirement Sistem. Para pengembang dari sebuah sistem berkomponen software dan non-software yang cukup banyak, seringkali memisahkan deskripsi dari requirement sistem dari deskripsi requirement software. Dengan cara ini, requirement sistem dispesifikasikan, requirement software didapat dari requirement sistem dan requirement untuk komponen sosftware dispesifikasikan . Karena merupakan bidang rekayasa sistem, dokumen jenis ini tidak akan dibahas terperinci di sini.

5.3: Spesifikasi Requirement Software Dokumen jenis ini mendirikan dasar untuk sebuah perjanjian antara pelanggan dan kontraktor atau penyuplai tentang apa yang seharusnya dan tidak seharusnya dikerjakan oleh produk software. Untuk pembaca yang kurang paham hal – hal yang sifanya teknis, dokumen jenis ini juga didampingi oleh dokumen definisi requirement software.

Dokumen ini memungkinkan penilaian mendalam tentang requirement sebelum desain dimulai sehingga mengurangi keharusan desain ulang. Dokumen ini juga memberikan dasar – dasar realistis untuk memperkirakan biaya, risiko dan jadwal produksi.

Requirements validation

Requirements validation Kebutuhan dokumen difokuskan pada prosedur validasi dan verifikasi. Kebutuhan akan validasi untuk meyakinkan bahwa software engineer telah mengerti tentang requirement yang diperlukan, dan juga sangat penting untuk membuktikan bahwa requirements document dapat disesuaikan dengan kebutuhan standard suatu perusahaan, dan juga dapat mudah dipahami, konsisten, dan lengkap.

6.1: Requirements Reviews Arti umum validation adalah memeriksaan (inspection) atau review (meninjau) requirements document. Reviewer bertugas mencari error (look for errors), asumsi yang salah (mistaken assumptions), hal-halyang kurang jelas (lack of clarity), dan penyimpangan standar (deviation from standard practice). Hal ini sangat penting dan munkin membantu memberikan petunjuk apa yang dicari dalam tabel checklists. Review terdapat pada : penyelesaian dari system definition document system specification document software requirements specification document baseline specification for a new release atau pada langkah lain dalam suatu proses

6.2: Prototyping Prototyping secara umum berarti untuk melakukan validasi, interpretasi software engineer mengenai software requirements, sama seperti memperoleh requirement baru. Keuntungan dari prototype adalah akan memudahkan software engineer menginterpretasikan asumsinya dan juga berguna untuk mengetahui kembali jika terdapat kesalahan.

6.3: Model Validation Merupakan suatu hal yang dibutuhkan untuk mengesahkan kualitas suatu model yang sedang dianalisis. Sebagai contoh, dalam objek model sangat berguna untuk melakukan static anlisis untuk menguji bahwa jalur komunikasi antara objek itu ada, dimana dalam daerah stakeholders, terjadi pertukaran data. Jika formal specification notations digunakan, sangat memungkinkan untuk menggunakan formal reasoning untuk membuktikan spesifikasi properties.

6.4: Acceptance Tests Property yang diperlukan dari sebuah software requirement adalah bahwa sangat mungkin untuk mengesahkan produk yang telah selesai dapat memenuhinya. Requirements yang tidak dapat divalidasi merupakan hanya sebuah ‘keinginan’. Sebuah tugas yang penting adalah merencanakan bagaimana menguji masing-masing requirement. Dalam berbagai kasus, desain acceptance tests yang melakukannya. Mengidentifikasi dan mendesain acceptance tests mungkin sangat sulit untuk non-functional requirement. Agar bisa divalidasi, pertama harus dianalisis pada poin dimana dapat ditunjukkan secara kuantitatif.

Practical Considerations

Practical Considerations Tidak semua organisasi mempunyai kebiasaan mendokumentasikan dan mengatur requirement. Bagaimanapun, sebagai perusahaan yang berkembang, pelanggan mereka bertumbuh, dan produk mulai berkembang, mereka menemukan bahwa mereka perlu untuk memulihkan keperluan – keperluan yang mendukung fitur produk agar dapat menaksir gangguan dari perubahan tujuan. Oleh sebab itu, requirements documentation dan pengubahan management adalah kunci sukses dari requirements process.

7.1: Iterative Nature of Requirements Process Kebanyakan proyek didesak oleh lingkungannya, dan banyak perubahan, atau revisi, dari software yang ada. Sehingga, selalu tidak bisa dijalankan untuk implementasi requirement process sebagai sebuah linear, dan penanganan lebih pada tim software development.

Pada beberapa proyek, hal ini bisa saja menghasilkan/berdampak dalam kebutuhan yang digariskan sebelum semua propertinya benar-benar dipahami. Point yang paling penting dalam mengerti requirement engineering adalah proporsi yang signifikan dari requirement yang akan berubah. Kadang- kadang dikarenakan error pada analisa, tapi ini sering akibat perubahan lingkungan yang tak dapat dihindarkan. Contohnya, operasi pelanggan atau lingkungan bisnis, atau pasar dimana software harus dijual.

7.2: Change management Change management adalah pusat untuk mengatur requirement. Topik ini menggambarkan peran dari change management, prosedur yang diperlukan, dan analisa yang seharusnya digunakan untuk usulan pengubahan. Ini telah memperkuat hubungan Software Configuration Management Knowledge Area.

7.3: Requirements Attributes Requirement sebaiknya tidak hanya terdiri dari perincian dari apa yang dibutuhkan, tapi juga dari informasi tambahan yang mana membantu mengatur dan menafsirkan requirement tersebut. Mungkin juga memasukkan informasi tambahan seperti kesimpulan dari masing- masing requirement, sumber daya dari masing- masing requirement, dan perubahan sejarah. Requirement attribute yang paling penting adalah sebuah pengenal yang mana memperbolehkan requirement tersebut unik dan jelas.

7.4: Requirements Tracing Requirements Tracing diperhatikan dengan pemulihan sumber daya requirement dan memprediksikan efek dari requirement. Tracing adalah pokok untuk melakukan analisa ketika requirement berubah. Sebuah requirement sebaiknya dapat di- trace ke belakang. Contoh, dari software requirement kembali ke system requirement.

Sebaliknya, requirement sebaiknya dapat di- trace ke depan Sebaliknya, requirement sebaiknya dapat di- trace ke depan. Contoh, dari system requirement ke software requirement yang telah diuraikan, dan ke kode modul yang mengimplementasikannya. Requirement Tracing untuk proyek yang khusus akan membentuk DAG ( Directed Acyclic Graph) yang kompleks dari requirement.

7.5: Measuring Requirement Sebagai sebuah bentuk yang praktis, biasanya digunakan untuk mempunyai beberapa konsep ‘volume’ requirement untuk produk software. Jumlah ini digunakan dalam mengevaluasi ukuran pada perubahan dalam requirement, dalam estimasi harga development atau tugas maintenance, atau menyerderhanakan penggunaan sebagai denominator pada pengukur lain. FSM ( Functional Size Measurement ) adalah sebuah teknik untuk mengevaluasi ukuran badan dari fungsi requirement. IEEE Std 14143.1 mendefinisikan konsep dari FSM. Informasi tambahan ukuran dan standard akan ditemukan di Software Engineering Process Knowledge Area.

TUGAS RK I KELOMPOK 5 ORANG 1 JURNAL REKAYASA KEBUTUHAN : HARDWARE SOFTWARE SYSTEM REG, PARAMETER (MODEL DAN PROCESS), NONFUNG, FUNGSIONAL, EMERGENT, QUANTIFI, DLL)