ti-enxame.com

Qual é a maneira adequada de criar documentos de requisitos?

No momento, meu supervisor está criando documentação/especificações de requisitos para mim usando um software de rastreamento de bugs. Parece uma péssima ideia para mim, todos os requisitos estão nesses pequenos bilhetes e eu tenho que clicar neste formulário da web idiota para obter os requisitos. O que é uma solução de software sensata para requisitos/especificações de software?

Para ser claro, estou construindo este grande componente de software com alguns recursos e esses recursos estão sendo apresentados neste software de rastreamento de bugs.

24
patrick

Estou bastante surpreso que ninguém até agora recomendou o uso de um wiki para rastrear os requisitos.

Descobri que é um sistema quase perfeito, porque:

  • Ele permite que as pessoas colaborem nos requisitos e torna esse aspecto altamente visível;
  • Ele permite que você mantenha facilmente os requisitos atualizados à medida que o projeto avança;
  • Você pode entrar e ver a história a qualquer momento, no caso de uma disputa "não foi isso que combinamos";
  • A maioria dos wikis modernos tem recursos de formatação decentes, por isso parece quase tão bom quanto um documento do Word;
  • Você pode criar um hiperlink diretamente de seus requisitos para a documentação real;
  • Você nunca precisa se preocupar com pessoas trabalhando em cópias diferentes/obsoletas;
  • Os requisitos podem começar a ser tratados como um processo iterativo, assim como design/implementação;
  • Se os requisitos começarem a ficar muito grandes/complicados, é fácil dividi-los em páginas/tópicos.
  • A maioria dos wikis aceita HTML, então se você realmente precisa de formatação avançada, provavelmente pode usar uma ferramenta como Windows Live Writer .

Se eu pudesse escolher, quase sempre escolho o método wiki hoje em dia, é realmente indolor em comparação aos antigos documentos do Word ou tentando amontoar tudo em um rastreador de bug.

18
Aaronaught

Eu sempre uso IEEE Std 830-1998 (Prática Recomendada IEEE para Especifcações de Requisitos de Software) como o modelo para meu documento SRS. Consulte http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

O próprio documento SRS final é geralmente um único documento do OpenOffice.org, mas geralmente há muitas partes constituintes nele, incluindo planilhas e diagramas.

Normalmente coloco todos esses documentos juntos em um repositório que coloco em um sistema de controle de revisão , como SVN ou CVS. Todos os outros analistas de negócios, designers, desenvolvedores, testadores, gerentes de projeto e clientes têm acesso a este repositório, para que possam lê-lo e fazer edições.

Lembre-se de que a SRS é um documento vivo e em evolução. Ele continuará a mudar e crescer por algum tempo. Não só é importante para todos os interessados ​​ter acesso ao SRS, mas também é importante ter um histórico completo das alterações e a capacidade de reverter essas alterações, se necessário. Portanto, um sistema de controle de revisão funciona muito bem para esse propósito. Boa sorte!

6
A. N. Other

Usar o rastreador de bug para gerenciamento de requisitos tem uma tendência a esconder a falta de colaboração e comunicação dentro da empresa.

Sem julgar qualquer método específico:

  • se for usar o waterfall, você precisa de documentos bem estruturados, precisos e de várias páginas (não um parágrafo que muitas pessoas normalmente digitam como uma descrição de bug). Esses documentos também são impossíveis de escrever e manter em um nível decente de qualidade se o marketing/vendedores (que originam os requisitos) não trabalharem bem em conjunto com a equipe de engenharia.
  • se você for usar um dos métodos ágeis, uma unidade de requisitos é uma história de usuário, representada por um cartão de história. O cartão em si não é um requisito, apenas um ponto de partida da conversa.

Uma (breve) experiência de um de meus antigos empregadores com o uso de um rastreador de bugs para requisitos foi que ele deu a muitas pessoas uma maneira muito fácil de parar de se comunicar completamente. As pessoas simplesmente escreveriam um desejo, jogariam no rastreador de bugs e assumiriam que eventualmente se tornaria realidade.

