Rekayasa Kebutuhan

Pembahasan rekayasa kebutuhan diadaptasi dari : Pressman, Roger S . Software Engineering: A Practitioner's Approach. 6th Edition. McGraw-Hill. 2005.

What is it ?
Requirement engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software
Why is it important ?
Designing and building an elegant computer program that solves the wrong problem serves no one's needs. That's why it is important to understand what the customer wants before you begin to design and build a computer-based system.
What is the work product ?
The intent of the requirements engineering process is to provide all parties with a written understanding of the problem. This can be achieved though a number of work products: user scenario's, functions, and features lists, analysis models, or a specification.

Latar belakang mengapa perlu adanya rekayasa kebutuhan adalah kenyataan bahwa menemukan kebutuhan klien secara lengkap adalah tidak mudah dan mahal. Tidak mudah karena :
1. klien tidak selalu mengetahui dengan pasti dan jelas apa yang diperlukan
2. kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud
3. kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak
Hal-hal di atas menyebabkan biaya pembangunan perangkat lunak menjadi mahal karena ada tambahan biaya lagi untuk perubahan yang dilakukan dan waktu yang dibutuhkan lebih dari seharusnya.

Rekayasa kebutuhan membangun jembatan menuju desain dan pembangunan perangkat lunak dengan menyediakan mekanisme yang tepat untuk memahami apa yang diinginkan klien, menganalisis kebutuha, menguji kelayakan, bernegosiasi untuk solusi yang masuk akal, menetapkan solusi yang dapat dipahami dua belah pihak, uji spesifikasi dan mengelola kebutuhan yang akan diwujudkan ke sistem operasional. Rekayasa kebutuh terdiri dari 7 fungsi:
1. inception [permulaan]
Inception atau permulaan, merupakan awal dari terjadinya pembicaraan tentang kebutuhan akan software. Permulaan ini dapat terjadi karena dari pembicaraan biasa,kebutuhan bisnis yang dirasakan, adanya pasar potensial, atau munculnya layanan potensial yang dapat dilakukan oleh software.
Aktifitas diawali dengan penetapan siapa stakeholder/pihak-pihak terkait dengan perangkat lunak yang akan dibangun. Misal :
- business operation manager
- product managers
- marketing people
- internal + external customer
- end-users
- consultants
- product engineers
- software engineers
- support and maintenance engineers
- others.
Kebutuhan dieksplorasi dari berbagai pandangan dari masing-masing stakeholders. Kebutuhan yang sama dan berbeda dari masing-masing dicatat, perbedaan persepsi diluruskan. Pertanyaan-pertanyaan awal/dasar dilontarkan kepada setiap stakeholder.

2. elicitation [Pengungkapan]
Klien mengungkapkan kebutuhan. Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.
Aktifitas dilakukan dalam bentuk pertemuan, dimana setiap stakeholder yang diundang diminta untuk membuat daftar kebutuhan software yang disertai penjelasan tentang karakteristik atau detil dari kemampuan tersebut.

3. elaboration [Penjelasan]
Apa yang diungkapkan pada proses permulaan dan pengungkapan kebutuhan, dijelaskan panjang lebar. Fokus pada pemodelan fungsi, fitur dan batasan dari perangkat lunak. Dalam kasus OOP, maka class, atribute dan hubungan antar class diidentifikasi pada aktifitas ini.

4. negotiation [Konflik Resolusi]
Jika terjadi konflik kepentingan karena perbedaan kebutuhan antara bagian pada klien, atau antar end-user, maka aktifitas negosiasi diperlukan untuk membuat prioritas kebutuhan, mengevaluasi tiap kebutuhan untuk mengurangi atau mengubah sesuai dengan yang dimaksud pihak-pihak yang berkonflik.
5. specification
Spesifikasi dapat berubap dokumen, model grafik, model matematika, skenario atau prototype yang merupakan produk akhir dari rekayasa kebutuhan. Apa yang disajikan sebagai spesifikasi merupakan hasil identifikasi kebutuhan melalui aktifitas-aktifitas sebelumnya.Spesifikasi menggambarkan fungsi dan keinerja dari perangkat lunak dan batasan-batasan yang ditentukan.
6. validation
Menguji kualitas dari spesifikasi untuk memastikan kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap dan bebas kesalahan. Mekanisme yang dapat dilakukan adalah formal technical review atau pertemuan evaluasi teknis.
7. management
mengelola kebutuhan dengan identifikasi, kontrol dan mengikuti perkembangan kebutuhan software yang dikerjakan selama proyek dan perubahan-perubahan yang terjadi.


13 Sep, 2008 | othie
« Prev item - Next Item »
---------------------------------------------

Comments


No comments yet. You can be the first!


Leave comment

This item is closed, it's not possible to add new comments to it or to vote on it

© 2007 yoursite.com | Designed by DesignsByDarren
Ported to Nucleus CMS: Suvoroff