System Requirements (Kebutuhan Sistem)
Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Tujuan dari fase analisis adalah memahami dengan sebenar-benarnya kebutuhan dari sistem baru dan mengembangkan sebuah sistem yang mewadahi requirement tersebut-atau memutuskan bahwa sebenarnya pengembangan sistem baru tidak dibutuhkan. Penentuan kebutuhan sistem merupakan langkah yang paling crucial dalam tahapan SDLC. Kebutuhan Sistem bisa diartikan sebagai berikut:
a. Pernyataan tentang apa yang harus dikerjakan oleh sistem
b. Pernyataan tentang karakteristik yang harus dimiliki sistem
Tipe-tipe Kebutuhan Sistem untuk mempermudah system analis menentukan keseluruhan requirement secara lengkap, maka analis membagi kebutuhan sistem ke dalam 2 jenis, yaitu :
1. Kebutuhan Fungsional (Functional requirement).
Kebutuhan fungsional adalah jenis kebutuhan yang berisi proses-proses apa saja yang nantinya dilakukan oleh system. Kebutuhan fungsional juga berisi informasi-informasi apa saja yang harus ada dan dihasilkan oleh sistem.
2. Jenis kedua adalah Kebutuhan Non fungsional (Nonfunctional Requirements).
Requirement jenis ini adalah tipe requirement yang berisi properti perilaku yang dimiliki oleh sistem, meliputi Operasional Pada bagian ini harus dijelaskan teknis bagaimana system baru akan beroperasi. Platform sistem yang dipakai didefinisikan, apakah menggunakan windows atau Linux misalnya. Software untuk mengembangkan sistem juga ditentukan. Hardware spesifik yang diperlukan juga ditentukan. Terakhir arsitektur sistem juga dijelaskan apakah 2-tier, 3 –tier atau yang lainnya. Performance Pada bagian ini dijelaskan seberapa bagus kinerja dari software yang dikembangkan dalam mengolah data, menampilkan informasi dan secara keseluruhan menyelesaikan proses bisnis yang ditanganinya. Efisiensi dari perangkat lunak juga dicantumkan. Keamanan Kebutuhan keamanan berisi pernyataan tentang mekanisme pengamanan aplikasi, data maupun transaksi yang akan diimplementasikan pada sistem. Sistem password yang digunakan akan seperti apa dan hardware spesifik untuk pengamanan sistem juga dideskripsikan. Politik dan budaya Requirement yang isinya menyangkut atau berhubungan dengan isu politik dan budaya ditentukan disini. Isi yang secara politik dan budaya harus dijamin tidak menimbulkan persepsi negatif terhadap sistem. Berikut adalah skema Non-Fuctional Requirements
Bagan Non-Functional Requirements
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. 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.
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. 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. 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). PDL digunakan untuk menggambarkan kebutuhan secara operasional dan sifatnya sangat dekat dengan implementasi program.
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 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
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
