Métodos de Rastreabilidade de Requisitos

Prévia do material em texto

Requisitos de Métodos de Rastreabilidade entre os Requisitos 
e o Código de Software 
Pedro L. R. Leal Jr1 
1Departamento da Ciência da Computação – Universidade Federal de Minas Gerais (UFMG) 
- Av. Antônio Carlos, 6627 - Pampulha - Belo Horizonte - MG 
Pedro.leal.junior@gmail.com 
Abstract. The practices of requirements traceability, which exist to ensure 
software compliance with their requirements, aren’t yet systematically used in 
most companies. This happens because the so far existing methods have failed 
to meet all the needs of the stakeholders [Neumüller et al., 2006] [Antoniol et 
al., 2005]. Based on that, we present here a list of requirements for methods of 
traceability between requirements and code of software, from the 
stakeholders’ point of view. We expect to contribute to the development of 
more effective methods: not being complex to the users; covering the entire 
scope of the stakeholders needs; focused on the use, not on the technology. 
Resumo. As práticas de rastreabilidade de requisitos, que existem para 
garantir a conformidade do software com os seus requisitos, não conseguem 
ter um uso sistematizado na maioria das empresas. Isto ocorre porque os 
métodos existentes até então falharam em satisfazer as partes interessadas em 
todas as suas necessidades [Neumüller et al., 2006] [Antoniol et al., 2005]. 
Com base nisso, apresentamos neste artigo um catálogo de requisitos para 
métodos de rastreabilidade entre requisitos e código, do ponto de vista das 
partes interessadas. Esperamos assim contribuir para o desenvolvimento de 
métodos mais eficazes: que não pareçam complexos para seus usuários; 
cubram todo o escopo das necessidades das partes interessadas; que sejam 
focadas no uso, não na tecnologia. 
1. Introdução 
1.1 Contextualização 
A garantia da conformidade do software com os seus requisitos é uma exigência básica da 
indústria de desenvolvimento de software, mas nem sempre é alcançada. Com o objetivo de 
resolver esse problema, surgiram as práticas de Rastreabilidade de Requisitos, que, apesar de 
já serem utilizadas há alguns anos, códigos fonte freqüentemente evoluem sem a atualização 
dos requisitos [Ramesh et al. 1997]. Isso ocorre porque manter a consistência e a 
rastreabilidade entre abstrações de alto-nível, funcionalidades e componentes de software é 
custoso e consome tempo [Antoniol et al. 2005]. Tentando minimizar esse problema, 
pesquisadores e a indústria de software desenvolveram diferentes métodos e ferramentas para 
aperfeiçoar a gerência de requisitos. Mas infelizmente falharam em alcançar uma adoção 
 
generalizada [Neumüller et al., 2006]. Conseqüentemente, muitas empresas ainda registram as 
ligações de rastreabilidade (trace links) manualmente, apesar das abordagens automáticas e 
semi-automáticas já estarem disponíveis. Este artigo não discute de forma abrangente o 
problema de rastreabilidade de requisitos, tal discussão pode ser encontrada, por exemplo, no 
trabalho de Gotel et al. (1994), concentramos nossa atenção nas ligações de rastreabilidade 
entre requisitos e código de software, cuja importância fica evidente no artigo de Antoniol et 
al. (2002). 
 Atualmente já existem diversos métodos especializados em rastreabilidade com o 
código de software, que podem ser agregados em categorias bases, como fizeram Cleland-
Huang et al. (2005) e Gotel (1994). Podemos, por exemplo, citar métodos baseado em 
roteiros (scenario), métodos baseados em modelos, métodos baseados em recuperação de 
informação (information retrieval), métodos baseados em semântica. 
 Os maiores inibidores para o uso desses métodos e ferramentas são, segundo 
Neumüller et al. (2006), a complexidade da rastreabilidade e o manuseio de um grande 
volume de informação, que podemos traduzir como falta de aderência com as necessidades 
das partes interessadas. Se um método parece complexo para um usuário, é porque o seu 
desenvolvedor não observou requisitos de usabilidade para o método. Se há problemas em 
manusear um grande volume de informação é porque não foi observado requisitos de 
escalabilidade para o método. 
 Deixar os métodos mais aderentes às necessidades das partes interessadas, tem de 
ser o foco dos pesquisadores em rastreabilidade de requisitos. Pohl (1996) deixa claro que 
“os três principais problemas do uso das ligações de rastreabilidade são: Primeiro, o uso das 
informações de rastreabilidade dependem da parte interessada e das atividades do processo 
de desenvolvimento de software, isto é, ligações não são usadas como são gravadas e, 
consequentemente, recuperações seletivas, de acordo com necessidades atuais tem de ser 
suportadas. Segundo, devido ao grande número de informações produzidas durante o 
processo, apenas ligações orientadas ao conteúdo são base para o uso apropriado, isto é, o 
uso da informação gravada é quase impossível se as ligações de rastreabilidade não estão 
encapsuladas em seus contextos. Terceiro, as pessoas envolvidas na captura das ligações de 
rastreabilidade são frequentemente diferentes dos usuários da informação”. 
1.2 Objetivo 
Este artigo tem como objetivo apresentar um catálogo de requisitos para os métodos de 
rastreabilidade entre requisitos e código de software, e assim contribuir para desenvolvimento 
de métodos com melhor usabilidade e ajudar os profissionais na escolha de uma boa 
ferramenta. O catálogo aqui apresentado pode alimentar um critério objetivo de escolha de 
ferramentas, pelo menos no que diz respeito às características da rastreabilidade entre 
requisitos e código. 
 Não catalogamos requisitos para outros tipos de ligações de rastreabilidade, por 
exemplo, ligações de rastreabilidade horizontais (código com código, requisito com requisito), 
ligações verticais com outros artefatos (requisito com modelos, requisitos com casos de teste). 
 Também não tratamos as ligações de rastreabilidade com os requisitos pré-
especificação (pre-requirements specification), assim como Gotel et al. (1994) o definiu. 
 
1.3 Partes interessadas 
 Este catálogo de requisitos tem interesse para todos que, no ciclo de vida do projeto 
de software, precisam usar a rastreabilidade entre requisitos e código. Utilizamos o Processo 
Unificado [Jacobson, 1999] como fonte dos papéis de trabalhadores e das atividades técnicas 
que necessitam da rastreabilidade. Além dessas, utilizamos o Rational Unified Process para a 
descrição dos papeis e das atividades que o Processo Unificado não cobre. Do artigo de 
Antoniol et al. (2002) obtivemos algumas descrições já realizadas de atividades que utilizam a 
rastreabilidade entre requisitos e código para diversos trabalhadores do desenvolvimento de 
software. 
 Começando com os programadores, percebe-se que muitas vezes precisam entender 
códigos que não foram escritos por eles. Antoniol et al. (2002) mostram-nos que 
programadores usam diferentes tipos de conhecimento para a compreensão do programa, 
variando do conhecimento específico do domínio até o conhecimento geral de programação. 
Ligações de rastreabilidade entre áreas específicas do código e seções relacionadas em 
documentos de especificação de requisitos ajudam na compreensão da motivação e 
fundamentação daquele trecho de código analisado. 
 Analistas de Sistema, que têm a responsabilidade de modelar o sistema a partir dos 
requisitos, também são responsáveis por garantir a completeza da implementação. Para isso, 
usam as ligações de rastreabilidade do tipo aqui tratado para localizar áreas do código que 
contribuem na implementação de funcionalidades específicas [Pinheiro et al. 1996, Koncli et 
al., 1988 e Ramesh et al., 1992], e assim, verificar que o seu modelo está permitindo a 
implementação dos requisitos indicados. 
 Projetistas de testes também aproveitam dessas ligações para planejar casos de testes 
completos e inferir a cobertura dos testes sobre os requisitos [Antoniol et al., 2002]. 
 As ligações são de grande uso durante a inspeção de código, provendo aos revisores 
as conexõesentre o código e os seus objetivos e na garantia da qualidade, observando a 
completeza da implementação [Antoniol et al., 2002]. 
 Gerentes de projetos precisam usar a rastreabilidade entre requisitos e código na 
análise de impacto de uma alteração no projeto. O gerente deve identificar os produtos de 
trabalho afetados pela alteração proposta [Arnold et al. (1993)]. Alterações podem 
inicialmente afetar qualquer artefato do sistema e propagar-se por outros produtos de trabalho 
[Fyson, 1998 e Turver, 1994]. Como exemplo, a alteração que adiciona uma nova 
funcionalidade em um sistema é, em muitos casos, iniciada alterando as especificações de 
requisitos. As alterações são então propagadas até o código fonte. O inverso também pode 
ocorrer: uma alteração no algoritmo ou numa estrutura de dados inicia-se no código fonte e é 
então documentada em seções relevantes do documento de desenho e pode até mesmo afetar 
alguns requisitos. 
 Arquitetos corporativos têm nas ligações entre requisitos e código uma sensível ajuda 
