Rastreabilidade de requisitos, qual é o teu problema?

Já ouvi dizer que o problema que a rastreabilidade de requisitos tenta resolver é: Em uma situação de alteração ou manutenção, é necessário identificar os artefatos (leia-se classes e documentos) relacionados ao requisito que está sofrendo a alteração.

Será que não existe nada mais simples para fazer isso?

Me parece que as seguintes soluções são melhores:

  • Cobrir a aplicação com testes automatizados de unidade, integração e funcional. Dessa forma, o impacto de qualquer alteração já se reflete nos testes. Muito mais confiável do que olhar uma matriz e analisar o impacto.
  • debug da aplicação com um ou mais breakpoints

Mais alguma solução?

Anúncios

4 Responses to Rastreabilidade de requisitos, qual é o teu problema?

  1. Thiago disse:

    E se ainda não existir código? Se ainda estivermos no levantamentos dos requisitos?

  2. André disse:

    Neste caso não é necessário saber o impacto das alterações, pelo menos eu não me importaria em sabê-lo, assumindo que se não exite código, não exitem classes.

  3. Mickaella disse:

    “assumindo que se não exite código, não exitem classes.” Mas provavelmente deve existir documentação, e o impacto que as alterações provocam vai refletir em prazo e custo.

    • andrecardoso disse:

      Mickaella,

      Se só tens documentação no teu projeto, provavelmente estarás bem no início, na 1a iteração, no máximo 2a. Neste caso, não teria sentido a rastreabilidade pois o impacto das mudanças será mínimo. Não concordas?

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: