• Compreender a origem dos requisitos
• Gerenciar o escopo do projeto
• Gerenciar mudanças nos requisitos
• Avaliar o impacto no projeto da mudança em um requisito
• Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar, talvez o requisito não seja atendido)
• Verificar se todos os requisitos do sistema são desempenhados pela implementação
• Verificar se o aplicativo faz apenas o que era esperado que ele fizesse.

Sugerimos como pré-requisito ler o conceito Rastreabilidade

Para facilitar o entendimento, dividimos os elementos existentes no projeto em três categorias.

• Elementos de modelagem e implementação. São os elementos que descrevem e implementam a solução. São descritos normalmente na ferramenta Enterprise Architec (EA).
• Documentos dinâmicos de gestão do projeto. Concretizam uma visão ou permitem gerenciar e monitorar o andamento do projeto. São normalmente descritos em editores de texto como o BrOffice.
• Documentos estáticos. Também definidos em editores de textos padrões, no entanto, são estáticos. Logo após criado é apresentados e arquivados, sem gerar mudanças ao longo do projeto. Alguns exemplos: atas, script de apresentação, proposta comercial, análise de viabilidade, relatório de revisões, termos de revisão e aceite.

Para os elementos estáticos não adotamos manter a rastreabilidade, já que, como o próprio nome diz, eles não sofrem alterações.

Os documentos dinâmicos de gestão do projeto, diante de alterações no escopo do projeto, sofrem alterações e por isto devem ser rastreados. A rastreabilidade destes elementos é conforme mostrada na figura abaixo. De acordo com a Planilha de Estimativa de Escopo, Prazo e Custo, o Gerente do projeto cria o Plano de Projeto definindo o Cronograma, Plano das Iterações, Lista de Riscos e Diário de Bordo. Ele também gerencia o escopo do projeto com a Planilha de Gerenciamento de Casos de Uso e Mudanças.

Os elementos de modelagem e implementação são as principais peças que serão conectadas, pois elas geram os principais elementos do software, o código e as tabelas. Manter a rastreabilidade destes elementos é essencial para manter o software funcionando adequadamente, caso contrário, uma mudança em um elemento poderia gerar um efeito colateral em outro elemento e ninguém perceber.

O diagrama abaixo apresenta a forma como a rastreabilidade será implantada em nossos projetos. Como podem ver, temos a rastreabilidade vertical dos documentos de gestão do projeto e dos elementos de modelagem e implementação.

Adotamos a ferramenta Enterprise Architect (EA) para modelarmos elementos de desenho do software. Um dos motivos desta escolha é que o EA é a possibilidade de construirmos um mecanismo de rastreabilidade eficiente entre os elementos de modelagem. É importante enfatizar que a rastreabilidade não é mantida somente na ferramenta Enterprise Architect, produtos de trabalho externos são também rastreados no projeto da seguinte forma:

Iniciando na fase de elaboração e se prolongando ao longo do projeto, a modelagem dos elementos no EA deve ser uma atividade cotidiana para a equipe técnica do projeto. Isto pois praticamente todos os dias são criados ou alterados elementos.

Identificando Relações entre Requistos e Elementos de Implementação

Em nosso processo identificaremos a rastreabilidade apenas entre os elementos de modelagem do projeto. Os demais elementos mantem a rastreabilidade implicitamente pela equipe do projeto conforme o diagrama apresentado e na execução das tarefas específicas para este fim (apresentadas no tópico seguinte).

Os primeiros elementos de modelagem criados são os Requisitos de Negócio. Retirados inicialmente do Documento de Visão, os requisitos de negócio devem ser adicionados no projeto do EA por uma organização lógica (requisitos funcionais e não-funcionais, por exemplo). Adicionados os requisitos, um diagrama de rastreabilidade horizontal deve ser criado, normalmente envolvendo todos os requisitos de negócio do projeto. Este diagrama (figura abaixo) identificará a relação entre cada requisito, identificando, por exemplo, se um requisito depende de outro, se um requisito é agregado a outro, etc.

