1 2

e requisitos estabelecidos no início da fase ou em uma fase anterior (Collofello, 1988,

Unidade 5
IEEE, 1990, Paulk et al., 1993b, Thayer & Thayer, 1997, Wallace & Ippolito, 1997) e
Validação de Requisitos busca responder à seguinte questão (Boehm citado por Pressman, 2000, Jacobson et al.,
1992): está-se construindo o sistema de forma correta? Na Engenharia de Requisitos,
a verificação avalia se a ERS está sendo construída de forma correta, de acordo com
padrões previamente definidos, sem conter requisitos ambígüos, incompletos (Kotonya
A Validação de Requisitos diz respeito à verificação do documento de
& Sommerville, 1998) ou, ainda, requisitos incoerentes ou impossíveis de serem
requisitos em relação à consistência, completeza e acurácia para que se possa certificar
testados (Rocha et al., 2001).
de que os requisitos representam uma descrição aceitável do sistema que será
Na Engenharia de Requisitos, a verificação e validação são executadas, de
implementado.
forma geral, pelos clientes, usuários, especialistas de domínio, engenheiros de
Este processo deve envolver os usuários do sistema, os especialistas de
requisitos, gerentes do projeto, projetistas do software e pelos gerentes de testes (Paulk
domínio, os engenheiros de requisitos e projetistas do sistema que analisam os
et al., 1993b, Kotonya & Sommerville, 1998). O modelo CMM - Capability Maturity
requisitos em busca de problemas, omissões, inconsistências, incompletezas e
Model (Paulk et al., 1993b) e o padrão ISO/IEC TR 15504 (SPICE, 1998) definem a
ambigüidades.
verificação e a validação como atividades que fazem parte da garantia de qualidade do
Na literatura pesquisada (Collofello, 1988, IEEE, 1990, Ghezzi et al., 1991,
software e, sendo assim, devem ser executadas também, de forma independente, pelo
Jacobson et al., 1992, Davis, 1993, Paulk et al., 1993b, Thayer & Thayer, 1997, Thayer
grupo de garantia de qualidade.
& Dorfman, 1997, Wallace & Ippolito, 1997, Kotonya & Sommerville, 1998, SPICE,
Apesar das atividades de Análise e Validação de requisitos serem abordadas
1998, Nuseibeh & Easterbrook, 2000) o termo validação possui várias definições, sendo
em separado, estas atividades têm muito em comum, envolvendo analisar os requisitos,
muitas vezes confusas, conflitantes e inconsistentes. O termo validação também é
julgar se estão descrevendo, de forma apropriada, as necessidades dos usuários e
confundido com o termo verificação (Collofello, 1988, Ghezzi et al., 1991). Sendo
especialistas de domínio e verificar os problemas nos requisitos. No entanto, existem
assim, torna-se necessário apresentar que definição será adotada neste estudo.
diferenças importantes entre elas.
Na Engenharia de Software, a atividade de validação diz respeito a avaliar o
A análise de requisitos preocupa-se em investigar os requisitos elicitados junto
software durante ou ao final do processo de desenvolvimento, para determinar se o
aos usuários e ainda não discutidos com eles, que muitas vezes estão incompletos e
mesmo satifaz aos requisitos especificados e está livre de falhas (Collofello, 1988,
expressos de forma não estruturada e informal. A atividade de validação deve ter,
IEEE, 1990, Paulk et al., 1993b) e busca responder à seguinte questão (Boehm citado
idealmente, um conjunto completo e acordado de requisitos como ponto de partida. No
por Pressman, 2000, Jacobson et al., 1992): está-se construindo o sistema correto? Na
entanto, durante a validação, problemas nos requisitos podem ainda ser encontrados e
Engenharia de Requisitos, a validação diz respeito a avaliar se a ERS está correta, ou
devem ser resolvidos antes que a ERS seja formalmente aprovada (Sommerville &
seja, se os requisitos e modelos documentados atendem às reais necessidades e
Sawyer, 1997, Kotonya & Sommerville, 1998).
requisitos dos usuários (Thayer & Thayer, 1997, Pressman, 2000, Nuseibeh &
O foco durante a análise dos requisitos é fazer com que os requisitos
Easterbrook, 2000). A meta é garantir que a ERS seja aprovada antes de ser usada como
representem de forma correta as necessidades dos usuários, ao invés de detalhes da
base para o desenvolvimento do software (Kotonya & Sommerville, 1998).
descrição dos requisitos. Deve se preocupar, principalmente, em responder à questão
Na Engenharia de Software, a verificação se refere ao processo de determinar
"Capturamos os requisitos corretos ?" A validação de requisitos preocupa-se com a
se os produtos gerados em uma dada fase do processo de software atendem às condições

