Levantamento de

Requisitos de Sistemas

Objetivo

O início do desenvolvimento de software é realizado pelo levantamento de requisitos que

propõe um processo genérico contém as seguintes atividades:
 Compreensão do domínio da aplicação
 Coleta de requisitos: interagir com os stakeholders do sistema
 Classificação: organiza em grupos coerentes;
 Resolução de conflitos entre os stakeholders
 Definição das prioridades
 Verificação se requisitos estão completos e consistentes

O Levantamento e análise de requisitos é um processo iterativo, com uma contínua

validação de uma atividade para outra, conforme exemplificado pela Figura 1 e que será
gerada a Especificação de Requisitos por meio de um Documento de Requisitos.

Figura 1. Processo de levantamento e análise de requisitos (SOMMERVILLE, 2003)

Dificuldades encontradas na fase de levantamento de requisitos do projeto

 baixo grau de satisfação dos usuários
 utilizar as técnicas adequadas
 não descrever os requisitos do sistema de modo claro, sem ambiguidades, conciso e
consistente com todos os aspectos significativos do sistema proposto.
 usuários não sabem o que quer que o sistema faça ou conseguem transmitir;
 requisitos identificados não são realistas
 não identificam os requisitos similares informados por pessoas diferentes.
 um stakeholder errado afeta em perda de tempo para os envolvidos
 falta de uma boa definição do projeto, da efetividade, de informações necessárias a
um perfeito diagnóstico para obter soluções inteligentes.
 diagnóstico fraco com conclusões comprometidas, não identificação das causas dos
problemas,
 custos elevados
 prazos vencidos ou comprometedores,
 omissão de processos fundamentais e descréditos.

1
Técnicas de Levantamento de Requisitos

As técnicas visam superar as dificuldades desta fase e cada uma tem seu conceito próprio,
vantagens e desvantagens e podem ser utilizadas em conjunto pelo desenvolvedor de
sistemas. Destacam-se aqui as seguintes técnicas:
1. Métodos de Conversação
2. Métodos de Observação
3. Métodos Analíticos
4. Métodos Sintéticos
5. Orientados a Ponto de Vista

1. Métodos de Conversação:
Meio de comunicação verbal entre duas ou mais pessoas.
Forma natural de expressar as necessidades, ideias, responder às perguntas para
identificar os requisitos do produto,

1.1 Entrevista (Interviews)

 técnica tradicional e mais simples de utilizar
 produz bons resultados na fase inicial de obtenção de dados.
 o entrevistador deve dar espaço ao entrevistado para esclarecer as suas
necessidades
 discussão do projeto desejado com diferentes grupos de pessoas.
 desenvolver um plano para uso eficiente do tempo evitando dispersão do assunto que
a torne longa e cansativa
 certificar-se da autorização para falar com os usuários,
 utilizar ferramentas automatizadas
 usar um estilo adequado ao entrevistar.
 planejar a entrevista é necessário coletar e/ou estudar dados pertinentes à discussão,
como documentos e formulários e descobrir que informação o usuário está mais
interessado.
 facilidade para alterar a ordem, eliminar e incluir perguntas;
 determinar um escopo limitado para que a reunião não se estenda por mais de uma
hora.
 validar o que foi documentado pelo analista realizando checklist com o usuário para
validar o que entendeu
 evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma
tentativa de persuasão.
 nunca deve criticar a credibilidade do entrevistado pois ele é o perito no assunto
 elaborar perguntas detalhadas e solicitar que o usuário:
Explique o relacionamento entre o que está em discussão e as demais partes
do sistema;
Descreva o ponto de vista de outros usuários em relação ao item que esteja
sendo discutido;
Descreva informalmente a narrativa do item em que o analista deseja obter
informações;
Perguntar ao usuário se o item em discussão depende para a sua existência de
alguma outra coisa, para assim poder juntar os requisitos comuns do sistema,
formando assim um escopo conciso.

1.2 WorkShop
 técnica de elicitação em grupo usada em uma reunião estruturada.
 fazem parte do grupo uma equipe de analistas, uma seleção dos stakeholders que
melhor representam a organização e o contexto em que o sistema será usado
 acionar o trabalho em equipe com intensa interação entre todos
 os elementos presentes, o workshop tem o objetivo de

