FUNDAMENTOS DE

ENGENHARIA DE
REQUISITOS

Prof.: Denise Franzotti Togneri

“Eu sei que você pensa que entende o que eu disse,

mas o que você não entende é que, o que eu disse,
não é o que eu queria dizer” (PRESSMAN, 2006).

"A parte mais difícil na construção de um sistema

de software é decidir o que construir ..."
(CMU/SEI-TR-12).

“Projetar e construir um sistema elegante que

resolva o problema errado não serve às
necessidades de ninguém”.
 3

Bem-vindos ao maravilhoso
mundo da Engenharia de
Requisitos!

PROBLEMAS NA ENGENHARIA DE 4

SOFTWARE
Freqüentemente, produtos de software são entregues com atraso, com baixa
qualidade, acima do orçamento, com funcionalidades que não são
utilizadas, não atendendo às reais necessidades dos usuários do sistema
nem da organização.

Estes problemas, normalmente, não têm uma causa única, mas as

deficiências nos requisitos do sistema contribuem fortemente para o
problema (DORFMAN, 1997).

Para muitos desenvolvedores de sistemas de software complexos e grandes,

os requisitos são o maior problema da Engenharia de Software.

Nenhuma outra parte do processo de desenvolvimento é tão difícil de

executar ou tão desastroso em seus resultados, quando feito de forma
inadequada (FAULK, 1997).
 A ENGENHARIA DE REQUISITOS - 5

PROBLEMAS E BENEFÍCIOS
Problemas relativos aos requisitos (SOMMERVILLE, 1997):
os requisitos não refletem as reais necessidades dos usuários do sistema;
os requisitos são inconsistentes e/ou incompletos;
a mudança nos requisitos, após terem sido acordados com os usuários, é
um processo caro;
falta de entendimento entre os usuários que definem os requisitos e os
engenheiros de software que constróem e mantém o sistema.

Benefícios de uma boa determinação dos requisitos (DORFMAN, 1997):

concordância entre desenvolvedores, clientes e usuários do trabalho a ser
feito e dos critérios de aceitação para a entrega do sistema;
uma base sólida para estimativa de recursos;
aumento da usabilidade, manutenibilidade do sistema e outros atributos
de qualidade;
a realização dos objetivos com recursos mínimos.

O QUE É UM REQUISITO ?
Segundo o IEEE Standard 729, citado por Davis (1993), um requisito é
1 - uma condição ou capacidade necessária para o usuário para resolver
um problema ou alcançar um objetivo;
2 - uma condição ou capacidade que deve ser encontrada ou possuída
por um sistema ou componente do sistema para satisfazer um contrato,
padrão, especificação ou outro documento imposto formalmente;
3 - uma representação documentada de uma condição ou capacidade
como em (1) ou (2).
Segundo Abbott (1986), um requisito é qualquer função, restrição ou outra
propriedade que deve ser fornecida, encontrada ou satisfeita para preencher
as necessidades os usuários do sistema.

OBS: É importante determinar quando a fase de requisitos inicia e termina.

Para isto, deve-se reconhecer primeiro que quando se tem um problema para
resolver, não se sabe se a solução será dada através de um software,
hardware ou uma combinação dos dois.
 7
CLASSIFICAÇÃO DOS REQUISITOS
Assim como existem diversas definições para o termo "requisito", existem
também diversas classificações.

Bracket (1990) classifica-os em

funcionais e
não funcionais.

Davis (1993) classifica-os em

requisitos comportamentais e
não comportamentais.

Sommerville (2003) classifica-os em

requisitos do usuário
requisitos de sistema (que podem ser funcionais, não funcionais ou
requisitos de domínio).

8
CLASSIFICAÇÃO DOS REQUISITOS
(SEGUNDO BRACKET (1990) E DAVIS (1993))
funcionais ou comportamentais: definem as funcionalidades ou
comportamentos que devem ser atendidos pelo software, ou seja, definem o
que o sistema faz. Descrevem as ações de transformação que os componentes
de hardware ou software do sistema devem executar sobre as entradas para
produzir as saídas (Thayer & Thayer, 1997);

não funcionais ou não comportamentais: são as restrições e os atributos de

qualidade de software ou de processos de software que devem ser atendidos
(Sabát Neto & Leite, 2000). Definem os atributos do sistema enquanto ele
executa seu trabalho (Davis, 1993).
 CLASSIFICAÇÃO DOS REQUISITOS 9