para localizar componentes candidatos a reuso[Antoniol et al., 2002]. De fato, desde que 
software freqüentemente não são produzidos para o reuso de seus componentes, ligações de 
rastreabilidade entre código e seus requisitos podem ser de grande ajuda para indexar os 
 
ativos de acordo com o modelo de domínio da aplicação e implementar mecanismos de busca 
que os trazem para uma potencial base de reuso. 
 Além desses profissionais que participam do ciclo de vida do software, esse catálogo 
também é de interesse de pesquisadores da ciência da computação. Estes precisam dominar a 
questão da rastreabilidade em todos os seus detalhes para buscarem uma solução que 
englobe os diversos aspectos do problema. O catálogo aqui mostrado sintetiza os requisitos 
de uma das dimensões da questão da rastreabilidade, sendo útil para a criação de novos 
métodos mais eficazes do que os já existentes. 
 Novas ferramentas de gerência de requisitos podem ser desenvolvidas acrescentando 
à sua lista de requisitos os aqui apresentados. A indústria de software carece de uma base 
sólida para fabricar ferramentas de gerência de requisitos eficientes e de simples utilização. 
Este catálogo pode ser usado como parte de requisitos de entrada para um projeto de 
desenvolvimento de uma ferramenta de gerência de requisitos. 
 Os desenvolvedores de ambientes de desenvolvimento de software (IDE) podem 
também usar este catálogo como fonte de informação, caso queiram disponibilizar uma 
integração com ferramentas de gerência de requisitos. 
1.4 Critérios 
 A catalogação dos requisitos obedeceu a um critério bem definido: primeiramente a 
compilação dos requisitos que se aplicam à rastreabilidade entre requisitos e código extraídos 
de normas e modelos de qualidade. Utilizamos o Chrissis (2007) para a extração de requisitos 
a partir do CMMI e a especificação ISO/IEC 12207. O segundo passo foi a extração de 
requisitos, que ainda não constava no catálogo, a partir das necessidades dos interessados 
listados acima, observadas nos processos de desenvolvimento de software baseados no 
processo unificado [Jacobson, 1999]. Depois utilizamos artigos que tratam da rastreabilidade 
de requisitos em geral. É o caso do artigo Ramesh et al (1997). 
 Por fim, recorremos a artigos que tratam de métodos para rastreabilidade entre 
código fonte e outros artefatos. Fizemos uma ligação entre as características desses métodos 
e os requisitos já catalogados para se descobrir a motivação das características. Para aquelas 
em que a motivação não estava catalogada, avaliamos a universalidade da característica para 
identificar se era ou não um novo requisito. Apresentamos aqui os artigos utilizados neste 
critério organizados por método. Para métodos baseado em roteiros (scenario), utilizamos o 
artigo de Egyed et al. (2002) e o de Eisenbarth et al. (2003). Os trabalhos de Murphy (1995) 
e Antoniol (2000) para métodos baseados em modelos. No caso de métodos baseados em 
Recuperação de Informação (information retrieval), Zhao et al. (2004). Já para os métodos 
baseados em semântica, Collard (2002). 
1.5 Estrutura do Catálogo 
Este catálogo está estruturado usando três níveis de hierarquia, seguindo os mesmos princípios 
adotados por Hoffmann et al. (2004). O nível mais alto é o agrupamento das partes 
interessadas. O segundo nível contém um critério, que especifica a forma que os requisitos 
devem ser avaliados. O terceiro nível é composto de requisitos. Como os requisitos não são 
 
necessariamente diferentes para cada interessado, sempre que duas partes interessadas 
diferentes compartilharem o mesmo requisito, o mesmo é descrito apenas para uma das partes 
interessada, enquanto a outra possui uma referência que aponta para o primeiro. 
 A classificação dos requisitos é feita pelos verbos usados nas sentenças dos 
requisitos, seguindo a técnica “MoSCoW”, que define prioridades nas tarefas efetuadas. 
“MoSCoW” é um acrônimo que representa: 
MUST have this. 
SHOULD have this if at all possible. 
COULD have this if it does not affect anything else. 
WON'T have this time but WOULD like in the future. 
Em português usamos: 
TEM de ter isto. 
DEVE ter isto, se for possível. 
PODE ter isto, se não afetar o resto. 
NÃO TERÁ isto agora, mas SERIA bom ter no futuro. 
Para este artigo, não faz sentido o “NÃO TERÁ isto agora, mas SERIA bom ter no futuro”, 
pois o escopo do catálogo não inclui possibilidades futuras para os métodos, mas apenas o 
que eles, do ponto de vista das partes interessadas, têm ou devem ou podem ter. 
2. Modelos e características dos Métodos de Rastreabilidade entre os 
Requisitos e o Código de Software 
Esta seção contém conceitos e modelos que caracterizam os métodos de rastreabilidade entre 
requisitos e código de software e que são relevantes para o entendimento do catálogo. 
 Rastreabilidade de requisitos é definida por Gotel et al. (1994), como sendo a 
habilidade de descrever e seguir a vida de um requisito nos dois sentidos, de avanço e 
retorno. A simplicidade dessa definição esconde a complexidade do problema. Só o fato de a 
rastreabilidade ser feita entre artefatos de naturezas distintas - requisitos, modelos de desenho 
(Design) de software, código fonte, casos de teste – já torna improvável o uso de um mesmo 
método para toda e qualquer rastreabilidade. A rastreabilidade entre um requisito de software 
e uma variável de classe em um código escrito em Java é diferente na forma e no conteúdo de 
outra rastreabilidade entre o mesmo requisito e uma associação em um diagrama UML. Um 
código Java é de natureza distinta de um modelo UML. 
 Ligação de Rastreabilidade (trace link): é o elemento que liga dois itens 
rastreáveis. As ligações de Rastreabilidade podem também ser de naturezas distintas. Uma 
ligação de rastreabilidade normalmente liga dois itens bem definidos. Mas no caso da 
rastreabilidade entre requisitos e código é possível que os itens ligados não sejam bem 
definidos, mas estejam fragmentados e diluídos em todo o código, caracterizando uma forma 
de ligação diferente da forma da primeira. É o caso da ligação com alguns requisitos não 
funcionais. O requisito “registrar em arquivo qualquer mudança de estado do software” é um 
 
exemplo. Ele pode não se ligar em uma área bem definida e delimitada do código, mas a 
implementação que resolve o requisito pode estar fragmentada em todo o código. Outro caso 
de ligação de natureza distinta é a ligação indireta. Um requisito pode interferir num código 
através de um modelo de desenho. O projeto de uma solução arquitetural pode ter sua 
motivação em um determinado requisito, e então determinar a estrutura final do código. Nesse 
caso, não há ligação direta entre o requisito e o código, mas através do modelo de desenho 
que representa a solução arquitetural para o requisito e que é refletida no código. A ligação de 
rastreabilidade entre o requisito e o código, neste caso, possui características de indireção.Unidade Computacional: Eisenbarth e tal (2003) definiram a Unidade 
Computacional como uma parte executável de um sistema. Exemplos de unidades 
computacionais são instruções (como acesso a variáveis globais), blocos de código básicos, 
rotinas, classes, unidades de compilação, módulos ou subsistemas. Para efeito de 
simplificação, neste artigo, também será incluído o código declarativo na definição de unidade 
computacional. 
 Corte Funcional (Slice): é o conjunto de Unidades Computacionais que podem 
afetar um conjunto determinado de variáveis [Beszédes, 2001]. Os algoritmos de corte 
podem ser classificados como algoritmo para Cortar estático (static slicing), que usa 
apenas informações estáticas do código para se obter o corte; e o algoritmo de Cortar 
dinâmico (dynamic slicing), que usa também valores de variáveis que podem influenciar o 
corte. 
 Item de Rastreabilidade (traceability item): O termo é definido por Spencer e 
Probasco (1998) como “qualquer item textual ou item de modelo que precisa ser 
explicitamente rastreado para outro item textual ou item de modelo, para manter a trilha de 
dependências entre eles”. 
 Item de código de rastreabilidade (ICR): Quando o item de rastreabilidade for 
uma Unidade Computacional ou um Corte Funcional, pode ser designado genericamente 
neste artigo por item de código de rastreabilidade ou ICR. 
 Na figura 1 está exibido um meta-modelo para explicar melhor a divisão do código de 
