Seleção de técnicas de elicitação de

requisitos de software

Apresentação
Muitos projetos da área de Tecnologia da Informação falham devido a requisitos mal identificados
ou mal compreendidos. Mas quais são as consequências destas falhas? É possível comparar os
requisitos de software aos alicerces de uma casa. Quando a estrutura de uma casa é malfeita, todo o
resto da construção fica comprometida, podendo, inclusive, levar à queda da edificação.

No desenvolvimento de software isso não é diferente. Os requisitos são a base para todas as
demais etapas do desenvolvimento. Se forem mal compreendidos e mal definidos, estes problemas
se propagarão para todas as atividades, levando, no mínimo, ao retrabalho. Além do retrabalho, o
não cumprimento dos requisitos pode acarretar prejuízos ainda mais significativos, como a perda da
credibilidade da empresa no mercado, prejuízos financeiros e, em alguns casos, até mesmo a perda
de vidas humanas.

Por este motivo, é importante focar grande parte dos esforços de desenvolvimento em elicitar
adequadamente os requisitos para que estes possam constituir uma base sólida para o
desenvolvimento de software.

Nesta Unidade de Aprendizagem, você aprenderá a identificar a fonte dos requisitos, ou seja, de
onde o Analista de Requisitos obtém as informações para que possa gerar os requisitos de software.
Aprenderá, ainda, as características das principais técnicas que podem ser utilizadas para elicitar os
requisitos. Por fim, irá compreender como selecionar a técnica de acordo com as características do
contexto.

Bons estudos.

Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:

• Identificar as fontes de informação de requisitos dos projetos de software.

• Reconhecer as características das técnicas de elicitação de requisitos dos projetos de software.
• Selecionar a técnica de elicitação de requisitos de acordo com as características do projeto.
 Desafio
Elicitar requisitos é uma atividade essencial para o sucesso de qualquer projeto que envolve
software. De acordo com as características do contexto, uma técnica pode ser mais adequada do
que outra. Saber selecionar e combinar as melhores técnicas de elicitação de requisitos pode
reduzir significativamente a quantidade de problemas relacionados a eles, como requisitos
incompletos, inconsistentes e invisíveis.

Imagine que você é Analista de Requisitos na área de Tecnologia da Informação de uma empresa
que comercializa planos de saúde.

Conteúdo interativo disponível na plataforma de ensino!

Com base nas informações fornecidas pela empresa, decida quais técnicas de elicitação de
requisitos você irá adotar, levando em consideração as características do contexto e os problemas
apontados.
 Infográfico
A etapa de elicitação dos requisitos é uma das mais críticas no processo de desenvolvimento de
software, independentemente se a equipe está utilizando métodos tradicionais ou inovadores.
Compreender os serviços e funções que o software deve disponibilizar é a base para todas as
demais atividades, inclusive para a etapa de implementação.

A elicitação tem início a partir da compreensão do cenário de negócio no qual o software está
inserido e da identificação das fontes que servirão de base para a coleta de informações. Dessa
forma, a seleção e correta aplicação da técnica minimizarão os riscos de surgimento tardio de
requisitos invisíveis ou esquecidos.

Confira neste Infográfico as etapas para a realização da elicitação de requisitos em projetos de

software. Em seguida, confira um pouco mais sobre o tema por meio de um vídeo.
Aponte a câmera para o
código e acesse o link do
conteúdo ou clique no
código para acessar.
A elicitação de requisitos é um processo fundamental no desenvolvimento de software e envolve
identificação, coleta e compreensão das necessidades dos usuários e das partes interessadas. Neste
vídeo, você vai conhecer as técnicas que podem ser empregadas para capturar informações
detalhadas sobre funcionalidades desejadas, restrições do sistema e objetivos a serem alcançados
em um projeto de software.

Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
 Conteúdo do livro
As consequências da condução inadequada da etapa de elicitação de requisitos em projetos de
software são inquestionáveis e bem conhecidas. Muitas pessoas que trabalham com
desenvolvimento de software já passaram pela frustração de verem seus projetos atrasarem, serem
replanejados e até mesmo cancelados por conta de requisitos que não foram adequadamente
identificados, compreendidos e documentados. Muitas vezes isto ocorre porque a pessoa
responsável pela etapa de elicitação de requisitos esqueceu algum stakeholder importante, não
sabia que existia alguma regulamentação à qual o software deveria ser aderente ou mesmo porque
desconhecia a melhor técnica de elicitação a ser aplicada naquela situação.

No capítulo Seleção de Técnicas de Elicitação de Requisitos, do livro Engenharia de Requisitos, base

teórica desta Unidade de Aprendizagem, você irá aprender a identificar as fontes de informação a
partir das quais pode-se obter os requisitos de um projeto de software. Você também vai conhecer
as técnicas de elicitação de requisitos e suas principais características e , por fim, aprenderá a
selecionar a técnica mais adequada para elicitar requisitos, de acordo com as características da
técnica e do contexto.

Boa leitura.
ENGENHARIA DE
REQUISITOS

Sheila Reinehr
Seleção de técnicas de
elicitação de requisitos
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Identificar fontes de informação de requisitos de projetos de software.

„„ Reconhecer as características das técnicas de elicitação de requisitos
de projetos de software.
„„ Selecionar a técnica de elicitação de requisitos de acordo com as
características do projeto.

Introdução
À medida que a tecnologia faz cada vez mais parte de nossas atividades
cotidianas, cresce nossa dependência do correto funcionamento de
dispositivos e softwares neles contidos. Utilizamos nossos smartphones
para apoiar a maioria das nossas atividades pessoais e profissionais, desde
consultar como está o trânsito no caminho para a faculdade ou o trabalho
até checar a temperatura para escolher a roupa adequada ou consultar a
conta para ver se o pagamento entrou. Não admitimos mais que os bancos
não tenham todos os serviços on-line ou que tenhamos que nos deslocar
até a pizzaria para buscar o lanche. Temos tudo na ponta dos dedos!
Para que essas facilidades nos alcancem na forma de funcionalidades
nos aplicativos do celular ou nos sites na internet, muita coisa precisa
acontecer antes. São necessários profissionais com diversas habilidades
e competências, esforço conjunto e horas de desenvolvimento e testes.
Em algum momento, pessoas criaram esses serviços.
De onde saem as ideias para essas funcionalidades? Quem define
o que um sistema deve executar e como deve executar? Como se faz
2 Seleção de técnicas de elicitação de requisitos de software

