Os Processos Típicos da Engenharia de Requisitos – Parte 1

Fonte: Kotonya e Sommerville – Requirements Engineering – Processes and Techniques

ISBN 0-471-97208-8
Traduzido por Eduardo Marquioni
Segundo o IEEE1 um requisito é definido como:
1. Uma condição ou capacidade necessitada por um usuário para resolver um problema ou atingir um
objetivo.
2. Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema
para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade.
3. Uma representação documentada de uma condição ou capacidade como em (1) ou (2).
“O começo é a parte mais importante do trabalho.” – Platão
Geralmente os projetos de software são entregues com atraso, custo acima do estimado e não atendem às reais
necessidades do usuário final ou da Organização que está pagando por ele. As falhas em sistemas não são devidas ao
staff incompetente ou engenharia de software pobre; elas são conseqüência de problemas com os requisitos de
sistema.
Requisitos de sistema são as especificações dos serviços que o sistema deve prover, as regras e informações de
background que são necessárias para desenvolver o produto. O processo de engenharia de requisitos pode ser
descrito como um processo sistemático de 5 passos distintos: elicitação de requisitos2, análise e negociação de
requisitos, especificação de requisitos, modelagem do sistema, validação de requisitos, gerenciamento de requisitos.
O termo “engenharia” é aplicável por se tratar de processo prático e sistemático para identificação da melhor
solução.
A partir desta edição do InfoChoose, serão apresentados em linhas gerais as características dos 5 processos típicos
da Engenharia de Requisitos. Neste artigo, serão tratadas a Elicitação de Requisitos e a Análise e Negociação de
Requisitos.

1. Elicitação de Requisitos
A elicitação de requisitos corresponde a identificar junto aos clientes, usuários e outros envolvidos quais são os
objetivos do sistema ou produto, o que deve ser acompanhado, como o sistema ou produto se encaixa no contexto
das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia.
“A parte mais árdua na construção de um software consiste exatamente em identificar ’o que’ construir.
Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma
incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores.” – Fred
Brook
Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade:
• Problemas de escopo: os limites do sistema são geralmente definidos de forma incompleta, ou os
clientes/usuários especificam detalhes técnicos desnecessários que podem confundir (ao invés de
esclarecer) os objetivos gerais do sistema;
• Problemas de compreensão: os clientes/usuários:
• Não estão completamente certos das necessidades;
• Têm uma compreensão pobre das capacidades e limitações de seu ambiente computacional;
• Não possuem uma compreensão plena do domínio do problema;
• Têm problemas comunicando suas necessidades aos engenheiros de software;
• Omitem informações que julgam óbvias;
• Especificam requisitos conflitantes com necessidades de outros clientes/usuários;
• Especificam requisitos ambíguos ou instáveis;
• Problemas de volatilidade: os requisitos mudam o tempo todo.
“Fatos não deixam de existir porque são ignorados.” – Aldous Huxley
Para auxiliar a superar estes problemas, os engenheiros de sistema devem abordar os requisitos de maneira
organizada. Alguns passos são sugeridos para elicitação de requisitos:
• Avaliar a viabilidade técnica e de negócio para o sistema proposto;
 • Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos
organizacionais;
• Definir o ambiente técnico3 no qual o sistema será instalado;
• Identificar “regras de domínio4” que limitam a funcionalidade ou performance do sistema ou produto que
será construído;
• Definir um ou mais métodos de elicitação de requisitos5;
• Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de
vista;
• Identificar claramente a justificativa de existência para cada requisito registrado;
• Identificar requisitos ambíguos que serão candidatos a prototipação.
Os produtos de trabalho a criar como conseqüência das atividades de elicitação de requisitos irão depender do
tamanho do sistema ou produto que será construído. Para a maioria dos sistemas, estes produtos de trabalho incluem:
• As necessidades e viabilidade estruturadas;
• O limite de escopo do sistema ou produtos;
• Uma lista de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de
requisitos;
• Uma descrição do ambiente técnico do sistema;
• Uma lista de requisitos e as regras de domínio aplicáveis a cada um;
• Um conjunto de cenários de uso capazes de prover uma idéia do uso do sistema ou produto sob diferentes
condições de operação;
• Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos.
Cada um destes produtos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos.

2. Análise e negociação de requisitos

Com os requisitos elicitados, os produtos de trabalho citados anteriormente formam a base para a análise de
requisitos. Esta análise categoriza e organiza os requisitos em subconjuntos relacionados, explora o relacionamento
de cada requisito com todos os demais, examina consistência, omissão e ambigüidade dos requisitos e prioriza
requisitos com base nas necessidades dos clientes/usuários.
As seguintes questões devem ser respondidas para a análise de requisitos:
• Cada requisito é consistente com os objetivos gerais do sistema/produto?
• Todos os requisitos foram especificados no nível apropriado de abstração? Em outras palavras, algum
requisito está em um nível de detalhe técnico inapropriado para este estágio?
• O requisito é realmente necessário, ou ele representa uma característica que pode não ser essencial ao
objetivo do sistema?
• Não há requisitos ambíguos;
• Cada requisito tem atribuição? Em outras palavras, há uma fonte (geralmente um indivíduo específico)
apontada para cada requisito?
• Nenhum requisito conflita com os outros?
• Cada requisito é passível de desenvolvimento no ambiente técnico designado para o sistema/produto?
Não é raro os clientes e usuários solicitarem mais do que pode ser realizado. É também relativamente comum que
clientes ou usuários distintos solicitem requisitos conflitantes, argumentando que sua respectiva versão do requisito
“é essencial para nossas necessidades especiais”. O engenheiro de sistemas deve harmonizar estes conflitos através
de um processo de negociação. Clientes, usuários e stakeholders devem ser também questionados quanto à
priorização de requisitos e então discutirem eventuais conflitos na priorização. Os riscos associados a cada requisito
são identificados e analisados. Estimativas de alto nível do esforço de desenvolvimento devem ser realizadas para
avaliar o impacto de cada requisito no custo do projeto e tempo de entrega. Usando uma abordagem interativa, os
requisitos são eliminados, combinados e/ou modificados de forma que cada grupo obtenha uma média de satisfação.
1
Instituto de Engenharia Elétrica e Eletrônica
2
Elicitar requisitos = “levantar”, identificar requisitos.
3
P.EX. arquitetura computacional, sistema operacional, necessidades de telecomunicações, etc.
4
Características do ambiente de negócio que são específicas para o domínio da aplicação.
5
Entrevistas, reuniões com grupos envolvidos, etc