Pergunta

Durante vários projetos, eu precisava garantir que o modelo de caso de uso que desenvolvi durante a fase de análise esteja cobrindo os requisitos do projeto. Para isso, pude ter algum grau de rastreabilidade entre declarações de requisitos (identificadas exclusivamente) e casos de uso (também identificados exclusivamente). Em alguns casos, permitir a rastreabilidade implicava algum esforço adicional que eu considerava (e depois provou) ser um bom investimento.

Agora, o maior problema que enfrentei foi manter essa rastreabilidade mais tarde, quando as coisas começaram a mudar (como resultado de solicitações de alteração ou como resultado de alterações no caso de uso).

Alguma idéia das melhores práticas para manutenção de rastreabilidade?

(Pode ser aplicado a outros itens no projeto - por exemplo, casos de uso e casos de teste, ou requisitos e casos de teste de aceitação)

Editar posteriorAs ferramentas podem ajudar, mas não podem detectar lacunas ou erros na rastreabilidade. Navegação ... talvez, mas não garantia que a rastreabilidade esteja atualizada ou correta após a aplicação das alterações.

Foi útil?

Solução

Eu acho que a rastreabilidade é uma das coisas mais difíceis de gerenciar nos requisitos, segundo para garantir que os requisitos estejam corretos em primeiro lugar. Em minha experiência, A melhor ferramenta de rastreabilidade é um ser humano.

Eu não tenho panacéias; Apenas algumas dicas para o que me ajudaram no passado.

  • Mantenha documentos em uma área central, onde todos possam chegar até eles facilmente. Não me importo se é o SharePoint, um wiki ou uma unidade de rede (embora eu goste de algo que forneça controle de versão, se possível). Mantenha -o em um só lugar e comercialize diabos para fora, para que todos saibam ir lá para respostas, em vez de usar cópias antigas ou interromper os desenvolvedores.
  • Se você tiver um ponto de contato central para gerenciar os artefatos ou agrupamentos funcionais deles, isso ajuda muito. Alguém que os entende e os problemas saberão para onde ir, o que atualizar e se houver dependências que precisam ser transportadas.
  • O custodiante dos artefatos precisa estar comprometido com eles e mantê -los atualizados. Um ano depois de configurar alguns documentos de requisitos em um site, ainda os mantive atualizados. Eu sei que a maioria dos desenvolvedores temia ter que fazer isso, mas um ano depois disso, ainda estou me beneficiando de olhar para aqueles para ver como um requisito funcional mudou com o tempo.
  • Não é necessário, mas é útil identificar rapidamente as alterações ao longo do tempo: use o rastreamento da versão do processador do documento, se ele o tiver. Caso contrário, eu incluiria pelo menos um log de alterações para o documento ou simplesmente marcaria um novo texto com uma referência ao número da versão.
  • Tentei colocar referências de dependência em meus artefatos no passado, como referências a outros documentos ou artefatos, mas descobri que eles ficaram desatualizados ou eram difíceis de acompanhar e, portanto, muitas vezes não eram atualizados. A disciplina pode superar isso, mas a maioria de nós tem muito o que fazer, não é? Então eu acho que a construção de referências cruzadas entre documentos/artefatos é onde eu gostaria de uma ferramenta ou alguns ainda a serem lançados utilitários de gerenciamento de requisitos gratuitos para fazer o trabalho :)

Outras dicas

Usamos há três anos uma ferramenta racional para escrever requisitos. Nessas ferramentas, muitos recursos dizem respeito à rastreabilidade.

Descobrimos que a usabilidade dessas ferramentas não é perfeita. Embora eles tenham fornecido as funcionalidades básicas de que precisávamos, perdemos muito tempo contornando suas limitações.


Suponho que você não esteja perguntando sobre rastreabilidade até o código, então excluo isso da minha resposta.


Ao mencionar IDs exclusivos para seus declarações e casos de uso, você já pode usar uma ferramenta para gerenciá -los.

Em essência, um modelo relacional simples (possivelmente em um banco de dados) pode cobrir as relações entre suas peças identificadas exclusivamente.

Eu procuraria uma ferramenta simples que faça isso. Se apenas uma pessoa puder modificá -lo, poderá ser simplesmente uma planilha do Excel!


Observe que vincular dois tipos de documentos provavelmente não é suficiente.
Você mencionou 5 tipos: declarações, casos de uso, casos de teste, requisitos e casos de teste de aceitação.
Precisávamos constantemente de transitividade (no mundo relacional, para ingressar nas mesas), para ter uma visão, incluindo várias etapas.

Existem muitos tipos de rastreabilidades a serem mantidos: requisitos do sistema para os requisitos do subsistema, requisitos para projetar, requisito para verificação (mais importante), exigência de codificar, requisitos para problemas etc.

A palavra, o Excel e um bom sistema de rastreamento são um longo caminho. Mas eles podem ser dolorosos quando você é obrigado a mostrar rastreabilidade. Manter manualmente a rastreabilidade é propensa a erros e trabalho intensivo. O sistema IBM Doors é a melhor ferramenta que usei até agora. Mas eles são caros. Recentemente encontramos um sistema Rastreamento final Isso funciona muito bem.

Você deseja adicionar uma versão # à declaração de requisitos e para cada caso de uso-os mais atualizados que estão sendo comunicados a todos e armazenados em alguma área facilmente acessível (física e/ou computador/web). Você precisará adicionar um documento de alteração que inclua qual foi a declaração anterior de requisitos e/ou o caso de uso, quando foi alterado por quem e quem aprovou.

Portanto, ao analisar as especificações de requisitos e os casos de uso que você/todos têm a visão mais recente e, se houver uma pergunta para uma alteração, você terá a mudança para se referir (não sobrecarregar os requisitos ou usar especificações com informações históricas, Mas mantenha as informações históricas como referência de uma forma facilmente acessível e significativa)

Eu diria que a melhor maneira é usar um rastreador de bug. Cada requisito é rastreado como um bug, modificações de desenvolvimento estão associadas a ele e as alterações podem ser mantidas com notas de bugs.

Muitos Bugtrackers permitem que você associe vários bugs juntos (por exemplo, como duplicatas), para que isso possa ser usado para manter os requisitos discretos combinados e ainda separados para rastrear individualmente.

Se você armazenar todos os outros artefatos em um SCM (ou seja, documentos de design, etc.), poderá rastreá -los também associando -os ao requisito.

Existem ferramentas para ajudar com tudo isso, ut que eu encontrei essas ferramentas "ciclo de vida completo" são realmente inutilizáveis, pois tentam fazer muito em um aplicativo ou como aplicativos relacionados que "integram" juntos e são incrivelmente caros.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top