para obter essas definições? A resposta é: depende! Depende do tipo

de software, do contexto em que o projeto está sendo desenvolvido,
da tecnologia e dos recursos disponíveis. Há casos em que é possível
conversar com alguém responsável por essas definições e há casos em
que é a lei que determina o que o software deve fazer. Para cada produto
existem também diversos olhares e perspectivas vindos das partes en-
volvidas. Para cada caso existe uma forma mais adequada de descobrir
os requisitos de um produto de software.
Neste capítulo você vai estudar a identificação das fontes de infor-
mação dos requisitos de um projeto de software em função do tipo de
projeto e seu contexto. Vai também conhecer as diversas técnicas para
a elicitação de requisitos e quando elas melhor se aplicam, de modo a
escolher a melhor técnica para cada contexto de desenvolvimento de
software.

1 Quais são as fontes de informação

dos requisitos?
Existem diferentes tipos de produtos de software; cada um implica dife-
rentes tipos de requisitos e, portanto, diferentes fontes de informação para
a obtenção desses requisitos. Sistemas de informação que apoiam as áreas
administrativas de uma empresa são diferentes de jogos de celular, que, por
sua vez, são diferentes de um sistema de controle de tráfego aéreo, que são
diferentes de um sistema de troca de mensagens. As particularidades de cada
tipo de produto e de cada contexto de projeto influenciarão na identificação
das fontes de informação.
Quando falhamos em identificar adequadamente as fontes de informação,
podemos ter, como consequência, usuários esquecidos e, portanto, não ouvidos,
ou requisitos que surgem quando a entrega do produto está sendo realizada.
Portanto, quanto melhor for a nossa capacidade de envolver todas as fontes,
maior será a chance de sucesso do projeto.
No início de um projeto, diversos stakeholders têm um papel importante
para determinar variáveis que influenciarão o seu desenvolvimento. Alguns
poderão definir requisitos de projeto, como orçamento, prazos, premissas,
 Seleção de técnicas de elicitação de requisitos de software 3

restrições e escopo. Geralmente, esses são os clientes, investidores, gestores

ou o próprio gerente do projeto. Outros, serão responsáveis por determinar
requisitos de processo, que influenciarão a forma como a equipe de desenvol-
vimento irá trabalhar. Esses podem ser externos à organização desenvolvedora,
como o próprio cliente ou investidor, ou podem ser internos à organização,
como a área de processos ou de compliance. E haverá um conjunto deles
que definirá efetivamente os requisitos do produto de software, sejam os
funcionais (“o que” o sistema deve fazer), sejam os não funcionais (“como”
o sistema deve fazer). Esses stakeholders são provenientes das mais variadas
áreas, como veremos a seguir.

Tipos de fonte de informação

Existem diversas classificações para os tipos de fonte de informação, como
veremos a seguir. Pohl e Rupp (2015) definem basicamente os três tipos lis-
tados a seguir.

„„ Stakeholders: são pessoas ou organizações que influenciam direta ou

indiretamente nos requisitos do sistema, como usuários, operadores do
sistema, desenvolvedores, arquitetos, clientes e testadores.
„„ Documentos: contêm informações importantes que podem se tornar
requisitos, como documentos de ordem legal ou regulatória, normas e
padrões, documentos específicos do domínio de negócio ou da própria
empresa, como documentos de requisitos de mais alto nível ou docu-
mentos de erros em sistemas legados, por exemplo.
„„ Sistemas em operação: sistemas legados, predecessores ou mesmo
concorrentes. Os sistemas podem ser a fonte de informações sobre
novas funcionalidades desejadas pelos clientes.

Outra forma de compreender as fontes de informação é a proposta por

Wiegers e Beatty (2013), que utilizam o conceito de classes de usuários
para designar um subconjunto de usuários que utilizam as mesmas funções
ou serviços do sistema. Essas classes representam também um indicativo da
prioridade que será dada aos requisitos. Eles apresentam uma hierarquia para
favorecer o entendimento dos conceitos, conforme ilustra a Figura 1.
4 Seleção de técnicas de elicitação de requisitos de software

Stakeholders

Outros
Clientes stakeholders

Usuários diretos Outros clientes

e indiretos

Classes de Classes de Classes de

usuários usuários não usuários Outras classes
favorecidos favorecidos ignorados de usuários

Figura 1. Hierarquia de stakeholders, clientes, usuários e classes de usuários.

Fonte: Adaptada de Wiegers e Beatty (2013).

Como se pode observar nessa proposta, os autores utilizam as seguintes

definições:

„„ Classes de usuários favorecidos: são aqueles usuários que estão mais

diretamente relacionados com a satisfação dos objetivos de negócio
do sistema e, portanto, seus requisitos terão maior prioridade do que
outros requisitos.
„„ Classes de usuários não favorecidos: são usuários que não devem
utilizar o produto, por razões legais, de segurança ou proteção, e que,
portanto, devem ser impedidos de fazê-lo por meio de funcionalidades
implementadas com essa finalidade (como hackers, por exemplo).
„„ Classes de usuários ignorados: são usuários que podem utilizar o
produto, porém não são a razão de existir do produto e os seus requisitos
terão menor prioridade.
„„ Outras classes de usuários: outros usuários que não sejam os ante-
riormente mencionados e que terão igual prioridade na definição de
requisitos.
 Seleção de técnicas de elicitação de requisitos de software 5

