Persyaratan fungsional atau non-fungsional?


34

Saya bertanya-tanya tentang persyaratan fungsional atau non-fungsional. Saya telah menemukan banyak definisi berbeda untuk istilah-istilah itu dan saya tidak dapat menetapkan beberapa persyaratan saya untuk kategori yang tepat.

Saya bertanya-tanya tentang persyaratan yang tidak terhubung dengan beberapa tindakan atau memiliki beberapa kondisi tambahan, misalnya:

  1. Pada daftar perangkat yang dipilih, perangkat dapat diulang.
  2. Database harus mengandung setidaknya 100 item
  3. Mata uang dengan nilai tertentu harus dalam dolar AS.
  4. Perangkat harus memiliki nama dan nilai konsumsi daya dalam Watt.

apakah persyaratan tersebut fungsional atau tidak fungsional?


4
Saya pikir perbedaan antara "fungsional" dan "non-fungsional" menyesatkan dan cenderung meninggalkan perangkat lunak dengan operabilitas yang buruk. Saya menemukan bahwa memikirkan "fitur pengguna akhir" dan "fitur operasional" mengarah ke perangkat lunak yang lebih baik: blog.softwareoperability.com/2013/04/08/… (posting saya)
Matthew Skelton

@ MatthewSkelton Saya tidak tahu apakah (2.) adalah fitur en-user atau fitur operasi. Tampaknya menjadi "fitur pengujian".
Martin Thoma

@moose - persyaratan untuk DB untuk / beroperasi dalam parameter tertentu / diberikan 100 item lebih merupakan persyaratan operasional, meskipun ini mungkin berdampak pada pengalaman pengguna akhir jika kinerja terdegradasi. Pada akhirnya, kita mungkin perlu sedikit lebih banyak konteks tentang persyaratan dalam OP untuk dapat dipecah menjadi F dan NF, meskipun - seperti yang saya sebutkan - saya pikir ini adalah sedikit perbedaan palsu bagaimanapun :)
Matthew Skelton

Jawaban:


41

Persyaratan fungsional menentukan apa yang akan dilakukan sistem atau aplikasi - khususnya dalam konteks interaksi eksternal (dengan pengguna, atau dengan sistem lain).

Saat melakukan pemesanan baru, sistem akan menampilkan total biaya dan memerlukan konfirmasi dari pengguna. Itu adalah persyaratan fungsional; itu menggambarkan fungsi sistem.

Rujuk ke Wikipedia: Persyaratan Fungsional untuk detail lebih lanjut.

Persyaratan non-fungsional adalah persyaratan apa pun yang tidak menggambarkan perilaku input / output sistem. Perhatikan bahwa kami masih berbicara tentang persyaratan , bukan detail implementasi , jadi hanya karena kami menggunakan frasa "tidak berfungsi" tidak berarti bahwa segala sesuatu adalah permainan yang adil untuk dimasukkan ke bagian itu.

Jenis persyaratan non-fungsional paling umum yang akan Anda lihat terkait dengan operasi sistem (ketersediaan, kontinuitas, DR), kinerja (throughput, latensi, kapasitas penyimpanan), dan keamanan (otentikasi, otorisasi, audit, privasi).

Ini semua adalah masalah lintas sektoral yang memengaruhi setiap "fitur" namun sebenarnya tidak memiliki fitur itu sendiri; mereka lebih seperti metadata fitur, membantu menjelaskan tidak hanya apakah sistem melakukan apa yang seharusnya tetapi juga seberapa baik melakukannya. Jangan mengambil analogi itu terlalu jauh - itu hanya analogi.

Persyaratan non-fungsional tidak subyektif atau lambaian tangan, bertentangan dengan apa yang tampaknya disarankan oleh beberapa orang di sini. Bahkan, mereka seharusnya memiliki metrik keras yang melekat padanya (yaitu waktu respons tidak lebih dari 100 ms). Persyaratan NF juga bukan rincian implementasi atau tugas seperti "tingkatkan kerangka kerja ORM" - tidak ada petunjuk di mana orang akan mendapatkan gagasan itu.