NÃO FUNCIONAIS
Diferentes taxonomias para requisitos não funcionais têm sido propostas,
como a de Kotonya & Sommerville (1998) que os classifica em
requisitos de processo (relativos à entrega, implementação e
conformidade a padrões),
requisitos de produto (relativos à usabilidade, confiabilidade, segurança,
eficiência, desempenho e capacidade) e
requisitos externos (relativos à interoperabilidade e restrições legais e
econômicas).
Já o IEEE (1998) classifica os requisitos não-funcionais em
requisitos de interface externa,
requisitos de desempenho,
requisitos lógicos de banco de dados (freqüência de uso, recursos de
acesso, as restrições de integridade e os requisitos de retenção de dados),
restrições de projeto,
conformidade a padrões e os
atributos de qualidade do software (confiabilidade,
disponibilidade, segurança, manutenibilidade e portabilidade).

CLASSIFICAÇÃO DE REQUISITOS 10
(SEGUNDO SOMMERVILLE (2003))
REQUISITOS DO USUÁRIO

REQUISITOS DE SISTEMA. Podem ser

Requisitos funcionais
Requisitos não funcionais
Requisitos de domínio

UM REQUISITO DO USUÁRIO PODE SER EXPANDIDO EM

DIVERSOS REQUISITOS DE SISTEMA

A DISTINÇÃO ENTRE ELES NÃO É CLARA!

 CLASSIFICAÇÃO DE REQUISITOS 11
(SEGUNDO SOMMERVILLE (2003))
REQUISITOS DO USUÁRIO:
São requisitos abstratos de alto nível, descritos numa linguagem
compreensível pelos usuários que especificam o comportamento externo do
sistema.
São declarações em linguagem natural e também em diagramas sobre as
funções que o sistema deve fornecer e as restrições sobre as quais deve
operar.
Ex: O software deve oferecer um meio de representar e acessar arquivos
externos criados por outras ferramentas.

CLASSIFICAÇÃO DE REQUISITOS 12
(SEGUNDO SOMMERVILLE (2003))
REQUISITOS DE SISTEMA:
são descrições detalhadas dos requisitos dos usuários.
Estabelecem detalhadamente as funções e restrições do sistema.
O Documento de Requisitos gerado deve ser PRECISO.
Podem ser
Requisitos funcionais: declarações de funções que o sistema deve
fornecer, como deve reagir a entradas específicas e como deve se
comportar em determinadas situações.
Requisitos não funcionais: são as restrições e os atributos de
qualidade que devem ser atendidos.
Requisitos de domínio: requisitos que se originam do domínio de
aplicação do sistema e refletem características deste domínio.
Podem ser funcionais ou não funcionais.
 13
ATIVIDADES DURANTE A FASE DE REQUISITOS:
ANÁLISE DO PROBLEMA VERSUS DESCRIÇÃO
DO PRODUTO (DAVIS, 1993)
Delinear restrições
a análise do Refinar restrições
A idéia inicial Negociar restrições conflitantes
problema
Entender o problema
Expandir informações

Um entendimento relativamente completo dos requisitos

a descrição Verificação de consistência

do produto Solidificação

Uma especificação de requisitos de software (ERS) completa e consistente

14
ATIVIDADES DURANTE A FASE DE REQUISITOS:
ANÁLISE DO PROBLEMA VERSUS DESCRIÇÃO
DO PRODUTO (DAVIS, 1993)
Na Análise do Problema
os analistas gastam seu tempo fazendo brainstorming, entrevistando
pessoas que têm conhecimento sobre o problema em mãos e
identificando todas as restrições possíveis na solução do problema. Há,
então, uma expansão considerável de informações e conhecimento sobre
o problema.
Maiores problemas: dizem respeito a encontrar formas de negociar
restrições e organizar a grande quantidade de informações.
A análise do problema deve ser executada até que o entendimento
completo do problema seja obtido.
Na Descrição do Produto
É tempo de "ter a caneta à mão" para tomar certas decisões difíceis e
preparar um documento que descreve o comportamento externo
esperado do produto a ser construído para resolver os problemas agora
entendidos.
É tempo de organizar idéias, resolver visões
conflitantes e eliminar inconsistências e ambigüidades.
 15
O TERMO ENGENHARIA DE REQUISITOS
A Engenharia de Requisitos é uma das fases da Engenharia de Software
que cobre todas as atividades envolvidas na descoberta, documentação e
manutenção do conjunto de requisitos de um sistema baseado em
computador.

O uso do termo "engenharia" implica que técnicas sistemáticas e iterativas

