SOFTWARE SOFTWARE REQUIREMENTSREQUIREMENTS
Dasar – Dasar Software Dasar – Dasar Software RequirementsRequirements
DefinisiDefinisi
software requirement adalah sebuah properti software requirement adalah sebuah properti yang harus diperlihatkan /ditunjukkan oleh yang harus diperlihatkan /ditunjukkan oleh software untuk menyelesaikan suatu software untuk menyelesaikan suatu permasalahan yang ada di dunia nyata / bersifat permasalahan yang ada di dunia nyata / bersifat riil.riil.
merupakan kombinasi rumit dari kebutuhan merupakan kombinasi rumit dari kebutuhan berbagai orang di bermacam – macam tingkat berbagai orang di bermacam – macam tingkat organisasi dan lingkungan di mana perangkat organisasi dan lingkungan di mana perangkat lunak akan dioperasikan.lunak akan dioperasikan.
properti yang esensial dari semua software properti yang esensial dari semua software requirement adalah harus mampu requirement adalah harus mampu diperiksa/diverifikasi.diperiksa/diverifikasi.
Product and Process requirementProduct and Process requirement
KebutuhanKebutuhan produk adalah requirement produk adalah requirement pada software untuk dikembangkan pada software untuk dikembangkan (Contohnya “Software harus memeriksa (Contohnya “Software harus memeriksa prasyarat mata kuliah yang diambil prasyarat mata kuliah yang diambil mahasiswa”)mahasiswa”)
Kebutuhan Kebutuhan proses adalah batasan – proses adalah batasan – batasan dalam mengembangkan software.batasan dalam mengembangkan software. Contohnya pilihan teknik verifikasi. Contohnya pilihan teknik verifikasi. Process requirement juga bisa ditetapkan Process requirement juga bisa ditetapkan oleh organisasi pengembang, pelanggan oleh organisasi pengembang, pelanggan atau pihak ketiga seperti badan regulator.atau pihak ketiga seperti badan regulator.
Requirement fungsional dan Requirement fungsional dan nonfungsionalnonfungsional
RequirRequireements fungsional menjabarkan fungsi – ments fungsional menjabarkan fungsi – fungsi yang akan dilaksanakan software. fungsi yang akan dilaksanakan software. Contohnya memformat teks. Kadang – kadang Contohnya memformat teks. Kadang – kadang disebut juga sebagai kapabilitas.disebut juga sebagai kapabilitas.
Requirements non-fungsional memberikan Requirements non-fungsional memberikan batasan terhadap solusi yang akan dihasilkan. batasan terhadap solusi yang akan dihasilkan. Disebut juga sebagai quality requirement. Disebut juga sebagai quality requirement. Requirement jenis ini masih bisa dibagi lagi Requirement jenis ini masih bisa dibagi lagi menjadi performance requirements, menjadi performance requirements, maintainability requirements, safety maintainability requirements, safety requirements, reliability requirements atau salah requirements, reliability requirements atau salah satu software requirements lainnya. satu software requirements lainnya.
Emergent PropertiesEmergent Properties
Beberapa requirement merupakan Beberapa requirement merupakan perwakilan dari emergent properties yaitu perwakilan dari emergent properties yaitu requirement yang tidak bisa ditangani oleh requirement yang tidak bisa ditangani oleh satu komponen saja. satu komponen saja. Keberhasilan dalam Keberhasilan dalam menanganinya juga bergantung pada menanganinya juga bergantung pada interoperasi dari berbagai komponen yang interoperasi dari berbagai komponen yang ada. ada. Emergent properties amat bergantung Emergent properties amat bergantung pada arsitektur sistem. pada arsitektur sistem.
Quantifiable Requirements Quantifiable Requirements
Software requirement harus bisa dinyatakan Software requirement harus bisa dinyatakan dengan jelas, tidak ambigu dan pada dengan jelas, tidak ambigu dan pada beberapa bagiannya yang sesuai, beberapa bagiannya yang sesuai, kuantitatif.kuantitatif.
Contoh requirement yang memenuhi syarat: Contoh requirement yang memenuhi syarat: Sebuah perangkat lunak dari suatu call Sebuah perangkat lunak dari suatu call central harus meningkatkan throughput central harus meningkatkan throughput sebanyak 20% dan sistemnya hanya sebanyak 20% dan sistemnya hanya menghasilkan kesalahan fatal dengan menghasilkan kesalahan fatal dengan peluang kurang dari 1*10-8.peluang kurang dari 1*10-8.
System Requirements dan System Requirements dan Software Requirements Software Requirements
Dalam topik ini sistem berarti kombinasi Dalam topik ini sistem berarti kombinasi dari elemen – elemen yang berinteraksi dari elemen – elemen yang berinteraksi untuk mencapai suatu tujuan yang untuk mencapai suatu tujuan yang terdefinisikan. Ini termasuk hardware, terdefinisikan. Ini termasuk hardware, software, firmware, manusia, informasi, software, firmware, manusia, informasi, tehnik, fasilitas, layanan dan berbagai tehnik, fasilitas, layanan dan berbagai elemen pendukung lainnyaelemen pendukung lainnya
System requirement adalah requirement System requirement adalah requirement untuk sistem secara keseluruhan. Dalam untuk sistem secara keseluruhan. Dalam sebuah sistem yang mengandung sebuah sistem yang mengandung komponen software, software requirement komponen software, software requirement diperoleh dari system requirement. diperoleh dari system requirement.
Requirement ProcessRequirement Process
Process ModelsProcess Models Bukan kegiatan berawal – berakhir secara Bukan kegiatan berawal – berakhir secara
diskrit tetapi dimulai dari awal suatu diskrit tetapi dimulai dari awal suatu proyek dan terus diperhalus selama siklus proyek dan terus diperhalus selama siklus hidup software.hidup software.
Mengidentifikasi software requirement Mengidentifikasi software requirement sebagai konfigurasi item – item dan sebagai konfigurasi item – item dan mengaturnya dengan praktik – praktik mengaturnya dengan praktik – praktik manajemen konfigurasi software yang manajemen konfigurasi software yang sama dengan produk – produk lain dari sama dengan produk – produk lain dari proses – proses siklus hidup software proses – proses siklus hidup software tersebut.tersebut.
Perlu diadaptasikan sesuai dengan Perlu diadaptasikan sesuai dengan konteks organisasi dan proyek.konteks organisasi dan proyek.
Process Actors Process Actors PenggunaPengguna : : kelompok yang kelak akan kelompok yang kelak akan
mengoperasikan software.mengoperasikan software. Pelanggan : Kelompok inilah yang akan Pelanggan : Kelompok inilah yang akan
memberlakukan suatu software ke dalam suatu memberlakukan suatu software ke dalam suatu organisasi.organisasi.
Analis Pasar : Analis pasar diperlukan untuk Analis Pasar : Analis pasar diperlukan untuk mengetahui kebutuhan pasar.mengetahui kebutuhan pasar.
Regulator : Banyak bidang di mana aplikasi terkena Regulator : Banyak bidang di mana aplikasi terkena regulasi misalnya perbankan dan transportasi umum. regulasi misalnya perbankan dan transportasi umum. Karenanya software yang dioperasikan pada bidang – Karenanya software yang dioperasikan pada bidang – bidang semacam ini harus sesuai dengan ketentuan bidang semacam ini harus sesuai dengan ketentuan dari badan regulator yang berwenang.dari badan regulator yang berwenang.
Perekayasa software : Kelompok ini memiliki hak yang Perekayasa software : Kelompok ini memiliki hak yang sah untuk mengambil keuntungan dari sah untuk mengambil keuntungan dari pengembangan suatu software, termasuk pengembangan suatu software, termasuk menggunakan ulang beberapa komponennya untuk menggunakan ulang beberapa komponennya untuk produk lain.produk lain.
Process Quality and Process Quality and
ImprovementImprovement
Membahas penilaian kualitas dan Membahas penilaian kualitas dan peningkatan dari suatu requirement peningkatan dari suatu requirement
process. process. Tujuannya adalah untuk Tujuannya adalah untuk menekankan peran kunci requirement menekankan peran kunci requirement
process dari segi biaya dan masa berlaku process dari segi biaya dan masa berlaku suatu produk software dan kepuasan suatu produk software dan kepuasan
pelanggan. pelanggan.
Requirements ElicitationRequirements Elicitation
Sumber – Sumber RequirementsSumber – Sumber Requirements
Tujuan. Tujuan. Tujuan bisa memberi motivasi bagi Tujuan bisa memberi motivasi bagi pembuatan software tetapi sayangnya sering pembuatan software tetapi sayangnya sering diformulasikan secara samar. diformulasikan secara samar. Karenanya perlu Karenanya perlu dinilai biaya dan nilainya secara jelas.dinilai biaya dan nilainya secara jelas.
Pengetahuan akan domain.Pengetahuan akan domain. Seseorang Seseorang perekayasa software harus mengetahui domain perekayasa software harus mengetahui domain dari aplikasi yang dikerjakannya.dari aplikasi yang dikerjakannya.
Pihak yang berkepentingan. Banyak software Pihak yang berkepentingan. Banyak software yang tidak memuaskan karena terlalu condong yang tidak memuaskan karena terlalu condong pada kepentingan pihak tertentu saja dan pada kepentingan pihak tertentu saja dan mengorbankan pihak lain.mengorbankan pihak lain. H Hendaknya dipahami endaknya dipahami dan dicapai keseimbangan dari sudut pandang dan dicapai keseimbangan dari sudut pandang tiap pihak.tiap pihak.
Sumber – Sumber RequirementsSumber – Sumber Requirements
Lingkungan operasional.Lingkungan operasional. Requirement Requirement akan disusun dari lingkungan di mana akan disusun dari lingkungan di mana software akan bekerja. Misalnya batasan software akan bekerja. Misalnya batasan timing untuk real – time software atau timing untuk real – time software atau kemampuan interoperasionalkemampuan interoperasional
Lingkungan organisasional. Seringkali Lingkungan organisasional. Seringkali suatu software dibuat untuk menunjang suatu software dibuat untuk menunjang proses bisnis. Karenanya perlu proses bisnis. Karenanya perlu diperhatikan struktur, budaya kerja dan diperhatikan struktur, budaya kerja dan situasi politik dari organisasi yang situasi politik dari organisasi yang bersangkutan.bersangkutan.
Elicitation Techniques Elicitation Techniques Wawancara. Merupakan tehnik yang paling Wawancara. Merupakan tehnik yang paling
tradisional. Perlu diketahui batasan dan tata tradisional. Perlu diketahui batasan dan tata caranya.caranya.
Skenario. Tehnik ini mampu memberikan konteks Skenario. Tehnik ini mampu memberikan konteks untuk menyusun requirement bagi pengguna. untuk menyusun requirement bagi pengguna. Memberikan kerangka kerja bagi perekayasa Memberikan kerangka kerja bagi perekayasa software dengan membolehkan pertanyaan software dengan membolehkan pertanyaan seperti “Bagaimana jika…” atau “Bagaimana ini seperti “Bagaimana jika…” atau “Bagaimana ini dikerjakan”.dikerjakan”.
Prototipe. Tehnik ini bisa memberi kejelasan pada Prototipe. Tehnik ini bisa memberi kejelasan pada requirement yang masih kabur. Tehnik ini requirement yang masih kabur. Tehnik ini bertindak mirip dengan skenario karena bisa bertindak mirip dengan skenario karena bisa memberikan konteks di mana pengguna bisa memberikan konteks di mana pengguna bisa tahu informasi apa yang harus diberikan.tahu informasi apa yang harus diberikan.
Elicitation TechniquesElicitation Techniques Pertemuan terfasilitasi. Tehnik ini baik untuk Pertemuan terfasilitasi. Tehnik ini baik untuk
menghimpun pandangan berbagai pihak yang menghimpun pandangan berbagai pihak yang berkepentingan. Bisa pula timbul – saran atau ide berkepentingan. Bisa pula timbul – saran atau ide yang membantu. Selain itu juga bisa mengenali yang membantu. Selain itu juga bisa mengenali konflik antar requirement. Tetapi pertemuan konflik antar requirement. Tetapi pertemuan sebaiknya menggunakan jasa seorang fasilitator sebaiknya menggunakan jasa seorang fasilitator untuk mencegah / mengendalikan kemungkinan untuk mencegah / mengendalikan kemungkinan dominasi pihak tertentu.dominasi pihak tertentu.
Observasi. Tehnik ini relatif mahal tapi wajib Observasi. Tehnik ini relatif mahal tapi wajib karena mungkin saja proses bisnis terlau karena mungkin saja proses bisnis terlau kompleks dan canggih untuk dijelaskan secara kompleks dan canggih untuk dijelaskan secara lisan. Perekayasa software harus masuk ke dalam lisan. Perekayasa software harus masuk ke dalam lingkungan kerja pengguna dan mengamati lingkungan kerja pengguna dan mengamati interaksi pengguna dengan software dan sesama interaksi pengguna dengan software dan sesama pengguna lain.pengguna lain.
Requirement AnalysisRequirement Analysis
Klasifikasi RequirementsKlasifikasi Requirements Fungsional dan non fungsional Fungsional dan non fungsional Apakah suatu requirement didapat dari satu atau Apakah suatu requirement didapat dari satu atau
lebih requirement yang berlevel lebih tinggi atau lebih requirement yang berlevel lebih tinggi atau merupakan emergent propety (sub bagian 1.4) merupakan emergent propety (sub bagian 1.4) atau ditetapkan oleh pihak yang berkepentingan atau ditetapkan oleh pihak yang berkepentingan atau sumber lain.atau sumber lain.
Apakah requirement ada pada produk atau proses. Apakah requirement ada pada produk atau proses. Prioritas. Secara umum, semakin tinggi prioritas Prioritas. Secara umum, semakin tinggi prioritas
suatu requirement semakin mendesak pula untuk suatu requirement semakin mendesak pula untuk dipenuhi dalam produk akhir.dipenuhi dalam produk akhir.
Cakupan dari requirement. . Hal ini sangat Cakupan dari requirement. . Hal ini sangat berpengaruh pada arsitektur software dan desain berpengaruh pada arsitektur software dan desain komponen.komponen.
Stabilitas. Requirement kadang berubah dalam Stabilitas. Requirement kadang berubah dalam suatu siklus hidup software bahkan mungkin dalam suatu siklus hidup software bahkan mungkin dalam proses pengembangannya.proses pengembangannya.
Conceptual ModellingConceptual Modelling
Pemodelan dari permaslahan riil adalah kunci dari Pemodelan dari permaslahan riil adalah kunci dari analisa software requirements. analisa software requirements. Tujuannya untuk membantu memahami Tujuannya untuk membantu memahami permasalahan. Model konseptual terdiri dari model permasalahan. Model konseptual terdiri dari model entitas – entitas dari domain permasalahan yang entitas – entitas dari domain permasalahan yang disusun untuk mewakili relasi riil dan disusun untuk mewakili relasi riil dan ketergantungan riil. ketergantungan riil. Ada beberapa model yang bisa dikembangkan. Ada beberapa model yang bisa dikembangkan. Antara lain aliran data dan kontrol, model keadaan, Antara lain aliran data dan kontrol, model keadaan, pelacpelacaakan even, interaksi pengguna, model obyek, kan even, interaksi pengguna, model obyek, model data dan lain – lain.model data dan lain – lain.
Conceptual ModellingConceptual ModellingFaktor yang mempengaruhi pemilihan Faktor yang mempengaruhi pemilihan pemodelan:pemodelan:
Sifat dari permasalahan. Beberapa tipe software Sifat dari permasalahan. Beberapa tipe software menuntut agar aspek tertentu dianalisa secara menuntut agar aspek tertentu dianalisa secara menyeluruhmenyeluruh
Keahlian perekayasa software. Lebih baik Keahlian perekayasa software. Lebih baik menggunakan notasi atau metode permodelan menggunakan notasi atau metode permodelan yang sudah familier.yang sudah familier.
Process requierement dari pelanggan. Mungkin Process requierement dari pelanggan. Mungkin pelangan ingin menetapkan notasi atau metode pelangan ingin menetapkan notasi atau metode pemodelan tertentupemodelan tertentu
Ketersediaan metode dan alat. Meskipun cocok Ketersediaan metode dan alat. Meskipun cocok namun jika tidak ditunjang dengan keahlian dan namun jika tidak ditunjang dengan keahlian dan alat yang baik, suatu notasi atau metode tidak alat yang baik, suatu notasi atau metode tidak bisa dipakai.bisa dipakai.
Desain Arsitektural dan Alokasi Desain Arsitektural dan Alokasi
RequirementRequirement Desain arsitektural adalah suatu tahap di mana Desain arsitektural adalah suatu tahap di mana requirement process dilakukan bersamaan dengan requirement process dilakukan bersamaan dengan desain sistem atau software. Karenanya sulit desain sistem atau software. Karenanya sulit memisahkan dua aktivitas tersebut.memisahkan dua aktivitas tersebut. Desain arsitektural sangat berhubungan dengan Desain arsitektural sangat berhubungan dengan pemodelan konseptual. Pemetaan domain entitas pemodelan konseptual. Pemetaan domain entitas dunia nyata menjadi komponen software tidak selalu dunia nyata menjadi komponen software tidak selalu jelas, sehingga desain arsitektural dianggap sebagai jelas, sehingga desain arsitektural dianggap sebagai topik terpisah. Requirement untuk notasi dan metode topik terpisah. Requirement untuk notasi dan metode secara umum sama pada pemodelan konseptual dan secara umum sama pada pemodelan konseptual dan desain arsitektural. desain arsitektural.
Negosiasi RequirementNegosiasi Requirement
Topik ini disebut juga sebagai “penyelesaian Topik ini disebut juga sebagai “penyelesaian konflik”. Topik ini membahas penanganan masalah konflik”. Topik ini membahas penanganan masalah requirement di mana timbul konflik antara dua pihak requirement di mana timbul konflik antara dua pihak yang sama – sama berkepentingan, antara yang sama – sama berkepentingan, antara requirement dengan sumber daya atau requirement requirement dengan sumber daya atau requirement fungsional dan non fungsional. Dalam kebanyakan fungsional dan non fungsional. Dalam kebanyakan kasus, keputusan yang diambil secara unilateral kasus, keputusan yang diambil secara unilateral bukanlah sikap bijaksana. Karenanya penting untuk bukanlah sikap bijaksana. Karenanya penting untuk mencapai konsensus dengan pihak yang mencapai konsensus dengan pihak yang berkepentingan.berkepentingan.
Spesifikasi RequirementSpesifikasi Requirement
Spesifikasi RequirementSpesifikasi Requirement
Pada kebanyakan profesi perekayasaan, istilah Pada kebanyakan profesi perekayasaan, istilah spesifikasi merujuk pada kegiatan memberikan spesifikasi merujuk pada kegiatan memberikan nilai numerik atau batas pada tujuan produk nilai numerik atau batas pada tujuan produk akhir. akhir.
Tetapi definisi ini tidak bisa dipakai pada Tetapi definisi ini tidak bisa dipakai pada rekayasa perangkat lunak mengingat rekayasa perangkat lunak mengingat banyaknya requirement yang ada dan banyaknya requirement yang ada dan kompleksitas interaksinya. kompleksitas interaksinya.
Karenanya pada rekayasa perangkat lunak Karenanya pada rekayasa perangkat lunak istilah “spesifikasi requirement software” istilah “spesifikasi requirement software” mengacu pada pembuatan dokumen baik fisik mengacu pada pembuatan dokumen baik fisik maupun elektronis. maupun elektronis.
Pada sistem yang kompleks, terutama Pada sistem yang kompleks, terutama yang melibatkan banyak kompone non yang melibatkan banyak kompone non software, ada 3 jenis dokumen yang software, ada 3 jenis dokumen yang dibuat yaitu dibuat yaitu definisi sistem, definisi sistem, requirement sistem dan requirement requirement sistem dan requirement perangkat lunak. perangkat lunak.
Pada produk software yang sederhana Pada produk software yang sederhana hanya satu dari 3 jenis dokumen itu yang hanya satu dari 3 jenis dokumen itu yang perlu dibuat. perlu dibuat.
Semua tiga jenis dokumen itu akan Semua tiga jenis dokumen itu akan dijelaskan di sini.dijelaskan di sini.
5.1:5.1:Dokumen Definisi SistemDokumen Definisi Sistem
Dokumen ini menyimpan requirement sebuah Dokumen ini menyimpan requirement sebuah sistem.sistem.
Dokumen ini mendaftar semua requirement Dokumen ini mendaftar semua requirement beserta keterangan latar belakang tujuan beserta keterangan latar belakang tujuan keseluruhan sebuah sistem, lingkungan yang keseluruhan sebuah sistem, lingkungan yang menjadi sasaran dan pernyataan batasan, asumsi menjadi sasaran dan pernyataan batasan, asumsi dan requirement non-fungsional. dan requirement non-fungsional.
Mungkin juga di dalamnya terdapat model Mungkin juga di dalamnya terdapat model konseptual yang didesain untuk memberikan konseptual yang didesain untuk memberikan gambaran tentang konteks sistem, skenario gambaran tentang konteks sistem, skenario pemakaian dan entitas - entitas domain yang pemakaian dan entitas - entitas domain yang penting, termasuk juga data, informasi dan aliran penting, termasuk juga data, informasi dan aliran kerja.kerja.
5.2:5.2:Spesifikasi Requirement Sistem.Spesifikasi Requirement Sistem.
Para pengembang dari sebuah sistem Para pengembang dari sebuah sistem berkomponen software dan non-software yang berkomponen software dan non-software yang cukup banyak, seringkali memisahkan deskripsi cukup banyak, seringkali memisahkan deskripsi dari requirement sistem dari deskripsi dari requirement sistem dari deskripsi requirement software. requirement software.
Dengan cara ini, requirement sistem Dengan cara ini, requirement sistem dispesifikasikan, requirement software didapat dispesifikasikan, requirement software didapat dari requirement sistem dan requirement untuk dari requirement sistem dan requirement untuk komponen sosftware dispesifikasikan .komponen sosftware dispesifikasikan .
Karena merupakan bidang rekayasa sistem, Karena merupakan bidang rekayasa sistem, dokumen jenis ini tidak akan dibahas terperinci di dokumen jenis ini tidak akan dibahas terperinci di sini.sini.
5.3:5.3:Spesifikasi Requirement SoftwareSpesifikasi Requirement Software
Dokumen jenis ini Dokumen jenis ini menjadimenjadi dasar untuk dasar untuk sebuah perjanjian antara pelanggan dan sebuah perjanjian antara pelanggan dan kontraktor atau penyuplai tentang apa kontraktor atau penyuplai tentang apa yang seharusnya dan tidak seharusnya yang seharusnya dan tidak seharusnya dikerjakan oleh produk software. dikerjakan oleh produk software.
Untuk pembaca yang kurang paham hal – Untuk pembaca yang kurang paham hal – hal yang sifanya teknis, dokumen jenis ini hal yang sifanya teknis, dokumen jenis ini juga didampingi oleh dokumen definisi juga didampingi oleh dokumen definisi requirement software. requirement software.
Dokumen ini memungkinkan penilaian Dokumen ini memungkinkan penilaian mendalam tentang requirement sebelum mendalam tentang requirement sebelum desain dimulai sehingga mengurangi desain dimulai sehingga mengurangi keharusan desain ulang. keharusan desain ulang.
Dokumen ini juga memberikan dasar – Dokumen ini juga memberikan dasar – dasar realistis untuk memperkirakan dasar realistis untuk memperkirakan biaya, risiko dan jadwal produksi.biaya, risiko dan jadwal produksi.
Requirements validationRequirements validation
Requirements validationRequirements validation
Kebutuhan dokumen difokuskan pada prosedur Kebutuhan dokumen difokuskan pada prosedur validasi dan verifikasi. validasi dan verifikasi.
Kebutuhan akan validasi untuk meyakinkan Kebutuhan akan validasi untuk meyakinkan bahwa software engineer telah mengerti tentang bahwa software engineer telah mengerti tentang requirement yang diperlukan, dan juga sangat requirement yang diperlukan, dan juga sangat penting untuk membuktikan bahwa requirements penting untuk membuktikan bahwa requirements document dapat disesuaikan dengan kebutuhan document dapat disesuaikan dengan kebutuhan standard suatu perusahaan, dan juga dapat standard suatu perusahaan, dan juga dapat mudah dipahami, konsisten, dan lengkap. mudah dipahami, konsisten, dan lengkap.
6.1:6.1:Requirements ReviewsRequirements Reviews
Arti umum validation adalah memeriksaan (inspection) atau Arti umum validation adalah memeriksaan (inspection) atau review (meninjau) requirements document. review (meninjau) requirements document.
Reviewer bertugas mencari error (look for errors), asumsi Reviewer bertugas mencari error (look for errors), asumsi yang salah (mistaken assumptions), hal-halyang kurang yang salah (mistaken assumptions), hal-halyang kurang jelas (lack of clarity), dan penyimpangan standar (deviation jelas (lack of clarity), dan penyimpangan standar (deviation from standard practice). from standard practice).
Hal ini sangat penting dan munkin membantu memberikan Hal ini sangat penting dan munkin membantu memberikan petunjuk apa yang dicari dalam tabel checklists. petunjuk apa yang dicari dalam tabel checklists.
Review terdapat pada :Review terdapat pada : penyelesaian dari system definition documentpenyelesaian dari system definition document system specification documentsystem specification document software requirements specification documentsoftware requirements specification document baseline specification for a new releasebaseline specification for a new release atau pada langkah lain dalam suatu prosesatau pada langkah lain dalam suatu proses
6.2:6.2:PrototypingPrototyping
Prototyping secara umum berarti untuk Prototyping secara umum berarti untuk melakukan validasi, interpretasi software melakukan validasi, interpretasi software engineer mengenai software engineer mengenai software requirements, sama seperti memperoleh requirements, sama seperti memperoleh requirement baru. requirement baru.
Keuntungan dari prototype adalah akan Keuntungan dari prototype adalah akan memudahkan software engineer memudahkan software engineer menginterpretasikan asumsinya dan juga menginterpretasikan asumsinya dan juga berguna untuk mengetahui kembali jika berguna untuk mengetahui kembali jika terdapat kesalahan. terdapat kesalahan.
6.3:6.3:Model ValidationModel Validation
Merupakan suatu hal yang dibutuhkan untuk Merupakan suatu hal yang dibutuhkan untuk mengesahkan kualitas suatu model yang sedang mengesahkan kualitas suatu model yang sedang dianalisis. dianalisis.
Sebagai contoh, dalam objek model sangat Sebagai contoh, dalam objek model sangat berguna untuk melakukan static anlisis untuk berguna untuk melakukan static anlisis untuk menguji bahwa jalur komunikasi antara objek itu menguji bahwa jalur komunikasi antara objek itu ada, dimana dalam daerah stakeholders, terjadi ada, dimana dalam daerah stakeholders, terjadi pertukaran data. pertukaran data.
Jika formal specification notations digunakan, Jika formal specification notations digunakan, sangat memungkinkan untuk menggunakan sangat memungkinkan untuk menggunakan formal reasoning untuk membuktikan spesifikasi formal reasoning untuk membuktikan spesifikasi properties. properties.
6.4:6.4:Acceptance TestsAcceptance Tests
Property yang diperlukan dari sebuah software requirement Property yang diperlukan dari sebuah software requirement adalah bahwa sangat mungkin untuk mengesahkan produk yang adalah bahwa sangat mungkin untuk mengesahkan produk yang telah selesai dapat memenuhinya. telah selesai dapat memenuhinya.
Requirements yang tidak dapat divalidasi merupakan hanya Requirements yang tidak dapat divalidasi merupakan hanya sebuah ‘keinginan’. sebuah ‘keinginan’.
Sebuah tugas yang penting adalah merencanakan bagaimana Sebuah tugas yang penting adalah merencanakan bagaimana menguji masing-masing requirement. menguji masing-masing requirement.
Dalam berbagai kasus, desain acceptance tests yang Dalam berbagai kasus, desain acceptance tests yang melakukannya. melakukannya.
Mengidentifikasi dan mendesain acceptance tests mungkin sangat Mengidentifikasi dan mendesain acceptance tests mungkin sangat sulit untuk non-functional requirement.sulit untuk non-functional requirement.
Agar bisa divalidasi, pertama harus dianalisis pada poin dimana Agar bisa divalidasi, pertama harus dianalisis pada poin dimana dapat ditunjukkan secara kuantitatif.dapat ditunjukkan secara kuantitatif.
Practical ConsiderationsPractical Considerations
Practical ConsiderationsPractical Considerations
Tidak semua organisasi mempunyai kebiasaan Tidak semua organisasi mempunyai kebiasaan mendokumentasikan dan mengatur requirement. mendokumentasikan dan mengatur requirement.
Bagaimanapun, sebagai perusahaan yang Bagaimanapun, sebagai perusahaan yang berkembang, pelanggan mereka bertumbuh, dan berkembang, pelanggan mereka bertumbuh, dan produk mulai berkembang, mereka menemukan produk mulai berkembang, mereka menemukan bahwa mereka perlu untuk memulihkan bahwa mereka perlu untuk memulihkan keperluan – keperluan yang mendukung fitur keperluan – keperluan yang mendukung fitur produk agar dapat menaksir gangguan dari produk agar dapat menaksir gangguan dari perubahan tujuan. perubahan tujuan.
Oleh sebab itu, requirements documentation dan Oleh sebab itu, requirements documentation dan pengubahan management adalah kunci sukses pengubahan management adalah kunci sukses dari requirements process.dari requirements process.
7.1:7.1:Iterative Nature of Requirements Iterative Nature of Requirements
ProcessProcess
Kebanyakan proyek didesak oleh Kebanyakan proyek didesak oleh lingkungannya, dan banyak perubahan, lingkungannya, dan banyak perubahan, atau revisi, dari software yang ada. atau revisi, dari software yang ada.
Sehingga, selalu tidak bisa dijalankan Sehingga, selalu tidak bisa dijalankan untuk implementasi requirement process untuk implementasi requirement process sebagai sebuah linear, dan penanganan sebagai sebuah linear, dan penanganan lebih pada tim software development. lebih pada tim software development.
Pada beberapa proyek, hal ini bisa saja Pada beberapa proyek, hal ini bisa saja menghasilkan/berdampak dalam menghasilkan/berdampak dalam kebutuhan yang digariskan sebelum kebutuhan yang digariskan sebelum semua propertinya benar-benar dipahami.semua propertinya benar-benar dipahami.
Point yang paling penting dalam mengerti Point yang paling penting dalam mengerti requirement engineering adalah proporsi requirement engineering adalah proporsi yang signifikan dari requirement yang yang signifikan dari requirement yang akan berubah.akan berubah.
Kadang- kadang dikarenakan error pada Kadang- kadang dikarenakan error pada analisa, tapi ini sering akibat perubahan analisa, tapi ini sering akibat perubahan lingkungan yang tak dapat dihindarkan. lingkungan yang tak dapat dihindarkan. Contohnya, operasi pelanggan atau Contohnya, operasi pelanggan atau lingkungan bisnis, atau pasar dimana lingkungan bisnis, atau pasar dimana software harus dijual. software harus dijual.
7.2:7.2: Change management Change management
Change management adalah pusat untuk Change management adalah pusat untuk mengatur requirement. mengatur requirement.
Topik ini menggambarkan peran dari Topik ini menggambarkan peran dari change management, prosedur yang change management, prosedur yang diperlukan, dan analisa yang seharusnya diperlukan, dan analisa yang seharusnya digunakan untuk usulan pengubahan.digunakan untuk usulan pengubahan.
Ini telah memperkuat hubungan Software Ini telah memperkuat hubungan Software Configuration Management Knowledge Configuration Management Knowledge Area.Area.
7.3:7.3: Requirements Attributes Requirements Attributes
Requirement sebaiknya tidak hanya terdiri dari Requirement sebaiknya tidak hanya terdiri dari perincian dari apa yang dibutuhkan, tapi juga dari perincian dari apa yang dibutuhkan, tapi juga dari informasi tambahan yang mana membantu informasi tambahan yang mana membantu mengatur dan menafsirkan requirement tersebut. mengatur dan menafsirkan requirement tersebut.
Mungkin juga memasukkan informasi tambahan Mungkin juga memasukkan informasi tambahan seperti kesimpulan dari masing- masing seperti kesimpulan dari masing- masing requirement, sumber daya dari masing- masing requirement, sumber daya dari masing- masing requirement, dan perubahan sejarah. requirement, dan perubahan sejarah.
Requirement attribute yang paling penting adalah Requirement attribute yang paling penting adalah sebuah pengenal yang mana memperbolehkan sebuah pengenal yang mana memperbolehkan requirement tersebut unik dan jelas.requirement tersebut unik dan jelas.
7.4:7.4:Requirements TracingRequirements Tracing
Requirements Tracing diperhatikan dengan Requirements Tracing diperhatikan dengan pemulihan sumber daya requirement dan pemulihan sumber daya requirement dan memprediksikan efek dari requirement. memprediksikan efek dari requirement.
Tracing adalah pokok untuk melakukan analisa Tracing adalah pokok untuk melakukan analisa ketika requirement berubah. ketika requirement berubah.
Sebuah requirement sebaiknya dapat di- trace ke Sebuah requirement sebaiknya dapat di- trace ke belakang. Contoh, dari software requirement belakang. Contoh, dari software requirement kembali ke system requirement.kembali ke system requirement.
Sebaliknya, requirement sebaiknya dapat Sebaliknya, requirement sebaiknya dapat di- trace ke depan. Contoh, dari system di- trace ke depan. Contoh, dari system requirement ke software requirement requirement ke software requirement yang telah diuraikan, dan ke kode modul yang telah diuraikan, dan ke kode modul yang mengimplementasikannya.yang mengimplementasikannya.
Requirement Tracing untuk proyek yang Requirement Tracing untuk proyek yang khusus akan membentuk DAG ( Directed khusus akan membentuk DAG ( Directed Acyclic Graph) yang kompleks dari Acyclic Graph) yang kompleks dari requirement.requirement.
7.5:7.5:Measuring RequirementMeasuring Requirement
Sebagai sebuah bentuk yang praktis, biasanya digunakan Sebagai sebuah bentuk yang praktis, biasanya digunakan untuk mempunyai beberapa konsep ‘volume’ requirement untuk mempunyai beberapa konsep ‘volume’ requirement untuk produk software. untuk produk software.
Jumlah ini digunakan dalam mengevaluasi ukuran pada Jumlah ini digunakan dalam mengevaluasi ukuran pada perubahan dalam requirement, dalam estimasi harga perubahan dalam requirement, dalam estimasi harga development atau tugas maintenance, atau development atau tugas maintenance, atau menyerderhanakan penggunaan sebagai denominator pada menyerderhanakan penggunaan sebagai denominator pada pengukur lain. pengukur lain.
FSM ( Functional Size Measurement ) adalah sebuah teknik FSM ( Functional Size Measurement ) adalah sebuah teknik untuk mengevaluasi ukuran badan dari fungsi requirement. untuk mengevaluasi ukuran badan dari fungsi requirement. IEEE Std 14143.1 mendefinisikan konsep dari FSM. IEEE Std 14143.1 mendefinisikan konsep dari FSM.
Informasi tambahan ukuran dan standard akan ditemukan Informasi tambahan ukuran dan standard akan ditemukan di Software Engineering Process Knowledge Area.di Software Engineering Process Knowledge Area.
Top Related