Requisitos de Métodos de Rastreabilidade entre os Requisitos

e o Código de Software
Pedro L. R. Leal Jr1
1
Departamento 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

compliance with their software requirements, don’t have a systematic use in
most companies. This is because existing methods so far failed to meet
stakeholders in all their needs [Neumüller et al., 2006] [Antoniol et al., 2005].
On that basis, we present here a list of requirements for methods of
traceability between requirements and code of software, from the point of
view of stakeholders. We hope thus to contribute to the development of more
effective methods: not seem complex to its users; covering the entire scope of
the needs of stakeholders; they are focused on the use, not 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. Os artigos de Cleland-
Huang et al. (2005) ou de Gotel (1994) são exemplos de formas de categorização destes
métodos. 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ões entre 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.

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)

Unidade Computacional Corte Funcional

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.
 Ligação de Rastreabilidade entre Requisito e
Requisito +IRR fundamenta Unidade Computacional
1..* 1..*
1..*

satisfaz

1..* +ICR
Unidade
Computacional
1..*

*
Composição de Unidade
Constructo
Computacional

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.
 * é realizado em * Ligação de Rastreabilidade entre
Requisito
Requisito e Corte Funcional
+colaboradores +realização
+codigo da realização
1
1 +satisfaz
define
+base
Requisito Não Requisito
1 1 +ICR
Funcional Funcional
Corte
Funcional

1..*
Unidade Computacional

Figura 3. Ligação de Rastreabilidade entre Requisitos e Corte Funcional.

Requisição de +gatilho gera +realização Ligação de Rastreabilidade entre Alteração e

Alteração Unidade Computacional
1 0..1
*

impacta alteração de requisito

+candidatos a alteração +removido

+adicionado +alterado
* +alterado * *
* *
Requisito
Unidade Computacional

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
1..*

Ligação de Rastreabilidade entre Requisito e Código

*
Ligação de Rastreabilidade entre Alteração e Ligação de Rastreabilidade Indireta
Unidade Computacional
entre Requisito e Código

Ligação de Rastreabilidade entre Ligação de Rastreabilidade entre Requisito e

Requisito e Corte Funcional Unidade Computacional

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.
 Requisito +IRR fundamenta Ligação de Rastreabilidade entre
Requisito e Código
1

satisfaz

+ICR 1
Item de Código de Rastreabilidade (ICR)

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.

Requisito +IRR fundamenta Ligação de Rastreabilidade entre

Requisito e Código
1

satisfaz

+ICR 2..*
Item de Código de Rastreabilidade (ICR)

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.

Requisito +IRR fundamenta Ligação de Rastreabilidade entre

Requisito e Código
2..*

satisfaz

+ICR 1
Item de Código de Rastreabilidade (ICR)

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.
- O método deve permitir que a ligação de rastreabilidade seja feita durante a atividade de
codificação.
- 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.
- 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.
- 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.
- 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].
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- O método tem de identificar as Ligações de Rastreabilidade e classifica-las quanto ao seu
tipo e âmbito.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- O método pode permitir que alterações concorrentes, mas complementares, em ligações de
rastreabilidade devam ser percebidas por seus executores, se possí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.
- 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
no CMMI (2006), Gerência de Configuração, página 114.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 e
o 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.
- 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

- 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.
- 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.
- 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.
- 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.
- 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.
- O método tem de indicar, caso exista, novos papeis para a aplicação do método.
- 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.
- 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 processo da 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:
- Adequação: O método tem de prover funcionalidades que satisfação os requisitos para cada
uma das partes interessadas citadas neste artigo.
- Acurácia: O método tem de manter ligações de rastreabilidade que sejam fieis à
fundamentação do código.
- Interoperabilidade: O método deve satisfazer os requisitos apresentados neste catálogo de
integração com outras ferramentas.
- Segurança: O método deve permitir o controle de acesso às ligações de rastreabilidade.
- 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:
- 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.
- Tolerância à falha: O método deve permitir que sua implementação se mantenha funcional,
mesmo com ocorrências de falhas.
- Recuperabilidade: O método tem de permitir a recuperação de informações, caso ocorram
falhas.
- 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.
- 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.
- 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:
- Inteligibilidade: O método tem de satisfazer os requisitos de usabilidade para cada parte
interessada mostrados neste catálogo.
- Apreensibilidade: O método tem de ser permitir que as partes interessadas possam aprender
a usá-lo.
- Operacionabilidade: O método tem de permitir que as partes interessadas possam operá-los
segundo os requisitos apresentados neste catálogo.
- 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:
- 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.
- 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:
- 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.
- 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.
- Estabilidade: As ligações de rastreabilidade têm de ser imunes a efeitos inesperados devido
às modificações no método.
- 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:
- Adaptabilidade: O método pode ser adaptável a diversas linguagens, ferramentas, e formas
de armazenar requisitos.
- Instalabilidade: O método deve poder ser implementado no ambiente no qual ele se propõe
a funcionar.
- 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.
- 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. Estes
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 normas de 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).