1

Unidade 6
Gerência de Requisitos

Frequentemente os usuários propõem mudanças nos requisitos, que resultam de

uma combinação de fatores, tais como erros de requisitos, conflitos e inconsistências,
melhor entendimento por parte dos usuários de suas necessidades, problemas técnicos,
de cronograma ou de custo, mudança nas prioridades do cliente resultantes de mudanças
no ambiente de negócios, o aparecimento de novos competidores, mudanças
econômicas, mudanças na equipe e ainda mudanças no ambiente onde o software será
instalado, mudanças organizacionais ou legais.
Surge então, a necessidade de gerenciar as mudanças nos requisitos, sendo essa
uma atividade relevante do processo de engenharia de requisitos. A gerência de
requisitos diz respeito às atividades, procedimentos, processos e padrões que são usados
para gerenciar mudanças nos requisitos e tem como objetivos manter uma trilha destas
mudanças e garantir que as mudanças sejam feitas no documento de requisitos de forma
controlada e documentada. As principais preocupações da gerência de requisitos dizem
respeito a gerenciar mudança de requisitos acordados, gerenciar os relacionamentos
entre os requisitos e as dependências entre o documento de requisitos e outros
documentos produzidos durante o processo de engenharia de software e sistemas.
O impacto das mudanças propostas aos requisitos deve ser avaliado e quando
as mudanças forem aceitas, o projeto e implementação serão, então, modificados. Se as
mudanças não forem controladas, as alterações com baixa prioridade podem ser
implementadas antes das alterações de alta prioridade. Além disto, modificações com
custo alto, que não são realmente necessárias, podem ser aprovadas.
A gerência de requisitos é executada em paralelo com as demais atividades da
engenharia de requisitos e continua após a entrega da primeira versão do documento de
requisitos, uma vez que estes continuam a mudar durante o desenvolvimento e estas
mudanças devem ser gerenciadas.
 2

O processo de gerência de mudança de requisitos consiste em um conjunto de

atividades para identificar, relatar, analisar, avaliar custo, documentar e implementar
mudanças nos requisitos do software. São elas:
1. A solicitação de mudança é conferida para ver se é válida. Algumas vezes,
os clientes entendem mal os requisitos e sugerem mudanças desnecessárias;
2. Os requisitos que são diretamente afetados pelas mudanças são
descobertos;
3. As informações de rastreabilidade são usadas para encontrar os requisitos
dependentes que também podem ser afetados pela mudança;
4. As mudanças atuais que devem ser feitas aos requisitos são propostas. Deve
haver uma consulta aos clientes, neste estágio, para garantir que estejam
satisfeitos com a mudança;
5. Os custos da mudança são estimados. Esta estimativa deverá incluir o
esforço requerido paras efetuar a mudança bem como o tempo necessário.
A disponibilidade de recursos para implementar a mudança deve ser
considerada;
6. Negociações com clientes são organizadas para verificar se os custos das
mudanças propostas serão aceitos por eles. Neste estágio, pode ser
necessário voltar ao passo 4 para propor mudanças alternativas, se o cliente
sentir que a mudança proposta está muito cara. Alternativamente, o cliente
pode modificar a solicitação de mudança, de forma que todo o processo
deverá ser repetido.
7. A mudança é implementada. As emendas ao documento de requisitos são
feitas ou uma nova versão do documento é gerada. Esta mudança deverá
ser validada usando qualquer procedimento de verificação de qualidade.

Para garantir uma abordagem consistente, as organizações podem definir um

conjunto de políticas de gerência de mudança de requisitos, que cobre:
1. O processo de solicitação da mudança e as informações requeridas para
processar cada solicitação de mudança;
2. O processo usado para analisar o impacto e custos das mudanças bem como
as informações de rastreabilidade associadas;
 3

3. O membro da organização que considera formalmente as solicitações de

mudança: é importante ter um grupo "independente" que considere as
solicitações de mudanças e que possa tomar uma decisão objetiva sobre a
contribuição desta mudança para as metas gerais do sistema e a efetividade
do custo da mudança;
4. O suporte de software (se houver) para o processo de controle de mudança.

No entanto, requisitos não podem ser gerenciados efetivamente sem

rastreabilidade. Um requisito é rastreável se for possível descobrir quem sugeriu o
requisito, por que o requisito existe; que requisitos estão relacionados a ele e como os
requisitos relacionam-se com outras informações, tais como projeto, implementação do
sistema e documentação do usuário. As informações de rastreabilidade são usadas para
encontrar outros requisitos que podem ser afetados pelas mudanças propostas.

Durante o processo de gerência de mudança de requisitos, a definição de um

formulário é necessária para auxiliar na conservação da trilha de qual estágio o processo
está e para documentar formalmente a solicitação de mudança. Este formulário é
preenchido progressivamente à medida que a mudança toma forma através do processo.
O leiaute do formulário de solicitação de mudança depende de quão detalhado é o
processo adotado na organização e do suporte eletrônico ao mesmo. Algumas
informações são essenciais e devem ser incluídas, tais como:
1. resultado de cada estágio da análise de mudança;
2. datas que mostram quando uma atividade foi iniciada e quando é passada
para mais tarde;
3. responsável por cada atividade;
4. a situação da solicitação, que pode ser: "rejeitada", "sob consideração",
"aceita para implementação imediata", "aceita para implementação
posterior", etc;
5. comentário onde qualquer outra informação relevante possa ser incluída.

