Apa Persyaratan Non-Fungsional dalam Rekayasa Perangkat Lunak?

⚡ Ringkasan Cerdas

Persyaratan Non-Fungsional menentukan atribut kualitas seperti kinerja, keamanan, kegunaan, keandalan, skalabilitas, dan portabilitas, mendefinisikan seberapa baik sistem perangkat lunak harus berperilaku dan mengubah ekspektasi yang samar menjadi target rekayasa yang terukur, dapat diuji, dan dapat ditegakkan di seluruh siklus hidup pengiriman.

📘 Definisi: Persyaratan Non-Fungsional, atau NFR, menjelaskan seberapa baik kinerja suatu sistem dalam hal performa, keamanan, kegunaan, keandalan, dan portabilitas.
️ Jenis Umum: Kemudahan penggunaan, keamanan, keandalan, skalabilitas, kapasitas, ketersediaan, pemeliharaan, dan kepatuhan terhadap peraturan adalah kategori-kategori yang menjadi fokus tim. track paling sering.
📊 Model FURPS+: FURPS+ mengelompokkan NFR (Non-Functional Requirements) ke dalam fungsionalitas, kegunaan, keandalan, kinerja, kemampuan dukungan, dan batasan desain atau antarmuka.
🎯 Pernyataan yang Dapat Diuji: Gantikan kata “cepat” atau “aman” dengan ambang batas numerik dan metode verifikasi agar NFR dapat diuji dan diterima.
🆚 Kontras Fungsional: Persyaratan fungsional menyatakan apa yang dilakukan sistem; persyaratan non-fungsional menyatakan seberapa baik sistem tersebut melakukannya dalam kondisi nyata.
✅ Dampak bisnis: Hilangnya NFR (Non-Functional Requirements) adalah penyebab utama insiden produksi, temuan regulasi, dan pengerjaan ulang arsitektur tahap akhir yang mahal.

Baca Selengkapnya

Apa itu Persyaratan Non-Fungsional?

A Persyaratan Non-Fungsional (NFR) menentukan atribut kualitas dari suatu sistem perangkat lunak. NFR menilai sistem berdasarkan daya tanggap, kegunaan, keamanan, portabilitas, dan atribut kualitas lainnya yang penting untuk keberhasilan. Contoh umum dari persyaratan non-fungsional adalah, “seberapa cepat situs web dimuat?” Kegagalan memenuhi persyaratan non-fungsional menghasilkan sistem yang membuat pengguna frustrasi.

Persyaratan Non-Fungsional dalam rekayasa perangkat lunak memberikan batasan pada desain sistem di seluruh backlog agile. Misalnya, situs web harus memuat dalam tiga detik ketika pengguna bersamaan melebihi 10,000. Mendeskripsikan persyaratan non-fungsional sama pentingnya dengan menangkap persyaratan fungsional.

Jenis-Jenis Persyaratan Non-Fungsional

Kategori utama dari persyaratan non-fungsional adalah:

Jenis Persyaratan Non Fungsional

Usability
Kemampuan melayani
pengelolaan
Dapat dipulihkan
Security
Data Integrity
Kapasitas
Ketersediaan
Skalabilitas
Interoperabilitas
Keandalan
Maintainability
Kepatuhan terhadap Regulasi
Kendala Lingkungan

Contoh Persyaratan Non-Fungsional

Berikut adalah contoh praktis dari persyaratan non-fungsional:

Pengguna wajib mengubah kata sandi awal setelah berhasil masuk untuk pertama kalinya, dan kata sandi awal tersebut tidak boleh digunakan kembali.
Karyawan tidak diperbolehkan memperbarui informasi gaji mereka sendiri, dan setiap upaya tersebut harus dilaporkan kepada administrator keamanan.
Setiap upaya pengguna yang gagal untuk mengakses suatu item data harus dicatat dalam jejak audit.
Situs web tersebut harus mampu mendukung 20 juta pengguna secara bersamaan tanpa mengurangi waktu respons.
Perangkat lunak tersebut harus portabel sehingga perpindahan dari satu sistem operasi ke sistem operasi lain tidak menimbulkan masalah.
Kerahasiaan informasi, ekspor teknologi yang dibatasi, dan hak kekayaan intelektual harus dapat diaudit.

Persyaratan Fungsional vs. Persyaratan Non-Fungsional

Perbedaan utama antara persyaratan fungsional dan non-fungsional adalah:

Parameter Teknis	Persyaratan Fungsional	Persyaratan Non-Fungsional
Apa itu?	Kata kerja	atribut
Kebutuhan	Itu wajib	Ini tidak wajib
Tipe penangkapan	Itu ditangkap dalam kasus penggunaan.	Itu ditangkap sebagai atribut kualitas.
Hasil akhir	Fitur Produk	Properti produk
Menangkap	Mudah ditangkap	Sulit ditangkap
Tujuan	Membantu Anda memverifikasi fungsionalitas perangkat lunak.	Membantu Anda memverifikasi kinerja perangkat lunak.
Area fokus	Fokus pada kebutuhan pengguna	Berkonsentrasi pada harapan pengguna.
Dokumentasi	Jelaskan fungsi produk tersebut	Menjelaskan cara kerja produk
Jenis Pengujian	Pengujian Fungsional seperti pengujian Sistem, Integrasi, End-to-End, API, dll.	Pengujian Non-Fungsional seperti Pengujian Kinerja, Stres, Kegunaan, Keamanan, dll.
Eksekusi Tes	Eksekusi Tes dilakukan sebelum pengujian non-fungsional.	Setelah pengujian fungsional
Info Produk	Fitur Produk	Properti Produk

Keuntungan dari Persyaratan Non-Fungsional

Manfaat utama dari Pengujian non-fungsional adalah:

Persyaratan non-fungsional memastikan sistem mematuhi aturan hukum dan kepatuhan.
Mereka melindungi keandalan, ketersediaan, dan kinerja sistem.
Mereka memberikan pengalaman pengguna yang baik dan kemudahan pengoperasian.
Mereka membentuk kebijakan keamanan perangkat lunak tersebut.

Kekurangan Persyaratan Non-Fungsional

Kelemahan umum dari persyaratan non-fungsional adalah:

Persyaratan non-fungsional dapat memengaruhi beberapa subsistem perangkat lunak tingkat tinggi.
Hal tersebut memerlukan pertimbangan khusus selama tahap arsitektur dan desain tingkat tinggi, yang meningkatkan biaya.
Implementasi jarang sekali sesuai dengan satu subsistem perangkat lunak tunggal.
Setelah fase arsitektur selesai, sulit untuk memodifikasinya.

Model FURPS+ untuk Mengklasifikasikan Persyaratan Non-Fungsional

FURPS+ adalah taksonomi yang paling banyak digunakan untuk persyaratan non-fungsional. Awalnya dikembangkan di Hewlett-Packard, taksonomi ini mengelompokkan atribut kualitas ke dalam lima kategori utama ditambah batasan tambahan yang ditandai dengan "+". Model ini membantu Analis Bisnis menghindari terlewatnya seluruh kelas persyaratan.

Fungsi: Kemampuan, keamanan, dan penggunaan kembali yang melampaui daftar fitur dasar.
Kegunaan: Faktor manusia, estetika, konsistensi, dokumentasi, dan daya tanggap pengalaman pengguna.
Keandalan: Ketersediaan, waktu rata-rata antar kegagalan, kemampuan pemulihan, prediktabilitas, dan akurasi.
Kinerja: Kecepatan, throughput, kapasitas, skalabilitas, dan konsumsi sumber daya di bawah beban.
Dukungan: Kemampuan pengujian, fleksibilitas, kemudahan instalasi, kemampuan lokalisasi, dan kemudahan pemeliharaan sistem yang dikirimkan.
Plus (+): Desain, implementasi, antarmuka, dan batasan fisik seperti platform, standar, atau perangkat keras yang dibutuhkan.

Tim yang memetakan setiap persyaratan non-fungsional ke kategori FURPS+ cenderung tidak akan mengirimkan sistem yang memenuhi fitur tetapi gagal dalam hal kinerja, keamanan, atau pemeliharaan.

Cara Menulis Persyaratan Non-Fungsional yang Dapat Diuji

Persyaratan non-fungsional yang ditulis dengan baik dapat diukur, diverifikasi, dan dibatasi waktu. Pernyataan yang samar seperti "sistem harus cepat" atau "aplikasi harus aman" adalah aspirasi, bukan persyaratan. Ikuti langkah-langkah di bawah ini untuk mengubah maksud menjadi NFR yang dapat diuji.