Lebih detail di Wikipedia: Persyaratan Non-Fungsional .


Untuk secara khusus membahas contoh-contoh dalam pertanyaan:

  1. Pada daftar perangkat yang dipilih, perangkat dapat diulang.

    • Jelas persyaratan fungsional. Menjelaskan seperti apa output sistem itu.
  2. Database harus mengandung setidaknya 100 item

    • Kedengarannya seperti aturan bisnis, demikian juga persyaratan fungsional. Namun, sepertinya tidak lengkap. Apa alasan aturan ini? Apa yang akan terjadi / harus terjadi jika database berisi kurang dari 100 item?
  3. Mata uang dengan nilai tertentu harus dalam dolar AS.

    • Persyaratan fungsional, tetapi tidak benar-benar dinyatakan dengan benar. Kata-kata yang lebih berguna adalah: Sistem harus mendukung satu mata uang (USD). Jelas ini akan diubah jika lebih dari satu mata uang perlu didukung, dan kemudian persyaratan harus mencakup informasi tentang konversi mata uang dan sebagainya.
  4. Perangkat harus memiliki nama dan nilai konsumsi daya dalam Watt.

    • Tidak benar-benar persyaratan apa pun, ini lebih seperti spesifikasi teknis. Persyaratan fungsional akan dinyatakan karena peringkat daya diasumsikan dalam Watt. Jika ada lebih dari satu UOM, maka seperti halnya dengan mata uang, persyaratan fungsional harus memiliki bagian tentang konversi unit, di mana / bagaimana mereka dikonfigurasikan, dll. (Jika berlaku).

Bagus! Yang saya tambahkan adalah bahwa persyaratan fungsional tidak perlu hanya berurusan dengan interaksi dengan lingkungan eksternal (konsep terkait adalah "persyaratan antarmuka" dengan sistem lain). Contoh tandingan untuk ini adalah "Sistem harus mengindeks database pengguna setiap 60 menit". Ini jelas internal.
Aram Kocharyan

2
@AramKocharyan: Itu bukan persyaratan fungsional. Jelas ada pelanggan SLA yang bersembunyi di sana di suatu tempat, dan itu adalah persyaratan fungsional. "Pembaruan kontak harus diproses dalam 60 menit untuk mendukung layanan / pemasaran pelanggan tepat waktu" - yang merupakan persyaratan internal dan fungsional. "Mengindeks database pengguna" bukanlah persyaratan sama sekali, ini merupakan implementasi; misalnya, cara lain untuk bertemu kata SLA bisa dengan menggunakan pengindeksan latar belakang realtime, atau untuk menghilangkan kebutuhan untuk pengindeksan sepenuhnya dengan menggunakan broker layanan atau bus dan memproses pembaruan dalam waktu dekat.
Aaronaught

+1! mengenai subjektivitas persyaratan non-fungsional, mungkin cukup untuk menunjukkan bahwa itu adalah inti dari arsitektur
RESTful

18

Sudah ada jawaban yang sangat baik oleh Aaronaught, tetapi karena ada jawaban lain, sekarang dihapus, yang benar-benar salah tentang apa persyaratan non-fungsional, saya pikir akan berguna untuk menambahkan beberapa penjelasan untuk menghindari kesalahan tentang apa yang persyaratan non-fungsional adalah.


Persyaratan non-fungsional adalah "kualitas atau properti yang harus dimiliki produk" ¹. James Taylor mengatakan bahwa persyaratan non-fungsional "[...] adalah [tetap] persyaratan, dan itu penting bagi pelanggan — kadang-kadang bahkan lebih penting daripada persyaratan fungsional" . Dia kemudian memberikan dua contoh: logo produk, dan keakuratan dan keandalan peralatan. Kedua contoh itu menunjukkan dengan sangat baik bahwa:

  • Persyaratan non-fungsional bukan jibber-jabber pemasaran seperti: "Internet penting saat ini dan kami ingin memiliki situs web".
  • Persyaratan non-fungsional menjadi perhatian pelanggan, karena mereka dapat sangat mempengaruhi produktivitas dan kemampuan itu sendiri untuk menggunakan produk.
  • Persyaratan non-fungsional sepenuhnya objektif.