Obviamente, quando muitas mudanças de requisitos são propostas (uma

situação normal em grandes sistemas), existe a geração de um grande volume de
 4

informações de mudança, que deverá ser armazenado em um banco de dados de

requisitos e, se possível, as mudanças devem ser ligadas diretamente aos requisitos que
forem afetados por ela.
A gerência de mudança envolve a manipulação de grandes quantidades de
informação que passam por muitos indivíduos na organização. É necessário conservar a
trilha de quais mudanças foram propostas, quais foram implementadas, quais ainda
estão sob consideração, etc. O suporte efetivo de ferramentas pode beneficiar,
enormemente, todo o processo. Este suporte pode ser fornecido por ferramentas de
gerência de requisitos especializadas ou por ferramentas CASE que sejam projetadas
para esta finalidade. O problema geral com estas ferramentas é que possuem seu
próprio modelo implícito do processo de mudança. As organizações que adotam estas
ferramentas devem adaptar-se ao modelo. Além disto, estas ferramentas especiais são
muito caras e existem dificuldades para integrá-las com outras ferramentas CASE
usadas na organização. Por estas razões, as ferramentas de suporte a mudanças
especializadas são usadas, na maioria das vezes, em grandes organizações, tais como
companhias aeroespaciais que estão envolvidas em projetos muito grandes.

6.1 - Requisitos Estáveis e Voláteis

Embora as mudanças sejam inevitáveis, alguns requisitos são mais estáveis que
outros. Os requisitos estáveis dizem respeito à essência do sistema e seu domínio de
aplicação. Eles mudam mais devagar que os requisitos voláteis. Requisitos voláteis são
específicos para a instanciação do sistema em um ambiente particular e para um cliente
particular (Kotonya; Sommerville, 1998). Existem pelo menos quatro tipos de requisitos
voláteis:
• Requisitos mutáveis: são os requisitos que mudam em função de mudanças no
ambiente no qual o sistema opera. Por exemplo, os requisitos que calculam
deduções de taxas evoluem quando leis relativas à taxas sofrem mudanças;
• Requisitos emergentes: são os requisitos que não podem ser completamente
definidos quando o sistema é especificado, mas emergem quando o sistema é
projetado e implementado. Por exemplo, pode não ser possível especificar, com
antecedência, os detalhes de como a informação será exibida. Quando os clientes
 5

vêem exemplos de formas de apresentação possíveis, eles pensam em novas formas

que possam ser úteis para eles;
• Requisitos resultantes: são os requisitos baseados em suposições de como o
sistema será usado. Quando o sistema é colocado em uso, algumas destas suposições
poderão estar erradas. Os usuários se adaptarão ao sistema e encontrarão novas
formas de usar sua funcionalidade. Isto resultará em demandas dos usuários para
mudanças e modificações no sistema;
• Requisitos de compatibilidade: são os requisitos que dependem de outros
equipamentos ou processos. Quando estes equipamentos mudam, estes requisitos
também evoluem. Por exemplo, um instrumento do sistema, dentro de uma sala de
controle de uma estação de força, poderá ter que sofrer modificações quando um
novo tipo de exibição de informação for adicionado.

É uma boa prática de gerência de requisitos tentar antecipar prováveis mudanças

de requisitos. Para isto, deve-se classificar os requisitos de forma a identificar os mais
voláteis e então prever possíveis mudanças. Com estas informações, os desenvolvedores
do sistema podem projetá-los de forma que estes requisitos sejam implementados
através de componentes relativamente independentes. Quando as mudanças forem
solicitadas, sua influência no resto do sistema será minimizada.

6.2 - Identificação de requisitos e armazenamento

Um pré-requisito essencial para a gerência de requisitos é que cada requisito
deve ter algum tipo de identificação única. Embora isto possa parecer simples e óbvio,
um grande número de documentos de requisitos não identifica unicamente os requisitos
do sistema. Consequentemente, a gerência efetiva de requisitos é impossível.

A abordagem mais comum para a identificação dos requisitos é baseada em

uma numeração de acordo com o capítulo e seção do documento de especificação
de requisitos onde o mesmo está inserido. Desta forma, por exemplo, o sexto requisito
da segunda seção do capítulo 4 receberá o número 4.2.6. No entanto, existem dois
problemas com este estilo de identificação de requisitos:
 6

1. Não é possível designar um número único até que o documento de

especificação de requisitos esteja terminado. A organização em capítulos e
seções deve ser estável. Quando um requisito é elicitado, ainda não está claro
onde ele ficará no documento de requisitos. Ele, então, não poderá ter um
número e portanto, não poderá ser referenciado por outros requisitos.
2. Designar um identificador baseado em número de capítulos e seções
classifica implicitamente um requisito. Isto sugere que um requisito seja
relacionado de perto com outros requisitos que tenham identificadores
similares. Os leitores do documento podem ser induzidos a pensar que não
existem outros relacionamentos deste requisito com outros, que estejam em
outra parte do documento.

