Come vengono determinati i requisiti nei progetti software open source?

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 ciò che è più divertente codificare.

Se il tuo progetto ha 100k utenti, molto probabilmente hai già un elenco di punti deboli che la maggior parte degli utenti vorrebbe correggere nella prossima release e un elenco delle principali funzionalità N richieste dagli utenti nel tuo tracker di problemi e continua a chiedere informazioni sui forum.

Con questo feedback, puoi scrivere i documenti dei requisiti per il tuo core team, creare roadmap per aiutare i collaboratori indipendenti a capire la tua visione e sperare che alcuni degli utenti 100k inviino le 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, La Cattedrale e il Bazar , in cui parla di "grattarsi il proprio prurito". Se stai cercando di risolvere un problema che stai affrontando personalmente, non devi fare riferimento ai documenti dei requisiti per capire se 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.

In corporate in-house software development it is common for requirements to be determined through a formal process resulting in the creation of a number of requirements documents.

Secondo la mia esperienza, questo è molto più comune quando si fa lo sviluppo basato sul contratto, soprattutto quando un'azienda esterna sta facendo lo sviluppo per la propria azienda, e c'è il legale bisogno di un contratto. Ma molte altre aziende controllano il loro sviluppo interno dalla propria gente in un modo diverso:

• comunicazione informale

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

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

Se il problema è comune, ad esempio scrivendo un compilatore o un browser, i requisiti vengono forniti in forma di standard linguistici, sistemi operativi di destinazione e hardware di destinazione, ecc.

Per cose come GNU Emacs, che è molte cose per molti, oltre ad ottemperare in modo eccellente al suo obiettivo originale di essere un editor di testo, penso che le esigenze fossero sensate a causa dell'immenso scopo di estenderlo. Chat, email, newsgroup, editing del codice, controllo della versione vengono in mente. C'è uno scienziato che lavora su Emacspeak. Penso che cose simili possano essere dette dai browser e da altre cose che consentono estensioni.

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

EDIT:

Quando il software open source passa alla manutenzione e restano insoddisfatti meno requisiti originali, la maggior parte dei requisiti può derivare da bug, necessità di adattarsi a nuove piattaforme come CPU multi core e altri hardware che offrono prestazioni migliori quando sfruttate, e ad esempio.

In un progetto completamente basato sulla ricerca come GNU Hurd, penserei che i requisiti derivino da risultati e documenti di 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 la produzione di tutte o la maggior parte delle funzionalità del software esistente e alcune altre funzionalità che gli sviluppatori / utenti ritengono interessante avere

• per progetti di ricerca, documenti e altre pubblicazioni potrebbe impostare i requisiti

• in fase di manutenzione, i bug, la necessità di adattarsi agli ambienti più recenti possono essere la fonte principale per i requisiti

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

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