REQUIREMENT ENGINEERING
Febryci Legirian 1211044Bangkit Kristianus P. 1211048Gerry Martinus 1211010
M. Fadhil Fadlan 1211054
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)"
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).
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).
Requirement Engineering dalam V model
Requirement Engineering
Tiga Dimensi Requirements Engineering
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.
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.
Gambar Contoh Form Requirement Catalogue Std. IEEE
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.
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
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.
Requirements Slicitation and Prioritization
O Kebutuhan harus dikumpulkan dari sumber yang
dapat berkontribusi.
O Kontribusi terutama dari calon pelanggan dan
pengguna.
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.
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.
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.
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.
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.
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.
Top Related