Come vengono determinati i requisiti nei progetti software open source?

Nello sviluppo del software aziendale interno è comune determinare i requisiti attraverso un processo formale che porta alla creazione di una serie di documenti sui requisiti. Nello sviluppo di software open source, questo sembra spesso essere assente. Quindi, la mia domanda è: come vengono determinati i requisiti nei progetti software open source?

Con "determinazione dei requisiti" intendo semplicemente "capire quali caratteristiche ecc. Dovrebbero essere sviluppate come parte di un software specifico".

I progetti open source a volte hanno flussi intensi di feedback degli utenti, e talvolta le aziende pagherebbero semplicemente per rendere pianificate e implementate determinate funzionalità (assumendo i propri sviluppatori o gli sviluppatori originali).

Se il tuo progetto ha 100 utenti, probabilmente puoi sviluppare tutto ciò che è più divertente da codificare.

Se il tuo progetto ha 100.000 utenti, molto probabilmente hai già un elenco di punti critici che la maggior parte degli utenti desidera risolvere nella prossima versione e un elenco delle principali funzionalità N che gli utenti richiedono nel tracker dei problemi e continuano a chiedere sui forum.

Con questo feedback, puoi scrivere i documenti dei requisiti per il tuo team principale, creare roadmap per aiutare i collaboratori indipendenti a comprendere la tua visione e sperare che alcuni dei 100k utenti invieranno patch.

Ho seguito l'open source da quando ho sentito parlare di Linux per la prima volta nel 1995, e non ricordo di aver mai sentito la parola "requisiti" usata in quel contesto.

Eric Raymond ha un buon saggio, The Cathedral and the Bazaar , in cui parla di "grattarsi il prurito". Se stai cercando di risolvere un problema che stai affrontando personalmente, non devi fare riferimento ai documenti sui requisiti per capire se l'hai risolto o meno.

Lo stesso saggio parla anche dell'ascolto dei tuoi utenti, che è un buon consiglio per tutti, non solo per i progetti open source. I progetti open source tendono ad essere meritocratici, quindi "chi scrive il codice, fa le regole", più o meno.

Nello sviluppo del software aziendale interno è comune determinare i requisiti attraverso un processo formale che porta alla creazione di una serie di documenti sui requisiti.

Secondo la mia esperienza, questo è molto più comune quando si fa uno sviluppo basato su contratto, specialmente quando si ha una società esterna che fa lo sviluppo per la propria azienda, e vi è la necessità legale di un contratto. Ma molte altre società controllano il proprio sviluppo interno dalla propria gente in un modo diverso:

• comunicazione informale

• elenchi di requisiti / bug / numeri / ticket prioritari (e che sicuramente non è un'invenzione della comunità "agile")

Questo è lo stesso modo in cui funzionano la maggior parte dei progetti open source - poiché non è necessario un contratto formale, nessuno si preoccupa di elaborare documenti di requisiti formali, dettagliati e formali, solo piccoli elenchi indolori di funzionalità mancanti o biglietti raccolti in un numero tracker da risolvere.

Se il problema è comune come, ad esempio, la scrittura di un compilatore o di un browser, i requisiti sono praticamente dati sotto forma di standard linguistici, sistemi operativi di destinazione e hardware di destinazione, ecc.

Per cose come GNU Emacs, che è molte cose per molti oltre a raggiungere in modo eccellente il suo obiettivo originale di essere un editor di testo, penso che i requisiti abbiano senso a causa dell'immenso scopo di estenderlo. Vengono in mente chat, e-mail, newsgroup, modifica del codice, controllo della versione. C'è uno scienziato che lavora su Emacspeak. Penso che si possano dire cose simili sui browser e altre cose che consentono le estensioni.

Se il software sta recuperando una funzione disponibile solo in software non open source, il requisito viene praticamente restituito.

MODIFICARE:

Quando il software open source passa alla manutenzione e meno requisiti originali rimangono insoddisfatti, la maggior parte dei requisiti può derivare da bug, è necessario adattarsi a nuove piattaforme come CPU multi-core e altro hardware che offrono prestazioni migliori quando sfruttate e così via.

In un progetto interamente basato sulla ricerca come GNU Hurd, penso che i requisiti provengano da risultati e documenti della ricerca.

Per riassumere,

• all'inizio, i requisiti per il software che tenta di risolvere problemi comuni possono provenire da documenti standard

• per software che sta raggiungendo altri software esistenti, è probabile che i requisiti siano quelli di produrre tutto o la maggior parte del set di funzionalità del software esistente e alcune altre funzionalità che gli sviluppatori / utenti trovano interessanti avere

• per progetti di ricerca, documenti e altre pubblicazioni potrebbero stabilire i requisiti

• durante la manutenzione, i bug, che devono adattarsi agli ambienti più recenti possono essere la fonte principale di requisiti

Non lo so per certo, ma una volta suggerimento è quello di utilizzare una metodologia simile ad Agile, in cui i requisiti vengono sollevati come ticket (o "carte"), usando qualcosa come JIRA, con ogni ticket che rappresenta una funzionalità o un requisito. Ogni biglietto potrebbe quindi essere scomposto in altri biglietti che rappresentano unità di lavoro più piccole.

Per quanto riguarda effettivamente capire cosa dovrebbe fare un'applicazione o un software, la semplice risposta è "parlare con gli altri sviluppatori". :) "Parlare" in questo caso potrebbe significare una lista di distribuzione e-mail, un forum o persino IRC, qualsiasi cosa che permetta alle persone di fusi orari e località geografiche diverse di chattare.