Claro que eles fizeram isso sem levar em conta:

  • suas próprias qualificações
  • sua participação no projeto
  • conflitos com outros requisitos
  • lacunas nos requisitos
  • custos
  • quaisquer considerações técnicas
  • etc.
5
azheglov

Geralmente usamos o Word, mas na realidade como você os cria no software é menos importante do que como você coleta os dados para criá-los e se a pessoa que coleta as informações sabe o suficiente para saber quando um requisito é excessivamente complicado e será muito mais caro do que um requisito mais simples, mas não adiciona valor real para ninguém (como quando eles querem que os números de ID sejam sempre atribuídos em ordem e nenhum seja ignorado) ou quando entrará em conflito com um requisito existente ou outro recurso planejado. Freqüentemente, nunca se fala com os usuários reais e há muitas surpresas quando seus gerentes não sabem de algo que absolutamente precisa ser feito e não está na nova versão do software.

Também podemos usar vários arquivos PDF, Excel ou Visio. Todos eles para o projeto são coletados e editados fora do SharePoint, para que possamos ver as versões anteriores, se necessário.

2
HLGEM

Acredito que documentos "Word" são a maneira errada de abordar os requisitos, pelas seguintes razões:

  1. Não há como "comparar" dois documentos para ver o que mudou.
  2. A interface do usuário desencoraja o uso de um estilo consistente. Sim, é possível usar estilos, mas a maioria das pessoas não se incomoda por causa da dificuldade.
  3. O formato do documento está essencialmente oculto. Claro, há uma especificação para arquivos OLE, que eu acho que são os documentos do "Word", mas a Microsoft enterrou tudo que é útil sob toneladas de tagarelice, então ninguém sabe ao certo. Mais cedo ou mais tarde, seu brilhante, O novo "Word" não abre o documento.
  4. Não funciona bem com outros formatos. Ou seja, a menos que você use Windows e IE, não terá sorte se alguém organizar os documentos de um projeto em arquivos HTML com links para arquivos no formato "Word". Clique no link errado e você terá que esperar por um longo período de download e início do Word, interrompendo o fluxo de pensamento. Hiperlinks de documentos do "Word" para outras pessoas podem ou não funcionar.
  5. "Word" é basicamente para escrever documentos destinados a aparecer no papel. Um objetivo admirável, mas que o torna menos do que útil para visualização on-line.

Não tenho uma sugestão alternativa com a qual tenha experiência, mas pensei no Texto Reestruturado ou Markdown do Python como alternativas.

2
Bruce Ediger

Eu escrevi um banco de dados de requisitos 6 ou 7 anos atrás para lidar com isso. Cada registro de requisito tem uma breve descrição, um memorando de "definição" e um memorando de "notas" (ambos em rich text, com capacidade de incorporar capturas de tela, etc.). Existem outros campos também, para projeto, entrega, número de sequência (para que possam ser ordenados logicamente), caso de uso/recurso ao qual está relacionado, estimativa de tempo, um campo para a pessoa que o manipula, se alguém o tiver selecionado para implementação, etc.

Há também um "Status" - "Entrado", enquanto estamos projetando os recursos; "Aprovado", definido quando um grupo de requisitos é revisado e determinado como pronto para implementação; "Implementado", definido pelo programador assim que ele achar que o requisito foi atendido e "Validado" quando o técnico de controle de qualidade concordar com o programador. (Se o técnico de QA discordar, ele pode defini-lo de volta para "Aprovado" para que o programador o receba de volta.) Os requisitos também podem ser "Adiados", "Rejeitados" ou "Questionados" (o que significa que o Conselho de Controle de Mudanças precisa examiná-los .)