devem ser usadas para garantir que os requisitos do sistema estejam
completos, consistentes, relevantes, etc (SOMMERVILLE, 1997).

A Engenharia de Requisitos é, portanto, um processo sistemático de

captura, modelagem e documentação de requisitos através de uma
abordagem iterativa e cooperativa de análise do problema, documentação
das observações resultantes em uma variedade de formatos de
representação e verificação da acurácia do entendimento obtido
(GRAHAM, 1998).

O PROCESSO DE
ENGENHARIA DE
REQUISITOS
 PROCESSO DE ENGENHARIA DE 17

REQUISITOS
É um conjunto estruturado de atividades que são seguidas para
derivar, validar e manter um documento de requisitos do sistema.

Informações de
Sistemas Existentes

Requisitos
Necessidades dos
acordados
Usuários Processo de

Padrões Engenharia Especificação do

organizacionais Sistema
de
Regulamentos
Requisitos Modelos de Sistema

Informação de
Domínio

PROCESSO DE ENGENHARIA DE 18

REQUISITOS
Varia muito, indo desde processos não estruturados (baseados na
experiência das pessoas) até processos sistemáticos ( baseados em
alguma metodologia).
Não faz sentido falar em processo ideal ou definir algum e impô-lo a uma
organização. Ao invés disto, as organizações devem iniciar com um
processo genérico de ER e instanciá-lo para um processo que seja
apropriado às suas necessidades (SOMMERVILLE; SAWYER, 1997).
Da mesma forma que o processo de software, o ponto de partida para a
definição de um processo de engenharia de requisitos é a escolha de um
modelo de processo, tais como os modelos em cascata e em espiral
(KOTONYA; SOMMERVILLE, 1998), e vários fatores influenciam sua
definição (PRESSMAN, 2006).
Ainda que diferentes projetos requeiram processos com características
específicas para contemplar suas peculiaridades, é possível estabelecer um
conjunto de atividades básicas que deve ser considerado em qualquer
definição de processo de Engenharia de Requisitos. Existem vários
conjuntos de atividades propostos para o processo.
 19
ATIVIDADES DA ENGENHARIA DE REQUISITOS
Nuseibeh & Kotonya & Thayer & Pressman Lamsweerde
Autores Easterbrook Sommerville Dorfman (2006) (2000)
Atividades (2000) (1998) (1997)
Concepção x
Análise de domínio x
Levantamento x
Elicitação x x x x
Modelagem x
Elaboração x
Análise de requisitos x x x
Negociação x x x
Documentação x
Especificação de x x x
requisitos
Análise da Especificação x
Verificação x
Comunicação x
Concordância x x
Validação x x
Documentação do x
processo, das decisões e
das fontes dos requisitos
Gerência de requisitos x x x
Evolução de requisitos x x

20
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
CONCEPÇÃO
LEVANTAMENTO
ELABORAÇÃO (é a modelagem)
NEGOCIAÇÃO
ESPECIFICAÇÃO
VALIDAÇÃO
GESTÃO
 21
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
1 - CONCEPÇÃO
Como um projeto de software é iniciado?
Em geral, a maioria começa quando uma necessidade de negócio é
identificada ou um mercado ou serviço potencialmente novo é descoberto.
Interessados da comunidade de negócios (gerentes de negócio ou pessoal de
marketing, por exemplo) definem um plano de negócio e identificam uma
descrição que funciona do escopo do projeto. Essas informações são
suficientes para iniciar discussões com a organização da engenharia de
software.
Na concepção do projeto, os engenheiros de software perguntam uma série
de questões livres de contexto para estabelecer
um entendimento básico do problema,
o pessoal que quer uma solução,
a natureza da solução desejada,
os benefícios e a efetividade da comunicação e
colaboração preliminares entre cliente e desenvolvedor.

22
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
1 – CONCEPÇÃO

ALGUNS PROBLEMAS
Clientes podem estar geograficamente distribuídos
Podem ter apenas uma vaga idéia do que é necessário
Ter opiniões conflitantes sobre o sistema a ser construído
Ter conhecimento técnico limitado e tempo limitado para interagir com o
engenheiro de requisitos.
 23
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
1 – CONCEPÇÃO - PASSOS NECESSÁRIOS PARA INICIAR A
ENGENHARIA DE REQUISITOS
Identificação dos interessados (stakeholders) quem quer que se
beneficie de modo direto ou indireto do sistema que está sendo desenvolvido.
Ex.: gerentes, marketing, clientes, usuários, engenheiros de software,
engenheiros de suporte.
Cada interessado tem uma visão diferente do sistema, obtém diferentes
benefícios e se expõe a diferentes riscos se o desenvolvimento falhar.
Criar uma lista de stakeholders que crescerá à medida que os requisitos
forem levantados “com quem mais você acha que eu deveria falar”?
Reconhecimento de diferentes pontos de vista dos stakeholders que pode
gerar conflitos que devem ser resolvidos na negociação
Trabalho em busca da colaboração
Formulação das primeiras questões questões livres de contexto

