Os Processos Típicos da Engenharia de Requisitos –

Parte 5
Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques
ISBN 0-471-97208-8
Tradução de Eduardo Marquioni
Finalizando a série de artigos da apresentação dos processos típicos da Engenharia de Requisitos, a parte 5
trata conceitos de Gerenciamento dos Requisitos/Gerenciamento de Alterações (Rastreabilidade de
Requisitos).
1. Rastreabilidade
Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no resto do sistema.
Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a
alteração afeta outros requisitos. Se a alteração é proposta enquanto o sistema está em implementação, o
impacto de alteração envolve verificar como a alteração afeta os requisitos, o design do sistema e sua
implementação. Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também
uma verificação adicional a fim de identificar como todos os stakeholders do sistema podem ser afetados pela
alteração.
Para conduzir este tipo de avaliação de impacto, informações sobre dependências de requisitos, razão do
requisito e sua implementação devem ser mantidas para complementar as informações do documento de
requisitos. Estas informações são chamadas usualmente de informações de rastreabilidade. Avaliações de
impacto de alteração dependem destas informações de rastreabilidade para encontrar os requisitos afetados
por uma proposta de alteração. Estas informações são classificadas em 4 tipos:
· Rastreabilidade “de – para trás”: links dos requisitos a suas fontes (outros documentos ou pessoas);
· Rastreabilidade “de – para frente”: links dos requisitos a seus componentes de design e implementação;
· Rastreabilidade “volta – para trás”: links dos componentes de design e implementação de volta para os
requisitos;
· Rastreabilidade “volta – para frente”: links de documentos (que precederam o documento de requisitos)
aos requisitos relevantes.
Potencialmente, isto cobre um volume muito grande de informação. Na prática, é impossível e caro coletar e
gerenciar todos os tipos de informação de rastreabilidade. Os gerentes do projeto devem definir políticas de
rastreabilidade identificando quais informações de rastreabilidade essenciais devem ser mantidas.
Na prática, as informações de rastreabilidade que são mais comumente mantidas são as rastreabilidades
“requisitos para requisitos” e “requisitos para design”.
A seguir, alguns dos diferentes tipos de rastreabilidade que podem ser instanciados:
Tipo de rastreabilidade Descrição
Requisitos – Fontes Link do requisito às pessoas ou documentos que especificaram o
requisito.
Requisitos – Razão Link do requisito com uma descrição de “porque” foi especificado. Pode
ser uma destilação de informações de várias fontes.
Requisitos – Requisitos Link do requisito com outros requisitos que sejam, de alguma maneira,
dependentes dele. Deve ser um link de “mão dupla” (“depende” e “é
dependente de”).
Requisitos – Arquitetura Link do requisito com os subsistemas onde estes requisitos estão
implementados. Particularmente importante se os subsistemas estiverem
sendo desenvolvidos por subcontratados diferentes.
Requisitos – Design Link do requisito com hardware ou componentes de software específicos
no sistema que são usados para implementar o requisito.
Requisitos – Interface Link do requisito com as interfaces de sistemas externos que serão
usados na provisão dos requisitos.
2. Tabelas de rastreabilidade
As tabelas de rastreabilidade mostram os relacionamentos entre requisitos ou entre requisitos e componentes
de design. As tabelas de requisitos devem ser definidas com o número dos requisitos destacados nas linhas e
colunas da tabela. Um exemplo simples para um sistema com 6 requisitos seria:
Depende de
 R1 R2 R3 R4 R5 R6
R1 X X
R2 X X
R3 X X
R4 X
R5 X
T6
Onde:
Linha: dependente de
Coluna: depende de
No exemplo, R1 é dependente de R3 e R4; R2 é dependente de R5 e R6, etc. Se for proposta uma alteração no
requisito R4, a leitura da coluna R4 aponta que R1 e R3 dependem de R4. Deve ser avaliado com isso o
impacto em R1 e R3 com relação à alteração proposta a R4.
A tabela de requisitos é gerenciável para um número pequeno de requisitos (P.EX. até 250). Quando a
quantidade de requisitos aumenta e a tabela fica com gerenciamento impossível podem ser usadas listas de
rastreabilidade. Estas listas são mais compactas que as tabelas, mas sua desvantagem é que não uma maneira
fácil de avaliar a inversa de uma relação (é necessária uma lista para “dependente de” e outra para “depende
de”):
Requisito Depende de
R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6
Embora não haja necessidade de um banco de dados de requisitos, é evidente que a navegação entre as
informações de rastreabilidade em um banco de dados de requisitos que mantenha informações de
relacionamentos de dependência N:N entre os requisitos é muito mais fácil.