Profa. Denise Franzotti Togneri Profa. Denise Franzotti Togneri

 3 4
verificação da versão final do documento de requisitos. O documento e os requisitos
devem seguir padrões de qualidade definidos. O processo de validação preocupa-se
mais com a forma pela qual os requisitos estão descritos. Em resumo, a validação de
requisitos deve preocupar-se, principalmente, (mas não exclusivamente) em responder
à questão "Os requisitos foram capturados de forma correta ?"
Entre os exemplos de problemas descobertos durante a validação, podem ser
destacados a falta de conformidade com padrões de qualidade, requisitos mal redigidos
que estão ambíguos, erros ou problemas pendentes no modelo do sistema e conflitos de
requisitos que não foram detectados durante o processo de análise. Estes problemas
devem ser resolvidos antes do documento de requisitos ser aprovado e usado como base
para o desenvolvimento do software. Em alguns casos, os problemas podem ser,
simplesmente, de documentação e podem ser resolvidos através da melhoria na
descrição dos requisitos. Em outros casos, no entanto, os problemas resultam de falhas
na elicitação, análise e/ou modelagem de requisitos e deve-se executar, novamente,
algumas das atividades anteriores do processo de engenharia de requisitos.
O processo de validação de requisitos utiliza como entradas a versão completa
do documento de requisitos, os padrões organizacionais (para se verificar a
conformidade a estes padrões) e o conhecimento sobre a organização (suas práticas,
perfis das pessoas, cultura, estrutura, etc). O processo produz, em geral, uma lista de
problemas encontrados no documento de requisitos e uma lista de ações acordadas em
resposta aos problemas levantados.
Na Engenharia de Requisitos, a validação leva a uma revisão e aprovação do
Documento de Requisitos por todos os envolvidos no processo, que se torna um
contrato de desenvolvimento de software. Mudanças de requisitos solicitadas depois que
o Documento de Requisitos esteja aprovado serão consideradas; no entanto, o cliente
deve estar ciente de que cada mudança posterior pode ser uma extensão do escopo do
software e, por conseguinte, pode aumentar o custo e/ou alongar o prazo de entrega
(Pressman, 2000, p. 294).
Várias técnicas complementares de verificação e validação dos requisitos têm
sido propostas, tais como revisão técnica formal, análise de rastreabilidade,
prototipação, validação de modelos automática ou não, inspeção, testes de requisitos e
planejamento inicial do teste do software (Paulk et al., 1993b, Wallace & Ippolito,
Profa. Denise Franzotti Togneri
1997, Thayer & Dorfman, 1997, Kotonya & Sommerville, 1998, Nuseibeh &
Easterbrook, 2000, Lamsweerde, 2000, Pressman, 2000).
Wallace & Ippolito (1997) classificam essas técnicas em estáticas, que são
aquelas que analisam diretamente a forma e estrutura do produto gerado, sem executar o
produto; dinâmicas, que envolvem execução ou simulação para detectar erros através da
análise da resposta do produto a um conjunto de dados de entrada; e análise formal, que
envolve o uso de técnicas matemáticas rigorosas para analisar os algorítmos de uma
solução, tais como a descrição de requisitos utilizando linguagens de especificação
formal (por exemplo, Z ou VDM).
Pfleeger (2001) classifica as técnicas de validação de requisitos em manuais e
automatizadas. As técnicas de validação manuais são, dentre outras, a leitura, a
referência cruzada manual, as entrevistas, as revisões, as listas de verificação, os
modelos manuais para verificar funções e relações, os cenários e as provas matemáticas.
As técnicas de validação automatizadas são, dentre outras, a referência cruzada
automatizada, os modelos automatizados para ativar as funções e os protótipos. A
escolha da técnica para um projeto depende da experiência, da preferência e da
adequação à técnica de definição e à especificação de requisitos adotada.
Este capítulo descreve algumas técnicas complementares para a validação:
revisão de requisitos, prototipagem, validação de modelos automática, testes de
requisitos e uma abordagem chamada resolução de ponto de vista.
5.1 - Revisão de Requisitos
A revisão de requisitos é a técnica mais usada de validação de requisitos.
Kotonya e Sommerville (1998) propuseram um processo de revisão composto de:
1. Planejamento da revisão: a equipe de revisão é selecionada e o horário e
local para a reunião de revisão são escolhidos; a equipe de revisão envolve,
em média, de 3 a 10 pessoas. Não há um tamanho ideal - depende do tipo
e tamanho do sistema e do número de usuários que serão afetados pelo
mesmo;
2. Distribuição dos documentos: o documento de requisitos e outros
documentos relevantes são distribuídos para os membros da equipe de
revisão;
Profa. Denise Franzotti Togneri
 5 6