Existem algumas técnicas alternativas para a identificação dos requisitos. São

elas:
1. Renumeração Dinâmica: alguns editores de texto, onde usualmente são
criadas as versões iniciais do documento de requisitos, permitem a
renumeração automática de parágrafos e a inclusão de referências cruzadas.
É possível, portanto, designar um número para um requisito a qualquer
tempo. Quando o documento for reorganizado e novos requisitos forem
adicionados, o sistema conserva a trilha da referência cruzada, renumerando
automaticamente o requisito dependendo do capítulo, seção e posição dentro
da seção. Todas as referências do requisito são também renumeradas.
2. Identificação do registro no banco de dados: quando um requisito for
identificado, ele é imediatamente incluído em um banco de dados de
requisitos, recebendo um identificador único. Este identificador é usado em
todas as referências subsequentes ao requisito.
3. Identificação simbólica: requisitos podem ser identificados através de um
nome simbólico que é associado com o próprio requisito. Por exemplo, EFF-
1, EFF-2, EFF-3 podem ser usados para requisitos que se relacionem com a
eficiência do sistema. O problema com esta técnica é que, algumas vezes, é
difícil classificar requisitos e designar um nome mnemônico para ele.
 7

Um editor de texto, bem como algum aplicativo para desenho, é usado para criar
uma versão inicial do documento de requisitos. No entanto, os requisitos são
normalmente armazenados em um ou mais arquivos. Quando várias pessoas estão
envolvidas na escrita deste documento, deve existir alguma cópia master armazenada,
que é usada como uma cópia de referência para todos os envolvidos e que é distribuída
para os leitores e revisores do documento de requisitos. Mudanças feitas por diferentes
pessoas são periodicamente fundidas e uma nova versão master será criada.

As vantagens em armazenar os requisitos em um único documento é que todos

eles ficam armazenados juntos e, portanto, é fácil acessá-los e relativamente simples
produzir novas versões do documento de especificação de requisitos. Segundo Kotonya
(1998, p. 119), a maioria das organizações que produzem requisitos para sistemas
pequenos ou de tamanho médio, mantém seus requisitos desta forma.

No entanto, a partir de uma perspectiva de gerência de requisitos, existem

algumas desvantagens nesta abordagem:
• Informações sobre dependências entre requisitos (rastreabilidade) têm que ser
mantidas externamente;
• Os recursos disponíveis para pesquisa de requisitos são limitados aos do
editor de texto utilizado. Neste caso, não é fácil encontrar grupos de
requisitos que tenham características comuns;
• Não é possível ligar, eletronicamente, requisitos com mudanças que tenham
sido propostas;
• Qualquer controle de versão de requisitos tem que ser um controle de todo o
documento ou, pelo menos, em nível de capítulo.
• Não é possível navegar automaticamente entre os requisitos relacionados ou
entre representações diferentes de requisitos (por exemplo, a partir de uma
representação textual para um modelo do sistema).

Para fornecer estes recursos, os requisitos devem ser mantidos em um banco de

dados, com cada requisito representado como uma ou mais entidades do banco de
dados. Os recursos do banco de dados podem ser usados para ligar requisitos
 8

relacionados e é possível, normalmente, formular consultas bastante complexas para

identificar agrupamentos de requisitos. O banco de dados pode fornecer alguns recursos
para controle de versão, ou pelo menos, provisão para estes recursos serem
implementados. Bancos de dados incluem, normalmente, recursos para browsing e
geração de relatórios. Requisitos relacionados são ligados e scripts simples podem ser
desenvolvidos para decompor o banco de dados, extrair partes de um registro para cada
requisito e gerar um esqueleto do documento de requisitos.

Bancos de dados relacionais foram projetados para armazenar e gerenciar grande

número de registros com mesma estrutura e um número mínimo de ligações entre eles.
Um banco de dados de requisitos, no entanto, tem, relativamente, poucos registros
sendo que cada um deles possui muitas ligações, tais como, ligações para documentos,
arquivos texto e outros requisitos. Manter estas ligações em um banco de dados
relacional é possível, mas ineficiente, pois requer operações em várias tabelas
diferentes. Para um número grande de requisitos, este tipo de banco de dados pode ser
muito lento.

Os bancos de dados orientados a objetos foram desenvolvidos recentemente e

são, estruturalmente, mais adaptados para a gerência de requisitos. Eles são melhores
que os bancos de dados relacionais quando existem muitos tipos diferentes de entidades
a serem gerenciadas e onde há ligações diretas entre entidades diferentes dentro do
banco de dados. Eles permitem que tipos diferentes de informação sejam mantidos em
objetos diferentes e a gerência de ligações entre os objetos é bastante direta.

Os sistemas gerenciadores de bancos de dados (SGBDs) disponíveis variam

desde os instalados em PCs até SGBDs instalados em mainframes. No entanto, um
banco de dados para gerência de requisitos depende dos seguintes fatores:
1. A declaração de requisitos: requisitos podem ser expressos em uma mistura
de linguagem natural, modelos gráficos, expressões matemáticas, etc. Em
alguns casos, informações adicionais tais como fotografias podem ser
armazenadas. Se existe necessidade de armazenamento de mais tipos de
 9