Poin terakhir sangat penting. Jika persyaratan bersifat subjektif, maka tidak ada hubungannya dalam daftar persyaratan. Tidak mungkin membangun tes validasi dari sesuatu yang subjektif . Satu-satunya tujuan dari daftar persyaratan adalah untuk menyebutkan harapan pelanggan yang tidak ambigu. "Saya ingin kotak ini berwarna merah" adalah persyaratan. "Saya ingin kotak ini memiliki warna yang bagus" adalah keinginan yang membutuhkan penjelasan.

Ingat bahwa daftar persyaratan seperti kontrak (dan dalam kebanyakan kasus adalah bagian dari kontrak). Itu ditandatangani oleh pelanggan dan perusahaan pengembangan, dan dalam kasus litigasi, itu akan digunakan secara legal untuk menentukan apakah Anda telah melakukan pekerjaan Anda dengan benar. Bagaimana jika saya memesan produk perangkat lunak untuk Anda, tentukan bahwa "produk itu harus hebat", dan menolak untuk membayar ketika produk itu dibuat, karena bagi saya, apa yang sebenarnya Anda lakukan bukanlah produk yang hebat ?

Jadi, mari kita lihat beberapa contoh.

  1. Produk perangkat lunak responsif kepada pengguna akhir.

Ini bukan persyaratan. Bukan fungsional. Bukan yang non-fungsional. Itu hanya bukan keharusan. Sama sekali. Ini memiliki nilai nol. Anda tidak dapat memeriksa apakah sistem perangkat lunak memenuhi persyaratan ini selama pengujian validasi. Baik Anda - departemen QA, maupun pelanggan.

  2. Memuat ulang statistik pengguna melakukan 90% dari waktu di bawah 100 ms. ketika diuji pada mesin dengan kinerja yang ditentukan dalam lampiran G bagian 2 dan beban di bawah 10% untuk CPU, di bawah 50% untuk memori dan tidak ada operasi disk R / W aktif.

Itu adalah persyaratan. Jika lampiran G bagian 2 cukup tepat, saya dapat membawa mesin dengan perangkat keras yang sama dan melakukan tes validasi di departemen QA, dan saya akan selalu mendapatkan hasil biner: lulus atau gagal.

Apakah ini persyaratan fungsional? Tidak. Tidak menjelaskan apa yang harus dilakukan sistem. Mungkin ada persyaratan fungsional sebelumnya, yang menyatakan bahwa aplikasi perangkat lunak harus dapat memuat ulang statistik pengguna.

Apakah ini persyaratan non-fungsional? Ini. Ini menentukan properti yang harus dimiliki suatu produk, yaitu waktu respons maksimum / rata-rata, berdasarkan ambang batas persentase.

  3. Aplikasi ini ditulis dalam C #.

Apakah ini persyaratan? Kami tidak benar-benar tahu tanpa konteks. Mungkin keinginan pengembang utama, yang ingin, dengan memasukkan persyaratan ini, untuk menghindari kemudian diskusi dengan rekan-rekannya tentang bahasa yang akan digunakan. Mungkin juga persyaratan berdasarkan perangkat keras / lunak, warisan atau elemen kompatibilitas. Kami tidak tahu.

  4. C # basis kode produk mengikuti Microsoft Minimum Recommended Rules dan Microsoft Globalization Rules.

