Apa kata yang lebih baik untuk persyaratan opsional dalam rekayasa perangkat lunak? Ungkapan itu kontradiktif. Saya telah menggunakan "Persyaratan Non-Inti" dalam proyek sebelumnya.
Apa kata yang lebih baik untuk persyaratan opsional dalam rekayasa perangkat lunak? Ungkapan itu kontradiktif. Saya telah menggunakan "Persyaratan Non-Inti" dalam proyek sebelumnya.
Jawaban:
Istilah "di luar ruang lingkup persyaratan" mungkin dapat digunakan. Ini berarti bahwa persyaratan telah ditangkap dalam proses Anda dan dapat dilacak, tetapi telah ditentukan bahwa persyaratan tersebut adalah sesuatu yang berada di luar lingkup sistem saat ini, karena sejumlah alasan, seperti anggaran, jadwal, waktu, atau kelayakan.
Namun, frasa "persyaratan opsional" biasanya digunakan untuk menunjukkan sesuatu yang ada dalam ruang lingkup, tetapi tidak harus diminta oleh sistem. Ini adalah ukuran prioritas kebutuhan. Dalam pengalaman saya, persyaratan sering diprioritaskan sebagai wajib, diinginkan, atau opsional (walaupun ada juga skema lain). Agar proyek dianggap lengkap dan berfungsi penuh, semua persyaratan wajib harus dipenuhi. Dengan sumber daya yang memadai, persyaratan yang diinginkan akan diterapkan selanjutnya. Akhirnya, apa pun yang dianggap opsional akan dimasukkan.
Saya percaya kebingungan berasal dari istilah "persyaratan". Dalam bahasa Inggris, persyaratan adalah "hal yang diperlukan" atau "syarat wajib, wajib, atau perlu". Namun, dalam rekayasa perangkat lunak, persyaratan istilah hanyalah karakteristik yang didokumentasikan dari sistem perangkat lunak. Konsep opsional dan wajib menjelaskan prioritas karakteristik yang terdokumentasi dari sistem perangkat lunak.
Kami menyebut mereka sebagai fitur "senang memiliki" yang bertentangan dengan persyaratan.
Untuk dokumentasi persyaratan perangkat lunak, kata-kata Persyaratan Opsional benar-benar OK, selama Anda menggunakan istilah ini sesuai dengan RFC 2119 Kata-kata kunci untuk Tunjukkan Tingkat Kebutuhan - yaitu untuk menunjukkan item yang benar-benar opsional.
Saat teks spesifikasi Anda menggunakan kata kerja alih-alih kata sifat, gunakan "MEI" dan bukan "OPTIONAL".
Karena kecil dan mudah dibaca, teks RFC sepenuhnya dikutip di bawah ini:
Kelompok Kerja Jaringan S. Bradner Permintaan Komentar: 2119 Universitas Harvard BCP: 14 Maret 1997 Kategori: Praktik Terbaik Saat Ini Kata-kata kunci untuk digunakan dalam RFC untuk Menunjukkan Tingkat Kebutuhan Status Memo ini Dokumen ini menetapkan Internet Best Current Practices untuk Komunitas Internet, dan meminta diskusi dan saran untuk perbaikan. Distribusi memo ini tidak terbatas. Abstrak Dalam banyak dokumen standar melacak beberapa kata digunakan untuk menandakan persyaratan dalam spesifikasi. Kata-kata ini sering dikapitalisasi. Dokumen ini mendefinisikan kata-kata ini sebagaimana mestinya ditafsirkan dalam dokumen IETF. Penulis yang mengikuti pedoman ini harus memasukkan frasa ini di dekat bagian awal dokumen mereka: Kata kunci "HARUS", "HARUS TIDAK", "DIBUTUHKAN", "AKAN", "AKAN TIDAK "," HARUS "," TIDAK HARUS "," DIREKOMENDASIKAN "," MUNGKIN ", dan "OPTIONAL" dalam dokumen ini harus ditafsirkan sebagaimana dijelaskan dalam RFC 2119. Perhatikan bahwa kekuatan kata-kata ini dimodifikasi oleh persyaratan tingkat dokumen di mana mereka digunakan. 1. HARUS Kata ini, atau istilah "DIPERLUKAN" atau "AKAN", berarti bahwa definisi adalah persyaratan mutlak dari spesifikasi. 2. HARUS TIDAK. Frasa ini, atau frasa "TIDAK AKAN", berarti bahwa definisi adalah larangan mutlak dari spesifikasi. 3. HARUS Kata ini, atau kata sifat "DIANJURKAN", berarti di sana mungkin ada alasan yang valid dalam keadaan tertentu untuk mengabaikan a item tertentu, tetapi implikasi penuh harus dipahami dan hati-hati ditimbang sebelum memilih kursus yang berbeda. 4. TIDAK HARUS Frasa ini, atau frasa "TIDAK DIANJURKAN" artinya mungkin ada alasan yang valid dalam keadaan tertentu ketika perilaku tertentu dapat diterima atau bahkan berguna, tetapi penuh implikasinya harus dipahami dan kasusnya ditimbang dengan cermat sebelum menerapkan perilaku apa pun yang dijelaskan dengan label ini. 5. MEI Kata ini, atau kata sifat "OPTIONAL", berarti item benar-benar opsional. Satu vendor dapat memilih untuk memasukkan item karena a pasar tertentu memerlukannya atau karena vendor merasakannya itu meningkatkan produk sementara vendor lain dapat menghilangkan item yang sama. Suatu implementasi yang tidak termasuk opsi tertentu HARUS siap untuk beroperasi dengan implementasi lain yang tidak termasuk opsi, meskipun mungkin dengan fungsionalitas yang berkurang. Dalam sama dengan suatu implementasi yang tidak termasuk opsi tertentu HARUS siap untuk beroperasi dengan implementasi lain yang tidak termasuk opsi (kecuali, tentu saja, untuk fitur tersebut opsi menyediakan.) 6. Bimbingan dalam penggunaan Imperatif ini Imperatif dari jenis yang didefinisikan dalam memo ini harus digunakan dengan hati-hati dan hemat. Secara khusus, mereka HARUS hanya digunakan di tempat itu sebenarnya diperlukan untuk interoperasi atau untuk membatasi perilaku yang dimiliki berpotensi menyebabkan bahaya (mis., membatasi pengiriman ulang) Untuk Misalnya, mereka tidak boleh digunakan untuk mencoba memaksakan metode tertentu pada implementor di mana metode ini tidak diperlukan untuk interoperabilitas. 7. Pertimbangan Keamanan Istilah-istilah ini sering digunakan untuk menentukan perilaku dengan keamanan implikasi. Efek pada keamanan tidak menerapkan HARUS atau HARUS, atau melakukan sesuatu spesifikasi mengatakan HARUS TIDAK atau HARUS TIDAK dilakukan mungkin sangat halus. Penulis dokumen harus meluangkan waktu untuk menguraikan implikasi keamanan dari tidak mengikuti rekomendasi atau persyaratan karena sebagian besar pelaksana tidak akan memiliki memiliki manfaat dari pengalaman dan diskusi yang menghasilkan spesifikasi. 8. Ucapan Terima Kasih Definisi dari istilah-istilah ini adalah campuran dari definisi yang diambil dari sejumlah RFC. Selain itu, saran telah tergabung dari sejumlah orang termasuk Robert Ullmann, Thomas Narten, Neal McBurnett, dan Robert Elz.
Tidak ada salahnya jika dokumentasi Anda mengacu pada RFC sebagai sumber definisi:
Dokumen ini menggunakan definisi berdasarkan yang ditentukan dalam RFC 2119 .
Saya menghargai itu bukan jawaban untuk pertanyaan Anda, tetapi di dunia saya, itu masih merupakan persyaratan, bahkan jika karena alasan apa pun Anda tidak akan memenuhinya.
Saya suka pendekatan MoSCoW (Harus, Harus, Seharusnya, Tidak punya waktu ini) untuk mengkategorikan persyaratan dengan pengguna, bersama dengan faktor-faktor lain (di dunia yang diatur saya, persyaratan bisa kritis atau tidak kritis, dan banyak argumen menyala lebih dari persyaratan opsional tetapi kritis.)
Kata yang lebih baik untuk persyaratan opsional adalah " Rekomendasi "
Bagaimana mengidentifikasinya sebagai fitur opsional atau tugas opsional. Ini hanya akan dilakukan jika pada titik tertentu dalam proyek telah ditentukan bahwa ada waktu dan uang yang tersedia untuk menyelesaikan fitur-fitur ini.
Mereka juga bisa dipicu jika peristiwa eksternal terjadi. Jika pelanggan beralih ke Windows 8, tugas berikut harus diselesaikan ...
Deskripsi fitur harus menyertakan tenggat waktu untuk menentukan apakah akan dilakukan.
Persyaratan dikategorikan ke dalam 4 area dalam Rekayasa Perangkat Lunak:
Sekarang persyaratan bisa Opsional atau Wajib , tergantung pada 4 kategori di atas, saya telah diuraikan di atas. Persyaratan opsional juga dapat jatuh ke dalam cakupan sistem yang sedang dipertimbangkan atau di luar cakupannya juga. Persyaratan opsional adalah cara yang baik untuk menghindari Scope Creep dan mendefinisikan ruang lingkup Anda secara tepat.
Persyaratan Opsional akan selalu menjadi bagian dari Rekayasa Perangkat Lunak karena membantu kami mengidentifikasi ruang lingkup dan merupakan cara yang baik untuk menghindari Scope Creep. Anda tidak dapat mengatakan bahwa mereka bertentangan dengan praktik rekayasa SDLC. Namun, persyaratan harus diprioritaskan dan didefinisikan dengan baik.
Dalam templat Volere , istilah "Ruang tunggu" digunakan.
... Template ini dimaksudkan untuk digunakan sebagai dasar spesifikasi kebutuhan Anda. Templat ini menyediakan untuk masing-masing jenis persyaratan yang sesuai untuk sistem bisnis, ilmiah, dan perangkat lunak saat ini. Ini menyediakan daftar periksa, struktur, dan keterlacakan untuk kebutuhan Anda ... Template ini adalah alat yang independen, dan telah berhasil digunakan dengan Yonix, Requisite, DOORS, Calibre RM, IRqA, dan alat populer lainnya ...
Teknik Volere dijelaskan dalam buku Menguasai Proses Persyaratan oleh Suzanne Robertson dan James Robertson ...
Dalam bisnis saya (pesawat ruang angkasa), mereka disebut "tujuan", yang menunjukkan bahwa mereka didokumentasikan dan upaya akan dikeluarkan untuk mencapainya, tetapi sistem akan tetap dianggap berhasil jika tidak terpenuhi; "keinginan" (bukan kata yang sebenarnya, tetapi ada Anda), menunjukkan bahwa seseorang menginginkannya dan mereka berusaha untuk mencapai status tujuan tetapi belum diterima atau didokumentasikan; atau "persyaratan merayap" yang merupakan versi keinginan yang lebih merendahkan yang menunjukkan hal-hal yang mencoba mengambil sumber daya tetapi itu tidak sepadan dengan proyek yang berusaha mencapai "cukup baik" di mana mereka akan berkompromi atau mengancam mencapai persyaratan yang sebenarnya.
Jika persyaratan Anda diprioritaskan , Anda mungkin menganggapnya sebagai persyaratan prioritas rendah .
Saya cukup terkejut tidak ada yang menyebutkan bahwa itu disebut "tujuan". Setiap perusahaan tempat saya bekerja telah memanggil mereka demikian. Mereka dilambangkan dengan menggunakan kata-kata "akan" atau "harus" bukannya "harus". Terkadang mereka termasuk dalam Kawat Gigi ketika berbicara tentang angka. mis. Sistem harus beroperasi terus menerus tanpa perlu perhatian operator selama 100 {250} jam. Artinya persyaratan yang harus dipenuhi adalah 100 jam, tetapi tujuannya adalah 250 jam.
Sebagai catatan, sangat jarang ada orang yang benar-benar merancang untuk memenuhi persyaratan obyektif, kecuali ada semacam insentif yang terlibat.
Istilah "Pensiun" terkadang digunakan untuk persyaratan opsional. Namun, itu mungkin tidak sesuai untuk dokumen formal.
Saya terkejut bahwa semua tanggapan berkaitan dengan persyaratan pelacakan dalam pengembangan proyek. Meskipun menjadi pengembang, saya tidak pernah terlalu khawatir tentang terminologi ini dalam konteks itu. Ketika saya pertama kali membaca pertanyaan saya menganggapnya terkait dengan spesifikasi produk pengguna, bukan pengembangan produk. Misalnya, ensiklopedia mungkin mencantumkan printer berwarna sebagai persyaratan opsional. Diperlukan jika Anda ingin manfaat penuh dari aplikasi tetapi opsional jika Anda ingin melihat layar. Tetapi bagaimana jika Anda memiliki misalnya printer monokrom? Bagaimana memperjelas apakah aplikasi Anda bekerja dengan batasan yang tidak jelas sehingga beberapa foto mungkin tidak terlihat bagus? Atau tidak mau mencetak sama sekali? Sebagai contoh lain, bagaimana saya harus memeriksa tinjauan printer untuk memeriksa apakah tinta merupakan persyaratan atau persyaratan persyaratan opsional dalam printer multi-fungsi? Dengan kata lain, apakah saya masih dapat memindai? Beberapa petunjuk tentang terminologi dan apa yang harus dicari akan disambut baik sebagai pengembang / penjual produk dan sebagai konsumen.