Functional and NonFunctional Requirement engineering merupakan salah satu tahap yang paling penting dalam kegiatan proyek perangkat lunak. SR dibuat oleh klien yang memesan software. Secara umum prosesnya adalah diawali dengan client menuliskan requirement sesuai kebutuhannya, lalu tim pengembang menganalisa requirement tersebut, Kemudian setelah ada persetujuan kedua pihak, pembangunan RPL pun dapat dimulai.Dengan kata lain : Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering. Hasil dari requirement engineering digunakan untuk : • Dasar penawaran suatu kontrak. Dalam hal ini item-item yang disajikan harus terbuka untuk masukan dalam pembangunan PL nya nanti • Dasar kontrak.disini item yang disajikan harus didefinisikan secara detil, sehingga apa yang akan dilakukan oleh pengembang menjadi jelas. Requirement engineering ini suatu tahap yang sangat penting, dimana di tahap inilah informasi-informasi serta batasan-batasan perangkat lunak yang akan dibangun di gali. Sehingga ini akan menjadi dasar tim pengembang untuk membuat perangkat lunak sesuai dengan data-data hasil requirement ini yang dituangkan dalam bentuk kontrak. Jadi pembangunan perangkat lunak tidak akan menyimpang dari requirement dan kontrak yang telah disetujui bersama dengan client. Dalam pengumpulan requirement, dapat dilakukan beberapa metode, diantaranya adalah : • Interviews • Questionnaires • Observation • Searching Macam-macam requirement : • User requirement. Berisi tentang layanan yang disediakan sistem serta batasan-batasannya, dan diupayakan disajikan secara jelas agar mudah difahami. • System requirement. Kumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil, sering disebut juga spesifikasi fungsional • A software design specification. Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga requirement ini sangat penting dalam pembangunan PL, dan penggunaan hasil requirement ini dapat dilihat pada gambar berikut : Dalam pelaksanaanya, terdapat masalah-masalah yang mungkin terjadi dalam requirement, yaitu : • Efek dari sistem baru terhadap organisasi sulit diantisipasi • Adanya perbedaan user, menyebabkan beda pula requirement dan prioritasnya • Adanya perbedaan requirement antara end-user sistem, dan organisasi yang membiayai sistem • Untuk menjelaskan requirement dibutuhkan prototype • Adanya perbedaan bahasa alami Kategori Software system requirement : 1. Functional Requirement : Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem. Functional requirement menggambarkan system requirement secara detil seperti input, output dan pengecualian yang berlaku. Masalah yang mungkin terjadi dalam menyusun functional requirement adalah: • Diintepretasikan/diartikan berbeda oleh user atau developer • Hasil intepretasi sering tidak menjawab kebutuhan klien • Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan system • Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan 2. Non-functional Requirement: Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar-standar tertentu. Karena berkaitan dengan kebutuhan sistem secara keseluruhan, maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil/account, bahasa pemrograman yang digunakan, system operasi yang digunakan. Sesuai dengan gambar 2 di atas, non functional requirement dibagi menjadi 3 tipe yaitu: Product req. berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi system Organisational req. berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan. External req. berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi. 3. Domain requirement. Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang tidak berhak. 4. User Requirement Menggambarkan functional dan non-functional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana. 5. System Requirement. Merupakan deskripsi sistem yang lebih detil dari user requirement (jadi masih berisi functional dan non functional req). Req ini bisa berlaku sebagai kontrak pembangunan sistem dan bisa terdiri dari macam model system seperti model object atau model data-flow. System req. menyatakan apa yang harus dikerjakan sistem, dan bukan bagaimana sistem diimplementasikan. Untuk itu bahasa yang lebih spesifik dan bersifat teknis dapat digunakan, seperti misalnya PDL (Program Description Language) seperti contoh pada gambar 3. PDL digunakan untuk menggambarkan kebutuhan secara operasional dan sifatnya sangat dekat dengan implementasi program. 6. Dokumen kebutuhan (requirement document) Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya. Pengguna dari dokumen kebutuhan adalah pihak-pihak yang dijelaskan pada Gambar 4 yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut. Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :  menjelaskan perilaku eksternal system  menjelaskan batasan pada implementasi  mudah diubah  sebagai alat referensi untuk pemelihara system  mencatat peringatan awal tentang siklus dari system  menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal Untuk melakukan requirement engineering, dapat dilakukan dengan langkah-langkah requirement engineerings sebagai berikut : 1. Inception  mendefinisikan ruang lingkup dan batasan masalah  diperlukan pemahaman dasar tentang masalah, orang yang membutuhkan suatu solusi, pemecahan masalah yang di kehendaki, dan adanya komunikasi yang efektif serta kerjasama antara pelanggan (customer) dan pengembang (developer) 2. Elicitation membantu customer mendefinisikan apa yang dibutuhkan dalam pengembangan suatu aplikasi. Beberapa hal yang sering menghambat dalam memahami pendefinisian masalah antara lain:  Cakupan masalah, batasan masalah yang tidak di definisikan dengan baik.  Pemahaman masalah, pengguna tidak benar-benar yakin terhadap apa yang dibutuhkan dan memiliki pemahaman yang kurang terhadap kemampuan dan batasan dari lingkungan komputasi mereka.  Volatilitas dari permasalahan, kebutuhan yang sering berubah-ubah sepanjang waktu. pendukung proses kolaborasi, maka panduannya antara lain:  Adanya pertemuan dan dihadiri dari software engineering dan customer.  Peraturan untuk persiapan dan persiapan telah ada.  Adanya agenda yang dibuat secara formal.  Seorang fasilitator akan mengawasi meeting.  adanya definisi masalah.  Tujuan akhir adalah untuk mengidentifikasi masalah, tujuan dari setiap elemen solusi. 3. Elaboration merupakan suatu model analisis yang terdiri dari beberpa model dan perbaikan tugas. Hasil akhir dari elaboration ini adalah suatu model analisa yang mendefinisikan suatu informasi yang fungsional dan memiliki wilayah perilaku suatu permasalahan. 4. Negotitation merupakan aktifitas pada setiap permulaan iterasi proses piranti lunak. 5. Specification merupakan hasil akhir dari kegiatan requirements engineering. 6. Validation perlu adanya validasi kembali untuk memastikan bahwa developer mengerti permasalahannya dan customer memahami masalah dengan tepat. 7. Management membantu tim proyek untuk mengindentifikasi, pengawasan, dan melacak perubahan kebutuhan setiap saat pada tahapan proyek. Kebutuhan manajemen di mulai dengan identifikasi. Setiap kebutuhan memiliki nomor yang unik. Sekali kebutuhan tersebut di identifikasi, maka tabel pelacakan segera dibuatkan