Engenharia de Software

Técnicas de Elicitação de Requisitos

Prof. MSc. Jonathan Bandeira - jonathan.bandeira@ulife.com.br
 Roteiro

• Técnicas para elicitação/levantamento de requisitos:

• Brainstorming
• Entrevistas
• Etnografia
• Descoberta de Requisitos (Pontos de vista)
• Cenários
• Casos de Uso
• JAD

2
 Processo de Levantamento e Análise de
Requisitos
• Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da
aplicação;
• Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir
seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza
em grupos coerentes;
• Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos
apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
• Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes
do que outros. Esse estágio envolve interação com os stakeholders para a definição dos
requisitos mais importantes;
• Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e
consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
 Brainstorming
• Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que
as pessoas sugiram e explorem ideias.
• As principais etapas necessárias para conduzir uma sessão de brainstorming são:
• Seleção dos participantes: Os participantes devem ser selecionados em função das contribuições diretas que
possam dar durante a sessão. A presença de pessoas bem informadas, vindas de diferentes grupos garantirá
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 de brainstorming
e as regras a serem seguidas durante a sessão;
• Produzir uma boa quantidade de ideias: Os participantes geram tantas ideias quantas forem exigidas pelos
tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma
única ideia. Se alguém tiver problema, passa a vez e espera a próxima rodada.
• Nesta técnica é designada uma pessoa para registrar todas as ideias em uma lousa branca ou em papel. À
medida que cada folha de papel é preenchida, ela é colocada de forma que todos os participantes possam vê-la.
• Analisar as ideias é a fase final do brainstorming. Nessa fase é realizada uma revisão das ideias, uma de cada vez.
As consideradas valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.
 Entrevistas

• Questionar os stakeholders sobre o sistema (ou processo) atual e sobre o sistema que
será desenvolvido.
• Tipos de entrevistas:
• Entrevistas fechadas: conjunto pré-definido de perguntas;
• Entrevistas abertas: sem agenda pré-definida; se adapta para explorar o conhecimento do
stakeholder.

5
 Pesquisa Quantitativa
• A pesquisa quantitativa utiliza uma metodologia baseada em números, métricas e cálculos
matemáticos.
• Ou seja, todos os dados obtidos a partir da pesquisa podem ser traduzidos numericamente em
percentuais.
• Com esse tipo de método, é possível obter respostas objetivas.
• Por exemplo, se a sua necessidade é identificar o número de pessoas que comprariam um
determinado produto que a empresa vai lançar, a pesquisa quantitativa seria capaz de gerar esse dado
numérico.
• A metodologia usa uma amostragem aleatória, mas geralmente composta por um número grande de
indivíduos, a fim de obter resultados mais próximos da realidade possível.
• A conclusão, ao fim da pesquisa, geralmente é obtida com estatísticas e percentuais calculados a
partir dos números coletados.
• Trata-se de um modelo capaz de identificar preferências, comportamentos e tendências entre
consumidores.
 Pesquisa Quantitativa
• A pesquisa quantitativa deve ser usada se o seu objetivo for ter resultados numéricos, estatísticas ou percentuais, sem
aprofundar nas motivações por trás desses dados.
• Como eu falei antes, esse tipo de pesquisa é aplicada a um grande número de pessoas, visto que é mais fácil extrair dela
os resultados por meio dos questionários aplicados.
• A vantagem é que hoje em dia a contagem dos dados é automatizada por sistemas, reduzindo o trabalho humano e
eliminando erros ou retrabalho.
• Utilize pesquisas quantitativas quando quiser validar uma hipótese estatisticamente, com dados concretos e confiáveis.
• É preciso fazer três perguntas ao considerar uma pesquisa quantitativa, avaliando se ela é, de fato a melhor opção. Veja
quais são elas.
• Validade interna: Os dados realmente medem o que eu quero?
• Confiabilidade: Se você repetir a coleta de dados, obterá os mesmos resultados?
• Validade externa: Os resultados podem ser generalizados para outras populações?
• Use a pesquisa quantitativa, por exemplo, se você quiser:
• Comprovar uma hipótese
• Mensurar uma tendência de consumo
• Mensurar conceitos que não são ambíguos.
 Pesquisa Qualitativa
• A pesquisa qualitativa, por sua vez, baseia-se no caráter subjetivo.
• Ou seja, seu resultado não mostra números concretos, e sim narrativas, ideias e
experiências individuais dos participantes.
• Os dados, portanto, são obtidos no formato de palavras  - ideias e concepções do indivíduo.
• Portanto, a pesquisa qualitativa geralmente é feita a partir de entrevistas.
• Ao contrário de identificar percentuais, na pesquisa qualitativa, são encontradas as
motivações por trás de um determinado comportamento ou preferência.
• Então, já dá para perceber que ela apresenta uma abordagem aprofundada.
• Justamente por isso, a amostragem é menor. São selecionados menos indivíduos em
relação à pesquisa quantitativa.
• No entanto, a pesquisa é capaz de extrair insights a partir da subjetividade do participante,
indo além dos números.
 Pesquisa Qualitativa
• Como a pesquisa qualitativa lida com a subjetividade, é o método apropriado para entender motivações,
opiniões, pensamentos e ideias das pessoas entrevistadas.
• Dá até mesmo para descobrir tendências por meio desse tipo de pesquisa.
• Nesse caso, as pessoas entrevistadas podem ser consumidores do mercado ou mesmo clientes da empresa.
• Trata-se de um modelo eficiente para desenvolver hipóteses e obter insights sobre o problema específico
que você pretende resolver.
• Algumas situações adequadas para esse modelo, de acordo com os autores, são estas:
• Descobrir necessidades de clientes
• Identificar o comportamento dos compradores
• Obter entendimento dos negócios
• Conhecer a linguagem usada pelas pessoas
• Criar novas ideias.
• Em poucas palavras, você deve optar pela pesquisa qualitativa quando sua necessidade for obter uma
resposta mais profunda e personalizada, seja na hora de validar o teste de um produto ou de criar uma
campanha de marketing, por exemplo.
 Etnografia
• É uma técnica de observação utilizada para compreender os requisitos sociais e organizacionais
• O analista (engenheiro de requisitos) se insere na organização do cliente
• Observa o trabalho no dia a dia;
• Anota as tarefas dos funcionários.

10
 Etnografia
• É eficaz:
• Para descobrir como as pessoas realmente trabalham
• Para descobrir a cooperação e conscientização das atividades de outras pessoas
• Para desenvolver um protótipo
• Para descobrir importantes detalhes que outros métodos omitem

11
 Levantamento por pontos de vista

• Em uma empresa de tamanho médio ou grande, existem vários stakeholders;

• Cada stakeholder tem um ponto de vista diferente;
• Cada um vê o problema de modo diferente;
• Objetivo: conhecer o problema por várias perspectivas.

12
 Levantamento por pontos de vista
• A primeira etapa da análise de ponto de vista é identificar os possíveis pontos de
vista. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a
abordagem de brainstorming para identificar os serviços em potencial e as
entidades que interagem com o sistema.
• A segunda etapa é a 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.
• A etapa de documentação do ponto de vista tem por objetivo refinar a descrição
dos pontos de vista e serviços identificados.
• O 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.
Levantamento por pontos de vista

14
Pontos de vista em um Sistema Bancário

15
Estruturação de pontos de vista

16
Levantamento por pontos de vista - Dificuldades

• Stakeholders frequentemente:
• Não sabem na realidade o que querem;
• Não conseguem expressar claramente o que desejam;
• Fazem pedidos não realistas;
• Se expressam com seus próprios termos (técnicos);

• Diferentes stakeholders expressam o mesmo requisito de forma diferente.

17
Levantamento por pontos de vista - Armadilhas

• Alguns stakeholders podem pedir requisitos para aumentar o seu poder na empresa;
• O ambiente é dinâmico: novos stakeholders e novos requisitos podem surgir;
• Pontos de vista podem apresentar duplicidade ou inconsistência.

18
 Cenários de Uso

• Descreve uma situação de uso do sistema

• Inclui informações como:
• Nome do Cenário
• Ator(es)
• Pré-condição
• Fluxo normal
• Fluxos alternativos
• Pós-condição

19
 Cenários de Uso - Exemplo
• Nome do Cenário: Sacar dinheiro
• Ator: Correntista
• Pré-condição: Conta e senha validada
• Fluxo normal
• 1. Entrar com valor do saque
• 2. Confirmar dados e operação
• 3. Debitar valor da conta do cliente
• Fluxo alternativo: Saldo insuficiente
• 3.1 Apresentar aviso ao cliente
• Pós-condição:
• Valor sacado é debitado do saldo do cliente
20
 Casos de Uso