É importante lembrar que, no momento da identificação das fontes de in-

formação, todos os potenciais stakeholders precisam ser considerados, mesmo
aqueles que não utilizarão diretamente as funcionalidades do produto. Por
exemplo, há usos indiretos, como aqueles representados por outros softwares,
que podem receber informações a partir do software que está sendo desenvol-
vido, ou mesmo aqueles softwares que realizam funções de forma automática,
representando humanos, como os bots. A equipe de desenvolvimento também
pode ter requisitos não funcionais relacionados, especialmente, à parte interna
do sistema, como portabilidade, manutenibilidade, reusabilidade etc. O usuário
que utiliza uma funcionalidade do sistema provavelmente não se preocupa
com a sua arquitetura interna, mas, para a equipe que será responsável pela
manutenção do produto, esses requisitos são relevantes e influenciarão na
forma como o produto será concebido e desenvolvido.

Em métodos ágeis como o SCRUM, adota-se o papel do product owner (dono do

produto), que é responsável por gerenciar o product backlog (backlog do produto).
Suas principais atribuições relacionam-se à responsabilidade pelo gerenciamento
das prioridades do backlog, bem como garantir que a equipe de desenvolvimento
tenha compreendido adequadamente o significado de cada item do backlog (SCHWA-
BER; SUTHERLAND, 2013). Nesses casos, é função do product owner convergir para
uma visão consolidada dos requisitos entre os interesses dos múltiplos stakeholders
(LEFFINGWELL, 2011).

O grau de envolvimento dos stakeholders pode variar de acordo com as

diferentes necessidades em relação ao projeto e aos requisitos. Leffingwell
(2011) classifica esse envolvimento da seguinte forma:

„„ Stakeholders que devem ser mantidos informados: são aqueles que

precisam saber do status do projeto e precisam ser mantidos informados
acerca das decisões, embora nem sempre tomem parte dessas decisões.
„„ Stakeholders que devem ser consultados: são aqueles que precisam
ser envolvidos devido às suas áreas de expertise, como arquitetos,
projetistas de interface, marketing e especialistas do domínio. Eles
devem ser incluídos nas decisões que envolvem a sua área de expertise.
6 Seleção de técnicas de elicitação de requisitos de software

„„ Stakeholders que serão parceiros no desenvolvimento: são aqueles

que precisam ser envolvidos por serem parceiros no processo, como os
product owners de outros projetos, outras equipes de desenvolvimento,
analistas de negócios ou requisitos e provedores de soluções com as
quais o sistema deve interagir.
„„ Stakeholders que controlam os resultados: são aqueles que tomam
as decisões sobre a solução, como executivos, gerentes de liberação,
usuários-chave que vão utilizar a solução e business owners.

Independentemente de como os stakeholders são classificados, é importante

que a origem dos requisitos esteja clara e que os potenciais stakeholders sejam
envolvidos logo no início do processo de elicitação de requisitos. Segundo
Wiegers e Beatty (2013), a voz do cliente precisa chegar aos ouvidos dos de-
senvolvedores. Para que isso seja possível, é necessário que seja identificado
corretamente quem precisa ter voz no projeto. Todas as classes de usuários
precisam ter alguém que fale por elas.

Pohl e Rupp (2015) sugerem que seja mantida uma lista sempre atualizada com esses
envolvidos. Eles argumentam que, caso a lista esteja incompleta ou exista algum
stakeholder que seja identificado tardiamente, as consequências negativas para
o projeto são certas: aspectos importantes podem permanecer não detectados,
o objetivo do projeto pode se perder ou custos adicionais podem surgir para a correção
dos problemas (retrabalho).

Como descobrir as fontes de informação

Para descobrir quais são as fontes de informação dos requisitos, um bom
começo é conversar com o patrocinador do projeto para que ele identifique as
áreas de negócios que terão alguma interface com o negócio que está sendo
tratado pelo software, bem como identifique possíveis leis ou regulamentações
que precisam ser atendidas. A partir daí podem surgir inúmeras potenciais
fontes de informação que, posteriormente, serão agrupadas dentro de uma
mesma classe, uma vez que tenham os mesmos interesses ou que utilizem as
mesmas funcionalidades.
 Seleção de técnicas de elicitação de requisitos de software 7

Para apoiar a identificação dos stakeholders externos e internos, Leffin-

gwell (2011) recomenda que sejam feitas perguntas como as apresentadas no
Quadro 1.

Quadro 1. Questões de apoio para identificar fontes de informação

Stakeholders externos Stakeholders internos

„„ Quem utilizará diretamente o „„ Quem precisa ser consultado sobre

sistema? o escopo do projeto?
„„ Quem utilizará os resultados „„ Quem contribuiu para o
daqueles que usam o sistema? orçamento e o cronograma?
„„ Quem será responsável por dar „„ Quem gerencia o relacionamento
suporte ao sistema? de negócios entre as equipes e o
„„ Com quais outros sistemas o nosso cliente?
sistema irá interagir? „„ Quem irá determinar como
„„ Que interfaces devem ser e quando o sistema deve ser
fornecidas? entregue para os clientes?
„„ Quem pode fornecer orientações „„ Quem pode afetar ou apoiar
sobre as funcionalidades e os politicamente o projeto?
itens de qualidade do sistema „„ Que parceiros dependem do
(usabilidade, confiabilidade, sistema?
desempenho e manutenibilidade)? „„ Quem se preocupa com o
processo que será usado no
desenvolvimento do sistema?

Fonte: Adaptado de Leffingwell (2011).

Leffingwell (2011) sugere que, para determinados casos, seja utilizado o

mapeamento de personas. Uma persona primária pode ser entendida como
alguém que interage com o software e que necessita de uma interface projetada
especificamente para ela. Uma persona secundária é um usuário que utiliza o
software com uma interface projetada para outro tipo de usuário. Mapear uma
persona significa caracterizar um representante hipotético, genérico, de uma
classe de usuários. Personas devem ser caracterizadas considerando caracte-
rísticas e comportamentos sociais e demográficos, preferências, preocupações
e informações similares (WIEGERS; BEATTY, 2013).
8 Seleção de técnicas de elicitação de requisitos de software

