Mengapa repot membedakan antara persyaratan fungsional dan nonfungsional?

Saya memahami perbedaan antara keduanya, tetapi saya ditanyai oleh kolega saya tentang manfaat persyaratan pelabelan sebagai fungsional atau nonfungsional (atau transisi). Kenapa repot-repot melakukannya? Dia menghabiskan apa yang dia katakan adalah dua hari melalui daftar persyaratan untuk satu proyek, dan tidak melihat manfaatnya, karena hasil akhirnya adalah menyerahkan dokumen ke badan bisnis lain dengan dekrit, "Lakukan semuanya."

Yang saya takutkan adalah persyaratan yang disatukan dalam satu dokumen. Saya mencoba menjelaskan manfaatnya secara praktis, tetapi tidak bisa menjualnya. Bagaimana cara saya menjual manfaat dari mendokumentasikan persyaratan mana yang fungsional dan mana yang tidak berfungsi.

Memisahkan persyaratan secara eksplisit akan membuatnya lebih mudah untuk merancang sistem yang tepat.

Dengan persyaratan nonfungsional (saya lebih suka atribut kualitas istilah / istilah - harus memberikan wawasan baru di luar fungsional vs tidak fungsional), Anda lebih peduli dengan sifat - sifat perangkat lunak daripada fungsionalitas. Itulah cara sistem melakukan beberapa fungsi, bukan hanya apa yang dilakukan sistem. Persyaratan kualitas memiliki pengaruh yang signifikan pada arsitektur sistem dengan cara yang persyaratan fungsional tidak dan untuk alasan ini mereka harus diperlakukan secara berbeda.

Memisahkan atribut kualitas dari persyaratan fungsional memungkinkan Anda untuk menganalisis, menentukan, dan memprioritaskan berbagai jenis persyaratan dengan cara yang berbeda. Sebagai contoh, atribut kualitas biasanya ditentukan menggunakan skenario atribut kualitas sementara persyaratan fungsional dapat berupa cerita, kasus penggunaan, pernyataan harus, atau sejumlah format lainnya. Sebagian besar sistem yang saya kerjakan memiliki kurang dari selusin atribut kualitas dan banyak, lebih banyak persyaratan fungsional.

Saya sebenarnya akan memperkenalkan jenis persyaratan lain - kendala teknis . Sekali lagi, memisahkan persyaratan secara eksplisit ke dalam tiga ember ini memberi Anda isyarat tentang bagaimana cara melakukan trade-off yang tepat saat membangun sistem. Persyaratan fungsional seringkali cukup dapat dinegosiasikan, atribut kualitas akan sangat memengaruhi arsitektur Anda dan struktur yang Anda pilih, kendala teknis tidak dapat dinegosiasikan.

Jika ini adalah tim saya, saya akan memberi tahu mereka persyaratan harus jelas dijelaskan berdasarkan jenis untuk memastikan kami tidak melewatkan sesuatu yang penting dalam arsitektur. Pikirkan driver arsitektur, bukan hanya fungsionalitasnya.

Anthony Lattanze dalam Arsitek Perangkat Lunak Sistem Intensif: Panduan Praktisi memberikan tinjauan praktis driver arsitektur dan mengapa mereka harus diperlakukan berbeda, jauh lebih komprehensif daripada ringkasan saya di sini.

Ketika setiap persyaratan memiliki prioritas / bobot yang sama (terutama "Wajib") maka Anda mungkin harus lebih khawatir daripada sekadar memisahkan persyaratan Fungsional dan Nonfungsional.

Namun demikian, ada beberapa alasan untuk memisahkan kedua kategori persyaratan:

Tanggung jawab untuk Implementasi Saya telah menemukan bahwa banyak persyaratan non-fungsional - terutama yang berfokus pada kinerja, hanya cukup berlaku untuk pengembang. Meskipun desain dapat mendukung skalabilitas dan kecepatan (dan bagian kode tertentu dapat disetel) secara umum dapat memenuhi persyaratan kinerja tergantung pada Arsitektur dan sering kali mengatur konfigurasi perangkat keras.

Tanggung jawab untuk Pengujian Seberapa mahir apakah Pengguna atau tim QA memeriksa bahwa persyaratan Keamanan, Toleransi Kesalahan, Keselamatan dan Keandalan dipenuhi?

