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.