software. Os meta-modelos aqui apresentados, tanto dessa figura como das seguintes, não 
pretendem apresentar uma visão encerrada da rastreabilidade. Foram feitos apenas para 
auxiliar no entendimento dos conceitos. Têm fins puramente didáticos. São escritos em UML 
1.5 e mostram as relações entre os conceitos utilizados no catálogo. No caso, a figura 1 
mostra a generalização da Unidade Computacional e do Corte Funcional no Item de Código 
de Rastreabilidade (ICR), que, por sua fez, é uma especialização do Item de Rastreabilidade. 
Também mostra, através de uma agregação, que um Corte Funcional é composto de uma ou 
mais Unidades Computacionais. 
 
 
Item de 
Rastreabilidade
Item de Código de 
Rastreabilidade (ICR)
Corte FuncionalUnidade Computacional
*1..* *1..*
Figura 1. Meta-modelo Item de Rastreabilidade. 
 Diferente da opção de Ebner e Kaindl (2002), que representam as ligações de 
rastreabilidade em meta-modelos como “associações” entre itens de rastreabilidade, nós 
optamos por representar ligações em forma de “classes”. Inspiramo-nos na definição de Jarke 
(1998), que diz que as ligações são produtos da rastreabilidade, e como produtos têm 
identidade e características bem definidas, e, portanto, devem ser representadas como 
“classes”. 
 A figura 2 mostra o meta-modelo das relações das ligações com as unidades 
computacionais. Uma ligação de rastreabilidade pode ligar diversos requisitos a diversas 
Unidades Computacionais. A semântica da ligação não é derivada diretamente dos itens que 
ligam, mas o inverso, os itens de rastreabilidade são conseqüências de uma percepção 
cognitiva. Jarke (1998) explica que “desta percepção, uma ligação de rastreabilidade captura 
objetos conceituais e os liga de uma forma significativa”. É possível que diversos requisitos 
juntos tenham um significado único e que esse significado seja a fundamentação de uma 
implementação distribuída em diversas Unidades Computacionais. Assim, podemos alterar 
requisitos ou Unidades Computacionais sem alterar a identidade da ligação, já que a idéia, a 
percepção cognitiva, que fundamenta o código pode se manter. 
 
Constructo
Requisito
Ligação de Rastreabilidade entre Requisito e 
Unidade Computacional
1..* 1..*
+IRR
1..* 1..*
fundamenta
Unidade 
Computacional
1..*
1..*
+ICR1..*
1..*
satisfaz
Composição de Unidade 
Computacional
1..*
*
1..*
*
Figura 2. Ligação de Rastreabilidade entre Requisito e Unidade 
Computacional. 
 Na figura 2 nota-se ainda a possibilidade de uma Unidade Computacional ser a 
composição de diversas outras Unidades Computacionais que podem ser fundamentadas em 
ligações de rastreabilidade diferentes. 
 O meta-modelo das Ligações de rastreabilidade entre Requisitos e o Corte Funcional, 
figura 3, mostra uma realidade diferente. Um requisito funcional é tomado como base para a 
ligação que é satisfeita num único corte funcional. Outros requisitos podem colaborar na 
fundamentação do código, mas apenas um é a base. O corte funcional é composto por 
diversas unidades computacionais, que podem ser fundamentas por outros requisitos. 
 Um tipo especial de rastreabilidade (Ligações de rastreabilidade para alterações) 
pode ser criado para melhor satisfazer uma prática pedida pelo CMMI. Na descrição do item 
SP 1.4 “Manutenção da Rastreabilidade Bidirecional de Requisitos” é dito que “a 
rastreablilidade é particularmente necessária na condução da análise de impacto das 
alterações de requisitos das atividades de projeto e produtos de trabalho” Chrissis, (2007), 
página 492. Ligações de rastreabilidade para alterações facilitam a análise e o histórico das 
alterações. 
 A figura 4 mostra as ligações de Rastreabilidade entre Alteração e Unidade 
Computacional. Uma alteração, quando realizada, é toda mapeada por essa ligação: a 
requisição que a originou, os requisitos alterados e as unidades computacionais incluídas, 
alteradas e excluídas. 
 
Requisito Não 
Funcional
Unidade Computacional
Corte 
Funcional
1..*
*
1..*
*
Requisito
Requisito 
Funcional
Ligação de Rastreabilidade entre 
Requisito e Corte Funcional
1
1
+ICR1
+satisfaz1
* *
+colaboradores
*
+realização
*é realizado em
1
1
+base
1
+codigo da realização
1
define
Figura 3. Ligação de Rastreabilidade entre Requisitos e Corte Funcional. 
 
Requisição de 
Alteração
Requisito
*
*
+candidatos a alteração
*
*
impacta
Unidade Computacional
Ligação de Rastreabilidade entre Alteração e 
Unidade Computacional
1 0..1
+gatilho
1
+realização
0..1
gera
*
+alterado
*
alteração de requisito
*
+adicionado
* *
+alterado
**
+removido
*
 Figura 4. Ligação de Rastreabilidade entre Alteração e Unidade de Código 
 É importante ressaltar que uma ligação de rastreabilidade entre requisitos e código 
pode ser indireta. Os requisitos podem ser refinados em diferentes artefatos antes de alcançar 
o código fonte. Antoniol et al. (2000) dizem que “Sistemas de software são desenvolvidos 
seguindo processos no qual a complexidade da engenharia de software é atacada por meio de 
subseqüentes atividades de refinamento. Analise de requisitos, projeto e codificação são fases 
que estão presentes em quase todos os processos de desenvolvimento de software”. Pode-se 
então pensar que os requisitos são sempre refinados em algum modelo de projeto, para então 
serem implementados. O próprio Antoniol deixa claro que a realidade não é essa: “entretanto, 
a manutenção da consistência entre os artefatos de software e uma atividade custosa e 
tediosa, que é freqüentemente sacrificada durante o desenvolvimento e manutenção devido às 
pressões do mercado”. Há requisitos que são implementados diretamente no código e há 
requisitos que passam por um projeto antes de serem implementados. Assim é necessário que 
as ligações entre requisitos e código possam ser indiretas ou não. A figura 5 mostra, dentre 
 
outras ligações, a Ligação indireta, que é uma composição de outras Ligações de 
Rastreabilidade. 
 
Ligação de Rastreabilidade entre Requisito e Código
Ligação de Rastreabilidade entre Alteração e 
Unidade Computacional
Ligação de Rastreabilidade entre 
Requisito e Corte Funcional
Ligação de Rastreabilidade entre Requisito e 
Unidade Computacional
Ligação de 
Rastreabilidade
Ligação de Rastreabilidade Indireta 
entre Requisito e Código
1..*
*
1..*
*
Figura 5. Meta-modelo dos tipos de Ligação de Rastreabilidade. 
 
 As ligações de rastreabilidade entre requisitos e código de software podem ser 
classificadas quanto ao âmbito ou quanto ao tipo de ligação.Classificação quanto ao âmbito dos itens de código de rastreabilidade (ICR): As 
ligações de rastreabilidade podem ser classificadas em função da abrangência que a 
fundamentação exerce sob o ICR. Criamos esta classificação baseada naquela feita por 
Eisenbarth et al (2003), página 218: 
Específica: o item de código existe somente por causa do requisito, que é satisfeito somente 
por este item de código. Em outras palavras, o ICR é fundamentado somente pelo requisito, 
que não é fundamento de nenhum outro item de código. 
Relevante: o item de código é fundamentado pelo requisito, mas também é fundamentado 
por outros requisitos. 
Específica com condição: o item de código existe somente por causa do requisito, que é 
satisfeito somente por este item de código em determinadas condições. 
Compartilhada: o item de código existe somente por causa do requisito, mas outros itens de 
código também colaboram na sua implementação. 
Irrelevante: O item de código é irrelevante para o requisito. 
 A classificação quanto ao âmbito depende exclusivamente das multiplicidades da 
relação da ligação com o requisito e com o ICR. A figura 2 mostra que, para ser específica, a 
ligação de rastreabilidade entre requisito e código deve se associar a apenas um ICR e a um 
Requisito. Assim temos que um único requisito fundamenta um único ICR. 
 
 
Item de Código de Rastreabilidade (ICR)
Requisito Ligação de Rastreabilidade entre Requisito e Código
1+ICR 1
satisfaz
1
+IRR
1
fundamenta
Figura 6. Meta-modelo da ligação de rastreabilidade do tipo de Específica 
 O que é ligeiramente diferente da Ligação de Rastreabilidade Compartilhada, que 
permite a um requisito seja satisfeito por diversos ICR. 
 
 
Item de Código de Rastreabilidade (ICR)
Requisito Ligação de Rastreabilidade entre Requisito e Código
2..*+ICR 2..*
satisfaz
1
+IRR
1
fundamenta
Figura 7. Meta-modelo da Ligação de Rastreabilidade Compartilhada. 
Já no caso da Ligação de Rastreabilidade Relevante, mais de um requisito fundamenta o ICR. 
Item de Código de Rastreabilidade (ICR)
Requisito Ligação de Rastreabilidade entre Requisito e Código
1+ICR 1
satisfaz
2..*
+IRR
2..*
fundamenta
Figura 8. Meta-modelo da Ligação de Rastreabilidade Relevante. 
 
 
 
 
3. Requisitos 
Esta seção contém o catálogo de requisitos para métodos de rastreabilidade entre requisitos e 
código de software, do ponto de vista das partes interessadas. 
3.1 Requisitos de Programadores 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos programadores. 
3.1.1 Indicação da fundamentação do código 
O método tem de registrar as ligações de rastreabilidade entre código (ICR) e requisitos que 
servem de base, no código fonte, para a lógica desenvolvida, e assim fundamentam o código. 
Requisito 1. O método deve permitir que a ligação de rastreabilidade seja feita durante a 
atividade de codificação. 
Requisito 2. O método deve informar quando novas Unidades Computacionais 
desenvolvidas podem interferir em ligações de rastreabilidade existentes. É o caso de 
alterações da classificação quanto ao âmbito de ligações já existentes. Por exemplo: 
um ICR que era originalmente Específico, com a nova Unidade Computacional, torna-
se Compartilhado. 
Requisito 3. O método deve ser o menos intrusivo possível na codificação. A 
codificação deve ser regida por padrões e normas que visam uma melhor estruturação 
e entendimento do código. Exigir uma forma de codificação para satisfazer um 
determinado método pode conflitar com padrões da organização e prejudicar a 
inteligibilidade do código. É um recurso que deve ser desencorajado nos métodos de 
rastreabilidade. 
Requisito 4. O método tem de suportar Ligações de Rastreabilidade Indireta, 
principalmente a rastreabilidade entre código e requisitos através de modelos de 
desenho (design). Muitos requisitos são realizados nas atividades de analise e 
desenho do sistema. Ao ser implementado a partir de algum modelo, o código está 
indiretamente realizando os requisitos que motivaram o modelo. O método de 
rastreabilidade entre requisitos e código deve somar estes requisitos aos outros que 
são diretamente realizados no código. 
Requisito 5. O método pode permitir que o programador indique os requisitos que 
fundamentam as Unidades Computacionais diretamente do ambiente de codificação, 
para não haver interrupção no trabalho de programação. Isso pode ocorrer através 
da implementação do método diretamente na ferramenta de codificação ou via alguma 
integração entre ferramentas. 
Fundamentação: Ramesh et al.(1997) dizem que a rastreabilidade facilita a compreensão dos 
processos por traz da criação dos artefatos. Durante a codificação, o programador utiliza os 
requisitos, direta ou indiretamente, como base lógica para o desenvolvimento das Unidades 
Computacionais. É importante que o método de rastreabilidade permita o registro dessa 
informação, já que, obtê-la mais tarde, pode ser uma tarefa árdua. 
 
Também o modelo CMMI, na área chave Desenvolvimento de Requisitos (RD), a meta 
específica 2, “Desenvolver requisitos do produto”, pede o registro da rastreabilidade do 
requisito até funções e componentes do produto. 
O método proposto por Zhao et al. (2004) baseado em recuperação de informação (IR) 
lembra-nos da importância da não interferência na forma de codificação adotado na 
organização. 
3.1.2 Compreensão do código 
O método deve ajudar o programador, durante uma manutenção, no entendimento de códigos 
que não foram escritos por eles. Deve permitir a análise de discrepâncias e buscar a clareza 
do código [Ramesh et al., 1997]. A compreensão do código, segundo alguns modelos 
cognitivos, pode ocorrer da forma ascendente (bottom-up), isto é, a partir de conceituação 
detalhes de Unidades Computacionais, que servirão de base para conceitos cada vez mais 
abstratos; da forma descendente (top-down), partindo de uma hipótese do funcionamento do 
código, que deve ser verificada junto aos Cortes Funcionais; ou alguma combinação das duas 
formas [Antoniol, 2002]. 
Requisito 6. O método deve permitir visualizar as Ligações de Rastreabilidade entre um 
determinado requisito funcional e os Cortes Funcionais de código que o resolve. 
Assim o programador que utiliza o modelo cognitivo descendente pode usar essa 
visualização para, uma vez que a hipótese da estrutura das unidades computacionais 
tenha sido formulada, procurar por sinais de sua confirmação ou negação nas ligações 
de rastreabilidade. 
Requisito 7. O método deve permitir uma visualização das ligações de rastreabilidade 
entre uma determinada Unidade Computacional e os requisitos que a justifica. Assim, 
Na compreensão ascendente, os programadores têm subsídios para atribuir conceitos 
às unidades de código. 
Requisito 8. O método deve permitir uma visualização das ligações entre um 
determinado Corte Funcional e os requisitos funcionais. Essa visualização ajuda, 
quando da utilização da compreensão ascendente, nos grupamentos das unidades de 
código em conceitos mais abstratos. 
Requisito 9. As visualizações podem mostrar a classificação quanto ao âmbito da 
ligação. Caso o ICR seja classificado como Compartilhado, as visualizações podem 
mostrar todos os ICR que juntos resolvem o requisito. Caso seja classificado como 
Relevante, podem mostrar todos os requisitos que fundamentam o ICR. 
Requisito 10. O método pode capturar as ligações dinamicamente, permitindo que 
qualquer alteração no código reflita imediatamente na rastreabilidade. 
Fundamentação: Os programadores usam diferentes tipos de conhecimento durante a 
compreensão do programa, variando do conhecimento específico do domínio do sistema até 
o conhecimento geral de programação. Ligações de rastreabilidade entre áreas específicas do 
código e sessões relacionadas em documentos de especificação de requisitos ajudam na 
compreensão tanto do modelo ascendente,como no descendente. Na compreensão 
 
descendente, uma vez que a hipótese tenha sido formulada, as ligações de rastreabilidade 
sugerem onde se deve procurar por sinais de sua confirmação ou negação. Na compreensão 
ascendente, o principal papel da rastreabilidade é ajudar os programadores na atribuição de 
conceitos a pedaços de código e no agrupamento desses pedaços em conceitos mais 
abstratos [Antoniol, 2002]. 
O método proposto por Murphy et al. (1995) mostra a importância da captura dinâmica das 
ligações de rastreabilidade a partir de um código de software legado. 
 
3.1.3 Diagnóstico 
O método deve fornecer as informações que minimizam o trabalho do programador no 
diagnóstico de uma questão técnica. 
Requisito 11. A partir de uma questão técnica, o método deve mostrar os ICR 
vinculados aos requisitos que a questão afeta, ordenadas pela classificação quanto ao 
âmbito dos ICR, do mais forte ao mais fraco: Específica, Específica com condição, 
Relevante, Compartilhada. A ligação de rastreabilidade neste caso é indireta: questão 
se liga com requisito que se liga com código. 
Fundamentação: A norma NBR ISO/IEC 12207:1998, no item 5.5 Processo de manutenção, 
atividade 5.5.3 Implementação da modificação, indica que o programador deve conduzir a 
análise e determinar que [..] unidades de software e versões destas necessitam ser 
modificadas. O modelo CMMI, na área chave Desenvolvimento de Requisitos (RD), a meta 
específica 2, “Desenvolver requisitos do produto”, pede o registro da rastreabilidade do 
requisito entre componentes do produto e questões. Assim é possível que uma questão que 
reporta um mau funcionamento do software seja previamente analisada e rastreada até os 
requisitos que são afetados. Sendo, as ligações classificadas quanto sua força e rastreadas até 
as unidades computacionais, o programador tem condições de diminuir o escopo do código 
que deve ser verificado, tornando seu trabalho mais produtivo. 
 
3.1.4 Alteração do código 
O método tem de permitir o registro da rastreabilidade entre a alteração proposta e o código 
alterado. 
Requisito 12. O método tem de fazer ligações de rastreabilidade entre Unidades 
computacionais incluídas, alteradas ou removidas e o registro da alteração proposta. 
Requisito 13. O método pode ser integrado com a ferramenta de gestão de configuração 
utilizada na organização para não manter dois registros concorrentes das alterações 
dos artefatos de código. 
Requisito 14. O método tem de identificar a versão alterada e a original dos artefatos 
que contêm as Unidades Computacionais alteradas. A Ligação de Rastreabilidade 
Entre Alteração e Unidade Computacional tem de se associar às versões originais e 
alteradas dos ICRs. 
 
Requisito 15. O método tem de identificar a versão alterada e a original dos requisitos 
envolvidos na alteração. A Ligação de Rastreabilidade Entre Alteração e Unidade 
Computacional tem de se associar às versões originais e alteradas dos Requisitos 
envolvidos na alteração. 
Fundamentação: Uma sub-prática da gerência de alterações de requisitos proposta pelo 
CMMI é “documentar todo requisito e alterações de requisitos que são dados ou gerados 
pelo projeto” [Chrissis, 2007, pág. 491]. Isto porque, como Chrissis explica, é essencial 
gerenciar as alterações no projeto eficientemente. 
 3.2 Requisitos para Gerentes de Configuração 
Esta subseção descreve os critérios e seus requisitos que cobrem as necessidades do ponto 
de vista dos Gerentes de Configuração dos métodos de rastreabilidade entre requisitos e 
código. 
3.2.1 Indexação 
O método tem de identificar cada unidade computacional, cada corte funcional, cada requisito 
e as ligações de rastreabilidade entre eles. 
Requisito 16. O método tem de identificar unicamente cada Item de Rastreabilidade 
durante seu ciclo de vida. Um item de rastreabilidade, especialmente o ICR, tem de 
receber uma identificação durante sua criação que deve ser única e não pode ser 
alterada durante as manutenções do código. A menos que a manutenção a 
descaracterize, e, portanto, a unidade deixa de existir, dando lugar a uma outra. 
Requisito 17. O método tem de ser capaz de identificar Unidades Computacionais em 
diferentes níveis de detalhe. Uma ligação pode ser feita utilizando tanto linha de 
código, como métodos, como classes ou subsistemas. 
Requisito 18. O método tem de ser capaz de identificar unicamente Cortes Funcionais. 
Uma possível forma é utilizar como identificadores as entidades externas que o Corte 
Funcional afeta diretamente. Não são as Unidades Computacionais que compõe um 
Corte Funcional que o identificam, pois, estas Unidades podem ser alteradas sem que 
a identidade do corte seja afetada. 
Requisito 19. O método pode permitir que as Unidades Computacionais que compõe 
um Corte possam variar em níveis de detalhe, do mais detalhado para o menos 
detalhado, sem caracterizar uma alteração no corte. Um determinado método, que faz 
parte de um corte, pode ser substituído por sua classe sem que aja alguma alteração 
no corte. 
Requisito 20. O método tem de identificar as Ligações de Rastreabilidade e classifica-las 
quanto ao seu tipo e âmbito. 
Requisito 21. O método deve indexar ICR em linguagens de programação distintas, 
reconhecendo as Unidades Computacionais segundo os paradigmas de cada uma. 
Caso seja uma linguagem Procedural, Orientada a Objetos e até mesmo reconhecer 
mecanismos como Orientação a Aspectos. 
 
Requisito 22. O método deve reconhecer constructos de linguagens mais sofisticados, 
como ponteiro e vínculos dinâmicos (dynamic binding). 
Fundamentação: para haver gerência de configuração sobre as ligações de rastreabilidade, é 
importante que os componentes da rastreabilidade sejam identificados, só assim pode-se 
registrar suas histórias nas ligações. Pan et al. (2005) mostram esta necessidade. 
O método proposto por Collard et al. (2002) lembra-nos da importância da identificação das 
unidades computacionais sem interferir na estrutura do código proposto pela organização. 
3.2.2 Gestão de configuração da rastreabilidade 
As ligações de rastreabilidade têm de ser controladas na mesma linha de base dos artefatos 
controlados. 
Requisito 23. O método tem de garantir a integridade das Ligações de Rastreabilidade 
entre Alteração e Unidade Computacional. Sempre que uma alteração ocorrer num 
ICR, deve existir uma Ligação de Rastreabilidade entre Alteração e Unidade 
Computacional que fundamenta a alteração. O método pode garantir a integridade 
através de um relatório de itens de Rastreabilidade alterados que não possuem 
Ligação de Rastreabilidade entre Alteração e Unidade Computacional ou não permitir 
a alteração sem a indicação da Ligação. 
Requisito 24. O método tem de permitir a utilização concorrente das Ligações de 
Rastreabilidade e de seus itens. Tem de ser possível o uso de trancas (lock), e outros 
mecanismos de controle, nas Ligações de Rastreabilidade e em seus itens durante 
edições para quando se estiver trabalhando num ambiente distribuído de uso 
concorrente. 
Requisito 25. O método tem de permitir que Ligações de Rastreabilidade acompanhem 
as linhas de base dos itens de rastreabilidade que referenciam. Assim uma alteração 
num item de Rastreabilidade que afete Ligações de Rastreabilidade e a alteração 
Ligação de rastreabilidade, só pode ser percebida por quem estiver utilizando a linha 
de base que os itens e as ligações fazem parte. 
Requisito 26. As Ligações de Rastreabilidade entre Alteração e Unidade Computacional 
devem poder referenciar Itens de Rastreabilidade entre linhas de base. Apesar de 
fazer parte da linha de base mais atualizada, este tipo de Ligação de Rastreabilidade 
deve referenciar a versão anterior tanto do ICR como do Requisito, que fazem parte 
de linhas de base mais antigas. 
Requisito 27. O método pode permitir que alterações concorrentes, mas 
complementares, em ligações de rastreabilidade devam ser percebidas por seus 
executores, sepossível, durante sua elaboração. Essas alterações ocorrem em 
colaboração, e o seu resultado deve ser liberado em conjunto para integração numa 
linha de base. 
Requisito 28. O método tem de reconhecer conflitos em Ligações de Rastreabilidade 
gerados por alterações em Itens de Rastreabilidade executadas concorrentemente. 
Duas alterações diferentes numa mesma Unidade Computacional (ou em Unidades 
 
Computacionais diferentes que fazem parte de uma única Unidade Computacional 
maior), que ocorreram concorrentemente e foram fundidas durante a liberação, 
podem gerar alterações nas suas fundamentações (rastreabilidade com requisitos) que 
são incompatíveis. Isto é, o resultado da fusão das alterações numa unidade 
computacional, não implica, necessariamente, na soma das ligações de rastreabilidade 
alteradas. 
Fundamentação: As ligações rastreabilidade também são itens de configuração e precisam ser 
gerenciadas num ambiente de desenvolvimento distribuído e concorrente, assim como descrito 
por Chrissis et al. (2007) na área chave de Gerência de Configuração, página 191. Chrissis et 
al. exemplifica uma linha de base com itens de configuração, explicitando o uso de itens de 
rastreabilidade na “matriz de rastreabilidade de requisitos”, pág. 192. 
3.3 Requisitos para Analistas de Sistema 
Esta subseção descreve os critérios e seus requisitos que cobrem as necessidades do ponto 
de vista dos analistas de sistemas dos métodos de rastreabilidade entre requisitos e código. 
Segundo o Processo Unificado, o analista de sistemas é, dentre outras coisas, o responsável 
por desenvolver um plano de gerência de requisitos e depois gerenciar as dependências dos 
requisitos com outros itens de rastreabilidade. 
 
3.3.1 Acompanhamento do estado dos requisitos 
O método tem de permitir ao analista acompanhar a evolução dos requisitos durante o seu 
ciclo de vida, mostrando o estado de sua realização. 
Requisito 29. O método tem de permitir a produção de relatórios de acompanhamento 
por requisito do produto que, inferindo as ligações de rastreabilidade entre requisitos 
e código, quantifique a completeza das realizações dos requisitos. O analista não 
precisa conhecer as ligações de rastreabilidade entre requisitos e código. As unidades 
computacionais e os cortes funcionais são detalhes desnecessários para suas 
atividades. Mas precisa destas informações para alimentar métricas que indicam o 
estado de implementação dos requisitos. Seria interessante que as medidas utilizadas 
nessas métricas fossem coletadas de forma automática, para poupar o custo de um 
trabalho de grandes proporções. O método deve permitir a geração de relatórios com 
essas medidas e se possível já com os cálculos das métricas. 
Requisito 30. O método pode permitir, usando os ICR como base comum, a 
visualização de relações entre requisitos. Caso dois requisitos diferentes compartilhem 
sua realização numa mesma Unidade Computacional, há indícios de relação entre 
esses requisitos, que, a partir de uma análise, pode levar a uma reavaliação da 
definição dos mesmos. 
Requisito 31. O método pode capturar as ligações dinamicamente, permitindo que 
qualquer alteração, criação ou remoção nos requisitos reflita imediatamente na 
rastreabilidade. Pode-se gerar novas ou alterar Ligações de Rastreabilidade a partir 
de criação e alteração em definições de requisitos. 
 
Requisito 32. O método tem de garantir a integridade das ligações. Pode ser feito 
através de verificação, gerando relatório de inconsistências ou não permitindo que a 
inconsistência ocorra. 
 Fundamentação: [Chrissis, 2007, pág. 491] a área de processo gerencia de requisitos, 
prática específica 1.3 “gerência de alterações de requisitos” pede para que as alterações dos 
requisitos com as suas evoluções durante o projeto sejam acompanhadas. O resultado da 
analise da evolução de um requisito é insumo para verificação de sua consistência, precisão 
completeza e correção. 
3.4 Projetistas de teste 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos projetistas de teste. 
3.4.1 Inferência da cobertura do teste 
O método deve permitir ao projetista de teste obter informações da cobertura dos casos de 
teste. 
Requisito 33. A partir de um relatório de execução do software, o método deve extrair 
os ICR e reportar todos os requisitos que se ligam a eles, classificados quanto ao 
âmbito. Estes requisitos devem satisfazer a necessidade do projetista de confirmar 
quais os requisitos estão sendo realmente testados na execução de cada caso de 
teste. Assim pode reavaliar o projeto dos testes para uma maior exatidão. 
Requisito 34. O método pode permitir uma visualização do software com seus cortes 
funcionais e os requisitos ligados a eles, para auxiliar na elaboração de testes 
funcionais. 
Requisito 35. O método pode permitir a elaboração de um relatório de referência 
cruzada entre os cortes funcionais e os requisitos não-funcionais, que ajudam na 
montagem de roteiros usados nos testes de requisitos não-funcionais. 
Requisito 36. O método pode integrar com a ferramenta de automação de testes 
utilizada pela organização. As visualizações e relatórios descritos acima podem ser 
implementados na própria ferramenta de automação de testes ou permitir a integração 
com a mesma. 
Fundamentação: Segundo o Processo Unificado, o projetista de teste é responsável pela 
integridade do modelo teste, garantindo que cumpra seu papel. Além disso, deve selecionar e 
descrever os casos de teste [Jacobson, 1998, pág. 303]. Para cumprir essas funções o 
projetista precisa examinar os motivadores e itens alvos dos testes. Em outras palavras, 
precisa conhecer as ligações de rastreabilidade entre código e os seus motivadores, os 
requisitos. 
 
 
3.5 Revisores Técnicos 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos Revisores Técnicos. 
3.5.1 Inspeções técnicas 
O método pode fornecer indicações de melhores candidatos à inspeção e a fundamentação 
de cada unidade computacional que é inspecionada. 
Requisito 37. O método pode fornecer um relatório de ICR que se fundamentam em um 
número maior de requisitos. Estes itens tendem a ser mais complexas e críticos para o 
funcionamento do software, e devem ser vistos como candidatos a inspeção. 
Requisito 38. O método deve permitir a compreensão do código pelo revisor [vide o 
critério compreensão do código pelos programadores]. 
Fundamentação: [Chrissis, 2007, pág. 580] mostra que a verificação é uma área chave do 
CMMI, e que a inspeção é uma forma de revisão por pares, que por sua vez é o mecanismo 
mais importante da verificação. Na página 583, [Chrissis, 2007] apresenta a sub-prática 
“identificar os requisitos satisfeitos por cada produto de trabalho selecionado.” Ele ainda 
aponta para “a prática específica de Manter a Rastreabilidade bidirecional de requisitos na 
área chave de processo de gerencia de requisitos para ajudar a identificar os requisitos para 
cada produto de trabalho”. A inspeção de código normalmente ocorre por amostragem. A 
seleção do código a ser analisado deve seguir critérios objetivos e eficientes. Também é 
necessário que o revisor compreenda o código analisado sob o ponto de vista dos requisitos. 
3.6 Gerentes de Projeto 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos Gerentes de Projeto. 
3.6.1 Análise de Impacto de alterações que afetam primeiramente os 
requisitos 
O método tem de dar subsídios na análise de impacto de uma alteração no projeto. 
Requisito 39. O método tem de, a partir de uma requisição de alteração, gerar um 
relatório com o resultado de alguma métrica que mostre a quantidade e a 
complexidade dos ICR envolvidos eo seu grau de envolvimento com a alteração. 
Observe que neste momento não há ainda uma Ligação de Rastreabilidade entre 
Alteração e Unidade Computacional, pois a alteração não foi realizada, é apenas uma 
requisição que precisa ser analisada. O relatório é possível através de um Ligação de 
Rastreabilidade Indireta: requisição de alteração que se liga com requisitos, que se 
ligam com ICR. O gerente do projeto precisa estimar custos e prazos para aprovar ou 
rejeitar a alteração proposta. 
Requisito 40. O método tem de, a partir de uma requisição de alteração, relatar os 
artefatos de código que possuem as unidades computacionais envolvidas na alteração. 
O relatório é possível através de um Ligação de Rastreabilidade Indireta: requisição 
 
de alteração que se liga com requisitos, que se ligam com unidades computacionais 
que fazem parte de artefatos de código. Os artefatos de código são Unidades 
Computacionais tratados como unidades físicas pelo processo de desenvolvimento de 
software da corporação. O relatório deve ser usado para complementar a lista de 
artefatos candidatos a alteração. 
Fundamentação: Alterações podem inicialmente afetar qualquer artefato do sistema e 
propagar-se por outros produtos de trabalho [Fyson, 1998 e Turver, 1994]. O caso aqui 
tratado é para toda alteração que diz respeito á alteração de requisitos. Como essa alteração 
deve ser propagada para outros artefatos do projeto, provavelmente deve afetar também o 
código. O método de rastreabilidade entre requisitos e código deve fornecer subsídios para 
ajudar na análise de impacto desse tipo de alteração. 
3.6.2 Análise de Impacto de alterações que afetam primeiramente o código 
Requisito 41. O método tem de identificar os ICR envolvidos na alteração e gerar um 
relatório com os requisitos afetados, o que ajuda na análise de impacto da alteração. 
Requisito 42. O método pode identificar e relatar os Cortes Funcionais que utilizam as 
Unidades Computacionais envolvidas na alteração, e assim, permitir uma análise de 
impacto horizontal no código afetado. 
Requisito 43. O método pode, para os requisitos onde as Ligações de Rastreabilidade 
são classificadas quanto ao âmbito como Relevantes ou Compartilhadas, relatar os 
outros ICR que completam a realização do requisito. 
Fundamentação: Gerentes de projetos precisam usar a rastreabilidade entre requisitos e 
código na análise de impacto de uma alteração no projeto. O CMMI prega que, “A 
rastreabilidade é particularmente necessária na condução da análise de impacto das alterações 
de requisitos” [Chrissis, 2007, pág. 492]. Alterações propostas no código devem ser 
rastreadas até os requisitos que o fundamentou, para que o gerente do projeto possa analisar 
o impacto da alteração nos requisitos. 
Egyed et al. (2002), ao explicar o funcionamento de seu método, chama a atenção de como o 
código de software funciona como uma base para se localizar relação entre requisitos que 
fundamentam uma mesma unidade computacional. Sendo assim a alteração de um requisito 
pode impactar diretamente em outros que estão ligados a mesma unidade computacional. 
3.6.3 Acompanhamento da alteração 
O método tem de permitir o acompanhamento do estado da alteração. 
Requisito 44. O método tem de relatar as diferenças entre os artefatos de código 
candidatos à alteração com os realmente alterados. Estas informações são extraídas 
das Ligações de Rastreabilidade entre Alteração e Unidades Computacionais e as 
ligações indiretas de rastreabilidade entre Requisição de Alteração e ICR. 
Fundamentação: “Para uma análise de impacto da alteração eficiente é necessário que a fonte 
de cada alteração seja conhecida e a razão de qualquer alteração documentada” [Chrissis, 
2007, pág. 491]. 
 