Identifikasi atribut kualitas tersebut. Petakan permasalahan tersebut ke dalam kategori FURPS+ sehingga tim mengetahui apakah itu merupakan persyaratan kinerja, kegunaan, keamanan, atau keandalan.
Pilih metrik. Setiap NFR (Non-Functional Requirements) memerlukan satuan — milidetik, permintaan per detik, pengguna bersamaan, persentase waktu aktif, atau standar kepatuhan seperti ISO 27001.
Tetapkan ambang batas numerik. Ganti “cepat” dengan “kurang dari 400 milidetik pada persentil ke-95”. Ganti “sangat tersedia” dengan “waktu aktif bulanan 99.9 persen”.
Jelaskan kondisinya. Sebutkan beban, lingkungan, atau segmen pengguna yang menjadi sasaran ambang batas, misalnya “selama puncak penjualan dengan 10,000 pengguna bersamaan”.
Definisikan metode verifikasi. Catat jenis pengujiannya — pengujian beban, pengujian penetrasi, eksperimen kekacauan, audit aksesibilitas — dan alat yang akan mengkonfirmasi ambang batas tersebut.
Terapkan pemeriksaan SMART. Konfirmasikan bahwa persyaratan tersebut Spesifik, Terukur, Dapat Dicapai, Relevan, dan Terbatas Waktu sebelum dimasukkan ke dalam backlog.

Contoh penulisan ulang: “Sistem harus cepat” menjadi “Halaman pembayaran harus merespons dalam waktu kurang dari 500 milidetik pada persentil ke-95 dengan 5,000 pengguna bersamaan, diverifikasi oleh sebuah JMeter "Uji beban setiap rilis." Pernyataan yang direvisi memungkinkan pengembang untuk mendesainnya, penguji untuk memverifikasinya, dan pemilik produk untuk menerimanya tanpa perdebatan.

Pertanyaan Umum Demo Slot

Alat beban dan kinerja berbasis AI menghasilkan lalu lintas realistis, mendeteksi anomali dalam distribusi waktu respons, dan memprediksi batasan penskalaan sebelum produksi. AI juga memeriksa log dan pola akses untuk menandai peristiwa keamanan yang terlewatkan oleh alat berbasis aturan tradisional.

Copilot dan GPT mengubah pernyataan kualitas yang samar menjadi NFR (Non-Functional Requirements) yang terukur dengan metrik, ambang batas, kondisi, dan metode verifikasi. Analis Bisnis meninjau setiap draf berdasarkan kategori FURPS+ dan kerangka kerja SMART sebelum menerimanya ke dalam backlog.

Pengujian fungsional memeriksa apakah fitur-fitur berfungsi dengan benar, seperti login atau pencarian. Pengujian non-fungsional mengukur seberapa baik sistem berkinerja di bawah beban, tekanan, dan penggunaan, mencakup target kinerja, keamanan, kegunaan, kompatibilitas, dan keandalan.

Skalabilitas, ketersediaan, latensi, elastisitas, dan efisiensi biaya mendominasi NFR (Non-Functional Requirements) cloud. Tim juga tracObservabilitas, tujuan pemulihan bencana seperti RPO dan RTO, serta kepatuhan multi-wilayah menjadi faktor penting karena hal-hal tersebut mendorong sebagian besar keputusan arsitektur cloud.

Pilih metrik dengan satuan, tetapkan ambang batas numerik, jelaskan kondisi di mana metrik tersebut berlaku, dan sebutkan metode verifikasinya. Misalnya, waktu respons di bawah 400 milidetik pada persentil ke-95 dengan 5,000 pengguna, diverifikasi oleh JMeter.

Enkripsi data saat disimpan dan saat ditransmisikan, kekuatan otentikasi, otorisasi berbasis peran, pencatatan audit, batas waktu sesi, dan kepatuhan terhadap standar seperti ISO 27001, PCI DSS, dan GDPR adalah persyaratan keamanan non-fungsional (NFR) yang paling banyak didokumentasikan oleh tim.

Menggunakan kata sifat yang ambigu, menghilangkan metrik atau kondisi, hanya mencantumkan NFR (Non-Functional Requirements) di akhir proyek, dan menyalin-tempel kode standar yang tidak dapat diverifikasi oleh pengujian apa pun adalah kesalahan paling umum yang menyebabkan pengerjaan ulang arsitektur di tahap akhir.

NFR (Non-Functional Requirements) terdapat dalam Spesifikasi Persyaratan Perangkat Lunak, catatan keputusan arsitektur, perjanjian tingkat layanan, dan daftar periksa definisi selesai. Tim Agile sering melampirkan NFR yang terukur pada epik dan pada definisi siap untuk setiap cerita pengguna.