Yani’s Weblog

it’s all about software engineering…

Kebutuhan Fungsional vs Non Fungsional

Pada tahap requirement gathering, kita harus mengumpulkan kebutuhan S/W selengkap-lengkapnya, kebutuhan fungsional maupun kebutuhan non fungsional. Kebutuhan fungsional berhubungan dengan fitur S/W yang ingin dibuat, sedangkan kebutuhan non fungsional tidak secara langsung terkait pada fitur tertentu. Kebutuhan non fungsional memberikan batasan pada kebutuhan fungional.

Contoh kebutuhan fungsional adalah (mis. untuk aplikasi perpustakaan) meminjam buku (mencatat peminjaman buku), mengelola denda, dll. Contoh kebutuhan non fungsional adalah keamanan (aplikasi hanya bisa diakses oleh pengguna yang berhak), performansi (respon aplikasi tidak boleh lebih dari 2 detik), dll.

Baik kebutuhan fungsional maupun non fungsional, harus dapat diukur dan dievaluasi di akhir pekerjaan, untuk menentukan keberhasilan dan kelengkapan pekerjaan…

October 16, 2008 - Posted by yaniwid | introduction | | 4 Comments

4 Comments »

  1. Ga jelas Bu perbedaan antara FR dan NFR.

    ISO 9126 menyatakan security adalah bagian dari fungsional. Dalam contoh pembatasan jumlah akses yang diberikan, saya bisa bayangkan ada sebuah fungsi yang mengecek jumlah akses pada saat tertentu dan jika sudah melebih jumlah maksimum, maka akses baru akan ditolak.

    Untuk usability atau maintaibility, kira-kira bagaimana cara mengukurnya Bu?

    Comment by henry | February 14, 2009

  2. Menurut saya apakah security itu FR atau NFR akan tergantung dari jenis P/L yang sedang kita buat. Jika yang kita buat adalah P/L untuk mengelola keamanan jaringan, maka fitur-fitur fungsionalnya tentu berbagai aspek security seperti membatasi jumlah akses, memblokir pengguna tertentu, dst. Fitur NF-nya misalnya, akurasi, performansi…
    Tapi untuk P/L on-line store, security bisa jadi NFR, misalnya yang boleh mengakses hanya pengguna yang sudah terdaftar. Fitur fungsionalnya adalah membeli barang, memesan barang, dst…
    Tidak perlu bingung dengan istilah. Pastikan saja bahwa seluruh kebutuhan sudah diidentifikasi, dan bisa diukur untuk menentukan keberhasilannya.

    Usability, misalnya untuk aspek ease of use, bisa diukur dari waktu yang dibutuhkan pengguna untuk belajar dulu sebelum bisa menggunakan P/L tsb. Tebal tipisnya dokumen manual bisa menjadi indikator. Jika manualnya tebal, artinya perlu effort besar untuk belajar menggunakan P/L tsb. Tapi kalau manualnya singkat atau bahkan tidak perlu ada, saking friendly-nya P/L tsb, tentu nilai usability makin tinggi…

    Maintainability misalnya bisa diukur dari modularitas program (coupling; cohesion). Atau dari waktu rata-rata yang dibutuhkan untuk melakukan modifikasi. Tapi yg terakhir ini bisa diukur setelah P/L tsb masuk cukup lama digunakan…

    Comment by yaniwid | February 16, 2009

  3. bagaimana format baku untuk menjabarkan kebutuhan fungsional dan non-fungsional suatu sistem? Apakah hanya cukup ditulis secara singkat dalam satu paragraf? Saya minta dokumen yang menjabarkan kebutuhan fungsional dan nonfungsional suatu sistem, jika ada..

    Comment by ayipeiger | April 24, 2009

  4. Tidak ada aturan/format baku untuk menulis kebutuhan fungsional dan non fungsional. Yang penting jelas, tidak ambigu, dan bisa ‘diukur’ sehingga setelah software-nya jadi, kita tahu apakah seluruh kebutuhannya sudah dipenuhi atau tidak. Penting juga untuk memberi ID pada setiap kebutuhan.
    Contoh ? Wah, harus main ke Lab RPL dong…

    Comment by yaniwid | April 25, 2009


Leave a comment

« Previous | Next »