2
  há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão
entre os vários mediadores.
 convocação deve possuir dia, hora, local, horário de início e de término; assunto a ser
discutido e a documentação.
 tomadas de decisão são baseadas em negociações mediado pelo facilitador.
 produzir documentações que refletem os requisitos e decisões tomadas sobre o
sistema
 obter um conjunto de requisitos bem definido;
 trabalho em equipe torna o levantamento de requisitos mais eficaz e com baixo custo
 tempo de obtenção de informações é reduzido.

1.3 BrainStorming: 
 é utilizado normalmente em workshops.
 gera documentação que refletem os requisitos e decisões tomadas sobre o sistema
 deve ser a apresentação do problema/necessidade a um grupo específico,
requerendo assim soluções.
 técnica para geração de ideias com uma ou várias reuniões para sugerir e explorar as
ideias
 etapas para conduzir uma sessão de brainstorming:
 Seleção dos participantes: para contribuições diretas, pessoas bem
informadas, de diferentes grupos garantindo uma boa representação;
 Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os
conceitos básicos e as regras a serem seguidas durante a sessão;
 Produzir uma boa quantidade de ideias: Os participantes expõem, um por vez
e se alguém tiver problema, passa a vez e espera a próxima rodada.
 ideias que pareçam não convencionais, são encorajadas, pois elas frequentemente
estimulam os participantes, o que pode levar a soluções criativas para o problema.
 quanto mais ideias forem propostas, maior será a chance de aparecerem boas ideias.
 Várias pessoas pensando é melhor do que uma
 devem ser encorajados a combinar ou enriquecer as ideias de outros
 uma pessoa registra todas as ideias e estas ficam visíveis a todos
 Analisar as ideias é a fase final do brainstorming.
 revisão das ideias e as consideradas valiosas pelo grupo são mantidas e classificadas
em ordem de prioridade.

1.4 Questionário
 técnica interessante quando há um grande número de pessoas para extrair as
mesmas informações.
 elaborar questões auto-aplicáveis e dirigidas por escrito aos participantes para ter
conhecimento sobre opiniões
 utilizar quando o informante pode estar em diversos locais diferentes e há dificuldade
em estar em todos estes locais.
 desenvolver de forma a minimizar o tempo gasto nas respostas e assim utilizar
resposta múltipla escolha, lista de verificação ou questões abertas.
 preparar o questionário com um título e tipo de informação que se deseja obter.
 agrupar as questões de tópicos específicos
 elaborar questões de forma simples e clara pois uma forma padronizada garante
uniformidade
 desenvolver um controle que identifique todas as pessoas que receberão os
questionários.
 permitir que os participantes respondam no momento em que acharem conveniente;
 distribuir e oferecer instruções sobre o preenchimento indicando prazo de devolução
 analisar as respostas e elaborar consolidação das informações fornecidas

1.5 Grupo Focal (Focus Group)

 grupo de discussão informal e de tamanho reduzido (até 12 pessoas)

3
  obter informação qualitativa em profundidade
 convidar as pessoas para participar da discussão sobre determinado assunto
específico.
 obter informações qualitativas a curto prazo, baixo custo e com flexibilidade
 esclarecer questões complexas no desenvolvimento de projetos;
 ter um facilitador/moderador com experiência para conduzir o grupo
 realizar seleção criteriosa dos participantes

2. Métodos de Observação:
Utilizado para a compreensão do domínio da aplicação, observando as
atividades humanas.

2.1 Etnografia
 compreender os requisitos humanos, sociais e organizacionais desempenhados numa
dada organização
 utilizar quando necessita um entendimento completo, detalhado e com maior
profundidade
 entender a política organizacional e a cultura de trabalho familiarizando-se com o
sistema e sua história.
 observar o trabalho diário e anotar as tarefas reais em que o sistema será utilizado
 descobrir requisitos de sistema implícitos da maneira como as pessoas realmente
trabalham,
 descobrir requisitos derivados da cooperação e conscientização das atividades de
outras pessoas.
 antes de iniciar a observação, identificar as áreas de usuário a serem observadas;