2 Técnicas de elicitação de requisitos

O ponto mais crítico da engenharia de requisitos é a elicitação. Podemos
dizer que ela é o coração do desenvolvimento de requisitos (WIEGERS;
BEATTY, 2013). Não se trata apenas de perguntar o que um grupo de usuários
deseja, mas, sim, de investigar, instigar, questionar, descobrir, explorar —
em resumo, extrair. Não se trata de apenas transcrever o que o usuário relata em
uma conversa, mas sim de explorar, de forma colaborativa, todos os aspectos
necessários para o entendimento correto do requisito. É um constante exercício
de: “e se…”, traduzido como: “e se acontecer tal coisa, como o sistema deve
reagir?”; “e se não acontecer tal coisa, como o sistema deve tratar?”.
Lembre-se, no entanto, de que a tarefa de elicitação de requisitos não é
trivial. Os usuários nem sempre sabem explicar as suas tarefas, podem es-
quecer ou deixar informações importantes de lado ou podem simplesmente
não estar disponíveis ou não quererem prestar informações (BOURQUE;
FAIRLEY, 2014). É função do analista de requisitos obter o engajamento
necessário para que essa atividade ocorra adequadamente, gerando a base para
as demais atividades do ciclo de desenvolvimento de software. Para que isso
seja possível, é necessário selecionar a técnica de elicitação mais apropriada
para cada situação específica.
Uma técnica de elicitação de requisitos pode ser compreendida como
uma ferramenta para auxiliar o analista de requisitos na condução da etapa
de elicitação e compreensão dos requisitos do software. Existem diversas
técnicas disponíveis; algumas implicam a interação direta com um stakeholder
humano, enquanto outras se aplicam a outros tipos de fontes de informação.
Independentemente da técnica selecionada, as seguintes etapas de prepa-
ração são necessárias:

„„ Identificação das fontes de informação: identificação das pessoas com

competência para prestar a informação, bem como das demais fontes
de informação, como documentos, elementos multimídia, softwares
etc., conforme detalhado na seção anterior.
„„ Familiarização com o assunto: buscar conhecer, antecipadamente,
as terminologias e os jargões da área de negócio que está sendo tratada,
bem como os conceitos-chave do negócio. Pesquisas em documentos
do domínio ou uma busca rápida na web podem ajudar.
 Seleção de técnicas de elicitação de requisitos de software 9

„„ Identificação dos objetivos: identificar claramente os objetivos da

elicitação, o nível de informação, os tópicos principais, a relevância,
a precedência e as prioridades.
„„ Elaboração do cronograma: elaborar com antecedência o cronograma
de atividades necessárias, visando à divulgação dos objetivos e infor-
mações logísticas (local, data, horário, materiais necessários).
„„ Identificação dos riscos na elicitação: identificar e documentar os
possíveis riscos envolvidos na elicitação de requisitos e as ações que
serão adotadas para preveni-los ou mitigá-los.

Neste capítulo, iremos abordar as seguintes técnicas, que envolvem a

interação direta ou indireta com fontes de informação humanas:

„„ entrevista;
„„ reunião;
„„ brainstorming;
„„ observação;
„„ questionário.

Ao final da seção, também abordaremos outras técnicas de elicitação que

não envolvem stakeholders humanos.

Entrevista
Uma das formas mais usuais de se realizar a elicitação de requisitos a partir de
fontes humanas é a entrevista. Trata-se de uma conversa entre duas pessoas,
provocada por uma delas, com um objetivo definido. A entrevista proporciona
o contato pessoal, que faz com que o entrevistado se sinta parte do processo
de construção da solução.
A entrevista facilita a obtenção de informações que, muitas vezes, estão
apenas na memória das pessoas, além de informações a respeito dos integrantes
da unidade, como suas qualificações, atribuições, utilização de processos, bem
como opiniões sobre a unidade e o trabalho. Se uma boa relação é estabelecida
com o entrevistado ou com um pequeno grupo de entrevistados, eles podem
se sentir mais seguros para falar sobre questões mais delicadas do que em um
grupo maior (WIEGERS; BEATTY, 2013).
10 Seleção de técnicas de elicitação de requisitos de software

Como qualquer outra técnica, a entrevista exige uma preparação por

parte do entrevistador. É recomendado que ele prepare uma lista de questões
mais abrangentes no início e que, progressivamente, ficam mais detalhadas.
As questões devem seguir uma ordem lógica e abordar um assunto de cada vez.
O roteiro com as questões deve servir apenas para guiar e orientar o processo
de entrevista, ele não deve ser usado de forma restritiva, pois a riqueza do
processo de entrevista está justamente no oposto. O entrevistador tem que
dar espaço para que o entrevistado possa se manifestar livremente sobre seus
anseios em relação à solução que está sendo desenvolvida.
A entrevista pode não obter os resultados desejados, caso ocorra uma das
seguintes situações:

„„ falta de preparo do condutor da entrevista;

„„ falta de preparo do entrevistado;
„„ tendência do entrevistado em dar respostas agradáveis;
„„ tendência do entrevistado em focar em palpites ou em respostas falsas;
„„ resistência do entrevistado com declarações do tipo “não sei”, “não
conheço”.

