SOFTWARE SOFTWARE REQUIREMENTSREQUIREMENTS

MUHAMMAD YUSUFMUHAMMAD YUSUFTeknik Informatika – Universitas TrunojoyoTeknik Informatika – Universitas Trunojoyo

Email : Email : yusufxyz@gmail.com

Http://yusufxyz.wordpress.comHttp://yusufxyz.wordpress.com

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, kuantitatif.beberapa bagiannya yang sesuai, 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 mengoperasikan kelompok yang kelak akan mengoperasikan

software.software. Pelanggan : Kelompok inilah yang akan memberlakukan Pelanggan : Kelompok inilah yang akan memberlakukan

suatu software ke dalam suatu organisasi.suatu software ke dalam suatu organisasi. Analis Pasar : Analis pasar diperlukan untuk mengetahui Analis Pasar : Analis pasar diperlukan untuk mengetahui

kebutuhan pasar.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 dari bidang semacam ini harus sesuai dengan ketentuan dari badan regulator yang berwenang.badan regulator yang berwenang.

Perekayasa software : Kelompok ini memiliki hak yang Perekayasa software : Kelompok ini memiliki hak yang sah untuk mengambil keuntungan dari pengembangan sah untuk mengambil keuntungan dari pengembangan suatu software, termasuk menggunakan ulang beberapa suatu software, termasuk menggunakan ulang beberapa komponennya untuk produk lain.komponennya untuk 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.