Ini hal yang aneh. Secara pribadi, saya lebih suka tidak menyebutnya sebagai persyaratan, dan memasukkannya ke dalam dokumen terpisah yang menetapkan standar dan praktik terbaik.

  5. Jendela utama aplikasi memiliki perbatasan 10px biru (# 00f) dengan lingkaran diisi merah muda (#fcc), lingkaran-lingkaran itu ditempatkan di tepi bagian dalam perbatasan dan berdiameter 3px, dipisahkan oleh 20px satu sama lain.

Ini adalah persyaratan, dan yang non-fungsional. Ini menentukan sesuatu yang dapat kami uji selama pengujian validasi, dan itu menentukan properti produk, bukan apa yang dimaksudkan untuk dilakukan produk.

  6. Sistem pelacakan kendaraan mengukur kecepatan dengan ketelitian ± 0,016 mph.

Juga persyaratan non-fungsional. Ini memberikan ambang batas terukur dari presisi sistem. Itu tidak memberi tahu apa yang harus dilakukan sistem, tetapi mengatakan seberapa tepat kerjanya. Tapi tunggu? Ini memberi tahu bahwa sistem pelacakan kendaraan mengukur kecepatan, bukan? Jadi itu persyaratan fungsional juga? Ya, tidak, karena kita aksen pada ketepatan pengukuran, bukan pada fakta bahwa pengukuran dilakukan.

  7. Sistem pelacakan kendaraan mengukur kecepatan kendaraan.

Sekarang ini persyaratan fungsional. Tidak tahu bagaimana sistem bekerja, tetapi apa yang dilakukannya. Melalui persyaratan fungsional, kita dapat belajar bahwa sistem pelacakan kendaraan mengukur kecepatan, daya baterai, tekanan Saya tidak tahu apa dan apakah lampu menyala atau tidak.

  8. Halaman situs web membutuhkan 850 ms. untuk memuat.

Ini bukan persyaratan. Mencoba menjadi satu, tetapi sama sekali tidak valid. Bagaimana Anda akan menghargai ini? Halaman apa? Semua? Diuji melalui jaringan 1Gbps lokal pada mesin klien quad-core dan server delapan-core dengan SSD yang digunakan sebesar 2%, atau melalui modem dari laptop tua dan jelek saat situs web di-host oleh server kecil yang digunakan sebesar 99% ? Apa yang dimaksud dengan "memuat"? Apakah itu berarti mengunduh halaman? Mengunduh dan menampilkannya? Mengirim permintaan POST dengan beberapa data besar, lalu memuat respons dan menampilkannya?

Untuk menyimpulkan, persyaratan non-fungsional selalu merupakan persyaratan, yang berarti persyaratan non-fungsional menggambarkan sesuatu yang benar-benar objektif dan dapat diperiksa melalui tes validasi otomatis atau manual, tetapi alih-alih memberi tahu apa yang dilakukan sistem, itu menjelaskan bagaimana sistem sedang melakukan sesuatu atau bagaimana sistem itu sendiri .


¹ Mengelola Proyek Teknologi Informasi: Menerapkan Strategi Manajemen Proyek untuk Inisiatif Perangkat Lunak, Perangkat Keras, dan Integrasi, James Taylor, ISBN: 0814408117.


+1 untuk detail. Saya agak tidak setuju dengan pendapat Anda dalam (1), Anda mengatakan "ini bukan keharusan". Saya pikir itu adalah persyaratan tetapi analis bisnis harus menjadikannya persyaratan "terukur" sebelum tim berkomitmen untuk itu. Saya juga menyukai penggunaan kata "keinginan" dan perbedaan antara "keinginan" dan "persyaratan"
NoChance

@Emmad Kareem: Anda benar. Saya membatasi diri pada persyaratan teknis semata, yaitu persyaratan yang akan digunakan oleh pengembang dan QA. Untuk analis bisnis, segala sesuatunya sedikit berbeda, dan beberapa elemen yang saya anggap sebagai persyaratan tidak benar-benar valid.
Arseni Mourzenko

Saya berpendapat "Aplikasi ini ditulis dalam bahasa C #." adalah kendala, bukan persyaratan fungsional, karena tidak menggambarkan perilaku sistem, tetapi menganggap keterbatasan ruang solusi.
Aram Kocharyan

@AramKocharyan: itu sebabnya saya mengatakan bahwa kita tidak tahu apakah pernyataan ini merupakan persyaratan sama sekali.
Arseni Mourzenko

3

Sebuah persyaratan fungsional menggambarkan hasil berinteraksi dengan sistem (sistem apa yang dilakukannya dalam situasi tertentu), sedangkan kebutuhan non-fungsional biasanya mengacu pada spesifikasi kinerja, kapasitas, waktu respon, dll ... hal-hal yang tidak mewakili fungsionalitas, sebuah proses dalam sistem, atau hasil dari suatu interaksi.

Karena itu, persyaratan non-fungsional yang Anda gambarkan sebenarnya persyaratan fungsional dengan spesifikasi teknis (yang sebenarnya membuatnya menjadi persyaratan buruk). Contoh persyaratan non-fungsional untuk kasus Anda akan menjadi seperti ini:

- UI tidak boleh dikunci saat animasi dadu berjalan.

Persyaratan pengguna biasanya persyaratan UI khusus, yang tergantung pada konteksnya akan fungsional atau non-fungsional, sedangkan persyaratan sistem (kapasitas pengguna bersamaan, misalnya) biasanya sebagian besar tidak berfungsi.


2

Hanya untuk menambahkan beberapa jawaban yang baik yang ada bahwa persyaratan non-fungsional kadang-kadang disebut "ilities" - kualitas yang perlu dimiliki sistem sebagai tambahan fungsionalitasnya yang sederhana. "Iilities" termasuk ketersediaan, kegunaan, keamanan, fleksibilitas - dan bahkan estetika yang lebih subyektif.

Beberapa di antaranya sangat sulit untuk ditentukan dan dinilai. Namun demikian, itu penting. Jika Anda mendaftar secara kontraktual, maka Anda ingin menghindari versi bergelombang tangan yang tidak berarti, misalnya "Sistem harus aman". Masalah dengan mencoba memakukan persyaratan seperti itu adalah bahwa orang cenderung tertarik pada hal-hal yang mudah diukur, daripada hal-hal yang penting (dan persyaratan mungkin ditulis oleh orang-orang yang tidak memiliki landasan dalam spesialisasi yang relevan ). Hasil akhirnya adalah bahwa Anda biasanya berakhir dengan sistem yang tidak aman, tidak dapat digunakan, atau fleksibel (ketersediaan tidak begitu sulit untuk ditentukan dan diukur, meskipun masih menyebabkan banyak sakit kepala).

Ada perbedaan budaya di sini antara orang-orang yang berurusan dengan kontrak dan barang-barang formal, dan orang-orang yang berurusan dengan analisis yang lebih umum, arsitektur, penelitian dll. Persyaratan tangan-bergelombang masih merupakan persyaratan sejauh menyangkut yang terakhir, karena mengungkapkan hal-hal yang penting bagi pelanggan, bahkan jika mereka bersimpati sepenuhnya dengan orang-orang kontraktual bahwa itu bukan persyaratan kontrak yang berguna sampai telah dieksplorasi secara rinci dan benar-benar diselesaikan.

Satu poin terakhir - jika Anda tidak dapat (belum) menghasilkan ukuran obyektif dari "ility", itu tidak berarti pelanggan tidak membutuhkannya. Jelas! = Tidak perlu. Namun, itu mungkin berarti kita perlu mengembangkan cara yang lebih baik untuk mengukur hal-hal seperti itu, mendapatkan dan memperbaiki persyaratan non-fungsional secara bertahap, atau mengontrak dengan cara (Agile dll) yang dapat bekerja tanpa langkah-langkah obyektif di muka untuk semuanya.


0

Semua komentar ini sangat bagus tetapi terlalu matang dan tidak menawarkan templat yang jelas untuk dikerjakan. Bukankah jelas untuk menetapkannya sebagai:

Menurut pendapat saya, persyaratan fungsional adalah apa yang dialami pengguna saat menggunakan aplikasi. Ini adalah persyaratan yang harus dipenuhi ketika pengembang mencoba menerapkan ini dari awal, melakukan peningkatan atau modifikasi. Misalnya: pengguna harus masuk. Katakanlah jika Anda juga menambahkan cara baru untuk menjalankan aplikasi melalui command prompt maka pengguna masih harus masuk.

Persyaratan non-fungsional terjadi di bawah kap. Pengguna tidak menyadarinya, tetapi harus ada di sana namun diterapkan. Sebagai contoh: Aplikasi harus dikembangkan dalam C #. Jika dikembangkan dalam bahasa lain apa pun, pengguna tidak akan melihatnya. Tapi itu mungkin persyaratan karena didasarkan pada kode yang ada. Contoh lain adalah bahwa itu harus diinstal pada server tertentu. Memindahkan server tidak akan diperhatikan oleh pengguna.


-1

Fungsional atau tidak fungsional? Saya akan mengatakan tidak. Kebanyakan, jika tidak semua contoh yang tercantum terlihat seperti aturan bisnis bagi saya (menetapkan batasan terkait proses dan aturan keputusan yang harus diikuti oleh proses sistem).

Mereka adalah sesuatu yang dilupakan oleh banyak insinyur atau tidak disadari, karena aturan bisnis biasanya dikumpulkan sebagai bagian dari analisis bisnis (dan sering tertanam dalam spesifikasi persyaratan fungsional daripada direferensikan secara eksternal).


mengapa contoh yang tercantum terlihat seperti aturan bisnis bagi Anda?
nyamuk

-4

Persyaratan fungsional biasanya adalah sesuatu yang sistem dapat atau akan lakukan. Ini dapat diekspresikan sebagai hasil dari tindakan (Dari hasil negatif). Persyaratan non fucntional adalah sesuatu yang tidak dipedulikan pelanggan / pengguna akhir, dan tidak mempengaruhi hasilnya - misalnya
- Windows akan memiliki batas biru dengan titik-titik merah muda. - Program ini akan ditulis dalam Java
- Ada hubungannya dengan standar pengkodean, metode dan proses.

Namun perlu diingat bahwa persyaratan non-fungsional dapat diubah menjadi persyaratan fungsional oleh pelanggan. contoh mungkin - Program ini akan ditulis dalam bahasa Erlang karena pelanggan membaca artikel majalah di atasnya dan ingin itu ditulis dalam bahasa Erlang. - Program harus menggunakan DB 2. karena pelanggan akan menjalankannya pada sistem DB 2 yang ada, memiliki pengalaman bertahun-tahun dan tim TI yang akrab dengan platform itu.
- Kode sumber harus lulus semua rekomendasi MISRA.

Singkatnya - jika pelanggan peduli tentang hal itu, itu adalah persyaratan fungsional, jika tidak, itu merupakan persyaratan non-fungsional atau bahkan mungkin bukan persyaratan.


1
-1. Baik pelanggan dan pengguna akhir melakukan peduli tentang persyaratan non-fungsional, karena mereka mempengaruhi secara langsung produktivitas mereka. Selain itu, persyaratan non-fungsional tidak dapat diubah menjadi persyaratan fungsional oleh pelanggan: tidak tergantung pada pelanggan untuk memilih apakah persyaratan fungsional atau non-fungsional.
Arseni Mourzenko

juga, non-func dapat dipecah menjadi kualitas "pengembangan" (pengembang peduli, misalnya pemeliharaan) dan "operasional" (pengguna peduli, misalnya kemudahan penggunaan)
Aram Kocharyan

-4

Saya pikir persyaratan fungsional adalah hal yang diperlukan untuk menggambarkan sistem dan perilakunya, tetapi persyaratan non-fungsional tidak diperlukan untuk sistem dan tidak dikumpulkan selama negosiasi perancangan sistem. , keamanan, pemeliharaan, dll. dari sistem yang dibangun.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.