Kebutuhan Fungsional vs Nonfungsional

Dalam siklus pengembangan aplikasi atau rekayasa perangkat lunak, biasanya akan diawali dengan proses rekayasa kebutuhan. Tahapan ini menjadi langkah bagi para pengembang dalam menemukan atau mengurai ide atau pemikiran calon pengguna perangkat lunak yang bertindak sebagai klien. Ide atau pemikiran tadi pada akhirnya harus didetailkan dalam bentuk daftar kebutuhan (requirement list) yang nantinya didokumentasikan sebagai dokumen spesifikasi kebutuhan perangkat lunak (SKPL).

Dalam Software Engineering Body of Knowledge (SWEBOK), kebutuhan dibedakan menjadi dua jenis, yaitu kebutuhan fungsional dan nonfungsional (cara penulisan yang salah: non fungsional, cek ini). Perbedaan jenis kebutuhan ini kadang agak kurang dipahami oleh para pengembang muda, terutama yang belum mengenal SWEBOK atau kurang teliti dalam membaca bahan bacaan yang berbau rekayasa perangkat lunak.

Kebutuhan fungsional mendeskripsikan fungsi-fungsi yang harus bisa dieksekusi atau dilakukan oleh perangkat lunak.

Kebutuhan ini sering juga disebut kemampuan atau fitur. Contohnya: memformat teks, mengirim pesan, atau mengunduh gambar. Kebutuhan fungsional dapat juga dideskripsikan sebagai sebuah kebutuhan yang mampu divalidasi perilaku (behavior)-nya berdasarkan langkah-langkah uji yang terdefinisikan.

Kebutuhan nonfungsional merupakan kebutuhan yang memberikan batasan atas solusi yang diberikan.

Kebutuhan nonfungsional sering juga disebut batasan kebutuhan atau kebutuhan yang berkaitan dengan kualitas. Selanjutnya, kebutuhan ini dapat diklasifikasikan lebih detail lagi menjadi kebutuhan yang berkaitan dengan aspek performa (performance), pemeliharaan (maintainability), keselamatan (safety), reliabilitas (reliability), keamanan (security), interoperabilitas (interoperability), atau bentuk lainnya yang masih berkaitan dengan aspek kualitas atas perangkat lunak.

Kebutuhan-kebutuhan ini harusnya didefinisikan sejelas mungkin, tidak ambigu, bahkan dapat dikuantifikasi, jika memungkinkan, terutama untuk kebutuhan-kebutuhan yang sifatnya nonfungsional. Pendefinisian ini sebisa mungkin dapat diverifikasi dan tidak multiinterpretasi (subjektif), seperti "perangkat lunak harus bisa diandalkan" atau "perangkat lunak harus mudah digunakan (user-friendly)". Frasa bisa diandalkan dan mudah digunakan ini menjadi masalah saat dituliskan dalam sebuah definisi kebutuhan karena tidak ada ukuran yang jelas bagaimana definisi kualitas tersebut dapat diverifikasi.

Definisi-definisi kebutuhan yang masih subjektif tersebut (terutama kebutuhan nonfungsional) dapat diganti menjadi seperti "perangkat lunak call center harus bisa meningkatkan jumlah layanan sebesar 20%", "perangkat lunak harus memiliki probabilitas dalam melakukan kesalahan fatal selama satu jam pengoperasian tidak lebih dari 1×10^-8", "perangkat lunak harus bisa diakses oleh 1 juta pengguna dalam 1 detik", atau definisi-definisi lain yang memang, jika memungkinkan, dapat dikuantifikasi, ada ukuran yang bisa diuji di kemudian hari. Hal ini, pada akhirnya akan memengaruhi arsitektur perangkat lunak, perangkat keras, ataupun infrastruktur yang dibutuhkan.