Uma sub-prática da gerência de alterações de requisitos proposta pelo CMMI é “Manter o 
histórico das alterações com suas fundamentações” [Chrissis, 2007, pág. 491]. 
Uma sub-prática da gerência de alterações de requisitos proposta pelo CMMI é “documentar 
todo requisito e alterações de requisitos que são dados ou gerados pelo projeto” [Chrissis, 
2007, pág. 491]. Isto porque, como Chrissis explica, é essencial gerenciar as alterações no 
projeto eficientemente. 
3.7 Arquitetos Corporativos 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos Arquitetos de 
Software Corporativos. O Processo Unificado define como função do Arquiteto de Software, 
dentre outras, a definição de componentes reusáveis. 
3.7.1 Localização de candidato ao reuso 
O método pode fornecer informações de unidades computacionais candidatas a reuso. 
Requisito 45. Para determinados requisitos, previamente selecionados pelo arquiteto, o 
método pode classificá-los segundo sua coesão nas unidades computacionais que os 
implementam. Primeiramente as que apresentam Ligações de Rastreabilidade 
classificadas quanto ao âmbito como Específicas. Seguido das Específicas com 
Condição. Depois as Relevantes. E, por fim, as Compartilhadas. Os requisitos que 
são implementados em Unidades Computacionais específica são mais facilmente 
isolados do resto do código do que as outras, já que essas unidades são coesas do 
ponto de vista do requisito. 
Fundamentação: A extração de ativos reusáveis a partir de um sistema de software é uma 
necessidade da indústria como descreve Caldiera e Basili (1991).Para se extrair ativos de 
reuso, a partir de software que não foram originalmente produzidos para o reuso de seus 
componentes, é necessário uma avaliação de quais unidades computacionais farão parte do 
componente de reuso e o quanto estas unidades estão dependentes do restante do código. 
3.8 Gerente da Qualidade 
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre 
requisitos e código que cobrem as necessidades do ponto de vista dos Gerentes da 
Qualidade. Alguns processos, como o Rational Unified Process 2003, atribuem às atividades 
aqui tratadas como pertencentes ao gerente de projetos. Como a norma NBR ISO/IEC 
12207:1998 pede que o processo de garantia da qualidade seja imparcial, e para isso, “a 
garantia da qualidade necessita ter autoridade e autonomia organizacional, independente das 
pessoas diretamente responsáveis pelo desenvolvimento do produto de software ou pela 
execução do processo no projeto”, por tudo isso, optamos por utilizar o papel de gerente da 
qualidade na execução destas tarefas. 
 
3.8.1 Gestão de Processos 
O método tem de conter a descrição das tarefas que compõe fluxo de trabalho para a sua 
utilização. 
 O método tem de indicar atividades com suas dependências, trabalhadores, artefatos de 
insumo e resultantes. Deve-se descrever a forma de utilização do método, e, para cada 
usuário, descrever as atividades que resolvem os requisitos mostrados neste catálogo. Assim 
o gerente da qualidade tem como inserir estas atividades no processo de desenvolvimento de 
software da empresa para que a utilização do método seja integrado às outras tarefas do 
processo. 
Requisito 46. O método tem de indicar, caso exista, novos papeis para a aplicação do 
método. 
Requisito 47. O método tem de indicar, caso exista, dependências com atividades não 
definidas pelo método. Um apontamento para a definição da atividade deve ser feita. 
Por exemplo, caso o método exija a descrição e execução de casos de teste assim 
como definido pelo Processo Unificado, deve apontar para a descrição desta 
atividade no Processo Unificado. 
Requisito 48. O método pode trazer guias de implantação e customização, para facilitar 
sua implantação numa empresa. 
Fundamentação: Para se aplicar um método de rastreabilidade entre requisitos e código pode 
ser necessário a criação de novas atividades, artefatos e perfis no processo, o método 
apresentado por Eisenbarth e tal. (2003) é um exemplo. Caso isso ocorra, esses elementos 
devem estar bem articulados com o restante do processoda organização. O CMMI descrito 
por [Chrissis, 2007] na pág. 165, na prática genérica GP 3.1, estabelecer um processo 
definido, pede para que seja mantido uma descrição de um processo definido com suas 
tarefas bem costuradas entre si. 
3.8.2 Qualidade do método 
O gestor da qualidade tem de garantir que o método utilizado segue normas de qualidade 
estipuladas para a organização. Estas normas normalmente baseiam-se na ISO/IEC 9126. 
O método tem de satisfazer os requisitos de funcionalidade: 
Requisito 49. Adequação: O método tem de prover funcionalidades que satisfação os 
requisitos para cada uma das partes interessadas citadas neste artigo. 
Requisito 50. Acurácia: O método tem de manter ligações de rastreabilidade que sejam 
fieis à fundamentação do código. 
Requisito 51. Interoperabilidade: O método deve satisfazer os requisitos apresentados 
neste catálogo de integração com outras ferramentas. 
Requisito 52. Segurança: O método deve permitir o controle de acesso às ligações de 
rastreabilidade. 
 
Requisito 53. Conformidade: O método deve ser aderente às normas e modelos 
utilizadas pela organização, como por exemplo CMMI. 
O método tem de satisfazer os requisitos de confiabilidade: 
Requisito 54. Maturidade: O método tem de evitar produzir resultados incorretos para 
qualquer conjunto de códigos e requisitos que façam parte do seu escopo. 
Requisito 55. Tolerância à falha: O método deve permitir que sua implementação se 
mantenha funcional, mesmo com ocorrências de falhas. 
Requisito 56. Recuperabilidade: O método tem de permitir a recuperação de 
informações, caso ocorram falhas. 
Requisito 57. Robusteza: O método tem de suportar manter um grande número de 
ligações de rastreabilidade, assim como ser indiferente ao um grande volume de 
alterações no projeto. 
Requisito 58. Escalabilidade: O método tem de suportar o crescimento do número de 
ligações de rastreabilidade sem um aumento na dificuldade de sua manutenção. 
Requisito 59. Precisão adequada: O método tem de alcançar o nível de detalhe 
necessário de acordo com a parte envolvida. 
O método tem de satisfazer os requisitos de usabilidade: 
Requisito 60. Inteligibilidade: O método tem de satisfazer os requisitos de usabilidade 
para cada parte interessada mostrados neste catálogo. 
Requisito 61. Apreensibilidade: O método tem de ser permitir que as partes interessadas 
possam aprender a usá-lo. 
Requisito 62. Operacionabilidade: O método tem de permitir que as partes interessadas 
possam operá-los segundo os requisitos apresentados neste catálogo. 
Requisito 63. Relevância: O método tem de manter apenas as ligações de rastreabilidade 
de interesse das partes envolvidas. 
O método tem de satisfazer os requisitos de eficiência: 
Requisito 64. Comportamento Temporal: o método tem de, na sua utilização pelas 
partes interessadas, apresentar os resultados em tempos adequados. Estes tempos 
devem ser definidos pela equipe de qualidade de cada organização. 
Requisito 65. Utilização de recursos: o método tem de, na sua utilização pelas partes 
interessadas, utilizar um número apropriado de recursos. Esses números devem ser 
definidos pela equipe de qualidade de cada organização. 
O método tem de satisfazer os requisitos de manutenibilidade: 
Requisito 66. Analisabilidade: As ligações de rastreabilidade resultantes das operações 
feitas pelo método têm de permitir uma análise para diagnosticar deficiências ou falhas 
nas operações. 
 
Requisito 67. Modificabilidade: O método tem de permitir manutenções nas ligações de 
rastreabilidade para corrigir problemas nas operações, melhorias no resultado ou 
adaptações à alterações no ambiente. 
Requisito 68. Estabilidade: As ligações de rastreabilidade têm de ser imunes a efeitos 
inesperados devido às modificações no método. 
Requisito 69. Testabilidade: As ligações de rastreabilidade resultantes das operações do 
método têm de permitir sua validação. 
O método tem de satisfazer os requisitos de portabilidade: 
Requisito 70. Adaptabilidade: O método pode ser adaptável a diversas linguagens, 
ferramentas, e formas de armazenar requisitos. 
Requisito 71. Instalabilidade: O método deve poder ser implementado no ambiente no 
qual ele se propõe a funcionar. 
Requisito 72. Co-existência: o método tem de ser capaz de co-existir com outros 
métodos que o processo da organização adota e compartilhar artefatos com estes 
métodos. 
Requisito 73. Repetibilidade: Dado uma linha de base dos requisitos e uma linha de base 
do produto o método tem de gerar sempre o mesmo conjunto de ligações de 
rastreabilidade entre os requisitos e o código. 
 
Fundamentação: Como o método de rastreabilidade entre requisitos e código é um produto 
de software, os requisitos de qualidade que os gestores de qualidade devem observar são os 
listados na norma ISO 9126. 
4. Aspectos práticos e operacionais 
De acordo com os requisitos identificados para os métodos de rastreabilidade entre requisitos 
e código, os seguintes aspectos práticos e operacionais relacionados à sua definição e à sua 
utilização podem ser apontados e/ou sugeridos: 
 - Os métodos especializados em rastreabilidade com o código de software já 
