Os Processos Típicos da Engenharia de Requisitos –

Parte 2
Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques
ISBN 0-471-97208-8
Traduzido por Eduardo Marquioni
Na última edição do InfoChoose teve início uma série de artigos para apresentar em linhas gerais os 5
processos típicos da Engenharia de Requisitos. A parte 2 desta série trata os processos de Especificação de
Requisitos, Validação dos Requisitos e o Gerenciamento dos Requisitos.

1. Especificação de Requisitos
No contexto de software, o termo especificação tem significado diferente para diversas pessoas. Uma
especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático formal, uma
coleção de cenários de uso, um protótipo, ou qualquer combinação dos itens citados.
Embora seja sugerido às vezes o desenvolvimento e uso de templates padrão para especificação de requisitos,
com o argumento que isto conduz a uma representação de maneira mais consistente e compreensível, há
momentos em que existe a necessidade da criação de uma especificação mais “flexível”.
Para grandes sistemas, um documento escrito contendo linguagem natural combinada a modelos gráficos
pode ser a melhor abordagem. Para sistemas pequenos desenvolvidos em ambiente técnico conhecido pode
ser suficiente a utilização de cenários de uso.
A especificação do sistema é o produto final produzido pelos engenheiros de requisitos. Ela é usada como a
base para as engenharias de hardware, software e banco de dados, pois descreve funções e performance
requeridas de um sistema baseado em computação e as regras que irão guiar seu desenvolvimento. A
especificação limita cada elemento alocado ao sistema. A especificação do sistema também descreve a
informação (dados e controle) que é entrada e saída do sistema.

1.1. Modelagem do Sistema

Imagine que se deseja especificar todos os requisitos para a construção de uma cozinha. Deve-se saber as
dimensões da obra, localização das portas e janelas e todo o espaço disponível. Com isso é possível
especificar os gabinetes e demais utilitários, além de indicar onde eles estarão localizados. Contudo, para uma
especificação completa, seria necessária a criação de uma planta ou uma representação tridimensional que
exibisse a posição dos gabinetes e demais utilitários, a relação entre eles a fim de avaliar, por exemplo, a
eficiência do fluxo durante o trabalho (que é um requisito básico de toda cozinha).
São construídos modelos de sistema pela mesma razão da planta da cozinha. É importante avaliar a relação
entre os componentes de um sistema, para avaliar a “estética” do sistema.
O engenheiro de sistemas pode criar um template para modelo do sistema (que funcionará como a fundação
para as etapas seguintes do desenvolvimento) contendo: a interface com o usuário, entradas, funções e
controles do sistema, saídas, manutenção e teste.
Pode ser definida também uma estrutura hierárquica montada a partir de um diagrama de contexto, para
identificar os produtores externos de informação, consumidores externos da informação produzida pelo
sistema e todas as entidades que se comunicam através da interface ou executam manutenção e testes.

2. Validação de Requisitos
Os produtos de trabalho criados como conseqüência da engenharia de requisitos (uma especificação do
sistema e informações relacionadas) devem ser validados quanto à qualidade durante o passo de validação de
requisitos. Esta validação examina a especificação para garantir que todos os requisitos do sistema foram
estruturados de maneira não ambígua, que as inconsistências, omissões e erros foram apagados e corrigidos, e
que os produtos de trabalho estão em conformidade com os padrões estabelecidos para o processo, para o
projeto e para o produto.
O mecanismo primário de validação de requisitos é a revisão técnica formal. O time de revisão inclui os
engenheiros de sistema, clientes, usuários e outros stakeholders que examinam a especificação1 do sistema à
procura de erros de conteúdo ou interpretação, pontos onde pode ser necessário esclarecimento, perda de
informações, inconsistências (um dos maiores problemas da engenharia de grandes produtos), requisitos
conflitantes, ou requisitos irreais (de desenvolvimento impossível).
Embora a revisão para validação dos requisitos possa ser conduzida de qualquer maneira desde que possibilite
a descoberta de erros nos requisitos, é útil examinar cada requisito contra um check list. A seguir um pequeno
subconjunto do que pode ser questionado:
• Os requisitos estão estruturados claramente? Não há problemas de interpretação incorreta?

• A fonte (pessoa, regimento, documento, etc.) foi identificada? A estrutura final do requisito foi
examinada pela/contra a fonte original?

• O requisito está definido em termos quantitativos?

• Quais são os requisitos relacionados a cada um? Eles estão claramente identificados através de uma
matriz de referência cruzada ou outro mecanismo?

• O requisito viola alguma regra de domínio?

• O requisito é passível de teste? Se sim, podem ser especificados os testes para exercitar os requisitos
2
?

• O requisito é rastreável para qualquer modelo de sistema que seja criado?

• O requisito é rastreável para os objetivos gerais do produto/sistema?

• Os requisitos associados à performance, comportamento e características operacionais foram

estruturados claramente? Que requisitos parecem implícitos?

3. Gerenciamento de Requisitos
É necessário persistir as alterações de requisitos através de toda a vida do software; neste sentido, o
gerenciamento de requisitos corresponde ao conjunto de atividades que auxilia o time do projeto a identificar,
controlar e rastrear os requisitos, bem como as alterações nos requisitos em muitos momentos do projeto3.
Gerenciamento de Requisitos é o processo que gerencia mudanças nos requisitos de um sistema. Os requisitos
evoluem devido às mudanças no ambiente do sistema e conforme os clientes desenvolvem um melhor
entendimento de suas reais necessidades4.
Novos requisitos surgem e há alterações nos requisitos em todos os estágios do processo de desenvolvimento
do sistema. São comuns os casos em que mais de 50% dos requisitos são alterados antes que o sistema seja
posto em operação, o que causa sérios problemas para os desenvolvedores; para minimizar dificuldades, os
requisitos devem ser documentados e controlados. Quando não há controle de alterações, mudanças de baixa
prioridade podem ser implementadas antes que aquelas de alta prioridade, além de mudanças com alto custo
não serem necessariamente aprovadas. Um levantamento em mais de 4.000 empresas européias identificou
que uma das principais áreas problemáticas do desenvolvimento e produção de software era o gerenciamento
de requisitos dos clientes (internos e externos).
As principais preocupações de gerenciamento de requisitos são:
• Gerenciar mudanças nos requisitos acordados;

• Gerenciar os relacionamentos entre os requisitos;

• Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos ao

longo do sistema e do processo de engenharia de software.
As mudanças nos requisitos podem ser devidas a erros e confusão no processo de engenharia de requisitos,
design ou problemas de implementação. Novos requisitos podem surgir conforme os stakeholders
desenvolvem uma melhor compreensão do sistema. Normalmente, as alterações em requisitos são resultados
de alterações em circunstâncias externas (P.EX. novas leis ou regulamentações introduzidas no ambiente de
negócio).
Os requisitos não podem ser gerenciados de forma efetiva sem rastreabilidade. Um requisito é rastreável se
for possível identificar quem solicitou o requisito, porque o requisito existe, quais os requisitos relacionados e
como os requisitos se relacionam a outras informações como design de sistemas, implementações e
documentos do usuário. Estas informações são utilizadas para identificar todos os requisitos afetados por
mudanças propostas.
Boas práticas de gerenciamento de requisitos, como uma manutenção de dependências entre requisitos têm
benefícios em longo prazo, como maior satisfação do cliente e custos de desenvolvimento mais baixos. Uma
vez que os retornos não são imediatos, o gerenciamento de requisitos pode parecer uma despesa
desnecessária; contudo, sem a gerencia, a economia de curto prazo será devastada pelos custos em longo
prazo.
Os problemas com gerenciamento de requisitos geralmente significam que os clientes não ficarão satisfeitos
quando da entrega do produto. Gerenciamento de requisitos é essencialmente um processo de gerenciar
grandes quantidades de informação e garantir que elas serão entregues à pessoa certa no tempo certo.
Ferramentas de gerenciamento de requisitos podem prover facilidades como:
• Um sistema de banco de dados para armazenamento de requisitos;

• Análise de documento e facilidades de geração para ajudar a construir um banco de dados de

requisitos e auxiliar na criação dos documentos de requisitos;

• Facilidades de gerenciamento de mudanças que ajudam a garantir que as mudanças foram avaliadas
e cotadas corretamente;

• Facilidades de rastreabilidade que auxiliam os engenheiros de requisitos a encontrar dependências

entre requisitos.
Nas próximas edições do InfoChoose, serão melhor discutidos aspectos relativos ao Gerenciamento de
Requisitos: estabilidade e volatilidade, armazenamento, gerenciamento de alterações e rastreabilidade.
1
É muito recomendável que haja várias revisões de requisitos durante a especificação dos requisitos, para que sejam
validadas pequenas porções de especificação, garantindo que a atenção seja focada em aspectos específicos dos requisitos.
2
Estes testes são chamados de critérios de validação.
3
Segundo Pressman
4
Segundo Kotonya e Sommerville