24
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
1 – CONCEPÇÃO – AS QUESTÕES LIVRES DE CONTEXTO - EXEMPLOS
Quem está por trás da solicitação deste trabalho?
Quem vai usar a solução?
Qual será o benefício econômico de uma solução bem-sucedida?
Há outra fonte para a solução que você necessita?
Como você caracterizaria “boas” saídas, que seriam geradas por uma solução bem-
sucedida?
Que problemas essa solução enfrentaria?
Você pode me mostrar (ou descrever) o ambiente de negócios no qual a solução será
usada?
Tópicos ou restrições especiais de desempenho afetarão o modo pelo qual a solução é
abordada?
Você é a pessoa certa para responder a essas questões? Suas respostas são “oficiais”?
Minhas questões são relevantes ao problema que você tem?
Estou formulando muitas questões?
Alguém mais pode fornecer informações adicionais?
Devo perguntar-lhe mais alguma coisa?
 25
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
2 – LEVANTAMENTO
Consiste em elicitar, levantar, coletar
Uma lista de clientes, usuários e outros interessados no sistema
Uma declaração da necessidade, da viabilidade e da justificativa do novo
produto
Uma afirmativa limitada do escopo do sistema ou do produto
Uma descrição do ambiente técnico do sistema
Uma lista de requisitos, organizada por função e as restrições de domínio
que se aplicam a cada um deles.
Um conjunto de cenários de uso que fornecem informações sobre o uso do
sistema ou do produto sob diferentes condições de operação.
Quaisquer protótipos desenvolvidos para definir melhor os requisitos.
Para isso, diversas técnicas de elicitação devem ser adotadas.

26
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
2 – LEVANTAMENTO - PROBLEMAS (CHRISTEL; KANG, 1992):
problemas de escopo: os limites e objetivos do software podem ser mal
definidos e requisitos de projeto inapropriados podem ter sido levantados;
problemas de entendimento e comunicação: os usuários e especialistas de
domínio podem não ter uma visão clara de suas necessidades e ter um baixo
entendimento dos recursos e limitações tecnológicas de seus ambientes
computacionais. Podem omitir informações por achá-las óbvias e podem
existir visões conflitantes entre eles;
problemas relativos à volatilidade: os requisitos podem evoluir ou mudar ao
longo do tempo.
 27
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
3 – ELABORAÇÃO (É A MODELAGEM)
Enfoca o desenvolvimento de um modelo técnico refinado das funções,
características e restrições do software.

É uma ação de modelagem de análise.

No paradigma estruturado MER, DFD, DTE;
No paradigma da orientação a objetos diagrama de casos de uso, de
classes, de estados, de sequência, ....

O resultado final é um modelo de análise que define o domínio do problema

informacional, funcional e comportamental.

28
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
4 – NEGOCIAÇÃO

“Conciliação é a arte de dividir um bolo de tal modo que todos acreditam ter
o maior pedaço”.

É comum clientes e usuários pedirem mais do que pode ser conseguido,

considerando-se os recursos limitados do negócio, os custos e o prazo do
sistema ou produto.
É comum que diferentes clientes ou usuários proponham requisitos
conflitantes, argumentando que sua versão “é essencial para nossas
necessidades especiais”.

Afinal, quais são as prioridades, o que é essencial, o que é necessário?

A negociação é a atividade que busca conciliar estes conflitos.
 29
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
4 – NEGOCIAÇÃO

As melhores negociações buscam um resultado “ganha-ganha”.

O cliente ganha por obter o sistema ou produto que satisfaça à maioria das
necessidades dos clientes, e
a equipe de software ganha por trabalhar com orçamentos e prazos realistas e
realizáveis.

