Kata yang lebih baik untuk Persyaratan Opsional? [Tutup]


12

Apa kata yang lebih baik untuk persyaratan opsional dalam rekayasa perangkat lunak? Ungkapan itu kontradiktif. Saya telah menggunakan "Persyaratan Non-Inti" dalam proyek sebelumnya.


9
Saya kira maksudnya sesuatu tidak dapat diminta (seperti dalam 'persyaratan') dan opsional (seperti dalam 'tidak diperlukan')
scrwtp

2
Ini benar-benar milik Inggris. Dan saya hanya memanggil mereka "opsi."
Blrfl

13
@ Blrfl Itu bukan bahasa Inggris. Dalam bahasa Inggris, frasa "persyaratan opsional" saling bertentangan. Namun, ini memiliki makna yang diterima secara luas dalam pengembangan perangkat lunak, dan ada cara alternatif untuk menyusun konsep ini dalam konteks proyek perangkat lunak. Tidak masuk akal untuk memilikinya di mana pun kecuali di sini.
Thomas Owens

3
@ThomasOwens: Saya tidak setuju. Setiap bidang di mana pekerjaan memiliki persyaratan dapat mengalami masalah ini, yang akan membuat ini menjadi pertanyaan manajemen proyek. Ini juga merupakan oxymoron, yang membuatnya menjadi makanan yang baik untuk bahasa Inggris, dan topik pertama dalam FAQ pertama di sana mengatakan pilihan kata pada topik. Tapi sesuaikan dirimu.
Blrfl

5
"Hal-hal yang tidak akan dibangun" adalah apa artinya di banyak proyek.

Jawaban:


13

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.


1
Istilah terkait adalah 'perubahan kasus', yang merupakan persyaratan yang diharapkan di beberapa titik di masa depan, tetapi tidak dalam cakupan saat ini. Dengan menangkap kasing perubahan, Anda dapat mencoba dan menghindari melakukan sesuatu dalam desain saat ini yang membuat kasing berubah. Ketika melakukan ini, Anda perlu mengawasi YAGNI sekalipun.
Kris C

IMHO, 'persyaratan opsional' menyiratkan opsional dalam present-tense dan persyaratan di masa depan yang juga bisa membaca persyaratan potensial opsional. Either way, saya setuju bahwa di luar ruang lingkup lebih tepat dalam kasus bisnis di mana harapan pelanggan perlu dikelola.
Evan Plaice

25

Kami menyebut mereka sebagai fitur "senang memiliki" yang bertentangan dengan persyaratan.


2
Dari perspektif persyaratan teknik, "fitur yang bagus untuk memiliki" masih perlu ditangkap sebagai persyaratan (dalam spesifikasi, sebagai cerita pengguna, sebagai tes penerimaan - namun proses Anda menentukan bahwa persyaratan ditangkap) dan dilacak sepanjang kehidupan proyek.
Thomas Owens

11

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 bahkan tidak tahu ini adalah RFC. Saya tidak terkejut bahwa ada yang seperti ini, sebagai standar IEEE, standar ISO, RFC, atau dokumen serupa lainnya yang diterbitkan.
Thomas Owens

Dokumen ini tampaknya agak terlalu spesifik untuk diterapkan secara luas sebagai pedoman untuk persyaratan perangkat lunak. Itu tidak berjudul "Kata-kata Kunci untuk Persyaratan," itu berjudul "Kata-kata Kunci untuk Persyaratan di RFC," dan dalam Petunjuk 6 itu sengaja membatasi ruang lingkupnya sendiri.
Robert Harvey

1
@RobertHarvey, maksud saya adalah untuk menjawab ide pertanyaan bahwa seseorang harus mencari kata yang lebih baik untuk menggantikan istilah profesional yang sudah mapan dengan semantik yang terdokumentasi dengan baik hanya karena mereka percaya itu bukan bahasa Inggris yang sempurna. Karena itu terlalu spesifik atau tidak, itu akan menjadi pertanyaan yang sangat berbeda bukan begitu? Saya dapat membayangkan banyak kasus di mana saya lebih suka kategorisasi gaya MoSCoW .
nyamuk

@gnat, Dia tidak membutuhkan kata kerja. Posting ini belum menjawab Apa kata yang lebih baik untuk "persyaratan opsional"?
Pacerier

7

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.)



2

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.


1

Persyaratan dikategorikan ke dalam 4 area dalam Rekayasa Perangkat Lunak:

  1. Persyaratan Bisnis : Berfokus pada sasaran dan sasaran bisnis keseluruhan sistem
  2. Persyaratan Pengguna : Berfokus pada tujuan pengguna dan apa yang harus dilakukan pengguna untuk menggunakan sistem untuk mencapai tujuan bisnis
  3. Persyaratan Fungsional : Fungsi dan tugas apa yang harus dilakukan sistem untuk mencapai tujuan bisnis
  4. Persyaratan Non-fungsional : Persyaratan apa yang ada selain yang fungsional. Ini termasuk lingkungan, kendala, antarmuka, masalah pemeliharaan, dll.

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.


1
Pertanyaannya menanyakan istilah berbeda untuk "persyaratan opsional" bukan untuk kategorisasi persyaratan.
yannis

1
Jika dia tahu kategorisasi, dia tidak akan pernah mengatakan bahwa Persyaratan Opsional bertentangan dengan Rekayasa Perangkat Lunak. :)
Maxood

1
deskripsi yang baik, tapi saya masih sedikit kesal pada frasa - entah sesuatu diperlukan atau tidak. Saya pikir kami telah membuat "persyaratan" menjadi entitas terpisah yang berarti "kebutuhan klien formal" ...
Aram Kocharyan

@Maxood Hmmm? Istilah itu kontradiktif, bukan konsepnya, tetapi pertanyaannya yang membahas istilah itu. Apakah Anda memiliki referensi bahwa istilah tersebut merupakan bagian dari model persyaratan formal (atau diterima secara luas)? Saya tahu ini biasa, tetapi melempar barang seperti "Persyaratan Opsional akan selalu menjadi bagian dari Rekayasa Perangkat Lunak" tanpa satu referensi pun sebenarnya bukan secangkir teh.
yannis

@ Yannis Rizos Ketika saya mengatakan "Persyaratan Opsional akan selalu menjadi bagian dari Rekayasa Perangkat Lunak", maksud saya dalam konteks konseptual. Karena teknik adalah tentang mencari solusi yang efektif dalam anggaran sambil menyeimbangkan persyaratan yang saling bertentangan. Penanya tidak pernah menyebut Persyaratan Opsional sebagai istilah di sini dalam pertanyaan dan saya juga tidak.
Maxood

1

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 ...


0

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.


0

Jika persyaratan Anda diprioritaskan , Anda mungkin menganggapnya sebagai persyaratan prioritas rendah .


Saya pikir "prioritas nol" mungkin lebih dekat ke "opsional".
Pacerier

0

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.


0

Istilah "Pensiun" terkadang digunakan untuk persyaratan opsional. Namun, itu mungkin tidak sesuai untuk dokumen formal.


0

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.


Uhm, jadi Apa kata yang lebih baik untuk "persyaratan opsional"?
Pacerier

0

Saya akan menyebutnya "fitur opsional", bukan persyaratan opsional. Persyaratan terdengar seperti sesuatu yang harus Anda miliki , sementara fitur terdengar seperti tambahan pada produk asli.

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.