Criado o diagrama de rastreabilidade horizontal, precisamos agora apenas mantê-lo mediante alguma alteração no projeto que identifique ou altere algum requisito ou sua relação.

O próximo passo, ainda na fase de elaboração, é a identificação dos Casos de Uso. Os Casos de Uso, em grande parte, realizam (são a representação da solução em funcionalidades do sistema) um ou mais requisitos. Por isto, eles são os elementos chave para indicar a rastreabilidade vertical. Crie então no EA um pacote para cada Caso de Uso, dentro deste pacote insira o Caso de Uso, o seu diagrama de rastreabilidade vertical e demais elementos relevantes (diagramas de sequência, atividades e outros ítens diretamente ligados ao Caso de Uso).

No diagrama de rastreabilidade vertical, inicialmente você indicará os requistos realizados e referenciados por este Caso de Uso.

Nos passos seguinte, novos elementos da modelagem serão criados, diagramas, classes, casos de testes, interfaces, mensagens, regras de negócio, etc. A cada novo elemento é necessário que você analise se este novo artefato possui alguma relação com os Casos de Uso do projeto. Necessariamente, no mínimo um Caso de Uso, este ítem deve se relacionar, caso contrário, sua existência não estaria realizando um requisito e ele não seria necessário no projeto. Sendo assim, indique a relação deste novo elemento com todos os Casos de Uso que ele se relaciona.

E pronto! Se todos os elementos foram inseridos no projeto com a atenção de relacioná-los com os demais elementos existentes a rastreabilidade do projeto está mantida.

Quem deve criar a rastreabilidade?

Por definição da rastreabilidade neste processo, vários produtos de trabalho possuem um vínculo virtual, por exemplo, entre Casos de Uso e a Planilha de Gerenciamento de Casos de Uso e Mudanças. No entanto, elementos de modelagem possuem um vínculo descrito no desenho do projeto. Portanto, em que momento e quem deve definir este vínculo? Para facilitar este entendimento criamos a planilha abaixo indicando onde cada papel criar o vinculo de rastreabilidade entre os elementos de modelagem:

Mas como utilizar a rastreabilidade?

Em nosso PDS o diferencial notável da rastreabilidade é no processo de solicitação de mudança. Como tarefa deste processo devemos analisar o impacto de cada mudança solicitada, quais produtos de trabalho ela altera, como altera e qual a estimativa de esforço para implementar esta alteração. Sem os diagramas de rastreabilidade, esta cálculo seria um "chutômetro" pois ninguém poderia indicar com certeza todos os itens a serem alterados, pois cada papel trabalha com ítens em um determinado nível e abrangência. Já com as matrizes de rastreabilidade horizontal e vertical é possível analisarmos todos os impactos de uma mudança no projeto.

Mas somente os dois diagramas são suficientes para rastrear todas as mudanças? Não! Uma alteração pode alterar uma classe utilizada por vários outros elementos fora do contexto do Caso de Uso analisando, então, como analisar quais são estes elementos? Para isto a ferramenta EA, diante dos diagramas criados, provê automaticamente uma matriz de rastreabilidade, indicando um sistema de rastreamento de elemento para elemento em qual tipo de relação. Desta forma podemos, por exemplo, analisar as relações desta classe com todos os outros produtos de trabalho e identificar o impacto correto da mudança.

O que mais posso usufruir da existência da rastreabilidade no projeto?

Inúmeras possibilidades podem, e devem, se beneficiar com a rastreabilidade. A rastreabilidade está diretamente ligada a qualidade do projeto! Através da rastreabilidade podemos filtrar elementos para uma determinada finalidade. As rastreabilidades podem ser configuradas para ajudar a responder o seguinte conjunto de questões, por exemplo:

• Podemos encontrar as necessidades dos usuários que serão atendidas na iteração #n
• Podemos levantar o status de todos os testes em todos os casos de uso na interação #n
• Podemos levantar todos os requisitos não-funcionais vinculados a testes que possuem status não testado
• Podemos levantar os resultados de todos os testes que falharam, em ordem de importância
• Podemos levantar a ordem de prioridade de um determinado conjunto de produtos de trabalho