Veja aqui algumas dicas adicionais para a condução de entrevistas para a elicitação
de requisitos:
„„ conquiste a confiança do entrevistado se apresentando e explicando claramente
a finalidade do encontro;
„„ tome notas durante a entrevista ou grave-a (se o entrevistado permitir);
„„ se possível, utilize o papel do redator (liberando você para focar na conversa com
o entrevistado);
„„ deixe para analisar criticamente depois (não corrija falhas, faça críticas ou discuta);
„„ inicie com questões mais abertas, tipo “como é o trabalho que você realiza?”;
„„ evite termos muito técnicos e tente se aproximar do jargão da área;
„„ evite perguntas com respostas apenas do tipo “sim” ou “não”, que podem limitar
a participação do entrevistado;
„„ se a entrevista se desviar, reconduza, com habilidade, para o fim programado;
„„ se o entrevistado se recusar a fornecer dados, obtenha a cooperação de outros
colegas em papel similar ou, em último caso, do superior hierárquico do entrevistado;
„„ esclareça as possíveis preocupações por parte do entrevistado;
„„ dê abertura para novos contatos, da sua parte e da parte do entrevistado;
„„ valide as informações obtidas com relação ao objetivo previamente estipulado.
 Seleção de técnicas de elicitação de requisitos de software 11

Embora a entrevista geralmente seja conduzida de forma presencial, hoje

já é muito comum que ela também seja realizada on-line, usando ferramentas
de comunicação. O único cuidado é garantir que a tecnologia de suporte
(ferramenta, rede, internet) funcione adequadamente, evitando as interrupções,
que prejudicam o andamento da conversa. Interrupções por falha na tecnologia
fazem com que se perca o ritmo da conversa e se gaste tempo para retomar
ao ponto anterior.
Wiegers e Beatty (2013) ressaltam a importância de praticar a escuta ativa
em todas as interações com os usuários. Isso significa manter uma postura
corporal receptiva, ter paciência, dar feedback verbal e questionar pontos que
não ficaram claros. Além disso, outra forma de demonstrar a escuta ativa é pa-
rafrasear o que o entrevistado disse, demonstrando que entendeu a mensagem.

Reunião
Outra forma bastante comum de elicitação de requisitos é a reunião. Uma
reunião é o intercâmbio de ideias, sugestões e opiniões entre determinados
indivíduos, visando à aceitação de um ponto de vista (esclarecimento, con-
clusão, decisão, linha de ação etc.) por parte dos participantes.
A reunião é uma comunicação direta entre os participantes e permite a
integração do grupo em torno do mesmo assunto, formando uma equipe de
trabalho. Ela é usada para a coleta de sugestões e críticas dos participantes
(discussões, acertos, acordos e busca de consenso e alternativas); aglutinação e
intercâmbio de experiências; e definição de problemas que devem ser tratados
pela solução, explorando as suas causas e efeitos. Ela permite o envolvimento
das pessoas para a tomada de decisão em grupo.
Assim como a entrevista, a reunião exige uma preparação por parte de quem
vai conduzi-la. É preciso organizar a agenda dos tópicos que serão tratados,
bem como o tempo estimado para discutir cada item. O ambiente no qual a
reunião ocorrerá deve ser amplo, ventilado e iluminado. O espaço deve ser
suficiente para acomodar todos os participantes. Material de apoio deve ser
providenciado, como quadro branco e canetas para anotações, computador,
projetor, tela de projeção e demais materiais de escritório.
12 Seleção de técnicas de elicitação de requisitos de software

A reunião tem estes três momentos:

„„ Abertura: apresentação dos participantes, dos objetivos da reunião,

das regras de condução e da duração prevista, bem como definição
do redator da ata de reunião. Caso seja uma reunião de continuidade,
a ata da reunião anterior deve ser lida e os pontos pendentes, tratados.
„„ Abordagem dos tópicos: exposição dos problemas e/ou questões que
se deseja resolver no decorrer da reunião; abertura da discussão e
ponderação até a seleção da alternativa mais adequada; busca pela
decisão consensual, evitando os conflitos.
„„ Conclusão: definição de quem é responsável pelas ações decorrentes
da reunião e como será retornado o feedback para os participantes.

Para que uma reunião com o objetivo de elicitação de requisitos seja bem-
-sucedida, é importante que o analista de requisitos que vai conduzi-la seja
cuidadoso ao se preparar. Existem algumas recomendações que podem ajudar:

„„ encaminhe a agenda para os participantes com antecedência, para que

possam se planejar (assunto, participantes, horário, local);
„„ o término deve ocorrer exatamente na hora marcada, pois as pessoas
têm outros compromissos profissionais e, principalmente, pessoais;
„„ se necessário, faça a reunião em outro local, afastado do ambiente de
trabalho, para evitar interrupções;
„„ não defenda ao extremo os seus dados, prefira levar o grupo a deduzir
que eles estão corretos a partir das informações objetivas;
„„ não mostre contrariedade quando o grupo rejeitar suas ideias;
„„ evite impasses, pois, em uma discussão, não devem existir vencedores
nem derrotados — isso é péssimo para a continuidade do projeto;
„„ não mude de opinião apenas para impedir o conflito, siga os seus ob-
jetivos com coerência;
„„ encaminhe as decisões por meio de consenso, nunca por votação ou
barganha;
„„ ao concluir a reunião, agende data, horário e local da próxima,
se necessário;
„„ se possível, procure registrar os acontecimentos diretamente em uma
ata ou memória da reunião e obtenha as assinaturas ao final da reunião,
evitando assim questionamentos posteriores quanto ao seu conteúdo.
 Seleção de técnicas de elicitação de requisitos de software 13

Embora tudo tenha sido preparado com antecedência, alguns imprevistos

podem acontecer e a reunião pode não ser bem-sucedida caso ocorra uma
das seguintes situações:

„„ se houver uma possível dominação da reunião por um só indivíduo, cujo

talento, personalidade ou conhecimento inibem os demais participantes;
„„ se houver conformidade de alguns participantes, aceitando a opinião
da maioria para se sentirem parte do grupo ou para evitar o conflito
(isso pode inibir soluções novas, arrojadas e diferentes);
„„ se houver faltas, atrasos e saídas antecipadas;
„„ se o ambiente físico for inadequado, levando ao desconforto ou distra-
ções (ambiente com muito barulho, por exemplo);
„„ se houver participação de pessoas não relacionadas ao assunto, que não
contribuem e ainda podem atrapalhar os resultados.