obter a aprovação das gerências, nomes e funções das pessoas chave e explicar a
finalidade do estudo;
 familiarizar-se com o local de trabalho, observar os agrupamentos, as facilidades
manuais e automatizadas;
 coletar amostras de documentos e procedimentos escritos,
 acumular informações estatísticas a respeito das tarefas, como: frequência que
ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está
sendo observada.
 observar as operações normais de negócios e também as exceções;
 documentar as descobertas resultantes das observações feitas.
 consolidar o resultado revendo os resultados com as pessoas observadas e/ou com
seus superiores.
 consumir mais tempo que outras técnicas e utilizar como complementar
 Pode causar desconforto nas pessoas que estão sendo observadas

2.2 Observação
 visitar o local a ser observado para obter informações par ao sistema
 Permitir coletar informações de acordo com o cotidiano das operações e execução
dos processos diários.
 captar o comportamento natural das pessoas;
 causar nível de intromissão relativamente baixo;
 observar de forma confiável com baixo nível de inferência.

2.3 Protocolo de Análise

 Processo de extração de registro de tarefas via audio, vídeo ou notas escritas.Análise
de protocolo é uma forma de levantamento de requisitos no qual o analista analisa as
partes interessadas quando estão envolvidas em algum tipo de tarefas.
 o analista deve ter conhecimento suficiente sobre domínio atual, a fim de
compreender melhor as tarefas.

4
3. Métodos Analíticos:
Conjunto de técnicas para análise de documentação e conhecimento existentes
Adquirir requisitos como domínio do negócio, fluxos de trabalho e características do
produto.
Estudar o conhecimento de especialistas aumenta a maturidade e qualidade;
Reutilizar informação já disponível salva tempo e custo;
Requer dados empíricos, do cotidiano, documentação, opinião de especialistas,
e sem estes, não é possível identificar os requisitos;

3.1 Reuso de Requisitos

 estudo e reutilização de especificações e glossários referente a projetos de sistemas
legados ou sistemas de mesma família (com funcionalidades de negócio similares).
 economizar tempo e recursos
 sistemas similares podem reutilizar acima de 80% de seus requisitos;
 pode levar a uma reutilização adicional de outros itens em outras atividades do ciclo
de vida de desenvolvimento (ex.: reuso do design de componentes já existentes,
testes e código fonte);
 redução de risco: requerimentos reutilizados tem uma chance maior de serem
compreendidos pelos stakeholders visto que já são conhecidos de certa forma;

3.2 Estudo de Documentação/Análise de Conteúdo

 estudar e reutilização de documentação de diferentes naturezas, para a identificação
de requisitos a serem implementados no sistema que se está modelando.
 grande variedade de documentação pode ser analisada incluindo estrutura
organizacional da empresa,  padrões de mercado, leis, manuais de usuário, relatório
de pesquisas de mercado, glossário de termos de negócio, etc.
 ficar atento a documentos desatualizados e com problemas podem levar a uma falha
na definição dos requisitos;

3.3 Laddering: 
 método de entrevistas estruturadas, um-a-um, utilizado para o levantamento de
conhecimento de especialistas visando saber o que é importante e por que.
 criar, revisar e modificar a hierarquia de conhecimento dos especialistas geralmente
na forma de diagramas hierárquicos (ex.: diagrama em árvore).
 cobre um amplo domínio de requisitos, mas nem todos;
 necessita de menos tempo para a preparação e execução das sessões de
levantamento;
 necessita de menos experiência para a execução das sessões de levantamento;
 provê um formato padrão que é adaptável para a automação computadorizada;
 combinar com outras técnicas e utilizar esta como complementar

3.4 Sorteio de Cartões

 utilizar para capturar informações e ideias sobre estrutura de requisitos de
especialistas de domínio.
 um conjunto de cartões é distribuído em um grupo de stakeholders onde cada cartão
é impresso com a descrição das entidades do domínio.
 ajuda os stakeholders a levantar os conceitos do domínio e distinguir entre problemas
de alto e baixo nível;
 o resultado do método pode ser utilizado como insumo para outros métodos de
levantamento de requisitos;

3.5 Repertory Grid

 Método onde os stakeholders são questionados sobre atributos e valores referentes a