3. Preparação para a revisão: os revisores lêem individualmente o
documento de requisitos para identificar conflitos, omissões,
inconsistências, desvios dos padrões e quaisquer outros problemas;
4. Reunião de revisão: cada requisito com problemas é discutido e um
conjunto de ações para endereçar os problemas é negociado e acordado.
Uma ata da reunião deve ser produzida;
5. Seguimento às ações: se for o caso, o coordenador da reunião verifica se as
ações acordadas foram executadas;
6. Revisão do documento: o documento de requisitos é revisado para refletir
as ações acordadas. Neste estágio, o documento pode ser aceito ou revisto
novamente.
Para apoiar o processo de revisão, uma boa abordagem é a adoção de listas de
verificação, que podem ser distribuídas e usadas para lembrar aos revisores o que
procurar quando lendo o documento de requisitos. Devem ser expressas de forma bem
genérica (com exceção de sistemas críticos), ser de fácil entendimento pelos usuários
finais e tratar de propriedades de qualidade do documento de requisitos e dos
relacionamentos entre os requisitos. As organizações devem derivar suas próprias
questões a serem respondidas na revisão de requisitos, baseadas em suas experiências e
padrões locais. Como uma regra geral, não devem ser muito longas. Se tiverem mais de
10 itens, os revisores não irão se lembrar de todos eles e terão que consultar a lista toda
hora para se lembrar de seu conteúdo (Kotonya e Sommerville, 1998).
Como as revisões envolvem gasto de tempo e dinheiro, deve-se tentar
minimizar o trabalho dos revisores. Erros evitáveis, tais como erros de ortografia e de
não conformidade com padrões da organização, e que podem ser detectados sem uma
revisão completa, devem ser removidos do documento de requisitos antes dele ser
distribuído para a equipe de revisão. Para isto, uma pessoa deve executar uma
verificação rápida de conformidade a padrões e processar o documento com um
verificador automático qualquer para remover erros ortográficos, erros de referência
cruzada, etc. Esta atividade é chamada de verificação de pré-revisão (Kotonya &
Sommerville, 1998).
Um engenheiro de requisitos que esteja familiarizado com os padrões, mas não
tenha sido envolvido com a especificação de requisitos do software, pode ser
Profa. Denise Franzotti Togneri
responsável por esta verificação inicial do documento, pois para este trabalho não é
necessário compreender os requisitos em detalhes. A verificação contra padrões pode
revelar problemas nos requisitos rapidamente. Se um documento de requisitos não
estiver de acordo com os padrões da companhia, isto pode indicar problemas em larga
escala com a especificação, o que pode requerer uma intervenção gerencial para sua
solução. Após o término do processo de verificação de pré-revisão, se existirem desvios
em relação aos padrões, duas ações podem ser tomadas, antes que a revisão se inicie:
retornar o documento para a equipe de engenharia de requisitos para a correção dos
desvios identificados ou anotar os desvios identificados, distribuindo-os para os
revisores do documento. Isto economiza tempo e dinheiro da criação de uma nova
versão do documento de requisitos. No entanto, os desvios dos padrões podem tornar
mais difícil o entendimento dos requisitos pelos revisores.
A menos que o documento de requisitos seja muito grande, a verificação inicial
de requisitos não leva, normalmente, mais que um dia. No entanto, a economia de
tempo para os demais revisores do documento é significante.
5.2 - Prototipação
Um protótipo do sistema pode ser usado para elicitação e análise de requisitos.
Muitas pessoas têm dificuldades em visualizar como uma declaração escrita dos
requisitos será traduzida para um software. Se um protótipo for desenvolvido para
demonstrar os requisitos, os usuários finais e os desenvolvedores acharão mais fácil
descobrir problemas e sugerir como os requisitos podem ser melhorados. Se um
protótipo for desenvolvido para a elicitação, faz sentido usá-lo mais tarde para a
validação. Caso contrário, o custo para desenvolvimento do protótipo apenas para a
validação será muito alto e portanto, inviável.
Os protótipos para validação devem ser mais completos que os protótipos
somente para elicitação. Os protótipos para a elicitação podem, simplesmente, incluir os
requisitos que forem particularmente difíceis de descrever ou entender, podendo omitir
requisitos já entendidos. Apesar de um protótipo para validação não necessitar incluir
todos os recursos do sistema, deve existir um número suficiente de recursos
implementados de modo eficiente e robusto, de tal forma que os usuários possam fazer
um uso prático e natural do sistema.
Profa. Denise Franzotti Togneri
 7 8