Veja aqui algumas dicas de perguntas para a condução de reuniões para a elicitação
de requisitos:
„„ Pergunta dirigida: pergunta dirigida especificamente a um participante. Ideal
para lidar com pessoas tímidas. Por exemplo: “Gostaríamos de ouvir a opinião de
Fulano sobre o assunto”; “Por favor, Sr. Fulano, poderia nos dizer alguma coisa?”.
„„ Pergunta geral: pergunta dirigida a todos os participantes, com a finalidade de
estimular a discussão. É um meio de reanimar discussões que, repentinamente,
esfriaram. Por exemplo: “Que mais poderíamos considerar a respeito do que foi
exposto?”; “Que outras medidas poderiam ser tomadas nesse caso?”; “Que alter-
nativas vocês sugerem?”.
„„ Pergunta redistribuída: pergunta que é retornada por quem a recebeu para um
dos demais participantes ou a todo o grupo. Por exemplo: “É uma boa pergunta,
como os senhores responderiam?”; “Ninguém melhor do que Fulano, que entende
desse assunto, para responder a essa pergunta”.
„„ Reversa: pergunta endereçada ao condutor, que a devolve a quem a formulou.
Esse processo exige certo tato, porque pode gerar antagonismo ou embaraço no
participante, que pode, receando que isso se repita, optar por não mais se manifestar.
14 Seleção de técnicas de elicitação de requisitos de software

Brainstorming
O brainstorming consiste em uma “tempestade de ideias”, sem julgamentos
ou análises, que ocorre em um ambiente descontraído e informal. Sentar-se
sozinho ou com um amigo para pensar em uma nova ideia não é exatamente
um brainstorming. A aplicação da técnica requer preparação e envolvimento
de mais pessoas.
Inicialmente, deve ser selecionada uma dinâmica para o entrosamento
dos participantes, que permita que o ambiente fique descontraído e propício
à criatividade. É comum que seja alguma brincadeira simples, com cunho
divertido, realizada em pé ou se movimentando. Esse aquecimento não deve
tomar muito tempo do evento.
O material necessário para o brainstorming também deve ser providenciado
com antecedência e pode ser constituído de notinhas adesivas coloridas (tipo
Post-it) e canetas coloridas. A quantidade vai depender da quantidade de
pessoas e dos objetivos do brainstorming. Lembre-se de que a base é a geração
de muitas ideias, e cada uma deve ser escrita em uma notinha.
A seção de brainstorming é composta por três fases: aquecimento (com
a dinâmica selecionada), ideação (com a geração das ideias) e encerramento
(com o agrupamento das ideias). Opcionalmente, pode ser realizada, na última
etapa, uma breve análise ou votação das melhores ideias.

Algumas questões devem ser observadas para que o brainstorming seja realizado
com sucesso:
„„ o brainstorming não se aplica a grupos muito fechados e formais;
„„ o clima precisa ser descontraído e não pode haver críticas, julgamentos e gozações,
pois isso inibe o fluxo de ideias;
„„ quando o grupo for muito grande, o ideal é dividi-lo em subgrupos com não mais
do que 8 pessoas cada (o número depende do contexto e dos perfis).
 Seleção de técnicas de elicitação de requisitos de software 15

Observação
Como o próprio nome sugere, esta é uma técnica na qual o analista de requi-
sitos vai a campo para poder observar como o trabalho ocorre. Esta técnica
utiliza os sentidos na obtenção de determinados aspectos da realidade. Não
consiste apenas em ver e ouvir, mas em examinar fatos ou fenômenos que se
deseja estudar.
A observação pode ser usada para confirmar informações obtidas das
entrevistas, questionários ou documentos, comparando-as com a realidade.
Pode-se levantar volumes, acessar outras fontes de informações (manuais de
procedimentos etc.) e levantar o fluxo de documentos ao longo das tarefas.
Ela é capaz ainda de ajudar a ter ideias sobre pontos nos quais o novo software
pode reduzir gargalos e minimizar trabalhos realizados de forma manual.
A principal limitação da observação é a interferência, mesmo que não
intencional, no ambiente de trabalho. A presença de um observador sempre
provoca perturbações nas pessoas, o que pode alterar as condições reais em que
o trabalho é realizado, por mais discreto que seja o observador. Outra questão
importante é que o observador tem seu próprio ponto de vista, ou seja, a sua
ótica pessoal, e pode tender a criar impressões favoráveis ou desfavoráveis.
Pode haver eventos que ocorrem ocasionalmente e sua ocorrência espontânea
não pode ser prevista, o que impede, muitas vezes, o observador de presenciar
o fato. E, uma última limitação, é que a observação consome tempo e certa-
mente não será viável para ser utilizada em cada tarefa que o usuário realiza.
O tempo de duração de uma observação pode variar, de acordo com o que
se pretende observar. É importante certificar-se que o fenômeno que se deseja
observar irá ocorrer durante o período da observação. Se a necessidade for
de observar algo que ocorre apenas em momentos de pico, por exemplo, é
necessário que sejam identificados os períodos em que esses picos tendem a
acontecer, para que o observador possa estar presente.
O observador deve tomar notas de forma discreta, buscando não despertar
nas pessoas a sensação de estarem sendo vigiadas. Gravações de áudio e vídeo
só podem ser realizadas com autorização.
Há casos em que é possível realizar uma observação menos passiva e mais
ativa, na qual uma interação com o executor da tarefa é possível. Isso pode ser
útil para compreender por que ele tomou aquela decisão naquele momento e
com base em que informações a decisão foi tomada.
16 Seleção de técnicas de elicitação de requisitos de software

A observação requer um olhar atento e muita discrição. Eis o que você deve observar
no ambiente:
„„ Como ocorre o fluxo de atividades entre os participantes do processo?
„„ Existem momentos de pico de atividades?
„„ Existem problemas causados pela tecnologia ou pela ausência dela?
„„ O que acontece quando a tecnologia falha (cai a rede, por exemplo)?
„„ Quais são os fluxos alternativos e casos que requerem um tratamento especial?

