Requirements Engineering

Dalam Engineering (rekayasa), Requirement adalah kebutuhan fisik dan fungsional tunggal mendokumentasikan bahwa produk atau jasa tertentu harus atau melakukan. Hal ini paling sering digunakan dalam arti formal di sistem rekayasa , rekayasa perangkat lunak , atau rekayasa perusahaan . Ini adalah pernyataan yang mengidentifikasi atribut yang diperlukan, kemampuan, karakteristik, atau kualitas suatu sistem untuk itu untuk memiliki nilai dan utilitas untuk pengguna.

Dalam pendekatan rekayasa klasik, set persyaratan yang digunakan sebagai masukan ke dalam tahap desain pengembangan produk.Persyaratan juga menjadi masukan penting dalam proses verifikasi, karena tes harus menelusuri kembali dengan persyaratan tertentu. Persyaratan menunjukkan apa elemen dan fungsi yang diperlukan untuk proyek tertentu. Hal ini tercermin dalam model air terjun dari perangkat lunak siklus hidup. Namun, ketika metode iteratif dari pengembangan perangkat lunak atau metode tangkas yang digunakan, persyaratan sistem yang secara bertahap dikembangkan secara paralel dengan desain dan implementasi.

Persyaratan teknik adalah serangkaian kegiatan yang mengarah pada derivasi dari sistem atau persyaratan perangkat lunak. Persyaratan rekayasa mungkin melibatkan studi kelayakan , atau fase analisis konseptual dari proyek dan elisitasi persyaratan (pengumpulan, pemahaman, meninjau, dan mengartikulasikan kebutuhan stakeholder ) dan analisis kebutuhan , analisis (memeriksa konsistensi dan kelengkapan), Spesifikasi (mendokumentasikan persyaratan) dan validasi (memastikan persyaratan yang ditentukan adalah benar).

Dalam system engineering (rekayasa), requirement  bisa menjadi gambaran apa yang sistem harus lakukan, disebut sebagai requirement Fungsional (Kebutuhan Fungsional) . Ini jenis kebutuhan menentukan sesuatu bahwa sistem disampaikan harus mampu melakukan. Tipe lain dari persyaratan menentukan sesuatu tentang sistem itu sendiri, dan seberapa baik melakukan fungsinya. Persyaratan seperti ini sering disebut non-fungsional persyaratan , atau 'persyaratan kinerja' atau 'kualitas persyaratan layanan. " Contoh persyaratan tersebut meliputi kegunaan, ketersediaan, keandalan, dukungnya, testability dan rawatan.

Sebuah koleksi persyaratan mendefinisikan karakteristik atau fitur dari sistem yang diinginkan. A 'baik' daftar persyaratan sejauh mungkin menghindari mengatakan bagaimana sistem harus menerapkan persyaratan, meninggalkan keputusan tersebut kepada perancang sistem. Menentukan bagaimana sistem harus dilaksanakan disebut "implementasi bias" atau "rekayasa solusi". Namun, penerapan kendala pada solusi sah dapat dinyatakan oleh pemilik masa depan, misalnya untuk antarmuka yang diperlukan untuk sistem eksternal, untuk interoperabilitas dengan sistem lain, dan untuk kesamaan (misalnya user interface) dengan produk yang dimiliki lainnya. Dalam rekayasa perangkat lunak, makna yang sama persyaratan berlaku, kecuali bahwa fokus perhatian adalah perangkat lunak itu sendiri.

Jenis-jenis produk  Requirement :

• Arsitektur Requirement : menjelaskan apa yang harus dilakukan dengan mengidentifikasi arsitektur sistem yang diperlukan dari suatu sistem ,
• fungsional Requirement : menjelaskan fungsi bahwa sistem ini adalah untuk mengeksekusi, misalnya, memformat beberapa teks atau modulasi sinyal. Mereka kadang-kadang dikenal sebagai kemampuan.
• Non-fungsional Requirement : menggambarkan karakteristik dari sistem bahwa pengguna tidak dapat mempengaruhi atau (langsung) melihat. Persyaratan nonfunctional kadang-kadang dikenal sebagai persyaratan kualitas atau lities .
• Constraint Requirement : memberi batasan pada alternatif desain atau proyek / proses operasi. Tidak peduli bagaimana masalah diselesaikan persyaratan kendala harus ditaati.

Non-fungsional persyaratan dapat lebih diklasifikasikan menurut apakah mereka persyaratan kegunaan, tampilan dan nuansa persyaratan, persyaratan kemanusiaan, persyaratan kinerja, persyaratan rawatan, persyaratan operasional, persyaratan keselamatan, persyaratan keandalan, atau salah satu dari banyak jenis persyaratan.

Dalam rekayasa perangkat lunak kategorisasi ini berguna karena hanya persyaratan fungsional dapat langsung diimplementasikan dalam perangkat lunak. Non-fungsional persyaratan dikendalikan oleh aspek-aspek lain dari sistem. Misalnya, dalam kehandalan sistem komputer berhubungan dengan tingkat kegagalan hardware, dan kinerja dikendalikan oleh CPU dan memori. Non-fungsional persyaratan dapat dalam beberapa kasus didekomposisi menjadi persyaratan fungsional untuk perangkat lunak. Sebagai contoh, tingkat sistem non-fungsional persyaratan keselamatan dapat didekomposisi menjadi satu atau lebih persyaratan fungsional. Lihat FURPS . Selain itu, persyaratan non-fungsional dapat diubah menjadi persyaratan proses ketika kebutuhannya adalah tidak mudah diukur. Sebagai contoh, tingkat sistem persyaratan rawatan dapat didekomposisi menjadi pembatasan konstruksi perangkat lunak atau batasan pada baris atau kode.

Fase Requirement

Dari seluruh fase yang ada di project, fase Requirement Development adalah yang paling penting. Bila kita melakukan kegiatan requirement dengan asal-asalan, akibatnya antara lain:

·    1. aplikasi sudah selesai dibuat, tapi tidak sesuai dengan keinginan user

·    2. pada fase coding, banyak terjadi delay karena ternyata ada requirement yang belum jelas

·    3. pada fase coding, banyak pekerjaan harus diulang karena salah memahami requirement.

Kenapa saya sebut dengan istilah Requirement Development, bukan Requirement Gathering seperti yang umum dipakai orang? Sebabnya adalah karena requirement yang baik itu tidak didapat dengan mudah. Tidak seperti memungut barang di jalanan (gathering), melainkan harus melalui proses yang iteratif (development). Kita tidak bisa mendapatkan requirement yang baik sekali jalan. Kita harus terus menerus melakukan investigasi, klarifikasi, verifikasi, agar requirement yang didapat benar-benar bagus kualitasnya.

Tujuan Requirement

Kita melakukan requirement development karena kita ingin tahu apa yang ingin dibuat. Setelah mengetahui apa yang ingin dibuat, barulah kita bisa: 

- memilih anggota tim yang tepat 

- memperkirakan biaya dan waktu yang dibutuhkan untuk membuatnya

- memilih arsitektur dan teknologi yang sesuai