Como os requisitos são determinados em projetos de software de código aberto?

No desenvolvimento corporativo de software interno, é comum que os requisitos sejam determinados por meio de um processo formal, resultando na criação de vários documentos de requisitos. No desenvolvimento de software de código aberto, isso geralmente parece estar ausente. Portanto, minha pergunta é: como os requisitos são determinados em projetos de software de código aberto?

Por "determinação de requisitos", quero dizer simplesmente "descobrir quais recursos etc. devem ser desenvolvidos como parte de um software específico".

Os projetos de código aberto às vezes têm fluxos intensos de feedback dos usuários e, às vezes, as empresas simplesmente pagam para fazer com que certos recursos sejam planejados e implementados (contratando seus próprios desenvolvedores ou os desenvolvedores originais).

Se o seu projeto tiver 100 usuários, você provavelmente poderá desenvolver o que for mais divertido de codificar.

Se o seu projeto tiver 100 mil usuários, provavelmente você já possui uma lista de pontos problemáticos que a maioria dos usuários deseja corrigir na próxima versão e uma lista dos N principais recursos que os usuários solicitam no rastreador de problemas e continuam perguntando nos fóruns.

Com esse feedback, você pode escrever documentos de requisitos para sua equipe principal, criar roteiros para ajudar colaboradores independentes a entender sua visão e esperar que alguns dos 100 mil usuários enviem patches.

Eu tenho seguido o código aberto desde que ouvi falar sobre o Linux em 1995, e não me lembro de ter ouvido a palavra 'requisitos' usada nesse contexto.

Eric Raymond tem um bom ensaio, The Cathedral and the Bazaar , no qual ele fala sobre 'coçar a própria coceira'. Se você está tentando resolver um problema que está enfrentando pessoalmente, não precisa se referir aos documentos de requisitos para descobrir se o solucionou ou não.

Esse mesmo ensaio também fala sobre ouvir seus usuários, o que é um bom conselho para todos, não apenas para projetos de código aberto. Projetos de código aberto tendem a ser meritocráticos, então 'quem escreve o código faz as regras', mais ou menos.

No desenvolvimento corporativo de software interno, é comum que os requisitos sejam determinados por meio de um processo formal, resultando na criação de vários documentos de requisitos.

Para minha experiência, isso é muito mais comum quando se faz desenvolvimento baseado em contrato, especialmente quando uma empresa externa faz o desenvolvimento para sua empresa, e existe a necessidade legal de um contrato. Mas muitas outras empresas controlam seu desenvolvimento interno por seu próprio pessoal de uma maneira diferente:

• comunicação informal

• lista de requisitos / bugs / problemas / tickets priorizados (e isso definitivamente não é uma invenção da comunidade "ágil")

É da mesma maneira que a maioria dos projetos de código aberto funciona - já que não há necessidade de um contrato formal, ninguém se preocupa em elaborar documentos de requisitos grandes, detalhados e formais, apenas listas pequenas e sem problemas de recursos ausentes ou tickets coletados em uma edição rastreador a ser resolvido.

Se o problema for comum, como, por exemplo, escrever um compilador ou um navegador, os requisitos serão dados na forma de padrões de idioma, sistemas operacionais de destino e hardware de destino, etc.

Para coisas como o GNU Emacs, que é muitas coisas para muitos, além de cumprir excelentemente seu objetivo original de ser um editor de texto, acho que os requisitos faziam sentido devido ao imenso escopo de estendê-lo. Chats, e-mails, grupos de notícias, edição de código, controle de versão vêm à mente. Há um cientista pesquisador trabalhando no Emacspeak. Acho que coisas semelhantes podem ser ditas sobre navegadores e outras coisas que permitem extensões.

Se o software está recuperando uma função que está disponível apenas em software não de código aberto, o requisito é praticamente dado novamente.

EDITAR:

Quando o software de código aberto continua com a manutenção e menos requisitos originais permanecem não atendidos, a maioria dos requisitos pode vir de bugs, é necessário se adaptar a novas plataformas, como CPUs com vários núcleos e outro hardware que ofereça melhor desempenho quando explorado.

Em um projeto totalmente baseado em pesquisa como o GNU Hurd, eu acho que os requisitos vêm de resultados e documentos de pesquisa.

Resumindo,

• ao iniciar, os requisitos para o software que tenta resolver problemas comuns podem vir dos documentos de normas

• para o software que está alcançando outro software existente, é provável que os requisitos sejam produzir todo ou quase todo o conjunto de recursos do software existente e alguns outros recursos que os desenvolvedores / usuários acham interessante ter

• para projetos de pesquisa, artigos e outras publicações podem definir os requisitos

• quando em manutenção, bugs, a necessidade de se adaptar a ambientes mais novos pode ser a principal fonte de requisitos

Não tenho certeza, mas uma vez a sugestão é usar uma metodologia do tipo Agile, onde os requisitos são aumentados como tickets (ou "cards"), usando algo como o JIRA, com cada ticket representando um recurso ou requisito. Cada ticket pode ser decomposto em outros tickets, representando unidades menores de trabalho.

Quanto a realmente descobrir o que um aplicativo ou software deve fazer, a resposta simples é "conversar com os outros desenvolvedores". :) "Falar" nesse caso pode significar uma lista de distribuição de e-mail, fórum ou até IRC, qualquer coisa que permita que pessoas de fusos horários e locais geográficos diferentes conversem.