dados do que simplesmente texto, um banco de dados com recursos de

multimídia pode ser usado;
2. número de requisitos: os requisitos para sistemas pequenos ou médios (até
1000) podem ser gerenciados usando bancos de dados comerciais para PC.
Sistemas maiores necessitam, normalmente, de um banco de dados projetado
para gerenciar um volume grande de dados rodando em um servidor
especializado.
3. A equipe de trabalho, a distribuição da equipe e o suporte
computacional: se os requisitos estão sendo desenvolvidos por uma equipe
distribuída de pessoas, a partir de diferentes organizações, será necessário
um banco de dados que forneça acesso remoto e multi-site. Se tipos
diferentes de computadores forem usados, uma solução baseada na Intranet,
que forneça acesso ao banco de dados de requisitos através de um sistema de
browsing WWW pode ser apropriado.
4. Uso de ferramentas CASE: ferramentas CASE de tipos diferentes podem
ser usadas nos demais estágios do processo de desenvolvimento. Se usarem
um banco de dados, deve-se usar o mesmo SGBD para a gerência de
requisitos.
5. Uso de banco de dados existente: se um banco de dados que suporte a
engenharia de software já estiver sendo usado, ele deve ser usado também
para a gerência de requisitos; se não, os custos relativos à compra de um
banco de dados para armazenar os requisitos, bem como treinamento devem
ser considerados.
 10

6.3 - Gerência de Mudança de Requisitos

A gerência de mudança diz respeito aos procedimentos, processos e padrões que
são usados para gerenciar mudanças nos requisitos do sistema. Ela garante que
informações similares sejam coletadas para cada mudança proposta e que um
julgamento geral seja feito sobre os custos e benefícios das mudanças propostas. Sem
uma gerência formal de mudança, é impossível garantir que as mudanças propostas para
os requisitos suportem as metas de negócio estabelecidas.

As mudanças nos requisitos são propostas, com freqüência pelos usuários e

resultam de uma combinação de fatores, tais como (Kotonya; Sommerville, 1998):
• Erros de requisitos, conflitos e inconsistências: quando os requisitos são
analisados e implementados, os erros e inconsistências emergem e devem ser
corrigidos. Estes problemas podem ser descobertos durante a análise e
validação de requisitos ou posteriormente, no processo de desenvolvimento;
• Evolução do conhecimento do sistema pelos clientes/usuários finais: à
medida que os requisitos forem sendo desenvolvidos, os clientes e usuários
finais desenvolvem um melhor entendimento do que necessitam realmente
do sistema;
• Problemas técnicos, de cronograma ou de custo: problemas podem ser
encontrados no projeto ou na implementação de um requisito. A
implementação de certos requisitos pode ser muito caro ou levar muito
tempo;
• Mudança nas prioridades do cliente: as prioridades podem mudar durante
o desenvolvimento do sistema como resultado de mudanças no ambiente de
negócios, o aparecimento de novos competidores, mudanças econômicas,
mudanças na equipe, etc
• Mudanças ambientais: o ambiente no qual o sistema será instalado pode
mudar de forma que os requisitos do sistema têm que mudar para manter a
compatibilidade; além disto, novas informações sobre o ambiente do sistema
podem se tornar disponíveis; por exemplo, novos mapas digitais para sistemas
de informações geográficas.
 11

• Mudanças organizacionais: a organização que pretende usar o sistema pode

sofrer mudanças em sua estrutura e processos, resultando em novos
requisitos do sistema.
• Mudanças legais: alterações ou criações de novas leis e/ou regulamentações.
Neste sentido, pode-se dizer que "a gerência de requisitos é um processo
político e não técnico" (Andriole98).

Surge então, a necessidade de gerenciar as mudanças nos requisitos, sendo essa

uma atividade relevante do processo de engenharia de requisitos. A gerência de
requisitos é o processo de gerenciar mudanças nos requisitos e tem como objetivos
manter uma trilha destas mudanças e garantir que as mudanças sejam feitas no
documento de requisitos de forma controlada e documentada.

Uma pesquisa recente na Europa em 4000 companhias mostrou que a gerência

de requisitos é um dos principais problemas no desenvolvimento e produção de software
(Kotonya; Sommerville, 1998). Estes problemas não estão confinados à gerência de
requisitos de clientes externos. Também existem problemas na gerência de mudança de
requisitos quando o sistema foi especificado e desenvolvido na mesma organização.

Para garantir uma abordagem consistente para a gerência de mudança, as

organizações podem definir um conjunto de políticas de gerência de mudança, que
cobrem:
5. O processo de solicitação da mudança e as informações requeridas para
processar cada solicitação de mudança;
6. O processo usado para analisar o impacto e custos das mudanças bem como
as informações de rastreabilidade associadas;
7. O membro da organização que considera formalmente as solicitações de
mudança: é importante ter um grupo "independente" que considere as
solicitações de mudanças e que possa tomar uma decisão objetiva sobre a
contribuição desta mudança para as metas gerais do sistema e a efetividade
do custo da mudança;
8. O suporte de software (se houver) para o processo de controle de mudança.
 12

6.3.1 - O Processo de Gerência de Mudança de Requisitos

