Bagaimana persyaratan ditentukan dalam proyek perangkat lunak sumber terbuka?

Dalam pengembangan perangkat lunak internal perusahaan, biasanya persyaratan ditentukan melalui proses formal yang menghasilkan sejumlah dokumen persyaratan. Dalam pengembangan perangkat lunak open source, ini sering tampaknya tidak ada. Oleh karena itu, pertanyaan saya adalah: bagaimana persyaratan ditentukan dalam proyek perangkat lunak sumber terbuka?

Dengan "menentukan persyaratan" yang saya maksudkan adalah "mencari tahu fitur apa, dll. Yang harus dikembangkan sebagai bagian dari perangkat lunak tertentu".

Proyek open source kadang-kadang memiliki aliran umpan balik pengguna yang intens, dan kadang-kadang perusahaan hanya membayar untuk membuat fitur tertentu terencana dan diimplementasikan (dengan mempekerjakan pengembang mereka sendiri atau pengembang asli).

Jika proyek Anda memiliki 100 pengguna, Anda mungkin dapat mengembangkan apa pun yang paling menyenangkan untuk dikodekan.

Jika proyek Anda memiliki 100 ribu pengguna, kemungkinan besar Anda sudah memiliki daftar titik nyeri yang ingin diperbaiki sebagian besar pengguna di rilis berikutnya, dan daftar fitur N teratas yang diminta pengguna di pelacak masalah Anda dan terus bertanya di forum.

Dengan umpan balik ini, Anda dapat menulis dokumen persyaratan untuk tim inti Anda, membuat peta jalan untuk membantu kontributor independen memahami visi Anda, dan berharap bahwa beberapa dari 100k pengguna akan mengirimkan patch.

Saya telah mengikuti open source sejak saya pertama kali mendengar tentang linux pada sekitar tahun 1995, dan saya tidak ingat pernah mendengar kata 'persyaratan' yang digunakan dalam konteks itu.

Eric Raymond memiliki esai yang bagus, The Cathedral and the Bazaar , di mana ia berbicara tentang 'menggaruk gatal Anda sendiri'. Jika Anda mencoba untuk memecahkan masalah yang Anda hadapi secara pribadi, Anda tidak perlu merujuk ke dokumen persyaratan untuk mencari tahu apakah Anda sudah menyelesaikannya atau tidak.

Esai yang sama juga berbicara tentang mendengarkan pengguna Anda, yang merupakan saran bagus untuk semua orang, bukan hanya proyek open source. Proyek open source cenderung meritokratis, jadi 'dia yang menulis kode, membuat aturan', lebih atau kurang.

Dalam pengembangan perangkat lunak internal perusahaan, biasanya persyaratan ditentukan melalui proses formal yang menghasilkan sejumlah dokumen persyaratan.

Menurut pengalaman saya, ini jauh lebih umum ketika melakukan pengembangan berbasis kontrak, terutama ketika memiliki perusahaan eksternal melakukan pengembangan untuk perusahaan Anda, dan ada kebutuhan hukum untuk kontrak. Tetapi banyak perusahaan lain yang mengendalikan pengembangan inhouse mereka oleh orang-orang mereka sendiri dengan cara yang berbeda:

• komunikasi informal

• daftar persyaratan / bug / masalah / tiket yang diprioritaskan (dan itu jelas bukan penemuan dari komunitas "gesit")

Ini adalah cara yang sama seperti kebanyakan proyek open source bekerja - karena tidak perlu untuk kontrak formal, tidak ada yang mengganggu untuk mengerjakan dokumen persyaratan formal yang besar, terperinci, formal, daftar fitur yang hilang, tanpa rasa sakit, atau tiket yang dikumpulkan dalam suatu masalah. pelacak harus dipecahkan.

Jika masalahnya adalah masalah umum seperti, katakanlah, menulis kompiler atau browser, persyaratannya cukup banyak diberikan dalam bentuk standar bahasa, sistem operasi target dan perangkat keras target, dll.

Untuk hal-hal seperti GNU Emacs, yang merupakan banyak hal bagi banyak orang selain memenuhi tujuan awalnya sebagai editor teks, saya pikir persyaratannya masuk akal karena ruang lingkup yang luas untuk memperluasnya. Obrolan, email, newsgroup, pengeditan kode, kontrol versi muncul di pikiran. Ada seorang ilmuwan riset yang bekerja di Emacspeak. Saya pikir hal serupa dapat dikatakan tentang browser dan hal-hal lain yang memungkinkan ekstensi.

Jika perangkat lunak mengejar fungsi yang hanya tersedia dalam perangkat lunak non-sumber terbuka, persyaratannya cukup banyak diberikan lagi.

EDIT:

Ketika perangkat lunak open source melanjutkan ke pemeliharaan dan lebih sedikit persyaratan asli tetap tidak terpenuhi, sebagian besar persyaratan dapat berasal dari bug, perlu beradaptasi dengan platform baru seperti CPU multi-core dan perangkat keras lain yang menawarkan kinerja yang lebih baik ketika dieksploitasi, dan semacamnya.

Dalam proyek yang sepenuhnya berbasis penelitian seperti GNU Hurd, saya pikir persyaratannya berasal dari hasil penelitian dan makalah.

Untuk menyimpulkan,

• ketika memulai, persyaratan untuk perangkat lunak yang berupaya memecahkan masalah umum dapat berasal dari dokumen standar

• untuk perangkat lunak yang mengejar ketinggalan dengan perangkat lunak lain yang ada, persyaratannya mungkin untuk menghasilkan semua atau sebagian besar set fitur perangkat lunak yang ada dan beberapa fitur lain yang menurut pengembang / pengguna menarik untuk dimiliki.

• untuk proyek penelitian, makalah dan publikasi lainnya dapat menetapkan persyaratan

• ketika dalam pemeliharaan, bug, perlu beradaptasi dengan lingkungan yang lebih baru dapat menjadi sumber utama untuk persyaratan

Saya tidak tahu pasti, tetapi sekali saran adalah untuk menggunakan metodologi Agile-like, di mana persyaratan dinaikkan sebagai tiket (atau "kartu"), menggunakan sesuatu seperti JIRA, dengan masing-masing tiket mewakili fitur atau persyaratan. Setiap tiket kemudian dapat didekomposisi menjadi tiket lain yang mewakili unit kerja yang lebih kecil.

Sedangkan untuk benar-benar mencari tahu apa yang harus dilakukan aplikasi atau perangkat lunak, jawaban sederhana adalah "berbicara dengan pengembang lain." :) "Berbicara" dalam hal ini bisa berarti daftar distribusi e-mail, forum, atau bahkan IRC, apa pun yang memungkinkan orang di zona waktu berbeda dan lokasi geografis untuk mengobrol.