Rastreabilidade

Um conceito que existe no software aeronáutico que não conheço em nenhuma outra indústria é o de rastreabilidade (traceability) entre artefatos de software. Como já vimos, os artefatos de software são os arquivos desenvolvidos, assim como os requisitos.

Como tudo deve ser orientado a requisitos, a origem da rastreabilidade parte deles, ou melhor, de cada um deles. Cada requisito que é alocado para software (o requisito de sistema) precisa ser rastreado para os requisitos que o detalham, passando assim por todos os níveis de requisito de software até chegar no código fonte. Ou seja, cada requisito de sistemas rastreia para requisitos de HLR, que rastreiam para LLR, que finalmente rastreiam para código. Assim é possível saber como os requisitos foram se desdobrando, detalhando e quais linhas de código implementam cada requisito.

O mesmo precisa ser feito com os testes. Os casos de teste precisam ser rastreados para os requisitos que eles testam. Quando todos os requisitos estiverem cobertos por testes, é sinal de que os testes estão completos do ponto de vista funcional.

Esta teia de associações tem uma motivação: estabelecer a dependência dos artefatos e assim saber quais serão impactados no caso de uma mudança em um requisito. Através da rastreabilidade será possível identificar todo o caminho seguido até o código e o teste, e então fazer as mudanças necessárias.

Uma maneira para se registrar a rastreabilidade é em forma de tabelas (ou matrizes de rastreabilidade). Para facilitar o trabalho os requisitos costumam possuir identificadores (números sequenciais). As matrizes listam para cada requisito quais os seus requisitos dependentes, código ou testes associados. É mais fácil fazer tabelar os pares de artefatos ao invés de tentar apresentar todos eles em uma mesma tabela. Exemplo: rastrear HLR para LLR em uma tabela; rastrear LLR para código em outra.

Existem dois possíveis sentidos na rastreabilidade (pensando no diagrama em V): de cima para baixo e de baixo para cima. O primeiro vai no sentido do requisito até chegar no código e o segundo o contrário. Para se conseguir navegar na rastreabilidade bi-direcionalmente é necessário fazer o dobro de tabelas: uma indexada pelos requisitos, outra pelo código. O mesmo vale para rastreabilidade para teste: uma tabela indexada pelos requisitos e outra pelos testes. A rastreabilidade no sentido inverso é bastante útil nas atividades de revisão, onde se deseja por exemplo saber se um código implementa corretamente o seu requisito rastreado, ou se um teste atende corretamente o seu requisito associado.

<<exemplos>>