Outro ponto importante é que os protótipos para elicitação podem não refletir
as alterações feitas durante o processo de análise dos requisitos. Durante a validação dos
requisitos, no entanto, é necessário (i) continuar o desenvolvimento do protótipo, para
que o mesmo se mantenha atualizado; (ii) desenvolver cenários de teste para que o
protótipo seja exercitado de forma sistemática e ampla; (iii) executar os cenários no
protótipo de forma mais realística possível. Os usuários devem trabalhar sozinhos para
não serem influenciados pelos conselhos do engenheiro de requisitos, que não entanto
devem usar a técnica de observação para acompanhar os testes e (iv) documentar os
problemas encontrados e as mudanças sugeridas pelos usuários (Kotonya e
Sommerville, 1998).
5.3 - Desenvolvimento do manual do usuário
Reescrever os requisitos de forma diferente é uma técnica muito efetiva de
validação, pois, para isso deve-se entender os requisitos e seus relacionamentos. O
desenvolvimento deste entendimento revela conflitos, omissões e inconsistências. Uma
forma de reescrever os requisitos usando o processo de validação é desenvolver um
rascunho do manual do usuário final do software (mesmo que o foco seja o protótipo).
Este manual deve conter: (i) uma descrição da funcionalidade que será implementada e
como acessá-la a partir da interface com o usuário; (ii) que partes do software não estão
implementadas; (iii) uma descrição de como recuperar informações, voltando o software
para um estado anterior conhecido ou mesmo como reiniciá-lo e (iv) se necessário,
instruções de instalação do protótipo.
Este manual deve ser escrito através da tradução sistemática da funcionalidade,
descrita em termos de requisitos, para descrições, em termos dos usuários finais, de
como usar o sistema. Se for difícil explicar uma função para os usuários finais ou
explicar como expressar a funcionalidade do sistema, isso pode sugerir que existem
problemas nos requisitos. Em alguns casos, o manual do usuário do protótipo pode ser a
base para a documentação final para os usuários. No entanto, nem sempre isto é
possível. O desenvolvimento pode ser cancelado ou o sistema pode sofrer mudanças de
forma que um manual completamente novo tenha que ser escrito. O custo de escrever
um rascunho do manual deve ser incluído nos custos do processo de validação.
Profa. Denise Franzotti Togneri
5.4 - Validação de modelos
Parte da especificação dos requisitos de um software pode consistir de um ou
mais modelos, que podem ser modelos de fluxo de dados, modelos de objetos, de
eventos, de entidades-relacionamentos, etc. A validação destes modelos tem três
objetivos (Kotonya & Sommerville, 1998):
1. Demonstrar que cada modelo individual é auto-consistente, isto é, o modelo
contém todas as informações necessárias e não existem conflitos entre as
diferentes partes do modelo;
2. Se existirem muitos modelos, demonstrar que são consistentes
internamente e externamente, isto é, entidades que são referenciadas em
mais de um modelo devem ser definidas para serem as mesmas em cada
modelo, itens comparáveis devem ter mesmo nome e as interfaces do
modelo devem ser consistentes;
3. Demonstrar que os modelos refletem de forma acurada os requisitos reais
dos usuários. Esta é a tarefa de validação de modelos mais difícil. Envolve
desenvolver argumentos convincentes de que o software definido no
modelo é o que os usuários realmente precisam.
Se os modelos são expressos usando notações suportadas por ferramentas
CASE, algumas destas verificações podem ser automatizadas, tais como: verificar a
consistência de modelos individuais e executar algumas verificações cruzadas de
modelo.
5.5 - Teste de requisitos
Um atributo desejável de um requisito é que ele possa ser testado; o objetivo
destes testes é verificar se o software satisfaz o requisito e então revelar problemas tais
como incompleteza e ambigüidade. Se existirem dificuldades em derivar casos de teste
para um requisito, isso pode indicar algum tipo de problema, tal como informações
perdidas, problemas em sua descrição, etc.
Um formulário deve ser projetado e preenchido para cada requisito que for
"testado" e deve incluir, pelo menos, o identificador do requisito, os requisitos
relacionados, a descrição do teste a ser aplicado e por que é um teste objetivo (deve-se
incluir as entradas e as saídas esperadas), uma descrição dos problemas nos requisitos
Profa. Denise Franzotti Togneri
 9 10