O processo de gerência de mudança de requisitos consiste em um conjunto de
atividades para documentar, relatar, analisar, avaliar custo e implementar mudanças nos
requisitos do sistema. Ele pode ser pensado como um processo de três estágios como
mostrado na figura 1 abaixo:

Problema
Análise do problema Análise da Implementação
identificado
e especificação da mudança e da mudança
mudança do custo Requisitos
revisados

Figura 1 - Estágios do processo de gerência de mudança de requisitos

Fonte: Kotonya; Sommerville, 1998.

Alguns problemas nos requisitos são identificados. Esses podem surgir a partir de uma
análise de requisitos, de novas necessidades dos usuários ou de problemas operacionais
com o sistema. Os requisitos são analisados usando a informação do problema e as
mudanças de requisitos são propostas.
1. As mudanças propostas são analisadas para verificar quantos requisitos (e se
necessários, quantos componentes do sistema) são afetados pela mudança e,
aproximadamente, qual o custo da mudança em termos financeiros e de tempo.
2. A mudança é implementada. As emendas ao documento de requisitos são feitas ou
uma nova versão do documento é gerada. Esta mudança deverá ser validada usando
qualquer procedimento de verificação de qualidade.
 13

Os processos específicos para análise do problema e implementação da mudança

são dependentes do tipo de mudança, dos requisitos afetados e do tipo de documento de
requisitos. No entanto, a análise de mudança e de custo é um processo mais geral, como
mostrado na figura 2.

requisito
rejeitado
solicitação
Conferir Encontrar Encontrar
mudança
vigência do requisitos dependências
requisito requisito diretamente Lista de
válido afetados requisitos

Lista de mudança de requisitos

solicitação
rejeitada
mudança informação
Propor Avaliar Avaliar
requisitos de custo
mudanças custos da aceitabilidade informação
nos mudança do custo de custo
requisitos
solicitação
solicitação rejeitada
rejeitada

Informação Informação
do cliente do cliente

Figura 2 - Processo de Análise de Mudança e de Custo

Fonte: Kotonya; Sommerville, 1998.

Existem 6 atividades básicas no processo de análise de mudança e de custo:

1. A solicitação de mudança é conferida para ver se é válida. Algumas vezes, os
clientes entendem mal os requisitos e sugerem mudanças desnecessárias;
2. Os requisitos que são diretamente afetados pelas mudanças são descobertos;
3. As informações de rastreabilidade são usadas para encontrar os requisitos
dependentes que podem ser afetados pela mudança;
 14

4. As mudanças atuais que devem ser feitas aos requisitos são propostas. Deve
haver uma consulta aos clientes, neste estágio, para garantir que estejam
satisfeitos com a mudança;
5. Os custos da mudança são estimados. Esta estimativa deverá incluir o esforço
requerido paras efetuar a mudança bem como o tempo necessário. A
disponibilidade de recursos para implementar a mudança deve ser considerada;
6. Negociações com clientes são organizadas para verificar se os custos das
mudanças propostas serão aceitas por eles. Neste estágio, pode ser necessário
voltar ao passo 4 para propor mudanças alternativas, se o cliente sentir que a
mudança proposta está muito cara. Alternativamente, o cliente pode modificar a
solicitação de mudança, de forma que todo o processo deverá ser repetido.

A solicitação de mudança pode ser rejeitada em três estágios do processo:

• Se a solicitação de mudança for inválida: isto normalmente acontece quando
o cliente não entendeu bem alguma coisa sobre os requisitos e propôs uma
mudança que não é necessária;
• Se a solicitação de mudança resultar em alterações que não são aceitas pelo
usuário: por exemplo, uma solicitação de mudança para diminuir o tempo de
resposta de uma transação pode significar que poucas transações
concorrentes poderão ser manipuladas;
• Se a implementação da mudança for muito cara ou levar muito tempo.

Durante o processo de gerência de mudança, informações sobre a mudança e

sobre o sistema são passadas para diferentes pessoas. A definição de um formulário é
necessária para auxiliar na conservação da trilha de qual estágio o processo está e para
documentar formalmente a solicitação de mudança. Este formulário é preenchido
progressivamente à medida que a mudança toma forma através do processo.

A organização de um formulário de solicitação de mudança depende de quão

detalhado é o processo adotado na organização e do suporte eletrônico do processo de
gerência de mudança. Alguns campos são essenciais e devem ser incluídos em todos os
formulários de solicitação de mudança:
 15

1. Campos para documentar o resultado de cada estágio da análise de mudança;

2. Campos de datas que mostram quando uma atividade foi iniciada e quando é
passada para mais tarde;
3. Campos que mostram quem é responsável por cada atividade;
4. Um campo de estado geral que assume valores tais como "rejeitado", "sob
consideração", "aceito para implementação imediata", "aceito para
implementação posterior", etc.
5. Um campo para comentário onde qualquer outra informação relevante possa
ser incluída.

Obviamente, quando muitas mudanças de requisitos são propostas (uma situação

normal em grandes sistemas), existe a geração de um grande volume de informações de
mudança, que deverá ser armazenado em um banco de dados de requisitos e, se
possível, as mudanças devem ser ligadas diretamente aos requisitos que forem afetados
por ela.