existentes e que não cobrem todos os requisitos aqui mostrados podem e devem ser usados, 
em conjunto com outros métodos, numa composição articulada de um método mais 
abrangente. 
 - Os métodos que se propõe resolver a rastreabilidade entre requisitos e código 
devem mostrar como implementam cada um dos requisitos aqui mostrados. 
 - Diversos requisitos pedem formas diferentes de visualizações das rastreabilidade. 
Aconselhamos o uso de mecanismos de visualização gráfica, por permitirem inteligibilidade em 
uma consulta com um grande volume de informação. Um bom exemplo é o uso da grade de 
conceitos (Concept Lattice) proposto por Einsenbarth (2003). 
 
 - Mecanismos de gerência de configuração que reconhecem Unidades 
Computacionais e Cortes Funcionais ajudam bastante na implementação do método. Um 
exemplo é o método de gerência de configuração proposto por Nguyen et al. (2005). 
 - Uso de hipertextos são bem vindos nas integrações com ferramentas de trabalho, 
como o proposto por Munson (2005). 
 - O catálogo aqui apresentado cobre apenas uma parte do problema de 
rastreabilidade. Precisa ser complementado com requisitos para todos os outros tipos de 
rastreabilidade. A rastreabilidade horizontal entre Unidades Computacionais é especialmente 
importante. Também é necessário o vinculo do código com a rastreabilidade pré-
especificação de requisitos. 
 - A importância dos requisitos pode variar de acordo com o tamanho da organização 
e do nível de maturidade do processo por ela utilizada. 
 - Confrontar este catálogo com os métodos de rastreabilidade entre requisitos e 
código, pode fornecer um índice de aderência dos métodos com as necessidades das partes 
interessadas,e funcionar como critério objetivo na escolha de um método. 
 
5. Conclusão 
Apresentamos o catálogo de requisitos para métodos de rastreabilidade entre requisitos e 
código de software, do ponto de vista das partes interessadas, com a finalidade de contribuir 
no desenvolvimento de métodos mais eficazes: que ocultem sua complexidade de usuários que 
não precisam conhecê-la; que sejam focadas no uso, não na tecnologia. Este catálogo não é 
para ser usado apenas por pesquisadores e desenvolvedores de métodos, mas também por 
aqueles que montam os processos de desenvolvimento de software numa organização, que 
podem usar o catálogo como critério objetivo na escolha do método mais adequado à suas 
necessidades. 
 O catálogo não tem a pretensão de ser uma visão encerrada sobre o assunto, mas de 
ser um ponto de partida para a discussão dos requisitos básicos que possam tornar a 
rastreabilidade viável nas organizações. Assim, deve sofrer revisões periódicas com o avanço 
da discussão e mudanças tecnológicas. 
 Os principais requisitos vieram de modelos e normasde qualidade (modelo CMMI, 
especificação ISO/IEC 12207), observados do ponto de vista das partes interessadas. 
Acreditamos assim ter construído um catálogo funcional e confiável. 
 Mesmo sabendo que o escopo desse trabalho é bastante limitado, esperamos ter 
contribuído para o efetivo uso da rastreabilidade no desenvolvimento de software. 
 
Referências 
Antoniol, G., Caprile, B., Potrich, A., Tonella, P. (2000) "Design-code traceability for object-
oriented systems", Annals of Software Engineering 9, p. 35–58. 
 
Antoniol, G., Canfora, G., Casazza, G., De Lucia, A. e Merlo, E. (2002) "Recovering 
Traceability Links between Code and Documentation", IEEE Transactions on Software 
Engineering, volume 28, número10. 
Antoniol, G., Merlo, E., Guéhéneuc, Y., Sahraoui, H. (2005) “On Feature Traceability in 
Object Oriented Programs”, TEFSE’05 - Traceability in Emerging Forms of Software 
Engineering. 
Arnold, R. e Bohner, S. (1993) “Impact Analisys – Towards a Framework for Comparison”, 
International Conference Software Maintenance, p. 292-301. 
Caldiera, G.; e Basili, V.R. (1991) “Identifying and qualifying reusable software components” 
IEEE Computer, volume 24, número 2, Pag.:61 – 70 
Cleland-Huang, J. (2005) “Toward improved traceability of non-functional requirements”, 
proferido no 3o. International Workshop on Traceability in Emerging Forms of Software 
Engineering, em conjunto com Automated Software Engineering ASE 2005. 
CMMI Product Team (2006) “CMMI for Development, Version 1.2”, Software Engineering 
Institute of Carnegie Mellon University. 
Collard, M., Maletic e J., Marcus, A. (2002) "Supporting Document and Data Views of 
Source Code", Proceedings of the 2002 ACM symposium on Document engineering. 
Ebner, G., Kaindl, H. (2002) “Tracing All Around in Reengineering”, IEEE Software, volume 
19, número 3, páginas 70-77. 
Egyed, A., Grünbacher, P. (2002) "Automating Requirements Traceability: Beyond Record & 
Replay Paradigm", Conference on Automated Software Engineering, 2002. Proceedings. 
ASE 2002. 17th IEEE International. 
Eisenbarth, T., Koschke, R., Simon, D. (2003) "Locating Features in Source Code", IEEE 
Transactions On Software Engineering, volume. 29, número 3. 
Hoffmann, M., Kühn, N., Weber, M., Bitter, M. (2004) “Requirements for Requirements 
Management Tools”, 12o. IEEE International Requirements Engineering Conference. 
Fyson,, M. e Boldyreff, C. (1998) “Using Application Understanding to Support Impact 
Analysis”, Journal Software Maintenance – Research and Practice, volume 10, p.93-110. 
Gotel O. e Finkelstein C. (1994) “An analysis of the requirements traceability problem”, 
Proceedings of the First International Conference on Requirements Engineering (IEEE). 
Jacobson, I., Booch, G., Rumbaugh, J. (1999) “The Unified Software Development Process”, 
Addison Wesley, 1a edição. 
Jarke, M. (1998) “Requirements Tracing”, Communications of the ACM, volume 41, número 
12. 
Koncli, J. e Bergen, M. (1988) “Gibis: A Hypertext Tool for Exploratory Policy Discussion”, 
ACM Trans. Office Information System, volume 6, no. 4, p. 303-331. 
 
Munson, E., Nguyen, T. (2005) “Concordance, conformance, versions, and traceability”, 
Automated Software Engineering, Proceedings of the 3rd international workshop on 
Traceability in emerging forms of software engineering, pag. 62-66. 
Murphy, G e Sullivan, D. (1995) “Software reflexion models: bridging the gap between source 
and high-level models”, Proceedings of the 3rd ACM SIGSOFT symposium on 
Foundations of software engineering. 
Neumüller, C., Grünbacher, P. (2006) “Automating Software Traceability in Very Small 
Companies: A Case Study and Lessons Learned”, 21st IEEE International Conference on 
Automated Software Engineering (ASE'06). 
Nguyen, T., Munson, E., Boyland, J. (2005) “An infrastructure for development of object-
oriented, multi-level configuration management services”, Proceedings of the 27th 
international conference on Software engineering. 
Pan, Kai, Whitehead , E. James, Jr. e Ge, Guozheng (2005) “Textual and Behavioral Views 
of Function Changes”, Automated Software Engineering, Proceedings of the 3rd 
international workshop on Traceability in emerging forms of software engineering, Long 
Beach, California. 
Pinheiro, F., Goguen, J. (1996) “An object-Oriented Tool for Tracing Requirements”, IEEE 
Software, vol. 13, no. 2, p. 52-64. 
Pohl, k., (1996) “PRO- ART : Enabling Requirements Pre-Traceability”, IEEE International 
Requirements Engineering Conference. 
Ramesh, B., Stubbs, C. e Powers, T. (1997) “Requirements traceability: Theory and 
practice”, In: Annals of Software Engineering 3, p. 397–415. J.C. Baltzer AG, Science 
Publishers. 
Ramesh, B. e Dhar, V. (1992) “Supportin Systems Development Using Knowledge Captured 
During Requirements Engineering”, IEEE Trans. Software Eng., volume 9, no. 2, p.498-
510. 
Spence, I. e Probasco, L. (1998) “Traceability Studies for Managing Requirements with Use 
Cases” http://www.uml.org.cn/RequirementProject/pdf/traceability.pdf 
Turver, R. e Munro, M. (1994) “Na Early impact Analisys Techique for Software 
Maintenance”, Journal Software Maintenance – Research and Practice, volume 6, no. 1, 
p.35-52. 
Zhao, W., Zhang, L., Liu, Y., Sun, J., Yang, F. (2004) "SNIAFL: Towards a Static Non-
Interactive Approach to Feature Location", Proceedings of the 26th International 
Conference on Software Engineering (ICSE'04).