uma série de entidades.
 Com esta informação é montada uma matriz de entidade X atributo.

5
4. Métodos Sintéticos:
Métodos sintéticos são formados pela combinação das várias técnicas em uma única.

4.1 Sessões JAD - Joint Application Design 

O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para
diversas finalidades, como: planejamento de atividades técnicas para um grande
projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de
horas necessárias para desenvolver sistemas grandes e complexos.
Workshops e sessões de grupo nos quais stakeholders e desenvolvedores se encontram
para discutir as características desejadas do produto.

 envolver todos os stakeholders importantes no processo de levantamento, através de

reuniões estruturadas e com foco bem definido.
 técnica para promover cooperação, entendimento e trabalho em grupo entre os
usuários e desenvolvedores.
 facilita a criação de uma visão compartilhada do que o produto de software deve ser.
 Desenvolvedores ajudam os usuários a formular problemas e explorar soluções e
assim ganham um sentimento de envolvimento, posse e responsabilidade com o
sucesso do produto

Princípios básicos do JAD:

 Dinâmica de grupo: reuniões com um líder experiente, analista, usuários e gerentes,
para despertar a força e criatividade dos participantes, para determinar os objetivos e
requisitos do sistema;
 Uso de técnicas visuais: para aumentar a comunicação e o entendimento;
 Manutenção do processo organizado e racional: análise top down e atividades bem
definidas. A garantia de uma análise completa reduz as chances de falhas ou lacunas
no projeto e cada nível de detalhe recebe a devida atenção;
 Utilização de documentação padrão: preenchida e assinada por todos os participantes
garantindo qualidade esperada do projeto e promove a confiança dos participantes.

A técnica JAD é composta de duas etapas principais:

Planejamento – elicitação e especificação dos requisitos;
Projeto – gerenciamento e desenvolvimento do sistema

Cada etapa possui três fases:

 Preparação: escolha dos participantes, garantia de agenda, acordo para
participantes e preparar o material.
 Sessão: realização dos encontros estruturados, envolvendo desenvolvedores e
usuários onde os requisitos são desenvolvidos e documentados.
 Revisão: rever a documentação produzida na sessão e examinar melhorias na
sistemática adotada

Tipos de Participantes (nem todos participam de todas as fases).

 Patrocinador (cliente) – Estabelece a diretrizes e objetivos do projeto. Possui
autoridade formal sobre as áreas de negócios afetadas pelo desenvolvimento do
produto. É ele quem faz a abertura da primeira sessão, apresenta os participantes
envolvidos.
 Usuários chaves – São aqueles que utilizarão o sistema. São responsáveis pelo
conteúdo da sessão, provendo informações de negócios e compartilhando suas
necessidades e como o novo produto poderia resolver os problemas por eles
reportados.
 Engenheiro de sistemas (analista de requisitos) – Responsável por criar os
documentos das sessões JAD. É responsável pelo registro das decisões e

6
 especificações produzidas. Deve possuir a habilidade para compreender as questões
técnicas e os detalhes discutidos numa sessão.
 Executor (Analista de sistemas) – Responsável pelo desenvolvimento do produto.
Fornece aos participantes uma visão geral do produto e aloca recursos.
 Condutor (líder de sessão) – Pessoa que irá conduzir a JAD e reunir o pessoal para
as sessões. Recomenda-se que o facilitador de encontros possua qualidades
gerenciais de liderança e bom relacionamento interpessoal.
 Observadores (eventuais participantes) – Outras pessoas interessadas no projeto. Os
observadores não são participantes e não são autorizados a opinar durante as
sessões.

4.2 Prototipação
 ajuda os stakeholders a desenvolver uma forte noção sobre a aplicação, ainda não
implementada e com a visualização do protótipo podem identificar os reais requisitos
e fluxos de trabalho do sistema.
 utilizada quando os stakeholders não conseguem expressar seus requisitos ou se não
têm nenhuma experiência com o sistema.
 utilizada no estágio inicial do projeto.
 Implementar de forma rápida um pequeno subconjunto de funcionalidades do produto.
 indicado para estudar as alternativas de interface de entrada ou de saída e eventuais