que tornaram o teste aplicado difícil ou impossível e comentários e recomendações de
como resolver os problemas encontrados no requisito.
Logo que a validação for concluída, o Documento de Requisitos é "assinado"
pelos clientes e desenvolvedores. A especificação torna-se um contrato de
desenvolvimento de software. Mudanças de requisitos solicitadas depois que a
especificação for concluída serão consideradas; no entanto, o cliente deve notar que
cada mudança posterior é uma extensão do escopo do software e, por conseguinte, pode
aumentar o custo e/ou alongar o prazo de entrega (Pressman, 2001).
perspectiva e visão. Uma perspectiva é definida como um conjunto de fatos observados
e modelados de acordo com um aspecto particular da realidade. Uma visão é definida
como uma integração dessas perspectivas. A estratégia proposta engloba procedimentos
para formalizar pontos de vista (métodos), procedimentos para analisar os pontos de
vista formalizados (analisador estático) e uma linguagem especial, chamada VWPL,
para representar pontos de vista.

5.6 – Resolução de Ponto de Vista

Para apoiar o processo de validação de requisitos, Leite (1989) propõe uma
abordagem chamada de resolução de ponto de vista. Um ponto de vista pode ser
definido como uma coleção de informações sobre um sistema, um problema, ambiente
ou domínio, que é coletada a partir de uma perspectiva particular (Kotonya &
Sommerville, 1998). É uma postura mental ou posição usada por um indivíduo quando
examinando um universo de discurso, que é o contexto global no qual o software será
desenvolvido, incluindo todas as fontes de informação e pessoas envolvidas (Leite,
1989). A noção de ponto de vista foi introduzida pela primeira vez, de forma implícita e
intuitiva, como parte do método de especificação de requisitos SADT – The Structured
Analysis and Design Technique e posteriormente, de forma explícita, por métodos, tais
como CORE – Controlled Requirements Expression, VOSE – Viewpoint-oriented
System Engineering e VORD – Viewpoint-oriented Requirements Definition (Kotonya
& Sommerville, 1998). A noção de ponto de vista também é empregada para
representar especificações parciais, validar requisitos, modelar domínio, em
especificações orientadas a serviço, para organizar o desenvolvimento de software a
partir de múltiplas perspectivas (conhecimento) e para gerenciar inconsistências
(Easterbrook & Nuseibeh, 1996).
O objetivo da abordagem proposta por Leite (1989) é utilizar pontos de vista
para apoiar a validação de requisitos nos primeiros estágios do processo de Engenharia
de Requisitos e pode, portanto, ser utilizada durante a análise e negociação de
requisitos. Ela visa identificar e classificar problemas relacionados à completeza e
corretude e foi desenvolvida em torno de três conceitos principais: ponto de vista,

Profa. Denise Franzotti Togneri Profa. Denise Franzotti Togneri