3. Políticas de rastreabilidade
O problema fundamental em manter informações de rastreabilidade é o alto custo de coletar, analisar e manter a informação.
Normalmente as informações de rastreabilidade não são atualizadas, e se torna progressivamente menos útil, o que gera pouco
incentivo em atualizá-la: em pouco tempo é descartada e a análise de mudança é realizada informalmente.
É útil para as Organizações a definição de um conjunto de políticas de rastreabilidade sobre a informação que deve ser mantida.
Normalmente estas políticas incluem:
· A informação de rastreabilidade que será mantida (ver tabela abaixo);
· As técnicas, como as matrizes de rastreabilidade, que serão utilizadas para manter a rastreabilidade;
· Uma descrição dos pontos em que a informação de rastreabilidade deverá ser coletada durante a execução dos processos de
engenharia de requisitos e desenvolvimento de sistemas. Os papéis das pessoas responsáveis pela manutenção da informação de
rastreabilidade também devem ser definidos;
· Uma descrição de como manipular e documentar políticas de exceções, para quando as restrições de tempo tornarem
impossível implementar a política de rastreabilidade normal. Haverá sempre ocasiões em que as alterações nos requisitos
deverão ser realizadas sem uma primeira avaliação de todos os impactos de alteração e sem manter a informação de
rastreabilidade. A política de exceções deve definir como essas alterações serão sancionadas;
· O processo usado para garantir que a informação de rastreabilidade seja atualizada depois que a alteração for realizada. Este
processo deve cobrir tanto o caso normal quando o processo de exceção.
As políticas de rastreabilidade normalmente são definidas para cada projeto, pois envolvem identificar a informação que será
rastreada, como representar a informação de rastreabilidade, identificação do responsável pela coleta de informações de
rastreabilidade, etc. Some-se a isto o fato de projetos terem requisitos diferentes, ciclos de vida diferentes: a política definida
para um projeto pode não ser aplicável a outro. Alguns fatores que influenciam na especificação de políticas de rastreabilidade:
Fator Descrição
Número de requisitos Quanto maior o número de requisitos, maior a necessidade de políticas de rastreabilidade formais.
Contudo, uma rastreabilidade completa requisitos – design é impraticável sem apoio de ferramenta
para sistemas grandes, pois há muita informação para manter.
Ciclo de vida estimado para o Políticas de rastreabilidade mais compreensíveis devem ser definidas para sistemas que tenham um
sistema ciclo de vida longo.
Nível de maturidade da Políticas de rastreabilidade detalhadas são mais efetivas em termos de custos em Organizações que
Organização tenham um nível de maturidade alto. Organizações no nível de maturidade básico devem focar na
rastreabilidade mais simples (requisitos – requisitos).
Tamanho e composição do Com um time de projeto pequeno, pode ser possível avaliar impacto de alterações propostas sem
time de projeto informações de rastreabilidade estruturadas. Em times grandes são necessárias políticas formais.
Especialmente se os membros do time trabalham em sites diferentes.
Tipo de sistema Sistemas críticos como sistemas de controle tempo-real ou sistemas de segurança críticos
necessitam de políticas de rastreabilidade mais compreensíveis que sistemas não críticos.
Requisitos específicos do Alguns clientes podem especificar que informações de rastreabilidade especificas, que devem ser
cliente entregues como parte da documentação do sistema.
Embora as políticas de rastreabilidade estejam especificadas, é muito importante que elas sejam realistas: é tedioso e consome
tempo manter informações de rastreabilidade; se as políticas não podem ser implementadas, elas não são úteis.
Toda a informação relativa a rastreabilidade que seja relevante para um projeto deve ser disponibilizada de maneira
(relativamente) simples aos membros do projeto. Esta informação deve ser atualizada regularmente para se manter útil.
Pode ser criado um manual de rastreabilidade, que seria o registro formal utilizado para mostrar os componentes independentes,
ou não afetados por uma proposta de alteração em particular.
O gerente do projeto (ou o gerente de requisitos) deve trabalhar com os desenvolvedores para garantir que as mudanças nos
requisitos, design, etc. foram incorporadas no manual de rastreabilidade; deve revisar as políticas de rastreabilidade; deve avaliar
os desvios da política de rastreabilidade e garantir que toda informação será mantida no manual.
Esperamos que esta série sobre a Engenharia de Requisitos auxilie os profissionais interessados e/ou envolvidos no assunto. A
Choose Technologies coloca-se à disposição para esclarecimentos adicionais através de seu corpo de consultores.