Requerment Engineering

Requerment Software Engineering

Definisi
Requirement menurut IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) dapat diartikan sebagai berikut.

• Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai tujuan
• Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen formal lain
• Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada kondisi 1 dan 2 diatas

Menurut Sommerville requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya berkerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem.

Ada beberapa macam requirement menurut Sommerville yaitu:
a. User Requirement (kebutuhan pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan perasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

b. System requirement (kebutuhan system)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

c. Software design specification ( spesifikasi rancangan perangkat lunak)
Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

Secara umum, requirement dibagi menjadi 2 yaitu
Functional requirement : menjelaskan tentang fungsional dari sistem
Non-Functional requirement : yang berperan untuk member batasan pada solusi atau biasa disebut quality requirement.

Requirement yang baik mempunyai karakteristik untuk tetap konsisten, dibutuhkan, tidak ambigu, dan bisa diverifikasi. Selain itu requirement juga harus lengkap, kenapa?

• Kesesuaian dengan keinginan pelanggan.
• Mengestimasi serta menjaga jadwal dan biaya pengembangan
• Menjaga arsitektur, desain, implementasi, dan tes dari pengembangan agar terhindar dari ketidak lengkapan dan kesalahan karena asusmsi yang salah.
• Menghindari ambigu
• Keamanan, telah terbukti banyak kegagalan terjadi karena tidak lengkapnya requirement.

Donald Firesmith merekomendasikan menggunakan multi requirement model sehingga sudut pandang bisa lebih luas dan detil, model tersebut harus di identifikasi, analisis, dan didokumentasikan. Gunakan checklist untuk memeriksa apakah model telah terimplementasi dalam requirement. Buatlah model sesuai dengan kebutuhan proyek secara spesifik. Serta memastikan pengalaman dan keragaman anggota team untuk menyesuaikan dengan kekomplekan sistem yang sedang dibangun. Selain itu gunakan repository untuk menyimpan metadata requirement untuk mendapatkan requirement sesuai dengan kebutuhan proyek, dan gunakan alat yang mampu mengidentifikasikan metadata dan report yang kurang. Dengan metode requirement iterative dan incremental, secara berkelanjutan kebutuhan pelanggan dan pengguna akan selalu berkembang sehingga requirement juga akan ikut berkembang, hal ini berarti requirement yang lengkap menjadi state yang relative.

Kelengkapan requirement harus tetap dijaga karena banyak requirement engineering yang tidak tahu bahwa sebenarnya requirement mereka kurang lengkap sehingga bisa menimbulkan “bencana” dalam pengembangan sistem, untuk itu perlu dibuat beberapa model requirement agar sudut pandang terhadap setiap detil bisa dipantau, den mengunakan repository untuk memudahkan dokumentasi dan verifikasi kepada stakeholder, selain itu memungkinkan juga melakukan check kelengkapan requirement berdasarkan template model proyek yang telah dispesifikasikan sesuai dengan kompleksitasnya.
Banyak orang sering salah dalam mendefinisikan requirement untuk sistem yang mereka bangun, kerena mereka kurang mendapat pelatihan dan pengalaman dalam membuat requirement. Bahkan di bangku kuliah yang mengajarkan mata kuliah system engineering hanya mengajarkan pengenalan untuk materi menulis requirement.

Aspek yang penting dari sistem engineering adalah merubah kebutuhan user menjadi jelas, ringkas, dan dapat diverifikasi. Requirement yang baik menyatakan sesuatu yang dibutuhkan, dapat diverifikasi, memungkinkan, dan Jelas.

Terdapat beberapa masalah yang sering ditemui dalam membuat requirement, diantaranya adalah : membuat asumsi yang buruk, menulis implementasi (HOW) daripada requirement (WHAT), menjelaskan operasional daripada kebutuhan, mengunakan istilah yang salah, mengunakan bahasa yang kurang tepat, requirement tidak lengkap, dan menspesifikasikan requirement secara berlebihan.

Asusmsi yang buruk terjadi karena pembuat requirement tidak mempunyai akses yang cukup terhadap informasi yang dibutuhkan. Hal ini bisa dikurangi dengan cara mendokumentasikan informasi yang kritis seperti kebutuhan, tujuan, batasan, misi dan lain-lain. Selain itu semua asumsi juga harus didokumentasikan sehingga ketika direview asumsi bisa diperbaiki jika tidak sesuai.

Spesifikasi requirement harus menyatakan Apa yang dibutuhkan (WHAT), bukan bagaimana hal tersebut di sediakan (WHY). Caranya dengan mentanyakan mengapa (WHY) anda membutuhkan requirement tersebut.

Istilah juga penting untuk diperhatikan, penulis requirement harus bisa membedakan istilah shall (bisa), will (akan) ,dan should (harus). Requirement mengunakan Shall (bisa), pernyataan fakta mengunakan will (akan), dan Tujuan mengunakan Should (harus).

Saat ini Requirement Spesification telah berpindah dari yang berkarateristik waterfall menjadi iterative, incremental, parallel, dan timebox.
Iterative Requirement Engineering : cocok digunakan untuk proses pengembangan yang terdapat fase penting yang belum pasti, misalnya pada software yang dibuat untuk ditawarkan kepada pelanggan, requirement pada software ini bisa berubah 180 deraajat karena pelanggan bisa membutuhkan sesuatu yang belum dipikirkan oleh pengembang, oleh sebab itu model iterative requirement engineering cocok untuk pengembangan software diatas, untuk memperbaiki dan meningkatkan kualitas software perlu melakukan iterasi yang berulang-ulang.

Incremental Requirement Engineering : Jika software yang akan dibuat terlalu besar dan komplek sehingga tidak bisa dibuat semua sekaligus, maka incremental requirement engineering sesuai untuk pengembangan software tersebut. Hal ini dikarenakan requirement elicitation, analysis,dan specification biasanya dilakukan secara incremental, dengan penambahan requirement dilakukan harian atau mingguan setelah perubahan signifikan dilakukan. Contoh yang paling mudah ditemukan adalah software seperti **legal copy** of microsoft word atau **legal copy** of corel draw yang mempunyai banyak versi seiring dengan perubahan tahun.

Parallel Requirement Engineering : dilaksanakan jika pengembangannya memiliki banyak aktifitas dan harus atau bisa dilakukan secara bersamaan, biasanya dalam proyek tersebut memiliki banyak sumber daya manusia dan hanya memiliki tenggat waktu yang rasional.

Timebox Requirement Engineering : jika proyek diselesaikan dalam waktu tertentu (deadline), maka harus dilakukan dengan memberikan batasan waktu (timebox) terhadap fase.
Yang perlu diperhatikan adalah keempat karateristik tersebut tidak harus dipilih salah satu dalam pengembangan requirement, namun sebaiknya digunakan semuanya, karena sejatinya keempat karakteristik tersebut tidak bersebrangan dan bisa mendukung satu sama lain untuk kelangsungan suatu proyek.

Modern Requirement
Yang menjadi tulang punggung dari modern requirement adalah repository. Dengan adanya repository memungkinkan untuk mengkontrol requirement dengan lebih fleksibel. Siapa yang menulis requirement, siapa yang mensetujui dapat mudah diketahui, perubahan dan history perubahan requirementpun bisa dilakukan, status pengerjaan requirement pun bisa diset dan dilihat ketika tahap pengembangan.
Selain itu dokumen requirement bisa dengan mudah digenerate dari repository dengan banyak versi untuk stakeholder yang berbeda-beda. Selain itu modern requirement juga terintegrasi dengan aktifitas dari stakeholder (misal IDE untuk menganalisa dan mendesign perangkat lunak) sehingga memudahkan dalam kerja sama tim pengembang perangkat lunak.

Pada akhirnya modern requirement mampu menghilangkan permasalah yang muncul di traditional requirement. Pembuatan requirement saat ini lebih cepat, lebih murah, dan mudah dikelola, selain itu requirement yang kurang lengkap dan tidak konsisten, ambigu, susah dimengerti lebih mudah diketahui dan diperbaiki karena fasilitas evaluasi modern requirement yang bisa melakukan review dan perubahan requirement di repository dengan mudah dan cepat.

Modern Requirement tool
Terdapat beberapa tool yang medukung modern requirement diantaranya adalah iRise Application Simulator. Tujuan dari iRise adalah memungkinkan bisnis analis / requirement engineering untuk mengembangkan requirement sekaligus dengan membuat simulasi aplikasi sehingga ketidaksamaan persepsi requirement dapat dihindari antar stakeholder. Selain itu terdapat JIRA , yang merupakan bug, issue tracking, dan project manajement system. JIRA didesain dengan focus penyelesaian tugas dengan mudah dan fleksibel. Selain itu memungkinkan untuk menuliskan fungsional baru sehingga JIRA bisa dipergunakan sebagai requirement repository.

Kesimpulan
Requirement adalah pernyataan yang mengidentifikasikan kebutuhan yang penting dalam sistem dan didalamnya mencakup aspek kebenaran, realistis, dibutuhkan, tidak ambigu, dan terukur. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara user yang memerlukan sistem dengan pembuat sistem.

Mempunyai Requerment Engineering yang bagus adalah penting karena dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar bagus. Untuk mendapatkan requirement yang bagus, ada banyak pekerjaan/tasks harus dilakukan, untuk itu tim Requerment Engineering tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai.

Referensi

1. IEEE Standard Glossary of Software Engineering Technology, IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers, New York, 1990
2. Sommerville, Ian. (2001), “Software Engineering” 6th. Addison Wesley.
3. [WIKI] “requirements”, http://en.wikipedia.org/wiki/Requirement
4. iRise “iRise – Product Overview “ ,http://www.irise.com/products/
5. jira “Atlassian – Beyond JIRA: Go beyond”,http://www.atlassian.com/beyond/go_beyond.jsp