O truque para fazer isso bem é uma granularidade razoável. Às vezes, pode fazer sentido ter requisitos de uma frase (por exemplo, "o problema descrito no problema 12345 foi corrigido"), mas, em geral, os requisitos devem descrever todos os aspectos importantes de um recurso inteiro (ou um grande pedaço de um). Por exemplo, um típico recurso de "novo relatório" terá um requisito para um formato de relatório (a aparência da saída) e um requisito para a caixa de diálogo de opções (explicando os campos, validação, etc.). Pode até haver um terceiro se há um gerador complexo processando os dados, ao invés de apenas uma consulta fácil ou algo assim. Além disso, criaremos um requisito de "Ajuda" para o tópico de ajuda correspondente.

Existem enormes vantagens em manter essas coisas em registros de banco de dados, em vez de um grande documento. Vários programadores podem trabalhar nos requisitos ao mesmo tempo. Os registros individuais são bloqueados para que apenas uma pessoa possa editar por vez, mas eles podem ser abertos e lidos enquanto outra pessoa está editando. A maior vantagem, porém, é que ele fornece documentação de pesquisa fácil de quais eram os requisitos e notas sobre como eles foram implementados. Temos mais de 25.000 requisitos lá agora, e podemos facilmente encontrar todos os requisitos com palavras específicas em todos os campos, ou a definição, ou notas, ou qualquer outra coisa, em menos de 10 segundos. (Tente fazer isso com mais de 6 anos de documentos do Word.)

Eu posso ver por que as pessoas podem dizer que é uma má ideia fazer requisitos em um "bug tracker", mas meu palpite é que isso é porque as ferramentas são uma porcaria, não porque manter os requisitos em um banco de dados pesquisável é uma má ideia.

1
SESummers

Eu usei uma vez http://www.pivotaltracker.com/ mas na minha empresa atual estamos usando .doc como fonte de especificação principal e Lighthouse como lista de desejos de recursos combinados e rastreamento de problemas. Para mim, é difícil fazer outras pessoas da equipe começarem a usar qualquer outra ferramenta quando estão tão acostumados com o Word.

1
Julia K Szopa

Eu mantenho um product backlog (um por projeto ou produto) que contém ser Stories . Eles podem ser armazenados em um software de rastreamento de bugs como o que você usa. Eu pessoalmente uso Excel para o backlog e Trac para o sprint backlog ( você provavelmente usa uma ferramenta como essa).

Quando necessário apenas, crio um documento do Word que descreve a história do usuário com mais detalhes e o anexo à história do usuário. Mas tento evitar isso dividindo a história do usuário em outras menores.

Pequenas histórias de usuários são mais fáceis de gerenciar (incluindo estimativas)

Gosto do documento Word porque me permite colocar links, formatar textos, colocar tabelas, capturas de tela e muito mais, e todos podem ler.

Claro, cada história de usuário é explicada em detalhes na sessão de estimativa e planejamento de sprint, e estou sempre disponível para mais perguntas quando o desenvolvedor decidir trabalhar nisso. Feedbacks frequentes usando revisão de sprint evitam que os desenvolvedores façam algo diferente do solicitado pelo proprietário do produto.

1
user2567

Pessoalmente, já usei documentos do Word, mas resolvi encontrar uma ferramenta no futuro para gerenciar isso para mim ... especialmente com a capacidade de definir bugs para requisitos, porque muitas vezes, o bug é nos requisitos, não o desvio entre especificações e implementação.

Nunca me ocorreu usar uma ferramenta de rastreamento de bugs, mas faz todo o sentido.

Por curiosidade, o que é que você não gosta?

EDIT: uma ressalva; diga ao seu gerente para reformular o software de rastreamento de bugs. Caso contrário, tudo nele é considerado um bug. Tive esse problema político no meu último cliente, onde coloquei tarefas no bug tracker. Não é bom.

1
John MacIntyre

Se você pode seguir a metodologia Agile, os links a seguir podem guiá-lo na escolha de uma boa ferramenta de gerenciamento de projetos Agile:

E, falando sério, experimente a metodologia Agile - ela prega uma abordagem simples, elegante, objetiva, não jazzística e sensata comum em tudo o que você faz, de forma que cada membro da equipe entenda e aprecie o papel e o esforço de todos os outros membros.

Boa sorte!

0
karthiks