Questionário
A técnica de questionário, também conhecida como survey ou pesquisa de
opinião, nada mais é do que a aplicação de um instrumento na forma de ques-
tionário, que tem por objetivo coletar informações de fontes, que podem ser em
grande volume e estar distantes fisicamente. O questionário pode ser a porta
de entrada para outras técnicas, por exemplo, levantando as principais dores
dos usuários com o processo ou o sistema atual (WIEGERS; BEATTY, 2013).
O questionário é composto por um conjunto de perguntas com respostas
objetivas ou abertas, dispostas em sequência lógica e progressiva. O objetivo
do questionário é obter informações que servirão de base para tratamentos
estatísticos. Lembre-se de que, se forem poucas pessoas, talvez seja melhor
realizar uma entrevista. Tenha em mente também que os questionários são
frios e impessoais e não permitem a mesma riqueza de outras técnicas.
Embora, à primeira vista, possa parecer que utilizar um questionário seja
uma atividade simples, na realidade, não é. Elaborar questões é uma tarefa que
exige conhecimento e experiência. Primeiro, porque as pessoas não gostam
de responder questionários e, portanto, ele deve ser curto e fácil de responder.
Segundo, porque exige habilidade para não introduzir viés e nem direcionar
as respostas. E, por fim, as perguntas devem permitir que sejam obtidas as
informações que o analista de requisitos necessita efetivamente.
A preparação do questionário envolve elaborar as questões, estimar o tempo
de resposta, simular previamente as análises e realizar um teste piloto. Esse
teste piloto deve permitir identificar se as pessoas conseguem compreender
adequadamente o que está sendo perguntado e se o tempo de preenchimento
está compatível com o estimado. Ajustes podem ser feitos após o teste piloto.
 Seleção de técnicas de elicitação de requisitos de software 17

Depois da etapa de preparação é que o questionário pode ser distribuído

para o público-alvo, estipulando-se a data esperada para retorno. Lembretes
para resposta podem ser enviados no período.

Para aumentar as chances de sucesso do seu questionário, fique atento a estas dicas:
„„ adicione uma breve introdução, que esclareça os pontos principais;
„„ utilize uma linguagem clara e simples para elaborar as perguntas;
„„ utilize frases concisas, sem prejudicar o entendimento da questão;
„„ utilize termos que evitem a dupla interpretação;
„„ dê preferência para as questões objetivas e que possam ser facilmente tabuladas,
fornecendo conclusões objetivas sobre o trabalho em andamento;
„„ revise se as alternativas cobrem todas as possibilidades que deseja investigar;
„„ não deixe um espaço muito grande para as respostas das questões abertas,
de modo a evitar longos discursos do respondente;
„„ utilize perguntas encadeadas (para testar a coerência das respostas) e perguntas
complementares (fará esgotar o assunto).

Outras técnicas
As técnicas descritas até aqui se aplicam à elicitação de requisitos realizada
quando existem classes de stakeholders que podem ser representadas por uma
pessoa, com a qual se pode fazer contato direto (como entrevistas e reuniões)
ou indireto (como no caso do questionário). Existem ainda outras técnicas
derivadas do design thinking que podem ser utilizadas quando as fontes são
humanas, mas elas não serão objeto deste capítulo.
Existem alguns tipos de requisitos que são provenientes de outras fontes não
humanas, como, por exemplo, leis ou normativas de órgãos regulamentado-
res. No segmento bancário, por exemplo, temos as normativas provenientes
do Banco Central, do Conselho Monetário Nacional, da Comissão de Valores
Mobiliários (CVM) etc. Temos ainda órgãos que regulamentam outros setores
como a Agência Nacional de Saúde (ANS), a Agência Nacional de Teleco-
municações (ANATEL), a Agência Nacional de Energia Elétrica (ANEEL) e
diversos outros. Essas leis ou normativas precisam ser lidas e interpretadas pelo
18 Seleção de técnicas de elicitação de requisitos de software

analista de requisitos junto com os especialistas do negócio. As regras impostas

tornam-se requisitos que devem ser atendidos pelo produto de software.
Algumas vezes, o produto está sendo desenvolvido para substituir um
software anterior, que pode não ter documentação associada e, portanto, a única
fonte dos requisitos é o próprio software que está sendo substituído. Nesses casos,
os requisitos podem ter que ser extraídos por meio da execução simulada
de tarefas (funcionalidades) ou da leitura do código-fonte. Além disto,
pode ainda haver um backlog de sugestões de melhoria pendentes do sistema
anterior, que pode servir de base para as funcionalidades do novo produto.
Abordagem similar é utilizada quando se quer obter requisitos a partir do
produto dos concorrentes, com a diferença de que, normalmente, não se
tem acesso ao código-fonte.

3 Seleção da técnica de elicitação de requisitos

Na fase de elicitação de requisitos nunca se utiliza apenas uma técnica e nem
somente aquela que se conhece, mas todas as que forem necessárias ou apro-
priadas para cada caso. Algumas dicas para aplicar a técnica mais adequada
e obter os melhores resultados de seu uso são descritas no Quadro 2.

Quadro 2. Seleção das técnicas de elicitação de requisitos

Técnica Quando usar

Entrevista „„ Quando existem pessoas que têm o conhecimento

necessário sobre o negócio e que estão disponíveis para
serem entrevistadas.
„„ Para captar as informações subjetivas (desabafos,
sentimentos, pontos de vista) que podem ser úteis para a
definição de requisitos do sistema.
„„ Para identificar o fluxo de trabalho e de documentos.

(Continua)
 Seleção de técnicas de elicitação de requisitos de software 19

(Continuação)

Quadro 2. Seleção das técnicas de elicitação de requisitos

Técnica Quando usar

Reunião „„ Para obter uma resposta rápida de várias pessoas sobre