30
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
4 – NEGOCIAÇÃO
Boehm (1998), define um conjunto de atividades de negociação no começo de
cada iteração do processo de software, buscando
Identificação dos interessados-chave do sistema ou subsistema.
Determinação das “condições de ganho” dos interessados.
Negociação das “condições de ganho” para conciliá-las em um conjunto
de condições ganha-ganha p/ todos envolvidos (inclusive a equipe de sw).
Na negociação:
Clientes , usuários e outros interessados são solicitados a ordenar os
requisitos e discutir os conflitos de prioridade.
Os riscos associados a cada requisito são identificados e analisados.
“Estimativas” grosseiras do esforço de desenvolvimento são feitas e
usadas para avaliar o impacto de cada requisito no custo do projeto e no
prazo de entrega.
Usando uma abordagem iterativa, requisitos são eliminados, combinados
e/ou modificados de modo que cada parte alcance
algum grau de satisfação.
 31
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
4 – A ARTE DA NEGOCIAÇÃO

Reconheça que não é uma competição ambas as partes devem ter a

sensação que venceram.
Trace uma estratégia decida o que gostaria de conseguir, o que a outra
parte quer conseguir, e como você fará para que ambos ocorram.
Ouça atentamente não formule sua resposta enquanto o outro estiver
falando. Ouça e obtenha conhecimento para ajudá-lo a negociar melhor sua
posição.
Focalize os interesses das outras partes não assuma posições radicais para
evitar conflitos.
Não deixe a coisa ficar pessoal enfoque o problema a ser resolvido.
Seja criativo pense grande para resolver impasses.
Esteja pronto a se comprometer comprometa-se com o acordo feito e siga
em frente.

32
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
5 - ESPECIFICAÇÃO
No contexto da Engenharia de Software, especificação significa coisas
diferentes para pessoas diferentes.
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 desses elementos.
Um gabarito padrão pode ser desenvolvido e usado para a especificação de
sistemas mas deve ser flexível.

A especificação é o produto de trabalho final produzido pelo engenheiro de

requisitos. Descreve a função e o desempenho de um sistema e as restrições
que governarão seu desenvolvimento.
 33
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
6 – VALIDAÇÃO
Os produtos de trabalho da ER são avaliados quanto à qualidade durante o
passo de validação.
Examina a especificação para garantir que
Todos os requisitos do software tenham sido declarados de modo não
ambíguo,
Que as inconsistências, omissões e erros tenham sido detectados e
corrigidos
Que os produtos de trabalho estejam de acordo com as normas
estabelecidas para o processo, o projeto e o produto.

PRINCIPAL MECANISMO DE VALIDAÇÃO DE REQUISITOS

REVISÃO TÉCNICA FORMAL.

34
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
7 – GESTÃO
Identifica, controla e rastreia requisitos e modificações de requisitos em
qualquer época, à medida que o projeto prossegue.

Cada requisito deve ser identificado.

Tabelas de rastreamento de requisitos devem ser desenvolvidas,

relacionando os requisitos identificados a um ou mais aspectos do sistema ou
de seu ambiente.

Estas tabelas auxiliam no entendimento de como uma modificação em um

requisito afetará diferentes aspectos do sistema a ser construído.
 35
ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO PRESSMAN (2006)
7 – GESTÃO
Exemplos de Tabelas de rastreamento de requisitos:
Tabela de rastreamento de características. Mostra como os requisitos
se relacionam a características importantes do sistema/produto
observáveis pelo cliente.
Tabela de rastreamento de fontes. Identifica a fonte de cada requisito.
Tabela de rastreamento de subsistemas. Caracteriza os requisitos
pelo(s) subsistema(s) que eles governam.
Tabela de rastreamento de interface. Mostra como os requisitos se
relacionam com as interfaces internas e externas do sistema.

36

ATIVIDADES DA ENGENHARIA DE
REQUISITOS SEGUNDO KOTONYA E
SOMMERVILLE (1998)
ELICITAÇÃO
ANÁLISE
NEGOCIAÇÃO
DOCUMENTAÇÃO
VALIDAÇÃO
GERÊNCIA
 37
UM MODELO MACRO DE
Gerência de
ATIVIDADES DO PROC. DE requisitos
ENG. DE REQ. [KOTONYA 98]

Elicitação Análise e Documenta Validação

requisitos Negociação ção de requisitos
requisitos requisitos

Necessidades dos
usuários, informações
Documentação
de domínio, informação
dos requisitos
dos sistemas existentes,
regulamentos, padrões, Especificação do
etc. sistema

Não há limites bem definidos entre as atividades; Requisitos acordados

são intercaladas e existe um alto grau de iteração e feedback entre elas .