6.3.2 - Ferramentas de Suporte à Gerência de Mudança

A gerência de mudança envolve a manipulação de grandes quantidades de
informação que passam por muitos indivíduos na organização. É necessário conservar a
trilha de quais mudanças foram propostas, quais foram implementadas, quais ainda
estão sob consideração, etc. O suporte efetivo de ferramentas pode beneficiar,
enormemente, todo o processo.

O suporte para a gerência de mudança de requisitos pode ser fornecido por

ferramentas de gerência de requisitos especializadas ou por ferramentas CASE que
sejam projetadas para esta finalidade. Os recursos que estas ferramentas devem
apresentar são:
1. Formulários eletrônicos de solicitação de mudança que serão preenchidos
pelos diferentes participantes do processo;
2. Um banco de dados para armazenar e gerenciar estes formulários;
 16

3. Um modelo de mudança que pode ser instanciado de forma que a pessoa

responsável por um estágio do processo saiba quem é responsável pela
próxima atividade do processo;
4. Uma transferência eletrônica de formulários entre pessoas com
responsabilidades diferentes e notificação eletrônica de correios quando as
atividades forem completadas.
5. Em alguns casos, ligações diretas com um banco de dados de requisitos. Em
alguns casos, isto pode suportar a manutenção de múltiplas versões de um
requisito com a informação de mudança, indicando por que novas versões
de requisitos foram derivadas. Somente as ferramentas mais sofisticadas
fornecem esta funcionalidade.

O problema geral com estas ferramentas é que possuem seu próprio modelo
implícito do processo de mudança. As organizações que adotam estas ferramentas
devem adaptar-se ao modelo. Além disto, estas ferramentas especiais são muito caras e
existem dificuldades para integrá-las com outras ferramentas CASE usadas na
organização. Por estas razões, as ferramentas de suporte a mudanças especializadas são
usadas, na maioria das vezes, em grandes organizações, tais como companhias
aeroespaciais que estão envolvidas em projetos muito grandes.

Ferramentas de objetivo geral, tais como processadores de texto, planilhas e

sistemas de correio eletrônico podem ser usadas para implementar um sistema de
gerência de mudança mais limitado. O estado de todas as mudanças, por exemplo, pode
ser sumarizado em uma planilha, com os arquivos do processador de texto usados para
armazenar as informações de gerência da mudança. O processo de gerência de mudança
deve especificar uma localização padrão para armazenamento da documentação da
mudança e mensagens de correio eletrônico devem ser usadas para notificar os
participantes do processo, sempre que um estágio, dentro de uma atividade, for
completado. Além disto, todas as informações podem estar disponíveis via Intranet.
 17

6.4 - Rastreabilidade
Uma parte crítica do processo de gerência de mudança de requisitos é a
avaliação do impacto de uma mudança no resto do sistema. Se uma mudança é proposta
enquanto os requisitos estão sendo desenvolvidos, deve-se avaliar como esta mudança
afeta outros requisitos. Se uma mudança é proposta durante a implementação do
sistema, a avaliação do impacto envolve avaliar como a mudança afeta os requisitos, o
projeto do sistema e sua implementação. Se uma mudança é proposta após a
implantação do sistema, haverá também uma avaliação de como todos os clientes do
sistema poderão ser afetados pela mudança.

Para executar este tipo de avaliação de impacto, deverão ser mantidas

informações sobre as dependências dos requisitos, sua razão e sua implementação, de
forma a completar as informações do documento de requisitos. Isto é chamado,
normalmente, de informações de rastreabilidade. As avaliações de impacto da mudança
dependem de informações de rastreabilidade para descobrir que requisitos são afetados
pela mudança proposta (Kotonya; Sommerville, 1998).

A Rastreabilidade fornece a base para o desenvolvimento de uma trilha de

auditoria para todo o projeto através do estabelecimento de ligações dentro e entre as
entidades do sistema, funções, comportamento e desempenho, por exemplo (Palmer,
1997).

Davis, citado por Kotonya (1998, p. 128) classificou as informações de

rastreabilidade em 4 tipos:
1. Rastreabilidade backward-from: liga os requisitos com suas fontes, que podem ser
pessoas ou outros documentos;
2. Rastreabilidade forward-from: liga os requisitos com os componentes de projeto e
de implementação;
3. Rastreabilidade backward-to: liga os componentes de projeto e de implementação
com os requisitos (fase anterior);
4. Rastreabilidade forward-to: liga outros documentos (que podem ser precedido o
documento de requisitos) com os requisitos relevantes.
 18

A rastreabilidade é essencial para verificação e validação; um melhor

entendimento dos processos usados para desenvolver o sistema e os produtos que
resultam; acesso rápido à informação, abstração da informação e para fornecer
visualização dentro de técnicas usadas para desenvolvimento do sistema e controle de
mudança, controle do processo de desenvolvimento e controle de risco Além disto, a
rastreabilidade fornece percepção para componentes não comportamentais, tais como
qualidade, consistência, completeza, análise de impacto, evolução do sistema e melhoria
do processo. Ela também suporta detecção de conflitos através do exame fácil de
ligações dentro e entre entidades selecionadas e através da visibilidade fornecida dentro
de todo o sistema, bem como garante que decisões tomadas mais tarde no ciclo de vida
de desenvolvimento são consistentes com decisões mais antigas (Palmer, 1997).