determinado assunto.
„„ Quando existem problemas ou questões a serem
esclarecidos, compartilhados e expostos com os demais
participantes.
„„ Para envolver o grupo da tomada de decisão.
„„ Para resolver situações de conflito (busca de consenso).
„„ Para fazer levantamento de alternativas e soluções para
determinado problema.
„„ Para analisar, avaliar e resolver problemas que envolvam
pessoas de áreas ou empresas distintas.
„„ Por exigência legal da empresa ou do governo.

Brainstorming „„ Quando o ambiente da empresa é informal e propício para

o desenvolvimento de atividades criativas.
„„ Quando se deseja encontrar soluções inovadoras e criativas.
„„ Quando se deseja lançar novos produtos no mercado.

Observação „„ Quando o fluxo de papéis e de trabalho é relevante.

„„ Quando problemas de desempenho estão relacionados à
forma de executar o trabalho.
„„ Quando a influência do ambiente real é importante.

Questionário „„ Se não houver tempo suficiente para entrevistar todas as

pessoas relevantes.
„„ Se as informações puderem ser adequadamente
trabalhadas para fins estatísticos.
„„ Se as pessoas estão situadas em pontos geográficos muito
distantes.
„„ Se, para prestar informações, houver necessidade de
consultar arquivos físicos.

Wiegers e Beatty (2013) compilaram diversas informações e recomendações

para a seleção da melhor técnica de elicitação de requisitos de acordo com as
características dos projetos. Elas estão representadas no Quadro 3.
20 Seleção de técnicas de elicitação de requisitos de software

Quadro 3. Seleção das técnicas de elicitação de requisitos de acordo com Wiegers e

Beatty (2013)

Análise de documentos
Análise de interface

Análise de interface
Questionário
Grupo Focal

Observação

de sistemas
Entrevista

de usuário
Workshop
Software para o mercado × × ×

Software interno para × × × × × ×

a organização

Software para substituir outro × × × × × ×

Melhorias em sistemas × × × × ×
existentes

Novo software × × ×

Implementação de × × × × ×
pacote de software

Sistemas embarcados × × × ×

Stakeholders distribuídos × × ×
geograficamente

Fonte: Adaptado de Wiegers e Beatty (2013).

Como se pode observar no Quadro 3, os autores consideram duas formas

de elicitação que não foram abordadas neste capítulo: grupo focal e workshop.
Mais informações sobre essas formas de elicitar requisitos podem ser obtidas
em Wiegers e Beatty (2013). Não considere esta lista como definitiva e exaus-
tiva. As técnicas podem ser combinadas de acordo com suas necessidades
em cada projeto.
 Seleção de técnicas de elicitação de requisitos de software 21

BOURQUE, P.; FAIRLEY, R. SWEBOK: guide to the software engineering body of knowledge
version 3. [S. l.]: IEEE Computer Society, 2014.
LEFFINGWELL, D. Agile software requirements: lean requirements practices for teams,
programs, and the enterprise. Upper Saddle River: Pearson Education, 2011.
POHL, K.; RUPP, C. Requirements engineering fundamentals: a study guide for the certified
professional for requirements engineering exam, foundation level, IREB Compliant. 2.
ed. Santa Barbara: Rock Nook, 2015.
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM: um guia definitivo para o SCRUM:
as regras do jogo. [S. l.], 2013. Disponível em: [Link]
scrumguide/v1/[Link]. Acesso em: 31 jan. 2020.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.

Leitura recomendada
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed.
Porto Alegre: AMGH, 2016.
 Dica do professor
Uma das maiores causas de fracasso em projetos de software é a condução indevida das atividades
relacionadas à Engenharia de Requisitos. A mais crítica destas etapas é, certamente, a elicitação de
requisitos. Diversas são as técnicas que podem ser utilizadas para descobrir os requisitos de um
produto de software. O JAD (Joint Application Design ou Joint Application Development) é uma
destas técnicas. Ela visa reunir os stakeholders relevantes do projeto em torno de um mesmo
objetivo: elicitar os requisitos do projeto, reduzindo as possíveis falhas de comunicação e
interpretação.

Nesta Dica do Professor, você irá conhecer um pouco mais sobre o JAD e compreenderá sua
importância em projetos de software.

Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
 Na prática
Um dos cuidados que um Analista de Requisitos deve ter para elicitar os requisitos de um projeto
de software é selecionar adequadamente a técnica que será utilizada. Isso depende das
características do projeto e do contexto no qual ele será desenvolvido. Quando o projeto é
inovador e se busca por soluções criativas, uma boa ideia é utilizar o brainstorming.

A técnica é adequada a ambientes mais informais e descontraídos. Geralmente, se evita o

brainstorming em ambientes muito formais ou muito hierarquizados. Também não se recomenda
misturar níveis hierárquicos quando se deseja explorar as ideias sem críticas e inibições.

Confira, Na Prática, alguns dos desafios que envolvem a atividade de conduzir uma sessão de
brainstorming.
Conteúdo interativo disponível na plataforma de ensino!
 Saiba mais
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:

O que é uma persona?

Neste vídeo, Daniel Furtado apresenta os conceitos sobre o que é uma persona e ressalta a
importância de colocar o usuário como o protagonista do processo.

Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.

Como criar personas?

Neste vídeo, Daniel Furtado apresenta formas de criar uma persona e inicia sua fala com uma
metáfora utilizando Lego. O foco é a análise inicial para verificar se o mercado tem necessidade do
produto que você está desenvolvendo.

Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.

Engenharia de Software
Leia o livro a seguir e aprofunde seus conhecimentos a respeito desta unidade de aprendizagem.

Conteúdo interativo disponível na plataforma de ensino!

Como criar personas?

Neste vídeo, Daniel Furtado apresenta formas de criar uma persona e inicia sua fala com uma
metáfora utilizando Lego. O foco é a análise inicial para verificar se o mercado tem necessidade do
produto que você está desenvolvendo.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.