Jangan Ulangi Dokumentasi Anda harus mengikuti prinsip KERING sama dengan kode. Persyaratan gaya UI umum harus dikelompokkan bersama. Jika orang yang bertanggung jawab atas persyaratan benar-benar menginginkannya, mereka dapat merujuk persyaratan non-fungsional (secara individu atau sebagai kelompok) dalam persyaratan fungsional.

Versi Jika Anda berada di lingkungan perusahaan dengan banyak "standar" - Anda dapat Menulis UI atau Keamanan tertentu (untuk menyebutkan pasangan) dokumen persyaratan yang dapat diversi. Dengan begitu Anda dapat menulis dalam persyaratan khusus aplikasi (kebanyakan Persyaratan Fungsional): "Aplikasi harus mematuhi V2.3 Persyaratan Keamanan yang ditentukan dalam XYZ-Company-SecReq-DocumnentNamingStandard.docx".

Mengapa repot membedakan antara persyaratan fungsional dan nonfungsional?

Salah satu alasan untuk membedakan adalah tingkat abstraksi antara kedua jenis. Persyaratan nonfungsional berada pada level sistem, dan katakan bagaimana sistem secara keseluruhan harus berperilaku. Persyaratan fungsional mengacu pada fitur tertentu dan fitur serta fungsionalitas apa yang harus disediakan untuk klien.

Persyaratan nonfungsional juga membatasi sistem, sementara persyaratan fungsional mengatakan apa yang harus dilakukan sistem. Persyaratan nonfungsional memberikan batasan tentang bagaimana persyaratan fungsional dirancang dan diimplementasikan kemudian. Dengan memisahkan mereka, menjadi mungkin untuk mengidentifikasi fitur-fitur dengan jelas dari kendala dan keterbatasan.

Yang saya takutkan adalah persyaratan yang disatukan dalam satu dokumen. Saya mencoba menjelaskan manfaatnya secara praktis, tetapi tidak bisa menjualnya. Bagaimana cara saya menjual manfaat dari mendokumentasikan persyaratan mana yang fungsional dan mana yang tidak berfungsi.

Dalam pengalaman saya, persyaratan fungsional dan non-fungsional sebenarnya dikelompokkan ke dalam dokumen yang sama atau dilacak dalam sistem yang sama. Namun, mereka diberi bagian dokumen mereka sendiri yang terpisah serta kriteria keberhasilan untuk memenuhi masing-masing.

Secara umum, Anda mengkategorikan persyaratan untuk membantu tim memenuhi mereka. Jika ada persyaratan khusus yang ditargetkan pada kebutuhan arsitektur, menyebutnya persyaratan "Arsitektur" harus membantu tim ketika mengerjakan arsitektur.

Sebuah dokumen tunggal berukuran besar dari semua persyaratan belum tentu merupakan hal yang buruk ... Menghabiskan 2 hari untuk meninjaunya juga tidak buruk. Masalahnya biasanya adalah bahwa sekali satu orang telah meninjau persyaratan, mereka mengerti, tetapi tidak mudah bagi orang lain untuk melakukan hal yang sama. Ini bisa menjadi bantuan besar untuk memulai pelabelan persyaratan dengan metadata yang akan membantu orang lain yang bergabung dengan proyek.

Mungkin mencoba menggambarkannya sebagai masalah abstraksi. Jika Anda perlu bekerja di basis kode lawas, Anda tidak hanya membaca semua baris kode yang ada kemudian mulai bekerja. Anda mengikuti struktur kode untuk membantu Anda. Memiliki beberapa struktur dalam persyaratan membantu dengan cara yang sama.

Ada banyak manfaat untuk pemisahan.

1. Hemat waktu pada Pengujian (yaitu hanya menguji persyaratan fungsional)
2. Menghemat waktu pada perubahan di masa depan untuk persyaratan (yaitu persyaratan non-fungsional akan membutuhkan waktu lebih sedikit untuk meninjau / menyetujui / mengimplementasikan / menguji)
3. Dalam dunia yang diatur (yaitu FDA, dll.), Persyaratan non-fungsional membutuhkan 1/10 dari jumlah dokumen yang diperlukan persyaratan fungsional.
4. Memberi tim kemampuan untuk membagi pekerjaan antara anggota tim senior (fungsional) dan junior (non-fungsional).

Saya bisa melanjutkan ...

Di permukaan, dua hari tampaknya seperti waktu yang lama, dalam jangka panjang bisa menghemat berminggu-minggu atau bahkan berbulan-bulan untuk pekerjaan di masa depan.