Na prática, é muito caro coletar e gerenciar todos os tipos de informação de

rastreabilidade. Os gerentes de projeto devem definir as políticas de rastreabilidade que
declarem que informações devem ser mantidas.
 19

Kotonya e Sommerville (1998, p. 130) definem diferentes tipos de

rastreabilidade, que podem ser instanciados através de ligações entre informações
específicas no documento de requisitos e outros documentos do sistema, como mostra a
figura 3.

TIPOS DE DESCRIÇÃO
RASTREABILIDADE
requisito-fonte Liga o requisito e a pessoa ou documentos que especificaram
o requisito
requisito-razão Liga o requisito com uma descrição do porquê do requisito
ser especificado.
requisito-requisito Liga requisito com outros requisitos que são, de alguma
forma, dependentes. Pode ser uma ligação de duas vias
(dependente e ser dependente de)
requisito-arquitetura Liga o requisito com os sub-sistemas onde foram
implementados. É importante quando sub-sistemas estão
sendo desenvolvidos por diferentes contratados.
requisito-projeto Liga requisito com componentes de hardware e software
específicos do sistema, que serão usados para implementar o
requisito
requisito-interface Liga requisito com as interfaces de sistema externas que
serão usadas na provisão do requisito.

Figura 3 - Tipos de Rastreabilidade

Fonte: Kotonya; Sommerville, 1998.

Na prática, as informações de rastreabilidade mais comumente mantidas durante

a fase de gerência de requisitos são dos tipos requisito-requisito e requisito-projeto.
 20

6.4.1 - Tabelas de Rastreabilidade

As tabelas de rastreabilidade mostram o relacionamento entre requisitos ou entre
requisitos e componentes de projeto. Os requisitos são listados ao longo de eixos
horizontais e verticais e os relacionamentos entre os requisitos são assinalados nas
células da tabela, conforme figura 4.

depende de
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6

Figura 4 - Tabela de Rastreabilidade Simples

Fonte: Kotonya; Sommerville, 1998.

As tabelas de rastreabilidade devem ser definidas com os números dos

requisitos, que são usados para nomear as linhas e colunas da tabela. Assim, por
exemplo, se um requisito na linha X depende de requisitos das colunas P, Q e R, as
células (X,P), (X,Q) e (X,R) devem ser assinaladas. Dado um requisito Rx em uma
determinada linha , a leitura horizontal mostra todos os requisitos que o requisito Rx
depende. Dado um requisito Rx em uma determinada coluna , a leitura vertical mostra
todos os requisitos dependentes do requisito Rx.

Na tabela acima, se uma mudança for proposta para o requisito R4, a leitura
vertical da coluna R4 mostra que os requisitos R1 e R3 são dependentes de R4 e,
portanto, o impacto da mudança nos requisitos R1 e R3 deve ser avaliado.

Se um número relativamente pequeno de requisitos deve ser gerenciado (até

250) a tabela de rastreabilidade pode ser implementada através de uma planilha. No
 21

entanto, como estas planilhas podem se tornar grandes e esparsamente populadas, os

requisitos podem ser agrupados e as tabelas de rastreabilidade podem ser criadas para
estes grupos. Outra solução é criar uma lista de rastreabilidade, conforme figura 5.

Requisito Depende de
R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6

Figura 5 - Lista de Rastreabilidade

Fonte: Kotonya; Sommerville, 1998.

A desvantagem desta lista, se comparada com a tabela de rastreabilidade, é que

não é fácil avaliar que requisitos são dependentes de um determinado requisito. Será
preciso construir uma lista específica para este caso.

6.4.2 - Políticas de Rastreabilidade

O problema fundamental na manutenção das informações de rastreabilidade é o
alto custo de coletar, analisar e manter estas informações. Existe um alto custo
envolvido na avaliação das dependências, bem como para atualizar estas informações
cada vez que uma mudança é feita em um requisito. Quando os projetos estão sendo
desenvolvidos com um cronograma de tempo apertado, outros trabalhos têm, algumas
vezes, uma prioridade maior. Frequentemente, as informações de rastreabilidade não
são atualizadas. Desta forma, a informação se torna, progressivamente, menos útil, e
haverá menor incentivo para seu uso e para manutenção da atualização. Dentro de
pouco tempo, será descartada e a análise de mudança será feita informalmente.

Para auxiliar os responsáveis pela gerência de requisitos, é útil que a organização

mantenha um conjunto de políticas de rastreabilidade que dispõe sobre as informações
 22

de rastreabilidade a serem mantidas. Estas políticas, normalmente, incluem os seguintes

