Requirement Engineering
Download as PPTX, PDF•3 likes•9,336 views
Ringkasan dokumen tersebut adalah: 1. Requirements engineering merupakan fase awal dalam proses pengembangan perangkat lunak dimana kebutuhan pengguna dikumpulkan dan ditetapkan. 2. Terdapat beberapa tahapan dalam requirements engineering seperti elicitation, specification, validation, dan pelacakan perubahan kebutuhan. 3. Kebutuhan tersebut kemudian didokumentasikan untuk memastikan konsistensi dan kelengkapan spesifikasi kebutuhan.
![Requirement Specification
O Requirements Specification adalah sebuah tahap
pendokumentasian requieremnt elicitation.
O Dokumen ini berisi tentang fitur dan fungsi yang
diinginkan oleh customer.
O IEEE mengeluarkan standard untuk dokumen spesifikasi
requirements yang terkenal dengan nama IEEE
Recommended Practice for Software Requirements
Specifications [IEEE-830].
O Dokumen spesifikasi requirements bisa berisi functional
requirements, performance requirements, external
interface requirements, design constraints, maupun
quality requirements.](https://image.slidesharecdn.com/tugas1ppt-130912092304-phpapp01/85/Requirement-Engineering-8-320.jpg)
Requirement Engineering
- 1. REQUIREMENT ENGINEERING Febryci Legirian 1211044 Bangkit Kristianus P. 1211048 Gerry Martinus 1211010 M. Fadhil Fadlan 1211054
- 2. Requirements Engineering Berdasarkan standart IEEE 1220-1998 yang merupakan standart aplikasi dan manajemen dari proses engineering sistem adalah: ”Statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, teastable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines)” "Pernyataan yang mengidentifikasi produk atau proses operasional, fungsional, atau karakteristik desain atau kendala untuk memperjelas dan memperkirakan apa saja yang diperlukan untuk sebuah produk atau proses penerimaan (oleh konsumen atau pedoman penjaminan mutu internal)"
- 3. Requirements Engineering menurut Pamela Zave dalam bukunya yang berjudul Classification of Research Efforts in Requirements Engineering, definisi Requiement Engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain (dalam satu keluarga).
- 4. Requirements Engineering O Requirements engineering merupakan fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Fase ini sangat penting, sebagaimana disepakati oleh para pakar software engineering karena Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan).
- 5. Requirement Engineering dalam V model Requirement Engineering
- 6. Tiga Dimensi Requirements Engineering
- 7. Requirement Elicitation O Requirement Elicitation adalah proses mengumpulkan dan memahami requirements dari user. O Permasalahan yang muncul adalah perbedaan disiplin ilmu yang dimiliki oleh pengembang software dengan pihak customer. O Customer biasanya lebih tahu tentang proses bisnis atau domein dari software yang ingin dikembangkan. O Sedangkan pengembang yang mempunyai tugas salah satunya adalah requirement analyst terkadang buta sama sekali terhadap domain atau proses bisnis tersebut.
- 8. Requirement Specification O Requirements Specification adalah sebuah tahap pendokumentasian requieremnt elicitation. O Dokumen ini berisi tentang fitur dan fungsi yang diinginkan oleh customer. O IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. O Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.
- 9. Gambar Contoh Form Requirement Catalogue Std. IEEE
- 10. Requirement Validation and Verifications O Requirement Validation adalah proses untuk memastikan bahwa requirements yang benar sudah ditulis. O Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. O Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.
- 11. Kegiatan Tahapan Requirement Engineering 1. Vision Statement 2. Requirements Slicitation and Prioritization 3. Pengetahuan Akuisisi dan Pengelolaan 4. Studi Kelayakan atau Analisis Risiko 5. Kebutuhan fungsional dan non-fungsional 6. Keselamatan dan Kebutuhan keamanan 7. Dokumentasi Kebutuhan 8. Penerimaan, Validasi dan Persetujuan Kebutuhan 9. Pelacakan Kebutuhan dan Perubahan kendali
- 12. Vision Statement O Visi dari sistem yang akan dibangun merupakan hal baik untuk memulai proses kebutuhan. O Visi dituangkan dalam bentuk dokumen yang menguraikan keseluruhan tujuan yang harus dicapai dan disetujui oleh stakeholders, terutama di tingkat manajemen. O Jika dalam proses ternyata visi tidak dapat dicapai, pernyataan visi harus direvisi dan dibahas kembali.
- 13. Requirements Slicitation and Prioritization O Kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi. O Kontribusi terutama dari calon pelanggan dan pengguna.
- 14. Pengetahuan Akuisisi dan Pengelolaan O Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. O biasa dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb. Studi Kelayakan atau Analisis Risiko O Untuk sistem yang lebih besar, studi kelayakan perlu dilakukan sebelum kebutuhan secara resmi diterima.
- 15. Kebutuhan fungsional dan non-fungsional O Kebutuhan fungsional • Adalah suatu kebutuhan yang menyatakan prilaku yang harus ada pada sistem. Sebagai contoh jika seorang pengusaha membeli mobil untuk membawa barang dari gudang ke toko, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang dari gudang ke toko. O Kebutuhan non fungsional • Sederhananya adalah batasan yang harus ada pada sistem dan bagaimana dalam membentuk sistem tersebut.
- 16. Keselamatan dan Kebutuhan keamanan O Bentuk kebutuhan non-fungsional menyangkut keselamatan dan keamanan sistem. O Resiko keselamatan dapat menimbulkan bahaya untuk pengguna individu, kelompok, atau masyarakat luas. O Keselamatan adalah penting, terutama jika komputer mengendalikan peralatan fisik atau pabrik, seperti rem mobil, pesawat, atau stasiun tenaga nuklir. O Keamanan menjadi isu penting jika data yang disimpan, data harus dilindungi terhadap penyalahgunaan, serta terhadap serangan berbahaya oleh pesaing.
- 17. Dokumentasi Kebutuhan O Setelah kebutuhan terkumpul dan dianalisa, selanjutnya didokumentasikan dengan jelas dan baik dan tidak ambigu. O Penulisan dokumentasi kebutuhan merupakan aspek yang “critical” sehingga memungkinkan suatu iterasi yang melibatkan seluruh „stakesholders‟ sangatlah mungkin terjadi.
- 18. Penerimaan, Validasi dan Persetujuan Kebutuhan O Keberhasilan setiap proyek pembangunan terutama tergantung pada penerimaan dari produk akhir yang diinginkan oleh pengguna. User harus menerima kebutuhan, yakni mempertimbangkan kebutuhan sebagai milik mereka. O Setelah didapat suatu kebutuhan yang teranalisa maka team rekayasa kebutuhan dan para stakeholdes memvalidasi kembali dan meperbaiki apa yang menjadi kekurangan. O Meliputi proses identifikasi, menyakinkan kembali, menanggapi dan memperbaiki masalah dari requirements, dan menyatakan bahwa requirement telah dapat diterima.
- 19. Pelacakan Kebutuhan dan Perubahan kendali O Untuk sistem yang besar, perlu dipastikan bahwa tidak ada kebutuhan dokumentasi yang terlupakan. O Kebutuhan dapat berubah, selama kehidupan sebuah proyek, baik sebelum atau setelah pengiriman. O Oleh karena itu, diperlukan untuk membuat perubahan kendali prosedur guna kebutuhan.