problemas de comunicação com outros produtos;
 reduzir riscos na construção do sistema, pois o usuário chave já verificou o que o
analista captou nos requisitos do produto.
 escolher ferramenta e/ou ambiente de prototipação
 permite alcançar um feedback antecipado dos stakeholders;
 redução de tempo e custo de desenvolvimento com a detecção de erros em uma fase
inicial do projeto;
 prover maior nível de satisfação dos usuários devido a sensação de segurança ao ver
algo próximo do real;
 demanda maior custo de investimento, em relação à outros métodos, para ser
realizado;
 demanda maior tempo maior para sua realização devido à complexidade do sistema e
a limitações técnicas;

5. Definição de requisitos orientada a ponto de vista - VORD (viewpoint-oriented

requirements definition –
Oferecer um framework orientado a serviço para o levantamento e análise de
requisitos visando descobrir conflitos nos requisitos propostos por diferentes tios de
usuários.
reconhecer a existência de várias perspectivas e ver o problema de modo diferente.

Etapas da análise de ponto de vista

 Identificação dos possíveis pontos de vista reunindo-se com diferentes usuários e
utilizar o brainstorming para identificar os serviços em potencial e as entidades
que interagem com o sistema.
 Estruturação de pontos de vista, que envolve agrupar pontos de vista
relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos
níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior.
 Documentação tem por objetivo refinar a descrição dos pontos de vista e serviços
identificados.
 Mapeamento de sistema conforme ponto de vista envolve identificar objetos em
um projeto orientado a objetos, utilizando as informações de serviço que estão
encapsuladas nos pontos de vista.

7
Conclusão

Todos os métodos de levantamento de requisitos possuem vantagens e desvantagens a

serem consideradas e nenhum deles é completo dadas as inúmeras variáveis de
complexidade, perfil de stakeholders, comunicação, nível de conhecimento do negócio, nível
de qualificação dos profissionais de levantamento de requisitos, situações políticas, nível de
comprometimento dos stakeholders, etc.

Com isso, a utilização de mais de uma técnica, de forma combinada, ou a utilização de

técnicas sintéticas, irá ajudar na complementação de possíveis lacunas de levantamento,
além de melhorar a qualidade e completude dos requisitos visto que pode ocorrer o
batimento cruzado de requisitos similares.

Outro fator importante é a utilização de um framework de decisão para a escolha dos

métodos mais apropriados dado o contexto do trabalho a ser realizado.
Não existe uma técnica padrão para o processo de levantamento de requisitos. Para
alcançar um levantamento de requisitos mais preciso é importante o conhecimento de
diversas técnicas para saber que técnica de levantamento aplicar em cada situação.
É primordial que o desenvolvedor de sistemas possua perfil adequado, mais do que apenas
a capacidade de desenhar fluxogramas e outros diagramas técnicos. Deve projetar e
analisar sistemas de ótimo desempenho e tenha a capacidade de:
 Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar
soluções baseadas em cada divisão;
 Absorver fatos pertinentes de fontes conflitantes ou confusas;
 Entender os ambientes do usuário/cliente;
 Aplicar elementos do sistema de hardware e/ou software aos elementos do
usuário/cliente;
 Comunicar bem nas formas escrita e verbal e entender o objetivo global do software.

A Tabela 1 apresenta os grupos de técnicas para o levantamento de requisitos.

São aplicadas em várias áreas do conhecimento. Ex:
Técnicas tradicionais questionários, entrevistas, observação, e análise de
documentos.
Tem por objetivo compreender melhor o pensamento e
Técnicas de elicitação de
comportamento dos grupos e as necessidades dos usuários.
grupo
Ex: brainstorming e as sessões JAD (Joint Application Design).
O uso de protótipo auxilia na elicitação e validação dos
requisitos de sistema.
Prototipação Pode ser utilizado para elicitar requisitos quando há um alto
grau de incerteza ou quando é necessário um
rápido feedback dos usuários.
Surgiram como uma alternativa para as técnicas tradicionais e
Técnicas contextuais
cognitivas e inclui técnicas de etnografia e análise social.
Tabela 1. Grupos de técnicas para levantamento de requisitos

8
Profa. Vânia Franciscon Vieira