pontos:
1. Tipos de informação de rastreabilidade que serão mantidas;
2. As técnicas, tais como matrizes de rastreabilidade, que deverão ser usadas
para manter a rastreabilidade;
3. A descrição de quando as informações de rastreabilidade devem ser
coletadas durante a engenharia de requisitos e os processo de
desenvolvimento do sistema. Os papéis das pessoas, tais como gerente de
rastreabilidade, devem também ser definidos;
4. Uma descrição de como manipular e documentar exceções à política, por
exemplo, quando restrições de tempo tornarem impossível implementar a
política de rastreabilidade normal. Sempre haverá ocasiões onde as
mudanças nos requisitos ou no sistema deverão ser feitas sem uma primeira
avaliação de todos os impactos da mudança e sem manutenção das
informações de rastreabilidade. Estas exceções à política devem definir como
estas mudanças deverão ser sancionadas;
5. O processo usado para garantir que as informações de rastreabilidade sejam
atualizadas após as mudanças serem feitas. Este deverá cobrir tanto o
processo de mudança normal quanto o excepcional.

As políticas de rastreabilidade usadas devem ser especializadas para cada

projeto, de forma a omitir alguma informação de rastreabilidade, decidir como as
informações de rastreabilidade devem ser representadas, decidir as responsabilidades
sobre esta coleção de informações, etc. Projetos (e clientes) têm requisitos e ciclos de
vida diferentes e as políticas de rastreabilidade para um sistema de informação simples,
projetado para uso interno, podem ser completamente diferentes das políticas para um
sistema crítico.
Alguns fatores influenciam na especialização das políticas de rastreabilidade,
conforme abaixo:
1. Número de requisitos: quanto maior o número de requisitos, maior a
necessidade de políticas de rastreabilidade formais. No entanto, uma
rastreabilidade do tipo requisito-projeto é impraticável para grandes
 23

sistemas, pois haverá uma quantidade de informações muito grande para

manter. Se for este o caso, deve-se ser realista e limitar as informações de
rastreabilidade que serão mantidas;
2. Tempo de vida estimado do sistema: políticas de rastreabilidade mais amplas
devem ser definidas para sistemas que tenham uma vida mais longa;
3. Nível de maturidade organizacional: políticas de rastreabilidade detalhadas
são, provavelmente, mais efetivas em organizações que têm um alto nível de
maturidade no processo. Organizações no nível de maturidade básica devem
focar na rastreabilidade do tipo requisito-requisito.
4. Tamanho e composição da equipe do projeto: com uma equipe pequena, é
possível avaliar o impacto das mudanças propostas sem informações
estruturadas de rastreabilidade. Com equipes grandes, no entanto, políticas
de rastreabilidade mais formais são necessárias. Isto é verdade, em
particular, se os membros da equipe trabalham em locais diferentes.
5. Tipo de sistema: sistemas críticos tais como sistemas de controle de tempo-
real ou sistemas de segurança críticos necessitam de políticas de
rastreabilidade mais amplas do que sistemas não críticos.
6. Requisitos específicos do cliente: alguns clientes podem especificar que as
informações específicas de rastreabilidade sejam entregues como parte da
documentação do sistema.

Qualquer política de rastreabilidade é específica, e é muito importante que seja

realista. A manutenção das informações de rastreabilidade é tediosa, consumidora de
tempo e de trabalho intensivo. Políticas mais amplas podem ser melhores em princípio,
mas se não puderem ser implementadas no momento, não terão utilidade. Políticas mais
leves que todas as pessoas podem executar e usar são melhores que as mais amplas que
não possam ser implementadas.

Uma forma de gerenciar a rastreabilidade é desenvolver um manual de

rastreabilidade como um suplemento do documento de requisitos. Ele conservará, em
um mesmo local, todas as informações de rastreabilidade que são relevantes para o
projeto, que forma que os membros da equipe possam, facilmente, encontrar as
 24

informações de rastreabilidade que necessitam. Sua manutenção é particularmente

importante para sistemas críticos. Ele é um registro formal, que poderá ser usado para
mostrar que componentes são independentes ou não são afetados por alguma mudança
proposta.

As informações de rastreabilidade devem ser regularmente atualizadas para que

possam permanecer úteis. Esta tarefa é de responsabilidade do gerente de
rastreabilidade. Deve ser implementado como um documento eletrônico em rede, ao
invés de ser em papel, para que os engenheiros de requisitos possam sempre tê-lo
atualizado.

6.5 - Diretrizes Gerais

Sabe-se que a atividade de gerência de requisitos é bastante complexa e que
algumas questões não são consideradas. No entanto, de forma genérica, a gerência de
requisitos pode ser implementada através da adoção das seguintes diretrizes
(Sommerville, 1997):
1. Identificar unicamente cada requisito;
2. Definir políticas para a gerência de requisitos;
3. Definir as políticas para rastreabilidade;
4. Manter um manual de rastreabilidade;
5. Usar um banco de dados para gerenciar requisitos;
6. Definir políticas para gerência de mudança;
7. Identificar os requisitos de sistema globais;
8. Identificar os requisitos voláteis;
9. Armazenar os requisitos rejeitados.

Uma vez que a mudança nos requisitos ocorre enquanto estão sendo elicitados,
analisados, validados, projetados, implementados ou mesmo após o sistema ter sido
implantado, torna-se necessária a adoção de um processo de gerência de requisitos
efetivo, de forma a contribuir para a melhoria da qualidade do processo de engenharia
de requisitos e, em conseqüência, do processo de desenvolvimento de software.