• Casos de Uso identificam
• Os atores envolvidos
• As funcionalidades principais
• A interação entre atores e funcionalidades do sistema

21
 JAD
• JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários
desenvolvedores.
• O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores
ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e
responsabilidade com o sucesso do produto.
• A técnica JAD tem quatro princípios básicos:
• Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos
participantes. O resultado final será a determinação dos 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: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de
uma análise completa reduzindo 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. Este documento garante a qualidade esperada do
projeto e promove a confiança dos participantes.
• A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que
se lida com o projeto de software.
• Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja,
organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais
encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização
tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
 JAD
• Há seis tipos de participantes, embora nem todos participem de todas as fases:
• Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento
pessoal e qualidades gerenciais de liderança;
• Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um
desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar
ideias e expressá-las com clareza;
• Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do
produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto
do novo produto;
• Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os
representantes são frequentemente gerentes ou pessoas-chave dentro da empresa que tem uma visão melhor do todo e de como ele será
usado;
• Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu
papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça;
• Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.
• 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.
• A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas
sessões JAD para acelerar a definição dos requisitos do sistema.
Leitura - Técnicas de Elicitação de Requisitos
• https://retraining.inf.ufsc.br/guia/app/classificacoes/tecnicas-de-elicit
acao-de-requisitos/entidades
Exercício – Simulando uma entrevista fechada
(Elaboração das Perguntas)
• Escolher um dos produtos: gestão de escola, gestão de biblioteca ou
gestão de clínica médica.
• Em equipes, elaborar um conjunto de 10 perguntas em um google
forms para cada um dos diferentes stakeholders entrevistados.
• Dentro destas perguntas, 5 devem ser objetivas (levantamento
quantitativo) e 5 devem ser discursivas (levantamento qualitativo).
• Considerar no máximo até 3 stakeholders, num máximo de 30
perguntas e no mínimo 2 stakeholders, num mínimo de 20 perguntas.
Exercício – Simulando uma entrevista fechada
(Aplicação)
• Divulgar o forms para que seja respondido pelos stakeholders.
• Deixar o formulário ser respondido por duas semanas.
Exercício – Simulando uma entrevista fechada
(Identificação dos Requisitos)
• Em meio as respostas, identificar os requisitos de software funcionais
e não-funcionais.
• Separar os requisitos de acordo com a visão de cada tipo de
stakeholder (levantamento por pontos de vista).
• Comparar os requisitos obtidos neste exercício com os identificados
no exercício anterior.
 Bibliografia
PRINCIPAL
• MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0. São Paulo: Pearson Education, 2004.
• https://bv4.digitalpages.com.br/?term=uml&searchpage=1&filtro=todos&from=busca&page=-
20&section=0#/legacy/2921

• RAMAKRISHNAN, Raghu; GEHRKE, Johannes.Sistemas de Gerenciamento de Bancos de Dados. 3.

edição. Porto Alegre: Bookman, 2007.
• https://integrada.minhabiblioteca.com.br/#/books/9788563308771/cfi/0!/4/2@100:0.00
• PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Uma abordagem profissional. 8a. Ed.
Bookman, 2016.
• https://integrada.minhabiblioteca.com.br/#/books/9788580555349/cfi/3!/4/2@100:0.00

28
 Bibliografia
COMPLEMENTAR
• SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
• https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&fil
tro=todos&from=busca&page=_14&section=0#/legacy/276

• PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall,
2004.
• https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&fil
tro=todos&from=busca#/legacy/476

• LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a
objetos e desenvolvimento iterativo. 3. ed Porto Alegre: Bookman, 2007.
• https://integrada.minhabiblioteca.com.br/#/books/9788577800476/cfi/0!/4/2@100:0.00
• FOWLER, Martin; SCOTT, Kendall. UML essencial: um breve guia para a linguagem-padrão de
modelagem de objetos. 3ª. ed. Porto Alegre: Bookman, 2004.
• https://integrada.minhabiblioteca.com.br/#/books/9788560031382/cfi/6/2!/4/2@0:0.131
• HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011. 29
 Engenharia de Software
Técnicas de Elicitação de Requisitos
Prof. MSc. Jonathan Bandeira - jonathan.bandeira@ulife.com.br