38
ATIVIDADES DO PROCESSO DE ENG. DE
REQUISITOS [KOTONYA98]
1 - ELICITAÇÃO DE REQUISITOS
É o processo de identificar necessidades e diminuir as disparidades entre
as comunidades envolvidas, com o objetivo de definir e destilar os
requisitos para encontrar as restrições destas comunidades.
Envolve questões sociais e de comunicação bem como questões técnicas.
Os requisitos do sistema são descobertos através de entrevistas com
clientes, questionários, de análise de documentos, do conhecimento do
domínio, estudos de mercado, prototipagem, etnografia, etc.

2 - ANÁLISE DE REQUISITOS E NEGOCIAÇÃO

Os requisitos são analisados em detalhes e os clientes negociam para
decidir quais requisitos serão aceitos (o conjunto de requisitos acordados
para o sistema).
Este processo é necessário porque existem conflitos inevitáveis entre os
requisitos e partir de fontes diferentes; as informações podem estar
incompletas ou os requisitos expressos podem ser
incompatíveis com o orçamento disponível para o sistema.
 PROCESSO DE ELICITAÇÃO, ANÁLISE E 39

NEGOCIAÇÃO DE REQUISITOS
Rascunho da declaração
de requisitos

Elicitação dos Análise de

requisitos requisitos

Documento de Problemas nos

requisitos requisitos
Negociação de
requisitos

A espiral de elicitação, análise e negociação de requisitos [Kotonya98]

O ciclo do processo continua até que a pressão do cronograma força o

início do projeto do sistema ou até que todos os usuários estejam
satisfeitos com os requisitos.

40
ATIVIDADES DO PROCESSO DE ENG. DE
REQUISITOS [KOTONYA98]
3 - DOCUMENTAÇÃO DOS REQUISITOS
Os requisitos acordados são documentados em um nível apropriado de
detalhes.
Uma vez que a ERS deve ser apropriada para o entendimento dos usuários,
ela é normalmente documentada usando linguagem natural e diagramas.

4 - VALIDAÇÃO DOS REQUISITOS

Esta atividade prevê uma verificação e revisão cuidadosa dos requisitos
para garantir consistência e completeza.
Este processo tenciona detectar problemas no documento de requisitos
antes que seja usado como base para o desenvolvimento do sistema.

5 - GERÊNCIA DE REQUISITOS
Em paralelo a todas as atividades descritas acima está o processo de
gerência de requisitos, que diz respeito a gerenciar mudanças nos
requisitos.
 41
ATIVIDADES DO PROCESSO DE ENG. DE
REQUISITOS [KOTONYA98]
5 - GERÊNCIA DE REQUISITOS
Mudanças nos requisitos do sistema são propostas pelos usuários com
freqüência e são inevitáveis quando ocorrem:
mudanças nas prioridades do negócio;
surgem novos requisitos;
quando são descobertos erros ou omissões nos requisitos;
quando os usuários desenvolvem um melhor entendimento de suas reais
necessidades.
A gerência de requisitos tem como objetivos manter uma trilha destas
mudanças e garantir que as mudanças sejam feitas no documento de
requisitos de forma controlada.
As principais preocupações da gerência de requisitos dizem respeito a
Gerência de mudança de requisitos acordados;
Gerência dos relacionamentos entre os requisitos;
Gerência das dependências entre o documento de requisitos e outros
documentos produzidos durante o processo
de engenharia de software e sistemas.

ANÁLISE DE REQUISITOS X VALIDAÇÃO DE REQUISITOS 42

EM COMUM
Tanto a Análise quanto a Validação de Requisitos buscam encontrar erros,
problemas, omissões, inconsistências e conflitos nos requisitos documentados.
DIFERENÇAS
ANÁLISE VALIDAÇÃO
Usa como base o rascunho do Usa como base o Documento de Requisitos
Documento de Requisitos que contém idealmente completo.
os requisitos elicitados até o momento.

É feita várias vezes, de forma cíclica, É executada, em geral, somente uma vez,
durante o processo de Eng. Requisitos no final do processo de Eng. Requisitos.

É feita pelo analista de sistemas, É feita por todos os envolvidos, ou seja,

também chamado de Engenheiro de
Requisitos.
especialistas de domínio, engenheiros de
requisitos (analistas de sistemas), usuários e
projetistas, envolvidos no desenvolvimento
do sistema. Também devem participar da
validação de requisitos os engenheiros de
requisitos e projetistas que não estão
envolvidos no desenvolvimento do sistema